(2601) SWE-Lego (52.6分)

🌺 论文摘要

SWE-Lego 论文摘要

参考链接

• 论文笔记, paper, SWE-lego, 代码

核心方法

• SWE-lego数据集：3.2k仓库+32k任务+18k轨迹，来源SWE-rebench

• 数据集构造方法：真实PR + 合成任务 + Qwen3Coder蒸馏轨迹

• Refine SFT方法：Mask错误动作 + 3难度课程学习，难度为交互轮次

模型效果(Qwen3-32B + SFT)

• SWE-V 达52.6分，TTS-16 达58.8分，8B 达42.2分。
• Refine SFT 比普通 SFT(48.8分) 高 3.8pt
• 没有Git Hacking的结果，让Agent 不能查看git log。

重要结论

• 精细化SFT数据 效果可以超过复杂训练方法。

关键贡献

• SWE-lego数据集，开源代码

问题背景

❓问题背景

问题背景

SWE 方法现状

• SFT：数据质量低，缺乏可执行环境和真实Bug来产生高质量轨迹。
• MidTrain：数据量和Data要求高。
• RL：缺乏可执行环境+任务数量，计算量大，难度高、不稳定。

缺乏数据

• 真实数据：真实，但过滤后，数据有限，难扩展。
• 合成数据：可扩展，但缺乏真实任务的复杂性。

轻量级SFT方法

• 如何改进数据质量和训练策略，超过复杂训练方法？

SWE任务失败分类

Failed To Reproduce 复现失败

• 没有尝试复现、尝试了未能复现Bug。

Read Localization Error 文件定位错误

• 已复现Bug，但要修改的文件找错了，没有打开或检查

Write Localization Error 代码片段定位错误

• 找对了文件，但是没有找对应该修复的代码片段。

耗尽最大轮数

• 写入了位置，但耗尽最大轮数。

实现错误

• 去修了，但实际还是修复错了。

SWE-Lego 数据集

📕核心方法

数据概览

SWE-Lego 数据

核心思想

• 任务：真实+合成，大规模+多样性+可执行的任务，
• 轨迹：高质量+验证过

数据来源

• 真实任务：SWE-rebench，贡献大，但难扩展
• 合成任务：SWE-smith，补充增益

数据规模

• 仓库：3.2k
• 任务：32k，可执行，高质量
• 轨迹：18k，验证过的。其中有4k是半解决，仅定位成功。

SWE任务 构建

Task构建(真实提质量+合成提数量)

仓库收集 & Sandbox 构建

• 仓库：从SWE-rebench选择3k Python仓库。
• 环境：自动构建镜像(解析setup.py等文件)
• 过滤：环境构建成功 & 通过sanity测试

真实 & 合成任务 构建

• 真实任务(深度)：SWE-rebench里的PR-Issue。
• 合成任务(广度)：follow SWE-smith 4种策略
  • LLM-Rewrite：根据函数头和稳定，重写代码
  • AST 程序化构建：语法破坏
• 注：合成数据质量低于真实Issue-PR数据，SWE-smith < SWE-rebench

效果结论

• Real Only < Real + 1合成 < Real + 5合成
• 真实数据Scaling有限，自己造数据混合进去，也有提升。

AgentSFT数据 构建

AgentSFT 数据构建

基础配置

• 模型：Qwen3-Coder-480B-A35B-Instruct
• Scaffold：OpenHands
• 超参：100轮

关键策略

• 防Git Hacking
  • 问题：LLM 运行Git log查看答案
  • 真实数据：删除Issue创建之后的Commit
  • 合成数据：删除Git历史
  • 结果：过滤1%
• 工具格式错误修正： Int和str 行号
• 修剪无效工具：丢弃任务管理器
  • 仅保留：execute_bash + str_replace_editor + think + finish
• 验证和过滤
  • 过滤低质量轨迹：如修改测试文件作弊的。
  • 回收班解决轨迹：定位正确 + 修复错误的轨迹。

Refined SFT(Mask错误动作+3阶段课程学习)

Refined SFT

Step-Level Error Mask

• 保留完整轨迹，Mask 错误动作的Loss，只学习正确动作

  • 错误定义：工具调用错误、参数错误等内容。

• 效果：提升2pt

• 同 SWE-Mirror SFT Mask错误动作。

3阶段课程学习(防遗忘)

• 模型打分作为难度

  • 1.5k人标数据，微调Qwen2.5-Coder-32B-Instruct，acc=70%
  • 打分：简单、中等、困难，预计解决时间是[0, 15min], [15min, 1h], [1h, ?]

