协同过滤（基线方案）
使用场景: 构建首个推荐器的开发者
候选生成：用户-物品矩阵分解
召回：相似用户喜欢的物品
排序：基于基础特征的简单 GBDT 模型
重排：过滤已看过的物品
冷启动由热门兜底处理
这样组织的原因: 协同过滤是经典起点——图表的召回阶段找出相似用户喜欢的物品，有交互数据后效果不错，但对新用户和新物品需要兜底。
真实案例
双塔召回
使用场景: 把召回扩展到数百万物品的团队
用户塔和物品塔产出 Embedding
召回 = 在物品 Embedding 上做近似最近邻检索
物品 Embedding 预计算并索引（向量库）
排序模型对召回的 Top-N 重新打分
随行为变化重训双塔
这样组织的原因: 双塔召回把召回变成向量检索来扩展——图表增加 Embedding 索引，因为大规模下为每个物品打分不可行，于是召回变成对预计算物品向量的 ANN 查找。
实时推荐
使用场景: 用新鲜信号提供推荐的团队
从实时用户事件更新的流式特征
用于排序的在线特征存储（低延迟）
召回混合预计算候选与会话内物品
排序在紧的延迟预算内按请求运行
行为流式回流，秒级更新特征
这样组织的原因: 实时推荐器增加流式特征路径——图表把特征存储拆为在线和离线，因为最新的会话内行为必须在请求的延迟预算内到达排序模型。
基于 LLM 的推荐
使用场景: 用 LLM 排序或解释推荐的团队
召回保持传统（对物品检索）
LLM 用自然语言上下文重排候选
用户意图表达为提示词，而非仅点击
LLM 为每个推荐生成解释
Embedding 桥接物品与 LLM 的上下文
这样组织的原因: 基于 LLM 的推荐器通常保留传统召回，把 LLM 放在排序 / 解释阶段——图表展示 LLM 对召回的候选列表重排，因为对整个目录跑 LLM 会太慢太贵。
使用技巧
- 把漏斗画成独立的召回和排序阶段——合并会掩盖推荐器为何能扩展（廉价召回、对少量物品做昂贵排序）。
- 把特征存储画成供给排序的独立节点；特征是共享基础设施，不是模型的一部分。
- 把用户行为反馈循环画出来——没有反馈路径的推荐器无法改进。
- 把业务规则和多样性放在模型之后的重排阶段，而非模型内部；它们是产品决策，不是学习到的分数。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=recommendation-system-architecture
编辑此推荐系统模板