精排精度高，为何不跳过召回粗排？

回答与解析

核心原因：候选规模与交互计算不匹配

Cross-Encoder 会把 query 和每个候选文档联合编码，文档侧表示通常不能像双塔向量那样预计算并复用。若对全库 N 个候选逐一精排，就需要 O(N) 次 query-document 前向计算和对应的数据读取；在大规模语料上，延迟、吞吐和成本都不适合在线服务。

分层漏斗

候选数没有通用的“千、百、十”标准，应根据语料规模、召回曲线、模型吞吐、并发和延迟预算选择。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 下是否划算。

关键一句:当候选规模不大或模型足够轻量时，分层不是必须的，可以合并召回和粗排。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商推荐，用户一进来，后台有上千万商品。精排模型效果最好，为啥不直接让精排对所有商品打分，非要先召回再粗排？

2. 问法 2 · 层层追问

   你了解推荐系统的漏斗架构吧？……那为什么精排模型更准，却放在最后，而不是一开始就用？……从计算和系统设计角度看，直接全量精排有什么问题？

3. 问法 3 · 直球架构

   既然精排模型精度更高，为什么不能跳过召回和粗排，直接对所有候选进行精排？请从计算效率和系统架构角度解释一下你的理解。