• 交互轮数作为难度 (选择此方法)

  • 简单0-50、中等50-70、困难70-100

• 三阶段课程学习 + 防止遗忘

  • Stage1：简单。打基础，学会基本工具使用。
  • Stage2：简单+中等。处理稍微复杂的逻辑。
  • Stage3：简单+中等+困难。攻克难任务，全能模型。

TTS 方法

TTS 方法

Sequential Scaling

• 增大交互轮数，100-140轮是极限。
• 但是越往后，成本越贵，超线性。

Parrallel Scaling

• rollout多个结果 + 验证器选择 最好的。TTS@k
• 验证器：
  • 模型：Qwen3-Coder-30B-A3B
  • 训练数据：5k 已解决、1.3k未解决 轨迹。
  • 目标：生成式，输出Yes/No。词概率作为得分。
  • 效果：生成式 > 回归式。

总结

• 先增大轮数，再并行选择

实验设置(三阶段课程SFT)

✍️实验设置

实验设置

基础模型

• Qwen3-8B, Qwen3-32B

训练任务/数据

• SWE-Lego 轨迹数据

评测任务/数据

• SWE-Verified

算法/策略

• SWE-Agent, LLaMA-Factory
• 三阶段课程学习 + 防遗忘，难度：交互轮次

超参

• 4epoch，bs=64
• Adam, weight decay 0.01，cosine wamrup 0.1。
• 学习率：7B/8B： 1e-4，32B：5e-5
• 128k，RoPE

关键结果(Qwen3-32B+三阶段SFT)

🍑关键结果

关键结果

模型效果(Qwen3-32B + SFT)

• SWE-V 达52.6分，TTS-16 达58.8分，8B 达42.2分。
• Refine SFT 比普通 SFT(48.8分) 高 3.8pt
• 没有Git Hacking的结果，让Agent 不能查看git log -p。

重要结论

• 精细化SFT数据 效果可以超过复杂训练方法。

关键贡献

• SWE-Lego数据集：3.2k 仓库 + 32k 任务 + 14.1k 轨迹

未来方向

⛳ 未来方向

未来方向

(2510) BugPilot(54.9分)

🌺 论文摘要

BugPilot 摘要

参考链接

• 论文笔记, paper, microsoft/FrogBoss-32B-2510

核心方法

• 1套Bug合成框架：SWE-Agent开发Feature，引入无意的FeatAdd-Bug
• 数据集-9k轨迹：R2E-Gym + SWE-Smith + FeatAdd轨迹/任务(未开源)
• 2种训练方法：SFT全数据训练，SFT冷启动+RL训练。
• R2E-Gym 脚手架

模型效果(Qwen3-32B + SFT, SWE-Verified)

• BaseMix5.8k-SFT pass@1 达49分，即SWE-Gym + SWE-smith 蒸馏数据
• 增加FeatAdd-1.2k-轨迹 SFT 达51.9分；增加FeatAdd-Bug RL达52.4分。
• 使用全9k蒸馏数据 SFT 达54.9分，高于SWE-Mirror-60k-SFT 52分。14B也达45分。

重要结论

• FeatAdd-Bug比较好
  • 解决率低(相比规则SWE-Smith)，平均修改4.2个文件，Bug类型更均匀。
  • 无意Bug比故意Bug 效果好。

关键贡献

• FeatAdd 无意引入的Bug 这种思想
• 仅开源模型，并未开源 数据集和代码。

问题背景(合成数据质量低)

❓问题背景

问题背景

• SWE 数据稀缺： 挖掘真实仓库Bug数量受限，需复杂清洗工作。
• 现合成数据质量低： 通常依赖规则(如故意写错函数)，合成Bug太简单，和实际Bug有差距。
• 目标： 需大规模生成 具有复杂性的真实Bug合成方法。

📕核心方法

Bug合成(BugPilot)

BugPilot 框架

环境配置

• Docker环境 + SWE-Agent + 强LLM，直接操作开发

  • Claude 4 + GPT4o + GPT5

• 任务：128 SWE-Smith 仓库，每个都有环境。

两种Bug生成策略

• FeatAdd-核心

  • 添加新功能，无意自然地制造Bug。

• BugInstruct-基线

  • 直接让LLM 引入难以察觉的Bug。

• 效果：难度比R2E-Gym, SWE-SMITH高，FeatADD 难度最高。

Bug 验证

• 至少有1个原测试失败。

数据规模

• 合成Bug：

FeatAdd Bug 比较均衡

