跳到主要内容

LLM 裁判是一个带版本的依赖,而非中立的基础设施

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数团队对待 LLM 评审员(LLM judge)的方式就像对待单元测试运行器一样:将其视为产生可信数字的中性基础设施。你编写评分标准(rubric),让模型针对你的输出进行评估,然后评审员返回分数。分数会显示在仪表盘上。仪表盘的趋势线驱动着产品路线图(roadmap)。没有人认为评审员是一个具有“行为”的东西,因为自动化的全部意义就在于将人为行为从环节中剔除。

但评审员本质上是一个模型。它有版本,有偏差。一旦它发生变化——无论是评估平台团队为了省钱更换了模型,还是提供商在 -latest 别名后悄悄滚动了权重——它产生的所有历史分数与新分数之间都会变得不可比。你的季度质量趋势现在是用两种不同的货币计价的,而且没有人给出汇率。

这并非假设的边缘情况。如果不像对待测量仪器那样对 LLM 进行版本化管理,这就是将其作为测量工具的必然结果。

你的评估历史是一个账本,评审员是其计账单位

当评审员升级时,新模型并不会以某种统一、易于修正的方式变得更严格或更宽松。它的评分方式是不同的。它可能对幻觉引用变得更严格,而对冗长程度变得更宽容。它可能失去了旧模型的某些位置偏见(position bias),却获得了对自家模型系列输出的自我偏好偏见(self-preference bias)。这种转变是多维度的,且不均匀地分布在你的评估切片(eval slices)中。

因此,失败模式并不是“所有分数都下降了 5%,减去一个常数即可”。而是你的质量版图形状发生了改变。原本看起来最薄弱的切片现在成了最强的,不是因为产品变了,而是因为尺子变了。团队查看仪表盘,发现一个功能退化了,而另一个功能改进了,于是针对退化展开调查,结果花了两个星期去追踪一个由于评审员严格度变化导致的伪“产品 Bug”。

更深层次的问题是认识论上的。评估分数只有在相对于同一仪器产生的其他分数时才有意义。孤立的“平均分 7.2”毫无意义;只有与上个月的“6.8”相比才有意义。当评审员改变的那一刻,这种对比就悄然断裂了,但数字依然以相同的字体、相同的坐标轴、相同的颜色显示在仪表盘上。可视化界面没有任何提示告诉你正在跨越一个不连续点。图表通过遗漏关键信息在撒谎,而且谎言极具说服力。

“中性基础设施”是让你受害的假设

为什么这种情况不断发生?因为组织层面的缝隙。评估平台团队拥有评审员。他们的考核指标是成本和吞吐量,因此升级评审员模型——使用更便宜的档位、更新的版本或更快的端点——对他们来说是合理甚至值得称赞的事情。在他们看来,这是一种对用户透明的基础设施优化,就像更换数据库连接池一样。

与此同时,产品团队将分数视为连续的时间序列。他们基于趋势线构建路线图论据。他们设置内部质量门禁,例如“评审员分数 ≥ 8”。他们从没见过评审员的版本,因为平台将其抽象化了——而这正是构建平台的初衷。

两个团队的行为都是理性的。问题出在他们之间的契约上。平台团队认为他们在提供服务;产品团队认为他们在读取测量值。服务可以透明地升级,但测量仪器不行。在任何重视测量的学科中,重新校准天平都是一个可见、已公告且有文档记录的事件。计量学中有一个词用来描述你所参照的单位:标准(standard),而标准是不能被悄悄更换的。

隐藏在浮动别名后的托管模型情况更糟。如果你的评审员固定在 -latest 端点,提供商可以在你完全不知情的情况下滚动权重,而你这边根本没有版本变动。你的评估历史在某个周二出现了一道缝隙,而你可能在三周后才通过 Slack 频道里混乱的讨论发现。社区一直要求提供商提供带日期的、可固定的快照(snapshots),正是因为没有它们,可重复的评估是不可能的。而且,即使是固定的快照也只能告诉你运行了什么,并不能保证永远安全,因为快照仍会根据弃用时间表而过期。

让评审员成为真正依赖项的准则

将评审员视为版本化依赖项并不罕见。这与你对待任何其他可能改变行为的依赖项所采取的卫生习惯是一样的。以下四个实践至关重要。

为每个评估套件固定一个评审员版本。 评审员模型、其确切的快照 ID、解码参数以及评分标准提示词(rubric prompt)都是仪器的组成部分。固定所有这些参数,并在记录该套件产生的每个分数时同时记录这些固定信息。没有记录评审员身份的分数是一个无标签的数据点——你无法判断它是用哪把尺子测量的,因此无法安全地将其与任何东西进行比较。如果你的评审员只存在于浮动别名之后,请将其视为已知的可靠性缺陷,而非无关紧要的问题。

