论文名称：SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
机构：普林斯顿大学 + OpenAI
Github 链接：github.com/SWE-bench/S…
榜单链接：www.swebench.com/
简介
SWE-bench可以说是目前大模型代码方向非常有名的一个Benchmark了，最初是由普林斯顿大学NLP团队在2023年10月发布的，当时主打的Motivation就是，通过一种方式可以评估大模型解决软件工程实际问题的能力，而不是考大模型八股文，解决算法题的能力。
但后来大家也知道，AI Coding这个方向越来越火，所以OpenAI也开始对SWE-bench做了一些完善操作，比如经过人工过滤筛选了一些质量比较差的case，也对每个通过的case做了人工验证，最后留下了SWE-bench_Verified数据集，现在官方的榜单也是以这个数据集的结果为准了。
数据构建
主要是从12个活跃的Python开源项目（如Django、Matplotlib）中，通过筛选 GitHub 上已解决的issue和对应的PR构建测试案例。每个案例需满足：成功修复了特定问题并附带验证测试case且原始代码库的测试覆盖率超过90%。
数据的主要信息如下，主要包括代码信息、问题描述、测试用例等。
instance_id：(str) - 格式化的实例标识符，通常为 repo_owner__repo_name-PR-number。patch：(str) - 黄金补丁，即 PR（不包括测试相关代码）生成的、解决了问题的补丁。repo：(str) - 来自 GitHub 的仓库所有者/名称标识符。base_commit：(str) - 仓库的提交哈希值，表示在应用解决方案 PR 之前仓库的 HEAD。hints_text：(str) - 在解决方案 PR 首次提交创建之前对问题的评论，创建日期。created_at：(str) - 拉取请求的创建日期。test_patch：(str) - 由解决方案 PR 贡献的测试文件补丁。problem_statement：(str) - 问题标题和正文。version：(str) - 用于运行评估的安装版本。environment_setup_commit：(str) - 用于环境设置和安装的提交哈希值。FAIL_TO_PASS: (str) - 一个 JSON 字符串列表，表示已由 PR 解决并与问题解决相关的一组测试。PASS_TO_PASS: (str) - 一个 JSON 字符串列表，表示在 PR 应用之前和之后应通过的测试。使用方法
具体的提交步骤，看官方给的submit教程即可，大体流程如下图，此处不赘述了。
- 输入：issue的描述 + 完整的代码库输出：模型修改后的代码
但是，这里面会有一个很大的问题是，代码上下文一般都很长，怎么给到模型用呢？论文里面提供了两个思路，主要是把解决问题最需要的上下文检索出来给到LLM。
- “取巧”（Oracle Retrieval）：会拿到作者当时为修复这个issue提交的PR中的patch，因为这个patch涉及到的代码文件，就是该仓库最重要的代码上下文，可以直接给到模型。这个跟标准答案最接近，也代表了大部分的情况，除了一些需要更多代码文件的上下文才可以解决的问题。稀疏检索（Sparse retrieval）：使用BM25算法做检索，基于issue的描述搜索仓库中相关代码，并将其限制长度在1.3～5万行。通过相关实验结果发现检索长度在2.7w行时，只有40%会命中到PR对应的代码文件。
但是上述两个检索代码的方法，只是论文中自己做实验用的方法，没有限制使用者一定要遵循他们的方法。
很多使用者在测试SWE-bench时，都会提出自己的方法，因为检索代码的准确性对于最后的成功率影响是非常大的，属于很关键的Context了，所以榜单上很多是Agent+大模型的综合结果，而不是单大模型的评估结果。
评价指标
- 问题解决率（%Resolved）
成功解决问题的比例，目前2025年5月最新的榜单第一名是近期很火的Augment了，后面找个时间介绍下。
总结
SWE-bench是真正意义上的评估代码Agent的benchmark，但只注重于代码修复，以及处理代码上下文输入的策略， 会导致参评Agent的效果不仅限于LLM本身，检索策略的重要性对最后的效果影响也是非常大。
