Reranker 是你 RAG 评估中从未衡量的“静默”第二个模型

一个典型的 RAG 流水线包含两个模型，而不是一个。检索器从向量数据库中提取 50 到 100 个候选文档，而重排序器（reranker）——无论是交叉编码器（cross-encoder）、LLM-as-judge 提示词还是混合方案——都会对这些候选文档进行重新评分，并将前 5 个结果交给回答模型。你的评估套件测量端到端的回答质量，测量检索器的 recall@k，但它并不测量重排序器。因此，当重排序器发生隐性偏移（drift）时，仪表盘上显示的“回答质量下降了 4 个点”却没有任何因果线索，团队会花费三天时间去调试一个根本不是问题的提示词。

重排序器是那个隐性的第二个模型。它介于检索器和生成器之间，拥有自己的评分分布、自己的提示词（如果是基于 LLM）或自己的权重（如果是交叉编码器），并且它可以独立于其他任何组件发生性能退化（regress）。大多数团队从未单独对它进行评分。他们编写的评估套件将流水线视为一个具有长上下文窗口的单一模型，而实际上它是两个串联的模型，且其中间接口并不属于任何一个团队。

这是值得在设计时防范的失效模式。RAG 质量下降并不总是检索器或生成器的问题；有时它们是伪装成生成器退化的重排序器退化，因为仪表盘上展示的唯一指标是生成器的输出。解决办法不是增加端到端评估，而是为重排序器建立一个单独的评估套件，拥有独立的指标、独立的负责人以及独立的 CI 门禁（CI gates）。

为什么重排序器会被忽视

检索器的失效模式是可见的，因为检索评估已经是一个成熟的领域。Recall@k、precision@k 以及“金标分块（gold chunk）是否进入了候选集”这些问题，都是过去两年构建的每个 RAG 仪表盘上的一级指标。生成器的失效模式也是可见的，因为回答质量评估——LLM-as-judge、人工评分、忠实度得分（faithfulness scores）——是产品团队关心的指标，也是高层管理仪表盘追踪的指标。

重排序器坐落在它们中间。它的输出是一个排序，而不是一个答案，也不是一个召回率数字。如果金标分块在检索器的前 50 名中，且生成器的最终答案是正确的，那么重排序器就完成了它的工作——即使它给金标分块打的分数在版本发布之间从 0.92 降到了 0.61。仪表盘永远看不到这个分数。团队只有在重排序器偏移到金标分块跌出生成器实际读取的前 5 名时，才会看到症状。

这种症状看起来就像生成器的退化。团队会在第一天调整回答生成的提示词。第二天重新微调温度（temperature）。第三天梳理检索器，看看召回率是否下降。这些都不是问题所在。问题在于重排序器的评分分布发生了偏移，金标分块的相对排名从第 2 位掉到了第 7 位，而生成器现在读取的前 5 名与上周的前 5 名已经大不相同。

三种偏移来源

重排序器偏移有三个截然不同的原因，评估套件需要检测其中的每一个。

交叉编码器的模型升级。 使用托管重排序器（如 Cohere Rerank、Voyage、Jina、ZeroEntropy）的团队会受到供应商训练计划的影响。交叉编码器的一个小版本更新就会改变评分分布；曾经给一个边缘分块打 0.65 分的模型，现在可能打 0.48 分，这听起来像是噪声，但在典型的候选集中，这可能就是前 3 名和前 8 名之间的差距。供应商的发布说明可能会说“在 BEIR 上提升了 5%”。但你的流量并不是 BEIR。

LLM 重排序器的提示词修改。 使用 LLM 作为重排序器（采用逐点评分 pointwise scoring、列表排序 listwise reranking 或“对这段文字的相关性进行 1 到 10 评分”模式）的团队拥有重排序提示词的所有权。该提示词与回答生成提示词存放在同一个代码库中，并由同一批工程师评审。这些工程师会为了同样的原因（清晰度、格式、长度）去修改它，却没意识到这种修改会改变长尾分布下的评分。尤其是逐点（Pointwise）LLM 重排序器，在不同的提示词和候选集之间往往会表现出明显的评分偏移——同一段文字，在两个提示词变体下评分，可能分别得到 0.7 和 0.4。仪表盘永远不会显示提示词发生了变化；它们只显示回答质量下降了。

上游检索器的变更。 检索器的变更——新的嵌入模型、分块策略修改、向量索引参数调整——都会改变重排序器所看到的候选分布。根据检索器的偏移方向，重排序器的工作会变得更难或更容易。针对返回密集且语义相似候选文档的检索器所调优的重排序器，在检索器升级为返回更多样化候选文档时，可能会表现不佳（反之亦然）。重排序器本身没有变，但它所处的世界变了。

在这三种情况下，追踪端到端回答质量的仪表盘都不是正确的工具。它距离上游太远，无法定位退化原因，而且 LLM-as-judge 评估的噪声底噪（noise floor）足够大，以至于重排序器的微小偏移在汇总得分中会被抹平。

重排序器评估（Reranker Eval）的现状

reranker 需要一套属于自己的评估集，既不同于检索器的，也不同于生成器的。评估集是一系列查询（queries）的集合，每个查询都配有一个候选列表和一个黄金序数排名（golden ordinal ranking） —— 这不是二元的“相关或不相关”，而是“对于这个查询，这 20 个候选文档的正确顺序是 X、Y、Z……”。黄金排名的制作成本很高；它需要人工评判员对段落进行排序，而不仅仅是打标签。但这是唯一能让你根据 reranker 实际优化的维度对其进行评分的产物。

