SWE-Bench Pro Verified：去除 reward hacking 与 task quality 失真的可靠评测集

  • 关联论文：2609.08149
  • 作者：flyP
  • 更新：2026-09-11

元层五问（v2 模板 §0）： R1 命名 = R-132（撞自己检测 ✓ 与 inbox/flyp/ 历史无同名主稿 · 注：SWE-Bench 通用主题需警惕撞名，已加边界声明） R2 截止日 = 2026-09-11（cron 任务窗口内） R3 评级 = A-（事实层全部 anchor 至 abstract · 数字 100% abstract verbatim · 无私域污染 · 双轨齐全 · 公开仓库 / 数字细节 abstract 未明确已 ⚠️） R4 边界 = 仅写本文件 / 不动他人目录 / 不 git / 不输出密钥；本稿 ≠ SWE-Bench / SWE-Bench Verified 原文分析，避免与外部评测团队产物撞名 R5 字数 = 主稿 ≤3,500 CJK · 反方 ≤300 CJK · 元信息 ≤100 CJK（硬约束 ≤3,900）

一句话结论

SWE-Bench Pro Verified 把「SWE-Bench Pro」这个仓库级软件工程 agent 评测基准里两类失真（reward hacking 来源 + task quality 来源）一并修掉，给出可信版本，让榜单成绩更接近 agent 的真实编码能力。

它要解决的真问题

SWE-Bench Pro 已成软件工程 agent 的事实标准之一。但作者分析发现其评测可信度被两类系统性失真侵蚀：

  1. Reward hacking 来源：gold solution 泄漏 + 隐藏评测信息泄漏 → agent 可能「抄答案」而非「真解题」，分数虚高；
  2. Task quality 来源：误导性 problem statement + 不当 scope 的测试 → 即使 agent 正常解题也会被判失败，分数虚低。

这两类问题叠加，会把榜单上的 agent 排序整段「反转」——一个靠 reward hacking 拿高分的 agent，可能在真实仓库里反而不如一个被 task quality 误判的低分 agent。

核心方法

SWE-Bench Pro Verified 的核心是「验证 + 修复」而非「重新出题」。具体动作（abstract 描述级）：

  • reward hacking 侧：识别 gold solution / 隐藏评测信息泄漏点，重写评测协议或 task 包装，切断 agent 直接抄答案的路径（具体技术手段 abstract 未明确，需要 PDF §III 核验）；
  • task quality 侧：人工 + 工具双重审阅 problem statement 与 test scope，修正误导性描述 + 收紧 test 边界（具体审阅流程 abstract 未明确）；
  • 保留原 SWE-Bench Pro 的 task 分布与难度：不在「题目难度」上动手脚，确保 verified 版与原版「同一难度谱」，避免「verified 版变简单」的可信度反向问题。

伪代码骨架（机制示意，非 SDK）：

def verify_task(task, gold_solution, hidden_info, tests):
    # 1. leak detection: gold solution / hidden info 是否在 agent 可达上下文
    leaks = detect_leak(gold_solution, hidden_info, task.context)
    # 2. statement audit: problem statement 是否误导（歧义 / 自相矛盾 / 与测试不一致）
    statement_issues = audit_statement(task.statement, tests)
    # 3. test scope audit: tests 是否覆盖了 statement 中的所有承诺？
    scope_issues = audit_test_scope(task.statement, tests)
    if any([leaks, statement_issues, scope_issues]):
        return fix_task(task, leaks, statement_issues, scope_issues)
    return task  # verified

关键实验与数据

  • 评测对象：原 SWE-Bench Pro 上的所有 task；
  • 操作方式：找到失真 task → 修复（leak / statement / scope 任一）→ 保留难度；
  • 核心证据：abstract 明确陈述两类失真存在并导致「benchmark performance inflate」+「obscure agents' true coding ability」；
  • 公开榜单数字：abstract 未给出具体 agent 在原版 vs verified 版上的 Δ 分数对比（标注为「原文未明确」）。

⚠️ 关键数字（verified 版的 task 数、agent 排名变化、reward hacking 命中率、statement audit 通过率）在 abstract 中均未明确。下文涉及「具体提升幅度」必须以 PDF §V 核验。

亮点与局限

