SWE-bench

义项:软件工程评测基准
SWE-bench

SWE-bench(Software Engineering Benchmark)是一个用于评估大语言模型与编码智能体解决真实软件工程问题能力的基准,由普林斯顿大学等机构的研究者于 2023 年发布。它从 GitHub 上 12 个常用 Python 仓库中收集 2,294 个问题与修复请求构成的样本,要求被测系统在只有问题描述和修复前代码库的情况下生成补丁,再用项目自带的单元测试判定是否解决。[1]此后它衍生出 Lite、Verified、Multimodal、Multilingual 等多个版本,成为比较 AI 编程能力时被广泛引用的指标,也因其测试质量与训练数据污染问题受到检讨。

目录
  1. 定义
  2. 原理
  3. 发展历程
  4. 应用
  5. 局限
  6. 参见

定义

SWE-bench 是一套以真实代码仓库为对象、以代码补丁为产出、以单元测试为判据的软件工程评测基准。每个任务给定一段来自 GitHub 的问题描述(issue)和一个尚未修复的代码库快照,被测系统需要理解问题并提交一处或若干处代码修改;评测程序把补丁应用到对应版本的仓库中,再运行项目原有的测试套件,全部通过才算解决该任务。[2]

与只要求补全单个函数或解答编程题的基准不同,SWE-bench 的任务分布在拥有大量文件的真实项目中。研究报告指出,完成任务往往需要同时理解多个函数、类乃至文件之间的关系,并在执行环境中反复调试,这已超出传统代码生成任务的范畴。[3][1]

原理

任务样本的构造分三步。第一步从 12 个维护规范、测试覆盖较好的开源 Python 仓库中抓取拉取请求;第二步筛选出已合并、关联了 issue 且改动了测试文件的请求;第三步逐一应用补丁并比较测试结果,只保留至少有一个测试由失败转为通过的样本,最终得到 2,294 个任务实例。[1]

评测依赖两组测试。Fail-to-Pass 是修复前失败、修复后应当通过的测试,用于判断问题是否真的被解决;Pass-to-Pass 是修复前后都应保持通过的既有回归测试,用于判断补丁是否破坏其他功能。两组测试全部满足,该实例才被记为已解决,指标为所有实例中已解决的百分比。[4][2]

每个样本都配有按拉取请求基准提交构建的 Docker 镜像,内含相应版本的仓库与依赖。补丁在容器内应用并执行测试,从而避免操作系统、库版本等环境差异带来的随机失败。维护方建议在 x86_64 机器上使用至少 120GB 空闲存储、16GB 内存和 8 个 CPU 核心运行本地评测。[5][6]

由于单个代码库规模可达数十万行,被测系统通常先做检索再修改。最初的基线用 BM25 检索相关代码片段交给模型;后来的做法多改由智能体在环境内自行搜索、编辑并运行测试,属于工具调用与多轮交互式的解法。[7][4]

发展历程

SWE-bench 于 2023 年 10 月发布,配套论文题为《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》,作者来自普林斯顿大学与芝加哥大学等机构。论文于 2024 年 1 月被 ICLR 2024 接收为口头报告。[7][5]

发布之初,能力最强的模型解决率不足 2%,其中 Claude 2 配合 BM25 检索为 1.96%。2024 年 4 月,研究团队发布 SWE-agent,首次引入面向软件工程任务的智能体框架,在全量测试集上取得 12.47% 的成绩。[5]

2024 年陆续出现多个子集。3 月发布 SWE-bench Lite,含 300 个实例,用于降低评测成本;8 月与 OpenAI 合作发布 SWE-bench Verified,由资深工程师从 1,699 道候选题中筛出 500 道确认可解的题目;10 月发布 SWE-bench Multimodal,任务描述中包含截图等视觉信息。2025 年 1 月,多模态版本的测试集改为私有,并提供云端评测工具。[8][6]

SWE-bench Multilingual 将评测从 Python 扩展到 9 种编程语言、42 个仓库,共 300 个实例,涵盖 C、C++、Go、Java、JavaScript/TypeScript、PHP、Ruby、Rust 等。[9][10]

随着模型与智能体框架改进,Verified 上的成绩快速上升。2024 年下半年曾出现约 49% 的结果,2025 年至 2026 年初前沿模型报告的数字升至 70% 以上,公开榜单显示近半年从 74.9% 提高到 80.9%,增速明显放缓。[4]

