论文翻译：R2E:将任何 GitHub 仓库转换为编程代理环境

原文链接：https://openreview.net/pdf?id=kXHgEYFyf3

R2E: 将任何 GitHub 仓库转换为编程代理环境

Naman Jain Manish Shetty Tianjun Zhang King Han Koushik Sen Ion Stoica

摘要

虽然大型语言模型（LLMs）的编码能力迅速发展，但相应的真实编程环境评估基准尚未跟上步伐。构建一个可扩展且互动的测试平台，用于评估通用 AI 编程代理在真实代码中的表现一直具有挑战性，主要是因为缺乏高质量的测试套件。在本文中，我们提出了 Repository to Environment (R2E)，这是一个框架，可以将任何 GITHUB 仓库转变为测试环境，以评估代码生成系统（包括静态和交互式）的性能。R2E 结合了程序分析和 LLMs 的协同作用，构建了任何 GITHUB 函数的等效测试工具。我们实例化了我们的框架，构建了第一个大规模基准 R2E-Eval1，用于构建 AI 编程助手的真实环境。我们的结果表明，即使 SOTA 模型无法通过高级提示技术生成正确的解决方案，它们也能有效地利用环境反馈，这突显了从静态功能编码向互动编程范式转变的必要性。我们希望我们的框架（和实例化的基准）能够通过提供网络规模的开放式编码环境来激发研究方向。R2E 代码可在 https://r2e.dev/ 获取。

1. 引言

LLMs 在代码相关任务上的性能快速提高，使得在现实世界中部署的编码助手得以发展。然而，对这种真实编码环境的评估并未跟上步伐。之前的基准（Chen 等人，2021；Wang 等人，2022b）用于评估 LLMs 的编码能力，仅包含简短且孤立的功能代码补全问题。而另一方面，真实的软件工程需要更复杂的工作流程，包括与现有（大型）代码库的集成、使用库、与解释器互动、调试错误等。在这项工作中，为了捕捉这种互动方面（与一次性代码生成相对），我们将编程代理视为能够使用解释器和错误反馈来根据规范改进其自身输出的 AI 系统。随着这种编程代理变得越来越强大，迫切需要建立真实的测试环境来评估它们。

在这项工作中，我们提出了 Repository to Environment (R2E)，这是一个可扩展的框架，可以将任何 GitHub 仓库转变为测试环境，以评估代码生成系统在真实场景中的性能。我们基于一个关键见解，即如果为真实代码合成测试套件，它们可以作为检查和执行引导编程环境的协调者。R2E 从 GITHUB 中获取一个函数，构建一个等效测试工具——一个包含测试用例和建立函数执行依赖关系的设置的脚手架。R2E 进一步完善了文档字符串，并使用改进的规范以及仓库代码和测试工具作为研究代码生成问题的实例。图1 提供了我们方法的端到端图。

这些环境有两个评估目的：首先，代码生成系统可以在这些真实场景中通过环境进行评估。其次，即使对于一个互动编程代理，我们的环境也可以通过解释器提供反馈给代理（图1 右侧）。值得注意的是，R2E 框架是可扩展的，可以用于构建网络规模的开放域编码数据集。此外，R2E 需要最少的人类监督，并且可以实时更新，以进行无污染的评估。

使用这个框架，我们构建了 R2E-Eval1（第4 节），这是第一个由自然语言文档字符串、仓库上下文和等效测试工具组成的大规模真实编码问题基准。图2 显示了一个函数和相应的合成测试工具的示例。

2. 背景

我们的 R2E 管道由程序分析和 LLMs 的协同作用驱动。这里，我们提供以下章节中使用的一些概念的背景。

测试。功能正确性的测试不仅仅是输入输出对，还包括真实软件依赖的更广泛的依赖关系。测试工具通过结合测试用例（定义输入和期望输出）和设置（建立操作条件和依赖关系如配置文件）来封装这一点。测试工具的复杂性，如图2 所示，超过了之前基准（如 HUMANEVAL (Chen 等人，2021)）中的简单输入输出示例。例如，在图2 中，测试工具包含程序期望成功运行所需的文件目录设置（即文件系统依赖关系）。

代码覆盖率。测试的质量通常通过其覆盖率来衡量——它所执行的代码元素（例如语句或分支）的比例（Ivanković 等人，2019）。例如，一个执行函数所有代码行的测试被认为具有100% 的行覆盖率。高覆盖率是理想的，以确保函数得到充分测试。我们使用分支覆盖率来评估我们的测试质量，因为它比行覆盖率提供了更细粒度的衡量标准。

程序分析用于切片上下文。为了有效地测试仓库代码，我们必须理解函数的操作上下文，包括它交互的函数和全局变量。我们使用依赖切片来构建这个上下文，将函数 f 的切片 Df 定义为 f 调用的函数 F’ 和 f 访问的全局变量 G’ 的集合，包括直接和间接调用。图2 左上角显示了一个为函数 indexer 提取的依赖切片示例，作为理解函数行为的最小上下文。结果切片 Df 提供了理解 f 行为的最小上下文，并指示其在仓库中的连通性，以切片大小 |Df| 量化。计算切片的详细信息在附录A 中。

3. R2E 框架

