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

# 量化智能体编程评估中的基础设施噪声 来源：https://www.anthropic.com/engineering/infrastructure-noise 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，从严格执行每项任务规格（1x，同时作为下限和上限）到完全无上限。其他条件保持不变：同一 Claude 模型、同一测试框架、同一任务集。 实验中，成功率随资源余量增加而提升。这主要由基础设施错误率单调下降驱动，从严格执行时的 5.8% 降至无上限时的 0.5%。严格执行到 3x 余量的降幅（5.8% 至 2.1%）在 p < 0.001 水平显著。余量越大，因超分配而被杀死的容器越少。 从 1x 到 3x，成功分数在噪声范围内波动（p = 0.40）。1x 下崩溃的大多数任务本就会失败——我们在数据中观察到了这一点。智能体进行探索时撞上资源墙被抢占，但它本就没有走在正确解法的路上。 然而从 3x 左右开始，趋势发生变化：成功率增速超过基础设施错误降幅。 3x 到无上限之间，基础设施错误仅再降 1.6 个百分点，而成功率跃升近 4 个百分点。额外资源使智能体能够尝试仅在充裕配置下可行的方案，例如拉取大型依赖、生成昂贵子进程、运行内存密集型测试套件。在无上限资源下，相比 1x 的总提升为 +6 个百分点（p < 0.01）。在边缘地带，像 `rstan-to-pystan` 和 `compile-compcert` 这类任务在获得内存余量后成功率显著提升。 ## **对测量的影响** 在约 3x Terminal-Bench 规格以下，额外资源解决的是基础设施可靠性问题，即瞬态资源峰值。Terminal-Bench 维护者使用的沙箱提供商在后台隐式执行了这一操作；评估变得更稳定，而非更简单。 但超过 3x 后，额外资源开始主动帮助智能体解决此前无法解决的问题，这表明限制条件实际上会改变评估的测量对象。严格限制无意中奖励极高效率的策略，而宽松限制更宽容，奖励能更好利用全部资源的智能体。 编写精简高效代码的智能体在严格约束下表现优异。依赖重型工具暴力求解的智能体在宽松条件下表现优异。两者都是合理的测试对象，但将其混为一谈却不指明资源配置，会使差异及真实世界泛化性难以解读。 在 `bn-fit-modify` 这一 Terminal-Bench 任务（要求贝叶斯网络拟合）中，部分模型的第一步是安装标准 Python 数据科学栈：`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 个百分点。 几分的领先可能预示真实能力差距——也可能只是更大的 VM。 ### **致谢** 作者：Gian Segato。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作反映了多个团队在为编码智能体进行评估方面的集体努力。欢迎有意贡献的候选人申请 anthropic.com/careers（http://anthropic.com/careers）。