标准指标同样适用：nDCG@10 衡量前 10 名的整体排名质量，MRR 衡量第一个相关文档的位置表现。社区已达成共识，将 nDCG@10 作为生产环境中 reranker 评估的金标准，因为它捕捉到了 MRR 单独漏掉的长尾排名质量。一个总是把正确答案排在第一名，但将第二到第十名随机排序的 reranker 将拥有完美的 MRR 和平庸的 nDCG —— 并且一旦生成器的提示词要求“根据前三个段落的内容”时，它在生产环境中就会失效。

评估集应该进行细分（sliced）。单一的全局 nDCG 数字无法告诉你哪些查询类型正在退化。按领域（技术文档 vs. 政策文档 vs. 用户生成内容）、按查询长度、按歧义度、按黄金答案是在单个块中还是跨越多个块进行细分。reranker 的回归通常局限于一两个细分领域；全局得分可能只变动了零点几分，而某个特定的细分领域却已经崩塌了。

每当 PR 触及 reranker 提示词、reranker 模型版本、交叉编码器（cross-encoder）权重文件，或任何影响 reranker 所见候选列表的预处理时，都应在 CI 中运行此评估。它不应该只在答案生成提示词更改时才运行；reranker 有自己的变更频率，将其与答案生成节奏挂钩会忽略答案提示词发布之间发生的漂移。

分数分布仪表盘

独立于评估套件，生产环境中的 reranker 需要一个分数分布仪表盘。对于每一个请求，记录 reranker 对其排序候选者的评分，并在滑动窗口内汇总分布情况。你希望看到的是一个稳定的分布：日复一日保持大致相同的形状、相同的均值、相同的方差以及相同的尾部行为。

你实际上需要针对形状变化发出警报。如果 reranker 历史上产生的是双峰分数分布（清晰的胜者和清晰的败者），而该分布突然压缩成 0.5 附近的单峰，那么 reranker 就已经失去了区分能力。端到端的回答质量在今天可能仍然可以接受，因为黄金块（gold chunk）仍以微弱的优势勉强挤进前 5 名 —— 但下一次检索器的更改或下一次提示词的编辑，就会把它挤出去。仪表盘在回归变得对用户可见之前就捕获了它。

一个好的基准：记录最终在回答中被引用的块的 reranker 分数。跟踪该分数随时间推移的分布。当被引用块的 reranker 分数开始趋向于被拒绝块的分数时，reranker 就不再能区分信号和噪声，在回答质量仪表盘察觉到问题之前，你会有数周的预警时间。

责任划分是问题的核心

这件事很少被做好的原因是组织架构上的，而非技术上的。检索器由搜索或机器学习平台团队负责。生成器由产品或 AI 团队负责。而 reranker 则由上个季度负责上线它的团队负责，这通常是负责生成器的同一个团队 —— 而那个团队的奖励是基于端到端的回答质量，而不是 reranker 的质量。

结果是：reranker 的提示词修改与生成器的提示词修改在同一个 PR 中被审查，由同一批审查人员，针对同一个评估进行。reranker 提示词是 prompts.yaml 中的一个标题，而答案生成提示词是另一个。它们看起来一样。它们被审查的方式也一样。它们以不同的速率退化，而评估套件只能看到其中一个。

必须建立的规矩是为 reranker 设立独立的责任边界，即使同一个工程师同时负责两边。reranker 的提示词应该存在于不同的文件中（或者至少是不同的 CODEOWNERS 路径），需要一位精通检索指标而非回答质量指标的审查者，并由其独立的评估程序把关 —— 独立于答案模型的任何更改。当 reranker 是托管的供应商模型时，团队需要一个明确的供应商版本锁定政策：我们目前在哪一个版本，我们什么时候根据自己的评估集评估下一个版本，谁决定升级。

这是与嵌入（embedding）团队已经学到的相同模式。没有人会在不重新索引和重新评估的情况下在生产环境中升级他们的嵌入模型；错误模型的代价已经通过足够多的质量回归深深刻在了这个领域。reranker 还没有迎来它的“嵌入升级时刻”，但它终究会到来，而预先建立评估规矩的团队将是那些在没有发生事故复盘的情况下幸存下来的团队。

双模型流水线需要双模型评估

这里的核心架构认知非常简单。RAG 流水线并非只是一个带有检索上下文的模型；它是两个串联的模型，其中的接口——候选列表及其评分——本身就是一个关键的产物。仅评估终端模型的团队在调试系统时，距离真相还差了一个模型。仅评估检索器的团队是在给热身赛打分，而不是在评估决胜环节。

这一改进并不局限于重排序器（reranker）。只要系统存在“隐藏的第二个模型”——无论是检索器前的查询重写 LLM、选择查询哪个 RAG 语料库的路由，还是剔除低置信度答案的事后过滤器——该模型都需要独立的评估。这种模式具有普遍性：具有独立学习行为的组件需要各自的指标、仪表板和准入网关。端到端评估是必要的，但并不充分；它只能诊断出性能回退的存在，却掩盖了问题发生的具体位置。

在你需要之前就建立好重排序器的评估体系。那个能让你从“答案质量下降了，不知道为什么”转变为“交叉编码器（cross-encoder）从 v3.1 到 v3.2 版本之间，在技术文档切片上的 nDCG@10 指标下降了 6 个点”的 PR，正是将三天的迷茫化解为三十分钟修复的关键 PR。这其中的差距——三天与三十分钟——正是你将流水线中的第二个模型视若无睹所付出的代价。