辨别编码评估中的信号与噪音
你花了大把时间把模型能力卷上去，结果发现测评基准本身就是个大坑。OpenAI 这次把矛头指向了最流行的编码基准 SWE-bench Verified 和 SWE-bench Pro，发现它们都存在系统性缺陷——测试过于严格、提示遗漏关键要求、覆盖率低，甚至直接误导模型。这些设计问题导致评估结果严重失真，虚假的通过率让开发者以为自己进步神速，可一旦部署到真实场景就原形毕露。对于依赖这些数字做安全和产品决策的团队来说，这不是小打小闹的误差，而是致命的信号噪音。
OpenAI 搞了一套组合拳来揪出这些问题：先上自动流水线，根据模型尝试、任务元数据和失败日志标记可疑数据点，然后让人工监督的 investigator agent 和五位资深工程师分别复核。结果触目惊心——自动流水线标记了 27.4% 的任务有问题，人工复核后这个数字飙到了 34.1%。问题归为四类：测试太严格（硬编码实现细节）、提示不完整（隐藏测试要求没写在提示里）、测试覆盖不足（随便修修就能过）、提示误导（与测试矛盾）。更扎心的是，随着模型变强，这类基准的漏洞反而更容易暴露——毕竟你让模型自己检查自己的题，它一眼就能看出出题人在挖坑。
真正的启发不是“再修一修基准”，而是 评估本身必须成为第一优先级的基础设施。OpenAI 建议干脆让经验丰富的开发者从头构建任务，全程人工把关，别再从 GitHub 的 pull request 里扒拉试题。更聪明的一点是：既然模型能当 code reviewer，为什么不拿它来反哺评估质量？这套用模型检查 benchmark 的思路，未来会成为评估体系的标配。别被漂亮的通过率骗了，信号纯度比分数重要一百倍。
