06 · 工业架构：召回 → 粗排 → 精排 → 重排

⏱ 20 分钟 ｜ ⭐⭐⭐ 全教程最重要的一节

🎯 一句话

真实推荐系统是一个漏斗：每一层用「更贵但更准」的模型处理「更少」的候选。用计算量换准确度，用分层换时延。

如果你只看这份教程的一节，看这节。这是所有推荐岗面试的第一个问题。

🚰 全景图（把它印在脑子里）

🤔 为什么必须分层？（一道算术题）

假设你的精排模型对一个 (用户, 物品) 打分要 0.1 毫秒。

核心权衡：

              准确度 ↑                 候选数量 ↑
   召回  ┃  ▁▁▁▁                    ████████████████
   粗排  ┃  ▃▃▃▃▃▃                  ████
   精排  ┃  ████████████            ▃
   重排  ┃  ██████ (+业务规则)       ▁

💡 一句话记住：越往后，模型越贵，候选越少。总计算量在每一层大致相当。

① 召回：多路并行，宁滥勿缺

核心心态转变 ⭐

召回不追求「排得准」，只追求「别漏」。

• 召回把好东西漏了 → 后面所有环节都救不回来（不可逆错误）
• 召回混进烂东西 → 精排会把它排到后面（可逆错误）

所以召回的指标是召回率，不是准确率。

典型的多路召回配置

一个真实的信息流产品会同时跑 20–50 路召回，每路出几百个：

合并方式：各路取 TopN → 去重 → 打上「来源」标记 → 送入粗排。

🔧 实战经验：加一路新召回通常比调优现有模型的收益更大。 召回的多样性 ≈ 系统的天花板。 但每路都要配额，否则某一路会淹没其他路。

② 粗排：一个「妥协」的产物

粗排本质是个工程妥协：召回出了 1 万个，但精排模型只跑得动 500 个，中间需要一刀。

关键设计约束：粗排必须比精排快至少 10 倍，同时尽可能像精排。

常见做法

粗排的正确指标

❌ 不是 AUC。 ✅ 是 「粗排 Top-K 和精排 Top-K 的重合度」（一致性 / Recall@K vs 精排）。

因为粗排的唯一职责是「别把精排会喜欢的东西砍掉」。

③ 精排：全系统的核心战场

这里是模型最复杂、投入最大、收益最直接的地方。

特征规模

用户特征     ID、画像、长期兴趣、短期行为序列（近500次）……      ~百维
物品特征     ID、类目、作者、时长、统计特征、多模态Embedding……  ~百维
上下文特征   时间、地点、设备、网络、当前会话……                 ~几十维
交叉特征     用户类目偏好 × 物品类目、用户价格带 × 物品价格……    ~几百维
────────────────────────────────────────────────────────────
总计         几百到几千维，Embedding 表可达 TB 级

⭐ 多目标：精排真正复杂的地方

用户在一个视频上可以做很多事，每一件都是一个预估任务：

融合公式（真实公司里的样子）：

$$\text{Score} = pCTR^{w_1} \times (\alpha + pFinish)^{w_2} \times (\beta + pLike)^{w_3} \times \cdots$$

🎚️ 这些 w 是业务旋钮，不是学出来的。 调大 pFinish 的权重 → 长视频更容易被推；调大 pShare → 内容更「social」。 算法工程师和产品经理吵架的主战场就在这几个数字上。

多任务模型架构演进

  ①  Shared-Bottom (最朴素)
      共享底层 → 每个目标一个塔
      ❌ 问题：任务冲突时互相拖后腿（跷跷板效应）

  ②  MMoE (Google, 2018)  ⭐ 工业界最常用
      多个专家网络 + 每个任务一个门控网络自己挑专家
      ✅ 任务间有冲突时也能各取所需

  ③  PLE / CGC (腾讯, 2020)
      专家分成「共享专家」和「任务专属专家」
      ✅ 进一步缓解跷跷板

  ④  ESMM (阿里, 2018)
      针对 CVR 的样本选择偏差：pCTCVR = pCTR × pCVR
      ✅ 在全空间建模，解决「只有点击了才有转化标签」的问题

④ 重排：模型管不了的事，规则来管

精排给出了「每个物品单独看有多好」，但最终展示的是一个列表，列表有列表的问题：

现代做法：不只是规则

