DEV Community

cognitalk
cognitalk

Posted on

Introduction of SWE-smith


https://www.youtube.com/watch?v=Wdkm_mJdFWU

🎯 一句话先概括

SWE-smith 是一个“自动造 bug 题库”的工具——它自动把真实开源项目跑起来，然后故意改坏代码，让 AI 学着去修，从而训练出更会修 bug 的编程 AI。

🧩 背景：AI 学修 bug 为什么难？

现在有个著名考试叫 SWE-bench：

  • 给 AI 一个真实 GitHub 项目 + 一个 bug 描述
  • AI 改代码
  • 跑原项目的单元测试，全过 = 修对了

问题来了：想让 AI 考高分，光靠“刷题”不够，得有大量带“标准答案+可运行环境”的练习题。

  • 真实 PR 太少、太贵、收集超累 👴
  • 网上抓 PR 又没法真正“运行验证” 👎

💡 SWE-smith 的核心脑洞

既然真实 bug 不好收集，那就让 AI 自己“造” bug！

流程只有三步：

① 自动装好项目（以前最麻烦的一步）

  • 给一个 GitHub 仓库
  • 用 SWE-agent（一个会自己敲命令装环境的 AI）尝试自动配置
  • 现在成功率约 40%，装好就得到一个可执行 Docker 环境

类比：以前老师手动给每道题配实验室，现在让助教自动搭实验室

② 用各种办法“故意改坏代码”

项目本来有能跑通的单元测试，SWE-smith 用 4 种方式搞破坏：

方法 通俗解释
程序化乱改 把代码转成语法树，随机删行/反转让/清空循环，再转回代码
让 LLM 改坏 让大模型重写某个函数，写错就留着当 bug
组合多文件改 把几个小 bug 拼一起，模拟真实 PR 多文件修改
反转真实 PR 找到项目历史修复，把修复“撤销”，bug 就回来了

改完之后：原来能过的测试现在失败了 → 这就是一道“找 bug + 修 bug”的题。

③ 拿去训练 AI

  • 用强模型（Claude 等）先示范怎么修 → 生成“解题轨迹”
  • 再用这些轨迹微调小模型（如 Qwen 2.5）
  • 结果：7B 小模型在 SWE-bench 上也能考到 40%+，甚至对单个项目（如 DSPy）训出“专属修 bug 专家”

📈 它比老方法强在哪？

  • 量大：128 个 Python 仓库 → 5 万个任务，现已扩到 9 种语言
  • 省空间：SWE-bench 每道题一个 Docker 镜像；SWE-smith 一个仓库一个镜像，里面塞一堆 bug，存储暴降
  • 少人工：从“人肉配环境”变成“AI 自动配 + 自动出题”

🤔 有个小争议（问答环节提的）

有人问：

考试只看“最终 bug 修没修好”，但好程序员价值在思考过程细不细致，你管不管？

演讲者答：

  • 目前主要看“最后测试过没过”（结果奖励）
  • 也有人在试“过程奖励”（比如有没有先找对文件）
  • 但实验发现：对刷 SWE-bench 分数帮助不大，未来做真正好用的编码 Agent 可能得再研究

🧠 总结成一句话

SWE-smith = 自动搭环境 + 自动往真实项目里“埋雷” → 让 AI 大量练习排雷 → 训练出更会修真实 bug 的编程智能体。

好的，这是对您提供的视频采访内容的详细分段和要点总结。

文章标题：SWE-smith：为软件工程智能体规模化构建高质量训练数据

第一部分 开场与自我介绍 (0% - 5%)

  • 演讲者身份与研究领域：演讲者是斯坦福大学的一年级博士生John Yang，导师是Ludwick Schmidt和D. Young。他此前在普林斯顿大学攻读硕士，师从Karthik Narasimhan。他的主要研究方向是编码智能体和软件工程智能体。
  • 过往相关工作：他主导或参与了多项知名工作，包括用于评估编码智能体的基准测试 SWE-bench、智能体框架 SWE-agent，以及早期的网络导航项目 Intercode 和其衍生版本 SWE-bench Verified。
  • 本次演讲主题转变：与一年前侧重于评估不同，本次演讲的重点转向了如何训练出能在这些基准测试上表现优异的模型。

