LLM-as-Judge 漂移：当你的评估器升级导致所有数据变动时

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。

这种谎言并非随机产生，它具有方向性。与待测模型同系列（相同供应商、相同代次、相同风格偏好）的评估模型，往往会报告一些看起来像进步的质量提升，但实际上这只是评估模型在迎合待测模型的表达习惯。而对于非同系列的评估模型，报告的退步可能看起来是灾难性的，但实际上只是评估模型采用了与上季度训练分数时不同的评分标准。这两种变动在复盘中都会被标注为“新提示词起作用了”或“新提示词把东西搞砸了”。但这两种说法都不足为信。

两口时钟，一个仪表盘

关于 LLM-as-judge 评估最简单的心理模型只有一口时钟：锁定待测模型的版本，将评估模型视为一把固定的尺子，每一次提示词迭代都会产生一个清晰的变化值。而真实的部署环境至少有两口时钟。每当有人修改提示词、重建 RAG 索引或轮换模型锁定版本时，待测时钟就会走动。每当供应商发布行为更新时，评估模型的时钟也会走动——这种情况越来越多地在没有版本升级的情况下发生，因为供应商将生产模型别名的质量改进视为非破坏性更新。

其结果是，1 月份的 4.2 分和 3 月份的 4.4 分描述的是两个经过不同训练的评估模型对两个经过不同迭代的待测模型的一致性评价。在任何具有纵向对比意义的层面上，4.4 分并不比 4.2 分更高。它是同一坐标轴标签下，由不同的仪器在不同的刻度上进行的另一次测量。你的仪表盘将两口时钟压平为一条直线，而这条线看起来就像是取得了进展。

关于 LLM 评估模型稳定性的研究对此有精确的记录。即使保持其他所有变量不变，温度值（Temperature）设置也会引入方差；即使在温度值为 0 时，供应商端的采样非确定性也会产生跨运行的评分分布漂移。再加上评估模型的行为更新，这种漂移就不再是高斯噪声，而是评分标准奖励偏好的系统性转变。2024 年关于 LLM-as-judge 方法的调研明确指出了后果：当你依赖私有评估模型时，可复现性（Reproducibility）不是你拥有的属性，而是供应商在下一次发布节奏中可以随时撤回的恩赐。

机制：为什么评估模型会定向漂移，而非产生随机噪声

如果评估模型的漂移是均值为零的噪声，你可以通过取平均值来消除它。但事实并非如此。有两种机制在左右漂移的方向。

第一种是自我偏好偏差（Self-preference Bias）：模型对看起来像自己生成的输出打分更高。GPT-4 给 GPT-4 风格的输出打的分，要高于质量相当的 Claude 或 Gemini 输出；Claude 亦然。2024 年的《自我偏好》（Self-Preference）论文将其归结为困惑度（Perplexity）——评估模型会给困惑度较低（看起来更熟悉）的文本打更高分，无论作者是谁。当评估模型升级时，它对“熟悉”的定义也会随之更新。上个月还在其分布之外的输出，现在可能已在其中。分数因此攀升，而这种攀升与待测模型的改进毫无关系。

第二种是系列偏好偏差（Family Bias）：评估模型对自己家族成员的评分高于质量相当的其他家族成员。如果你的待测模型是 GPT-4.1，而评估模型是 GPT-4o，评估模型不仅会奖励 GPT 风格的文本，还会奖励 OpenAI 谱系特有的风格标记。当你的待测模型升级到 GPT-4.5 而评估模型仍停留在 GPT-4o 时，家族轴线保持对齐，改进看起来会比实际更大。而当评估模型更换到不同的系列（例如出于成本考虑更换供应商）时，家族轴线发生偏移，待测模型看起来就像一夜之间发生了退步。

