中山大学&华为联合提出 Issue Resolution 数据集构建神器SWE-Factory：每条只要$0.024
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
还在为构建高质量的软件Issue解决数据集而头疼吗？
传统方法不仅耗时耗力，成本更是高得离谱。
中山大学和华为联合提出全新的低成本开源解决方案——SWE-Factory，能够通过多智能体框架自动收集Github仓库上的代码，一键打造高质量代码评估数据集。
论文：https ://arxiv. org/abs/2506. 10954
代码：https ://github. com/DeepSoftwareAnalytics/swe-factory
最近，为了测试和提升AI的编程能力，研究者们开发了很多新的工具。
一类是代码能力的评估基准（软件Issue解决数据集），比如有专门用来评估Python代码的SWE-bench、评估多种编程语言代码的OmniGIRL和SWE-benchMultimodal。
还有一类工具提供了完整的训练环境，比如SWE-Gym和SWE-smith，帮助提升这些AI模型的编程技能。
但要做一个能真实反映编程能力的评估基准并不简单。传统的构建流程极其繁琐，高度依赖人工，通常会遇到下面的问题：
手动搭建评估环境：搭建数据集的你可能会苦恼于每个Issue都需要单独配环境，conda/docker配置又困难重重；
编写定制的评分脚本：你可能要为不同项目和测试框架编写专门的解析器，来判断测试结果。
进行繁琐的Fail2pass验证：你可能要对测试环境反复检查，确保这个软件Issue环境能够判断提交代码的对错。
总而言之，在SWE-Factory出现之前，虽然已有的工作在自动化方面取得了显著进展，但始终未能打通数据集构建的\“最后一公里\“，目前，还没有哪个开源工具能从头到尾全自动搞定上面的三个步骤。
而SWE-Factory能自动完成从环境搭建、测试验证到质量评估的全流程，将原本需要数小时的手工配置压缩成泡一杯咖啡的时间，大大提高了评估数据集的构建效率。
在这种背景下，SWE-Factory的出现为全流程自动化构建评估基准走出了一条全新的可行路径，同时也可以帮你自动配置许多场景下的开发环境，可以说是非常方便了。
受GitHub问题解决数据集构建流程的启发，SWE-Factory有四个协作agent角色模拟手动数据收集过程。
这包括四个agent：仓库探索者、环境管理者、测试管理者和测试分析师，提出了一个自动化评估环境构建的多智能体框架SWE-Builder，能够利用多agent进行仓库信息检索、Dockerfile和评估脚本生成，以及迭代测试分析。
为提高效率和一致性，SWE-Builder还引入了记忆池（MemoryPool）来复用成功的环境配置（Dockerfile和测试脚本），通过复用已有配置，避免了从零开始的重复工作，从而加速构建过程。
软件工程中普遍采用的一种惯例是使用进程退出码来指示测试结果，其中零退出码通常表示成功，而非零值表示失败。这一做法被广泛的测试框架所采用，例如pytest、Maven和npm。
SWE-Factory的系统利用这一稳健的惯例来实现自动化评分机制。SWE-Factory的测试管理器将此逻辑直接集成到每个评估脚本中。它附加命令以捕获主测试命令的退出码，并以标准格式报告。
基于退出码的方法相较于需要自定义日志解析器的方法具有显著优势。测试日志的输出格式在不同编程语言、框架和配置之间可能存在巨大差异，使得开发自定义解析器成为一项费时且易出错的任务。相比之下，SWE-Factory的方法为评估测试结果提供了一个统一的接口，从而减少了人工检查或复杂的、特定于问题的解析逻辑。
Fail2pass验证是构建高质量GitHub问题解决数据集的关键步骤。此验证的目的是通过确认每个评估环境_在应用真实Patch之前的测试套件上运行失败（应用前退出码为非零），在应用后运行通过（应用后退出码为0）_来确保评估的有效性。
然而，在传统方法中存在一个主要瓶颈，它通常需要手动检查大量复杂的测试报告来确定Patch前后的结果，这使得Fail2pass验证成为一个极其费力的任务。
SWE-Factory利用基于退出码的评分系统来自动化整个验证过程。它在应用真实Patch之前和之后都执行评估脚本，根据一个简单的规则对每次运行的结果进行分类：退出码为0表示通过，任何非零值表示失败。只有表现出这种清晰的失败到通过转换的实例才会被SWE-Factory保留，确保最终数据集的质量。
名称
Patch应用前的错误码
Patch应用后的错误码
Fail2pass
非零
0
Fail2fail
非零
非零
Pass2pass
0
0
时间：SWE-Factory使用DeepSeek-v3构建Python任务，可以达到13分钟的平均最短构建时间，在多语言任务中使用GPT-4. 1-mini的平均构建时间为22分钟，大幅提高了配置数据集环境的效率。
SWE-Factory构建了一个包含2,441个问题的数据集SweSetupBench，原始数据来自12个开源仓库。所有选中的仓库都是知名的开源项目，每个项目在GitHub上拥有超过2. 5k个星标。这些仓库涵盖四种编程语言——Python、Java、JavaScript和TypeScript。SweSetupBench-lite则包含来自四种编程语言的12个仓库的671个问题。SWE-Factory使用这个子集进行评估。
使用GPT-4. 1-mini：成功构建了671个问题中的269个有效任务实例（40. 1%），平均成本为每个实例0. 045美元。
使用Gemini-2. 5-flash：成功构建了225个有效实例（33. 5%），成本最低为0. 024美元。
使用DeepSeek-v3-0324：生成了232个有效任务实例（34. 6%）。
基于退出码的方法和人工检查结果具高度重合，用这种方法判断提交代码是否正确能够达到100%的准确率。这种方法只需要捕获测试执行后的退出码，而不用解析不同测试框架下的多种日志格式。
基于退出码的方法在识别Fail2pass案例时实现了高召回率（1. 00）和高精确率（DeepSeek为0. 93，GPT为0. 93，Gemini为0. 90）。这表明仅使用退出码是一种有效的自动Fail2pass验证策略。
基于退出码的方法虽然召回率很高，但精确率存在不足。
这项工作发现，这些误报并非简单的\“失败\“，而是一种特殊情况：在应用补丁前，测试因代码存在结构性错误（如导入错误，而不是测试样例不通过）而根本无法运行；在应用补丁后，错误被修复，测试才能正常运行并通过。他们将这种现象命名为Error2pass。
他们提到了一个名为python-attrs__attrs-830的典型案例：修复前，一个ImportError直接让测试框架在收集阶段崩溃，导致一个测试都没跑成。而打上正确的补丁后，这个错误消失了，所有21个测试都能成功运行并通过。
Error2pass暴露了现有基准测试中的一个根本缺陷：解决方案与测试代码的\“紧密耦合\“。
同样在python-attrs__attrs-830这个典型案例：一个标准的修复方案不仅引入了新函数to_bool，其测试代码也同步更新，指定要导入并使用这个函数。这种评估方式很不公平。如果一个AI模型生成了逻辑上完全正确、但函数名叫to_boolean的方案，它会被判定为失败，仅仅因为测试代码找不到to_bool这个函数名而报错（ImportError）。
为了公正地评估模型，我们必须在构建数据集时，将这些\“错误通过\“的案例识别并排除出去。
SWE-Factory的研究团队希望这个全自动化的构建流程能够加速大规模、高质量的GitHub问题解决数据集的收集，为未来更强大、更通用的代码大模型的训练和评估，提供源源不断的\“燃料\“。通过降低数据集的构建门槛，他们鼓励更多的研究者能够参与进这项工作，共同构建一个更加丰富和多样化的AI软件工程评测生态。
SWE-Facory的研究中一个值得深入讨论的关键发现是Error2pass现象。SWE-Factory的工作为后续研究提供了一个重要启示：在未来构建高质量基准时，需要仔细识别并过滤掉Error2pass实例，以确保评估的公正性和准确性。
针对传统GitHub问题解决基准构建流程中，环境搭建、评分和验证等环节高度依赖人工的痛点，来自中山大学和华为的联合团队提出了一个端到端的自动化解决方案SWE-Factory，有着两大核心创新：
引入了名为SWE-Builder的多智能体框架，以AI协作代替人工进行环境配置；
采用了基于退出码的策略，实现了对测试结果的精准自动评分和自动化Fail2pass验证。
实验证明，SWE-Factory能够高效、低成本地构建有效实例，其自动化验证的准确性也与人工评估完全一致，为社区提供了一个可靠、开源的自动化流程，有力地推动了大规模、高质量软件工程数据集的建设。
备注：昵称-学校/公司-方向/会议(eg. ACL)，进入技术/投稿群
id：DLNLPer，记得备注呦
