Cognition 发布 Devin 的 SWE-bench 技术报告

为了评估 Devin，我们转向 SWE-bench，这是一个针对软件工程系统的自动化基准测试，由 GitHub issue 和 pull request 组成。我们认为 SWE-bench 是一个很好的选择，因为它通过单元测试确定性地评估系统在真实世界代码库中解决 issue 的能力，而不像 HumanEval 这样的基准测试仅限于独立函数。

在 SWE-bench 中，Devin 成功解决了 13.86%* 的 issue，远超此前最高的无辅助基线 1.96%。即使给定要编辑的确切文件（“辅助”模式），此前最好的模型也只能解决 4.80% 的 issue。

我们在 https://github.com/CognitionAI/devin-swebench-results 提供了我们的评估工具和 Devin 的代码编辑。

背景

SWE-bench 是一个包含 2,294 个 issue 和 pull request 的数据集，这些内容抓取自 GitHub 上流行的开源 Python 仓库。其目标是测试系统编写真实世界代码的能力。

每个 SWE-bench 实例由一个 GitHub issue 和解决它的 pull request 组成。该 pull request 必须包含一个单元测试，该测试在代码更改前失败、更改后通过（称为“fail to pass”测试）。diff 被分为两部分：patch 和 test_patch，分别包含代码更改和测试更改。

然后，被评估的系统需要根据 GitHub issue 描述和仓库（在 issue 发生时的状态）生成一个 diff。如果在应用编辑后所有单元测试都通过，则该实例被视为成功。

来源：swebench.com

在 SWE-bench 中，LLM 要么被给定要编辑的正确文件集合（“辅助”模式）；要么由一个单独的系统根据与 issue 文本的相似度检索要编辑的文件（“无辅助”模式）。作为一个 agent，Devin 不会收到任何文件列表，而是自行浏览文件，这更接近于“无辅助”模式的 LLM。

正确解决 SWE-bench 实例具有挑战性。较难的 PR 需要更改数十个文件、保持向后兼容性，和/或进行大量复杂推理。即使在辅助模式下，最好的 LLM 也只能达到 4.80% 的成功率。

方法

我们将 SWE-bench 调整为评估 agent，这比原本针对 LLM 的评估更为通用。

设置

• 我们使用标准化提示词端到端地运行 agent，该提示词要求它仅根据 GitHub issue 描述来编辑代码。在运行过程中，我们不向 agent 提供任何其他用户输入。
• 仓库被克隆到 agent 的环境中。我们只在 git 历史中保留基础提交及其祖先，以防止信息泄露给 agent。值得注意的是，我们移除了 git remote，使 git pull 无法工作。
• 我们在测试开始前设置好 Python conda 环境。
• 我们将 Devin 的运行时间限制为 45 分钟，因为与大多数 agent 不同，它有能力无限期运行。如果它愿意，可以选择提前终止。

评估

• 一旦 agent 的运行退出，我们将所有测试文件重置为原始状态，以防 agent 修改了测试。我们提取文件系统中所有其他 diff 作为 patch。为了确定哪些文件是测试文件，我们取 test patch 中所有被修改文件的集合。
• 我们将 agent 的 patch 应用到仓库，然后应用 test patch。
• 我们运行 SWE-bench 提供的评估命令，并检查所有测试是否通过。

你可以在 https://github.com/CognitionAI/devin-swebench-results 找到我们改编的评估工具代码。

结果

我们在随机选取的 SWE-benchmark 测试集的 25%（2,294 个中的 570 个）上评估了 Devin。这样做是为了减少基准测试完成所需的时间，与原论文作者使用的策略相同。
Devin 成功解决了 570 个 issue 中的 79 个，成功率为 13.86%。这显著高于此前最佳的辅助系统（Claude 2）的 4.80%。

此图中的基线是在“辅助”设置下评估的，即向模型提供其需要编辑的确切文件。基线在“非辅助”设置下表现更差，此时由单独的检索系统为 LLM 选择要编辑的文件（最佳模型是 Claude 2 + BM25 检索，为 1.96%）。

由于非辅助和辅助设置都无法与 agent 设置严格比较——在 agent 设置中，Devin 获得整个仓库并可以自由浏览文件——我们选择为基线比较采用更强的数字。我们认为，端到端运行 agent 是 SWE-bench 更自然的设置，因为它更接近现实世界的软件开发。我们预计未来会有更多 agent 在此设置下的结果。

分析

多步规划

Devin 可以执行多步计划以从环境中获得反馈。72% 的通过测试需要超过 10 分钟才能完成，这表明迭代能力有助于 Devin 取得成功。

定性示例

我们对 Devin 的结果提供一些定性分析。请记住，Devin 仅以 issue 描述和克隆的仓库作为输入。

