RAG 如何实现 Rerank？

核心回答

Rerank 通常放在粗召回之后：先由向量、BM25 等检索器找出一批候选，统一标识并去重，再用重排模型结合用户问题与每个候选内容重新打分，按分数选出适量证据，最后组装上下文交给生成模型。

常见实现是 Cross-Encoder：将 query 和候选文本一起输入模型，让两者在编码时直接交互，输出相关性分数。它比预先分别编码再算向量相似度更细致，但查询时要处理每一对候选，因此只对召回池做精排。重排可以提升候选顺序，不能找回没有召回的证据；权限、版本和业务条件也需要确定性处理。

实现链路怎样衔接

1. 根据真实身份与业务范围执行检索，取得候选文本、chunk_id、文档版本、原文位置和各路名次。
2. 合并重复候选，保留来源信息，按所用模型整理问题与候选文本。标题和章节能帮助理解时可以一并提供。
3. 批量计算 query 与候选的相关性分数，按返回的候选索引或标识恢复原文，避免排序后取错内容。
4. 选取重排结果，必要时补相邻条件或父段，合并重复上下文，并在 Token 预算内组织证据与引用。

粗召回候选数、重排保留数与最终上下文大小是三个不同的控制量。例如可以先比较较宽的候选池，再把精排后更少的内容送入模型；具体数量由证据覆盖、任务跨度与延迟评测决定。

为什么不是再算一次向量相似度

双塔检索通常预先计算文档向量，查询时计算问题向量，再快速查近邻。候选文本与问题在编码阶段没有逐对交互。

Cross-Encoder 在查询时联合处理两者，能够更具体地比较问题条件与原文表达。例如“某版本支持什么功能”与“另一版本已取消该功能”主题很像，联合打分有机会区分版本和否定条件。但这仍是模型判断，不能替代产品版本过滤，也不能保证每次排序正确。

专用重排模型并非都采用完全相同架构，LLM 也可以按点、成对或列表方式评分。选型时需要比较中文与领域表现、输入长度、批处理能力、延迟和成本；不用一个固定分数阈值套所有模型。分数可能是 logits 或经过变换的值，不天然等于答案可信概率。

工程上容易漏掉什么

输入截断。 如果重要条件在长块末尾，重排模型没读到，再精细也无法据此判断。应先检查模型输入限制，合理组织标题、正文和块边界，而不是只扩大候选数。

映射与去重。 保持模型输入顺序与返回索引一致，多路同一块只保留适当的一份；跨块合并时保存原始命中位置。不能把多个近似切片当成多份独立证据。

权限与版本。 它们属于内容可用范围，不应让相关性模型决定。扩展父段后也要检查可见范围，防止子块可读而父文档含受限内容。

失败回退。 记录重排超时和错误，按业务选择使用已过滤的融合结果、缩小候选或返回明确失败。回退后也保留引用和质量观察，不能把“接口返回了结果”当成精排已经成功。

如何验证有提升

固定同一份候选池，先比较有无重排的 MRR、nDCG 或前列证据精度，再做完整链路的答案正确性、引用、延迟和成本对照。候选漏证据时回到召回；候选有证据却被排掉时，再检查训练领域、输入截断和模型。

评估不应偷偷把未召回的正确文档补进候选，再声称线上效果提高。需要区分重排模型本身的能力测试与真实召回后的系统评测。关于是否值得保留重排，可继续看召回已足够多时能否去掉 Reranker？。

对应教程

参考资料