AgentSFT 数据集

AgentSFT 轨迹蒸馏

• 任务：Bug数据
• 模型：Claude Sonne4
• 配置：64k上下文 + 10k Prompt
• 拒绝采样：仅保留正确样本。
• 成功轨迹：BugInstruct 2.3k + FeatAdd 1.2k

AgentSFT 数据集

BaseMix

• 数据源：R2E-Gym + SWE-Smith。

• 数据量：5.6k 训练 + 198测试

BaseMix + FeatAdd

• 数据量：5.6k + 1.2k
• 原文表格BugPilot合成轨迹大约3.6k，但这里只用了1.2k，可能是纯FeatAdd？
  • 怎么选的以及为什么，暂时不清楚。

AllData

• 数据源：BaseMix + FeatAdd + 剩余1k(R2E-Gym,SWE-Smith)
• 数据量：9k 轨迹

模型训练

SFT训练对比配置

SFT 训练

SFT 对比实验

• 实验1：BaseMix 数据
• 实验2：BaseMix + FeatAdd 1.2k
• 实验3：BaseMix + 其他1.2k(来自R2E+SWE-smith)
• 实验4：BaseMix + FeatAdd 1.2k + 其他1.2k
  • 其实就是R2E-Gym + SWE-Smith + FeatAdd

SFT 超参

• lr=1e-5，epoch=2，32k，但只训练前32k内容
• 8卡 H100， 10小时，LLaMA-Factory

RL 训练

RL 训练

基模

• 基于BaseMix SFT模型继续RL训练。

数据

• FeatAdd Bug，1.2k

环境

• R2EGym Scaffold

• 同 DeepSWE，用RLLM训练框架，RLVR。

超参

• rollout 64k，训练仅 前32k，测试 64k
• 任务最多 100步；一共训练25步
• bs=64，mini_bs=8，rollout=8，温度1，lr=1e-6
• 8*8 H100，50小时

实验设置(SFT+RL)

✍️实验设置

实验设置

基础模型

• SFT模型：Qwen3-32B/14B
• RL模型：轨迹SFT后的模型，BaseMix-5.8k (R2E-Gym+Swe-Smith)

训练任务/数据

• SFT 数据：BaseMix + FeatAdd + 剩余1.2k(R2E,Smith)。

  • 其实就是：R2E-Gym + SWE-Smith + FeatAdd

• RL 数据：1.2k FeatAddBug

评测任务/数据

• SWE-Verified：500个

算法/策略

• SFT + RL

超参

• SFT + RL 各自见上文

关键结果(Qwen3-32B+SFT+RL)

🍑关键结果

关键结果

模型效果(Qwen3-32B, SFT, RL) (SWE-V指标)

• BaseMix5.8k-SFT pass@1 达49分。即SWE-Gym + SWE-smith 蒸馏数据
• 增加FeatAdd-轨迹 SFT 达51.9分；增加FeatAdd-Bug RL达52.4分。
• 使用全9k蒸馏数据 SFT 达54.9分，高于SWE-Mirror-60k-SFT 52分。14B也达45分。

重要结论

• FeatAdd生成的Bug比较难：解决率低(相比规则SWE-Smith)，平均修改4.2个文件，Bug类型更均匀。
• 无意Bug比故意的Bug 效果更好。

关键贡献

• 无意Bug这种思想以及数据集。

未来方向

⛳ 未来方向

合成数据是未来的方向

• Self-Improvement：使用微调后模型做开发来生成Bug，避免闭源模型太强，导致无Bug产生。
• 特定领域训练：修改 Prompt 以生成特定领域/类型的Bug（安全/并发Bug等）。
• 扩展任务：不仅是写Bug，可扩展到其他SWE任务（测试生成、配置环境、Agent协作等）。

(2509) SWE-Mirror(52分, Seed)

🌺 论文摘要

SWE-Mirror 论文摘要

参考链接

• 论文笔记, paper

核心方法

• 1套SWE任务合成移植方法：任务选择 + 任务移植 + 任务验证

  • Bug移植：生成测试用例 + 生成Bug源代码 + 生成Issue描述

• SWE-mirror-60k 数据：4语言+40 仓库+60k任务+6.3k蒸馏轨迹

  • 数据未开源，python为主，来自SWE-Gym, SWE-rebench, Multi-SWE-RL

• SFT方法：Mask错误动作

• Scaffold：OpenHands+MopenHands

模型效果(Qwen2.5-Coder-Instruct-32B + SFT)

