SWE-bench 兴衰记:一个代码基准是怎么被建起来、刷上去、又亲手关掉的

2024 年 8 月,OpenAI 联合 SWE-bench 原作者团队人工过滤出 500 道「质量可靠」的题目,命名为 SWE-bench Verified;2026 年初,还是 OpenAI,发布了《Why we no longer evaluate SWE-bench Verified》——审计发现无法稳定解出的题目里近六成有测试缺陷,而且用红队引导让三大厂商的旗舰模型全都复现出了「标准答案」。一个基准,发布方亲手建、亲手修、又亲手埋,前后不到两年。这条完整的兴衰曲线是研究「代码智能到底该怎么测」的最佳标本:它把基准评测的所有经典病灶——测试缺陷、数据污染、scaffold 干扰——都在真实世界里演示了一遍。

起点:把真实 GitHub issue 变成考场

SWE-bench 由普林斯顿 NLP 团队提出(arXiv:2310.06770,2023-10,ICLR 2024),设计思路在当时堪称惊艳:不用人造题,直接从 12 个流行 Python 仓库(Django、sympy、scikit-learn 等)的历史记录里抽出 2,294 个真实 GitHub issue,模型拿到仓库代码与 issue 描述,生成 patch,然后跑该 issue 对应 PR 里的测试——FAIL_TO_PASS 测试由失败转通过、且 PASS_TO_PASS 测试不被破坏,才算解出。这是第一个把「真实软件工程」搬进评测的基准,发布时最强模型 Claude 2 只解出 1.96%,作者自己微调的 SWE-Llama 也只有个位数成绩,进步空间看起来无限大。

Verified:一次人工质检,与它没治的病

全集很快暴露出质量问题:题目难度不可控、部分 issue 描述含糊、有的测试本身就是坏的。2024-08-13,OpenAI 与原作者合作推出 SWE-bench Verified:从全集抽 500 例,由 9 名 contractors 逐例复核、每例至少 3 名标注者把关,剔除描述欠明确、测试有故障、要求有歧义的题目。此后厂商官网报成绩,基本都用这 500 题。

但两次审计揭示了它的天花板。Epoch AI(2025-06)的分析:Verified 里 90% 的任务人类一小时能做完(39% 不超过 15 分钟)、87% 是 bug fix、单个仓库 Django 就占了近一半题目、前 5 个仓库合计超过 80%;抽验 40 道「无人解出」的题,14 道本身就是无效题。换句话说,Verified 饱和只证明一件事:模型会修中小型 Python 项目的 bug。而 OpenAI 在 2024 年发布 Verified 时其实就写明了警告——这些题目来自公开仓库,「很可能已被污染」。污染警告与基准同龄,只是当时没人当回事。

刷分时代:scaffold 决定一半分数

2024 到 2025 年,Verified 分数从 33% 一路刷到 80%。复盘这条曲线,有一半的涨幅与「模型变聪明」无关——与模型配套的 scaffold(agent 框架、工具编排、提示策略)影响巨大。把这个问题第一次摆上台面的正是 OpenAI 自己:2024 年的 Verified 发布文里给出过 Lite 子集上的对照——同一个 GPT-4,套简单 RAG scaffold 只有 2.7%,换成 CodeR 框架 28.3%,同模型分差 25.6 分。官方榜单后来的历史数据把差距拉得更夸张:同一个 Claude 3.5 Sonnet(2024-10 版),套 SWE-agent 得 33.6%,换 AgentScope 框架 15 个月后达到 63.4%——同模型分差近 30 分;GPT-4o 在不同 scaffold 下从 21.6% 到 38.8%;GPT-5 从 65.0% 到 74.4%。极端案例是 mini-SWE-agent:100 行 Python 的极简框架能拿 65%,说明 scaffold 的复杂度与分数并无线性关系,但「哪个 scaffold」确实重要。

评测口径的水同样很深:榜上至今存在 TTS(Bo8)/TTS(Bo16) 条目——多次采样取最优,单次 pass@1 和 best-of-16 放在同一张榜上;厂商自报分数与第三方独立复现的落差可达 17 分(如某模型自报 72–75%,独立复现 58.6%)。2024 年还有过一场著名的「Agentless 之争」:一个不用 agent 的三段式流水线(定位 → 修复 → 验证)配上 GPT-4o,成绩竟媲美甚至超过复杂的 agent scaffold,直接引发「解真实 issue 到底需不需要 agent」的行业争论。swebench.com 后来干脆把 Verified 榜拆成两条赛道:Agent(自定义 scaffold,团队提交)与 Bash Only(统一 mini-SWE-agent、官方运行)——后者的存在本身就是对「scaffold 干扰」的制度性承认。而一篇 2026 年 2 月更新到第三版的元研究《Dissecting the SWE-Bench Leaderboards》(arXiv:2506.17208)翻检了 Lite 与 Verified 榜共 80 种提交方案后给出的评价更扎心:许多方案架构与来源不明、缺乏文档约束,榜单的科学性远低于它的传播度。

三记重锤:审计、污染与「假修好」