位置偏差（Positional Bias）和长度偏差（Length Bias）是三阶效应。在两两比较（Pairwise Comparisons）中，GPT-4 具有显著的首因偏好（Primacy-preferred）；而其他模型则具有近因偏好（Recency-preferred）。无论内容如何，较长的输出通常能获得更高分。每一次评估模型升级都可能重新权衡这些偏差。如果新的评估模型对长度的关注减少，你花了一个季度优化的精简版 RAG 系统就会突然失去因长度膨胀带来的领先优势，于是关于回滚的讨论便开始了。

每一个偏好偏差在孤立状态下都是经过深入研究且可以缓解的。问题在于，评估模型的升级会同时改变所有这些偏差，且比例未知，供应商也不会提供任何关于变动的更新日志。

幻影回归是简单的情况，幻影胜利则更糟糕

当评测器（Judge）升级导致你的仪表盘数据下跌时，至少会有人感到恐慌并展开调查。这种模式大家都很熟悉：回归测试集从绿变红，二分查找 Prompt 的变更，结果一无所获，最后终于有人注意到评测器的供应商悄悄发布了一个“改进版”。虽然痛苦，但仍可修复 —— 你只需要重新建立基准，标注不连续点，然后继续工作。

幻影胜利（Phantom wins）则是没人能察觉的故障模式。评测器升级发生了，分数趋势上行，团队发布了本周的 Prompt 变更，数据看起来印证了改进，于是 Prompt 被推向生产环境。两个月后，用户针对某种行为的投诉激增，而这种行为评测器早已停止惩罚，但用户依然深恶痛绝。仪表盘和用户从一开始就没达成一致；团队只有在评测器的新偏好与用户偏好产生足够大的漂移并变得显而易见时，才注意到这种分歧。

这就是为什么评测器更新后“质量上升”应该引发与“质量下降”同等的怀疑。两者都是评测器变动的证据，而非候选对象的表现。一个纪律严明的团队会将不相关的“评测器更新 + 分数变动”视为重新校准的触发条件，而不是对已发布变更的确认。

固定基准评测器

第一条且最不容谈判的纪律是在评测元数据中 固定基准评测器版本（pinning a baseline judge version）。每一次评测运行都必须记录评测器的模型 ID、温度（temperature）、系统 Prompt 哈希以及评分标准（rubric）版本，并与候选对象的标识符并列。跨时间的分数对比必须在评测器身份一致的前提下进行。如果两次运行之间评测器列发生了变化，分数的差异是未定义的，而不是零。仪表盘应通过拒绝在评测器版本不连续的点之间连线来强制执行这一点。

固定版本听起来很简单。但在实践中，它需要团队克服两点阻力。首先，必须固定到特定的快照模型 ID（例如 gpt-4o-2024-08-06 而不是 gpt-4o），因为供应商的别名是不稳定的。其次，要接受固定的评测器最终会被弃用，并提前为迁移预留预算。没有定期重新固定节奏的“固定基准评测器策略”是一个定时炸弹：当收到弃用通知邮件的那天，你仓库里所有的历史分数都会失去锚点。

重新固定的流程有其特定的形式。在同一个数据集（生产环境追踪数据、评测集以及留出的元评测集）上并行运行旧的固定评测器和新的候选评测器。测量每个类别的一致性（agreement）。对于一致性较高的类别，将基准重置（rebase）到新评测器并标注不连续点。对于一致性较低的类别，将它们冻结为已知的漂移区，在评分标准重新校准之前，不要跨版本边界对比分数。

评测器对评测器的校准节奏

固定基准能告诉你旧评测器说了什么，但它不能告诉你旧评测器是否正确。为此，你需要定期的 评测器对评测器校准（judge-vs-judge calibration） —— 在主评测器评分的相同追踪数据采样切片上，运行一个独立的评测器（理想情况下是不同的模型家族，且绝对要是不同的供应商）。