GITHUB 是一个丰富的现实代码问题数据源，但现实中的仓库可能非常嘈杂、难以运行且维护不善。我们在这里提出 R2E，这是一个自动化框架，可以将任何 GitHub 仓库转变为测试环境，以评估代码生成系统在真实代码上的性能。

第3.1 节详细描述了我们最初的问题策划过程。第3.2 节描述了我们的测试工具合成方法。我们在第3.3 节评估了我们合成测试的质量。最后，我们描述了如何改进问题规范，以构建高质量基准（第3.4 节）。

3.1. 问题策划

3.1.1. 仓库策划

我们抓取了2022 年7 月之后创建的 GITHUB 上的 PYTHON 仓库，这些仓库非分叉，至少有40 颗星，并且包含 toml 或 setup.py 文件。这个日期与 OpenAI 模型 GPT-3.5-TURBO 和 GPT-4 的报告截止数据对齐，因此防止了污染。接下来，我们过滤掉了之前迭代过程中一些失败的仓库。我们将每个仓库保存在一个通用的 Docker 镜像中。我们使用 pdm3 和 pip install 命令构建它们，尽可能使用跨仓库包缓存，以减少内存占用。此外，我们使用 pipreqs 添加 toml、setup 或要求文件中缺少的依赖项。最后，我们尽可能半手动安装不可安装的仓库，最终得到一个安装了429 个仓库的 docker，总大小超过400 GB。

3.1.2. 函数策划

我们首先从收集的仓库中提取所有函数（和方法），以识别适合自然语言驱动的代码生成和功能正确性评估的问题。特别是，我们过滤掉了没有文档字符串的函数，以确保我们有一个等效的自然语言提示。然后，我们应用基于关键字的过滤器，排除与 GPU、云任务等相关的函数，因为它们不利于标准的功能正确性评估。我们通过其连通性（详见第2 节）估计函数的复杂性。我们过滤掉了不调用仓库中其他组件的函数。我们在附录中提供了应用的过滤器的更全面列表。通过这些阶段的过滤，我们从429 个仓库中收集了9825 个候选问题。

3.2. 测试工具生成：环境的关键

GitHub 仓库缺乏评估代码生成所需的高质量测试，因此需要自动化测试工具生成，以大规模收集问题。

如果生成了这些测试，它们可以作为检查和引导执行编程代理的协调者。作为检查，它们可以评估生成代码的功能正确性。测试还支持代码生成以外的应用，如重构、优化和转码，其中测试可以检查变换后的程序是否等价于原始程序。最后，作为协调者，它们可以运行生成的代码，捕获编译器反馈，启用修复等。

为了解决这个问题，R2E 结合了程序分析和 LLM 提示，合成了任意 GitHub 代码的测试。下面，我们总结了 R2E 测试生成方法的一些关键设计选择。

等效测试，而不是输出预测。R2E 将测试输出与输入分离。相反，它使用原始函数作为参考实现来生成预期输出。这一关键见解大大简化了测试生成，因为它消除了预测输出的需求。因此，我们生成了等效测试——它们检查原始函数和生成函数在给定输入集上的输出是否等效。

工具，而不是 I/O 对。R2E 为每个函数生成等效测试工具（第2 节），其中包含测试用例和所需设置，如数据库连接、外部文件、配置等，使其能够在现实环境中运行函数。这与传统基准（如 HUMANEVAL (Chen et al., 2021)）中的原始类型 I/O 示例有所不同。这是必要的，因为现实代码通常需要的不仅仅是简单的输入参数。它们可能需要多个依赖项，如访问文件、环境变量、API 和用户定义的函数或类。

切片上下文，而不是整个仓库。LLM 测试生成在之前的工作中（如 HUMANEVAL+ (Liu et al., 2023b)）对简单的孤立函数有效。然而，在仓库设置中，仅提供函数是不足够的，而提供整个仓库则成本高昂。R2E 使用一种新颖的依赖切片提示方法，提取生成测试所需的最小仓库上下文。如第2 节所述，它找到函数直接或间接依赖的函数和全局变量。

执行和覆盖质量控制。最近的研究表明，基于执行的基准由于低质量测试而可能存在缺陷（Liu et al., 2023b）。为避免这种情况，我们在为仓库构建的 Docker 容器中执行生成的测试工具。在“自等效”模式下运行等效测试，因此被测试的函数和参考实现相同。因缺少包等问题导致的无效工具被排除。一个（等效）测试工具被认为是有效的，如果所有（等效）测试都通过。我们进一步强调使用分支覆盖率（第2 节）来衡量测试用例的质量。这一检查对于确保生成的测试覆盖函数的完整行为并可用于检查功能等效性至关重要。

我们将设计决策编码为提示指南，提示 GPT-4-TURBO 并使用切片上下文生成高质量测试工具。图2 显示了处理复杂数据类型和独特设置的生成工具，具体取决于函数的要求。附录中列出了测试生成的附加指南。

3.3. 测试工具评估

3.3.1. 实验设置

我们从两个方面评估等效测试工具生成。首先，测量有效性，即是否执行原始函数并通过所有等效测试？然后，我们还通过分支覆盖率（第2 节）评估质量，以识别测试覆盖函数行为的程度，这是等效性检查的关键属性。