• SWE-verified 达52分。Multi-SWE-Bench-Flash 达21分。

重要结论

• Mask错误动作 SFT 效果比不Mask或片段剪辑掉的好。
• SFT Data Scaling有效：4k轨迹训练，6->35分；12k训练，达52分。

关键贡献

• SWE-Mirror-60k 任务，没开源，也不算贡献吧。

问题背景

❓​问题背景

SWE组件和两种任务构建方法优缺点

SWE 两大组件

• Task Context
  • Issue + PR + 仓库代码
  • 测试用例、标准答案
• Gym
  • 可执行环境：测试命令、日志解析、验证正确性、提供奖励。

SWE 两种任务构建方法

• 合成问题-扩展任务
  • 工作：SWE-smith，SWE-Synth，程序化+重写等方法构建Bug，合成数据。
  • 优点：规模化。
  • 缺点：未利用真实软件工程中丰富的历史数据，人工制造的Bug
• 搭建Gym-扩展任务
  • 工作：自动搭建环境、收集PR扩展数据。SWE-rebench。
  • 优点：利用真实数据。
  • 缺点：环境成本高，成功率低，1实例-1GB，10w实例 -100TB存储。

PR-Mirror

• 核心：利用现有代码+现有环境，移植复现之前的Bug，避免为每个bug都重装环境。
• 扩展：把原Repo的PR，移植到相似的目标Repo，去构建新任务。
• 移植可行的3个理论
  • 组件相似性：很多组件底层架构逻辑和API，有相似之处。(如Pytorch/Tensorflow)
  • 逻辑可移植性：Bug本质往往是逻辑错误。
  • 验证可迁移性：源仓库测试用例经过修改后，可验证目标仓库Bug。

SWE 挑战

Gym 环境构建困难

• 收集Context容易，但构建Gym很困难，需要大量人工 单独搭环境。
• 大部分：Task-Gym 是一对一依赖关系。

SWE-Mirror SWE任务合成移植方法

数据源

数据源(Gym环境)

• SWE-Gym, SWE-rebench, Multi-SWE-RL
• 筛选条件：5分钟 完成所有测试 + 1GB内存

最终数据集

• SWE-mirror-60k：4语言，40 仓库，60k任务，Python大头

任务选择

1. 任务选择

• 目标：为每个Repo+Gym (目标Repo)，寻找可移植的Issue。
• 搜索相关相似Repo：
  • Qwen-32B 生成5个关键词 + 关键词搜索相关Top20 Repo
• 从相关Repo收集过滤Issue-PR：
  • 手工规则+LLM筛选，筛选高质量 可移植的Issue
  • 100测试集，LLM准召：84%、86%

Issue 迁移

2. 任务移植

原Issue提炼

• 原Issue-PR 简洁抽象描述提炼：包括功能、核心逻辑、当前行为、预期行为、观察症状等。

移植过程

• 生成 测试用例
  • TestAgent：抽象描述 + 目标Repo-Gym的测试套件 --> 新的测试用例
  • test.patch：当前代码能通过，应用Bug后的代码不能通过。
• 生成 Bug源代码
  • Mirror Agent：抽象描述 + test.patch 包含的文件路径 + 函数名称 --> 修改源代码
  • mirror.patch：有Bug的版本，任务起点。
  • fix.patch：正确答案，无bug，即未应用Bug的版本。
• 生成 Issue描述
  • Prompt指令：原Issue描述 + test.patch + fix.patch + few-shot 示例
  • 描述：连贯 自包含的任务描述。

最终产出任务

• mirror.patch：引入目标bug的补丁
• test.patch：测试用例
• fix.patch：无bug，标准答案
• Issue描述/problem_statement：问题描述

效果评估

• 成功率：46% 很高了。88%任务具和原始Issue相比具有中高一致性。

任务验证

3. 任务验证 (质量控制)

应用实际测试

• run.log：mirror，执行原始测试
• test.log：mirror + test，执行生成的测试
• fix.log：mirror + test + fix，应用3个补丁，执行测试

日志检查及过滤标准

• 不能导致原测试挂掉：检查run.log+test.log，只能有pass2pass, fail2fail, skip2skip, none2fail。
• 必须真的修复Bug：必须有 Fail2Pass
• 不能产生新Bug：不能有 Fail2Pass
• 测试不能不稳定：有时fail、有时pass，必须过滤

AgentSFT 数据蒸馏

SWE-Mirror AgentSFT 轨迹数据蒸馏

概览

