修好的考卷也会泄题：SWE-bench Verified 为什么失效
June 24, 2026 · 8:14 AM

修好的考卷也会泄题：SWE-bench Verified 为什么失效

这篇长文从 SWE-bench Verified 的创建、审计和被弃用切入，解释 AI 基准为什么会同时被坏测试压低、被训练污染抬高、被饱和压扁。读者将获得一套更稳妥的读榜方法：先检查题源、冻结时间、样本量、跨分布验证和污染审计，再相信分数。

实证漫游长文
实证漫游长文@brownsun
2024 年 8 月，OpenAI 把 SWE-bench 修了一遍：找专业软件工程师过滤掉不公平、含糊、环境难复现的任务，留下 500 个看起来更可靠的 GitHub issue 修复题。2026 年 2 月，OpenAI 又发文说，SWE-bench Verified 已经不适合衡量前沿模型的编码能力，建议停止报告这个分数。中间只隔了 18 个月。12
这不是一场简单的「榜单翻车」。SWE-bench Verified 的失效更像一台测量仪器的老化记录：先是原始标尺太粗，修过之后变得更准；模型、训练数据、社区讨论和排行榜压力继续涌入，标尺又被测量对象反过来改造。最后，分数还在变，分数含义已经换了。

一张考卷的两次验尸

原始 SWE-bench 的设想很漂亮。研究者从 12 个流行 Python 开源仓库里抓取已解决的 GitHub issue 与对应 pull request，构造出 2,294 个任务；模型看到 issue 文本和修复前的代码库，提交补丁，系统运行「修复前失败、修复后通过」的测试来判定是否解决问题。SWE-bench 官网记录，2023 年发布时，一个 RAG（检索增强生成）基线只得到 1.96%。3
这个设计避开了传统编程题的玩具感：任务来自真实仓库，答案不是一段函数，而是能让测试通过的补丁。问题也藏在这里。真实 issue 往往含糊，PR 里的测试有时检验了 issue 没说清的实现细节，运行环境还可能让无关测试失败。OpenAI 2024 年发布 Verified 版本时说，他们让 93 名有 Python 经验的软件开发者审阅 1,699 个随机样本，每个样本由 3 人标注；最终 68.3% 的样本因描述不足、测试不公平或其他问题被过滤，只留下 500 个样本。1
这组数字来自 SWE-bench 官网与 OpenAI 两次公告：2,294 个原始任务、500 个 Verified 任务，以及 2026 年审计中高失败样本的 59.4% 实质问题率。312
Loading stats card…
OpenAI 说，SWE-bench Verified 上前沿模型的进步在最近 6 个月只从 74.9% 到 80.9%；他们审计了 o3 在 64 次独立运行中经常失败的 138 个任务，发现 59.4% 存在实质性测试或描述问题。过窄测试占 35.5%，会拒绝功能上正确但实现方式不同的补丁；过宽测试占 18.8%，会检查问题描述没有要求的额外功能；其他问题占 5.1%。2
Loading chart…
这张图只覆盖 OpenAI 审计的 138 个高失败率样本，不代表整个 500 题集合的随机估计。它足以说明另一件事：当模型能力接近测试上限时，以前可以忽略的测试瑕疵会变成主要误差源。60 分模型被坏题扣掉几分，读者可能只看到「还很弱」；80 分模型被坏题挡住，排行榜就会把测试缺陷误读成能力边界。

污染不是一句「模型背题了」

SWE-bench Verified 的第二个问题更难处理：题目、仓库、PR、测试、讨论和榜单都在公开互联网上。大型模型的训练语料又大量来自公开网页和代码仓库。数据污染最窄的定义是训练集与测试集有重叠；近年的综述把它扩展成训练、微调、部署后互动与基准本身多阶段泄漏的集合，影响包括分数虚高、研究结论失真和不同任务上的污染效应差异。4
「背题」这个说法太粗。一个模型未必逐字记住答案，也可能记住仓库结构、历史 issue 的文件路径、PR 讨论里的实现名、release notes 中某个参数的引入时间。SWE-bench 这种任务尤其容易被这种半记忆污染：模型不需要背完整补丁，只要知道哪几个文件、函数名或隐藏测试偏好的实现细节，成功率就会显著上升。
2025 年一篇题为 The SWE-Bench Illusion 的论文设计了一个切中要害的对照实验：只给模型 issue 描述和仓库名，不给代码库结构，让模型猜需要修改的文件路径。按常识，这应该很难；如果没有仓库树和代码上下文，issue 文本通常不足以精确定位文件。论文报告，多个前沿模型在 SWE-bench Verified 上能达到 60% 到 76% 的文件路径识别准确率；面对 SWE-bench 外部仓库任务时，准确率降到 53% 以下。5
污染、饱和与可被利用的测试设计对应三类评估失真示意图
污染、饱和与可被利用的测试设计对应三类评估失真示意图
自制示意图，不指代任何真实数据集。
这个实验不能证明每个高分解法都是记忆。它证明了更有限、也更麻烦的事实：在某些公开基准上，模型携带的背景知识已经强到足以完成一个本应依赖现场上下文的子任务。评估者此时很难把「会修 bug」和「熟悉这批历史 bug」拆开。
OpenAI 2026 年的红队结果给了另一个角度。他们让 GPT-5 以任务 ID、描述、gold patch 和 PR 测试为线索，尝试诱导 GPT-5.2-Chat、Claude Opus 4.5 与 Gemini 3 Flash Preview 露出任务特异性记忆；文中展示的例子里，模型能输出接近原始 gold patch 的代码修改、文件路径、注释甚至正则表达式。OpenAI 因此说，所有被测前沿模型都至少见过部分问题或解法。2
这会产生一个反直觉后果：测试越真实，越接近互联网上真实开发活动，越可能进入未来模型的训练语料。玩具题不真实，但容易封存；真实 issue 有效度更高，却天然可爬、可讨论、可复现、可被训练过程吸收。

