RAG 重排模型怎样放在召回链路中

RAG 的重排模型通常放在初召回之后、最终上下文装配之前：检索器先给出候选片段，重排器再结合用户问题对候选评分，应用最后选择能放进上下文的证据。重排不是第二个生成回答的模型，也不能从候选之外找回漏掉的资料。

例如用户问“电子产品退回仓库后在哪里看处理进度”，检索结果却把“退货申请入口”排在前面。先检查真正的“仓库处理进度”资料是否已经在候选中：在候选里但位置靠后，值得尝试重排；完全不在候选里，应先改召回或资料组织。这个场景是教学假设，不是线上事故记录。

示例模型官方发布页：https://huggingface.co/BAAI/bge-reranker-v2-m3

Sentence Transformers 官方地址：https://sbert.net/

先看用户缺的是哪一段证据

把“回答不好”拆成可观察的问题。对一条问题保留初召回的 chunk_id 列表，再看应有证据是否出现。随后观察重排后的同一列表以及最终实际送入生成模型的片段。这样才能区分“没召回”“被排到后面”“装配时被挤掉”三种情况。

不要仅根据生成答案是否“流畅”决定保留哪一层。建议记录片段身份而不是把敏感全文直接塞进普通日志；需要查正文时使用受控的诊断入口。这是实现建议，不是重排模型自动提供的能力。

给初召回和重排划清职责

可将实现理解为两个组件边界：“候选提供”包含用户问题、初召回器、候选片段；“相关性判定”包含重排器、相关性分数、排序列表。初召回器负责在大语料中高效找出一批可能相关内容；Cross-Encoder 类重排器将问题与候选文本配对判分，而不是生成可独立入库的文档向量。此类职责划分见 Sentence Transformers 的检索与重排说明。

初召回可以来自词法检索、向量检索或两者的候选合并。若合并多路结果，先统一 chunk_id 和去重，再交给重排；不要直接混加来源不同、含义不同的原始检索分数。权限范围也应在候选进入模型前落实，重排分数不代表访问许可。

把分数映射回原始片段

下面用已经得到的候选列表展示集成接缝。代码只做模型评分和索引映射，不实现向量库、不调用生成模型，也没有在本文环境执行。需要事先准备兼容的 sentence-transformers 及其运行依赖；首次加载可能下载权重，服务中应在初始化时加载并复用模型，而不是每个请求加载一次。

import math
from sentence_transformers import CrossEncoder

# 示例采用 CPU 和明确的输入截断长度；实际应按部署资源与模型说明调整
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3", device="cpu", max_length=512)

def rerank_candidates(query, candidates, keep=2):
    # candidates 必须已完成权限过滤，并保留唯一的 chunk_id、text、source
    if not query.strip():
        raise ValueError("查询不能为空")
    if keep 

例中的 keep=2、batch_size=8、max_length=512 都只是演示配置，不是通用最佳值，也不表示本文测得的吞吐量。输入过长会截断，模型看到的文本可能少于原片段；不要在被截断的部分恰好包含关键限定条件时，把高分当成完整文档的保证。

模型卡说明该模型以问题和文本为输入，输出相关性分数；分数可通过 sigmoid 映射，但映射到 0–1 并不意味着已经校准成“答案正确概率”。不在这里设所有问题通用的 0.5 门槛。见 官方模型卡；predict 的输入输出与截断参数见 CrossEncoder API 文档。

让引用与空结果对用户可见

最终上下文不是“若干段字符串”这么简单。建议为每段保留片段文本、chunk_id、来源标题和可定位位置，生成回答后引用能对应回这些资料。若使用外部重排接口，返回索引也要映射回原请求的候选数组，不能按返回名次去取原列表同位置元素；部分接口明确返回 index，见 Cohere Rerank API。

上下文装配器依赖片段文本、片段标识和来源信息；上下文预算约束其可放入的内容，输出的引用列表要保留来源对应关系。这些应用对象应有明确字段，而不是靠模型自己猜链接。

从用户体验看，加载期间显示“正在检索资料”即可，不显示虚构完成百分比；证据不足时明确告知无法据此作答，并允许调整问题。引用用可辨识的标题，不只依赖颜色或一个难理解的分数。引用清单和空结果提示是应用要实现的功能，不是加一个 reranker 就自动出现。

分别约束候选数量和上下文预算

需要分别管理候选数量、重排保留数和上下文 token 预算。候选多能给重排更多选择，也会增加配对评分负担；只把 top_n 设得小，不应据此假定模型只计算这么多条。重排器输入长度与生成模型上下文长度也不是一个上限。

组装最终提示词时，使用生成模型对应的 tokenizer 估算完整模板、问题、历史对话与证据所占 token，并为输出保留预算。若不足，按明确的片段策略缩减或选取，不能只用“每个汉字等于一个 token”的固定规则。不把大量重复片段占满窗口，也别裁掉使规则成立的条件。

建议在固定问题样本上同时比较：初召回覆盖、重排后的证据位置、最终上下文是否包含答案依据，以及整体延迟分布。记录模型版本和候选规模；只换 reranker，其他条件尽量保持一致。这里描述评估方案，不提供未经测量的准确率或耗时数据。

为超时和错误排序保留退路

初召回为空时直接进入无证据状态；重排异常或超过服务时限时，根据产品约定返回可重试提示，或降级为已经过滤且标明未重排的检索结果。降级不应跳过权限检查，也不应把部分评分与未评分候选混在一个“完整重排结果”里。超时控制应放在实际推理服务调用与任务管理层，前面这个本地同步函数没有实现请求取消。

能把重排直接放到全部知识库前面吗？

大语料通常不适合逐条配对评分；本文采用先缩小候选再重排的结构。很小的候选集合可以直接评分，但不能把这推成全库方案。

重排第一名就一定能回答吗？

不能。它只是候选间的相关性排序；资料可能都不够相关、已经过时或缺少关键条件。

换一个模型还沿用旧分数门槛吗？

不应直接沿用。先用相同任务样本重新观察分数含义与证据保留情况，再决定应用阈值与拒答策略。