评估回归误报频发？先给每个用例算噪声下限

单次评估运行几乎无法告诉你任何事情：一个失败的黄金用例说明不了什么，一次通过的运行更是如此。当评分器是字符串匹配、裁判模型或对自由文本输出的模式校验时，同一个提示词可以在系统毫无变化的情况下通过六次、失败两次。

问题的解法不是引入更重的评估框架，而是从重复的基线运行中测出每个用例的噪声下限（noise floor），再加一条规则：数据支撑不了结论时，拒绝升级判定。

本文基于一篇关于评估稳定性的技术文章整理，文中代码为原作者的实现思路。

为什么一次运行无法区分噪声与回归

把每个评分用例想象成一枚硬币，你试图用几次抛掷来估计它的偏差。一个提示词在八次基线重复中通过五次、在八次候选重复中通过三次，在仪表盘上看起来很吓人，但在 n=8 的情况下，置信区间宽到根本不足以支撑这种警报。

算一下就很清楚：8 次中通过 6 次，单侧 95% Wilson 下界约为 0.46；8 次中通过 3 次，下界约为 0.16。候选低于基线下限，但它不是零，因此诚实的结论是“不确定，需要更多样本”，而不是“回归”。

这正是许多评估套件悄悄丧失可信度的地方。团队把阈值接到单次运行上，阈值因采样抖动而触发，一个月内所有人都学会了忽略这份报告。噪声下限让报告重新变成信号，因为它编码了在任何提示词改动之前，测试工具本身会产生多大的波动。

Wilson 下界是一种用于估计二项分布比例（如通过率）置信区间的方法，由统计学家 Edwin B. Wilson 于 1927 年提出。与常见的正态近似（Wald 区间）相比，Wilson 区间在样本量小、比例接近 0 或 1 时表现更稳定，不会产生超出 [0,1] 范围的荒谬边界。其核心思想是：观测到的通过率 p̂ = k/n 只是真实通过率的一个带噪声的估计，真实的通过率可能更低。单侧 95% Wilson 下界给出了一个保守的界限——我们有 95% 的置信度认为真实通过率不低于这个值。在评估回归检测中，如果候选的下界高于基线的下界（或基线点估计），我们才有统计依据说它没有变差；否则只能判定为“不确定”。这解释了为什么 8 次中通过 6 次与 8 次中通过 3 次虽然点估计差距很大，但两个区间可能重叠，无法得出回归结论。

核心机制：重复、下限与戳记守卫

作者用约八十行标准库 Python 构建了这个闸门，假设你已经在每个分数旁边保存了模型、采样参数和评分器版本的戳记（stamp）——因为脱离了戳记的分数无法与任何东西比较。

整个模块的核心是三层：重复运行、单侧 Wilson 下界、以及对过于不稳定、根本无法判定的用例实行隔离（quarantine）。其中两个基线采集是大多数人会跳过、但恰恰最值得做的部分：它们由同一个戳记针对未改动的提示词生成，因此两者之间的任何差距都是纯粹的测试工具方差——这正是你在归咎提示词之前需要知道的量。

退出码仅在某个用例零通过、或升级后仍然失败时才返回非零，这样嘈杂的套件就不会再阻塞那些本不该被阻塞的部署。

python eval_noise_floor.py collect --out runs/base_a.json --repeats 8 \
  --model your-model-id --grader-version g7
python eval_noise_floor.py collect --out runs/base_b.json --repeats 8 \
  --model your-model-id --grader-version g7
python eval_noise_floor.py collect --out runs/cand.json --repeats 8 \
  --model your-model-id --grader-version g7
python eval_noise_floor.py compare runs/base_a.json runs/base_b.json runs/cand.json

重复运行：设计便宜，执行昂贵

重复次数会让开销线性增长，算术很快就变得令人不安。四十个用例、k=8、两个基线加一个候选，就是 960 次生成；再把每个不确定用例升级到 k=16，总数在你还没调优任何东西之前就突破两千次调用。

