0225- 退役与评测新范式

用户9970

用户3733

5月9日修改

今天看到 Olivia Watkins 和 Mia Glaese 去了 Tiago Forte 的播客。

Olivia Watkins 是 OpenAI Frontier Evals 团队成员，负责前沿能力评测；Mia Glaese 是 OpenAI 研究副总裁，领导 Codex、人类数据与对齐团队。她们同时参与 SWE-Bench Verified 的构建与审计，处在评测体系的第一线。​

这期播客总共录了 27 分钟，Olivia Watkins 和 Mia Glaese 谈到了 12 个有趣的观点：​

1、SWE-Bench Verified 曾是“北极星”编码基准，但现在进展停滞，基准已被“饱和+污染”，继续刷分已经不再代表真实能力提升。​

2、原版 SWE-Bench 的问题不在于任务“太难”，而在于问题设置不稳定：很多失败案例来自测试或题目本身有缺陷，而非模型能力不足。​

3、OpenAI 为 Verified 版本投入了接近百名工程师、多轮复核，才筛出 500 个更可用的任务，说明“真实世界编码评测”成本极高。​

4、开源仓库天然难以防污染，很多任务来自热门仓库，训练数据中不可避免地出现相似代码与历史版本，导致模型“凭记忆猜对”。​

5、污染不仅是“看过答案”，还包括模型推理中暴露的“未来版本细节”，比如模型能想到题目未给出的参数名，说明训练语料中出现过后续实现。​

6、深入复核发现，超过一半失败案例存在问题，多为“测试过窄”：测试只接受一种命名或实现细节，但题目并未要求该细节。​

7、因此“没过测试≠实现不合理”，SWE-Bench 在高分段开始测量“猜测试细节”的能力，而非编码能力本身。​

8、即使是领先模型，SWE-Bench Verified 的“真实上限”也难评估，OpenAI 在极难任务上观察到约 31 题已可通过，污染可能已让天花板提前到来。​

9、SWE-Bench Pro 的吸引力在于难度更高、任务更大、语言与仓库更多样，且在污染审计上显示更干净、更有“头部空间”。​

10、他们使用“污染审计代理”检测模型泄露：给出任务与补丁，引导模型暴露是否熟悉任务编号、答案或仓库细节，Verified 上出现多模型“复述答案”的迹象。​

11、未来理想的编码评测不仅要衡量“能否修 GitHub issue”，还要衡量设计品味、长期任务、可维护性等更贴近工程真实工作的维度。​

12、评测有两条路：人类专家高成本评判（如 GDP-Bench），或自动化测试低成本评判；前者更真实、后者更可比，但后者容易遗漏“是否值得合并”的关键标准。​

---

#01 SWE-Bench Verified 为什么退役​
主持人：你们发布的新文章里，核心观点是什么？​
嘉宾（Olivia）：SWE-Bench Verified 过去是衡量编码进步的北极星，但现在已被饱和和污染削弱，继续用它衡量进步已经不可靠。​

编辑补充：这里“饱和”指的是模型分数进入高位后，增量不再代表能力提升；“污染”则来自开源仓库与训练数据的重叠，模型可能不是“会写”，而是“记得”。​

主持人：你们怎么确认污染是真实存在的？​
嘉宾（Olivia）：我们看到模型能推断出题目没提到的参数或实现细节，像是记住了仓库更晚版本的实现，这种情况几乎不可能靠题目推理出来。​

#02 评测不是“错”，而是“太窄”​
主持人：是不是基准本身有问题？​
嘉宾（Olivia）：我们复核了模型难解的题目，超过一半存在测试过窄、描述不清或题目遗漏的问题，比如测试要求某个函数名，但题目没说必须这样命名。​

编辑补充：这意味着“没过测试”不等于“实现不好”，而是评测缺乏对多种合理解的包容度。高分段开始考“猜测试”，而不是考“能力”。​

#03 为什么转向 SWE-Bench Pro​
主持人：那替代方案是什么？为什么是 SWE-Bench Pro？​
嘉宾（Mia）：它更难、更大、更多样，任务时长有 1-4 小时甚至更长，语言与仓库覆盖更广，头部空间更大。​

主持人：污染问题会缓解吗？​
嘉宾（Mia）：我们用“污染审计代理”做过检验，在 Verified 上看到模型会复述答案或任务编号，但在 Pro 上只看到很轻微的熟悉迹象。​

#04 未来评测要测什么​
主持人：理想的编码评测应该怎么做？​
嘉宾（Mia）：不仅要测能不能修 issue，还要看设计品味、代码质量、可维护性，以及更长任务的完成能力。​

编辑补充：这会迫使评测走向两难：是走高成本的人类专家评审（像 GDP-Bench），还是坚持自动化测试的可比性。两条路线都要走，但需要更清晰的权衡标准。​

0225- 退役与评测新范式​