• PRM (Personalized Re-ranking)：用 Transformer 建模整个列表，考虑物品间的相互影响
• 生成式重排：直接生成整个序列，评估「列表整体收益」而非「单点收益之和」

🗺️ 一次完整请求的时序图

 t=0ms    用户请求到达
          ↓
 t=0-10   【特征服务】拉用户画像、实时行为序列 (Redis/特征平台)
          ↓
 t=10-40  【召回】20 路并行 ────┬─ ItemCF 查倒排  (2ms)
                               ├─ 双塔 ANN 检索   (8ms)
                               ├─ 标签召回        (3ms)
                               ├─ 热门(缓存)      (1ms)
                               └─ ... 取最慢的那路
          ↓ 8000 个候选
 t=40-60  【粗排】小模型批量打分 → 留 500
          ↓
 t=60-140 【精排】大模型批量打分 → 多目标融合 → 留 50
          ↓
 t=140-150【重排】打散 + 多样性 + 业务规则 → 留 10
          ↓
 t=150    返回结果
          ↓
 [异步]   曝光埋点 → 消息队列 → 实时特征更新 + 样本落盘 → 模型训练

⚠️ 端到端预算通常是 200–500ms。超时怎么办？降级：跳过精排直接用粗排结果，或直接返回缓存/热门。永远不能返回空。

💡 三个反直觉但极其重要的经验

1. 各层的优化收益不同，且随时间变化

早期系统：加召回路 收益最大。 成熟系统：精排模型 + 特征 收益最大。 超大规模系统：重排和多样性 反而成为增长点（因为单点准确度已经饱和）。

2. 「链路一致性」是隐形杀手

如果召回按 A 标准选、精排按 B 标准排，好东西会在中间被误杀。 → 现代做法：用精排的分数去指导（蒸馏）粗排和召回的训练，让全链路目标对齐。

3. 离线涨了，线上不一定涨

离线 AUC +0.5%，线上 CTR 可能不动甚至跌。原因： - 离线用的是历史曝光数据（有偏），线上面对的是全量候选 - 离线没有多样性/新鲜度约束，线上有 - 用户会适应，短期涨不代表长期涨

→ 一切以 A/B 实验为准（第 12 节）。

🔗 这一章连到哪里

✅ 检查点

这几题请务必答出来，面试必考：

1. 画出推荐系统四层架构，说出每层的候选数量级和耗时。
2. 为什么召回的指标是召回率而不是准确率？
3. 粗排的指标应该是什么？为什么不是 AUC？
4. 多目标融合的权重是学出来的还是人定的？
5. 「链路一致性」是什么问题？怎么缓解？
6. 端到端超时了怎么办？

🛑 可以停在这里 —— 你已经掌握了推荐系统的骨架

到这一节为止，你已经能和推荐算法工程师正常对话了。

后面的章节都是往这个骨架上挂肉： - 第 7、8 节 → 精排的模型和特征 - 第 9、10 节 → 召回的模型和检索 - 第 11 节 → 重排 - 第 12、13、15 节 → 让它真的能上线

⚡ 走神救援

四层漏斗：召回(1亿→1万,多路并行,重召回率) → 粗排(→500,精排蒸馏,重一致性) → 精排(→50,多目标 MMoE,重 AUC) → 重排(→10,多样性+业务规则)。总时延 200ms 内。核心权衡：越往后模型越贵候选越少。三个坑：链路不一致、离线涨线上不涨、超时要降级。⭐ 每一层的正确指标是不一样的：召回只看 Recall（别漏），粗排看的不是 AUC 而是「粗排 Top-K 与精排 Top-K 的重合度」——它唯一的职责是别把精排会喜欢的东西砍掉；精排才看 AUC。⭐ 精排真正复杂的地方是多目标：pCTR / pFinish / pLike / pShare 各预估一个，再乘起来融合成最终分，而那几个权重 w 是业务旋钮，不是学出来的——它就是算法和产品吵架的主战场。架构上 Shared-Bottom 会有跷跷板效应，MMoE 用门控让每个任务自己挑专家，PLE 再拆出「共享专家 + 任务专属专家」，ESMM 则用 pCTCVR = pCTR × pCVR 解决「只有点击了才有转化标签」的样本选择偏差。⚠️ 各层的收益会随系统成熟度迁移：早期加召回路最赚，成熟期靠精排模型和特征，超大规模系统反而是重排和多样性成为增长点。

下一节 👉 07-特征工程.md