量化智能体编程评估中的基础设施噪音

摘要

1) 一句话摘要 智能体编程评估的分数极易受底层基础设施资源配置的影响，资源限制的差异可导致高达 6% 的分数波动，因此在比较模型能力时必须严格控制和记录运行环境。

2) 关键点

分数波动显著： 基础设施配置的差异会导致 Terminal-Bench 2.0 的得分出现高达 6% 的波动（p < 0.01），这一幅度往往超过了排行榜上顶尖模型之间的分数差距。
严格限制导致高错误率： 在 Kubernetes 中严格执行单任务资源规格（1x，即保证分配量等于硬性上限）会导致高达 5.8% 的基础设施错误率，主要原因是瞬时内存峰值引发的 OOM（内存溢出）终止。
适度放宽提升稳定性： 将资源余量从 1x 提升至 3x，可将基础设施错误率显著降至 2.1%（p < 0.001），同时成功率的波动保持在统计噪音范围内（p = 0.40）。
过度放宽改变评估本质： 超过 3x 资源后，不设上限的总成功率比 1x 提高了 6%（p < 0.01）。宽裕的资源允许智能体采用高开销策略（如安装大型依赖项、暴力破解），而严格限制则奖励精简高效的代码。
跨基准测试的一致性： 这种资源依赖现象并非孤例；在 SWE-bench 中，将可用 RAM 增加 5 倍同样导致得分单调增加了 1.54%。
配置建议： 建议分离容器的“保证分配量”和“硬性终止阈值”以提供缓冲空间，并根据经验校准资源区间（如设置 3 倍上限），以在不造成分数膨胀的情况下中和基础设施噪音。
结果解读准则： 在资源方法论标准化之前，除非评估配置被详细记录并完全匹配，否则应对排行榜上低于 3% 的分数差异保持怀疑态度。

3) 风险/不足

能力与环境混淆风险： 公共基准测试旨在衡量模型能力，但实际操作中存在将纯粹的模型能力与基础设施特性（如硬件规格、集群健康度、并发级别、出网带宽）混为一谈的风险。
隐藏变量干扰： 评估系统本质上是端到端测试，得分会受到时间限制甚至一天中不同时间段（由于流量模式导致的 API 延迟波动）等难以控制的混淆因素影响。
决策误导风险： 业界越来越多地依赖基准测试分数进行模型部署决策，但排行榜上微小的领先可能仅仅是因为使用了更大的虚拟机或在更幸运的时间段运行，其包含的不确定性远大于报告数字的精度。
透明度与标准化缺失： 目前基准测试普遍缺乏公开或标准化的环境配置记录，导致外界难以分辨分数差异是源于真实能力还是基础设施噪音。

正文

像 SWE-bench 和 Terminal-Bench 这样的智能体编程基准测试，常被用于比较前沿模型的软件工程能力。排行榜上的顶尖模型得分往往只有几个百分点的差距，这些分数常被视为衡量模型相对能力的精确指标，并越来越多地影响着模型的部署决策。然而我们发现，单是基础设施配置的不同，就能产生超过这些微小差距的分数波动。在内部实验中，Terminal-Bench 2.0 在资源最充足和最匮乏的设置下，得分差距达到了 6 个百分点（p < 0.01）。

静态基准测试直接对模型的输出进行评分，运行时环境不会影响结果。但智能体编程评估则不同：模型会获得一个完整的环境，在其中编写程序、运行测试、安装依赖项，并进行多轮迭代。运行时环境不再是一个被动的容器，而是解决问题过程不可或缺的一部分。两个拥有不同资源预算和时间限制的智能体，实际上参加的并不是同一场考试。

评估开发者已经开始注意到这一点。例如，Terminal-Bench 2.0 在其最新版本中推荐了每项任务的 CPU 和 RAM 规格。然而，仅仅“指定”资源并不等于一致地“执行”限制。此外我们还发现，执行限制的方法本身甚至会改变基准测试实际衡量的内容。

发现问题的起因

我们在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0 时发现，我们的得分与官方排行榜不符，且基础设施错误率高得惊人：高达 6% 的任务因 Pod 错误而失败，而这大多与模型解决任务的能力无关。

