[LLM Agents F25] Predictable Noise in LLM Benchmarks
| 字段 | 内容 |
|---|---|
| 作者/整理 | 基于 Sida Wang 授课内容整理 |
| 来源 | Berkeley RDI |
| 日期 | 2026-08-18 |
![[LLM Agents F25] Predictable Noise in LLM Benchmarks](cover.jpg)
官方幻灯片证据链：小样本评测为何仍需要统计学
Sida Wang 的论证不是简单地说“小 benchmark 不可信”，而是把两个都合理的直觉放在一起检验：一方面，HumanEval、SWE-bench 等生成式或 Agent 评测远小于 MNIST/ImageNet；另一方面，一个真正困难且有长答案的问题似乎比一道选择题携带更多信息。整讲沿着逐题概率矩阵、配对比较和可预测噪声逐步回答：难题可以揭示新能力，但要稳定比较两个模型，仍然必须估计采样误差、推理随机性和题目分布。
讲授路线与研究背景：先定义要测量的信号
slides 1--3 给出题目、路线和讲者背景。这里的“millions of questions”不是单个 benchmark 有百万题，而是把许多模型、数据集、题目和重复采样组合成大规模逐题观测。讲者长期参与代码生成 benchmark 与 Eval-Arena，因此本讲关注的不是抽象统计练习，而是榜单上的几个百分点究竟能否支持研究决策。
\lecturefigure{slides-images/slide-001.png}{官方 slide 1：Predictable Noise and Patterns from Millions of Questions} \lecturefigure{slides-images/slide-002.png}{官方 slide 2：从小型 benchmark 到噪声区间与改进建议的讲授路线} \lecturefigure{slides-images/slide-003.png}{官方 slide 3：讲者在代码模型、Agent RL 与 benchmark 上的研究背景}
读图：先区分 capability signal 与 ranking signal
某模型首次解决一个此前无人解决的问题，是强烈的 capability signal；但“模型 A 比模型 B 高 1.5 分”属于 ranking signal，需要重复样本和误差区间。前者可由一个高价值案例触发，后者必须回答差异是否能在新题目、新 seed 或新运行中复现。本讲主要解决第二类测量问题，同时保留第一类发现价值。
术语消化：本讲的四类统计对象
| 术语 | 回答的问题 | 在本讲中的作用 |
|---|---|---|
| Effect size | 两模型差多少 | 区分“有差异”与“差异足够有价值” |
| Standard error | 测得的差异会波动多少 | 决定当前测试集能否稳定分辨模型 |
| Confidence interval | 抽样程序给出的合理范围 | 防止把单点分数当成确定真值 |
| Signal-to-noise | 增益相对测量误差有多大 | 判断 benchmark 是否能测出目标级别的进步 |
样本量危机：难题是否能抵消测试集变小
前一节区分了能力发现与精确排序，本节把差异落实到样本量与单题信息量。阅读接下来的规模对照时，需要同时追踪测试题数量、答案形态和研究声明：它们共同决定证据强度，任何单一维度都不足以宣布 benchmark 可靠或失效。
slides 4--8 先用历史对照建立压力。ImageNet 上 10% 的提升足以改变领域判断，因为 10 万测试样本使统计显著性几乎不是争议；现代代码和 Agent benchmark 常只有数百题，每题却生成长代码、调用工具或执行多步轨迹。由此出现 A/B 两种假设：小数据集天然不可靠，或单个极难问题已经足够有信息量。
\lecturefigure{slides-images/slide-004.png}{官方 slide 4：ImageNet 式大提升与当前 LLM 小幅增益的可信度差异} \lecturefigure{slides-images/slide-005.png}{官方 slide 5：MNIST、ImageNet 与生成式/Agent benchmark 的测试集规模} \lecturefigure{slides-images/slide-006.png}{官方 slide 6：长代码答案是否让单题更有信息量} \lecturefigure{slides-images/slide-007.png}{官方 slide 7：解决一个开放问题为何具有样本量为一的重大意义} \lecturefigure{slides-images/slide-008.png}{官方 slide 8：小样本不可靠与少量极难题足够有效的两种竞争假设}
统计问题的准确问法
测试集小并不自动意味着无用，答案长也不自动等于信息量大。需要问的是：观测结果对潜在能力变量有多敏感、重复运行的一致性多高、模型间差异相对标准误有多大。只有把“题目难度”和“响应可靠性”分开，才能判断一题究竟贡献了多少可比较信息。
课堂提示：讲者拿 IMO、IOI 和开放问题作类比，不是要取消统计检验，而是提醒“发现能力”和“精确排序”具有不同证据门槛。研究报告应明确自己声称的是哪一种。
逐题概率热图：强模型也会错简单题
slides 9--12 把每列设为模型、每行设为按难度排序的问题，颜色表示同一模型在同一题上多次采样的 pass@1。热图并没有形成从左上到右下的清晰能力边界：弱模型偶尔解出难题，强模型也会在简单题失败。若单题代表稳定能力，这些反转不应如此常见；现实更像每个模型--题目组合都有一个连续成功概率。
\lecturefigure{slides-images/slide-009.png}{官方 slide 9：逐题、逐模型 pass probability 热图的阅读方法} \lecturefigure{slides-images/slide-010.png}{官方 slide 10：不同代码 benchmark 的逐题概率矩阵之一} \lecturefigure{slides-images/slide-011.png}{官方 slide 11：不同代码 benchmark 的逐题概率矩阵之二} \lecturefigure{slides-images/slide-012.png}{官方 slide 12：HumanEval 中强弱模型跨难度反转的具体位置}
读图：颜色不是确定的 0/1 标签
先横向比较同一题上的模型，再纵向比较同一模型跨题表现。大量中间颜色说明“会不会做”不是固定标签，而是一次采样的 Bernoulli 结果，其参数是潜在成功概率 \(p_{m,i}\)。难度排序只能解释平均趋势，不能保证每次运行都单调；因此单次 pass/fail 会丢掉概率信息。
热图不证明所有题都一样
不一致性可能来自模型随机性、题目歧义、测试缺陷、记忆污染或真实的能力组合差异。热图证明的是简单的一维“模型能力减题目难度”不足以解释全部数据，而不是证明题目内容无关。后续统计模型必须保留这种证据边界。
长答案并不自动提高统计功效
slides 13--16 继续反驳“难题天然高信息量”。如果模型能写出看似深奥的证明，却无法定义基本概念，长答案可能来自复制、偶然搜索或不一致推理。slide 14 的关键观察是红色单元格并非 sharp zero：弱模型不是永远不会，只是成功概率更低。对可验证任务，首次从 0 提升到可重复的 1% 也许揭示新能力，但从 1% 到 99% 仍需大量样本才能估计。
\lecturefigure{slides-images/slide-013.png}{官方 slide 13：用 hard question 补偿低统计功效的条件与反例} \lecturefigure{slides-images/slide-014.png}{官方 slide 14：弱模型在难题上的非零概率与第一批成功样本} \lecturefigure{slides-images/slide-015.png}{官方 slide 15：课堂重新选择 A/B 假设并否定无条件的小而难路线} \lecturefigure{slides-images/slide-016.png}{官方 slide 16：把 kettle 误认成扫地机器人后的信任崩塌}
课堂提示：Kettle 例子为何重要
在约 00:15:15，讲者描述维修助手先把烧水壶认成机器人吸尘器。即便后续建议碰巧正确，用户也无法确认中间推理是否可靠。多步 Agent 任务的总成功率近似由各关键步骤成功概率相乘；步骤越多，局部不一致越容易压低整条轨迹的可信度。长答案因此可能携带更多错误机会，而非更多独立信息。
Super-Population：把 benchmark score 放回抽样模型
slides 17--20 转入统计基础。设题目 \(x_i\) 从潜在任务总体 \(\mathcal D\) 抽取，模型 \(A\) 在题目上的得分为 \(A(x_i)\)。样本均值估计总体期望，样本方差估计题目间差异，均值标准误随 \(1/\sqrt N\) 缩小。slide 19 再问观测差异是否可能仅由机会造成，slide 20 用数值例子显示小数据集的噪声区间足以吞掉常见的几个百分点增益。
\lecturefigure{slides-images/slide-017.png}{官方 slide 17：长答案争论之后仍需进入统计分析} \lecturefigure{slides-images/slide-018.png}{官方 slide 18：从 super-population 抽样估计均值、方差与标准误} \lecturefigure{slides-images/slide-019.png}{官方 slide 19：模型差异是否可能由 chance 产生} \lecturefigure{slides-images/slide-020.png}{官方 slide 20：小测试集上的噪声区间数值量级}
其中 \(N\) 是测试题数，\(\widehat\mu_A\) 是样本平均分，\(\widehat{\mathrm{Var}}(A)\) 衡量不同题目上的离散程度，\(\widehat{\mathrm{SE}}\) 表示若重新抽取测试集，均值估计会波动多少。标准误不是模型“真实能力的方差”，而是当前测量程序的不确定度。
置信区间不是“真值落在里面的概率”
频率学派置信区间描述重复抽样程序的覆盖率。对一次固定实验，更稳妥的表达是“按该程序构造的区间具有 95% 长期覆盖率”，而不是把参数本身说成以 95% 概率位于区间内。讲义后文用区间作发布门禁时，也应保留这一解释。
Paired Comparison：同题比较为何更有力
slides 21--24 区分 paired 与 unpaired。配对比较让模型 A、B 回答同一批题，再对逐题差值 \(D_i=A(x_i)-B(x_i)\) 求均值；如果两模型在题目难度上的波动高度相关，公共难度项会在差分中抵消。非配对比较让两模型面对不同题目，题目组成差异会额外进入方差。slides 22--23 还加入推理随机变量，说明题目抽样与同题重复生成是两层不同噪声。
\lecturefigure{slides-images/slide-021.png}{官方 slide 21：Paired 与 unpaired 比较的直觉和方差公式} \lecturefigure{slides-images/slide-022.png}{官方 slide 22：利用模型可独立重复采样估计推理噪声} \lecturefigure{slides-images/slide-023.png}{官方 slide 23：题目方差与推理方差到 standard error 的分解} \lecturefigure{slides-images/slide-024.png}{官方 slide 24：配对模型差值的标准误计算}
这里 \(D_i\) 是同一题上的模型差值。由
可见，当 A、B 都在相同难题上下降时，协方差为正，配对差值方差会明显小于两个独立均值方差之和。这就是相同测试集不仅“公平”，还提高统计功效的原因。
老师强调：seed variance 不是全部噪声
模型可以对同一题独立采样，这让我们能估计条件于题目的推理方差；但重新抽一批题目还会产生任务总体方差。约 00:24:55，讲者提醒后者可能更重要。只跑多个 seed 而固定一小批题，无法回答结果对新任务是否稳定。
从 Bernoulli 怪现象到 Bootstrap、Sign Test 与 Eval-Arena
slides 25--28 用“每次以 0.8 概率正确”的模型说明单次 0/1 观测为何会出现反直觉排序，再用数组运算、bootstrap 和 sign test 得到近似一致的误差判断。Bootstrap 从经验分布有放回重采样，模拟重新从 super-population 取题；sign test 只看两模型结果不同的题，并检验胜负不对称是否可能由机会造成。Eval-Arena 将这些 pairwise tests 系统化到大量模型对。
\lecturefigure{slides-images/slide-025.png}{官方 slide 25：真实正确率 0.8 仍会产生反直觉单次结果} \lecturefigure{slides-images/slide-026.png}{官方 slide 26：用简单数组公式计算 Bernoulli 方差} \lecturefigure{slides-images/slide-027.png}{官方 slide 27：Bootstrap 与 sign test 给出相近判断} \lecturefigure{slides-images/slide-028.png}{官方 slide 28：Eval-Arena 对模型对执行配对比较和统计检验}
Bootstrap 的最小实现语义
每次从 \(N\) 个题目索引中有放回抽取 \(N\) 个索引，重新计算模型差值；重复许多次后，差值分布近似描述测试集重采样的不确定性。必须按题目为单位一起重采样 A、B 的结果，才能保持配对结构；分别重采样会人为破坏协方差并扩大方差。
实践经验：约 00:28:21，讲者认可 bootstrap，但建议先理解简单数组公式。工具不是替代理解：若重采样单位、配对关系或随机层级设错，运行再多次也只会得到精确的错误答案。
Predictable Noise：数据集大小、准确率与相关性
slides 29--32 给出本讲标题中的“可预测”。多个 benchmark 上，单模型标准误 \(\mathrm{SE}(A)\) 与模型差值标准误 \(\mathrm{SE}(A-B)\) 大致同量级，对应模型表现相关性约为 0.5；噪声还随总体 accuracy 呈弧形变化，因为二元得分方差 \(p(1-p)\) 在 \(p=0.5\) 最大、接近 0 或 1 时变小。SWE-bench Verified 上的筛选增益必须放入该准确率区间的噪声带解读。
\lecturefigure{slides-images/slide-029.png}{官方 slide 29：不同 benchmark 的可预测噪声与约 0.5 相关性} \lecturefigure{slides-images/slide-030.png}{官方 slide 30：噪声随 overall accuracy 变化的经验曲线之一} \lecturefigure{slides-images/slide-031.png}{官方 slide 31：更多数据集上的 accuracy-dependent noise} \lecturefigure{slides-images/slide-032.png}{官方 slide 32：SWEFixer 与 P2P filter 的 SWE-bench Verified 配对结果}
读图：为什么准确率中段最吵
对二元结果，单次方差为 \(p(1-p)\)。当模型几乎总错或总对时，重复结果较稳定；当 \(p\approx0.5\) 时最不稳定。不过模型比较看的是 \(A-B\)，还受两者逐题相关性影响。图中的经验曲线因此是 Bernoulli 基线、题目异质性和模型相关性的合成，不应只套一个理论抛物线。
Beta 概率形态与“重新加权题目”的失败
slides 33--36 从逐题成功概率的经验分布继续建模。强模型的题目概率常向 0 和 1 两端集中，可近似呈双峰 Beta 形态；但该观察主要来自 binary predictions，不能直接外推到连续 judge score。讲者原本希望通过难度建模、过滤或重加权降低噪声，却发现 Item Response Model 等方法没有稳定优于朴素基线，主因是模型自身响应不一致，而非少数“坏题”独占噪声。
\lecturefigure{slides-images/slide-033.png}{官方 slide 33：逐题经验成功概率及 Beta 分布近似} \lecturefigure{slides-images/slide-034.png}{官方 slide 34：不同模型和 benchmark 的 Beta 累积分布} \lecturefigure{slides-images/slide-035.png}{官方 slide 35：二元预测下更多 Beta 经验曲线} \lecturefigure{slides-images/slide-036.png}{官方 slide 36：过滤、重加权与题目难度建模未能显著提升 signal}
Beta 拟合的证据边界
Beta 是 \([0,1]\) 概率的灵活分布，可描述两端集中，但拟合良好不等于生成机制就是 Beta，也不证明所有题目可由单一难度参数解释。对长文本 rubric、部分得分和工具轨迹，应先定义观测模型，再决定是否仍适用 Bernoulli/Beta 框架。
课堂失败结论
“清洗得更精致”不一定增加可比较信息。HumanEval+、MBPP+ 或主观更高质量的数据集未必有更高 signal-to-noise；当主要噪声来自模型随机性和能力不一致时，仅过滤题目会缩小 \(N\)，反而提高标准误。优先策略是增加 benchmark 数量、扩大样本，或让每个昂贵 Agent 样本产出超过 1 bit 的结构化信息。
测量建议、Signal-to-Noise 与 Agent Eval 治理
slides 37--42 收束为可执行建议。multiple seeds 和训练曲线方差有用，但通常低估完整不确定性；更可靠的顺序是读取已有噪声表、按 accuracy 区间查曲线、导出逐题结果运行配对代码。signal-to-noise 定义为模型系列中有意义增益相对标准误的比值；许多代码生成 benchmark 低于 2，无法稳定测出模型规模翻倍的增益。最后的 SWE-bench issue 提醒：当一次评测涉及 10 万 token、无人审计轨迹时，数据和执行错误会长期隐藏。
\lecturefigure{slides-images/slide-037.png}{官方 slide 37：multiple seeds、训练曲线与逐题结果的噪声测量建议} \lecturefigure{slides-images/slide-038.png}{官方 slide 38：Eval-Arena 的噪声参考、排名与可疑样本工具} \lecturefigure{slides-images/slide-039.png}{官方 slide 39：各 benchmark 的 signal-to-noise 排名表} \lecturefigure{slides-images/slide-040.png}{官方 slide 40：signal-to-noise 还依赖模型类别} \lecturefigure{slides-images/slide-041.png}{官方 slide 41：复杂 SWE-bench 执行链路中的真实审计事故} \lecturefigure{slides-images/slide-042.png}{官方 slide 42：不同模型对和规模区间的 paired comparison 结果}
分子是要测量的模型增益，分母是同题配对差值的标准误。\(\mathrm{SNR}<2\) 通常意味着差异尚不足以稳定越过常见 95% 双侧阈值，但它不是跨所有多重比较情形的万能判据。排行榜同时比较大量模型时，还需控制 family-wise error 或 false discovery rate。
读图：Signal-to-noise 比“题目看起来难”更接近 benchmark 质量
slide 39 中，MMLU、TQA 等大规模选择题的 SNR 高于许多复杂代码 benchmark；这不表示选择题更接近真实工作，而是表示它们更稳定地测出既定模型差异。生态有效性与统计可靠性是两条轴：Agent benchmark 可以更真实，却仍需要更多任务、更丰富轨迹标签和更严格执行审计。
Agent Eval 的额外故障面
Agent 分数不仅受题目和推理 seed 影响，还受环境镜像、依赖版本、工具权限、超时、重试和 evaluator 脚本影响。复杂度越高，越不能只保存最终 pass/fail。应保留逐步轨迹、工具返回、环境哈希和失败归因，使“模型没做对”与“评测基础设施坏了”能够分开。
本章小结
官方 42 页幻灯片形成一条完整证据链：小 benchmark 的长答案并未自动解决统计功效；逐题概率揭示模型响应具有连续性和不一致性；paired comparison 与方差分解给出可计算的不确定度；经验噪声又能由数据集大小、accuracy 和模型相关性部分预测。最终建议不是停止评测，而是报告误差、共享逐题结果、扩大信息量并审计复杂执行链路。
课程定位：为什么今天要讨论 “可预测噪声”
从 “分数崇拜” 到 “分数校准”
Sida Wang 这讲的起点很直接：当前社区对 benchmark 的使用方式，经常默认 “分数差异 = 能力差异”。在小规模任务上这个假设有时成立，但在大模型和 agentic workload 下，分数本身已经变成高噪声统计量。也就是说，榜单并非无价值，而是必须先回答 “这个分数的误差有多大”、“这个差异是否统计显著”。
本讲核心命题
Benchmark score 不是确定值，而是随机变量。只有把它放回概率与统计框架，排行榜才有可解释性。
噪声为何在 LLM 时代被放大
传统监督学习评测里，输入固定、输出空间较小、评分规则清晰，因此噪声通常主要来自采样误差。LLM 评测不同：模型输出自由度更高，prompt 模板选择空间更大，解码策略和 judge pipeline 都会注入额外方差。尤其在 open-ended 任务和 agent benchmark 中，轨迹级交互使 variance 成倍上升。
LLM benchmark 噪声放大的三个结构性原因
- 生成随机性：temperature、top-p、sampling seed 会改变输出分布。
- 协议随机性：prompt wording、system instruction、few-shot selection 会改写任务难度。
- 评审随机性：LLM-as-judge、人评一致性、rubric 模糊性都会造成测量噪声。
本章小结
这讲不是反对 benchmark，而是反对把 noisy metric 当作 deterministic truth。后续所有技术点都围绕同一个目标：把 “分数” 变成 “可校准、可比较、可复现实验信号”。
噪声分类法：把不确定性拆成可建模组件
三层噪声结构
Sida 把噪声源拆为可以落地操作的几层：task/data 层、inference/protocol 层、evaluation/judge 层。这种分层的价值在于，它把 “噪声” 从模糊概念变成可诊断对象。团队在调研 benchmark 波动时，常见失败是把所有误差都归因到模型；分层框架要求先定位误差来自哪一层。
| 噪声层 | 典型来源 | 可控手段 |
|---|---|---|
| Task/Data | 数据污染、难度漂移、样本选择偏差 | 数据去污染、难度分桶、分布追踪 |
| Inference/Protocol | prompt 模板、解码策略、上下文拼接方式 | 协议固定、seed 控制、A/B 模板对照 |
| Evaluation/Judge | rubric 模糊、judge 偏置、评审一致性不足 | 双评审、仲裁机制、置信区间汇报 |
“可预测” 的含义
可预测不等于可消除。实际系统里，很多噪声不会消失，但可以被估计、被约束、被报告。比如当你知道某个 benchmark 在固定配置下的 run-to-run standard deviation 是 \(0.8\)，那么 \(0.3\) 的改进就不应被当作 “胜出”。这个思想本质是 measurement science，而不是 leaderboard engineering。
错误的报告方式
只报单点分数，不报 variance；只报最佳 run，不报 run distribution；只报总体平均，不报分桶结果。
噪声与 “可比性”
社区经常做 cross-paper 对比，但如果协议不同、模板不同、judge 不同，分数本身不可比。Sida 的强调点是：先建立 comparability，再谈 superiority。否则论文 A 比论文 B 高 1 分，可能只是评测协议不同，而不是模型变强。
排行榜比较的常见误区
当两个系统不共享同一评测协议时，排序信息的可信度会显著下降。盲目比较只会制造伪进展。
本章小结
可预测噪声的关键不是 “把噪声归零”，而是建立统一分层框架，让每个分数都能被解释。分层越清晰，后续统计估计和协议治理越容易落地。
统计建模：把 benchmark score 当作随机变量
最小数学框架
令某任务上的观测分数为 \(S\)，理想能力为 \(\mu\)，噪声为 \(\epsilon\)，则 $$ S = \mu + \epsilon,\quad \mathbb{E}[\epsilon]=0,\quad \mathrm{Var}(\epsilon)=\sigma^2. $$ 如果只报告 \(S\) 而不报告 \(\sigma\)，我们无法判断 “改进” 是否真实。进一步对多次运行 \(S_1,\dots,S_n\) 取均值 \(\bar{S}\)，其方差缩放为 \(\sigma^2/n\)，这解释了为什么多次重复评测是必要步骤。
为什么单次跑分不够
单次跑分只给你一个 realization，无法告诉你 score distribution。没有分布信息，就无法做显著性判断。
bootstrap 与置信区间
课程里反复提到 bootstrap 的价值：在样本规模有限、分布未知时，bootstrap 提供了实际可操作的 uncertainty estimate。对于 benchmark reporting，可以使用 percentile CI（如 95% CI）作为标准报告项。
scores = run_eval_k_times(model, benchmark, k=20)
mean_score = np.mean(scores)
ci_low, ci_high = bootstrap_ci(scores, confidence=0.95)
report(mean_score, ci_low, ci_high)
报告规范建议
每个主结果至少包含：mean、std、95% CI、重复次数 \(k\)、协议版本号。
噪声可预测性的工程收益
一旦噪声被量化，决策就会变得更理性。比如模型改进 pipeline 中，可以把 “是否上线” 从单分阈值改成 “显著改进阈值”：只有当新模型相对旧模型在关键子集上显著优于阈值，才进入下一阶段。这会显著减少 “看起来进步，线上退化” 的事故。
未校准噪声会误导训练方向
如果评测噪声被误当作能力增益，训练团队会被带向错误目标，浪费计算预算和研究周期。
本章小结
这讲最重要的统计思想很朴素：分数必须和不确定性一起报告。bootstrap、重复评测和显著性检验不是锦上添花，而是 benchmark 能被信任的最低门槛。
协议噪声：Prompt、Seed、Decode 为什么会改变结论
Prompt template 不是中立变量
LLM 任务里，prompt 经常携带隐含 inductive bias。即便任务语义相同，不同模板也可能导致明显分差。Sida 在讲中强调，如果论文结论依赖某一个模板，必须检查它在模板扰动下是否稳定。
协议敏感性测试（Protocol Sensitivity Test）
固定模型与数据，仅改变模板/解码参数，观察分数变化范围。若变化过大，说明结论脆弱。
Decode 设置与 variance
许多 benchmark 默认温度为 0，但在 agentic workload 中，模型通常无法完全 deterministic。此时 seed 和 decode policy 的影响会累积到轨迹层。课程里建议把 decode policy 当作评测协议的一部分进行 versioning，而不是隐含默认值。
协议版本管理建议
- 固定并公开：temperature、top-p、max tokens、stop criteria。
- 记录并公开：evaluation harness commit hash。
- 对关键结果做 seed sweep，至少报告 3-5 个随机种子的分布。
Judge 噪声：LLM-as-judge 的双刃剑
LLM judge 能快速扩展评测规模，但会引入 judge drift、position bias、verbosity bias 等问题。Sida 的态度是 “可用，但要校准”。常见做法包括双 judge 交叉验证、人评抽检、以及对评审 rubric 进行对抗测试。
Judge 过拟合风险
当模型针对 judge 偏好优化（而非任务真实目标）时，会出现 “会得分但不会做事” 的现象。
本章小结
协议层噪声是最容易被忽略、也最容易被治理的一层。只要建立版本化协议、重复评测和 judge 校准流程，很多 “神秘波动” 都能被解释为协议差异，而非能力突变。
数据与任务噪声：污染、难度漂移与分布错配
数据污染（contamination）
模型训练语料与 benchmark 测试集重叠，会显著高估泛化能力。课程中给出的核心观点是：污染检测不应只做 exact match，还应关注 paraphrase 和近重复。
污染治理的三层方案
- 静态去重：n-gram / MinHash / embedding 近邻过滤。
- 过程审计：训练数据版本化与可追踪清单。
- 评测防御：动态更新测试集或构造 holdout private split。
难度漂移（difficulty drift）
随着模型能力提升，旧 benchmark 可能迅速饱和。此时分数增益压缩，噪声占比上升，导致 “谁第一” 变得更多取决于方差而不是能力差。Sida 建议对 benchmark 进行 difficulty stratification（按难度分桶）并持续更新 hard split。
难度分桶的收益
分桶后可以区分两类改进：
- 在 easy split 提升：可能只是模板适配或表层优化。
- 在 hard split 提升：更可能代表真实能力增长。
任务分布错配
公开 benchmark 的任务分布往往与真实应用分布不同。对于 agent 系统，这种错配更严重，因为线上任务包含权限约束、工具失败、长上下文污染和多轮中断等现实因素。课程强调，benchmarks 应和 production telemetry 联动，而不是孤立存在。
只优化公开基准会产生局部最优
模型可能在 benchmark 上显著提升，但在真实任务链路里因为异常恢复和工具鲁棒性不足而退化。
本章小结
数据与任务层噪声决定了 benchmark “测到的到底是不是你想测的能力”。去污染、难度分桶和分布对齐是提升评测信度的三条主线。
从单轮到 Agent：为什么 agent benchmark 噪声更难
轨迹级方差（trajectory-level variance）
在 agent benchmark 中，分数不仅受最终答案影响，还受中间决策路径影响。一个早期小错误会在后续工具调用中放大，形成高方差尾部事件（long-tail failure）。这使得 “同一模型、同一任务” 在多次运行中的结果分布更宽。
Agent eval 的本质变化
从 “静态样本打分” 转向 “动态轨迹打分”。评测对象不再是单输出，而是决策过程。
环境不确定性与评测一致性
Agent 任务依赖外部环境：API 延迟、网页变化、工具可用性、文件状态都可能改变结果。因此课程强调要把 environment versioning 当成 benchmark 协议的一部分，必要时使用 sandbox replay 或 deterministic simulator。
Agent benchmark 的最小可复现要素
- environment snapshot 版本号；
- tool API mock/real 的开关与记录；
- timeout 与 retry 策略；
- trajectory log 与 error taxonomy。
评估指标需要从 “accuracy” 扩展到 “reliability”
Sida 讲中指出，对于 agent 系统，仅看 success rate 不够。至少还应报告 recovery rate、invalid action ratio、tool efficiency、time-to-success 等指标。这样才能区分 “偶然成功” 与 “稳定可用”。
只看最终成功率会掩盖系统退化
两个系统可能成功率接近，但一个需要大量无效工具调用和回退，另一个路径更短更稳。若只看 success rate，优化方向会偏离真实用户体验。
本章小结
Agent benchmark 的难点不在 “题更难”，而在 “系统变量更多”。评测若不显式建模环境与轨迹噪声，就会把系统随机波动误判为模型能力变化。
落地建议：团队如何构建抗噪声评测流水线
一个可执行的评测 SOP
结合本讲内容，可以整理出一个可落地的评测 SOP：先定义任务层级和关键指标，再固定协议版本，然后做重复评测并报告置信区间，最后再做跨模板和跨环境鲁棒性验证。这个顺序能避免 “先看排行榜再补解释” 的被动流程。
| 阶段 | 动作 | 交付物 |
|---|---|---|
| 1 | 任务定义与分桶 | task schema、难度分桶、目标指标 |
| 2 | 协议冻结 | prompt 模板、decode 参数、judge 配置版本 |
| 3 | 重复评测 | mean/std/CI、seed sweep 结果 |
| 4 | 鲁棒性检查 | 模板扰动、环境扰动、judge 一致性报告 |
| 5 | 上线判定 | 显著性门槛、回归报警规则、回滚策略 |
当资源有限时，优先做什么
课程里一个务实观点是：很多团队不是不知道统计方法，而是没有预算全做。若只能选几件事，优先级建议是：重复评测（k 次运行）> 协议版本固定 > 最小置信区间报告 > 难度分桶。这四项能用最小成本换来最大可解释性提升。
低成本高收益实践包
- 同一配置至少跑 5 次并报均值与标准差；
- 每次发布写明协议版本与 seed；
- 对最关键 20% 样本做人评抽检；
- 对 hard split 单独汇报，不与总体平均混报。
本章小结
抗噪声评测不是大厂特权，而是一套可分层实施的方法。即使资源有限，也可以通过重复评测、协议冻结和最小统计报告显著提高结论可信度。
实战案例：如何判断 “+0.6 分” 到底算不算进步
案例设定
为了把课程中的统计思想落到工程决策，我们构造一个典型场景：团队有两个版本，Model-A（基线）和 Model-B（候选），在同一 benchmark、同一协议下各跑 10 次。平均分看起来 Model-B 高 0.6 分，但 run-to-run 波动也明显。
| 模型 | Mean | Std | Runs | 95% CI |
|---|---|---|---|---|
| Model-A | 72.4 | 1.1 | 10 | [71.7, 73.1] |
| Model-B | 73.0 | 1.2 | 10 | [72.2, 73.8] |
课程强调的决策规则
当两个模型置信区间重叠明显时，不应直接下结论 “B 胜过 A”。更稳妥做法是：增加重复次数、做 paired test、并在关键子集上复核。
从总体分数转向分桶结论
把样本按难度分桶后，我们可能看到完全不同的结论：Model-B 在 easy split 提升很大，但在 hard split 几乎无提升。若真实业务更接近 hard split，那么总体 +0.6 分并不代表真实价值。
| 难度分桶 | Model-A | Model-B | 差值 (B-A) |
|---|---|---|---|
| Easy | 84.1 | 85.7 | +1.6 |
| Medium | 71.5 | 72.0 | +0.5 |
| Hard | 58.8 | 58.9 | +0.1 |
只报总体分数会导致错误上线
如果业务请求以 hard case 为主，盲目按总体分数上线，可能带来 “线上体感无提升甚至退化” 的结果。课程中把这类问题称为 benchmark interpretation failure。
把显著性检验写进发布流程
在团队流程上，建议把 “统计显著性门槛” 变成 release gate。候选模型只有在关键任务集上满足预设门槛（例如 p-value 与 effect size 同时达标）才可进入灰度。这让评测从 “结果展示” 升级为 “质量控制”。
可执行的发布门槛示例
- 关键任务集上 \(\Delta \text{score} \ge 0.8\)；
- paired bootstrap 的 95% CI 下界 \(>0\)；
- hard split 不得退化超过 0.2 分；
- 工具调用效率指标（tokens / tool calls / latency）不得恶化超过阈值。
本章小结
“+0.6 分” 的意义取决于方差、分桶和业务分布。统计显著性不是学术装饰，而是模型发布的风险控制工具。
Agent 评测日志归因：从轨迹错误到系统改进
为什么必须看 trajectory log
在 agent benchmark 中，最终失败通常是多步错误叠加的结果。课程中反复强调，不看轨迹日志就很难判断 “是模型 reasoning 错误” 还是 “工具接口失败”。这也是为什么 reliability 指标必须和 success rate 一起报告。
最小日志字段建议
- 每一步 action 的输入、输出、时间戳；
- 工具返回状态码与异常分类；
- 中间状态摘要（memory snapshot）；
- 终止原因（成功、超时、无效动作、评审拒绝）。
错误归因表：把失败模式量化
把失败模式结构化后，团队才知道应该优化模型、协议还是 infra。下面的表格示例体现了这一点：表面上 success rate 只有小幅提升，但 invalid action 与 timeout 大幅下降，说明系统稳定性改进显著。
| 错误类型 | Baseline | New | 变化 |
|---|---|---|---|
| Invalid Action | 12.4% | 8.1% | -4.3pp |
| Tool Timeout | 9.7% | 6.0% | -3.7pp |
| Wrong Plan | 14.2% | 13.0% | -1.2pp |
| Judge Rejection | 6.8% | 6.1% | -0.7pp |
一个简化的日志分析脚本
为了让评测闭环更自动化，可以用轻量脚本聚合 trajectory 失败模式。关键不是脚本复杂度，而是全团队共享同一 taxonomy。
from collections import Counter
counter = Counter()
for traj in trajectories:
reason = traj["termination_reason"]
counter[reason] += 1
total = sum(counter.values())
for k, v in counter.items():
print(k, f"{v/total:.2%}")
没有统一 taxonomy，日志会退化成噪声
如果每个子团队定义一套 termination reason，跨实验比较会迅速失效，最后又回到 “只看总分” 的旧问题。
本章小结
Agent 评测真正的增益来自 “过程可解释”。轨迹日志、错误归因和统一 taxonomy 是把评测变成可优化系统的必要条件。
组织治理：如何防止 benchmark 被 “刷分工程” 劫持
评测治理不只是技术问题
Sida 在问答里提到，噪声问题最终会变成组织问题：如果团队激励只看 leaderboard，系统自然会朝 “短期可刷分” 方向演化。治理目标是让激励函数和真实能力一致，而不是让发布节奏被单一分数绑架。
评测治理的三条红线
- 禁止只报 best run，不报完整 run distribution；
- 禁止跨协议比较但仍给出确定性排序；
- 禁止把私有调参结果当作通用能力结论对外发布。
抗游戏化（anti-gaming）机制
为了降低 benchmark gaming，可以采取 challenge split、协议轮换、隐藏测试集、以及周期性人工审计。课程强调，治理不是为了变慢，而是为了让 “快” 不以牺牲真实性为代价。
| 机制 | 解决的问题 | 代价 |
|---|---|---|
| Hidden Test Split | 防止公开集过拟合 | 复现成本上升 |
| Protocol Rotation | 防止模板投机 | 历史可比性下降 |
| Human Audit | 校准 judge 偏差 | 人力成本较高 |
| Release Gating | 把统计门槛写入流程 | 发布速度变慢 |
面向 2026 的评测系统形态
如果把本讲结论外推到下一阶段，团队需要的不只是 benchmark harness，而是 benchmark platform：可版本化协议、可追踪日志、可配置统计报告、可插拔 judge 和可审计发布流程。只有这样，benchmark 才能成为研发基础设施，而不是一次性演示工具。
没有治理，噪声会反向塑造研究方向
当团队把 “噪声中奖” 误当成 “能力突破”，研究资源会被系统性错配，长期会拖慢真实进展。
本章小结
Benchmark 可靠性最终由组织机制保证。技术框架给出测量能力，治理机制保证测量结果不会被短期激励扭曲。
统计实操补充：如何设定 “可发布” 的显著性门槛
从 effect size 到 MDE（Minimum Detectable Effect）
课程反复强调 “不要把微小分差直接解读成能力提升”。在工程实践中，可把这个原则落实为 MDE 机制：在发布前先声明 “至少提升多少才算有效进步”，低于该阈值则进入观察区而非发布区。
MDE 的直观解释
MDE 不是统计上的真理，而是团队关于 “业务上有意义提升” 的共同约定。它把统计显著性和产品价值连接起来，避免为了追逐小数点后两位而过度优化 benchmark。
若把每次运行结果近似视为独立样本，均值比较的样本量可用如下近似式估计：
其中 \(\Delta\) 为目标检测差异（MDE），\(\sigma\) 为历史波动标准差，\(\alpha\) 为显著性水平，\(\beta\) 为二类错误率。该式给出的不是绝对答案，但可快速评估 “当前 run 数是否明显不足”。
常见误区：先跑完再找显著性
很多团队先跑几次，看到结果 “似乎更好” 才临时做显著性检验。这样会引入选择偏差。更稳健做法是提前写下评测计划：run 次数、停止条件、主指标与次指标、判定阈值。
重复运行预算：什么时候 5 次够，什么时候远远不够
对于低噪声分类任务，5 次重复可能已经足够稳定；但对 agent benchmark，轨迹随机性和环境扰动会使方差显著上升，10--20 次运行才可能得到可解释区间。课程中的建议是基于历史方差做分层预算，而不是给所有任务统一 run 数。
| 任务类型 | 历史波动（示例） | 建议 run 数 | 发布建议 |
|---|---|---|---|
| Closed QA / MCQ | \(σ ≤ 0.3\) | 5–8 | 报告均值+CI，通常可快速发布 |
| Open-ended generation | \(0.3 < σ ≤ 1.0\) | 8–12 | 强制双 judge 抽检 |
| Agent workflow | \(σ > 1.0\) | 12–20 | 必报轨迹级错误与环境版本 |
可执行规则
当观测提升 \(< \mathrm{MDE}\) 或 95%CI 与基线显著重叠时，默认结论应为 “暂无证据表明显著提升”，而非 “模型退化/提升” 的二元叙事。
多指标冲突：如何从 “单分数” 过渡到 “发布门禁”
真实系统几乎总会出现指标冲突，例如 success rate 上升但 timeout 上升，或总体分数上升但 hard split 下降。课程建议把发布判定写成门禁规则（gating policy），例如：
- 主指标达到 MDE 且通过显著性门槛；
- 可靠性指标（timeout、invalid action）不得劣化超过阈值；
- hard split 不得出现统计显著退化；
- 若使用 LLM-as-judge，必须通过抽样人工复核。
为什么要 “门禁化”
门禁化的核心价值是降低解释自由度。发布前就定义好规则，可以防止事后挑选有利指标，也让跨版本比较具有一致标准。
本章小结
统计实操的关键不是追求复杂检验，而是把 “阈值、预算、门禁” 前置定义。这样 benchmark 才能从研究展示工具升级为工程决策基础。
附录：一份可直接复用的 Benchmark 报告模板
报告模板字段
为了把课程思想直接落到团队协作，这里给出一份可复用模板。核心原则是 “所有可影响结论的变量都要显式记录”，避免后续复现时出现信息缺失。
| 字段 | 示例 | 说明 |
|---|---|---|
| Model Version | model_2026_04_rc2 | 必须能唯一定位权重与配置 |
| Benchmark Version | bench_v3.4 | 任务集与样本切分版本号 |
| Prompt Protocol | proto_2026_04_a | system prompt + template + few-shot 策略 |
| Decode Config | temp=0.2, top_p=0.95 | 生成参数是评测协议组成部分 |
| Judge Config | judge-v2 | 若有 LLM judge，需记录模型和 rubric |
| Runs / Seeds | 10 runs, seeds=[1..10] | 无重复运行的结果不应进入最终报告 |
| Main Metric | success_rate=73.0 | 总体分数 |
| Uncertainty | std=1.2, 95%CI=[72.2,73.8] | 至少报告一种置信区间 |
| Hard Split | 58.9 (+0.1) | 避免总体分数掩盖难样本退化 |
| Reliability Metrics | invalid_action, timeout, recovery | Agent 任务必须补充可靠性指标 |
| Environment Version | env-2026-04-01 | 保证任务环境可复现 |
| Known Limitations | judge bias risk, sample drift | 主动披露风险与限制 |
发布前检查清单
Release Checklist
- 是否完成了不少于 5 次重复评测并保存全部原始日志？
- 是否确认协议版本、judge 版本和环境版本均已冻结？
- 是否报告了 hard split 与关键业务子集表现？
- 是否有人评抽检来校准自动评审偏差？
- 是否有回归告警阈值与回滚预案？
为什么这份模板有用
它把课程中的统计原则、协议治理和工程可复现性收敛成一份统一文档格式。模板统一后，跨团队比较将基于同一信息面展开，能显著降低 “因为记录不全导致的争议”。
本章小结
评测体系要可持续，必须让 “报告结构” 标准化。模板和清单看似琐碎，但它们决定了 benchmark 结论能否被长期复用。
总结与延伸
全讲结论汇总
| 问题 | 课程结论 | 实践含义 |
|---|---|---|
| 为什么分数会波动？ | 分数本质是随机变量，噪声可预测但不可忽略 | 必须报告方差与置信区间 |
| 噪声来自哪里？ | 数据层、协议层、评审层共同作用 | 先分层诊断，再做治理 |
| 如何比较模型？ | 先保证 comparability，再谈 superiority | 不同协议下分数不可直接排序 |
| Agent 评测有什么不同？ | 轨迹级方差与环境噪声显著更高 | 需要环境版本化与可靠性指标 |
| 如何在团队落地？ | 建立抗噪声评测 SOP | 从重复评测和协议冻结开始 |
一句话复盘
Takeaway
如果不对 noise 建模，benchmark 会奖励偶然性；对 noise 建模后，benchmark 才会奖励真实进展。
拓展阅读
- Percy Liang et al., HELM（Holistic Evaluation of Language Models）相关论文与报告
- “Beyond the Imitation Game”（LM 评测框架讨论）
- 统计学习中的 bootstrap 与 uncertainty quantification 经典教材
- 针对 LLM-as-judge 的 bias / consistency 研究工作
- Agent benchmark（WebArena / SWE-bench / BrowserGym 类）中的复现与评测协议文档