一个常见的 RAG 问题是：正确答案所在的段落其实被检索到了，却排在第八名，而送进大模型的只有前三名。重排序模型（Reranker）的作用，就是在初步检索得到的候选集上，用更精细但更慢的方式重新打分排序，把真正相关的内容推到最前面。 在很多项目中，加入重排序是提升回答准确率最立竿见影的一步。

为什么需要两阶段检索

向量检索通常使用“双塔”结构：查询和文档各自独立编码成向量，再计算相似度。文档向量可以预先算好存储，检索时只需要计算一次查询向量，速度非常快，适合从海量文档中快速筛选。

但代价是：查询和文档在编码时互相“看不见”对方，模型无法细致比较二者的对应关系。比如“这款产品支持退款吗”和“本产品不支持七天无理由退款”，向量可能很接近，但细节含义完全相反。

重排序模型通常采用“交叉编码”结构：把查询和文档拼在一起输入模型，让模型逐词比较二者的关系，直接输出相关性分数。精度更高，但每个候选都要单独计算一次，无法预先缓存，所以只适合对少量候选做精排。

于是形成了经典的两阶段架构：先用向量检索或混合检索快速召回几十个候选，再用重排序模型精选出最相关的几个。

重排序能解决哪些问题

  • 细节和否定：区分“支持”与“不支持”、“适用”与“不适用”；
  • 问题与答案的对应：判断一个段落是否真正回答了问题，而不只是主题相关；
  • 多个相似文档的区分：如不同版本的产品说明、不同年份的政策文件；
  • 过滤噪声：给明显不相关的候选打低分，配合阈值过滤，减少无关内容进入上下文。

选型要点

语言支持

中文或中英混合场景，要选择在中文数据上训练充分的重排序模型。可以用自己的真实查询做小规模对比测试。

输入长度

重排序模型同样有长度限制，候选文本过长会被截断。这与文档切分策略密切相关。

延迟与成本

重排序的计算量与候选数量成正比。候选太多会显著增加延迟，太少又可能漏掉正确答案。通常从几十个候选开始测试，找到效果与延迟的平衡点。

部署方式

可以调用云服务商的重排序 API，也可以自部署开源模型。自部署时，较小的重排序模型在普通 GPU 甚至 CPU 上也能运行，但要关注并发时的延迟。

用大模型做重排序

另一种方式是直接让大语言模型判断候选文档与问题的相关性，或对多个候选进行排序。它的理解能力更强，可以处理复杂推理型的相关性判断，但成本和延迟都明显更高，一般用于候选很少、对精度要求极高的场景。

实践建议

  1. 先评估再上线：构建一批带标注的问题，比较加入重排序前后，正确段落出现在前几名的比例；
  2. 设置相关性阈值：分数过低的候选宁可不要，让大模型在“没有可靠资料”时如实说明；
  3. 监控延迟：重排序是检索链路中的额外环节，要纳入整体延迟预算；
  4. 结合元数据过滤：先按时间、部门、权限等条件过滤，再重排序，避免把不该看的内容排上来。

小结

向量检索负责“广撒网”，重排序负责“精挑选”。两阶段检索架构在效果和效率之间取得了很好的平衡。如果你的 RAG 系统经常出现“资料明明有，却答不对”的情况，加入重排序通常是最值得优先尝试的改进。检索质量的整体评估方法，可参考 RAG 评测正在变难。