Infrastructure noise in evals
Infrastructure noise in evals 指 agent 评测结果被运行环境中的非能力因素显著扰动的现象。它包括资源上限、容器 enforcement 方式、时间限制、并发度、网络带宽、cluster 健康度等变量对最终分数的影响。关键点在于：这些变量有时只是在制造伪失败，有时又会真正改变 agent 能采用的求解策略，因此会混淆“模型能力”与“环境条件”。
- 这个概念只在 agent-style eval 上特别突出，因为模型是在真实执行环境中持续交互，而不是一次性输出静态答案。
- 因此同一个模型、同一个 task set、同一个 harness，如果资源预算或 enforcement 方式不同，严格来说就已经不是“同一场测试”。
- 文章里的核心例子来自 Terminal-Bench 2.0：把资源 spec 同时设成保底值和 kill threshold，会导致很多容器因为瞬时峰值被提前杀掉。
- 这类噪声的第一层表现是 infra errors 增加，例如 OOM kills、pod failures、超时或依赖安装中断；它们会让 agent 在还没真正尝试解题前就失败。
- 第二层更关键：当资源继续放宽时，agent 不只是更稳定，而是能尝试原本做不到的策略，例如安装大依赖、跑重测试、启动更多昂贵子进程。
- 这意味着基础设施变量有时是在“修复测量噪声”，有时是在“重定义评测内容”，两者不能混为一谈。
- 从更高层看，这和 Evaluation harness 紧密相连，因为 harness 的职责不只是调度 task 和记录 transcript，也要尽量压低这类外部干扰。
- 它也和 Agentic coding evals 直接相关，因为 leaderboard 上的几分差距，可能本来就在这种基础设施方差范围之内。
- 这个概念和 Inference infrastructure regressions 有亲缘关系，但焦点不同：后者讲生产 serving 路径把模型质量拉低，前者讲评测环境把 benchmark 分数搞脏。
ℹ️ Conflict:
- 并非所有基础设施差异都是“噪声”。如果 benchmark 本来就想测资源受限环境下的表现，那么资源限制本身就是题目的一部分。
- 但如果 benchmark 目标是比较模型能力而不是比较 VM 大小，就必须把这些环境变量显式记录和校准，否则小分差会失去解释力。
- 完全消除这类噪声通常不现实，因此更务实的目标是识别主要 confounder、报告配置、并把其影响压到统计噪声范围内。
- Quantifying infrastructure noise in agentic coding evals
- Evaluation harness
- Agentic coding evals
- Inference infrastructure regressions
- Anthropic
- Anthropic, “Quantifying infrastructure noise in agentic coding evals”, 发布日期未在 raw 摘录中标明。
- 原文摘录：[llm-wiki/raw/anthropic/Quantifying infrastructure noise in agentic coding evals](/raw/anthropic/Quantifying infrastructure noise in agentic coding evals.md)