• 模型：Claude3.7-Sonnet, Claude4-Sonnet
• 任务：SWE-Mirror-60k，选择 15k任务
• Agent：OpenHands
• 超参：100轮，每任务3轨迹，温度=1
• 成功蒸馏：6.3k 轨迹
• 和 SWE-rebench轨迹合并，组成12k轨迹。

实验设置(SFT, Mask错误动作)

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-Instruct-7B/32B

训练任务/数据

• SWE-Mirror 蒸馏轨迹 + SWE-rebench轨迹，合计12k轨迹

评测任务/数据

• SWE-verified, Multi-SWE-Bench-Flash

算法/策略

• SFT：Mask错误动作，只学习有效轮次。同 NEBIUS RFT冷启动 一致。
• Scaffold：OpenHands，MopenHands(多语言)
  • OpenHands：编辑文件、shell命令、浏览网页等。

超参

• 3epoch，AdamW cosine decay, decay weight=0.01, warmpup=0.1, 峰值lr=5e-5
• 如果数据小于4k，则：5epoch，lr=1e-4

关键结果(Qwen2.5-Coder-Instruct-32B + SFT)

🍑关键结果

关键结果

模型效果(Qwen2.5-Coder-Instruct-32B)

• SWE-Mirror-LM-32B swe达52分，7B达 22分。MSB-Flash 32B达21分。
• 32B 超过DeepSeekR1-0528(45分)，低于Qwen3-Coder-480B-A35B(69.6)

重要结论

• Mask错误动作 SFT 效果比不Mask或片段剪辑掉的好。
• SFT Data Scaling有效：4k轨迹训练，6->35分；12k训练，达52分。

关键贡献

• SWE-Mirror-60k 任务。

未来方向

⛳ 未来方向

未来方向

• 数据扩展：
• 多语言扩展：

(2506) Skywork-SWE(36分)

🌺 论文摘要

Skywork-SWE 摘要

参考链接

• 论文笔记, paper, Skywork-SWE-32B, blog

核心方法

• SWE任务收集构建方法
  • Repo+PR 收集 + 统一环境安装 + 执行验证等。
  • 基于真实环境执行来做数据验证，3层增量式镜像 (基础+环境+实例镜像)。
• Skywork-SWE数据：10k任务 + 2.5k仓库 + 8k蒸馏轨迹。没开源数据
• Scaffold：Openhands

模型效果 (Qwen-2.5-Coder-32B + SFT)

• SWE-verified 达36分，TTS-3 达47分。

重要结论

• SWE Data-Scaling, Test-Time-Scaling, 轮数Scaling Law 得到验证。
• 经过单元测试验证的数据比SWE-smith合成数据 靠谱，提升6.8%

关键贡献

• 仅开源模型，未开源代码和数据。

(2505) SWE-rebench

🌺 论文摘要

SWE-rebench 摘要

参考链接

• 论文笔记, paper, NEBIUS-SWE-rebench-轨迹数据, nebius/SWE-rebench

核心方法

• 自动 SWE Issue-PR任务 收集工具

关键贡献

• SWE-rebench 数据集：21k python任务
• SWE-rebench Benchmark 排行榜

❓问题背景

问题背景

大规模数据促进SWE效果

现有数据存在局限性

• 现有数据：静态Github代码+合成指令数据 居多。
  • 只能教会模型补全代码，而非解决问题。
  • RL需要：试错、交互式验证学习。
• SWE-Gym 改进：但需人工配置环境，难扩展，仅11仓库。

现有Bench存在局限性

• 静态数据可能被训练污染
• 不同Scaffold、不同对比。

自动挖掘工具

📕核心方法

仓库收集+Issue过滤

自动挖掘工具

仓库收集

• Github Archive
  • 每日json档案更新Github事件，收集Issue相关内容。
    • 描述、讨论、关联PR、metadata等
    • 从PR中提取信息：合并状态、最新commit、讨论等。
• Github
  • Clone相关仓库及完整提交历史。
• 数据量：
  • 45w 有Issue相关联的PR
  • 3w 宽松许可，python占比75%

Issue 保留规则(过滤)

• 宽松许可 + Python仓库， Issue 已解决，PR 已合并
• PR 没有关联多个Issue，Issue描述>10字
• PR 必须修改测试文件，PR必须修改其他文件，修改文件数量在1-15之间
• 最终数据量：15.3w 实例

自动安装环境和执行验证

自动环境安装

自动环境安装(Agentless 方案)