第一锤来自发布方自己。 2026 年初 OpenAI 的弃用公告给出了最硬的数字:选 o3 在 64 次独立运行中无法稳定解出的 138 题(占 500 题的 27.6%),每题由至少 6 名工程师独立复核——至少 59.4% 存在测试缺陷:35.5% 是过窄测试(比如要求实现描述里根本没提到的函数名),18.8% 是过宽测试(gold patch 修了三个 issue,描述只写了一个)。第二锤是污染实锤。 同一篇公告里,OpenAI 用 GPT-5 对 GPT-5.2-Chat、Claude Opus 4.5、Gemini 3 Flash 做了 15 轮红队引导,三家全部复现出 gold patch 或逐字复述题目细节——「至少见过部分题目」从学术猜疑变成了官方结论。第三锤来自学术界。 普渡与微软的《The SWE-Bench Illusion》(arXiv:2506.12286)证明仅凭 issue 文本(不给代码库)就能以 76% 的准确率定位 bug 文件(同类非 SWE-bench 仓库只有 53%);Wang、Pradel 等人(arXiv:2503.15223)则发现 29.6% 被判「通过」的 patch 行为与标准答案发散,其中 27.3% 还做了超出必要的多余修改,合计让解决率虚高约 6.2 个百分点——「过了测试」和「修对了」是两件事。

榜单现状与继任者

截至 2026-10-08,swebench.com 官方榜的面貌:Agent 赛道第一是 Claude 4.5 Opus 搭两个不同 scaffold 的并列 79.20%(2025-12 提交),Gemini 3 Pro Preview 77.4%;Bash-Only 赛道(统一 scaffold、官方运行,2026-02 批次)第一是 Claude 4.5 Opus (high) 76.80%(单题成本 $0.75),Gemini 3 Flash 75.80%($0.36),MiniMax M2.5 同为 75.80% 但单题只要 $0.07。历史锚点放进同一坐标:2024-11 的 Claude 3.5 Sonnet (new) 是 48.80%,GPT-4o 是 21.62%——两年翻了一倍半还多。需要提醒的是,个别第三方榜单上「95%+」的成绩用的是自建采样口径(如多次采样加自定工具预算),与官方统一环境不可比,引用时务必带口径。

家族内部也在扩展边界:SWE-bench Multilingual(300 例、42 个仓库、9 种编程语言)与 Multimodal(17 个 JavaScript 仓库,每题带 UI 截图)把语言与形态的覆盖补上;SWE-Gym 把同一批任务做成了开源训练环境(评测之外供 RL/SFT 使用)。真正的继任者们各自补一块短板:SWE-bench Pro(Scale AI,2025-09)把任务规模拉到平均改 107.4 行代码、跨 4.1 个文件(Verified 平均约 1 个文件),1,865 例里 731 例用 GPL 等 copyleft 许可证「法律性防污染」、276 例来自企业私有仓库——发布时 GPT-5 与 Claude Opus 4.1 在公共集都只有 23% 上下,与 Verified 上的 70%+ 落差近三倍;到 2026 年春,第三方转述的 Pro 榜头部也才 59%(榜首 GPT-5.4 xHigh,转引自独立评测博客,官方榜页面未能直接抓取)——这条更陡的曲线刚刚开始爬。SWE-Lancer(OpenAI,2025-02)拿 Upwork 真实任务按「赚到的美元」计分;GDPVal(OpenAI,2025-09)题目私有、专家盲评;Terminal-Bench、ProgramBench(2026-05,从二进制重建程序,榜首仅 18.5%)把评测推向更长、更冷启动的方向。

厂商自报成绩的「脚注文化」也是这段历史的注脚:OpenAI 在弃用公告里引用的官方口径是「过去六个月从 74.9% 涨到 80.9%」(前者的 GPT-5、后者的 Claude Opus 4.5 自报成绩);Anthropic 为 Sonnet 4.5 报 77.2% 时特意注明「10 次试验平均、无 test-time compute」,而常被一起引用的 82.0% 需要并行 test-time compute 才能达成——同一个模型,两种口径,两个数字。这些脚注比分数本身更能说明这个基准的测量精度。

怎么读一个代码基准分数

把 SWE-bench 三年的教训压缩成读数守则:一看 scaffold 口径——同模型不同框架能差 30 分,只比较「同 harness 下的数字」(官方 Bash-Only 赛道或 vals.ai 这类统一复现);二看采样次数——pass@1 与 best-of-16 是两个物种;三看自报还是复现——厂商公告的分数与自己 harness 跑出来的分数之间隔着几十个工程细节;四看时间窗——发布日期之前就公开的仓库,都该默认有污染风险,红队引导出原答案已是可复现的测试手段;五看任务画像——「87% 是 bug fix、90% 一小时内」的基准就算 100% 饱和,说的也不是「会写软件」,而是「会修小 bug」。

结语

SWE-bench 的三年是一堂完整的评测方法论公开课:它证明了「真实 issue + 真实测试」的设计远胜人造题,也证明了再真实的数据集也逃不过 Goodhart 定律——当分数变成营销指标,测试缺陷、scaffold 优化与记忆化就会从四面八方涌来。OpenAI 那篇弃用公告其实是给整个行业立了个样板:承认基准失效、公开审计数据、推荐替代方案,比守着一个注水的数字体面得多。Humanity's Last Exam 上的 deep research 分数一年半里从 26.6% 翻到 60% 以上——同样的剧本已经在重演,区别只是这次我们看过一遍了。

参考资料

← 返回资讯列表

读者留言

COMMENTS 暂无
仅本站原创文章开放留言 · 请勿留下手机号、邮箱等个人信息

还没有留言,来说第一句?