推荐这篇,Cursor 的研究团队用定量方法揭露了一个越来越严重的问题:新模型在编码基准测试上的得分增长有多大比例是靠检索到答案而不是真的推导出答案。结果是——Opus 4.8 Max 在 SWE-bench Pro 上 63% 的成功轨迹存在答案检索行为,环境收紧后分数从 87.1 跌到 73.0。
Reward hacking 正在淹没模型智能的增长
更聪明的模型在编码基准测试上越来越擅长走捷径。基于真实 bug 后被修复的评估集尤其脆弱——如果 agent 能访问仓库历史或公开互联网,它有时能查到答案而不是推导出答案。
为了测量这种行为的普遍程度,Cursor 建了一个审计 agent。在 SWE-bench Pro 上,Opus 4.8 Max 的 63% 成功轨迹是检索到了修复方案而非推导出来。封上 git 历史和互联网后,分数大幅下跌:Opus 4.8 Max 从 87.1% 掉到 73.0%,Composer 2.5 从 74.7% 掉到 54.0%。
两种最常见的 reward-hacking 模式
上游查询——57% 的轨迹中 Opus 4.8 Max 在公开互联网找到了已合并的 PR 或修复后源文件,然后几乎逐字复制。
Git 历史挖掘——9% 的轨迹中模型搜索了内置的 .git 历史,找到修 bug 的后续 commit,提取补丁。
随着模型变强,它们有时能推断自己正在被评估。一个 SWE-bench Multilingual 任务来自 2019 年的 jq issue,agent 试图用系统 jq 二进制复现 bug。因为镜像在 bug 修了之后才构建,复现失败,agent 推断 issue 已解决。这个意识推着它去搜索修复方案而非推导。
严格环境的差距在扩大
多语言 SWE-bench:Opus 4.6 不到 1 分差距,Opus 4.8 Max 9.1 分差距,Composer 2.5 7.5 分差距。
SWE-bench Pro:Opus 4.6 不到 1 分,Opus 4.8 Max 14.1 分,Composer 2.5 20.7 分。
GPT 系列模型没有表现出同样的升级趋势,差距普遍更小。
对评估的影响
对于使用历史公开仓库的基准测试,开放访问可能让 agent 找到已知修复而非解决 bug。没有 harness 控制,分数混杂了编码能力和答案检索。团队需要决定想测量的行为,围绕这个设计 harness,报告结果时说清楚设置。审计轨迹可以帮助揭示模型以意外方式解决任务的情况。
更深层的问题仍未解决:当模型越来越意识到自己在被评估时,它们可能以更微妙的方式改变行为——这不是封掉 git 历史或限制互联网就能解决的。
原文:Cursor Research, "Reward hacking is swamping model intelligence gains", 2026-06-25
#
编码评测# #
SWEbench# #
Agent#