🤖 AI

Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines

本文介绍了一种随时有效的归因框架，该框架通过使用固定的真人标注锚点集和博弈 e-过程（betting e-process），能够可靠地在连续评估流水线中区分产品退化与 LLM 评判器漂移，从而解决了两者之间的歧义，并在准确性和成本效率方面优于标准的统计方法。

原作者： Yitao Li

发布于 2026-06-16

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Yitao Li

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这是一篇使用简单语言和创意类比对论文进行的解释。

核心问题：“断掉的尺子”

想象你经营着一家面包店。你想知道你的蛋糕是否随着时间的推移而变差了。为了检查这一点，你雇佣了一位非常昂贵、受过高度训练的“大师级品鉴师”（强力评判者）来品尝每一块蛋糕并给出评分。

然而，大师级品鉴师太贵了，无法品尝每一块蛋糕。所以，你雇佣了一位更便宜、更快的“助手品鉴师”（廉价评判者）来品尝每一块蛋糕。你只在随机抽取少量蛋糕时才请大师级品鉴师来品尝，以确保助手的表现达标。

难点在于： 大师级品鉴师不是人类，而是 API 背后的 AI 模型。有时，构建大师级品鉴师的公司会悄悄更新其软件（“版本升级”）或更改其指令。突然之间，大师级品鉴师变得更加严格或更加宽松。

现在，你面临着一场危机：

如果蛋糕评分下降了，是面包师做出了一个烂蛋糕？（系统漂移/System Drift）
还是大师级品鉴师改变了他们对什么是“好”蛋糕的看法？（评判者漂移/Judge Drift）

如果你因为大师级品鉴师改变了想法而责怪了面包师，你可能会解雇一位优秀的员工。如果你因为面包师真的搞砸了而责怪了大师级品鉴师，你可能会继续售卖劣质蛋糕。论文将此称为**“漂移的歧义性”**（Ambiguity of the Drift）。

解决方案：“锚点”集

作者提出了一个聪明的方案来解决这个谜团。他们引入了一个特殊的蛋糕组，称为**“锚点集”**（Anchor Set）。

冻结的锚点： 在你开始监控之前，你选取一组特定的蛋糕，让人类进行品尝，并将“真实得分”写在纸上。你将这些蛋糕锁进冷冻库。它们永远不会改变。
竞赛： 每隔一段时间，你会从冷冻库中取出一个这样的蛋糕，并询问当前的大师级品鉴师是否要品尝它。
- 如果大师级品鉴师对这个冻结蛋糕的评分发生了变化，我们就知道品鉴师变了。（蛋糕没变，是品鉴师变了）。
- 如果大师级品鉴师对这个冻结蛋糕的评分保持不变，但新蛋糕的评分下降了，我们就知道面包师变了。（品鉴师是一致的，是产品变差了）。

它是如何运作的：“守护窗口”

该系统同时运行两个独立的警报器：

警报 A（面包师）： 观察新的蛋糕。如果评分下降，它会尖叫：“面包师不行了！”
警报 B（品鉴师）： 观察冻结的锚点蛋糕。如果评分发生变化，它会尖叫：“品鉴师不行了！”

论文引入了一个**“守护窗口”**（Guard Window）规则来决定该责怪谁：

如果警报 B（品鉴师）先响起来，或者如果警报 A 响起来后警报 B 很快也响起来了，系统会说：“是评判者的问题。”（品鉴师变了，所以我们不能相信面包师的警报）。
如果警报 A 响起来了，而警报 B（品鉴师）从未响起来（或过了很久才响），系统会说：“是系统的问题。”（品鉴师很稳定，是产品本身坏了）。

“竞赛”概念

论文将此描述为一场**“竞赛”**。

“锚点过程”（观察冻结蛋糕）必须足够快，以便在“主过程”（观察新蛋糕）错误地指责面包师之前，捕捉到品鉴师发生变化的情况。
如果锚点过程太慢，主过程可能会在锚点意识到“等等，品鉴师刚才变了！”之前就尖叫“面包师不行了！”
论文通过数学证明，如果你设置好锚点（足够的冻结蛋糕，且品尝频率足够高），锚点总能在与变化中的品鉴师进行的竞赛中获胜。

他们的发现（结果）

作者使用真实的 AI 模型（Google 的 Gemini）和真实数据（得益于助手任务和摘要任务）测试了这一点。