我们考虑两种广泛的测试生成策略：输出预测和等效性。等效性测试生成方法在运行时使用真实函数实现来获取预期输出。另一方面，输出预测方法试图生成测试的输入和预期输出，这是一种更难的问题。此外，我们研究了在仓库上下文中不同的上下文创建策略：简单、完整和切片。简单策略提示包含函数但没有上下文。完整策略提供包含函数的文件及其导入的所有文件（直到6000 个令牌限制）。最后，切片策略实现了我们提出的依赖切片方法，提供函数所需的最小上下文。我们在两个问题设置中比较这些策略：（1）文件内：被测试函数仅依赖于其文件中的上下文，（2）文件外：它依赖于仓库中的外部文件。我们使用最先进的 GPT-4-TURBO 模型生成所有测试。附录 B 中详细说明了我们的设置、模型和提示。

3.3.2. 有效性和质量结果

表1 显示了我们评估的结果。

等效性测试优于输出预测。根据设计（第3.2 节），R2E 生成等效性测试，通过使用原始函数作为参考实现来生成预期输出，从而将测试输出与输入分离。这显著提高了生成的有效测试数量（约20%），与通过 LLM 预测预期输出生成的测试相比。

集中上下文提高覆盖率。简单策略在有效性方面表现相对较差（低至19%），但生成的有效测试工具具有高覆盖率（约88%）。例如，由于缺乏必要的上下文，简单生成的测试往往未能生成正确的输入参数类型（如架构或自定义类）。

广泛上下文提高有效性。另一方面，完整策略生成的有效测试更多（高达51.7%），但覆盖率较低（77.2%）。这表明，集中的上下文在涵盖函数的边缘案例方面更有效，但广泛的上下文对于理解函数的依赖性是必要的。

我们的切片策略在两者之间取得了良好的平衡，并在有效性和覆盖率方面达到了最佳结果。总体而言，我们观察到，R2E 的依赖切片策略生成了约44% 的有效测试工具，具有高达约83% 的代码覆盖率。

3.3.3. 失败模式

我们收集并分类了无效的等效测试工具，并研究它们的失败模式。我们发现40% 的错误是由于 ValueErrors 和 TypeErrors，反映了测试中不正确的键、属性或类型使用。此外，15% 是 DataFormatErrors，由不正确的数据格式或架构引起，突显了测试 GITHUB 代码的复杂性超出原始类型。

断言错误（预期和实际输出不匹配）占了显著的25% 错误，显示了现实代码中功能正确性的细微方面。尽管 R2E 简化为等效测试，但断言通常需要比简单检查相等性更细粒度。例如，检查类属性、数据框中的列等需要对代码和仓库上下文有更深入的理解。最后，环境错误（21%），如操作系统和文件系统错误，表明测试环境配置的挑战。

3.4. 规范的改进

GITHUB 仓库中的自然语言文档字符串可能未充分指定，无法用于代码生成。这里，我们使用自动化方法，通过模型改进文档字符串，提供额外上下文，如原始文档字符串、合成的测试工具、参数类型和从运行测试工具中构建的序列化输入输出参数。轶事和相关工作表明，提供执行输出可以让模型更好地理解函数语义，从而生成更高质量的文档字符串。附录 C 提供了所使用的提示。

我们进一步研究了子集中改进文档字符串的质量（附录 C.1）。最后，我们进行了严格的手动评估，并过滤了规范较差或模糊的问题（进一步详述）。

4. R2E-Eval1 基准

在第3 节中，我们展示了 R2E 使构建用于编程代理的执行测试环境成为可能。R2E 从代码库中获取一个函数并将其转换为一个元组 I = {D, R, T}，其中 D 是函数的改进文档字符串，R 是代码库的其余部分，T 是生成的测试工具。

我们实例化了这个框架，构建了 R2E-Eval1，这是第一个具有功能正确性测试的真实代码生成问题的大规模数据集。表2 将 R2E-Eval1 与几个用于评估 LLMs 代码生成能力的流行基准进行了比较。之前的工作如 HUMANEVAL (Chen et al., 2021) 和 ODEX (Wang et al., 2022b) 支持基于执行的度量，但针对的是没有真实仓库设置的孤立简单问题。最近关于仓库级代码生成的工作如 CROSSCODEEVAL (Ding et al., 2023)、REPOBENCH (Liu et al., 2023c) 和 REPOEVAL (Zhang et al., 2023d) 使用了仓库上下文，但要么放弃了基于执行的评估，要么严重依赖人类编写的测试，而这些在 GITHUB 上很少能大规模获得

。R2E-Eval1 是唯一可执行的基准，具有仓库上下文，并且是自动化的，实现了可扩展性。接下来，我们描述了 R2E-Eval1 的构建和分析。

4.1. 基准构建

4.1.1. 数据集质量

我们在这项工作中非常重视问题的质量。质量在这里意味着函数、文档字符串和测试用例写得如何。为确保这一点，我们仅考虑具有高分支覆盖率的函数。我们的最终基准问题平均有11.5 个测试用例，平均分支覆盖率为92.2%。另外一轮手动检查帮助我们选择了高质量的问题。手动评估过程中，我们寻找以下特征：

(a) 文档字符串清晰且定义明确
(b) 文档字符串与原始函数和生成的测试意图相符，识别关键功能
© 模型生成的失败和成功实际上对应问题意图（类似于 Cassano 等人 (2023) 使用的过程）

此过程去除了具有任意或特殊边缘案例且无法通过简单文档字符串很好指定的复杂函数。

