RAG 从 Demo 到生产，绕不开 Rerank

本文是「RAG 面试通关」系列的第 6 篇。 上一篇：第 5 篇《为什么你的 RAG 搜不出答案？面试官让我重写检索逻辑》 下一篇预告：第 7 篇《RAG 不是把检索结果扔给模型就完事了》

上周帮一个学员复盘面试。

面试官问他：

“你们 RAG 项目里为什么要加 Rerank？”

他说：

“因为 Rerank 可以让结果更准。”

面试官继续问：

“那为什么不直接用 Embedding 检索排好？Rerank 和向量检索有什么本质区别？Rerank 会带来什么成本？TopK 和 TopN 怎么设？”

他就答不下去了。

这个问题很典型。

很多人知道 RAG 里有 Rerank，也知道中文叫重排。

但如果只会说“重新排序，让更相关的排前面”，面试里是不够的。

真正做过生产级 RAG 的人都知道：

Rerank 不是锦上添花的小模块，而是 RAG 从 Demo 走向生产时经常绕不开的一环。

但它也不是万能药。

它能提高排序质量，也会带来延迟和算力成本。

今天这篇，我们就把 Rerank 面试题讲透。

2个关键：粗筛与精排

一、面试官问：Rerank 是什么？

新手回答

Rerank 就是把召回出来的文档重新排序，让更相关的内容排在前面。

高手回答

Rerank 是 RAG 检索链路里的精排阶段。

召回阶段会从大规模知识库中快速找出一批候选文档，比如 Top50 或 Top100。

这个阶段追求的是速度和召回率，宁可多捞一点，也不要漏掉正确内容。

Rerank 则是在候选文档上做更细粒度的相关性判断，把真正和用户问题最相关的内容排到前面，再选 TopN 交给大模型。

所以 Rerank 的本质不是“重新排一下顺序”这么简单。

它是用更强但更慢的相关性模型，在小规模候选集上做精细判断。

面试时可以总结成一句话：

召回是粗筛，Rerank 是精排。召回负责找得全，Rerank 负责排得准。

二、为什么召回之后还需要 Rerank？

因为召回阶段通常不够精细。

比如向量召回是通过 Embedding 相似度来找内容。

它很快，但它的判断比较粗。

用户问：

“RAG 里如何防止模型引用无权限文档？”

向量召回可能召回这些内容：

1. RAG 权限控制方案
2. RAG Prompt Injection 防护
3. 企业知识库权限设计
4. 大模型安全合规介绍
5. 文档级 ACL 实现方式

这些都“看起来相关”。

但用户真正想问的是 RAG 检索阶段的权限过滤。

这时需要一个更细的模型，判断每个候选文档和 Query 的匹配程度。

这就是 Rerank 的价值。

它可以解决几个问题。

第一，把真正相关的文档提前。

第二，降低弱相关文档进入上下文的概率。

第三，在有限上下文窗口里，把最有价值的 Chunk 留给 LLM。

第四，提升回答的准确性和引用质量。

但注意：

Rerank 只能重排已经召回的候选。

如果正确文档一开始就没被召回，Rerank 救不了。

三、Rerank 和 Embedding 检索有什么区别？

这是面试高频题。

核心区别是 Bi-Encoder 和 Cross-Encoder。

Embedding 检索：Bi-Encoder

Embedding 检索通常是双编码器模式。

Query 过一次模型，变成 Query 向量。

Document 也过一次模型，变成 Document 向量。

然后计算两个向量的相似度。

它的优点是快。

因为文档向量可以提前离线算好，存进向量数据库。

用户来问问题时，只需要算 Query 向量，然后做向量检索。

缺点是 Query 和 Document 在编码时没有充分交互。

模型只是最后比较两个向量距离，容易丢掉细粒度匹配信息。

Rerank：Cross-Encoder

Rerank 常用 Cross-Encoder。

它会把 Query 和候选文档拼在一起，一起输入模型。

模型可以在内部看到 Query 的每个词和文档的每个词之间的关系，最后输出一个相关性分数。

它的优点是判断更准。

缺点是慢。

因为每一个 Query 和 Document 组合都要跑一次模型。