应用

SWE-bench 被广泛用于比较大语言模型和编码智能体的软件工程能力,官方榜单按解决率排序,并按是否开放权重、是否由团队亲自运行等维度区分。各家在发布新模型或新智能体框架时,常把 SWE-bench 分数作为主要指标之一。[8][2]

在研究方法层面,该基准提供了可执行、可自动判分的任务格式,常被用作训练和评估软件工程智能体的环境,配套出现了 SWE-agent、SWE-smith、sb-cli 等工具,分别用于智能体框架、训练数据生成与云端评测。[7][11]

由于其测试结果由代码执行给出而非人工打分,也有研究把它当作强化学习中可验证奖励的来源,用于训练模型在长上下文中定位并修改代码。[7]

局限

测试本身可能与任务描述不匹配。OpenAI 复核了模型长期无法解出的 138 道 Verified 题目,认为其中 59.4% 存在实质性缺陷:35.5% 的测试过于狭窄,强行限定实现细节,使功能正确的提交被判错;18.8% 的测试考察了问题描述中并未提及的功能;另有 5.1% 属于其他问题。

数据污染是另一项质疑。由于题目与金标准补丁来自公开的开源代码库,可能已进入模型的训练数据。有研究仅向模型提供 issue 文本而不给代码库,让其猜测需要修改的文件路径,在 Verified 上的准确率最高可达 76%,明显高于外部仓库的 53%,提示部分成绩源自记忆而非推理。[12][13]

还有研究筛查 issue 文本后发现,被判为成功的补丁中约 32.67% 存在答案泄露,即修法已在 issue 或评论中出现;31.08% 因测试过弱而可疑。剔除这些问题后,同一智能体框架的解决率从 12.47% 降到 3.97%。[14][13]

任务规模与真实工程存在差距。收集策略偏好问题定义清晰、单元测试无歧义的样本,由此筛出的补丁改动量普遍偏小,Multilingual 版本金标准补丁的中位数仅为 10 行代码,而真实软件开发常常需要大得多的修改。[10]

此外,分数可比性受外部条件影响。同一基础模型搭配不同智能体脚手架,结果可相差十几到三十个百分点;不同子集之间的分数也不能直接比较。基于上述原因,OpenAI 已停止报告 Verified 的分数,建议改用 SWE-bench Pro 等污染较轻的评测数据。

参见

  • SWE-agent —— 研究团队基于 SWE-bench 提出的软件工程智能体框架,曾在全量测试集上取得 12.47% 的解决率。

  • 大语言模型 —— SWE-bench 主要评估的对象,任务是让模型读懂问题并生成补丁。

  • GitHub —— 基准中的问题描述与修复请求均采集自该代码托管平台。

  • Docker —— 评测环境以容器镜像形式提供,用于保证结果可复现。

  • 单元测试 —— 判定补丁是否解决问题的依据,分为 Fail-to-Pass 与 Pass-to-Pass 两组。

  • 数据污染 —— 评测题目与解法进入训练数据后导致分数虚高的问题,是 SWE-bench 受到检讨的主要原因之一。

参考资料

  1. princeton.edu 上的网页 [引用日期2026-10-29]
  2. forkast.news 上的网页 [引用日期2026-10-29]
  3. arxiv.org 上的网页 [引用日期2026-10-29]
  4. SWE-bench Benchmark — Klu - August 21, 2026 [引用日期2026-10-29]
  5. Overview [引用日期2026-10-29]
  6. SWE-bench:基于语言模型的软件问题修复基准项目 [引用日期2026-10-29]
  7. meta [引用日期2026-10-29]
  8. Official Leaderboards [引用日期2026-10-29]
  9. SWE-bench Datasets [引用日期2026-10-29]
  10. SWE-bench Multilingual [引用日期2026-10-29]
  11. SWE-bench:基于语言模型的软件问题修复基准项目 [引用日期2026-10-29]
  12. arxiv.org 上的网页 [引用日期2026-10-29]
  13. 24_coding_agents [引用日期2026-10-29]
  14. acm.org 上的文件 [引用日期2026-10-29]
词条评价
词条统计

浏览次数:0 次

阅读量:0 次 · 阅读完成量:0 次

最近更新:2026-10-28T18:30:41Z

历史版本

本条目引用的词条
SWE-agent 大语言模型 GitHub Docker 单元测试 数据污染