示例 1：✅ scikit-learn__scikit-learn-10870

Devin 最初被描述所误导，并按照描述字面意思在 return self 之前添加了 self.lower_bound_ = max_lower_bound。这实际上是不正确的，因为该变量尚未定义。

作为 issue 描述中提供的测试代码，Devin 随后更新了测试文件：

但在运行测试并收到错误后，Devin 修正了该文件：

在此修复之后，Devin 重新运行测试使其通过并成功退出。

这个示例之所以有趣，有几个原因：

• Devin 极其严格地遵循原始 issue 中的指令，尽管这些指令并不准确。这表明其与用户偏好过度对齐。
• 凭借在其环境中运行测试的能力，Devin 能够纠正自己的错误。软件开发人员能够迭代至关重要，agent 也应该能够做到同样的事情。

示例 2：✅ django__django-10973

Devin 识别出正确的文件 django/db/backends/postgresql/client.py，并进行了完整的编辑：

在这里，Devin 能够成功修改一大段代码。SWE-bench 中许多成功的编辑都是单行 diff，但 Devin 能够一次处理多行。

示例 3：❌ sympy__sympy-17313

这是一项困难的任务，涉及修改计算机代数系统，以正确处理 floor 和 ceiling 对象上针对可指定为正或负的值的比较运算符。它需要复杂的逻辑推理和多个推导步骤。

Devin 错过了要编辑的正确类，编辑了 frac 类而不是 floor 类和 ceiling 类。除此之外，Devin 只编辑了其中一个比较运算符 __gt__，而 __lt__、__le__ 和 __ge__ 也需要修改。这次编辑与正确结果相差甚远。

正确的 diff 可以在这里找到：
https://github.com/sympy/sympy/pull/17313/files。这个 diff 相当复杂，包含大量边界情况处理和大量单元测试，并且需要对 sympy 代码库有深入理解。（注意，必须通过每一个测试才能通过 SWE-bench 实例。）

示例 4：❌ scikit-learn__scikit-learn-10774

这个任务涉及为仓库中的所有数据集添加额外的返回选项功能。Devin 能够成功为其中几个数据集完成这一修改；下面展示了一个示例。

Devin 设法为数据集 california_housing.py、covtype.py、kddcup99.py 和 mldata.py（原始 PR 实际上排除了这个）做了类似的修改。遗憾的是，Devin 漏掉了其中两个数据集 lfw.py 和 rcv1.py，因此测试最终失败。我们打算提升 Devin 编辑多个文件的能力。

测试驱动实验

我们进行了一项额外实验，向 Devin 提供最终单元测试以及问题陈述。在这种“测试驱动开发”设置下，在 100 个抽样测试中，成功通过率提高到 23%。（注意，在评估之前，对测试本身所做的任何更改都会被抹除。）

这一结果无法与 SWE-bench 的其他结果相比较，因为智能体能够访问真实测试补丁。尽管如此，测试驱动开发是软件工程中的一种常见模式，因此这一设置是 SWE-bench 的自然扩展。人类给智能体一个有针对性的测试让其通过，是人类工程师与智能体协作的一种自然方式，我们预计未来会看到更多测试驱动的智能体。

Devin 借助测试新解决的问题示例
✅ django__django-13321：

Devin 通过在函数前添加一条 print 语句，然后运行单元测试，再根据 print 语句编辑文件，从而解决了这个问题。测试用例的存在让 Devin 更容易调试。

✅ django__django-16983：新的单元测试断言会输出一条确切的错误消息：“The value of 'filter_horizontal[0]' cannot include […]”。如果事先不知道错误的确切措辞，就不可能通过测试。这凸显了该基准测试的一个问题，并表明没有测试补丁就不可能获得满分。

注意事项

鉴于基准测试中开源仓库的流行程度，Devin 的底层模型会包含来自这些仓库的数据。然而，我们用来比较的基线（Claude、GPT、Llama 等）也面临类似的数据污染问题。

此外，还需要付出努力来防止智能体找到关于这些 PR 的外部信息并可能复制 diff。在测试设置期间，我们会移除仓库的 Github 远程以及所有未来提交，这样智能体就无法直接访问它们。具有互联网访问权限的智能体可能会通过其他方法找到外部信息；我们已经手动检查了 Devin 的成功运行，以确保没有发生这种情况。

展望未来

智能体仍处于早期阶段，还有很大的改进空间。在 Cognition，我们相信智能体将在不久的将来大幅改进。我们很高兴看到 SWE-bench 以及针对数据分析、信息浏览等任务的新基准测试取得进展。

帮助我们推动推理与规划的前沿。我们正在招聘！