如果召回 100 个候选，就要对 100 个 Query 和 Chunk 对进行打分。

所以 Rerank 不能替代召回。

它适合在召回之后，对小候选集做精排。

4个权衡：效果和成本一起看

四、BGE Reranker 这类模型有什么作用？

BGE Reranker、Cohere Rerank、Jina Reranker、Sentence-Transformers CrossEncoder 这类模型，本质上都是相关性打分模型。

输入是：

用户问题 + 候选文档。

输出是：

这个候选文档和用户问题的相关性分数。

在中文 RAG 场景里，BGE Reranker 使用比较多，因为它开源、中文效果较好，也方便私有化部署。

但不要绝对化地说某个模型一定最好。

模型选择仍然要看业务测试集、语言场景、延迟、部署方式和成本。

面试时可以这样说：

我会优先用业务测试集评估 Reranker 对 MRR、NDCG、Hit Rate 和最终回答质量的提升。如果提升明显，再结合延迟和成本决定是否上线。

五、Rerank 放在 RAG 的哪个阶段？

标准流程是：

用户 Query。

Query Rewrite 或 Query Expansion。

多路召回，得到候选 TopK。

Rerank 对 TopK 重新打分排序。

选择 TopN 进入上下文。

LLM 基于上下文生成回答。

Rerank 在召回之后，Prompt 组装之前。

它的作用是决定哪些 Chunk 更值得进入上下文。

不要把 Rerank 放到全库之前。

因为 Rerank 太慢，不适合对全量文档逐个打分。

也不要以为 LLM 最后会自己判断，所以 Rerank 可有可无。

如果上下文窗口有限，前面塞进去的内容质量越高，后面生成越稳。

六、TopK 和 TopN 怎么设置？

这是实战高频问题。

TopK 是召回阶段返回多少候选。

TopN 是 Rerank 后最终送给 LLM 的数量。

常见策略是：

召回 TopK 取 30 到 100。

Rerank 后 TopN 取 3 到 8。

为什么不能召回 TopK 只取 5？

因为召回是粗筛，TopK 太小容易漏掉正确 Chunk。

为什么不能 TopK 取 500？

因为 Rerank 每个候选都要打分，候选太多会增加延迟和算力成本。

TopN 也不是越多越好。

送给 LLM 的上下文太多，会引入噪声，也会增加 Token 成本。

所以面试时可以这样答：

我会先保证召回 TopK 足够覆盖正确文档，再通过 Rerank 压缩到适合上下文窗口的 TopN。具体值要通过测试集调参，看 Recall@K、MRR、最终回答质量和 P95 延迟。

七、Rerank 会带来什么性能问题？

Rerank 最大的问题是慢和贵。

Embedding 检索之所以快，是因为文档向量可以提前算好。

但 Cross-Encoder Rerank 不能提前算好。

因为它的输入是 Query 和文档的组合。

每来一个新 Query，都要重新和候选文档组成 pair 打分。

如果召回 TopK 是 100，就意味着要做 100 次相关性判断。

如果 QPS 高，成本会很快上来。

常见优化方式有这些。

第一，减少 TopK。

比如从 100 降到 50，但要确认召回率不明显下降。

第二，使用更小的 Reranker。

Base 模型可能比 Large 模型更适合高并发场景。

第三，批量推理。

不要一个候选调用一次模型，要把多个 Query Document pair 组成 batch。

第四，做缓存。

对于重复 Query 或重复文档组合，可以缓存 Rerank 分数。

第五，设置超时降级。

Rerank 超时后，可以直接使用召回排序结果，保证系统可用。

第六，只对高价值请求启用。

比如普通问答不启用，复杂问题或低置信度问题才启用。

八、Rerank 能解决什么，不能解决什么？

Rerank 能解决的问题

第一，候选文档排序不准。

正确文档被召回了，但排在后面。

第二，向量召回语义太泛。

召回了一堆相关但不够精准的内容。

第三，混合召回结果需要统一排序。

向量召回和 BM25 召回的结果合并后，需要一个更强的模型判断最终相关性。

第四，上下文窗口有限。

只能给 LLM 放少量 Chunk，所以要挑最相关的。