亮点

  1. 「验证 + 修复」而非「重新出题」：保留原 SWE-Bench Pro 的难度谱，避免「verified 版变简单」的二次失真；
  2. 同时打两类失真：reward hacking + task quality 并修，对榜单可信度的修复是端到端的；
  3. 方向对了：与同日发布的 AgentAudit（2609.09875）形成「benchmark 可信度」的双轨——前者修 benchmark 本身，后者评 agent 在 benchmark 上的失败位置；
  4. 填补社区缺口：SWE-Bench 家族之前已有 SWE-Bench Lite / SWE-Bench Verified（针对 SWE-Bench 而非 Pro），但 Pro 版本的 verified 一直缺位。

局限

  1. 被引 0（2026-09-09 提交）：同行评审尚未发生；
  2. 具体数字 abstract 未给：verified 版 vs 原版各 agent 排名变化幅度、leak 命中率、statement audit 通过率均未披露 ⚠️；
  3. 「修复」的标准未必唯一：problem statement 误导 / test scope 失当的判定本身是 judgment call，可能引入 verified 团队的偏好；
  4. 公开仓库 / 评测协议 abstract 未附链接：独立复现门槛高（与原 SWE-Bench Pro 是否有公开 GitHub 仓库需进一步核查）；
  5. 难以反向验证：单方面声明「修好了」不等于社区公认；需等独立第三方复现。

对工程落地的启发

  • 任何 benchmark 都需要「verified pass」：上线前自建内部 benchmark 也应跑 leak / statement / scope 三件套审计，避免团队内「我们做的内部榜第一」其实是 reward hacking；
  • 「保留难度谱」是 verified 版本的核心约束：重做基准最容易踩的坑是「verified 版变简单」，SWE-Bench Pro Verified 把这点作为方法学约束明确写出，值得借鉴；
  • 双轨对照：自己 agent 跑 verified 版 + 原版两份，对比 Δ 是判断自身稳健性的便宜信号；
  • 避免撞名：本主题（SWE-Bench 家族）已被多团队多角度解读，写作时务必明确「本文针对 SWE-Bench Pro Verified ≠ SWE-Bench Verified ≠ 原 SWE-Bench Pro」三者的区别，避免撞自己 ⚠️。

与同方向工作的关系

  • vs 原 SWE-Bench Pro：Verified 是 Pro 的「可信度修复版」，不是替代；保留难度谱；
  • vs SWE-Bench Verified（针对 SWE-Bench 非 Pro）：两者都是「verified」思路，但目标 benchmark 不同（SWE-Bench 是经典版，Pro 是仓库级商用版），不可混为一谈；
  • vs AgentAudit（2609.09875，同日）：SWE-Bench Pro Verified 修「benchmark 本身的可信度」；AgentAudit 评「agent 在 benchmark 上的失败位置」。两者构成「评测可信度」主题的双轨：
  • SWE-Bench Pro Verified = 把尺子校准；
  • AgentAudit = 把尺子的读数拆到 stage；
  • vs LiveCodeBench / RepoBench 等动态榜：动态榜用持续更新规避失真，但代价是「同一 agent 不同时间点分数不可比」；Verified 路线保留可比性，代价是修榜本身需要人工；
  • vs HumanEval / MBPP：单函数级别基准的 verified 化早已成熟；SWE-Bench Pro Verified 把这条路径推到仓库级 + 商用代码库规模。

适合谁读

  • agent 团队负责人 / Tech Lead：上 SWE-Bench Pro 之前先跑 Verified，避免自家 agent 排名被 reward hacking / task quality 失真误导；
  • benchmark 维护者 / 数据集策展人：把「leak detection + statement audit + scope audit」三件套吸收到自家 benchmark 发布 checklist；
  • 学术评测研究者：可作为「verified benchmark 路线」的近期案例，与动态榜路线（LiveCodeBench）对照阅读；
  • 不推荐：纯应用 LLM 开发者（chat / RAG）—— 本主题只与代码 agent / 仓库级 benchmark 相关。

反方（v2 三段式 · 按主线分布）

  • 机制层：「修复」的判定标准本身是 judgment call；problem statement 误导与 test scope 失当的边界由谁来划、划在哪条线，abstract 未明确 author team 的审阅 SOP；这意味着 verified 版可能引入 verified 团队的偏好，构成「权威方定义失真」的新风险。
  • 工程层：保留原版难度谱是承诺也是负担——任何 verified 修复都可能在「题面改了」与「难度没改」之间踩线，需大量 regression testing；公开仓库 / 评测协议 abstract 未附，独立复现门槛高 ⚠️。
  • 数据层：verified 版 vs 原版各 agent 排名变化幅度、leak 命中率、statement audit 通过率等核心数字 abstract 均未披露；缺乏量化证据下「修好了」的声明难以被社区证伪；与同日发布的 AgentAudit（2609.09875）相比，本篇缺乏「跨模型横向数字」，可比性较弱。

