门户首页
Paper Reading · Benchmark · arXiv 2310.06770 · ICLR 2024

SWE-bench：2,294 个真实 GitHub Issue，定义「智能体修 bug」的评测合约

从约 90,000 个 Pull Request 经三阶段过滤得到 2,294 个任务实例；判分不看补丁写得像不像，而是跑两遍测试套件——FAIL_TO_PASS 全过 ∧ PASS_TO_PASS 全过。2023 年底最好的模型（Claude 2）只解出 1.96%，这个惨淡数字让它成为智能体评测的事实标准，也是本站评分模块与数据仓库的源头。

生成时间：2026-09-15 · 版本 v0.2 · 生成 Agent：TraeWork（LLM: Kimi-K3） · 载体：agentsoft-research-platform teaching-web-platform
← 返回入口页 姊妹篇：SWE-agent 论文精读 配套：SWE-bench 入门讲义 配套：数据 Schema 论文 wiki 笔记
1 2 3 4 5 背景 合成题饱和 · 10 min 构造 3 阶段过滤 · 15 min 任务 issue+codebase · 15 min 评测 F2P/P2P · 15 min 落地 本仓同款 · 10 min 学习路径 · 总时长 ~65 min
图 1 · 学习路径（5 步：背景 → 构造 → 任务 → 评测 → 本仓落地对照）
SWE-bench 构造管线 · 三阶段过滤（论文 §2.1 / Figure 2） Stage I · 仓库选取与抓取 ~90,000 PR 12 个流行开源 Python 仓库（PyPI 高下载、维护规范、测试覆盖好）· 每个 PR 以 base commit 绑定代码库快照 Stage II · 属性过滤 只保留 merged PR，且 ① 解决了某个 GitHub issue（resolves）② 改动了仓库的测试文件（说明人类顺带贡献了验证用测试） Stage III · 执行过滤 真的装一遍、跑一遍：装不上 / 运行报错丢弃；至少存在 1 个「打补丁前失败、打补丁后通过」的测试（F2P）才保留 2,294 个任务实例 issue 文本 + 代码库快照 + gold patch + test patch（F2P/P2P 清单） 仓库分布（论文 Figure 3）：django 850 · sympy 386 · scikit-learn 229 · sphinx 187 · matplotlib 184 · pytest 119 · xarray 110 · astropy 95 · pylint 57 · requests 44 · seaborn 22 · flask 11
图 2 · 三阶段构造管线：从 ~90,000 个 PR 过滤到 2,294 个任务实例（漏斗逐层收窄 = 宁缺毋滥）

概览

2,294
任务实例（真实 issue）
12
流行 Python 仓库
~90,000
构造起点的 PR 总数
1.96%
2023 年底最好成绩（Claude 2）

论文精读

SWE-bench · 论文精读（4 张 card）
回答「为什么合成题测不出真实能力」+「90,000 个 PR 怎么滤成 2,294 道题」+「F2P/P2P 判定式为什么这样设计」+「1.96% 这个数字意味着什么」
卡片 1 · 背景与动机

为什么 HumanEval 不够：真实修 bug 难在哪里

2023 年的代码评测以 HumanEval 为代表：看函数签名写函数，几行代码、自包含、当场可判。论文指出这类合成题已经「饱和」——模型在上面动辄七八十分，但这不代表它能修真实 bug。真实软件工程是另一件事：在大仓库里导航、理解跨文件函数的相互作用、在绕来绕去的代码里发现一个小错误。论文的定位宣言：真实世界软件工程是一个「丰富、可持续、有挑战」的评测试验床——可持续指新 issue 不断产生，数据集可以低成本持续扩充。

核心知识点
  • 好 benchmark 的两个硬约束：任务要难到难住现有模型 + 预测必须容易验证（跑测试即可）
  • HumanEval 类合成题：自包含、几行代码、与真实工程脱节
  • 真实 issue 修复：经常需要同时跨多个函数、类甚至文件协调改动（论文摘要原话）
  • 四位作者中的 Jimenez 与 Yang 后来也是 SWE-agent 的共同一作——出题的人接着去答卷
课堂实训
在本仓跑 python -m swe_bench_warehouse.api._internal stats --name swe-bench-lite，看 Lite 子集的仓库分布，对照论文 Figure 3 体会「django/sympy 占大头」的长尾形态。
思考与讨论
论文说「容易验证」是好 benchmark 的硬约束。如果改用 LLM 当裁判来判分（不跑测试），会得到什么、失去什么？
配套讲义：SWE-bench 入门 论文 wiki 笔记
卡片 2 · 构造管线

三阶段构造管线：90,000 PR → 2,294 任务

GitHub 上的数据又多又脏，论文的核心工程贡献是一条三阶段过滤管线（上方图 2）：先抓 12 个流行仓库的约 90,000 个 PR，再按属性过滤（merged ∧ 解决了 issue ∧ 改了测试文件），最后执行过滤（真的把环境装起来跑测试，至少一个 F2P 才留）。通过率约 2.6%——宁缺毋滥是这个数据集的基因。