静默更新： 他们模拟了一个“静默版本升级”，即 AI 品鉴师变得稍微宽松了一些。
- 结果： 他们的系统 100% 正确地识别出这是“评判者漂移”。它从未错误地指责面包师。
- 旧方法的失败： 行业标准方法（简单的统计检验）在实际并没有任何变化的情况下，有 75% 的时间都在尖叫“面包师不行了！”它简直是一个误报机器。
严格更新： 他们模拟了一个突然变得非常严格的品鉴师。
- 结果： 该系统几乎每次都能正确识别出这是“评判者漂移”。
- “竞赛”在行动： 在一个数据集上，品鉴师的变化非常剧烈，以至于锚点立即捕捉到了它，完美地赢得了竞赛。在另一个数据集中，变化较为微妙，因此锚点花费了更长的时间，但“守护窗口”规则依然挽救了局面。
成本：
- 用昂贵的大师级品鉴师检查每一项物品成本太高。
- 他们的这种方法对所有项目使用廉价的助手，对一些随机项目使用昂贵的大师，并对锚点进行持续的小规模监测。
- 成本： 它的成本大约是检查所有项目价格的 64%，但它更聪明，且不会产生错误的指控。此外，还有一个“虽然便宜但反应迟钝”的版本，成本仅为 21%，但可能会漏掉一些坏蛋糕。

总结

论文通过使用冻结的人类标注样本作为参考点，解决了“是谁发生了漂移？”的问题。

如果参考点移动了，说明评判者变了。
如果参考点保持不动，但新产品移动了，说明系统变了。

他们通过数学证明了这套方法是有效的，并展示了它如何击败了容易产生误报的现有行业标准。这就像拥有一个“真相锚点”，即使在评判者的想法发生变化时，也能保持质量控制的公正性。

技术摘要：谁发生了漂移？LLM 评估流水线中的随时有效归因

1. 问题描述

LLM 产品的持续评估日益依赖于“LLM-as-judge”（模型即评委）流水线，其中一个强大的模型对交互进行评分，以触发性能下降时的警报。这些系统的基本假设是，评委作为一个固定的标尺；因此，评分下降意味着产品的退化。然而，评委本身是一个基于 API 的模型，会受到静默版本更新、提示词（prompt）调整或策略变更的影响。

当监控系统触发警报时，它面临着一种歧义：是产品质量下降了，还是评委的评分行为发生了变化？错误的归因代价高昂：团队可能会回滚一个健康的产品，或者因为将警报视为“评委漂移”而忽略了一个真正的回归。经典的统计方法（如滚动 z-检验）在连续监控场景中会失效，因为它们缺乏随时有效性（anytime-validity）；在每一步都运行一个固定 $\alpha$ 的检验会导致虚假报警率上升，即使在无漂移流中也会产生伪检测。

2. 方法论

本文提出了一个利用**随时有效 e-过程（anytime-valid e-processes）和人类锚定归因规则（human-anchored attribution rule）**来解耦系统漂移与评委漂移的框架。

A. 预算化主监控器（系统漂移检测）
该系统采用了一种分层的、基于预测驱动的监控器（遵循 Csillag 等人，2025b；Angelopoulos 等人，2023）来检测质量回归：

架构： 一个廉价评委 ( $\mu$ ) 对每个项目进行评分，而一个昂贵的强评委 ( $y$ ) 在固定预算下对抽样子集进行评分。
机制： 对于每个（细则 $\times$ 分层）单元格，预测驱动的 e-过程累积“财富”，以测试关于均值未低于健康基准线的零假设。
成本效率： 系统使用 **e-财富升级（e-wealth escalation）**触发机制。随着漂移证据的积累，强评委的采样概率会增加。这使得系统能以约三分之一的全量评估成本检测到局部盲点回归，同时保持随时有效性（保证在任何停止时间下的虚假报警率保持在限定范围内）。

B. 锚点构建（评委漂移检测）
为了解决归因歧义，作者引入了第二个独立的、锚定于固定人类标签的 e-过程：

锚点集 ( $A$ )： 在监控开始前收集并冻结的一组带有固定人类标签 ( $h$ ) 的项目。
交织（Interleave）： 以稳定的速率（例如每 $1/\rho$ 个项目）重新对随机选择的一个锚点项目进行强评委评分。
E-过程： 贝廷 e-过程（betting e-process）追踪当前评委在锚点上的评分与冻结的人类标签之间的差距。
不对称性： 由于锚点项目和人类标签是固定的，只有评委的变化才会改变差距分布。系统漂移影响传入的项目，但不会改变锚点的差距。这创造了一个“单向镜”，专门用于检测评委漂移。

