为何我们不再评估SWE-bench Verified

# 为什么 SWE-bench Verified 不再能衡量前沿编码能力 来源：https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ 自2024年8月首次发布 [SWE-bench Verified](https://openai.com/index/introducing-swe-bench-verified/) 以来，业界广泛用它来衡量模型在自主软件工程任务上的进展。发布之初，SWE-bench Verified 提供了能力进展的有力信号，并成为了前沿模型发布中报告的标准指标。跟踪和预测这些能力的进展也是 OpenAI [Preparedness Framework](https://openai.com/index/updating-our-preparedness-framework/) 的重要内容。最初创建 Verified 基准时，我们试图解决原始评估中存在的问题——那些问题使得 [SWE-bench 数据集](https://arxiv.org/abs/2310.06770) 中的某些任务无法完成。 经过最初的飞跃，SWE-bench Verified 上的前沿进展已经放缓——过去6个月内从 74.9% [提高](https://llm-stats.com/benchmarks/swe-bench-verified) 到 80.9%。这引发了一个问题：余下的失败是反映了模型本身的局限，还是数据集本身的属性问题？ 在一项新分析中，我们发现 Verified 集合存在两个主要问题，表明该基准已不再适合在目前的性能水平上衡量前沿发布中的自主软件工程能力： 1. **测试拒绝正确解决方案：** 我们对数据集中模型经常无法解决的 27.6% 的子集进行了审计，发现至少有 59.4% 的审计问题存在有缺陷的测试用例，尽管我们在最初创建 SWE-bench Verified 时已尽力改进，但它们仍然拒绝了功能正确的提交。 2. **针对解决方案的训练：** 由于大型前沿模型可以从训练中学习信息，因此很重要的一点是，模型绝不能在其训练中接触到它们即将被评估的问题和解决方案。这就像在考试前把题目和答案分享给学生——他们未必会死记硬背，但看过答案的学生肯定比没看过的表现更好。SWE-bench 的问题来源于开源仓库，许多模型提供者会将这些仓库用于训练目的。在我们的分析中，我们发现所有接受测试的前沿模型都能够复现作为正确参考的人类编写的原始错误修复（称为 gold patch），或者逐字记忆某些任务的问题描述细节，这表明它们在训练过程中都至少接触过部分问题和解决方案。 **我们还发现，那些在训练中接触过问题的模型更有可能成功，因为她们拥有通过不明确的测试所需的额外信息。** 这意味着 SWE-bench Verified 上的改进不再反映模型在真实世界软件开发能力上的有意义提升。相反，它们越来越反映模型在训练时接触该基准的程度。这就是我们停止报告 SWE-bench Verified 分数的原因，我们也建议其他模型开发者也这么做。 我们正在构建新的、未受污染的评估，以更好地跟踪编码能力。我们认为这是更广泛研究界应该关注的重要领域。在拥有这些评估之前，OpenAI 建议报告 SWE-bench Pro 的结果。 --- 原始的 [SWE-bench](https://arxiv.org/abs/2310.06770) 评估发布于2023年。每个问题都来源于12个开源 Python 仓库中一个已解决的 GitHub issue，并配以对应的 pull request (PR)。为了判断模型生成的代码变更是否正确，每个问题都附带两组测试： - 在未修改的代码库上会失败、但在正确修复 issue 后应该通过的测试 - 在修复前后都通过的回归测试，以确保无关功能保持完整。 模型看不到测试。它只能根据原始的 issue 文本和修复前的仓库状态来生成代码变更。只有当应用代码变更后所有测试都通过时，才算通过一个问题。 我们发现该评估存在许多问题，可能导致模型能力被低估： - 某些单元测试过于具体或与任务不符，导致正确的修复可能被拒绝。 - 许多任务描述不够明确，可能导致多种有效的解释——而测试只覆盖其中一种。 - 根据环境设置（例如 Linux vs Windows，或 Python 版本），某些测试可能偶然失败。 我们在2024年创建了 [SWE-bench Verified](https://openai.com/index/introducing-swe-bench-verified/)，旨在解决这些问题。我们与软件工程专家合作，审查了1,699个 SWE-bench 问题，过滤掉存在这些问题的题目。每个问题由三位专家独立审查。这一审查过程最终产生了 SWE-bench Verified，一个包含500个精选问题的集合。 尽管 SWE-bench Verified 相比初始版本有了很大改进，但残余问题依然存在。我们对 OpenAI o3 在64次独立运行中未能稳定解决的138个 SWE-bench Verified 问题进行了审计。每个案例由至少六位经验丰富的软件工程师独立审查。如果某位专家标记了问题，则由额外团队重新验证。 我们发现，在这138个问题中，59.4% 的问题在测试设计和/或问题描述方面存在实质性缺陷，使得即使是最强大的模型或人类也难以甚至不可能解决。 - 35.5% 的审计任务包含严格的测试用例，这些测试强制执行特定的实现细节，导致许多功能正确的提交无效——我们称之为 **狭窄测试用例**。 - 18.8% 的审计任务包含检查问题描述中未指定额外功能的测试，我们称之为 **宽泛测试用例**。 - 剩下的5.1% 的任务存在不属于该分类的各种其他问题。 第一个失败模式的说明性例子是 [pylint-dev\_\_pylint-4551](https://github.com/pylint-dev/pylint/pull/4551)，其中 PR 引入了一个新函数 `get_annotation` 作为整体解决方案的一部分。这个函数名在问题描述中没有提及，但被测试直接导入。虽然某些模型可能会直觉地创建这样的函数，但严格来说，为了正确解决问题，并不需要实现一个具有这个具体名称的函数。许多有效的解决方案由于导入错误而无法通过测试。 宽泛测试用例的一个例子是 [sympy\_\_sympy-18199](https://github.com/sympy/sympy/pull/18199)。该任务来源于一个 PR，该 PR 解决了 `nthroot_mod` 函数的三个不同 issue，具体是 [#17373](https://github.com/sympy/sympy/issues/17373)、[#17377](https://github.com/sympy/sympy/issues/17377) 和 [#18212](https://github.com/sympy/sympy/issues/18212)。然而，SWE-bench Verified 任务的描述只涵盖了最后一个 issue [#18212](https://github.com/sympy/sympy/issues/18212)。这造成了不匹配：PR 的测试覆盖了全部三个 issue，而描述只详细说明了一个。在我们的运行中，模型通常能正确实现所描述的修复，随后却未能通过涉及另外两个 issue 实现的测试。 --- SWE-bench Verified 及其仓库（代码库和发布说明）都是开源的，并被广泛使用和讨论，这使得模型开发者很难避免污染。 我们首先在自己模型中遇到了污染迹象。例如，当 GPT‑5.2 解决了我们认定几乎不可能解决的31个任务时。在 [django\_\_django-14725](https://github.com/django/django/pull/14725) 中，测试要求一个特定的新参数 `edit_only`，而这个问题陈述并未明确要求该参数。在解题过程中，GPT‑5.2 在其思维链中显示出它了解详细说明代码变更的发布说明，并正确指出 `edit_only` 参数是在 Django 4.1 中引入的。 为了更广泛地评估污染的重要性，我们创建了一个自动化红队测试设置。对于每个 SWE-bench Verified 问题，我们让 GPT-5 去探测 GPT‑5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview 是否存在污染。选择这些模型是为了排除推理模型，但我们承认它们之间可能存在不小的能力差距。 为了探测污染，GPT-5 接收了：SWE-bench Verified 任务的 ID、描述、gold patch 和 PR 测试。在15轮交互中，我们允许 GPT-5 改变系统/开发者提示、用户提示、助手预填充以及不同的诱导策略。每轮之后，一个评判模型会标记出现了多少新颖的任务特定信息，每个响应都被标记为从“无”到“强”的污染程度。GPT-5 被允许根据前一轮调整策略，以迭代地恢复任务特定细节。对于每个强污染的示例，我们通过另一个评判模型验证 GPT-5 没有向目标模型泄露过多信息。最后，我们手动审查了组成本文转录的“强”示例。 以下是来自不同模型提供商的强污染示例。 给定任务描述的一小段，GPT‑5.2 输出了精确的 gold patch。特别是，它知道确切的类名和方法名，以及引入的新早期返回条件 `if username is None or password is None`。 Opus 不仅能够回忆起 PR 引入的精确4行功能变更，以及所涉及的具体文件名和方法，还能逐字引用属于 diff 的一部分的内联注释。 Gemini 3 Flash 在除了 ID 之外没有获得任何关于该任务的其他信息的情况下，能够逐字输出任务描述和 gold patch 的细节。这包括用于用户名验证的新正则表达式公式以及变更的精确行号。 --- 从这次对 SWE-bench Verified 的审计中，我们看到了评估设计的两条更广泛的经验教训。首先，从公开可用材料中提取的基准存在污染风险，训练数据的暴露可能会悄悄抬高分数。如果在基准构建中使用了公开爬取的数据，模型开发者应该进行额外的污染测试。公开发布的基准，甚至它们的解决方案，最终都可能进入训练数据。在数据集的发布方式（例如密码保护）和训练数据过滤（例如严格遵守 canary 字符串）方面都应格外小心。 其次，自动评分很难正确完成：完美的测试用例应该完全验证正确的功能，既对不重要的实现细节保持中立，又能抵御取巧的解决方案。这些问题本质上是复杂且难以解决的。发现这些问题需要多次大规模的人工标注活动。 我们已将这些发现纳入最近的评估工作中。在过去的几个月里，我们选择报告 SWE-Bench Pro 公开部分的结果。我们建议其他模型开发者也这样做。SWE-bench Pro 并不完美，但凭经验看，它似乎较少受到污染问题的影响。我们的污染管线发现了一些污染案例，但这些案例明显比 SWE-bench Verified 更少见且不那么严重，并且没有模型能够生成完整的逐字 gold patch。 我们将继续投资于原创的、私有的基准测试，并寻求业界和学术界的帮助，请他们也这样做。在 [GDPVal](https://openai.com/index/gdpval/) 中，任务由领域专家私人创建，降低了暴露风险，并且解决方案由经过培训的评审员进行整体评分。这种方法资源密集，但对于衡量真正的能力提升越来越必要。