4.1.2. 数据集组成

我们还考虑了基准中问题的多样性和趣味性。我们识别了几个校准趣味性的代码属性，如依赖项数量、参数类型、行数、使用的库等。

表3 展示了我们基准的统计数据。我们的手动分析还表明，R2E-Eval1 问题在其覆盖的领域方面是多样的：Python 操作（列表、字符串、字典操作）、数据操作（JSON、文件、pandas、numpy）、算法和协议实现（networkx、统计）、特定领域问题（编程语言、网络、量子计算、形式验证、数值计算）等。

我们还确保基准在不同仓库数量方面是多样的，防止偏向于某个代码库或领域。总体而言，这个过程使得 R2E-Eval1 中的246 个问题从137 个仓库中精心挑选出来。

每个问题实例 I 可以通过提供文档字符串 D 评估代码生成系统，并在仓库上下文 R 中通过生成的测试工具 T 评估其响应。

5. R2E：走向编程代理

我们进行实验，了解 LLMS 在现实代码生成上的三个重要问题。

Q1 目前的 LLMS 能在多大程度上解决静态的真实代码生成任务？（第5.1 节）
Q2 典型的 LLM 失败模式是什么？（第5.2 节）
Q3 编程代理范式（如自修复）与静态编程相比表现如何？（第5.3 节）

我们的结果表明，尽管在 HUMANEVAL 上表现很高，SOTA LLM 模型（GPT-4）在 R2E-Eval1 中只能达到约50% 的表现。通过分析，我们发现 LLMS 在理解现有函数接口和推理复杂对象方面存在困难。最后，我们比较了静态编码方法（如 COT）与提出的互动编程范式，证明了后者的显著优势。

5.1. 静态代码生成

首先，我们研究了在 R2E-Eval1 数据集上直接代码生成，即不进行交互的代码生成。由于测试工具生成方法，我们对生成的代码进行了功能正确性评估。这与之前的工作（Liu 等人，2023c；Ding 等人，2023）依赖执行自由的精确匹配度量来评估仓库设置中的代码补全形成对比，这种方法可能不可靠并限制了评估的范围。

我们使用 PASS@1 评估功能正确性，通过为每个问题实例生成5 个候选补全并计算通过测试工具的比例。我们考虑了几种封闭访问和开放访问的模型进行实验——GPT-4、GPT-3.5-TURBO、CODELLAMA-7B、CODELLAMA-13B 和 CODELLAMA-34B。由于 GPT-4 和 GPT-3.5-TURBO 是指令调优模型，我们对它们使用聊天样式提示，而对 CODELLAMA 模型使用代码补全提示。附录 E 进一步详细说明了我们的设置、模型和提示。

污染。GPT-4 和 GPT-3.5-TURBO 的截止日期为2021 年，因此在我们的基准上未受污染，因为我们从2022 年8 月后创建的仓库中策划了问题（见第3.1 节）。

给定我们基准中的问题实例 I = {D, R, T}，我们需要使用剩余的仓库上下文生成代码。由于整个仓库上下文可能非常大，我们检索内容以提供给模型（详细见下文）。我们首先评估当前模型在我们的基准上表现如何，然后研究检索选择如何影响性能。接下来，我们研究使用链式思维提示（COT）（Wei 等人，2022）在更难任务中改善模型性能的效果。

模型性能。图3 比较了各种模型在我们基准上使用 PASS@1 的表现（图中使用 CL 代表 CODELLAMA 以简洁）。我们发现各种模型的表现比其他基准如 HUMANEVAL 相对较低。这是预期的，因为我们的基准代表了从 GITHUB 收集的更具挑战性的真实问题，要求在生成代码之前理解现有的仓库上下文。我们发现 GPT-4 明显优于所有其他模型，PASS@1 接近50%，而其他模型的 PASS@1 仅在30% 左右。

检索的效果。我们研究了函数定义检索与依赖切片（第2 节）对真实函数的函数使用检索的效果。具体来说，仅提供必要定义的依赖上下文，而完整上下文设置添加了文件的其余部分和其他文件，直到6000 个令牌限制。图3 比较了这两种设置。

两种检索方法的表现相似，在大多数模型上实现了±1% 的彼此性能。更详细地看，我们发现非重叠问题的皮尔逊相关系数为0.48。我们发现依赖上下文与完整上下文之间提供了一个有趣的权衡。一方面，依赖上下文提供了模型相关函数实现的更集中视图。与此同时，函数使用（存在于完整上下文中）经常被重用，使模型能够直接复制它。详见附录 F.1 的更详细讨论和示例。最后，我们相信 R2E-Eval1 提供了一个独特的机会，以启用执行进行研究。

COT 的效果。我们研究了更好的提示策略，研究了零样本和双样本 COT 提示，这些提示在生成代码之前为函数实现绘制了计划。我们对 instruct GPT-3.5-TURBO 和 GPT-4 模型进行了研究，但发现 COT 类设置并不能改善直接提示的性能（见附录表7）。

5.2. 模型行为与失败分析

问题复杂度的表现。我们使用（1）真实实现中的令牌数和（2）真实实现中使用的依赖数量6 来衡量问题实例的复杂度。我们发现这两项度量与模型的 PASS@1 负相关。图4 和图12 展示了模型的 PASS@1 随着依赖数量和令牌数量的变化趋势。