这种得分差异归结于资源限制的执行方式。我们的 Kubernetes 实现将每项任务的资源规格同时视为“下限”和“硬性上限”：每个容器都能保证获得指定的资源，但一旦超出就会被立即终止。容器运行时通过两个独立的参数来执行资源限制：一个是保证分配量（预先保留的资源），另一个是硬性终止限制。当这两个值设为相同时，就没有任何应对瞬时峰值的余地：一次短暂的内存波动就能导致原本可以成功的容器因 OOM（内存溢出）被终止。为了解决这个问题，Terminal-Bench 排行榜使用了另一种沙盒提供商，其限制更为宽松，允许暂时的资源超额分配而不终止容器，从而保障了基础设施的稳定性。

这一发现引出了一个更大的问题：资源配置对评估得分的影响究竟有多大？

资源配置对得分的量化影响

为了量化脚手架（Scaffold）的影响，我们在六种资源配置下运行了 Terminal-Bench 2.0：从严格执行单任务规格（1x，即规格同时作为上下限），到完全不设上限。其他所有条件（相同的 Claude 模型、测试框架和任务集）均保持不变。

实验表明，成功率随着资源余量的增加而上升。这主要是因为基础设施错误率在每个阶段都在单调下降，从严格限制时的 5.8% 降至不设上限时的 0.5%。随着资源余量的增加，因超出分配额度而被终止的容器越来越少。

1x 到 3x 资源余量： 基础设施错误率显著下降（从 5.8% 降至 2.1%，p < 0.001），而成功率的波动在噪音范围内（p=0.40）。我们在数据中观察到，在 1x 限制下崩溃的大多数任务，即使不崩溃最终也会失败。智能体在探索时触及资源壁垒被抢占，但它原本就没有走在正确的解决路径上。
3x 到不设上限： 趋势发生改变，成功率的攀升速度超过了错误率的下降速度。基础设施错误率进一步下降了 1.6 个百分点，而成功率跃升了近 4 个百分点。额外的资源使智能体能够尝试只有在宽裕分配下才有效的策略，例如引入大型依赖项、生成高开销的子进程以及运行内存密集型测试套件。在不设上限时，总成功率比 1x 提高了 6 个百分点（p < 0.01）。在边缘情况下，像 rstan-to-pystan 和 compile-compcert 这样的任务在获得内存余量后，成功率有了显著提升。

资源限制如何改变评估的本质

在达到大约 3 倍 Terminal-Bench 规格之前，额外的资源主要解决了基础设施的可靠性问题（即瞬时资源峰值）。Terminal-Bench 维护者使用的沙盒提供商在后台隐式地执行了这一操作；评估变得更稳定，但并没有变得更容易。

然而，超过 3 倍标记后，额外的资源开始主动帮助智能体解决以前无法解决的问题，这表明资源限制实际上改变了评估所衡量的内容。严格的限制会在无意中奖励极其高效的策略，而宽裕的限制则更加包容，奖励那些能更好地利用所有可用资源的智能体。

编写精简、高效代码的智能体在严格限制下表现良好；使用重量级工具进行暴力破解的智能体在宽裕限制下表现出色。两者都是合理的测试目标，但如果不说明资源配置就将它们压缩成一个单一的分数，会使得差异和现实世界的泛化能力变得难以解释。

例如，在需要拟合贝叶斯网络的 bn-fit-modify 任务中，一些模型的首要动作是安装标准的数据科学栈（pandas、networkx、scikit-learn 等）。在宽裕的限制下，这行得通；但在严格限制下，Pod 会在安装期间耗尽内存，此时智能体甚至还没写下一行解决方案代码。虽然存在更精简的策略（仅使用标准库从头实现数学运算），且有些模型默认采用该策略，但其他模型则不然。不同的模型有不同的默认方法，而资源配置决定了哪种方法能够碰巧成功。

我们在不同的 Anthropic 模型中复现了这一核心发现。效应的方向是一致的，尽管幅度有所不同。同样的趋势似乎也适用于 Claude 以外的模型，但我们尚未进行严格测试。

我们还在 SWE-bench 上进行了交叉实验，以测试这种模式是否适用于 Terminal-Bench 之外的评估。我们在 227 个问题（每个问题 10 个样本）中将可用 RAM 增加到基准的 5 倍。同样的效应依然存在，尽管幅度较小：得分随着 RAM 单调增加，5x 时的得分比 1x 时高出 1.54 个百分点。由于 SWE-bench 任务的资源密集度较低，影响幅度较小是符合预期的，但这证明了资源分配在那里同样不是中性的。

其他方差来源

