【AI论文】SWE-Factory：您的自动化工厂，提供问题解决培训数据和评估基准

摘要：为GitHub问题解决任务构建大规模数据集，对于训练和评估大型语言模型（LLMs）的软件工程能力至关重要。然而，创建此类基准的传统过程极具挑战性且劳动密集，尤其是在搭建评估环境、评定测试结果以及验证任务实例这些阶段。在本文中，我们提出了SWE-Factory，这是一个旨在应对这些挑战的自动化流水线。为解决这些问题，我们的流水线集成了三个核心自动化组件。首先，我们引入了SWE-Builder，这是一个多智能体系统，用于自动化评估环境的搭建，它采用了四个专业化智能体，这些智能体以协作、迭代的方式工作，并利用环境记忆池来提高效率。其次，我们引入了一种基于退出代码的标准化评分方法，该方法无需手动编写自定义解析器。最后，我们利用这些可靠的退出代码信号，自动化了fail2pass验证过程。针对四种编程语言中的671个问题进行的实验表明，我们的流水线能够有效地构建有效的任务实例；例如，使用GPT-4.1-mini时，我们的SWE-Builder以每个实例0.045的成本构建了269个有效实例，而使用Gemini-2.5-flash时，它在每个实例成本最低为0.024的情况下实现了相当的性能。我们还证明，与人工检查相比，我们基于退出代码的评分方法实现了100%的准确率，而我们的自动化fail2pass验证的精确度达到了0.92，召回率达到了1.00。我们希望我们的自动化流水线能够加速大规模、高质量GitHub问题解决数据集的收集，以用于训练和评估。我们的代码和数据集已在Github。Huggingface链接：Paper page，论文链接：2506.10954

研究背景和目的

研究背景

随着大型语言模型（LLMs）在软件工程领域的广泛应用，为GitHub问题解决任务构建大规模数据集变得至关重要。这些数据集不仅用于训练LLMs，以提升其解决实际软件问题的能力，还用于评估这些模型在真实场景下的表现。然而，传统的方法在创建此类基准数据集时面临诸多挑战，特别是在设置评估环境、评定测试结果以及验证任务实例这些关键阶段。这些过程往往需要大量的人工干预，不仅效率低下，而且容易出错，从而影响了数据集的质量和可用性。

具体而言，传统方法在构建评估环境时，需要手动编写环境配置脚本和测试脚本，这要求开发者对项目结构和依赖关系有深入的了解。此外，由于不同项目的环境和测试要求各异，手动配置的过程难以标准化和自动化，导致环境搭建的一致性和可重复性难以保证。在评定测试结果时，传统方法通常需要开发者编写自定义的解析器来解析测试日志，以提取测试结果。然而，由于测试日志的格式和内容因项目而异，解析器的编写过程复杂且容易出错，影响了结果评定的准确性和效率。最后，在验证任务实例时，传统方法通常需要人工检查测试前后的日志，以确认测试是否从失败变为成功（即fail2pass验证）。这一过程同样劳动密集且容易出错，因为人工检查可能受到主观因素的影响，导致验证结果的不一致。

研究目的

针对上述挑战，本文提出了SWE-Factory，这是一个旨在自动化GitHub问题解决任务数据集构建过程的流水线。具体而言，研究目的包括：

1. 自动化评估环境搭建：通过引入SWE-Builder，一个基于多智能体的系统，自动化评估环境的搭建过程。SWE-Builder通过协作、迭代的方式工作，利用环境记忆池来提高效率，减少人工干预。

2. 标准化评分方法：引入一种基于退出代码的标准化评分方法，消除手动编写自定义解析器的需求。这种方法通过捕获测试命令的退出代码来确定测试结果，简化了评分过程，提高了评定的准确性和效率。

3. 自动化fail2pass验证：利用可靠的退出代码信号，自动化fail2pass验证过程。这一过程确保只有那些在应用补丁前后测试结果从失败变为成功的任务实例被保留，提高了数据集的质量。