单文件与多文件上下文。我们比较了模型在仅需要生成单个文件的问题与需要生成多个文件的问题上的表现。模型在单文件问题上的表现显著优于多文件问题（图13）。这表明 a）模型在多文件上下文中比在单文件上下文中更困难，b）我们的基准中多文件类别的问题比单文件问题更复杂，这在实际中也有所观察。

不理解提供函数的接口。当提供复杂函数作为上下文时，LLMS 不能理解这些函数的正确输入输出行为，传递错误的输入或期望错误的输出。因此，即使是强大的 LLMS 如 GPT-4 在提供复杂函数上下文时也会犯错。参见列表8。这表明如果提供执行上下文，编程代理可以理解这些接口并表现得更好。

重复 vs 复用代码。抽象是编写好代码的重要组成部分。然而，LLMS 倾向于重复代码而不是使用现有上下文。特别是，当提供上下文中的某些现有函数时，模型重新实现相同的功能而不是直接使用它。参见列表2 和3 的示例。这与关于 copilot 如何影响代码质量的发现一致（Blog.）。

5.3. 自修复代理

到目前为止，我们描述了使用直接代码生成方法在我们的基准上评估模型。然而，测试工具和对解释器的访问使我们能够评估可以与解释器互动并获取反馈的编程代理。具体来说，我们实例化了一个使用测试工具

我们研究在提供（oracle）测试工具的反馈时，LLMS 能否修正自己的错误？我们从基准中抽取了 GPT-4 和 GPT-3.5-TURBO 未生成正确解决方案的56 和48 个实例（详细实验设置见附录

E.2）。我们将模型生成的不正确程序视为初始程序，然后在5 次迭代中向模型提供使用工具的错误反馈。图5 显示了模型在我们基准上随迭代次数变化的自修复率。

首先注意，由于我们仅对模型未生成正确解决方案的失败实例进行抽样，因此 GPT-4 和 GPT-3.5-TURBO 的第0 次迭代得分为0%。接下来，我们发现 GPT-4 达到了33% 的最高自修复率，而 GPT-3.5-TURBO 仅达到20% 的最高自修复率。这表明使用执行、解释器和测试工具，编程代理可以改进代码生成。请注意，虽然高级提示技术并不能改善性能（见附录表7），但使用解释器可以使编程代理实现强大的结果。

6. 相关工作

代码生成基准。代码生成主要通过功能正确性评估，并已在多个领域进行了探索。HUMANEVAL (Chen et al., 2021) 和 MBPP (Austin et al., 2021) 研究了孤立单函数问题上的代码生成。APPS (Hendrycks et al., 2021) 和 CODE-CONTESTS (Li et al., 2022) 基准主要用于评估算法代码生成能力。DS-1000 (Lai et al., 2023)、ARCADE (Yin et al., 2022)、NUMPYEVAL (Zhang et al., 2023b) 和 PANDASEVAL (Jain et al., 2022) 研究数据科学 API 代码生成。最近，Wang 等人（2022b）提出了 ODEX，用于评估带有人类编写的输入输出示例的 API 编码。这些工作在孤立环境中评估代码生成能力，缺乏周围上下文或其他文件的依赖。在对比之下，R2E 编码问题直接从 GITHUB 策划，更类似于现实设置。INTERCODE 和 WEBARENA 提供了特定领域互动编程和网页任务的通用环境。我们提供了一个框架和环境，用于提取自 GITHUB 的互动通用编程任务。

对于仓库设置，以往的工作主要关注执行自由的评估度量，如精确匹配和 BLEU，因缺乏测试工具而进行。CONALA (Yin et al., 2018) 从 STACKOVERFLOW 策划了一个大型数据集，其中包含配对的自然语言和程序片段。Shrivastava 等人（2023b;a）研究了不同的上下文选择方法，用于提示和训练仓库级代码生成的 LLMS。REPOEVAL (Zhang et al., 2023a)、REPOBENCH (Liu et al., 2023c) 和 CROSSCODEEVAL (Ding et al., 2023) 研究了仓库级代码补全。然而，这些工作仅评估短上下文代码生成能力，无执行或功能正确性限制短补全。相比之下，我们使用我们的新颖测试生成方法合成函数级测试工具，并使用它们在仓库代码上执行功能正确性检查。最近，Jimenez 等人（2023）提出了 SWEBENCH，用于评估 LLMS 是否可以解决 GITHUB 问题。然而，他们假设从拉取请求中获得的测试用例防止了大规模收集问题。相比之下，我们的测试工具合成允许从多样化的仓库集中收集问题（137 个仓库对比12 个仓库）。最后，Du 等人（2023）提出了手动策划的 CLASSEVAL，用于评估 LLMS。

其他代码相关任务。除了代码生成之外，自动修复（Chen et al., 2023; Olausson et al., 2023; Madaan et al., 2023b; Peng et al., 2023; Zhang et al., 2023c）、测试生成（Tufano et al., 2022; Watson et al., 2020）、执行（Austin et al., 2021; Liu et al., 2023a; Gu et al., 2024）和优化（Madaan et al., 2023a）等任务也进行了研究。这些任务启用各种代理设置，如 CODET (Chen et al., 2022)、Key 等人（2022）、PARSEL (Zelikman et al., 2023)、FUNSEARCH (Romera-Paredes et al., 2023)、REFLEXION (Shinn et al., 2023)、LEVER (Ni et al., 2023)、CODEPLAN (Bairi et al., 2023)、ALPHACODIUM (Ridnik et al., 2024)、REACT (Yao et al., 2022) 和 TOT (Yao et al., 2023)。