一致性指标在这里至关重要，且选择并非只是学术性的。Cohen's Kappa 和 Krippendorff's Alpha 是标准指标，但在生产环境评测中常见的偏斜分数分布下表现不佳（大多数追踪数据落在最高档，极少数失败落在最低档）。Gwet's AC2 对这种偏斜更具鲁棒性。排名相关性（Spearman, Kendall）则完全避开了评分标准边界问题，并回答了你通常最关心的问题：两个评测器对追踪数据的排序是否一致？

频率也很重要。仅在接入时运行一次校准，之后再也不管，无法告诉你任何关于漂移的信息。每次评测都运行校准又太昂贵且充满噪音。一个合理的折中方案是：每周对固定的分层样本进行校准，并设置基于阈值的告警。一致性保持在预设底线之上 —— 继续发布。一致性跌破底线 —— 冻结由评测驱动的决策，直到分歧排查完成。

分歧排查（Disagreement triage）是这项工作中枯燥但核心的部分。每一次分歧都是主评测器和校准评测器发生背离的追踪数据。阅读它们。通常会出现以下三种情况之一：评分标准存在歧义（修复评分标准）、一个评测器存在另一个评测器没有的偏见（记录它），或者追踪数据确实处于合理评测器也会产生分歧的边界上（将该类别标记为高方差，并在发布决策时要求人工审查）。每种结果都会更新你的评测栈。没有任何一种结果是“我们的评测器不好，升级它” —— 这种反应会重新引入你正试图捕捉的漂移。

评测元数据中的评测器版本管理

操作上的故障模式通常不是“决定不管理评测器版本”，而是“遗忘”。团队标准化了一个固定的评测器，发布了评测流水线，六个月后，固定的模型 ID 被硬编码在三个地方，被某人 Fork 的 Jupyter Notebook 引用，并在没人记得修改过的 CI 脚本中轮换。

能经受住人员更迭的纪律是 将评测器元数据作为每个评测工件中的一等公民列（first-class column）。评测运行程序如果缺乏全限定的评测器记录，则拒绝写入分数行：记录应包括带有快照日期的模型 ID、温度、解码参数、评分标准版本哈希，以及评测时处于激活状态的少样本（few-shot）示例。仪表盘按评测器身份进行过滤，默认视图仅显示最新的固定评测器。跨评测器的对比需要显式的确认，并带有清晰的视觉不连续标注。

这与十年前将机器学习社区从无声的训练流水线漂移中拯救出来的规范是一样的。模型权重被版本化了；训练数据被版本化了；超参数被记录了。评测器就是你流水线中的一个模型。它需要同样的待遇，即使它位于 API 之后，即使供应商假装模型字符串本身就是一个稳定的标识符。

停止在没有脚注的情况下盲目相信仪表盘

核心教训并非 LLM-as-judge 不可靠——在它设计的初衷上，它是可靠的，即在特定时间点根据固定准则对相似候选方案进行排序。关键在于 LLM-as-judge 并非一种时不变的测量工具，将其视为这种工具会将供应商的常规更新转化为幻影般的提升或退化，而这些变化既非团队成员所为，也无法复现。

解决方案不在于引入更多的裁判、更智能的准则，或者更花哨的评估框架。解决方案其实很枯燥：通过快照 ID（snapshot ID）锁定裁判，将裁判配置与候选方案同步进行版本管理，定期进行裁判间的校准，对分歧进行复核分析而非简单地取平均值，并且拒绝在裁判逻辑发生断层时绘制纵向趋势线。当仪表盘上的数字变动时，第一个问题不应该是“哪个 prompt 改了？”——而应该是“尺子变了吗？”在你能够仅凭元数据回答这个问题之前，仪表盘向你展示的是一个故事，而非测量结果。

认真对待这一点的团队，最终会拥有变动更少、意义更明确的质量仪表盘。而不这样做的团队，则会在供应商每次发布新版本时重新验证提示词，追逐由他们自己的测量工具制造出来的幻影，并渐渐对自己花了一年时间建立的评估体系失去信心。偏移从未发生在候选方案中。它发生在测量候选方案的工具上，而当时没有人关注那个计时器。