如果你的 RAG 系统经常出现这种情况——检索日志里明明召回了正确文档，但它排在第 7、第 12 位，最后被截断在 Top-3 之外，模型拿着三条不相关的内容硬答——那你缺的不是更好的向量模型，而是一层 Rerank（重排序）。
Rerank 是目前 RAG 优化里性价比最高的组件之一：不动语料、不换向量库、不改切分，加一层模型调用，检索质量往往肉眼可见地提升。这篇文章讲清它的原理、适用边界和落地配置。
重排的任务只有一个：把「真正能回答问题的那条」放到最前面。
为什么向量检索自己排不准
向量检索用的是 Bi-Encoder 架构：查询和文档各自独立编码成向量，然后算余弦相似度。文档向量是提前算好存进向量数据库的——这是它能在亿级数据里毫秒响应的原因，也是它排不准的原因：编码文档时，模型根本不知道将来会有什么问题来查它。一段文字被压缩成一个几百到几千维的向量，细节必然丢失，相似度衡量的是「主题相近」，而不是「能否回答这个具体问题」。
Cross-Encoder（重排模型）则把查询和文档拼在一起送进模型，让注意力机制在两者的每个词之间直接交互，输出一个「这段内容对这个问题的相关度」分数。它能看到 Bi-Encoder 看不到的东西：问题问的是「怎么退款」，这段讲的是「怎么开发票」，主题都是售后但答非所问——向量相似度很高，Cross-Encoder 会打低分。
代价同样明显：每对「查询-文档」都要跑一次模型前向，没法预计算。拿它扫全库不现实，所以工程上形成了标准的两阶段检索：
查询
→ 粗排（召回）：向量 / BM25 / Hybrid，从全库快速捞 Top 20–100
→ 精排（Rerank）：Cross-Encoder 逐条打分，收窄到 Top 3–5
→ 生成：只把精排后的 3–5 条拼进提示词粗排追求「别漏掉」（召回率），精排追求「排对序」（精确率），分工明确。这也回答了一个常见疑问：Rerank 不是替代向量检索，而是接在它后面。
加 Rerank 能带来多少提升
各家重排模型的官方评测（Cohere、BGE、Jina 等）和社区复现的结论方向一致：在检索基线做得还行的前提下，加 Rerank 通常能把 Top-3/Top-5 的命中率提升 10%–30%，对 Hybrid Search 融合后的结果也仍有提升——RRF 只看排名不看内容，Rerank 是真的读了内容。我们自己在中文知识库上的体感：「召回了但排不进前三」的坏例子，加 Rerank 后大部分消失。
但有两种情况加了也白加：
- 粗排就没召回：正确文档压根不在 Top-50 里，重排巧妇难为无米之炊。先按《RAG 为什么答不准》排查召回问题。
- 切分质量太差：块内容本身残缺混乱，排序再准，模型拿到的还是烂材料。先看《RAG 文档切分怎么做》。
重排模型怎么选
| 方案 | 形态 | 特点 |
|---|---|---|
| BGE-Reranker（bge-reranker-v2 系列） | 开源自部署 | 中文表现好，社区使用最广，有不同尺寸可选 |
| Jina Reranker | API / 开源 | 多语言，支持长文档 |
| Cohere Rerank | API | 效果稳定，接入简单，按调用量计费 |
| Qwen-Reranker 等国产系列 | 开源 / API | 中文场景可重点评测 |
| 用 LLM 当重排器 | API | 让大模型对候选逐条打分，效果好但又慢又贵，适合离线评估 |
选型建议：有 GPU 或愿意用推理服务的选开源自部署（BGE 系起步），量小图省事的直接接 API。注意三个工程参数：
- 候选数量：粗排给 Rerank 喂 20–50 条比较划算，喂 100+ 延迟和成本明显上升，收益递减；
- 截断长度：多数重排模型对输入长度有限制，超长 chunk 会被截断——这也是 chunk 不宜过大的又一个理由；
- 延迟预算：自部署小模型批量打分通常在几十到一二百毫秒，API 方案看网络。相对于大模型生成动辄数秒，这点延迟一般可接受，但对时延敏感的搜索建议框（suggest）场景不适合。
自部署重排模型对硬件要求不高，一张消费级显卡就能支撑常见的知识库流量。
一份可以直接套用的配置
以「向量 + BM25 混合召回、BGE 重排」为例，这是中文知识库场景的稳妥起点：
粗排: Hybrid Search（RRF, k=60），召回 Top 30
精排: bge-reranker-v2-m3，对 30 条打分
过滤: 分数 < 0.3 的丢弃（阈值按自己评估集校准）
输出: 取 Top 5 拼上下文；若全部低于阈值 → 回答“知识库未找到”最后一行值得强调：Rerank 分数是天然的「拒答依据」。向量相似度因为量纲问题很难定阈值，而 Cross-Encoder 的相关度分数区分度好得多——所有候选都低分，说明库里确实没有答案，明确拒答比让模型硬编要好，这直接减少幻觉。
验证流程
- 从坏例子里筛出「已召回但排序靠后」的问题（看检索日志确认正确文档在 Top-30 内）；
- 接入重排，对这批问题跑 A/B：只对比 Top-5 内是否包含正确文档；
- 用评估集整体跑一遍，确认没有把原本排得好的问题排坏（会有少量，属正常）;
- 校准拒答阈值：拿 10 个「库里肯定没有答案」的问题看分数分布，把阈值定在能拦住它们的位置。
Rerank 的收益极易验证：找出「召回了但排不进前三」的坏例子，接入前后对比即可。
适用人群与替代方案
适合已有 RAG 系统、检索日志显示「召回没问题但排序不行」的团队。替代方案有三个层次：一是扩大 Top-K 加长上下文，把 Top-10 全塞给模型——简单粗暴，但上下文变长带来成本上升和「中间信息被忽略」的问题（见《长上下文模型真的更强吗》）；二是升级 embedding 模型，治本但要全量重建索引；三是查询改写，对「问题本身没问好」的坏例子比 Rerank 更对症。多数团队的最终形态是：好的切分 + Hybrid 召回 + Rerank 精排，三者叠加。
常见问题
Q：Rerank 和 RRF 融合是一回事吗？ A：不是。RRF 只按排名做数学融合，不读内容；Rerank 是模型真正阅读「查询+文档」后打分。可以先 RRF 融合两路召回，再交给 Rerank 精排，两者串联。
Q：每次查询都过一遍重排模型，成本能接受吗？ A：自部署小模型的单次成本可以忽略；API 方案按厂商定价计算，通常远低于生成环节的大模型费用。相比之下，不加重排导致的坏答案和人工排查成本要高得多。
Q：Agent 场景的工具检索也能用 Rerank 吗？ A：能。工具很多时（几十上百个），先向量粗召候选工具，再重排选出最相关的几个注入提示词，是 Agent 工具管理的常用做法。
小结
记住这个分工就够了：召回管「别漏」，重排管「排对」。当你的坏例子集中在「正确内容明明召回了却排不进前几」，加一层 Cross-Encoder 重排是所有优化手段里见效最快的一个，顺带还能拿到可靠的拒答阈值。先跑 20 个坏例子验证，再决定全量上线。