Why SWE-bench Verified No Longer Measures Frontier Coding Capabilities
原标题： Why SWE-bench Verified no longer measures frontier coding capabilities 中文标题： 为什么 SWE-bench Verified 不再能衡量前沿编码能力
发布日期： 2026年2月23日 作者： OpenAI 原文链接： https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
一句话摘要
OpenAI 通过系统审计发现 SWE-bench Verified 存在两大致命缺陷——59.4% 的审计任务包含有缺陷的测试用例，且所有主流前沿模型均存在训练数据污染——因此建议业界停止使用该基准，转向 SWE-bench Pro。
完整核心内容翻译
背景
自 2024 年 8 月首次发布以来，SWE-bench Verified 已被业界广泛用于衡量模型在自主软件工程任务上的进展。在发布后，它提供了强有力的能力进步信号，成为前沿模型发布中报告的标准指标。
然而在初始飞跃之后，SWE-bench Verified 上的最先进进展已趋于放缓——在过去 6 个月中仅从 74.9% 提升至 80.9%。这引出了一个问题：剩余的失败反映的是模型局限性，还是数据集本身的属性？
在新的分析中，OpenAI 发现了两个主要问题，表明该基准不再适合衡量当前性能水平下的前沿自主软件工程能力：
问题一：测试用例拒绝正确解决方案
OpenAI 对 o3 在 64 次独立运行中经常未能解决的 138 个 SWE-bench Verified 问题（占数据集的 27.6%）进行了审计。每个案例由至少六位经验丰富的软件工程师独立审查。如果专家标记了问题，会由额外团队重新验证。
审计发现，59.4% 的 138 个问题包含测试设计和/或问题描述中的实质性问题，使得即使是最强大的模型或人类也极难或不可能解决：
- 35.5% 的审计任务拥有过于严格的测试用例（narrow test cases），强制执行特定实现细节，拒绝了许多功能正确的提交。
- 18.8% 的审计任务拥有过于宽泛的测试用例（wide test cases），检查问题描述中未指定的额外功能。
- 剩余 5.1% 的任务有其他杂项问题。
过于严格测试的例子
在 pylint-dev__pylint-4551 中，PR 引入了一个新函数 get_annotation 作为解决方案的一部分。这个函数名在问题描述中未被提及，但测试直接导入它。虽然某些模型可能凭直觉创建这样的函数，但正确解决问题并不严格要求实现一个具有此特定名称的函数。许多有效的解决方案因导入错误而未通过测试。
过于宽泛测试的例子
在 sympy__sympy-18199 中，任务源自一个解决了三个不同问题（#17373、#17377 和 #18212）的 PR，但 SWE-bench Verified 任务的描述只涵盖了最后一个问题 #18212。这造成了不匹配：PR 测试覆盖所有三个问题，而描述只详述了一个。在实际运行中，模型通常正确实现了描述的修复，然后在覆盖其他两个问题的测试上失败。
问题二：训练数据污染
SWE-bench Verified 和相关仓库（代码库和发布说明）都是开源的且被广泛使用和讨论，这使得模型开发者很难避免污染。
OpenAI 首先在自己的模型中发现了污染迹象。例如，当 GPT-5.2 解决了 31 个被认为几乎不可能解决的任务时。在 django__django-14725 中，测试要求一个特定的新参数 edit_only，这在问题描述中并未明确要求。GPT-5.2 在其思维链中展示了它拥有关于发布说明的信息，并正确识别出 edit_only 参数是在 Django 4.1 中引入的。
自动化红队测试揭示的跨厂商污染
为更广泛地评估污染的严重性，OpenAI 创建了一个自动化红队测试设置。对于每个 SWE-bench Verified 问题，使用 GPT-5 对 GPT-5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview 进行污染探测。
在 15 轮对话中，GPT-5 可以变化系统/开发者提示、用户提示和助手预填充及不同的诱导策略。
GPT-5.2 的污染示例： 给定任务描述的简短片段后，GPT-5.2 输出了精确的 gold patch（标准修复补丁），包括确切的类名和方法名，以及引入的新早期返回条件。
Claude Opus 4.5 的污染示例： 同样能够在给定最少提示的情况下再现特定的实现细节。
Gemini 3 Flash 的污染示例： 也展示了对训练数据中 SWE-bench 解决方案的记忆。
研究还发现，在训练期间接触过问题的模型更有可能成功，因为它们拥有通过未充分指定的测试所需的额外信息。
讨论
这意味着 SWE-bench Verified 上的改进不再反映模型真实世界软件开发能力的有意义进步。相反，它们越来越反映模型在训练时接触了多少基准测试内容。这就是 OpenAI 停止报告 SWE-bench Verified 分数的原因，并建议其他模型开发者也这样做。
OpenAI 正在构建新的、未受污染的评估来更好地追踪编码能力，并认为这是更广泛研究社区需要关注的重要领域。在此之前，OpenAI 推荐报告 SWE-bench Pro 的结果。
技术要点
测试设计缺陷的系统分类： 将有缺陷的测试分为"过于严格"（强制特定实现细节，35.5%）和"过于宽泛"（测试超出问题描述范围的功能，18.8%）两类，共覆盖 59.4% 的审计任务。
跨厂商污染的自动化检测方法： 使用 GPT-5 作为红队探测器，通过 15 轮自适应对话策略来诱导目标模型暴露训练数据中的 SWE-bench 信息，并通过裁判模型验证污染严重性。
污染对评估结果的系统性影响： 接触过训练数据的模型不仅能记忆答案，更能利用这些额外信息通过那些问题描述不充分的测试——这两个缺陷相互放大。
基准测试退化的生命周期： SWE-bench Verified 从有价值的评估工具退化为被博弈的指标，印证了 Goodhart 定律在 AI 评估领域的体现。
推荐的替代方案： OpenAI 推荐 SWE-bench Pro 作为当前的替代基准，同时正在开发新的未受污染评估体系。
深度解读
这篇文章不仅仅是关于一个基准测试的技术报告——它揭示了 AI 评估领域一个深层次的结构性挑战。
污染问题的普遍性令人警醒。 文章明确指出，不仅 OpenAI 自己的模型存在污染，Claude Opus 4.5 和 Gemini 3 Flash 也同样如此。这表明在大规模预训练的时代，基于公开数据构建的基准测试面临着几乎不可避免的污染风险。当基准测试的解决方案存在于 GitHub 等公开平台上时，任何使用互联网数据进行训练的模型都可能"见过答案"。
两个缺陷的相互放大效应尤为值得关注。 过于严格或过于宽泛的测试意味着模型需要超出问题描述的信息才能通过——而污染恰好提供了这些额外信息。这创造了一个悖论：受污染的模型反而在有缺陷的基准上表现更好，而未受污染的模型则被不公平地惩罚。
Goodhart 定律的经典案例。 "当一个度量标准成为目标时，它就不再是一个好的度量标准。" SWE-bench Verified 的兴衰完美地例证了这一点。随着它成为模型发布时的关键指标，围绕它的优化（包括无意的数据污染）侵蚀了它作为真实能力衡量标准的价值。
OpenAI 选择公开这一发现并率先停止报告该指标，展示了一种值得赞赏的学术诚实。然而，这也引发了一个更根本的问题：在模型训练数据集越来越庞大的今天，我们如何构建真正"防污染"的基准测试？ SWE-bench Pro 是否也会面临同样的命运？
延伸思考
基准测试的保鲜期： 在 AI 快速发展的今天，是否所有公开基准测试都有一个"有效期"？如何设计持续有效的评估体系——是定期更新问题、使用私有测试集，还是彻底改变评估范式？
污染检测作为标准流程： 本文展示的自动化污染探测方法是否应该成为所有基准测试报告的标准组成部分？这将如何改变模型评估的实践？
闭源评估的回归： 如果公开基准测试不可避免地会被污染，是否意味着行业需要更多的闭源、受控的评估？这与学术界对透明性和可重复性的追求如何平衡？
对 AI 能力叙事的影响： 如果过去几个月的 SWE-bench 进步部分归因于污染而非真实能力提升，这对我们理解 AI 编码能力的实际进展有何影响？行业是否高估了当前模型的自主软件工程能力？
本文为 OpenAI 研究博客的深度中文解读，仅供学习参考。