在 RAG 系统的检索环节，一个常见的问题是：向量检索返回的 Top-K 个片段虽然整体相关，但在排序上并不总是最优——最合适的段落有时会排在第三、第四位，而非第一位。这会导致后续生成时，模型优先“看到”的是次优上下文，从而影响回答质量。引入重排模型（Reranker），就是在粗筛之后再做一次精细排序，把真正最贴合问题的片段提到最前面，显著提升检索的命中精度。
1. 为什么向量检索的排序不够“精”
向量检索（基于 embedding 相似度）本质上是用单一向量表示整段文本的语义，这个过程不可避免地存在信息压缩。可能出现的问题包括：
- 主题相关但不匹配具体问题：一个关于“年假申请流程”的段落和一个关于“年假天数规定”的段落，向量空间里离得很近，但用户问“我有多少天年假”时，显然后者才应该排第一。
- 关键词重叠但意图偏离：问题中包含“报销”，知识库中有大量报销文档，但用户真正想问的是“报销额度”，却被一堆“报销流程”的片段挤到后面。
- 长文本尾部细节被稀释：关键信息藏在段落末尾，向量嵌入更偏向整体主题，忽略了细节匹配。
这些问题单纯靠 embedding 很难解决，因为 embedding 是单向的相似度计算，缺乏对“给定问题，哪段文本更能回答它”的精细判断。
2. 重排模型：让“相关性”判断更准确
重排模型是一种专门训练来判断“问题-文档”对相关性的模型，它不生成向量，而是直接接收一个问题和一段文本，输出一个相关性分数。其设计思路是：让模型同时阅读问题和候选文本，对二者之间的匹配程度做深度融合判断，而非分别编码后再算余弦距离。
常见的重排模型（如 Cohere Rerank、BGE-Reranker、Jina Reranker 等）通常基于 BERT 类架构等，通过交叉编码器（cross-encoder）对（query, document）对进行打分，能够捕捉到更细颗粒度的语义关系，包括：
- 关键实体是否对齐（问题中的“北京办公室”与文档中的“北京分部”）
- 信息是否直接回应问题（是“定义”还是“操作步骤”）
- 文本中包含的是答案本身，还是仅提到相关概念
3. 实际应用流程
在 RAG 检索管线中，重排模型通常作为一个精排阶段嵌入：
- 粗排阶段（向量检索）：使用 embedding 模型从海量知识库中快速召回一个较大的候选集，比如 Top-50 或 Top-100 个片段。
- 精排阶段（重排）：将问题与候选集中的每个片段组成 pair，逐对送入重排模型计算相关性分数，然后按新分数重新排序，截取 Top-5 或 Top-10。
- 送入生成：将重排后的最优片段作为上下文提供给 LLM。
这样做既保留了向量检索的速度（在千万级库中快速初筛），又借助重排模型的高精度优化了最终提供给模型的上下文质量。
4. 效果与成本权衡
引入重排模型通常能带来明显的命中率提升。在实际测试中，使用同尺寸的开源嵌入模型配合重排，问答的最终准确率通常可以提升 10% ~ 20%，在需要精准匹配法规条款、产品参数等场景中改善尤其显著。
但需要注意成本和延迟：
- 计算开销增加：对每个问题都要调用 N 次重排模型（N 为候选数量），这部分会引入额外耗时和费用。
- 优化建议：
- 根据业务容忍度调整粗排召回数量，例如从 50 降到 20，在精度和速度之间取平衡。
- 选择轻量级或者支持批量打分（一次请求传多个文档）的重排模型 API，减少调用次数。
- 在本地部署开源重排模型（如 BGE-Reranker-large），可以降低网络延迟和 API 调用成本。
5. 实用提示
- 何时考虑引入：当发现向量检索返回的 Top-3 片段经常不能直接回答问题，或者答案被排在靠后位置时，加入重排的收益最明显。
- 并非必须：如果知识库规模较小（几千个片段）、查询相对固定，且 embedding 模型已经足够精准，单阶段检索可能已经足够。
- 组合使用：重排模型不一定要替换掉原有的精排策略（如基于关键词的 BM25 融合），而是可以和它们形成互补，进一步提升鲁棒性。
重排模型的引入，本质上是将“语义匹配”任务交给更专业、更细粒度的模型来完成。它在 RAG 管线中扮演着“最后一公里”的质量把关角色，投入不多却往往能换来用户体验的明显改善。
小结
通过“粗排（向量检索）+ 精排（重排模型）”的两阶段检索架构，RAG 系统可以在保持检索速度的同时，显著提升最终送入 LLM 的上下文质量。这是目前实践中验证过的最具性价比的检索优化手段之一，也是很多生产级 RAG 系统的标配。