第二部分 背景：SWE-bench基准测试与当前进展 (5% - 15%)

  • SWE-bench基准测试简介：SWE-bench是一个流行的测试模型作为软件工程智能体能力的评估标准。它从真实世界的GitHub issue和PR中提取问题，将其转化为一个任务：给定一个代码库和一个自然语言描述的issue，系统（无论是语言模型还是像SWE-agent、OpenHands这样的脚手架工具）需要修改代码库来解决该issue，并通过运行单元测试来验证修复是否成功。
  • 性能的巨大飞跃：自SWE-bench发布一年以来，模型的得分从最初的2-4%大幅提升至现在的70-71%。演讲者指出，这些性能的巨大提升主要归功于更强大的基础模型。
  • 核心研究问题：从学术角度看，关键问题是如何从数据角度出发，制造出更好的模型。

第三部分 现有训练方法的两种范式与局限 (15% - 30%)

  • 范式一：智能体（Agentic）方法
    • 工作方式：采用ReAct（推理-行动-观察）循环。模型根据issue决定打开哪个文件、执行bash命令（如ls），然后根据终端的输出来决定下一步行动。
    • 数据收集难点：已有工作如SWE-gym通过重做SWE-bench的收集流程来获取训练数据，但这需要手动为每个仓库创建执行环境（Docker镜像）。另一个例子SWE-Searcher或SWE-RL则从在线大量抓取PR，但缺乏交互式执行环境。
  • 范式二：无智能体（Agentless）方法
    • 工作方式：不需要执行环境，模型像解数学题一样，通过分析代码语义来直接推断出应该做的修改。
    • 数据收集难点：可以轻松抓取大量在线PR，但训练仅限于代码的表面形式，无法学习与执行环境交互、运行命令和查看执行输出的能力，从根本上限制了这种范式的潜力。
  • 核心矛盾总结：
    • SWE-bench/SWE-gym类数据：拥有宝贵的执行环境，但收集过程高度依赖人工，繁琐且成本高（每个实例都需要独立的Docker镜像，占用大量存储空间）。
    • 在线PR抓取类数据：易于规模化，但缺乏执行环境，限制了训练的深度和有效性。

第四部分 SWE-smith：目标与核心思路 (30% - 45%)

  • SWE-smith的目标：融合上述所有方法的优点，创造一种能够自动规模化到大量仓库并合成大量任务实例的策略，同时实现极少甚至无需人工监督。
  • 核心思想：半自动地使用一个智能体来安装一个仓库，一旦拥有了该仓库的执行环境，就可以通过各种策略在代码库中合成bug，从而获得一个包含数千个带有执行环境的任务实例的优秀训练集。
  • 三个主要工作流：
    1. 创建执行环境：为一个给定的GitHub仓库创建一个Docker镜像/执行环境。
    2. 合成任务实例：利用已有的执行环境，对代码库进行破坏性修改，使其原有的单元测试失败。一个任务实例就是一个能导致某些测试失败的代码变更（diff）。
    3. 训练：基于生成的执行环境和任务实例，可以使用任何训练算法来训练模型。

第五部分 步骤一：自动创建执行环境 (45% - 50%)

  • 技术基础：基于SWE-agent项目的改进。SWE-agent原本是让语言模型作为智能体解决软件工程任务的框架，经过一年的优化，现在已经足够强大，可以接受一个GitHub仓库并尝试自动安装。
  • 成功率：目前，让SWE-agent自动安装一个仓库的成功率约为40%。用户也可以使用Claude Code等工具达到类似效果。

第六部分 步骤二：合成任务实例的多种方法 (50% - 65%)

  • 方法一：程序化修改（Procedural Modification）
    • 原理：将函数或类等程序实体转换为抽象语法树（AST），然后对AST进行随机操作（如删除赋值语句、反转条件判断、清空循环体等），再将修改后的AST转换回源代码。
    • 特点：完全免费，可以大规模生成具有特定特征的、结构化的bug。最初专注于Python，现已扩展到9种其他语言。
  • 方法二：利用语言模型（Language Model）
    • 子方法A：直接将原始函数交给语言模型，让它“搞砸它”。
    • 子方法B（更有效）：清空函数体，让语言模型重新实现。只要它实现错了，就保留下来作为一个任务实例。
  • 方法三：组合多文件修改（Combining Patches）
    • 动机：现实世界中的PR通常涉及多个文件的修改，而前两种方法往往只修改单个程序实体。
    • 做法：智能地组合由前两种方法产生的不同bug补丁，例如合并来自同一模块、破坏相同测试或位于同一文件的多个补丁，以模拟更复杂的多文件变更。
  • 方法四：保留真实世界特性（Real-World Preservation）
    • 做法：给定一个代码库的一个PR，让模型撤销该PR所做的更改，从而反向生成一个任务实例。
    • 意义：这是一种比传统SWE-style收集更省力的方式，保留了真实世界问题的复杂性。

