完整题目
既然精排模型精度更高，为什么不能跳过召回和粗排阶段直接对所有候选进行精排？请从计算效率和系统架构角度解释。
本文目录
核心原因：候选规模与交互计算不匹配
Cross-Encoder 会把 query 和每个候选文档联合编码，文档侧表示通常不能像双塔向量那样预计算并复用。若对全库 N 个候选逐一精排，就需要 O(N) 次 query-document 前向计算和对应的数据读取；在大规模语料上，延迟、吞吐和成本都不适合在线服务。
分层漏斗
| 阶段 | 典型方法 | 主要目标 |
|---|---|---|
| 召回 | BM25、稠密向量 ANN、规则召回 | 用索引快速取得高召回候选 |
| 粗排（可选） | 双塔分数、轻量模型、业务特征 | 在较低成本下进一步压缩候选 |
| 精排 | Cross-Encoder 或其他重交互模型 | 对小候选集做精细相关性排序 |
候选数没有通用的“千、百、十”标准，应根据语料规模、召回曲线、模型吞吐、并发和延迟预算选择。ANN、倒排索引和其他召回结构的复杂度也依具体实现与数据分布而定，不能统一写成 O(1) 或 O(logN)。
系统边界与验证
召回负责控制计算量并保证相关文档进入候选集；精排只能重排已召回内容，无法补回漏掉的证据。工程上应分别测 Recall@K、排序指标、端到端回答质量、P50/P95/P99 延迟、吞吐和成本，再调候选规模与 batch。若要估算全量精排成本，应使用目标硬件上实测的每批吞吐和并发数据，不能用脱离环境的固定毫秒数代替 profile。
图解
换一种问法，检查是否真正理解
场景切入
假设你在做电商推荐，用户一进来，后台有上千万商品。精排模型效果最好，为啥不直接让精排对所有商品打分，非要先召回再粗排？
层层追问
你了解推荐系统的漏斗架构吧？……那为什么精排模型更准，却放在最后，而不是一开始就用？……从计算和系统设计角度看，直接全量精排有什么问题？
直球架构
既然精排模型精度更高，为什么不能跳过召回和粗排，直接对所有候选进行精排？请从计算效率和系统架构角度解释一下你的理解。
练习口述回答 · 约2分钟
- 本质问的是系统效率和架构取舍
- 计算效率：全量精排的复杂度爆炸
- 系统架构：分层漏斗的设计价值
- 工程约束：延迟和成本的实际限制
- 落地风险与判断收尾
我的判断是，这道题本质上在问质量、延迟和成本怎样权衡。Cross-Encoder 会联合编码 query 与每个候选文档，文档侧表示通常不能像双塔向量那样预计算复用。若对全库 N 个候选逐一精排，就要做 O(N) 次前向计算和对应的数据读取，大规模在线服务通常承受不了。
比如企业知识库有大量文档时，我会先用 BM25、稠密 ANN 或规则召回取得高召回候选；需要时再用双塔分数、轻量特征或业务模型做粗排；最后用 Cross-Encoder 对小候选集精细排序。粗排是可选层，召回和精排也可以在小语料或轻模型场景合并，不存在必须三层的固定架构。
候选规模没有统一的千万、几万、几百或 Top-50 标准，召回索引的复杂度也不统一是 O(1) 或 O(logN)。我会在目标硬件上测模型 batch 吞吐、数据读取、并发和延迟分位数，再决定各层预算，而不是用固定毫秒数替代 profile。
这里最大的失败风险是召回漏掉关键证据，因为精排只能重排已召回内容，无法把漏掉的内容补回来。所以要分别看 Recall@K、排序指标、端到端答案质量、P50/P95/P99 延迟、吞吐和成本，联合调整候选规模。上线前还要做压测和监控；如果延迟或成本超过预算，就降级到轻量模型、缩小候选集或限制并发，并验证降级后的质量护栏。
如果语料很小、精排模型足够轻，或者使用 late interaction 等可索引结构，可以减少层级。结论不是“永远不能全量精排”，而是用实测证明在质量门槛和 SLA 下是否划算。