核心知识点
  • Stage I：12 个流行 PyPI 仓库，约 90,000 个 PR，每个 PR 以 base commit 锚定代码库快照
  • Stage II 属性过滤：merged ∧ resolves issue ∧ 改动测试文件（测试改动 = 人类留下的判分依据）
  • Stage III 执行过滤：安装成功 ∧ 运行无错 ∧ 至少 1 个 fail-to-pass 测试
  • 任务规模（论文 Table 1）：issue 平均 195 词；代码库平均 3,010 个非测试文件 / 438K 行；gold patch 平均改 32.8 行 / 1.7 个文件 / 3 个函数；F2P 测试平均 9.1 个
课堂实训
对照讲义「从 PR 构造 Benchmark 题目」过一遍本仓的 5 步构造流程，逐条指认它对应论文管线的哪个 Stage、多了哪些本仓自己的质检。
思考与讨论
Stage II 为什么要求 PR 必须改动测试文件？去掉这个条件数据量会大得多（论文训练集就这么做的，得到 19,000 对），代价是什么？
配套讲义：Benchmark 构造 配套讲义：数据 Schema
卡片 3 · 评测合约

任务与评测合约：F2P + P2P 双向判定

模型拿到的输入是 issue 文本 + 完整代码库，要交的是一个 patch 文件。判定方式是全文的题眼：打补丁前跑一遍测试、打补丁后再跑一遍，按测试状态变化分两类——F2P（FAIL_TO_PASS）从失败变通过，证明 bug 真修好了；P2P（PASS_TO_PASS）保持通过，证明没顺手弄坏别的功能。resolved = F2P 全过 ∧ P2P 全过，一条可以机械执行的判定式，不需要任何人读补丁。

核心知识点
  • 输入：issue 描述（平均 195 词）+ 代码库（平均 438K 行，远超上下文窗口 → 必须检索或让 agent 自己找）
  • 输出：标准 patch 文件；%Apply 单独统计「连合法 patch 都生成不了」的比例
  • 判定：resolved = F2P 全部通过 ∧ P2P 全部保持通过（防回归）
  • 与 HumanEval 的本质差别：判分依据是仓库真实测试框架，不是出题人写的几行 assert
课堂实训
打开本仓 experiment_modules/scoring/answer_evaluator/ 的评分代码，找到 F2P/P2P 的判定实现，与论文 §2.2 逐句对照——本站评分模块就是这条合约的工程化。
思考与讨论
一个补丁让 9 个 F2P 测试全过、但弄挂了 1 个 P2P 测试，算不算「解决了 issue」？论文选择算「没解决」——这个严格性保护了 benchmark 的什么性质？
配套讲义：评测流程 wiki 笔记 §核心方法
卡片 4 · 结果与遗产

关键结果：1.96% 的起点与后续家族

论文评测了 2023 年底最强的几个模型（BM25 检索设置）：最好成绩是 Claude 2 的 1.96%，ChatGPT-3.5 只有 0.17%，GPT-4 在 25% 随机子集上甚至是 0.00%（预算所限未跑全量）。换用「直接给出该改哪些文件」的 oracle 检索，Claude 2 也只到 4.8%。一个反直觉发现：上下文塞得越多成绩越差（Claude 2：13k 上限 1.96% → 27k 1.87% → 50k 1.22%）——检索进来的无关代码会干扰模型，这个观察正是姊妹篇 SWE-agent 的出发点之一。

核心知识点
  • BM25 检索成绩（Table 5）：Claude 2 1.96% · SWE-Llama 7b/13b 0.70% · ChatGPT-3.5 0.17% · GPT-4 0.00%（* 25% 子集）
  • %Apply 列：SWE-Llama 13b 53.62% 的 patch 能打上，Claude 2 43.07%，GPT-4 只有 14.83%——先学会「输出合法 patch」再谈「修对」
  • oracle 检索：Claude 2 4.8%（Table 18）——知道改哪里也修不对，瓶颈不只在定位
  • SWE-Llama：19,000 个 issue-PR 对（37 个仓库，与评测集严格不相交防污染），CodeLlama 上 LoRA 微调，超 30K token 的样本剔除后实训 10,000 条
  • 遗产：Lite（300）/ Verified（500）/ Pro / Multilingual 变体家族，判分合约始终是 F2P ∧ P2P
课堂实训
用本仓加载器 stats("swe-bench-original") 与 stats("swe-bench-verified") 各跑一遍，把输出与论文 Figure 3 的仓库分布对照，理解「变体 = 同一合约下的不同筛法」。
思考与讨论
从 1.96% 到今天榜单上的 70%+，两年时间差主要补在了哪里——检索、交互式 agent、还是模型本身？带着这个问题去读姊妹篇 SWE-agent，它的 Table 1 给了直接的实验证据。
姊妹篇：SWE-agent 论文精读 延伸深读：Agent 测试价值悖论