第七部分 SWE-smith的规模与效率优势 (65% - 72%)

  • 规模对比：
    • SWE-bench: 2,294个任务实例；SWE-bench Verified: 500个。
    • SWE-gym: 约2,000个任务实例，来自几十个仓库。
    • SWE-smith: 能够实现10倍的增长，覆盖更多的任务实例和仓库数量。
  • 存储成本优势：
    • SWE-bench：每个任务实例需要一个独立的Docker镜像/执行环境。
    • SWE-smith：每个仓库只需一个执行环境，对应多个任务实例。这使得存储效率大大提高，成本显著降低。

第八部分 训练与实验结果 (72% - 85%)

  • 训练方法：论文初期主要采用知识蒸馏和拒绝采样微调。即使用专家模型（如Claude 3.5/3.7）配合SWE-agent生成大量轨迹，然后用这些轨迹微调学生模型（如Qwen 2.5）。
  • 评估基准：引入了新的评估基准 SWE-bench Multilingual，用于测试模型在非Python领域的性能。
  • 关键成果：基于SWE-smith数据和Qwen 2.5微调的模型成为首个在完全开源数据和模型架构下突破40% 得分的模型。
  • 缩放定律（Scaling Trend）：实验表明，随着训练轨迹数量的增加，模型性能持续提升，尚未出现明显的平台期。
  • 消融实验启示：增加仓库的数量和Bug类型的多样性，对于提升模型性能非常有帮助。
  • 单仓库智能体案例：使用SWE-smith为单个仓库（如Stanford的DSPy库）合成的数据训练一个7B模型，可以得到在该仓库上极具竞争力的专用智能体。

第九部分 未来方向与生态系统 (85% - 93%)

  • 当前状态：初始版本覆盖了128个Python仓库和5万个任务实例。目前已支持9种编程语言，并为Go语言新增了1万个任务实例，并计划继续扩展。
  • 社区贡献方向：
    • 探索生成Bug或Issue文本的新方法。
    • 注意到许多后续工作（如Qwen 3 Coder、Sky-T1、DeepSeek-R1、Agentica等）都已在使用SWE-smith，形成了一个活跃的数据飞轮。
  • 潜在研究方向：“一个仓库，一个智能体”（One Repo, One Agent）的设置可能带来有趣的研究问题。
  • 开源生态：演讲者团队致力于打造一个完全开源的生态系统，包括Mini-SWEA-agent、Bench-Agent、SWE-smith等，鼓励大家参与其中。

第十部分 问答环节 (93% - 100%)

  • 问题一：关于过程奖励 vs 结果奖励
    • 提问：目前的评估只看最终是否解决了issue（高层次结果），但软件工程师的价值体现在非常细粒度的思考过程中。如何平衡这种“issue级别”的训练数据和更精细的过程？
    • 回答：这是一个很好的问题。单元测试作为信号是终极的，但忽略了过程。这正是许多RL工作开始使用SWE-smith的原因，因为它允许定义自己的问题并检查过程。对于过程奖励（Process Reward）是什么，演讲者表示没有确定的答案。一些论文显示，简单的过程检查（如模型是否正确识别了要编辑的文件）有帮助，但与最终是否解决问题的稀疏奖励相比，提升并不巨大。因此，对于在SWE-bench上取得高分，可能可以忽略过程，但对于打造一个真正优秀的编码智能体，可能需要更多洞察。
  • 问题二：关于DSPy的使用
    • 提问：在DSPy的例子中，是使用DSPy框架来编排智能体的思考过程，还是对智能体的编排进行了更精细的控制？
    • 回答：那个DSPy智能体是专门针对DSPy仓库训练的，目标是像一个超级专注的DSPy开发者那样回应。它与DSPy框架本身的功能无关，可以看作是一个专门为DSPy开发的7B参数级别的“开发者”。

Top comments (0)