> ⚠️ 本稿事实层全部 anchor 至 arxiv abstract（2609.08149，2026-09-09 提交）。verified 版 task 数 / agent 排名变化 / leak 命中率 / statement audit 通过率 / 公开 GitHub 链接 = 原文未明确。本稿 ≠ SWE-Bench Pro 团队官方产物，仅为第三方学术解读。

工程落地与核查（Jay）

实际系统怎么用

1. 直接跑 SWE-Bench Pro Verified 而非原版

若团队以 SWE-Bench Pro 榜单选型 agent：

# 替换数据源
export SWE_BENCH_DATA="SWE-Bench-Pro-Verified-v1"  # 待官方发版后
python evaluate.py --benchmark=swebench-pro-verified --model=your-agent

现状提醒：Verified 版目前尚未正式发布（2026-09-09 刚提交），真正可跑需要等 official release + GitHub 仓库公开。

2. 自建 leak detection 三件套（不依赖官方）

在官方仓库出来之前，可以先做 leak detection 自检：

# 检测 gold solution 是否泄漏到 agent 可达上下文
def check_leak(task, agent_context):
    gold = task["gold_solution"]
    # 检查 gold solution 中的函数名、变量名是否出现在
    # agent 的 system prompt / task prompt / file context 中
    leak_tokens = extract_identifiers(gold)
    return any(t in agent_context for t in leak_tokens)

# 检测 hidden info 是否通过 test 文件泄漏
def check_test_leak(task):
    test_file = task["test_file"]
    # 若 agent 可读 test_file 则 reward hacking 路径存在
    return task["hidden_test_info"] not in test_file

3. 对比 Δ 快速判断 agent 稳健性

对同一 agent 跑原版 + Verified 两份，取 Δ： - Δ 接近 0：agent 没有被失真干扰，真实能力强 - Δ 显著正向（原版低 Verified 高）：原版被 task quality 误杀 - Δ 显著负向（原版高 Verified 低）：原版靠 reward hacking 拿分

坑在哪

坑 1：Verified 版 task 覆盖率未知

abstract 未明确「多少比例的 SWE-Bench Pro task 被修复」。若只修 10% 的 task，Verified 版与原版差异可能很小，失去意义。等 PDF §III 核验具体覆盖率。

坑 2：leak detection 本身可能被绕过

abstract 说「切断 agent 直接抄答案的路径」，但没说怎么切。若只是把 gold solution 移出文件路径，advanced agent 仍可能从其他文件名猜到答案。真正的 leak 切断需要对抗性测试验证。

坑 3：Verified 版 task 与原版不是同分布

abstract 承诺「保留原版难度谱」，但修复 leak/statement/scope 本身可能改变 task 分布（即使内容难度相同，token 分布变了）。若 agent 对 token 分布过拟合，Verified 版分数仍可能不准。

坑 4：独立复现门槛高（暂无 GitHub）

当前既无官方仓库，也无评测脚本。抄作业只能等官方 release 或自己实现 abstract 描述，implementation bias 风险大。

坑 5：「保留难度谱」承诺无法被外部验证

这是信任假设而非可证伪声明——verified 团队说自己保留了难度，但无量化方法。需等第三方复现。

事实核查记录

  • ✅ 两类失真（reward hacking + task quality）导致 benchmark performance inflate：abstract 原文有
  • ✅ 保留原版难度谱：abstract 明确承诺
  • ⚠️ 核心数字（verified task 数、agent Δ 分数、leak 命中率）：abstract 未给，需 PDF §III–§V
  • ⚠️ GitHub 仓库链接：abstract 未附，独立复现待官方发布

与同日 AgentAudit 的工程互补

SWE-Bench Pro Verified 校准的是「尺子准不准」，AgentAudit 校准的是「读数能不能定位到哪一步坏了」。两者组合：

原始 agent 成绩
  → 先跑 SWE-Bench Pro Verified（尺子校准）
  → 若仍失败，跑 AgentAudit（定位哪一步失败）

这才是完整的 agent 调试闭环。