我们审计了SWE-Bench Pro——最广泛使用的AI编码基准之一——发现它已不再能可靠衡量前沿编码能力。

我们发现SWE-Bench Pro中30%的任务存在缺陷，因此撤回先前推荐研究社区将其作为主要编码评估的建议。

在编码评估中分离信号与噪声

来源：https://openai.com/index/separating-signal-from-noise-coding-evaluations/ 准确衡量模型能力对于合理的部署和安全决策至关重要，包括OpenAI《准备框架》(opens in a new window) (https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf)下的决策。我们在每次模型发布时，都会报告多种外部和内部基准的结果，以追踪模型进展。当评估存在影响结果的缺陷时，可能会导致对能力的错误理解，扭曲安全案例并影响研究优先级。

我们近期调查了(https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)最广泛使用的编码基准之一SWE-bench Verified，发现其存在根本性设计和污染问题，且该评估已无法为软件开发能力提供有意义信号。当时，我们鼓励更广泛的社区转向SWE-Bench Pro。

SWE-Bench Pro(opens in a new window) (https://scale.com/blog/swe-bench-pro)旨在改进SWE-bench Verified，通过让模型在更长周期和更真实编码任务中接受测试，更好地追踪智能体编码能力。与SWE-bench Verified类似，任务以编程方式从一组公共和私有仓库的功能变更历史中提取。模型需要实现一个解决方案，通过新功能测试且不破坏现有功能。在731个任务的公共子集中，前沿模型的通过率在八个月内从23.3%提升至80.3%。

此后我们对SWE-Bench Pro进行了类似审计，使用数据点分析流水线审查数据集。该流水线审查模型尝试、任务元数据和失败轨迹，以标记可能的评估缺陷。每个被标记的任务随后通过多次调查智能体传递进行审计，并由五位经验丰富的软件工程师独立复核，分歧提交进一步调查。

我们发现数据集中相当一部分任务存在明显问题。数据点分析流水线标记了200个（27.4%）有缺陷任务，而人工标注活动识别出249个（34.1%）。

问题主要分为四类：

• 过于严格的测试¹(https://openai.com/index/separating-signal-from-noise-coding-evaluations/#citation-bottom-1)：强制执行提示中未指定的具体实现细节，使许多功能正确的提交无效。
• 提示不充分²(https://openai.com/index/separating-signal-from-noise-coding-evaluations/#citation-bottom-2)：遗漏了隐藏测试强制执行且无法合理推断的要求。
• 测试覆盖率低：对请求功能检查不足，使得不完整的修复也能通过。
• 误导性提示：引导模型走向错误行为或与测试要求矛盾。

我们的发现凸显了策划困难但公平的基准的难度，以及智能体在可扩展数据质量检查中的日益重要作用。基于这些结果，我们估计SWE-Bench Pro中约30%的任务存在缺陷，并建议模型开发者仔细检查结果。

方法论

我们的目标是确保任务失败反映的是模型的真实局限，而任务成功代表了对提示要求的完整有效解决方案。为检查评估用数据的质量，我们创建了一个质量保证流水线，评估每个数据点是否准确反映模型能力。

初始数据质量流水线标记问题以供审查。我们通过更深入的智能体辅助审计和与经验丰富的工程师合作进行的人工标注活动来验证。

初始自动过滤器审查给予模型的指令、模型解决任务的尝试以及用于评分的测试，以标记可能存在问题或缺陷的例子。该过滤器标记了286个可能有问题任务。随后我们对该子集进行了两种方式的深入审查：人工监督的智能体审查（通过调查智能体进行广泛检查并由人类做出最终判断）和与经验丰富的软件开发者合作进行的人工标注活动。

人工监督的智能体审查

每个被标记的问题通过基于Codex的调查智能体进行审计，这些智能体可以访问任务仓库和环境。这有助于他们区分合理的任务歧义（通常可以通过研究附近代码和仓库约定来解决）与真正的不充分说明。智能体可以运行测试、检查仓库中的文件，并调查模型尝试及其在任务中的常见失败模式。在多次独立重复这些深入审计后，研究人员审查摘要，做出最终判断，并标记可能的问题。

人工标注活动

与此同时，我们对标记的子集进行了人工标注活动。我们与经验丰富的软件工程师合作，他们接受了基准目标、问题分类和边缘案例的培训，然后审查任务。每个任务由五位工程师审查。

审查者先根据可见的问题陈述、测试用例和真实参考解决方案（称为黄金补丁）形成独立判断，然后将流水线分析或记录作为支持背景。随后审查者根据具体证据分配标签和严重等级，将分歧或低置信度案例提交进一步审查。

人工审查者比调查智能体更倾向于将任务标记为有缺陷。两种审查路径在分类上也存在一些分歧，但在被标记的任务中，没有出现“未缺陷”作为最常见的人类标签。在智能体流水线标记的类别中，审查者判断的重叠率为74%。

与智能体流水线相比，人工审查者更倾向于为任务选择多个标签，表明他们认为任务存在多种缺陷或不能完全归入单一类别。这表明智能体加审查者流水线导致保守标签：它捕捉了人类识别出的相同广泛故障模式，同时低估了审查者看到的额外或重叠问题。最大的差异在于测试覆盖率低，人类将其选为基准中9.4%任务的最常见问题，而智能体流水线仅为4.1%。

故障模式

在多个案例中，任务提示规定了具体实现，但隐藏测试用例期望不同的行为。

讨论

我们识别出的问题，加上SWE-bench Verified (https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)中的类似案例，凸显了严格检查基准的重要性。开源仓库的问题和拉取请求最初是为人类协作而创建的，通常通过维护者和贡献者之间长时间反复沟通。因此，问题描述、合并代码和单元测试并不总是能够形成干净、孤立的