7. 讨论

局限性。自然语言本质上是模棱两可的，文档字符串可能未能很好地指定角落案例。我们试图通过我们的规范改进方法和手动过滤来减轻这一影响。未来的工作可以更广泛地研究这种模棱两可性，并探讨更好的交互机制。接下来，我们使用观测等效性来检查模型生成的候选项在一组输入上的正确性。我们使用分支覆盖率作为评估测试的度量，但这仍然是一个软性检查。未来的工作可以应用变异测试和过采样以进一步提供对生成测试的信心。

结论。

我们提出了 R2E，这是一个可扩展的框架，可以将 GITHUB 仓库转变为编程代理测试环境。通过这个框架构建的 R2E-Eval1 可以评估静态和互动代码生成系统，提供关于模型行为和更好编程工作流程需求的宝贵见解。以往的工作应用拒绝采样和强化学习来提高 LLMS 的编码能力（Singh et al., 2023; Jain et al., 2023; Le et al., 2022）。我们相信 R2E 可以使这些尝试应用于真实程序。同样，R2E 可以收集基于 LLM 的交互跟踪，用于代码生成、调试、优化等任务，进一步用于构建 LLM 代理。

感谢

这项工作得到了美国能源部、科学办公室、高级科学计算研究办公室通过 X-STACK 计划（科学计算编程环境计划（DE-SC0021982））、国家科学基金会（CCF-1900968）和 SKY Lab 工业赞助商和合作伙伴（Astronomer、Google、IBM、Intel、Lacework、Microsoft、Mohamed Bin Zayed University of Artificial Intelligence、Nexla、Samsung SDS、Uber 和 VMware）的支持。

最后，我们感谢 Alex Gu、Wen-Ding Li、Pengcheng Yin、Miltos Allamanis、Michael Pradel、Zijian Wang 和 Sida Wang 对本文的有益意见和反馈。

影响声明
本文的目的是推进机器学习领域。我们的工作可能对社会产生许多潜在影响，但我们认为这里没有必要特别强调。

参考文献
Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., Jiang, E., Cai, C., Terry, M., Le, Q., 等人。使用大型语言模型进行程序合成。arXiv 预印本 arXiv:2108.07732, 2021.

Bairi, R., Sonwane, A., Kanade, A., D C, V., Iyer, A., Parthasarathy, S., Rajamani, S., Ashok, B., 和 Shet, S. Codeplan：使用 LLM 和规划的仓库级编码。在基础模型决策神经信息处理系统研讨会（FMDM-NeurIPS），2023 年11 月。

Bareiß, P., Souza, B., d’Amorim, M., 和 Pradel, M. 几乎免费的代码生成工具？一项关于代码中少量预训练语言模型的研究。arXiv 预印本 arXiv:2206.01335, 2022.

Blog., E. C. 定量评估 GitHub Copilot 对代码质量的影响。https://www.expresscomputer.in/news/quantifying-github-copilots-impact-on-code-quality-ai/104480/.

Cassano, F., Li, L., Sethi, A., Shinn, N., Brennan-Jones, A., Lozhkov, A., Anderson, C., 和 Guha, A. 它能编辑吗？评估大型语言模型遵循代码编辑指令的能力。arXiv 预印本 arXiv:2312.12450, 2023.

Chen, B., Zhang, F., Nguyen, A., Zan, D., Lin, Z., Lou, J.-G., 和 Chen, W. Codet：生成测试的代码生成。arXiv 预印本 arXiv:2207.10397, 2022.

Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. d. O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., 等人。评估训练代码的大型语言模型。arXiv 预印本 arXiv:2107.03374, 2021.

Chen, X., Lin, M., Schärli, N., 和 Zhou, D. 教授大型语言模型自我调试。arXiv 预印本 arXiv:2304.05128, 2023.

Ding, Y., Wang, Z., Ahmad, W. U., Ding, H., Tan, M., Jain, N., Ramanathan, M. K., Nallapati, R., Bhatia, P., Roth, D., 等人。Crosscodeeval：用于跨文件代码补全的多样化多语言基准。arXiv 预印本 arXiv:2310.11248, 2023.

Du, X., Liu, M., Wang, K., Wang, H., Liu, J., Chen, Y., Feng, J., Sha, C., Peng, X., 和 Lou, Y. Classeval：用于评估 LLMs 在类级代码生成上的手工制作基准，2023.

Fraser, G. 和 Arcuri, A. Evosuite：面向面向对象软件的自动测试套件生成。在第19 届 ACM SIGSOFT 研讨会和第13 届欧洲软件工程基础会议论文集，页416–419, 2011.

Fraser, G. 和 Arcuri, A. 整个测试套件生成。IEEE 软件工程汇刊, 39(2):276–291, 2012.

Gu, A., Rozière, B., Leather, H., Solar-Lezama, A., Synnaeve, G., 和 Wang, S. I. Cruxeval：代码推理、理解和执行基准。arXiv 预印本 arXiv:2401.03065, 2024.