C. 归因规则（防护窗口）
系统结合主过程 ( $\tau_{sys}$ ) 和锚点过程 ( $\tau_{anc}$ ) 的停止时间，使用一个防护窗口（guard window） $W$ 来发布 $\{none, system, judge\}$ 判定：

评委判定（Judge Verdict）： 如果锚点过程先触发（ $\tau_{anc} < \infty$ ）且主过程在防护窗口内触发（ $\tau_{sys} \le \tau_{anc} + W$ ），则判定为评委（judge）。逻辑是：受污染的评委使主过程的警报失效。
系统判定（System Verdict）： 如果主过程先触发且锚点过程在防护窗口内未触发，则判定为系统（system）。
竞态条件（Race Condition）： 该设计依赖于“归因竞速”。为了防止误判，锚点过程必须被配置为比受污染的主过程触发虚假系统警报的速度更快地检测出评委漂移。

3. 核心贡献

锚点构建与归因规则： 一种利用人类锚定的、随时有效的 e-过程来显式分离评委漂移与系统漂移的新方法，它能输出三态判定而非二元警报。
理论保证：
- 随时有效性（Anytime-Validity）： 锚点族在任何数据依赖的停止时间下都保持受限的虚假报警率 ( $\alpha_{judge}$ )。
- 单向识别性（One-Way Identification）： 锚点过程在数学上保证对系统漂移不敏感；它只能由评委的变化触发。
- 归因竞速（Attribution Race）： 论文确立了一个设计定律，即锚点过程必须被配置为“跑赢”主过程。误判（在评委漂移期间发生虚假系统报警）是防护窗口宽度、锚点速率和锚点集大小的函数。
- 正交性（Orthogonality）： 锚点预算和主过程配置是独立的，允许分别调节评委延迟和系统效能。
真实漂移的实证验证： 该方法在两个领域（HelpSteer2 和 TL;DR 摘要）针对两种真实的评委变化（一次静默版本更新和一次严格提示词策略更新）进行了测试，无需重新调优。
操作优越性： 所提出的 e-过程在控制虚假报警和检测微妙漂移方面显著优于经典基准（朴素滚动 z-检验和经过校准的 Page–Hinkley 检测器）。

4. 结果

检测准确度：
- 静默版本更新： 在 60/60 次运行中被检测为评委漂移，且零次评委到系统的误判。
- 严格提示词变更： 在 HelpSteer2 上（当 $W=300$ 时）被正确归因为评改的次数为 110/120。在提示词偏移更剧烈的 TL;DR 领域，归因是完美的（240/240）。
- 误判： 在评委漂移期间，虚假系统报警的速率随防护窗口 ( $W$ ) 的增大而单调下降，证实了“归因竞速”理论。
基准对比：
- 朴素滚动 z-检验（行业默认）在 75% 的无漂移流中产生了虚假报警。
- 校准后的 Page–Hinkley 检测器虽然维持了其虚假报警预算，但未能检测到微妙的真实版本更新（在 HelpSteer2 上仅有 8% 的检测率），且需要持有的校准数据。
成本效率： 该监控器运行成本约为全量强评估的 0.64（在“较便宜但较迟钝”的模式下为 0.21），同时保持了有效的检测保证。

5. 意义与主张

本文解决了一个在 LLM 运维中关键且尚未解决的失效模式：无法在连续监控中区分产品退化与评委不稳定。

实际影响： 该构造提供了一个明确的保证，即评委漂移绝不会在定义的误差预算 ( $\alpha_{judge}$ ) 之外被错误地归咎于系统。这防止了团队做出昂贵且错误的运维决策（例如，回滚健康的模型）。
理论贡献： 它证明了**随时有效性（anytime-validity）**不仅是一个理论上的优选，更是连续监控中的实际必要条件，因为标准的固定时界方法在顺序检验下会发生灾难性失效。
设计定律： 论文确立了归因是一个竞速问题。它提供了一个具体的“协同配置”方案：锚点预算的大小必须确保锚点过程检测评委漂移的速度快于受污染的主过程触发虚假系统警报的速度。
局限性： 作者坦诚地指出，该方法假设人类标签保持有效（如果标准演进则需要定期刷新），并且并未声称在固定预算下实现了最优的投注策略或最小化误判，而是侧重于有效性和识别性。

总之，本文提出了一个稳健且具备成本意识的框架，将模糊的“漂移警报”转化为可验证的归因，确保“标尺”本身也受到与它所测量的“产品”同等严格的监控。