这种成本结构正是团队持续交付单次评估的主要原因：诚实版本大约是欺骗版本十倍的流量。

作者提到，在原型阶段某些平台会提供免费模型访问额度（如千万级 token 的促销额度）以及可选的免费服务器来跑长时间重复任务。但这些数字和条款都是促销性的、有时效性，围绕它们做重复预算之前应先在项目官方页面确认。作者也做了利益披露：该文是为某个产品的推广而准备的。

无论用哪个端点填充 generate 可调用对象，都要把测试工具留在自己的适配器后面。只在某一家提供商的促销额度上运行的回归闸门不是闸门，而是依赖，条款一变它就会失效。

独立同分布（i.i.d.）假设是重复运行统计推断的基石。它要求每次重复运行之间互不干扰，且服从相同的概率分布。在实际评估中，这意味着：(1) 每次运行必须重新初始化环境，不能残留上一次的状态；(2) 采样参数（temperature、top-p、随机种子等）必须全程固定；(3) 评分器版本必须一致，避免中途升级导致分布漂移。一旦违反 i.i.d.（例如有状态智能体修改了数据库，或缓存了上一次的输出），通过率就不再是真实通过率的无偏估计，Wilson 下界也会失去意义。因此文章强调“重跑必须从重置夹具开始”，这不是工程洁癖，而是统计有效性的前提。此外，k=8 的选择是在成本与统计功效之间的折中：k 越大，置信区间越窄，但生成调用次数也线性增长。

四种判定分别该触发什么

判定	证据模式	动作
within_noise	候选通过率不低于基线下限	发布，并记录通过率，让下限随现实漂移
inconclusive	低于下限，但至少有一次通过	仅重跑该用例、k=16，然后再动提示词
regressed	所有重复零通过，或 k=16 后仍低于下限	阻塞变更，二分定位提示词或模型戳记
quarantine	两次相同基线运行差距超过 0.25	先修评分器；该用例无法作为闸门

隔离用例往往被误读为模型问题

一个裁判模型对同一补全两次翻转，或者一个依赖空白的正则，在被测量两次之前看起来都像是不稳定的提示词。把这些用例从闸门里拉出来，修好评分器，再带着它们自己的下限重新引入。

评分器噪声是指评分环节本身引入的随机性，而非模型输出的随机性。常见来源包括：裁判模型（LLM-as-judge）对同一输出给出不同分数、正则表达式依赖空白或标点导致匹配不稳定、字符串匹配对大小写或同义词敏感、以及人工标注的主观差异。当评分器噪声很大时，同一个模型输出可能被判为通过或失败，导致通过率方差膨胀。文章中的“两次相同基线运行差距超过 0.25”就是评分器噪声过大的信号——因为两次运行用的是完全相同的提示词和戳记，任何差距都只能归因于评分器本身。此时正确的做法不是调整提示词或模型，而是先修复评分器（如更换更稳定的裁判模型、改用确定性评分规则、增加评分重复取多数），否则该用例无法作为可靠的回归闸门。

局限与不适用场景

对结构化输出使用确定性评分器的场景很少需要 k=8，因为精确键匹配基本无噪声，一次健全性重复就够。

会在调用之间修改数据库、队列或沙箱的有状态智能体，直接破坏了独立性假设——重跑必须从重置夹具开始，否则下限毫无意义。

无法固定 temperature、top-p 和评分器版本的团队应该就此止步：没有稳定戳记的重复，只会产生一种更昂贵的猜测。

有数据留存义务的受监管环境，在把黄金用例送进任何免费额度之前也要先读条款，而这个测试工具在这方面给不了任何保护。最后，关注延迟或成本预算的团队需要单独的测试工具，因为通过率下限对你真正关心的尾部行为没有任何说明。

如果重复密集的版本听起来值得一试，而 token 账单是障碍，那么免费模型访问和免费服务器选项是一个合理的起点。保持适配器边界完整，自己核实条款，即使促销结束，闸门依然属于你。