裁判模型被悄悄升级的评估框架

就在你发布提示词（prompt）更改的同一周，所有评估类别的得分都提升了 6 个百分点。团队成员将其视为改动奏效的证明。三周后，有人注意到这种提升也出现在了提示词更改绝不可能触及的类别中——这是一个你专门用来检测此类情况的对照组——而且这种提升是均匀分布的，而真正的产品改进绝不会呈现出这种形态。评审模型在某个周二以相同的终端节点（endpoint）名称发布了。在你的系统变动之前，你的分数就已经变了。

这种失效模式对“大模型作为评审员”（LLM-as-a-judge）评估流水线的破坏，比文献中警告过的任何失效模式都要更隐蔽。不是偏见，不是位置效应，也不是自我偏好——这些是评审员在特定时间点的属性，你的评估设计可能已经考虑到了这些因素。真正让你栽跟头的是评审员在你没注意的时候发生了变化，而你的终端节点名称、评估代码和仪表板都在声称一切如常。测量单位在一个稳定的标签下发生了偏移。跨越迁移边界的每一次比较现在都被混淆了，你无法将差值分解为“我们的系统改进了”和“尺子的标准变宽松了”，因为你从未构建过能进行这种分解的工具。

评审员是测量仪器，而非库调用

工程领域中的所有其他测量工具都被视为具有作为“合同”的校准，而非取决于“感觉”的属性。扭矩扳手有一份带有日期的校准证书。pH 计会定期根据缓冲溶液进行重新锚定。A/B 测试框架会对其方差估计器进行版本化，并在没有迁移说明的情况下拒绝比较在不同版本下运行的实验。你评估流水线中的评审模型默认情况下不做任何这些工作，而且它提供的 API 界面会主动鼓励你忘记校准的存在。

评审员产生一个数字。该数字被报告给利益相关者。利益相关者对待这个数字就像对待测试通过率一样——认为其含义随时间推移保持稳定。但事实并非如此。评审员是一种测量仪器，其校准是从供应商那里“租来”的，供应商可以单方面更改条款，而你与该供应商签订的合同几乎肯定不包括“当我们更改评审员的评分方式时，我们会告知你”。质量改进是供应商发布的一个功能。但你并不希望这个功能在季度中期发布到你衡量系统是否改进的唯一持久记录中。

值得采用的思维模型是：评审员不是你评估逻辑的一部分，而是你评估 基础设施 的一部分。在任何其他情境下，你都已经知道如何处理未经通知就发生变化的基础设施这类风险。你需要对其进行版本化，对其进行锁定（pin），并将对其进行的任何更改视为一次具有明确前后测量对比的迁移，而不是你应该静默继承的透明升级。

为什么终端节点名称不是版本号

默认的集成看起来就像一个字符串——一个模型名称，可能是一个像 latest 这样的别名，或者只是一个完全没有版本后缀的系列名称。阅读代码的工程师会将该字符串视为版本，就像 python==3.11.4 是一个版本一样。但它不是。这个字符串是一个稳定的句柄，它可能解析为一个稳定的产物，也可能不是。供应商会更换该句柄背后的底层权重，以发布质量改进、安全补丁、延迟优化和量化更改，而他们做这一切都不会更改你所锁定的字符串。你的“锁定”只是一个通过不断变化的重定向来解析的名称。

真正能实现锁定的方式是快照 ID（snapshot ID）——这是一个带有日期或哈希值的模型版本，供应商承诺保持其不可变。大多数供应商的 API 都会暴露这一点；但很少有客户端集成会使用它。供应商文档中的默认示例使用系列别名，因为文档作者希望你能够免费升级。这种权衡对于新鲜度至关重要的聊天产品是有意义的。但对于以可复现性为核心的测量仪器来说，这毫无意义。

修复方法是机械且低成本的：在评估流水线调用评审员的 API 层，拒绝接受除全限定快照 ID 以外的任何内容。将供应商客户端包装在一个轻量级适配器中，如果调用者传递了系列别名，则抛出异常。将快照 ID 作为提交到评估配置中的值，就像你提交数据集哈希值一样。现在，终端节点升级需要一个更改快照 ID 的显式拉取请求（pull request），迁移变成了有人负责的事情，而不是发生在你身上的意外。

校准锚点集

将评审员锁定在快照 ID 可以防止静默升级的情况。但当你 确实 需要升级时（你最终肯定会升级，因为旧快照会过时），它并不能让你跨迁移对比分数。为此，你需要一个校准锚点集（calibration anchor set）：这是一个小型的、不可变的参考示例集合，你已经手动对其预期分数进行了评分并提交，在更广泛的评估被视为有效之前，任何评审员运行的实际分数必须在容差范围内与这些分数匹配。

锚点集之于评审员，就像缓冲溶液之于 pH 计。它的存在是为了回答一个问题：这个仪器现在返回的数字是否与我们上次检查时返回的一致？你精心构建一次——每个评分维度几十个示例，涵盖你预期评分的全范围，每个示例都有团队审查并认可的人工评分标准答案。你对其进行版本化。你绝不让它泄露到团队构建的任何模型的训练集中。并且在每个评估周期之前，你都会针对它运行评审员。

几个关键属性：

• 不可变性（Immutable）：锚点分数不会根据新的评审员输出重新评分。重点在于锚点是固定的，而评审员相对于它移动。
• 覆盖评分范围（Covers the score range）：集中在平均值附近的锚点无法告诉你评审员在尾部是否变得更严苛，而这正是校准漂移最常见的形态。
• 包含近边界案例（Includes near-boundary cases）：评审员评分中哪怕 1 分的变动都会改变最终结论的例子，是漂移最早显现的地方。
• 私密持有（Held privately）：如果锚点集泄露到供应商的训练数据中，它就不再是锚点了。

加载中…