RAG 什么时候需要重排？

先给结论

重排是候选生成之后的可选排序阶段。它适合“支持证据已经进入候选集，但顺序不理想”的问题；它不能找回第一阶段完全漏掉的文档，也不能修复权限过滤、解析、切分、索引更新或错误标注。是否需要重排应由冻结评测集上的增益、延迟和成本决定，不是 RAG 的必选配置。

召回与重排的分工

第一阶段的目标是在预算内生成覆盖率足够的候选。它可以是关键词、稠密向量、稀疏向量、结构化查询或多路组合，不一定是双塔模型。第二阶段读取查询与候选的更多信息重新排序，例如 Cross-Encoder 对每个 query-document 对联合编码，因此通常比预计算文档向量更贵。

先检查候选 Recall@K：若正确证据不在候选中，增加重排不会改善结果；应先查语料、权限、查询、索引、过滤和候选深度。若正确证据经常在候选中却排在上下文窗口之外，才有明确的重排机会。

什么时候值得尝试

• 候选中有大量主题相近、版本相近或措辞相似的文档，第一阶段难以区分细粒度相关性。
• 最终上下文预算小，排序变化会直接决定哪些证据进入生成。
• 有足够且可信的相关性标注，可以比较重排前后，而不是只看几个展示样例。
• 增加的推理延迟、计算成本和运维复杂度符合业务预算。

这些条件不意味着某个行业“必须重排”。医疗、金融等高风险场景首先需要来源、权限、时效、人工复核和责任边界，重排模型不能替代这些控制。

如何验证