• 寻找安装文件：LLM 扫描 README.md, Dockerfile, setup.py等。
• 生成安装配方：拼接上述文件，让LLM生成安装recipe。
• 迭代交互式安装：LLM去执行安装，出错，环境反馈Bug，LLM重新修改recipe，再重新安装。
• 成功率：31%，丢弃其余不成功的。
• 其中，对版本做分组，小版本共用1个环境，而非每个Bug一个环境。

基于执行的安装验证

• 确保测试正确
  • 修复前有Bug：test_patch，至少有1个错误。
  • 成功修复：test_patch + solution_patch，Fail2Pass，没有报错。
  • 无新Bug：pass2pass

模型评估任务质量

自动任务质量评估

背景

• 需要评估，不然有些问题不可解或者难以验证，导致错误惩罚LLM。
• SWE-Bench-Verified：人工验证

微调模型来评估质量(Qwen2.5-72B-Instruct)

• 输入：Issue描述 + Gold Patch + Test Patch
• 输出，预测3内容：
  • Issue 清晰度：Issue描述是否足够详细。
  • 任务 复杂度：预估工作量。
  • Test Patch正确性：测试是否准确，能验证出修复是否达预期。
• 微调数据集：SWE-Bench-Verified 标注数据。
• 效果：三指标准确率：81%、67%、79%。

启发式筛选规则

• 根据膝盖文件数量筛选：不准确。
• 基于模型各标签自行筛选数据。

SWE-rebench 数据概览

概览

SWE-rebench 数据集

• 21k python 任务 + 环境 + 验证

rebench 排行榜

• 持续更新，去污染(新题目)，标准化对比(scaffold等)。

⛳ 未来方向

未来方向

• 任务质量提升：可能有的任务不可解。
• 语言扩展：现在仅python

(2504) SWE-smith (40分, SWE-Agent-LM)

🌺 论文摘要

SWE-smith 摘要

参考链接

• 论文笔记, paper, SWE-smith

核心方法

• SWE任务合成方法：Agent安装环境 + 4策略合成候选任务 + 执行验证 + 逆向合成Issue
• SWE-smith数据：128仓库+50k任务+5k蒸馏轨迹
• SWE-Agent

模型效果 (Qwen2.5-Coder-32B)

• 使用轨迹数据SFT，SWE-verified 达40，提升33pt。

重要结论

• 任务Scaling有效，多样性很重要，PR-Mirror, LM-Rewrite的任务比较好。

关键贡献

• 开源代码、任务、环境、轨迹，真开源！
• SWE-smith 52k任务，26k SWE-smith-轨迹，SWE-smith-env

问题背景(缺乏数据+现2种数据方法有缺点)

❓问题背景

问题背景

SWE 任务缺数据

• SWE-LLM 依赖闭源模型，开源缺乏大规模、高质量训练数据。
• 需要infra去促进训练数据scale

两种数据模式各有弊端

• 直接爬取 Github PR/Issue
  • 优点：简单，量大管饱
  • 缺点：缺乏执行环境、缺乏测试用例，缺乏可靠验证信号，数据质量不可靠
  • 学习：模型只能学习表面代码相似度形式
• SWE-bench 扩展模式
  • 优点：执行单元测试 可靠，可以用来蒸馏轨迹数据，数据质量高
  • 学习：学习逻辑功能。
  • PR 要求：解决了Issue + 需修改新增真实单元测试
  • 缺点：成本高，数据要求严格导致扩展受限，人工调试环境。

SWE-Smith 任务合成方法

📕核心方法

数据方法概览

SWE-Smith 整体流程

• 先定义环境，再合成任务实例。
  • 给定代码库，使用SWE-Agent来构建环境，仓库级环境。
  • 通过4种策略，生成多个候选任务
  • 通过执行验证，过滤不合格任务。
  • 使用LLM生成Issue描述。
• 最终： 128个Python仓库 + 50k任务实例
• 轨迹蒸馏：最终 5k 轨迹数据

合成细节(Agent搭环境+4策略合成Bug+执行验证+合成Issue)

SWE-Smith 任务构建方法

环境构建

• 仓库筛选：24年11月 PyPI下载量前5000的包，去掉stars<1000+SWE重复的仓库。
• 给定仓库(最新commit)，让SWE-Agent 在100内 安装环境和执行测试。
• 人工验证安装和测试情况：测试用例通过>80%，则算成功，为其构建仓库级docker镜像。

候选任务构建

• 核心：为每个仓库，通过4种策略生成不同的候选任务。
• 大模型生成：
  • 给函数文档重新实现：LLM-Rewrite，效果很好
  • 让LLM故意改错代码 ：LLM-Modify，效果最差