4. 大规模、高质量数据集的构建：通过自动化上述过程，加速大规模、高质量GitHub问题解决数据集的收集，以用于训练和评估LLMs。

研究方法

为了实现上述研究目的，本文采用了以下研究方法：

1. SWE-Builder的设计与实现：

   • 多智能体系统：SWE-Builder由四个专业化智能体组成，包括仓库探索器、环境管理器、测试管理器和测试分析师。这些智能体以协作、迭代的方式工作，共同完成评估环境的搭建。

   • 环境记忆池：利用环境记忆池来重用之前成功的环境搭建配置，提高效率和一致性。记忆池中存储了之前成功搭建的环境的Dockerfile和测试脚本，当需要搭建类似环境时，可以从记忆池中检索相关配置进行重用。

   • 迭代优化过程：SWE-Builder的工作流程是一个迭代过程，通过不断收集反馈、优化配置来完善评估环境。在每次迭代中，仓库探索器收集环境搭建信息，环境管理器生成Dockerfile，测试管理器编写测试脚本，测试分析师验证环境的有效性。如果验证失败，测试分析师会提供反馈，指导相关智能体进行修正。

2. 基于退出代码的评分方法：

   • 退出代码捕获：在测试脚本中添加命令来捕获测试命令的退出代码，并将其以标准化格式报告。这样，无论测试框架的输出格式如何变化，都可以通过解析退出代码来确定测试结果。

   • 评分逻辑集成：将评分逻辑直接集成到测试脚本中，简化了评分过程。测试脚本在执行完成后会打印一个唯一的标记到输出日志中，包含退出代码信息。评分系统通过解析这个标记来确定测试结果。

3. 自动化fail2pass验证：

   • 测试前后对比：在应用补丁前后分别执行测试脚本，并记录退出代码。如果应用补丁前测试失败（退出代码非零），应用补丁后测试成功（退出代码为零），则认为该任务实例满足fail2pass条件。

   • 人工验证辅助：尽管自动化验证过程能够过滤出大部分符合条件的任务实例，但为了确保数据集的质量，仍需要进行人工验证。人工验证主要关注那些自动化验证过程中可能遗漏或误判的特殊情况。

4. 实验设计与评估：

   • 数据集构建：从12个开源仓库中收集了2441个问题，构建了SweSetupBench数据集。为了评估效率，还构建了一个更小的子集SweSetupBench-lite，包含671个问题。

   • 模型选择与评估指标：选择了三个成本效益高的LLMs（GPT-4.1-mini、Gemini-2.5-flash和DeepSeek-v3）进行评估。评估指标包括成功率（成功生成完整评估环境的任务比例）、有效率（通过严格人工验证的任务比例）、处理时间、成本和平均迭代次数。

   • 实验执行与结果分析：在实验中执行了SWE-Factory流水线，并记录了相关指标。通过对比不同模型和不同编程语言下的表现，分析了SWE-Factory的性能和局限性。

研究结果

通过实验评估，本文得到了以下研究结果：

1. SWE-Builder的有效性：

   • 在SweSetupBench-lite数据集上，使用GPT-4.1-mini时，SWE-Builder的成功率为57.2%，有效率为40.1%。这意味着在671个问题中，SWE-Builder成功生成了384个完整评估环境，其中269个通过了严格的人工验证。

   • 不同模型在处理不同编程语言的问题时表现出差异。例如，DeepSeek-v3在Python任务上表现出色（成功率为71.2%，有效率为43.4%），而GPT-4.1-mini在TypeScript任务上领先（成功率为64.8%，有效率为54.0%）。

2. 基于退出代码的评分方法的准确性：

   • 通过手动检查1059个独特评估环境生成的测试报告（共2118次测试运行），发现基于退出代码的评分方法与手动检查之间达到了100%的一致性。这证明了该方法在评定测试结果时的准确性和可靠性。

