《SWE-bench：语言模型能解决真实 GitHub 议题吗？》

它要解决什么问题

多数代码模型的评测只要求很小的一件事：补全一个函数、修一段代码、根据简短描述生成一个程序。真实的软件维护并不是这样。开发者拿到一份议题（issue）报告，要在庞大的代码库里找到相关代码，并在不破坏已有功能的前提下把它改掉。一个能在孤立情境下写出整洁函数的模型，离完成这件事可能还很远。

SWE-bench 就是为了衡量这类工作而设计的。论文由 Carlos E. Jimenez、John Yang、Alexander Wettig、Shunyu Yao、Kexin Pei、Ofir Press 和 Karthik Narasimhan 于 2023 年 10 月 10 日提交到 arXiv^[1]。

基准是怎么构建的

它由 2,294 个软件工程问题组成，全部取自真实的 GitHub 议题以及解决这些议题的对应拉取请求（pull request），覆盖 12 个流行的 Python 仓库^[1]。每道题把一个代码库和一份待解决议题的描述交给模型，要求模型编辑代码库来解决该议题^[1]。真实的修复很少只落在一个地方，因此解题往往需要同时理解并协调多个函数、类乃至多个文件中的改动^[1]。

这一设计正是基准的关键。模型无法靠匹配单个函数签名蒙混过关，它必须把一段自然语言的抱怨对应到代码库中的具体位置，并给出一组彼此一致的修改。题目还带着真实项目的粗糙感：报告问题的人和最终修好问题的人往往不是同一个人，写下的文字也出自不同的时间。

第一次评测的结果

首轮评测的结果相当冷静。无论是当时最先进的商用模型，还是作者自己微调的模型 SWE-Llama，都只能解决最简单的那部分议题；表现最好的模型 Claude 2 只解决了 1.96%^[1]。换句话说，大约每 100 道题里有 98 道模型没能给出有效的修复。这与「模型被要求写一个小而独立的程序时文思泉涌」所留下的印象，是完全不同的两幅图景。

Lite 子集与检索设置

作者还报告了 SWE-bench Lite 上的结果，这个较小的子集覆盖了原来 12 个仓库中的 11 个^[2]。由于整个仓库放不进模型的上下文，实验中包含一个步骤，用来决定模型能看到代码的哪些部分。模型分别在稀疏检索（sparse retrieval）和 oracle 检索两种设置下被评测，后者直接把相关文件交给模型，作者认为这种设置不够真实^[2]。

为什么重要

作者把真实世界的软件工程描绘成一片丰富、可持续且富有挑战的试验场，用来评测下一代语言模型^[1]。极低的解决率让差距变得具体：能写出看起来像样的代码的模型，仍然难以在真实仓库里完成一次维护性改动。由于题目来自真实的议题与拉取请求，而不是手工编写的谜题，这个基准上的分数能说明模型距离成为代码库的可用贡献者还有多远，也能说明这份工作里哪些环节——找到代码、读懂报告、做出前后一致的修改——依然困难。