• 程序化制造Bug：效果好。
  • 先解析代码结构再故意破坏。错误微小，难以觉察。
• 组合Bug：在同1文件里组合前面的多个bug
• PR Mirror(PR 反转)：效果最好
  • 从正确代码->错误代码，在现有版本上模拟之前的bug，避免重装环境
  • 找到之前修复bug的PR，给LLM输入 最新代码 + diff文件，让其复原之前的Bug代码。
  • 优点：始终在最新版本和环境上工作，环境配置简单。

执行验证

• 为每个候选patch，执行测试，仅保留能制造Fail2Pass的任务。
• 做2分钟耗时限制：bug测试卡死或很慢，依然丢弃。

Issue 生成

• 难度控制住：描述很重要，不能太简单了。
• LLM逆向生成：
  • LLM输入：diff patch、F2P test的源代码、测试失败的报错日志
  • LLM生成：Github issue风格的Issue描述。

LLM 生成Bug

程序化制造Bug

组合Bug

PR Mirroring，从正确代码->错误代码，复现之前的bug

AgentSFT 数据蒸馏

SFT 轨迹数据蒸馏

概览

• 模型：GPT4o, Claude 3.7 SOnet
• Agent：SWE-Agent，ReAct
• 轮数：75轮
• 任务：SWE-Smith 50k 任务
• 最终数据：5k 轨迹

关键策略

• 任务：共8k任务做蒸馏，占比Smith任务 17.3%
  • 包含：PR-Mirror + LLM Rewrite 这两种策略产生的轨迹最有效。
• 轨迹：每任务执行3次，17k尝试，解决率36%，共6.4k轨迹。
• 过滤：去掉简单任务，最终5k轨迹

实验设置(SFT)

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-Instruct-7B/32B

训练任务/数据

• 在SWE-smith任务上，合成的5k轨迹 (Claude/GPT4o)

评测任务/数据

• SWE-verified(500)， SWE-light(300)，SWE-Multilingual(300)

算法/策略

• SFT
• SWE-Agent：ReAct 风格，编辑文件、执行命令等。

超参

关键结果(SWE-Agent-LM-32B + SFT)

🍑关键结果

关键结果

模型效果

• SFT后的SWE-Agent-LM-32B，SWE-Verified 40.2pt，提升33pt
• SWE-Agent-LM-32B 仅需24.9步，但Claude 3.7 Sonnet 需要29.1步。
  • 但32B容易陷入重复动作。

重要结论

• 任务实例/bug类型/仓库覆盖 越多越好，任务Scaling有效果。多样性>难度。
• PR-Mirror、LM-Rewrite、程序化制造Bug 效果都好，依次排序，LM Modify 效果最差。
• 合成Issue已非常接近人类真实水平
• 可针对特定仓库优化模型表现(Pandas,Sckikit-learn等)，对通用能力损害小

关键贡献

• 开源SWE-smith工具包：生成任务实例 + 执行环境 + 专家轨迹数据

未来方向

⛳ 未来方向

未来方向

(2504) R2E-Gym(34.4分)

摘要背景

🌺 论文摘要

R2E-Gym 摘要

参考链接

• 论文笔记, paper, r2e-gym, R2E-Gym

核心方法

• 自动合成SWE任务方法：Commit挖掘+测试用例生成+反向Issue生成
• R2E-Gym 数据： 10仓库+8k任务+3.3k蒸馏轨迹 ，R2E-Gym Sub：4.5k 任务
• OpenHands

模型效果(Qwen-Coder-32B + SFT)

• SWE-Verified 达 34.4分

重要结论

• 合成数据不输人工数据
• Hybrid TTS 有效果，从34.4提升至51分。

关键贡献

❓问题背景

问题背景

• 开源模型有差距：真实GitHub-SWE问题，开源显著落后于闭源模型(GPT-4, Claude 3.5)
• 数据有瓶颈：缺乏大规模、高质量的可执行训练环境
  • 现有数据：许多无可执行环境，或依赖人类编写的Issue和测试用例，难以自动化扩充
• 推理扩展难题：现有验证方法 基于测试执行 + 基于模型打分，都存在局限性
  • 缺乏对测试时计算（test-time compute）的最佳扩展策略的研究。

R2E-Gym 任务合成方法

📕核心方法

R2E-Gym SWE任务合成方法

合成流程

• 挖掘Commit变更数据

  • SEART 搜索 Python 仓库，
  • 提取Commit历史记录，使用LLM挖掘出有价值的变更。不依赖 Pull Requests。