基准老化比作弊更普遍

即使没有明确泄题，静态基准也会老化。2026 年一项关于基准饱和的系统研究分析了 60 个文本型 LLM 基准，定义「饱和」为顶尖模型之间失去可靠区分能力，并用排行榜不确定性构造饱和指数。研究发现，60 个基准中有 29 个达到高或很高饱和，14 个达到很高饱和；基准年龄和测试集规模比「公开还是私有」「闭卷还是生成」等常见标签更能解释饱和差异。6
这项研究有一个不合直觉的结果：私有测试集并没有显示出显著保护效果。公开与私有基准的饱和分布相近；生成式任务也没有系统性地比选择题更抗饱和。较大的测试集反而与较低饱和相关，因为样本多一点，统计分辨率高一点，顶尖模型之间的小差异不容易被噪声淹没。6
把 SWE-bench Verified 放进这个框架，问题就不只是「有没有污染」。它同时遇到三种老化：
失真来源在 SWE-bench Verified 里的表现分数会怎样误导
测试瑕疵部分任务的测试过窄、过宽或描述不充分，OpenAI 审计的高失败样本中 59.4% 有实质问题。2低估模型能力，把正确但不同的解法判错。
训练污染题目来自公开仓库，模型可能见过 issue、PR、补丁或相关 release notes。2高估模型能力，把熟悉历史题误读成一般软件工程能力。
饱和压缩前沿模型成绩贴近上限，近 6 个月只从 74.9% 到 80.9%。2排行榜差异看似精细，实际可能落在测试误差与样本偏差内。
这三类误差方向不同。坏测试可能压低分数，污染可能抬高分数，饱和会压扁差异。它们同时存在时，一个总分很难回答读者最关心的问题：这个模型换到我的仓库、我的 bug、我的约束下，会不会更可靠？

好基准开始像临床试验

更稳的评估不会靠一个新名字解决。LiveCodeBench 提供了一条思路：持续从 LeetCode、AtCoder、CodeForces 等比赛平台收集新题，论文摘要称它在 2024 年版本中包含 2023 年 5 月到 2024 年 5 月发布的 400 道高质量题，并覆盖代码生成、自修复、执行与测试输出预测等场景。7 动态收题可以降低旧题进入训练语料后的污染风险，但不能自动解决难度漂移、题型偏差和社区过拟合。
OpenAI 自己转向更昂贵的做法。GDPval 由有经验的行业人士编写和审阅任务，覆盖 44 个职业、1,320 个专门任务；每个任务平均经过 5 轮专家审查，交付物包括文档、幻灯片、图纸、表格和多媒体。8 这类评估更接近临床试验：题目来源、样本选择、评分者盲评、审查流程和局限性都要记录。代价也像临床试验一样高，扩展慢，复现难，更新成本重。
一个可用的基准生态大概需要分层，而不是寻找单一圣杯：
  • 快速公开基准适合做回归测试，告诉开发者新模型有没有明显退步。
  • 持续更新的 live benchmark 适合追踪短期能力变化，但必须监控题源漂移。
  • 私有专家任务适合估计高价值能力，最好伴随盲评、样本量、失败案例和置信区间。
  • 事后污染审计要成为常规动作，而不是榜单崩掉之后的补救。
这些层次不能互相替代。公开题的好处是可复核，坏处是可训练；私有题的好处是抗污染，坏处是外部难以审计。评估体系只能在这两种风险之间做工程权衡。

读 AI 分数时，先问五个问题

SWE-bench Verified 的教训适用于所有 AI 榜单。看到一个新模型在某基准上领先 3 个百分点，先别急着把它翻译成产品能力。更可靠的读法是把分数当成仪器读数，先检查仪器。
  1. 题目什么时候冻结？ 冻结越久，进入训练语料、论坛讨论和优化循环的概率越高。
  2. 测试是否测到目标能力？ 如果评分器要求某个隐藏实现细节，分数会惩罚合理替代解。
  3. 样本量能否区分顶尖模型？ 500 题听起来不少；当前沿模型只差几个百分点，误差条和任务相关性就会变得很重要。
  4. 是否有跨分布验证？ 同一批仓库、同一种题型、同一套脚手架上的高分，不等于换语言、换项目、换约束后仍然高分。
  5. 有没有污染审计？ 只说「我们去重了」不够。需要说明去重口径、训练语料可见性、红队诱导结果和可疑样本处理方式。
最危险的误读不是相信某个分数完全准确，而是忘了分数也有生命周期。一个基准刚发布时可能是好仪器，几年后变成训练材料，再过一段时间变成营销语言。它仍然有用，只是用途变了：从衡量前沿能力，退化为检查系统是否还能做旧题。
SWE-bench Verified 的结局反而给了一个健康信号。OpenAI 当年参与修补它，后来又公开停用它；同一条证据链同时记录了改进和失效。AI 评估真正稀缺的不是新榜单，而是愿意承认旧榜单何时该退休的制度。

References

  1. 1Introducing SWE-bench Verified
  2. 2Why SWE-bench Verified no longer measures frontier coding capabilities
  3. 3SWE-bench
  4. 4A Survey on Data Contamination for Large Language Models
  5. 5The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason
  6. 6When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation
  7. 7LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code
  8. 8Measuring the performance of our models on real-world tasks

Related content

Add more perspectives or context around this Post.

  • Sign in to comment.