资源分配并不是唯一的隐藏变量。在某些配置中，时间限制也开始发挥作用。

原则上，评估设置的每一个元素都可能影响最终得分：从集群健康状况到硬件规格，从并发级别到出网带宽。智能体评估本质上是端到端的系统测试，系统的任何组件都可能成为混淆因素。例如，我们观察到通过率会随一天中的时间而波动，这可能是因为 API 延迟会随流量模式和突发事件而变化。我们尚未正式量化这种影响，但它说明了一个更大的问题：“模型能力”和“基础设施行为”之间的界限，比单一的基准测试分数所暗示的要模糊得多。模型提供商可以通过专用硬件来保护其评估基础设施免受此影响，但外部评估者很难做到这一点。

公共基准测试通常旨在衡量纯粹的模型能力，但在实践中，它们有将模型能力与基础设施特性混为一谈的风险。有时这可能是可取的，因为它支持对整个技术栈进行端到端测试，但更多时候并非如此。对于公开发布的编程评估，在不同的时间和日期进行多次运行有助于平均掉这些噪音。

我们的建议

最理想的情况是在完全相同的硬件条件下运行每项评估（包括运行评估的脚手架和推理栈），以确保完美的复现性。但这在实际中并不总是可行。

鉴于容器运行时实际执行资源限制的方式（通过保证分配量和独立的硬性终止阈值），我们建议：

分离资源参数： 评估应针对每项任务分别指定这两个参数，而不是给出一个单一的固定值。单一的精确规格会使保证分配量等于终止阈值，不留任何余地：我们在 1x 限制下记录的瞬时内存峰值足以破坏评估的稳定性。分离这两个参数可以为容器提供足够的缓冲空间以避免虚假的 OOM 终止，同时保持硬性上限以防止分数膨胀。
校准资源区间： 这两个参数之间的区间应经过校准，使得下限和上限处的得分落在噪音范围内。例如在 Terminal-Bench 2.0 中，设置 3 倍于任务规格的上限将基础设施错误率降低了约三分之二（从 5.8% 降至 2.1%，p < 0.001），同时保持了适度且在噪音范围内的分数提升（p = 0.40）。这是一个合理的权衡：在不消除有意义的资源压力的情况下，基础设施的混淆因素在很大程度上被中和了。具体的乘数会因基准测试和任务分布而异，因此应当被报告出来，但这种经验校准原则是通用的。

结论与意义

这些发现具有超越评估基础设施的实际意义。基准测试分数越来越多地被用作决策依据，但这种日益增加的关注（和依赖）并没有在运行或报告的严谨性上得到相应的体现。就目前情况而言，排行榜上 2 个百分点的领先优势，可能反映了真正的能力差异，也可能仅仅反映了某个评估运行在了更强大的硬件上，或者碰巧在一个更幸运的时间段运行，亦或两者兼有。如果没有公开（或标准化）的设置配置，外界很难分辨，除非相关方付出额外努力在完全相同的条件下复现客观结果。

对于像 Anthropic 这样的实验室来说，这意味着智能体评估的资源配置应被视为一等实验变量，需要像提示词格式或采样温度一样被严格记录和控制。对于基准测试维护者，发布推荐的资源规格（如 Terminal-Bench 2.0 所做的那样）大有裨益，而明确执行方法则能填补我们所发现的漏洞。对于任何使用基准测试结果的人来说，核心结论是：智能体评估中微小的分数差异所包含的不确定性，远大于报告数字的精度所暗示的程度——特别是考虑到某些混淆因素实在难以控制。

在资源方法论标准化之前，我们的数据表明：对于排行榜上低于 3 个百分点的差异，除非评估配置被详细记录并完全匹配，否则应保持怀疑态度。 在 Terminal-Bench 中等资源配置范围内的观察差异略低于 2 个百分点。朴素的二项式置信区间已经跨越了 1-2 个百分点；我们在此记录的基础设施混淆因素是叠加在其上的，而不是包含在其中。在分配范围的极端情况下，这种差异甚至达到了 6 个百分点。

几个百分点的领先可能意味着真正的能力差距——但也可能仅仅意味着使用了一台更大的虚拟机。

致谢

本文由 Gian Segato 撰写。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作反映了致力于编程智能体评估的多个团队的集体努力。欢迎有兴趣做出贡献的候选人访问 anthropic.com/careers 申请职位。

wsl-docs

探索