3. 自动化fail2pass验证的性能：

   • 在自动化fail2pass验证过程中，使用退出代码作为过滤标准取得了高精度和高召回率。例如，在DeepSeek-v3上，精度为93%，召回率为100%；在GPT-4.1-mini上，精度和召回率均为93%；在Gemini-2.5-flash上，精度为90%，召回率为100%。

   • 尽管自动化验证过程取得了高精度和高召回率，但仍存在少量误判情况。这些误判主要是由于“error2pass”现象引起的，即测试在应用补丁前无法执行，但在应用补丁后可以执行并成功。为了确保数据集的质量，仍需要进行人工验证来过滤掉这些特殊情况。

4. 成本效益分析：

   • 不同模型在处理任务时的成本效益各异。例如，Gemini-2.5-flash以最低的成本（每个任务0.024美元）实现了49.8%的成功率和33.5%的有效率，而GPT-4.1-mini虽然成本较高（每个任务0.045美元），但实现了更高的成功率和有效率。

研究局限

尽管SWE-Factory在自动化GitHub问题解决任务数据集构建方面取得了显著进展，但仍存在以下研究局限：

1. 对特定测试框架的依赖：

   • 基于退出代码的评分方法依赖于测试框架能够正确返回退出代码。如果测试框架在执行过程中崩溃或无法正确返回退出代码，则该方法可能无法准确评定测试结果。

2. “error2pass”现象的过滤：

   • 尽管自动化fail2pass验证过程能够过滤出大部分符合条件的任务实例，但仍无法完全避免“error2pass”现象的误判。这些特殊情况需要人工验证来过滤掉，以确保数据集的质量。

3. 多语言支持的局限性：

   • 虽然SWE-Factory支持多种编程语言，但在处理某些特定语言或框架的问题时可能仍存在挑战。例如，某些语言或框架可能有特殊的测试要求或环境配置方式，需要进一步优化SWE-Builder来适应这些情况。

4. 计算资源的消耗：

   • 运行LLMs进行环境搭建和测试评定需要消耗大量的计算资源。特别是在处理大规模数据集时，计算资源的消耗可能成为一个限制因素。未来需要进一步优化算法和流程来降低计算资源的消耗。

未来研究方向

针对上述研究局限和挑战，未来可以从以下几个方面进行深入研究：

1. 扩展评分方法的适用性：

   • 研究如何扩展基于退出代码的评分方法的适用性，使其能够处理更多种类的测试框架和输出格式。例如，可以开发一种通用的日志解析器来解析不同格式的测试日志，并从中提取测试结果。

2. 优化自动化fail2pass验证过程：

   • 进一步优化自动化fail2pass验证过程，减少误判情况的发生。例如，可以引入更复杂的模式匹配算法来识别“error2pass”现象，并自动过滤掉这些特殊情况。同时，可以研究如何结合人工验证和自动化验证来提高验证过程的准确性和效率。

3. 增强多语言支持能力：

   • 针对特定语言或框架的问题进行深入研究，优化SWE-Builder的环境搭建和测试评定能力。例如，可以开发针对特定语言或框架的插件或扩展包来增强SWE-Factory的功能。同时，可以探索如何利用迁移学习等技术来提高模型在不同语言或框架下的泛化能力。

4. 降低计算资源消耗：

   • 研究如何降低运行LLMs进行环境搭建和测试评定时的计算资源消耗。例如，可以优化算法和流程来减少不必要的计算步骤和重复工作。同时，可以探索利用云计算和分布式计算等技术来提高计算资源的利用率和效率。

5. 构建更全面的数据集：

   • 进一步扩大数据集的规模和覆盖范围，包括更多种类的编程语言、框架和问题类型。同时，可以注重数据集的多样性和平衡性，以确保模型在不同场景下的泛化能力和鲁棒性。

6. 探索与其他技术的结合：

   • 研究如何将SWE-Factory与其他技术（如持续集成/持续部署（CI/CD）流程、自动化测试工具等）相结合，以进一步提高软件开发的效率和质量。例如，可以将SWE-Factory集成到CI/CD流程中，实现自动化测试和评估环境的搭建和验证。