RAG重排序怎么接？候选召回、Reranker评分与延迟评估指南

在RAG流程中，向量检索或关键词检索通常先从知识库找出一批候选片段，再由Reranker对问题与候选片段的相关性进行重新判断。重排序适合处理“候选大致找对了，但前几条不够准确”的情况。它并不是第二次全库检索，不能找回召回阶段没有进入候选集的文档。

先区分召回与重排序

召回阶段的任务是扩大覆盖范围，从知识库中取得可能相关的候选内容；重排序阶段的任务是对这些候选进行更细致的相关性判断，并按分数重新排列。两者关注点不同：召回通常更重视覆盖率和检索速度，Reranker则需要逐条或逐对处理问题与片段，通常会带来额外计算开销。

一个常见流程是：用户问题进入检索器，得到候选片段；系统将同一个问题分别与每个候选片段组成输入对；Reranker为每一对输入计算相关性分数；系统按照分数降序排列，再截取指定数量的片段交给生成模型。分数主要用于同一批候选中的排序，不应直接当作跨模型、跨版本或跨任务的绝对质量指标。

接入时需要明确的参数

召回数量与最终片段数量分开设置

召回数量决定Reranker有多少候选可以判断，最终片段数量决定生成模型实际接收多少上下文。这两个参数不应混为一谈。例如，在中文产品手册问答中，可以先召回20个片段，重排序后选取5个，再将这5个片段交给生成模型。对照实验时，还应保留不经过重排序、直接从原始召回结果中选取5个片段的基线。

候选数量过小，相关内容可能在进入重排序前就被过滤；候选数量过大，则会增加评分耗时，并可能受到输入长度或服务资源限制。最终片段数量还要结合生成模型的上下文窗口、片段长度、问题复杂度以及提示词内容确定。

检查输入格式与截断策略

Reranker一般需要接收“问题—候选片段”成对输入。接入前应确认接口要求的字段、批处理方式、最大输入长度和返回结果格式。还要检查模型是否适合目标语言，尤其是中文产品文档、混合中英文术语或代码片段等场景。

当问题和候选片段超过输入长度限制时，系统可能截断文本。应明确截断发生在片段开头、结尾，还是按特定规则处理，并观察标题、章节路径、表格字段等关键信息是否因此丢失。必要时可在入库或召回后对片段进行合理切分，但不能只通过盲目缩短文本来解决上下文问题。

如何验收重排序是否有效

不要仅凭少数案例判断效果。应准备一组固定查询集，覆盖常见问题、相近概念、需要跨段落理解的问题，以及知识库中确实不存在答案的问题。每次实验使用相同的查询、知识库快照和生成配置，至少比较“原始召回”和“召回后重排序”两条流程。

• 排序质量：如果有人工标注，可检查相关片段是否更靠前，并使用适合排序任务的指标进行比较；也可以按查询逐条记录前几位结果是否包含正确依据。
• 端到端回答质量：检查回答是否引用了正确片段、是否减少无关上下文、是否出现遗漏或无依据生成。排序质量提升不代表回答一定同步改善，因此需要单独验收。
• 额外延迟：记录召回、Reranker、上下文拼接和生成各阶段耗时，同时关注批处理、候选数量和输入长度变化对延迟的影响。
• 资源与异常：检查超长输入、空候选、模型服务超时、返回分数缺失和批量请求失败时的降级行为。

评估时应固定Reranker模型、召回器、候选数量和最终片段数量，再逐项调整参数。不要把不同模型返回的分数直接横向比较，也不要因为某个查询结果变好就宣称整体效果改善。

一个可执行的验收记录

1. 建立固定查询集，并为需要命中的问题准备相关片段或答案依据。
2. 记录原始召回结果、重排序后的结果，以及最终送入生成模型的片段。
3. 对比前几位相关性、回答依据完整性和错误引用情况。
4. 分别记录平均延迟与较慢请求的延迟，注明候选数量和输入长度。
5. 根据结果决定是否调整召回数量、最终片段数量、片段切分方式或是否启用重排序。

如果原始召回已经稳定且延迟预算紧张，重排序未必值得接入；如果候选中常有多个相近片段、原始排序不稳定，或生成模型经常先看到次要内容，则可以通过固定查询集验证Reranker是否带来足够收益。最终决策应以可复现的排序、回答和延迟结果为依据。