基准:SWE-bench、GAIA 与 AgentBench

基准:SWE-bench、GAIA 与 AgentBench

本节摘要:排行榜只告诉你哪个模型在某个基准上赢了,却不告诉你三件至关重要的事——基准是否被污染(解法泄露进训练集)、基准是否测量你在乎的能力(代码 vs 浏览 vs 通才)、评估器是否健壮(AST 匹配 vs 状态检查 vs 人工评审)。2026 年,三个基准锚定了 Agent 评估:SWE-bench(Jimenez 等人,ICLR 2024 oral)测代码补丁——2294 个真实 GitHub issue,Agent 拿到修前提交点的代码库加 issue 描述,产出补丁,评估器应用补丁跑测试套件,补丁必须把 FAIL_TO_PASS 测试翻成通过、且不破坏 PASS_TO_PASS;SWE-bench Verified(OpenAI,2024 年 8 月)是人工策展的 500 题子集,清除了歧义 issue 与不可靠测试;SWE-bench+ 的污染审计更扎心——32.67% 的成功补丁在 issue 文本里就泄露了解法,31.08% 因测试覆盖太弱而可疑。GAIA(Mialon 等人,2023)走「人类易、AI 难」路线:人类 92% 通过、带插件的 GPT-4 仅 15%,测通才工具使用与多模态。AgentBench(Liu 等人,ICLR 2024)横跨 8 个环境,发现开源 LLM 追赶商业模型的主要瓶颈是长程推理、决策与指令遵从。读完本节,你应能说出每个基准的构成、污染故事与盲区,并避免「单数字执念、污染式声明、把基准当开发目标」三种陷阱。

对应原课程:Phase 14 · Lesson 19 · benchmarks-swebench-gaia(原英文 phases/14-agent-engineering/19-benchmarks-swebench-gaia/docs/en.md)。前置:第 06 节(工具使用)。

学习目标

阅读完本节,你应当能够:

1. 说出 SWE-bench 的测试装置(FAIL_TO_PASS),解释它为何用单元测试做门控。
2. 解释 SWE-bench Verified(OpenAI,500 题)为何存在,以及它清除了什么。
3. 描述 GAIA 的设计哲学:人类易、AI 难;三个难度等级。
4. 说出 AgentBench 的八个环境,以及它对开源 LLM 找出的主要瓶颈。
5. 总结 SWE-bench+ 的污染发现及其含义,并说明这些基准不测什么。

一、问题与直觉

排行榜告诉你哪个模型在一个基准上赢了。但它不告诉你:

• 基准是否被污染(解法在训练数据里、测试集泄漏)。
• 基准是否测你在乎的能力(代码 vs 浏览 vs 通才)。
• 评估器是否健壮(AST 匹配、状态检查、人工评审)。

在引用任何数字前,先吃透这三个锚定基准及其失败模式。否则,「SWE-bench 50%」这句话比不说还危险——它制造了虚假的信心。

SWE-bench(Jimenez 等人,ICLR 2024 oral)

• 来自 12 个流行 Python 仓库的 2294 个真实 GitHub issue。
• Agent 拿到:修前提交点的代码库 + 自然语言 issue 描述。
• Agent 产出:一个补丁(patch)。
• 评估器:应用补丁,跑该仓库的测试套件。补丁必须翻转 FAIL_TO_PASS 测试(此前失败、此后通过),且不破坏 PASS_TO_PASS 测试(此前通过、此后仍通过)。

SWE-agent(Yang 等人,2024)发布时达到 12.5%,靠的是强调Agent-计算机接口(Agent-Computer Interface)——文件编辑器命令、模型能理解的搜索语法。这是第 06 节「工具描述是承重的」在基准层的回响:给模型好用的接口,能力就涨。

SWE-bench Verified

OpenAI,2024 年 8 月。人工策展的 500 题子集。清除了歧义 issue、不可靠测试、修复不明确的任务。这是「你的 Agent 真能交付真实补丁吗」的首选基准。

污染

• 超过 94% 的 SWE-bench issue 早于大多数模型的训练截止。
• SWE-bench+ 发现:32.67% 的成功补丁在 issue 文本里就泄露了解法(模型在描述里看到了修复),31.08% 因测试覆盖太弱而可疑。
• Verified 更干净,但并非无污染。

实战含义:一个在 SWE-bench 上得 50% 的模型,在 SWE-bench+ 上可能只有 35%。声称 SWE-bench 性能时,永远同时报告两者。

GAIA(Mialon 等人,2023 年 11 月)

• 466 题;300 题保留给 huggingface.co/gaia-benchmark 的私有排行榜。
• 设计哲学:「对人类概念上简单(92%),对 AI 难(带插件的 GPT-4:15%)。」
• 测推理、多模态、网页、工具使用。
• 三个难度等级;Level 3 需要跨模态的长工具链。

GAIA 是你用来测「通才能力」的基准。别和代码专用基准混淆。

AgentBench(Liu 等人,ICLR 2024)

• 8 个环境:代码(Bash、DB、KG)、游戏(Alfworld、LTP)、网页(WebShop、Mind2Web)、开放式生成。
• 多轮,每个 split 约 4k~13k 轮。
• 核心发现:长程推理、决策、指令遵从是开源 LLM 追赶商业模型的主要瓶颈。