保留一个冻结的锚点集(anchor set)。 维护一小组稳定的输出——大约 50 到几百个——永远不要更改它们,并涵盖从明显很差到明显优秀的完整质量范围。这是你的标准参考。它在评估中的地位相当于存放在金库里的标准砝码。

运行评审员迁移协议,而非简单更换。 当你更换评审员时,不要只是开始产生新数字。首先使用旧评审员和新评审员对整个冻结锚点集重新评分。两个分数向量为你提供了两个尺子之间的测量映射:也许新评审员在中间范围严格了 0.6 分,但在极端情况下表现一致;也许它重塑了整个质量区间。这个映射就是你的“汇率”。有了它,你可以将旧分数换算成新尺度,或者至少可以诚实地量化哪些对比已无法挽回,必须重新建立基准。没有它,你就是在瞎猜。

让缝隙清晰可见。 评审员的每一次变动都要记录在变更日志(changelog)中:日期、旧版本、新版本以及锚点集的变化差异(delta)。仪表盘在每一次评审员迁移处画出一条垂直线,就像股票图表标记拆分一样。这条线不是装饰。它是对读者的指令:不要用眼睛跨过这个点进行对比。 跨越未标记评审员变更的趋势线并不是真正的趋势;它不过是披着一件风衣的两个截然不同的趋势。

校准是持续性的,而非一次性的上线任务

锁定裁判模型 (judge) 是必要的,但还不够,因为即使是被锁定的裁判模型也不会完全静止不动。对 LLM 裁判模型的研究不断发现一个令人不安的结论:即使是顶尖的裁判模型,在微小的提示词扰动下——比如重新排列评分细则、重命名评分字段、或者交换候选答案的呈现顺序——也会表现出巨大的单样本分差。在成对比较中,仅仅交换呈现顺序就可能让准确率波动超过 10 个百分点。测量工具存在噪声,而且这种噪声不可小觑。

这意味着,一个锁定的裁判模型是一个 稳定 的工具,但并非一个 经过校准 的工具。你仍然需要了解它的评分如何映射到基准真相 (ground truth) —— 即人类的判断 —— 而且即便模型版本不变,这种映射关系也会发生漂移,因为你的输入分布在变。你的产品在六个月前生成的输出与今天的输出不同,而基于旧分布校准的裁判模型可能会在不知不觉中误判新的输出。

解决这一问题的做法是进行周期性的校准检查:按照固定的节奏,针对人类标记的校准集重新运行裁判模型,并测量一致性。如果一致性下降,裁判模型就需要重新对齐 (re-grounding) —— 使用更清晰的评分基准、为每个分数等级提供少样本示例 (few-shot examples),或者针对已被广泛证实且可预测的“冗长偏好” (verbosity) 和“自我偏好” (self-preference) 效应进行偏差修正。一个经过良好校准的裁判模型可以达到人与人之间的一致性水平,但这个水平是争取和维护来的,而不是在设置时就自带的。如果将校准视为上线前的清单项目而非一个持续的过程,裁判模型就会在沉默中腐化为一个随机数生成器。

周一要做的事

从审计开始。针对你最关注的评估仪表盘,回答一个问题:折线图上的每个点具体是由哪个版本的裁判模型生成的? 如果你无法回答每一个点,那么你拥有的就不是质量趋势图,而是一系列由可能不同的工具生成的、按从左到右排列的测量结果,基于此得出的任何结论都是站不住脚的。

然后先做低成本的修复。如果你的供应商提供带日期的快照,请将裁判模型锁定在该快照上。本周构建一个冻结的锚点集 (anchor set);它不需要很大也能发挥作用。从现在起,在你流水线写入的每个分数中添加裁判模型版本作为记录字段,这样未来的你就不必再陷入这种境地。

值得借鉴的认知重构是:LLM 裁判模型是一个具有版本、行为特征和发布节奏的依赖项,而不是一个中立的神谕。你技术栈中其他所有带版本的依赖项都已经有了变更日志、锁定策略和迁移协议。裁判模型比大多数依赖项更接近你决策的核心,因为它定义了你的产品所谓的“更好”究竟意味着什么。一个不记录由哪个裁判模型生成评分的评估历史,就像是一份用不断被重新定义的货币书写的账本——而基于这份账本构建的路线图,正被一个无人计算过的汇率所左右。

References:Let's stay in touch and Follow me for more thoughts and updates