Skip to content

SWE 自进化

📅 发表于 2026/09/16
🔄 更新于 2026/09/16
👁️ — 次访问
📝 2073 字
7 分钟

(2512) Self-Play SWE-RL (51.4分, Meta)

🌺 论文摘要

Self-Play SWE-RL 摘要

参考链接

核心方法

  • Self-Play SWE-RL框架
    • 给定仓库+环境,通过写Bug+修Bug 自我博弈联合RL训练无需人工Issue
  • 仓库数据未知
  • CWM scaffoldbash + search-replace 编辑器

模型效果(CWM-32B-sft)

  • 在SWE-V和SWE-Pro上,SSR方法都超过RL+人类Issue训练的模型,但也没高多少
  • SWE-V51.4分SWE-P28.9分

重要结论

  • Self-Play RLRepair/Injection-Only RL 性能更好Inject-Only 效果最差。
  • 大幅删除代码的Bug更好比仅改一行代码的Bug的好。后者太简单,学习信号弱。
  • 由于共享1个Policy,Solver解决率信号 对训练效果影响不大

关键贡献

  • Self-Play SWE-RL 思想,很有启发意义的工作

问题背景

问题背景

合成数据是静态的

问题背景

RL 受限于人类天花板

  • 训练数据和环境 依赖人工:Issue、PR、环境、单元测试等。
  • 人类数据噪音多不可靠难扩展
  • 导致RL本质模仿和优化 人类写代码的过程。

当前合成数据存在局限性

  • 思想:LLM合成Bug,再去蒸馏数据。

  • 缺点:

    • 依赖人类:测试套件、解析器等。
    • 依赖TeacherModel:LLM去操作、LLM去蒸馏数据。
    • 扩展受限
    • Bug是静态合成的:模型进化,但Bug却无法进化,导致系统无法持续自我改进
  • 代表工作:SWE-smith/BugPilot.

Self-Play结合真实动态仓库

Self-Play + 真实动态Repo

Self-Play

Zero Self-Play

  • 代表工作:
    • Absolute Zero:训单个推理模型。
      • 只和Python解释器交互,只能学到Python细节,无法学到真实知识经验
    • R-Zero:共同进化挑战者和求解者。
    • LSP:自我博弈。
  • 缺点:无法获得 超出固定环境模型现有储备之外的新知识

想法

  • 基于真实动态Repo,Agent和代码环境交互学习,不依赖人类训练数据。
  • Self-Play + 真实世界仓库

Self-Play SWE-RL

📕核心方法

核心思想

Self-Play SWE-RL

核心思想

  • 沙盒环境 + 代码仓库 + 工具集(来自CWM, Bash+Editor)
    • 无需:单元测试、Issue描述、执行测试命令、特定语言先验知识等。
  • 1个LLM2个角色(不同prompt),Injector-造BugSolver-修复Bug
  • 通过造Bug+修Bug迭代式循环提升共同对抗式-RL训练

优点

  • 通过self-play,模型生成多样化+有挑战+不断进化课程
  • 静态bug无法比拟

高阶Bug

  • Solver失败的尝试,作为高阶Bug
  • 类似真实开发中多步骤、相互依赖的修改。

生成Bug(Injector)

Bug 套件

Bug本身

  • bug_inject.diff:向代码注入Bug

隐蔽手段

  • test_weaken.diff移除或削弱测试隐藏Bug

  • 正常情况

    • 开发过程,遇到一个隐藏bug才去去写单元测试,去修复它。
  • 这里

    • 隐藏对应单元测试隐藏Bug,避免直接状态检测机制不通过、无法合并等情况。
    • 模拟一个真正潜藏Bug的状态。

防作弊手段

  • test_files.txt:测试文件列表,避免AI直接修改测试文件,每次测试时直接恢复。

验证工具

  • test_scripts.sh:运行测试套件,检测错误、验证修复
  • test_parser.py:解析测试输出结果,每个测试ID映射到结果。
Bug Injector Agent

目标

  • 探索仓库,生成高质量适配SolverBug,并给到Bug Solver。

Bug制造策略

  • 代码移除
    • 删掉某个文件、删掉大段核心逻辑
    • 迫使Solver重写代码,功能开发。
  • 历史回滚
    • AI 去翻阅历史Git Log,找到以前的修改,撤销,重新引入旧 Bug
    • 利用人类程序员的历史智慧。
  • 高阶Bug
    • Injector制造BugSolver失败的解法,这个烂代码就变成新Bug 题目
    • 优点:非常真实(人类就这样的),多样性好覆盖全

约束和质量控制

  • 约束条件
    • 避免低级情况:直接删除某函数,直接报错缺乏xx函数
    • 删除函数后,需修改调用地方,保证代码能跑通但结果是错的
  • 质量控制
    • 设置最小文件更改数
    • 必须有测试失败(有bug),必须有测试通过(环境没崩)