这些基准不测什么

• 真实运维成本(token、墙钟时间)。
• 对抗条件下的安全行为。
• 你所在领域的表现(用你自己的评估,第 30 节)。
• 尾部失败(基准取平均;生产运维关心最差的 1%)。

⚠️ 三种基准陷阱:① 单数字执念——SWE-bench 50% 告诉你的,远不如 P50/P75/P95 成本 + 步数分布。② 污染式声明——报告 SWE-bench 却不提 Verified 或 SWE-bench+,是误导。③ 把基准当开发目标——为基准优化会偏离生产有用性(goodhart 定律:当一个指标成为目标,它就不再是好指标)。

二、从零实现

原课程 code/main.py 实现了一个玩具版 SWE-bench 式测试装置:

• 合成的修 bug 任务(3 个)。
• 一个脚本化的「Agent」提出补丁。
• 一个测试运行器,检查 FAIL_TO_PASS(bug 已修)与 PASS_TO_PASS(无回归)。
• 一个 GAIA 式难度分类器,按问题分解深度分级。

Step 1:任务与门控定义

@dataclass
class Task:
    codebase: str                       # 修前提交点的代码
    issue: str                          # 自然语言描述
    fail_to_pass: list                  # 此前失败的测试,补丁后必须通过
    pass_to_pass: list                  # 此前通过的测试,补丁后不得破

@dataclass
class Verdict:
    resolved: bool                      # FAIL_TO_PASS 全翻 + PASS_TO_PASS 全保
    no_regression: bool
​

Step 2:评估器(应用补丁 + 跑测试)

def evaluate(task: Task, patch: str) -> Verdict:
    apply(task.codebase, patch)                      # 应用补丁
    ftp_ok = all(run(t).passed for t in task.fail_to_pass)   # 修复门
    ptp_ok = all(run(t).passed for t in task.pass_to_pass)   # 无回归门
    return Verdict(resolved=ftp_ok and ptp_ok, no_regression=ptp_ok)
​

Step 3:GAIA 式难度分类

def difficulty(question):
    depth = count_decomposition_steps(question)   # 需要拆几步
    if depth <= 2: return 1
    if depth <= 5: return 2
    return 3                                       # Level 3 需跨模态长工具链
​

运行 python3 code/main.py 会展示每个任务与每个难度的解决率,把评估规则具体化。

💡 设计要点:SWE-bench 的评估器之所以可信,是因为它检查测试的实际状态(修没修好、有没有回归),而不是去匹配补丁的 AST。这正是第 06 节提到的 BFCL V3「基于状态的评估」思想——查状态,不查形状。

三、框架对比

四、可复用产物

原课程 outputs/skill-benchmark-harness.md:为任意「代码库-任务」对搭建 SWE-bench 式测试装置,带 FAIL_TO_PASS / PASS_TO_PASS 门控、步数与成本度量、解法泄露检查。

五、练习

1. (Easy) 把玩具装置移植到一个真实仓库(挑你自己的)。为已知 bug 写 3 个 FAIL_TO_PASS 测试。
2. (Medium) 加一个步数指标。在你的 3 个任务上,每次解决要多少 Agent 步?
3. (Medium) 读 SWE-bench+ 论文,实现一个解法泄露检查(把 issue 文本与 diff 做模式匹配)。
4. (Hard) 从 GAIA 公开 split 下载一题。追踪一个 GPT-4 级 Agent 会怎么做。它需要哪些工具?
5. (Hard) 读 AgentBench 的按环境分解。哪个环境映射你的产品界面?那里的「SOTA」长什么样?

本节要点回顾

1. SWE-bench:2294 个真实 GitHub issue,补丁必须翻 FAIL_TO_PASS 且不破 PASS_TO_PASS,ICLR 2024 oral。
2. SWE-agent 靠接口涨分:12.5% 的关键是好用的 Agent-计算机接口——工具描述承重的回响。
3. SWE-bench Verified:OpenAI 人工策展 500 题,清歧义/不可靠测试,但非无污染。
4. SWE-bench+ 污染审计:32.67% 成功补丁在 issue 文本泄露解法,31.08% 测试覆盖太弱可疑;声称性能必须同报 SWE-bench 与 +。
5. GAIA:466 题,人类 92% / AI 15%,测通才工具使用与多模态,Level 3 需跨模态长工具链。
6. AgentBench:8 环境(代码/游戏/网页/开放式),发现开源 LLM 的瓶颈是长程推理、决策、指令遵从。
7. 四件不测:真实运维成本、对抗安全、你的领域、尾部失败。
8. 三大陷阱:单数字执念(看分布不看均值)、污染式声明(不提 Verified/+)、把基准当开发目标(goodhart)。
9. 评估器查状态不查形状:SWE-bench 跑测试看状态,与 BFCL V3 思想一致。
10. 生产用自定义评估:基准给方向,第 30 节的自建评估才贴近你的产品形态。

下一节,我们继续基准话题,聚焦网页与桌面环境——WebArena 与 OSWorld 如何在真实浏览器与操作系统里度量 Agent,以及 Computer Use(第 21 节)所依赖的评估地基。