• 提取或生成测试用例

  • 如Commit带测试用例，直接提取Fail2Pass测试用例。
  • 若无测试用例，则自动生成测试用例。

• 反向翻译生成 Issue

  • 利用TestCases+ Commit 来反向 合成Issue。

最终数据集

• R2E-Gym 8.1k任务，subset 4.5k 任务，仅10 python仓库。

AgentSFT 数据蒸馏

• 基于Subset任务 + Claude-3.5-Sonnet 做蒸馏 + Openhands + R2E 环境
• 共3.3k 轨迹，2k任务

Hybrid TTS

Hybrid TTS (执行验证+免执行验证)

• 先基于免执行验证选出top-n，再基于执行验证做最终排序。

实验设置(SFT)

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-7B, 14B, 32B

训练任务/数据

• SWE任务：R2E-Gym-Subset 4.5k
• SFT 数据：蒸馏3.3k轨迹 + 2k任务。

评测任务/数据

• SWE-Verified

算法/策略

• SFT 训练，LLaMA-Factory
• 验证器训练：
  • Testing Agent：Qwen-Coder-32B
  • 免执行验证器：Qwen-Coder-14B，对轨迹做二分类打分。

脚手架

• OpenHands的ReAct框架
  • file_editor、search_tool、execute_bash、submit

超参

• 2epochs, lr=1e-5, bs=78 seqlen=20k

关键结果(Qwen2.5-Coder-32B + SFT)

🍑关键结果

关键结果

• 数据扩展有效
  • SFT-32B SWE-Verified达 34.4% Pass@1，比之前SOTA SWE-Gym提高13.8%。
  • 证明了合成数据的有效性。
  • 合成数据不输人工数据：
    • 纯合成数据训练：27分；纯人工数据训练：28分。差不多。
  • 训练带思考比不带思考，提升4pt，思考34分，不带思考仅30分。
• 验证器性能互补
  • 单独使用基于执行或免执行的方法，性能均在 42-43% 左右饱和。
  • 混合验证器，将性能提升至 51.0%。
• 计算效率：
  • 增加“测试 Agent”的采样次数比单纯增加“编辑 Agent”的采样次数更具计算性价比。
• SOTA 表现：51分成绩使开源模型首次在SWE任务与专有模型(o1, Sonnet + Tools)竞争。

⛳ 未来方向

未来方向

• 环境构建自动化：目前的依赖安装和环境构建仍含手动步骤，未来利用LLM实现全自动化。
• 更长上下文：训练仅20k/32k上下文，未来利用上下文并行训练处理更复杂的Agent。
• 测试生成质量：进一步减少生成测试中的毒性Toxic Tests和无效测试，提高验证器的鲁棒性。

(2412) SWE-Gym(19.7分)

🌺 论文摘要

SWE-Gym 摘要

参考链接

• 论文笔记, paper, 代码, SWE-Gym Data

核心方法

• SWE任务构建方法：通过脚本直接提取PR，并半手动构建好环境(仅覆盖11仓库)
• SWE-Gym数据集：2.4k任务+ 11仓库
• OpenHands，Moatless

模型效果(Qwen2.5-Coder-32B + SFT)

• SWE-Verified 19.7分，TTS-16 达32分。

重要结论

• Best-of-16策略：20.6 -> 32分，开源模型新标杆。

SWE-Gym 任务收集构建方法

SWE-Gym 任务构建方法

仓库识别

• 用SEART搜索 + 选择python仓库
• 过滤条件：PyPI 下载top-5k + 500star + 300行代码 + 500个pr + 100个contributor
• 最终数据：358 仓库。时间：2022.07.01之前的

任务构建

• SWE-bench的提取脚本：把仓库PR 转换成具体任务实例

• 最终数据：64k实例，作为SWE-Gym-Raw

• 每个任务：Issue、代码、解决方案，但是缺乏可执行环境。

环境构建

• 为11个仓库 + 大量任务实例，半手动的创建环境
• 设置版本编号，按版本来构建实例环境，按版本分组。
• 手动查阅CI脚本，一个一个配置环境。

验证机制

• Fail2Pass：原始代码必须失败，打上patch后 必须通过。

结果

• 200小时人工配置，6TB Docker镜像。

SFT 数据蒸馏

• 模型：GPT4o, Claude3.5-Sonnet
• 轮数：平均19轮
• 最终：off-policy 491条，on-policy 875条(微调Qwen2.5-Coder-Inst-32B)，失败的1318条。