量化智能体编码评估中的基础设施噪声 \ Anthropic

来源: https://www.anthropic.com/engineering/infrastructure-noise 抓取时间: 2026-07-21 16:26:06

智能体编码基准测试（如 SWE-bench 和 Terminal-Bench）通常用于比较前沿模型的软件工程能力——排行榜上的前几名往往仅相差几个百分点。这些分数经常被视为相对模型能力的精确衡量标准，并越来越多地影响关于部署哪些模型的决策。然而，我们发现，仅基础设施配置本身就能产生超过这些差距的差异。在内部实验中，Terminal-Bench 2.0 上资源最充足和最匮乏的设置之间的差距为 6 个百分点（p < 0.01）。

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

评估开发者已经开始考虑这一点。例如，Terminal-Bench 2.0 在其最新的 2.0 版本中按任务指定了推荐的 CPU 和 RAM。然而，指定资源与一致地强制执行它们不是一回事。此外，我们发现强制执行方法可以改变基准最终实际衡量的内容。

我们是如何发现这个问题的

我们在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0。在校准设置时，我们注意到我们的分数与基准的官方排行榜不匹配，并且基础设施错误率高得惊人：多达 6% 的任务因 Pod 错误而失败，其中大多数与模型解决任务的能力无关。

分数的差异归结为强制执行方式。我们的 Kubernetes 实现将每个任务的资源规格同时视为下限和硬性上限：每个容器保证获得指定的资源，但一旦超出就会被立即终止。容器运行时通过两个独立的参数强制执行资源：保证分配（预先保留的资源）和容器被终止的硬性限制。当这些参数设置为相同值时，就没有处理瞬时峰值的余量：短暂的内存波动可能会 OOM 杀死原本会成功的容器。为了解决这个问题，Terminal-Bench 的排行榜使用了不同的沙箱提供程序，其实现更为宽松，允许临时超配而不终止容器，以有利于基础设施稳定性。

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

为了量化支架的影响，我们在六种资源配置下运行了 Terminal-Bench 2.0，从严格执行每个任务规格（1 倍）（将它们同时作为下限和上限）到完全无限制。其他一切保持不变：相同的 Claude 模型、相同的测试工具、相同的任务集。

在我们的实验中，成功率随着资源余量的增加而提高。这主要是由于基础设施错误率在每一步都单调下降，从严格执行时的 5.8% 降至无限制时的 0.5%。从严格执行到 3 倍余量之间的下降（5.8% 到 2.1%）在 p < 0.001 时是显著的。随着更多余量，更少的容器因超出其分配而被杀死。

从 1 倍到 3 倍，成功分数在噪声范围内波动（p = 0.40）。大多数在 1 倍时崩溃的任务无论如何都会失败——这是我们在数据中观察到的。智能体进行探索，遇到资源瓶颈，然后被抢占，但它从未走上正确解决方案的道路。

然而，从大约 3 倍开始，这种趋势发生了变化：成功率上升的速度超过了基础设施错误下降的速度。

在 3 倍到无限制之间，基础设施错误额外下降了 1.6 个百分点，而成功率跃升了近 4 个百分点。额外的资源使智能体能够尝试只有在慷慨分配时才有效的方法，例如引入大型依赖项、生成昂贵的子进程以及运行内存密集型测试套件。在无限制资源下，相对于 1 倍的总提升为 +6 个百分点（p < 0.01）。在边际上，像 rstan-to-pystan 和 compile-compcert 这样的任务在获得内存余量时显著提高了成功率。

这如何影响衡量

直到大约 3 倍的 Terminal-Bench 规格，额外的资源解决了基础设施可靠性问题，即瞬时资源峰值。Terminal-Bench 维护者使用的沙箱提供程序在幕后隐式地执行此操作；评估变得更加稳定而不会变得更容易。

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

一个快速编写精简、高效代码的智能体在严格约束下会表现良好。一个使用重量级工具暴力破解解决方案的智能体在慷慨约束下会表现良好。两者都是值得测试的合法内容，但如果在不指定资源配置的情况下将它们合并为单个分数，会使差异——以及现实世界的通用性——难以解释。

在 bn-fit-modify 上，这是一个需要贝叶斯网络拟合的 Terminal-Bench 任务，某些模型的第一步是安装标准的 Python 数据科学栈：pandas、networkx、scikit-learn 及其所有工具链。在慷慨的限制下，这有效。在严格的限制下，Pod 在安装过程中就会耗尽内存，而智能体甚至还没编写一行解决方案代码。存在一种更精简的策略（仅使用标准库从零开始实现数学运算），某些模型确实默认使用它。其他模型则不会。不同的模型有不同的默认方法，资源配置决定了这些方法中哪一种恰好成功。我们在不同的 Anthropic 模型中复制了核心发现。效果的方向是一致的，但幅度各不相同。同样的趋势似乎也适用于 Claude 以外的模型，但我们尚未对其进行严格测试。

我们还通过在 SWE-bench 上运行交叉实验，测试了这种模式是否适用于 Terminal-Bench 以外的评估。我们在 227 个问题上，每个问题 10 个样本，将总可用 RAM 最多变化到基线的 5 倍。同样的效果成立，尽管幅度较小：分数再次随 RAM 单调增加，但 5 倍时仅比 1 倍高 1.54 个百分点。SWE-bench 任务资源密集度较低，因此预期影响较小，但这表明资源分配在那里也不是中性的。

其他方差来源

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

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

公共基准测试通常旨在衡量纯模型能力，但实际上它们冒着将其与基础设施怪癖混为一谈的风险。有时这可能是可取的，因为它支持整个栈的端到端测试，但更多时候并非如此。对于旨在公开共享的编码评估，在多个时间和多天运行将有助于平均噪声。

我们的建议

理想情况是在完全相同的硬件条件下运行每个评估——包括运行评估的支架和推理栈——因为这将确保全面的完美可重复性。然而，这可能并不总是切实可行的。

鉴于容器运行时实际强制执行资源的方式——通过保证分配和单独的硬终止阈值——我们建议评估按任务指定两个参数，而不是单个固定值。单个精确规格将保证分配设置为等于终止阈值，留下零余量：我们在 1 倍时记录的瞬时内存峰值足以破坏评估。将两个参数分开可以让您给容器足够的喘息空间，以避免虚假的 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 申请。