一致性验证

  • 基础检查
    • 测试文件检查:AI指导的测试文件是否真存在,而不是幻觉。
    • 解析器检查:AI写的python解析脚本能不能跑。
    • 脚本检查:在源代码库上运行测试,必须通过。
  • Bug质量检查
    • 规模检查:修改的文件数量 不能太少(如5个)
    • Bug检查:注入Bug后,必须有测试Fail
  • 隐蔽性检查
    • 注入Bug,删掉部分测试原报错消失
  • 逆向高级检查(无冗余检查)
    • 避免AI注水无关紧要的更改,剔除冗余代码。
    • 所有文件都改坏,然后逐个恢复,检查Bug是佛会减少。
Bug Injector 奖励学习信号

概览

  • 一致性反馈:生成正确可用的Bug
  • Solver反馈
    • Solver 秒解决 - 题目太简单:Injector 得分低
    • Solver 解不开 - 题目太困难:Injector 得分低
    • 寻找处于Solver能力边界上的难题

公式

  • 权衡Bug一致性Solver解决率(s),α=0.8超参rinject={1,一致性验证失败α,s{0,1}1(1+α)s,0<s<1

修复Bug(Solver)

Bug Solver Agent

Bug 代码构建

  • 注入Bug应用bug_inject.diff

  • 掩盖测试应用test_weaken.diff

  • 高阶Bug(可选):应用pred_patch.diff

  • 销毁证据:不能保留.git 历史,防止Solver查看git diff或 git log

Prompt 设计

  • Issue 很难写、数据少,因此不使用自然语言描述
  • 给模型看代码差异:test_weaken.diff的反转版,直接展示对应Bug的单元测试
    • 请修复源代码保证把这个测试加回去代码能跑通

修复过程

  • 输入:坏代码库 + 请修好它的初始Prompt
  • 过程:思考 -> 调用工具 -> 环境交互运行测试迭代循环
  • 输出:pred_patch.diff

奖励设计

  • 所有测试都通过,得1分。rsolve={1,通过所有测试1,其他

对抗奖励

  • Solver:受益于更高的解决率
  • Injector:受益于更低的解决率

实验设置(联合对抗RL)

✍️实验设置

实验设置

基础模型

  • CWM-sft-32B,没有RL训练过

训练任务/数据

  • Baseline:人类的Issue + RL,仓库可能是SWE-B-Verified + SWE-B-Pro里的。
  • Self-PlayRL:SSR

评测任务/数据

  • SWE-Bench-Verified, SWE-Bench-Pro
  • 超参:温度=1,topp=0.95

算法/策略

  • 对抗式联合RL训练1个LLM,同时生成Bug修复Bug

  • 大Batch尽量On-Policy (small-policy-staleness),让梯度更新更稳定

    • 去掉超过8 off-policy的数据
  • CWM scaffoldbash + search-replace 编辑器

超参

  • 512 H100,64卡训练448卡Rollout
  • 128k
  • Global Batch Size:16M token,整体150步,2.5B tokens

关键结果(CWM-sft-32B + 对抗RL)

🍑关键结果

关键结果

模型效果(CWM-32B-sft)

  • 在SWE-V和SWE-Pro上,SSR方法都超过RL+人类Issue训练的模型,但也没高多少
  • SWE-V51.4分SWE-P28.9分

重要结论

  • Self-Play RLRepair/Injection-Only RL 性能更好Inject-Only 效果最差。
  • 大幅删除代码的Bug更好比仅改一行代码的Bug的好。后者太简单,学习信号弱。
  • 由于共享1个Policy,Solver解决率信号 对训练效果影响不大

关键贡献

  • Self-Play-RL思想,只需环境+代码, LLM自我博弈,写Bug+修Bug,联合RL训练。

未来方向

未来方向

未来方向

不足点

  • Solver可能会作弊,面向测试编程。因为读取了所有测试用例
    • Public Tests 给AI看, Private Tests实际测试
  • 测试单一,仅靠单元测试。
    • 引入高级验证标准
  • Injector和Solver是同1个模型,可能导致思维趋同。
    • 引入不同模型博弈MoE等。

Self-Play 研究方向

  • 更聪明的出题方法
    • 需要指定Seed,给Injector指定目标,避免随机重复写Bug,保证多样性。
  • 合成复杂的多步骤SWE任务
    • 多上下文回放、上下文压缩、高阶Bug升级等。
  • 更高效的Long-Horizon SWE训练方法。
    • 目前很长+Outcome RL,存在信用分配问题。
    • 每跑一公里,就自我检查一下。
    • 给出结构化建议,比如某一步出错等。
总访客数:— · 总访问量:—
PLM's Blog @ 2016 - 2026