Hendrycks, D., Basart, S., Kadavath, S., Mazeika, M., Arora, A., Guo, E., Burns, C., Puranik, S., He, H., Song, D., 等人。使用 APPS 测量编码挑战能力。arXiv 预印本 arXiv:2105.09938, 2021.

Ivanković, M., Petrovic, G., Just, R., 和 Fraser, G. Google 的代码覆盖率。在2019 年第27 届 ACM 联合会议上的欧洲软件工程和软件基础研讨会论文集，页955–963, 2019.

Jain, N., Vaidyanath, S., Iyer, A., Natarajan, N., Parthasarathy, S., Rajamani, S., 和 Sharma, R. Jigsaw：大型语言模型遇见程序合成。在第44 届国际软件工程会议论文集，页1219–1231, 2022.

Jain, N., Zhang, T., Chiang, W.-L., Gonzalez, J. E., Sen, K., 和 Stoica, I. LLM 辅助代码清理，用于训练准确的代码生成器。arXiv 预印本 arXiv:2311.14904, 2023.

Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., 和 Narasimhan, K. Swe-bench：语言模型能解决现实中的 GitHub 问题吗？arXiv 预印本 arXiv:2310.06770, 2023.

Key, D., Li, W.-D., 和 Ellis, K. 我说，你验证：迈向可信的神经程序合成。arXiv 预印本 arXiv:2210.00848, 2022.

Lahiri, S. K., Naik, A., Sakkas, G., Choudhury, P., von Veh, C., Musuvathi, M., Inala, J. P., Wang, C., 和 Gao, J. 通过测试驱动的用户意图正式化进行互动代码生成。arXiv 预印本 arXiv:2208.05950, 2022.

Lai, Y., Li, C., Wang, Y., Zhang, T., Zhong, R., Zettlemoyer, L., Yih, W.-t., Fried, D., Wang, S., 和 Yu, T. DS-1000：自然且可靠的数据科学代码生成基准。在国际机器学习会议论文集，页18319–18345。PMLR, 2023.

Le, H., Wang, Y., Gotmare, A. D., Savarese, S., 和 Hoi, S. C. H. Coderl：通过预训练模型和深度强化学习掌握代码生成。神经信息处理系统进展, 35:21314–21328, 2022.

Lemieux, C., Inala, J. P., Lahiri, S. K., 和 Sen, S. Codamosa：使用预训练的大型语言模型逃脱测试生成中的覆盖率高原。在国际软件工程会议（ICSE）, 2023.

Li, Y., Choi, D., Chung, J., Kushman, N., Schrittwieser, J., Leblond, R., Eccles, T., Keeling, J., Gimeno, F., Dal Lago, A., 等人。使用 Alphacode 进行竞争级代码生成。科学, 378(6624):1092–1097, 2022.

Liu, C., Lu, S., Chen, W., Jiang, D., Svyatkovskiy, A., Fu, S., Sundaresan, N., 和 Duan, N. 使用预训练语言模型进行代码执行。arXiv 预印本 arXiv:2305.05383, 2023a.

Liu, J., Xia, C. S., Wang, Y., 和 Zhang, L. 你的代码是由 ChatGPT 生成的吗？严格评估用于代码生成的大型语言模型。arXiv 预印本 arXiv:2305.01210, 2023b.

Liu, T., Xu, C., 和 McAuley, J. Repobench：用于评估仓库级代码自动补全系统的基准。arXiv 预印本 arXiv:2306.03091, 2023c.

Madaan, A., Shypula, A., Alon, U., Hashemi, M., Ranganathan, P., Yang, Y., Neubig, G., 和 Yazdanbakhsh, A. 学习改进性能的代码编辑。arXiv 预印本 arXiv:2302.07867, 2023a.

Madaan, A., Tandon, N., Gupta, P., Hallinan, S., Gao, L., Wiegreffe, S., Alon, U., Dziri, N., Prabhumoye, S., Yang, Y., 等人。Self-refine：通过自我反馈进行迭代改进。arXiv 预印本 arXiv:2303.17651, 2023b.

Ni, A., Iyer, S., Radev, D., Stoyanov, V., Yih, W.-t., Wang, S., 和 Lin, X. V. Lever：使用执行学习验证语言到代码生成。在国际机器学习会议论文集，页26106–26128。PMLR, 2023.

Olausson, T. X., Inala, J. P., Wang, C., Gao, J., 和 Solar-Lezama, A. 解密 GPT 自我修复代码生成。arXiv 预印本 arXiv:2306.09896, 2023.

Pacheco, C. 和 Ernst, M. D. Randoop：用于 Java 的反馈驱动随机测试。在第22 届 ACM SIGPLAN 会议配套的面向对象程序设计系统和应用会议配套，页815–816, 2007.

Panichella, A., Kifetew, F. M., 和 Tonella, P. 将自动化测试用例生成作为多目标优化问题，并动态选择目标。IEEE 软件工程汇刊, 44(2):122–158, 2017.

Peng, B., Galley, M., He, P., Cheng, H., Xie, Y., Hu, Y., Huang, Q., Liden, L., Yu, Z., Chen, W., 和 Gao, J. 检查你的事实并再试一次：通过外部知识和自动化反馈改进大型语言模型。arXiv 预印本 arXiv:2302.12813, 2023.

