SWE-at-Scale: Scalable Issue Synthesis from Historical Bug Fixes
Silin Chen, Zihan Zhang, Xiaodong Gu, Jiale Huang, Yuling Shi, Han Li, Zhao Shan, Chengcheng Wan, Zhensu Sun, Haibing Guan
cs.SE
2026-10-15
上海交大等把13407条真实修复倒成注错监督,微调Qwen3.5-9B后合成题人工偏好61.2%,四款agent Pass@1低至16.81%,单文件采样200次仍有88.27%补丁不重复。
仓库级 SWE 题得同时具备真实仓库、测试能观测的行为 bug、像用户写的 issue,以及能跑的环境。SWE-bench 真题跟着 GitHub issue 的自然速度增长,还受仓库许可和环境成本约束。靠多收真 issue 扩不出评测集。
SWE-smith 用提示改函数或重写代码,SWE-Synth 重写组件再滤测试,BugPilot 让 agent 加功能并留下弄挂的回归。这些 bug 超出了手写变异规则,但模型没专门学过怎么把对的代码写坏。多抽几次,就会回到预训练里熟悉的错法。
历史修复里记着 bug 如何形成。补丁倒过来,修复监督就变成锚在真实开发上的注错监督。SWE-at-Scale 用这个分布到新代码里反复采样。
监督来自 SWE-Fixer、SWE-rebench、SWE-bench-Live 和 SWEGym,原始超过 13.4 万条 issue-fix。把 golden patch 打回 buggy 仓库得到修复后文件,再算出回到 buggy 版本的 unified diff,这就是注错目标。正反补丁都要 round-trip 成功。
筛掉非代码、格式类改动、不完整 diff 和超 64K token 的样本,并剔除 Verified 仓库。分布采样加人工检查后,留下 688 库、13407 条。Logic 与 Interface 最多,真实数据里这两类本来就多。
Qwen3.5-9B 吃进带行号的完整正确文件,不被告知改哪一行,自己决定位置和改法。LoRA 微调一个 epoch,64K 上下文,一张 RTX PRO 6000。
只保留至少打挂一个原先通过的回归测试的候选,叫做 P2F。再写成 GitHub 风格的 issue。
对照实验统一用 Verified 每条实例的同一文件和正确状态,每文件最多五次,首次温度 0,其后 1.0,一出 P2F 就停。SWE-smith 只能改真实补丁所在的函数。解题用 mini-SWE-agent,温度 0,最多 250 步,写题模型不解题,三次取平均。
可用性看五次内能否得到非平凡 P2F,排除换成 pass、TODO 或 return None。真实感 HPR 由三名三年以上工程师多数票决定,比较同一上下文里合成样本和真 issue 哪个更像日常开发。Pass@1 越低,题越难。
| 方法 | 可用性 | HPR | Pass@1 |
| SWE-at-Scale | 72.6% | 55.9% | 31.68%-48.48% |
| SWE-at-Scale+ | 94.0% | 61.2% | 16.81%-37.02% |
| LLM-Rewrite 最好配置 | 72.2% | 51.8% | 高于反向修复两条路线 |
| FeatAdd(DS-V4-Flash 合成) | 文中称明显更低 | 真实感不差 | 37.93%-62.07% |
| SWE-bench Verified | 真题 | 成对对照 | 69.60%-97.00% |
| DeepSWE | 专家命题 | 未做同款投票 | 24.30%-63.40% |
四款解题模型按 DeepSeek-V4-Flash、GPT-5.4-mini、GLM-5.3-Flash、Qwen3.8-Flash 排列,Scale 的 Pass@1 为 48.48%、31.68%、42.15%、44.44%,Scale+ 为 33.19%、16.81%、35.32%、37.02%。Scale+ 在每一列都更低,也低于 Verified 和提示式基线,并进入 DeepSWE 的难度带。
指定位置注入像局部变异,LLM-Modify 的 HPR 垫底。重写更接近无意写错,最好也只有 51.8%。
MBTE 是单文件上 bug 类型熵的宏平均。训练固定 2000 条、仓库从 5 增至 100,MBTE 上升,可用性大致持平。50 个文件上,温度 0 时 MBTE 0.527、可用性 69.0%,温度 0.6 到峰值 1.173,温度 1.0 掉到 0.714、可用性 23.4%。
预算加到每文件 200 次、温度 0.6,MBTE 从 0.583 比特升到 2.063,可用性在 50 次以后停在约 47%。4749 条可用补丁里 4192 条归一化后仍唯一,占 88.27%。同设置 LLM-Modify 只有 1.22 比特、44.1% 可用、61.74% 唯一。Scale 与 Scale+ 平均改动 18.793 与 18.536 行,Verified 为 14.334 行。单条消耗 17.45k token,LLM-Rewrite 要 34.92k-62.82k,FeatAdd 要 2.29M。
搭环境通常比造 bug 贵。正确仓库和测试可以复用,同一文件能抽出多种错,200 次之后 diff 仍有 88.27% 不重复。9B、一张 RTX PRO 6000、一个 epoch,就把 13407 条修复变成生成器,单条成本比 FeatAdd 低两个数量级以上。
已有 Python 测试仓库时,适合拿来扩评测。相对提示注错,多样性和难度是实的。相对人工题,它仍是合成数据。Scale+ 更难更好用,但多老师模型和 executor。直接出 diff 的版本更好复现。这些题能否训练出更强 agent,论文没有测。
覆盖只限 Python,其他语言没有迁移实验。测试盖不住的 bug 会被丢掉,测试稀的仓库留题很少。
HPR 61.2% 表示票更多给了合成样本。评审三人,主文没给配对数量和一致率。投票容易偏向干净、刚好打挂测试的改动,到不了「比真 issue 更真实」。
Pass@1 把 bug 难度和 LLM 写的 issue 绑在一起,文案一飘,通过率就掉。Scale+ 更低的那一截有多少来自 bug 本身,没有拆开。94% 可用性是五次里成一次,温度 0.6 的单次可用率约 47%,两套口径不能混用。
Scale+ 的模式由 DeepSeek-V4-Flash 撰写,9B 只仿写,改代码靠 executor。没有「executor 固定、模式改由普通模型写」的对照,学生模型贡献了多少算不清。
18.8 行对 14.3 行不是复杂度。88.27% 是 diff 唯一,不是行为唯一。MBTE 到 200 次仍在涨,100 次后已放缓。合成还锚在 Verified 文件上,基线被限制在真实补丁所在函数内,Scale 自己选位置,难度差不能全记在注错分布上。脚手架只有 mini-SWE-agent。