考察点
Rerank 是 RAG 优化链路里面试官爱问的进阶题。它考察你是否理解「检索是两阶段」的架构思想：召回要快、精排要准，用不同模型各干各的。能讲清双塔和交叉编码器的本质差异，才算真懂。追问常走「Rerank 模型怎么选」「延迟怎么办」「能不能用大模型代替」。
参考答案
为什么需要 Rerank
向量检索用的是双塔架构：文档离线编码成向量，query 在线编码成向量，两者算余弦相似度。问题是 query 和文档的向量是独立编码的，模型在编码 query 时根本不知道文档内容，交互信息全靠最后那一个点积——表达瓶颈就在这。
**交叉编码器（Cross-Encoder）**不一样：它把 query 和文档拼成一对，一起送进 Transformer，让两者在每一层充分交互，最后输出一个相关性分数。精度高得多，但每对都要完整跑一遍前向——百万文档全算一遍不可能。所以架构上必然是接力：
ANN 粗召回（双塔，快，Top 20-100） → Rerank 精排（交叉编码器，准，Top 3-5） → 进 Prompt
实际收益
Rerank 的价值在混合召回场景更明显。多路召回融合后的候选集里，既有向量语义相关但文不对题的，也有 BM25 字面匹配但语义无关的，Rerank 用统一的相关性判断把噪声压下去。我项目里接入 bge-reranker-v2 后，Top-3 命中率（正确答案片段进 Prompt 的比例）提升了约 10 个点，生成侧 Bad Case 肉眼可见减少。而且 Rerank 还有个副产品：可以设分数阈值，最高分都低于阈值时判定「知识库没有相关内容」，直接走兜底话术而不是硬答——这是幻觉控制的重要一环。
模型选型
- bge-reranker-v2 系列：中文效果第一梯队，开源可私有化，有 Gemma2 底座的大杯和轻量小杯两档。
- Cohere Rerank API：英文强，调用省事，按次计费。
- jina-reranker：多语言长文档场景。
选型和 Embedding 一样，拿自己业务的 query-文档对做评测，看 NDCG 或 Top-K 命中率，榜单只作初筛。
工程细节
- Rerank 多少条：输入 20-50 条是甜区。太少（10 条）可能正确片段压根没被粗召回捞到；太多延迟扛不住，且低排名段对结果无贡献。
- 延迟：交叉编码器逐对计算，50 对在小模型上约 50-200ms（GPU）。CPU 部署要砍到 20 对以内，或者上量化版。
- 位置：Rerank 在融合之后、拼 Prompt 之前。别在单路召回内就 Rerank，浪费算力。
- 缓存：高频 query 的 Rerank 结果可以缓存（query+候选集哈希做 key），热点场景省一半算力。
能不能用 LLM 直接当 Reranker
可以（RankGPT 这类 listwise 排序），效果是天花板，但成本和延迟都高一档。折中方案：线上用小交叉编码器，离线用 LLM 造训练数据蒸馏小模型，或者只在高价值场景（客服转人工前的最后拦截）用 LLM 复排。
可能的追问
Q：Rerank 和微调 Embedding 冲突吗？先做哪个？ 不冲突，作用环节不同。先上 Rerank——零训练成本，立刻见效；Embedding 微调是召回侧优化，见效慢但治本。两个都做，召回和精排各自守住一段。
Q：Rerank 分数能直接当相关性概率用吗？ 不能。交叉编码器输出的是相对排序分，不是校准过的概率，不同 query 之间分数不可比。用它做「是否兜底」的阈值判断时，阈值要按自己数据分布定，不能套别人的数。
Q：上下文窗口够大，直接把 50 个候选全塞给 LLM 行不行？ 成本和延迟翻倍不说，「大海捞针」研究表明模型对中段上下文利用最差，塞得越多平均质量越差。精选 3-5 条的效果通常好于全塞。