Ridnik, T., Kredo, D., 和 Friedman, I. 使用 Alphacodium 进行代码生成：从提示工程到流工程。arXiv 预印本 arXiv:2401.08500, 2024.

Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M. P., Dupont, E., Ruiz, F. J., Ellenberg, J. S., Wang, P., Fawzi, O., 等人。使用大型语言模型进行程序搜索的数学发现。自然, 页1–3, 2023.

Ryder, B. G. 构建程序的调用图。IEEE 软件工程汇刊, (3):216–226, 1979.

Salis, V., Sotiropoulos, T., Louridas, P., Spinellis, D., 和 Mitropoulos, D. Pycg：实用的 Python 调用图生成。在2021 IEEE/ACM 第43 届国际软件工程会议（ICSE），页1646–1657。IEEE, 2021.

Shinn, N., Labash, B., 和 Gopinath, A. Reflexion：具有动态记忆和自我反思的自主代理。arXiv 预印本 arXiv:2303.11366, 2023.

Shrivastava, D., Kocetkov, D., de Vries, H., Bahdanau, D., 和 Scholak, T. Repofusion：训练代码模型以理解你的仓库。arXiv 预印本 arXiv:2306.10998, 2023a.

Shrivastava, D., Larochelle, H., 和 Tarlow, D. 仓库级提示生成，用于大型代码语言模型。在国际机器学习会议论文集，页31693–31715。PMLR, 2023b.

Singh, A., Co-Reyes, J. D., Agarwal, R., Anand, A., Patil, P., Liu, P. J., Harrison, J., Lee, J., Xu, K., Parisi, A., 等人。超越人类数据：扩展自我训练解决问题的大型语言模型。arXiv 预印本 arXiv:2312.06585, 2023.

Tufano, M., Drain, D., Svyatkovskiy, A., Deng, S. K., 和 Sundaresan, N. 使用变压器和焦点上下文生成单元测试用例。arXiv 预印本 arXiv:2009.05617, 2020.

Tufano, M., Deng, S. K., Sundaresan, N., 和 Svyatkovskiy, A. Methods2test：将焦点方法映射到测试用例的数据集。在第19 届国际矿业软件库会议论文集，页299–303, 2022.

Wang, Y., Kordi, Y., Mishra, S., Liu, A., Smith, N. A., Khashabi, D., 和 Hajishirzi, H. 自我指导：使用自生成的指令对齐语言模型。arXiv 预印本 arXiv:2212.10560, 2022a.

Wang, Z., Zhou, S., Fried, D., 和 Neubig, G. 用于开放域代码生成的基于执行的评估。arXiv 预印本 arXiv:2212.10481, 2022b.

Watson, C., Tufano, M., Moran, K., Bavota, G., 和 Poshyvanyk, D. 学习有意义的断言语句用于单元测试。在第42 届 ACM/IEEE 国际软件工程会议论文集，页1398–1409, 2020.

Wei, J., Wang, X., Schuurmans, D., Bosma, M., Xia, F., Chi, E., Le, Q. V., Zhou, D., 等人。链式思维提示引发大型语言模型的推理。神经信息处理系统进展, 35:24824–24837, 2022.

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., 和 Cao, Y. React：在语言模型中协同推理和行动。arXiv 预印本 arXiv:2210.03629, 2022.

Yao, S., Yu, D., Zhao, J., Shafran, I., Griffiths, T. L., Cao, Y., 和 Narasimhan, K. 思维树：使用大型语言模型进行深思熟虑的问题解决。arXiv 预印本 arXiv:2305.10601, 2023.

Yin, P., Deng, B., Chen, E., Vasilescu, B., 和 Neubig, G. 学习从 Stack Overflow 挖掘对齐的代码和自然语言对。在国际矿业软件库会议（MSR），页476–486。ACM, 2018. doi: https://doi.org/10.1145/3196398.3196408.

Yin, P., Li, W.-D., Xiao, K., Rao, A., Wen, Y., Shi, K., Howland, J., Bailey, P., Catasta, M., Michalewski, H., 等人。在互动数据科学笔记本中从自然语言生成代码。arXiv 预印本 arXiv:2212.09248, 2022.

Zelikman, E., Huang, Q., Poesia, G., Goodman, N. D., 和 Haber, N. Parsel：一种（去）分解的框架，用于使用语言模型进行算法推理。arXiv 预印本 arXiv:2212.10561, 2023.

Zhang, F., Chen, B., Zhang, Y., Liu, J., Zan, D., Mao, Y., Lou, J.-G., 和 Chen, W. Repocoder：通过迭代检索和生成进行仓库级代码补全。arXiv 预印本 arXiv:2303.12570, 2023a.

Zhang, K., Li, G., Li, J., Li, Z., 和 Jin, Z. Toolcoder：通过搜索工具教代码生成模型使用 API。arXiv 预印本 arXiv:2305.04032, 2023b.

Zhang, K., Li, Z., Li, J., Li, G., 和 Jin, Z. Self-edit：用于代码生成的故障感知代码编辑器。在第61 届计算语言学协会年会（第1 卷：长文）论文集，页769–787。加拿大多伦多，2023 年7 月。计算语言学协会。

Zhang, T., Yu, T., Hashimoto, T., Lewis, M., Yih, W.-t., Fried, D., 和 Wang, S. 代码审查员重新排序用于代码生成。在国际机器学习会议论文集，页41832–41846。PMLR, 2023d.