推荐系统为啥都长一个样？聊聊「离线训练 + 在线召回 + 排序」这套大数据架构
如果你干过推荐系统，不管是内容推荐、电商、广告、资讯、短视频，大概率都会发现一件事：
架构看起来都差不多，但效果差距却能差出一个银河系。
我这些年看过、拆过、踩过的推荐系统不算少，越到后面越有一个感受：
推荐系统拼到最后，真不是算法多高级，而是架构是不是“拧得顺”。
今天我们就掰开揉碎，聊聊这套最经典、也最现实的推荐系统架构：
离线训练 + 在线召回 + 在线排序
一、先说结论：为啥推荐系统一定要拆成三段？
一句话总结：
不是为了优雅，而是为了活命。
推荐系统天然就有三大矛盾：
- 数据量巨大（全量用户 × 全量物品）
- 实时性要求极高（几十毫秒内给结果）
- 模型又想越复杂越好
这三件事，你想一锅端，结果只有一个：
👉 系统崩、效果差、老板不开心
所以业界最终形成了一个非常“工程味”的共识架构：
离线：负责“想清楚”
在线：负责“跑得快”
拆开来看，就是三段：
- 离线训练：用大数据慢慢算
- 在线召回：快速缩小候选集
- 在线排序：精排出最终结果
二、离线训练：推荐系统真正“聪明”的地方
1️⃣ 离线训练到底在干嘛？
说人话版本：
用昨天甚至更早的数据，训练一个“大概靠谱”的模型。
典型离线任务包括：
- 用户画像构建
- 物品画像生成
- Embedding 训练（user / item 向量）
- 召回模型、排序模型训练
这一层的关键词只有一个：
全量 + 稳定 + 不着急
所以技术选型一般是：
- Spark / Flink Batch
- Hive / HDFS / Lakehouse
- TensorFlow / PyTorch 离线训练
2️⃣ 一个很真实的例子：Embedding 离线训练
比如用户-物品 Embedding，离线训练完之后：
# 伪代码：离线训练 user/item embedding
model = MatrixFactorization(
user_cnt=num_users,
item_cnt=num_items,
dim=128
)
model.fit(user_item_interactions)
# 训练完成后导出 embedding
user_embeddings = model.get_user_embedding()
item_embeddings = model.get_item_embedding()
关键点不是代码，而是输出物：
- user_id → 向量
- item_id → 向量
👉 这些向量，是后面在线召回和排序的“弹药库”。
三、在线召回：推荐系统的“第一道生死线”
1️⃣ 为啥一定要有召回？
你想象一个极端情况：
- 1 亿用户
- 1 千万内容
你如果在线直接算：
1 个用户 × 1000 万内容 = 1000 万次打分
老板会很冷静地告诉你一句话：
“你这是在做压力测试，不是在做推荐。”
所以召回的核心目标只有一个：
从海量内容中，秒级挑出几十到几百个“可能有戏”的候选。
2️⃣ 常见的召回方式（不追求多，只追求稳）
现实项目里，召回基本都是多路并行：
- 协同过滤召回
- Embedding 向量召回
- 热门 / 新品 / 活跃召回
- 规则召回（关注、订阅、地理位置）
比如一个非常典型的向量召回：
def recall_by_embedding(user_embedding, item_index, top_k=200):
# ANN 检索（FAISS / HNSW）
item_ids = item_index.search(user_embedding, top_k)
return item_ids
召回层最大的 KPI 不是“准”，而是“不漏”。
这句话很重要。
很多新人一上来就追求召回精准度，结果把后面排序的空间全杀死了。
四、在线排序：真正决定“点不点”的地方
1️⃣ 排序模型才是离用户最近的“刀锋”
召回只是“候选”，排序才是：
谁在第 1 位，谁直接凉。
排序模型的输入，通常是：
- 用户特征
- 物品特征
- 上下文特征（时间、设备、位置）
- 用户 × 物品的交叉特征
一个极简示意：
def rank(user, candidates):
features = build_features(user, candidates)
scores = ranking_model.predict(features)
return sorted(candidates, key=lambda x: scores[x], reverse=True)
2️⃣ 为什么排序一定是在线的？
因为排序要用的东西太“新”了：
- 刚点过什么
- 当前时间段
- 最近几分钟行为
- 实时上下文
这些东西：
等你离线算完，用户都下一个 App 了。
所以排序模型一定是：
- 轻量
- 可快速推理
- 延迟可控
五、这套架构真正的难点，其实不在算法
说点掏心窝子的。
我见过太多团队：
- 模型写得很漂亮
- 论文指标很好看
- 线上效果却一塌糊涂
问题往往出在这几件事上：
1️⃣ 离线和在线特征不一致
离线训练用 A 特征，在线服务用 B 特征
这是推荐系统里最经典、也最隐蔽的坑。
解决思路只有一个：
- 特征工程平台化
- 一套代码，多端复用
2️⃣ 召回太“保守”
怕脏、怕噪声、怕误点，结果：
召回池里全是“老熟人”，系统越来越无聊。
我个人非常认同一句话：
推荐系统一定要“允许犯错”，否则永远不会进化。
3️⃣ 架构不是越复杂越好
不是所有团队都需要：
- 10 路召回
- 3 层排序
- 强化学习在线调参
很多时候：
一套干净、可解释、稳定的架构，胜过一堆花活。
六、写在最后：推荐系统其实很“人性化”
做久了你会发现，推荐系统不像传统算法那么“冷”。
它更像一个人：
- 离线训练 = 复盘昨天
- 在线召回 = 快速想起可能的选项
- 在线排序 = 临场判断
真正好的推荐系统，不是“算得最准”，而是：
在算力、延迟、业务目标之间，找到那个最现实的平衡点。