Rerank 不能解决的问题

第一，正确文档没被召回。

Rerank 只能排候选集里的东西。

候选里没有答案，它无能为力。

第二，知识库本身没有答案。

没有相关文档，再怎么排也没用。

第三，文档切分太差。

如果 Chunk 语义断裂，Rerank 也只能在坏材料里选相对好的。

第四，LLM 不遵循上下文。

如果正确 Chunk 已经进了上下文，但模型仍然胡编，这更像是 Prompt、拒答策略或模型能力问题。

所以不要把 Rerank 当万能药。

它是排序优化，不是全链路修复工具。

九、如何评估 Rerank 效果？

不要靠感觉。

要用指标。

常见评估方式有几类。

第一，看 MRR

MRR 关注正确文档排在第几。

如果正确文档从第 8 名被 Rerank 提到第 1 名，MRR 会明显提升。

Rerank 最擅长优化这个指标。

第二，看 NDCG

NDCG 关注整体排序质量。

如果多个文档相关程度不同，NDCG 能更好评估排序是否合理。

第三，看 Hit Rate 或 Recall@N

看最终送给 LLM 的 TopN 里，是否包含正确文档。

如果 Rerank 后 Top5 命中率提升，说明它对最终上下文有帮助。

第四，看最终回答质量

Rerank 是中间模块，最终还是要看回答是否更准确，引用是否更可靠，用户是否更满意。

第五，看延迟和成本

如果准确率提升 3%，但 P95 延迟从 2 秒涨到 7 秒，可能不值得。

评估 Rerank 一定要同时看效果和代价。

6步落地：别只背概念

十、项目里怎么落地 Rerank？

可以按这个流程讲。

第一步，先定位问题。

确认 bad case 是“正确文档被召回但排名靠后”，而不是“根本没召回”。

如果根本没召回，应该先优化召回策略。

第二步，准备测试集。

至少准备一批 Query 和对应的正确文档，评估加 Rerank 前后的排序变化。

第三步，选择模型。

中文私有化场景可以评估 BGE Reranker、Jina Reranker 等开源模型。

不想部署时可以先用商业 API 验证收益。

第四步，调 TopK 和 TopN。

先保证 TopK 覆盖正确文档，再压缩 TopN 控制上下文质量。

第五步，做性能优化。

包括批量推理、模型量化、缓存、超时降级和异步处理。

第六步，线上灰度。

观察回答准确率、用户反馈、P95 延迟、GPU 成本和错误率。

面试时如果能说出这个流程，比单纯背概念强很多。

十一、面试官追问清单

1. Rerank 和向量检索有什么本质区别？
2. 什么是 Cross-Encoder？
3. 为什么 Rerank 不能直接用于全库检索？
4. Rerank 放在 RAG 的哪个阶段？
5. 召回 TopK 和 Rerank TopN 怎么设置？
6. Rerank 会带来哪些性能成本？
7. 如何优化 Rerank 延迟？
8. Rerank 能解决召回失败吗？
9. 如何评估 Rerank 效果？
10. 什么场景不适合加 Rerank？
11. Rerank 分数能不能和向量相似度直接相加？
12. 如果加了 Rerank 效果反而变差，你怎么排查？

总结

最后总结一下。

Rerank 是 RAG 从 Demo 到生产经常绕不开的一环。

但它不是万能药，也不是无脑加就行。

面试时记住五句话。

第一，召回是粗筛，Rerank 是精排。

第二，Embedding 检索通常是 Bi-Encoder，快但粗；Rerank 常用 Cross-Encoder，准但慢。

第三，Rerank 只能重排已召回的候选，不能解决正确文档没被召回的问题。

第四，TopK 和 TopN 要结合召回率、上下文窗口、延迟和成本一起调。

第五，Rerank 是否值得上线，要看 MRR、NDCG、Hit Rate、最终回答质量和系统延迟。

下一篇我们讲 RAG 面经系列第 7 篇：Prompt 与上下文组装。

因为检索结果排得再好，也不代表大模型一定能答好。

怎么把材料交给模型，怎么让模型引用来源，怎么让它不知道就拒答，是下一关。