OpenAI 退出 SWE-Bench | 公开数据训练价值归零？

一、SWE-bench 长什么样

1. 该修好的测试：Django 开发者当年修这个 bug 时新加的测试，原来不通过，打上 AI 的补丁后必须通过。
2. 不能弄坏的测试：仓库里原有的相关测试，打补丁前通过，打补丁后也必须通过。

OpenAI 用一个模型去「审问」其他模型：只给题目编号或一小段描述，看它们能不能说出不该知道的东西。结果，所有被测的前沿模型都至少在部分题上露了馅：

• 只给 django__django-11099 这个编号，Gemini 3 Flash 就复述出了题目内容，还写出了标准答案里那处正则改动。
• Claude Opus 4.5 在一道天文学库 Astropy 的题上，准确说出了要改的文件路径、函数名，甚至代码里的一行注释。
• GPT-5.2 在一道 Django 题上，说出了题目描述里根本没提到的一个参数名，依据是它「记得」Django 的版本发布说明。

这不难理解。SWE-bench 的题，本来就是 GitHub 上公开的 bug 报告和修复记录。这些内容在变成考题之前，早就躺在互联网上：被代码托管平台收录，被技术博客讨论，被各种数据集转载。模型在预训练时把整个公开互联网读一遍，等于考前把参考答案看了好几遍。

上一篇我们讲 Terminal-Bench 时提到过：公开的考卷是行业共用的尺子，也因此始终面临被抓进训练数据的风险。 SWE-bench 是这个风险最典型的样本，它的题甚至在成为考题之前就已经公开了。

更麻烦的是，污染还会和第二个死因叠加。OpenAI 发现，「见过」原题的模型，更容易通过那些测试写得有问题的题：它不需要读懂题目，只需要记得当年的补丁长什么样。

四、死因二：题本身就是坏的

OpenAI 挑出 Verified 里 138 道题：它自家的 o3 模型跑了 64 次都没能稳定做对。每道题至少由 6 位资深工程师复查。结论是：59.4% 的题本身有实质性问题。

问题主要分两类：

1. 测试太窄（35.5%）：测试会拒绝功能上完全正确的解法。比如一道 pylint 的题，测试里直接调用了一个函数名，可题目描述从头到尾没提过这个名字。你修好了 bug，但函数没起成那个名字，照样不通过。
2. 测试太宽（18.8%）：测试检查了题目没要求的东西。比如一道 SymPy 的题，原始的修复一次解决了三个问题，题目描述却只提了其中一个。

7 月对 Pro 的审查，用的是 AI 加人的方法：先用 Codex 驱动的审查代理逐题排查，再请 5 位工程师独立复核。代理判定 27.4% 的公开题有问题，人工判定 34.1%，取中间约 30%。

问题类型和 Verified 几乎一模一样：测试要求了题目没写的实现细节，题目漏写了测试要检查的要求，测试覆盖不全让半成品也能通过，描述把人往错误的方向引。

OpenAI 举了一个例子：一道来自开源图书馆项目 OpenLibrary 的题，题目里给的示例格式是行首空一格，隐藏的测试却要求空两格。严格按题目做的模型，反而会失败。 这时分数反映的不是能力，而是运气。

五、SWE-Bench Pro 也没躲过

Pro 并不是没有吸取教训。它的设计处处是针对 Verified 的：

• 防污染：公开题只选用 GPL 许可证的仓库（选这类「传染性」许可证，是为了降低被收进训练数据的可能），另有 858 道题完全不公开，还有 276 道来自创业公司的私有代码库。
• 防模糊：每道题都经过三轮人工处理：澄清题意、补充要求、验证测试。

防污染确实起了作用：OpenAI 在 2 月的文章里说，没有任何模型能完整复现 Pro 公开题的标准补丁。可半年后，它还是被判了约 30% 的坏题。

问题出在题的来源上。Pro 和 Verified 一样，题目仍然是从真实的代码提交里「挖」出来的。而一段真实的开发历史，天然不是一道合格的考题：

1. Bug 报告是写给维护者的，不是写给考生的。 它默认读者了解项目的来龙去脉，很多关键信息藏在讨论区、代码评审，甚至开发者的脑子里。
2. 测试是为那一次具体的修改写的，不是为判分写的。 开发者写测试，是为了确认「我这个改法」没问题，所以测试天然会贴着他自己的实现细节，比如函数名、格式、顺序。换一种同样正确的写法，测试就可能不认。
3. 一次提交常常不只干一件事。 顺手修了别的问题、重构了旁边的代码，测试里就会多出题目没交代的要求。

人工复核能修掉一部分问题，但修不掉这个根本的错位：你是在把别人的工作记录，硬改成一张考卷。

所以 OpenAI 7 月那篇文章的结论很明确：与其继续从代码提交里挖题，不如请有经验的开发者从零设计新的评测，从一开始就按考题的标准来写题目和测试。它在 2 月就点名过的方向，也是同一个思路：比如 GDPval，题目由专业人士私下原创、由受过训练的评审打分。

六、下一代考卷：从「挖」到「造」

把三代 SWE-bench 的兴衰连起来看，变化的不只是难度，而是出题的方式：

• 挖题：成本几乎为零，规模大，来自真实世界；但题目公开得比考试还早，测试也不是为判分写的。
• 造题：每道题要资深从业者花几个小时甚至几天，从任务描述、交付要求到判分规则全部原创，不公开或延迟公开；成本高，但干净，判得准。

我们拆过的 Terminal-Bench，走的就是「造」的路线：每道题由专家原创，带参考解法和专门写的测试，题目元数据里标着专家完成时间。即便如此，它也被审出了判分漏洞。可见造题这件事，没有捷径可走。

这背后是一个越来越清楚的趋势：模型越强，好考题越贵。 能从公开世界里免费挖到的题，要么已经被背下来了，要么本来就不够格当考题。剩下的路，只有找真正懂行的人，一道一道地造。

这对国内也一样。如果你在看一份模型发布报告，看到它还在用 SWE-bench Verified 的分数证明自己「编程第一」，现在可以多问一句：这个分数，测的是能力，还是记忆？

七、谁来造题？

造一道合格的编程考题，需要的不是会刷题的人，而是在真实项目里写过、修过、评审过代码的人：他知道一个需求怎么写才不会被误读，知道测试怎么写才不会只认一种写法，也知道哪些「顺手的改动」不该出现在题里。

这正是专家数据最核心的价值：不是做题，而是定义什么叫做对。 Relia 在做的，就是找到这样的人，用他们真实的作品验证水平，再组织他们出题、判分、审题。

下一篇，我们分析「众包专家出题」的考试：号称「人类最后的考试」的 HLE。它把这个问题推向了另一个极端：当出题的是上千位专家，题目的对错又由谁来保证？

Relia Lab｜Benchmark and expert data for frontier AI.

Relia Lab 是 Relia 的评测与专家数据实验室，我们正在招募出题人的方向：

代码评测：软件工程、系统运维、安全、Agent 开发

科研评测：理工科研究、实验设计、论文与研究想法

3D 评测：3D 生成、建模与渲染、空间理解

产品评测：产品设计、前端与 UI、交互体验、用户研究

工业评测：工业设计、制造工艺、CAD 与仿真

量化评测：因子与策略研究、回测与风险、交易系统

🙋行业专家：后台回复「出题」，了解出题人计划并报名

🏢 AI 团队：后台回复「合作」，定制 Benchmark、专家数据与RL环境