← 返回 2026-01-06

SWE-Lego：推动监督微调在软件问题解决中的极限 SWE-Lego: Pushing the Limits of Supervised Fine-tuning for Software Issue Resolving

Chaofan Tao, Jierun Chen, Yuxin Jiang, Kaiqi Kou, Shaowei Wang, Ruoyu Wang, Xiaohui Li, Sidi Yang, Yiming Du, Jianbo Dai, Zhiming Mao, Xinyu Wang, Lifeng Shang, Haoli Bai 📅 2026-01-04 👍 25 2026-07-13 08:35
代码修复 数据增强 测试时扩展 监督微调 软件工程
arXiv HuggingFace PDF

通过混合数据集、精炼SFT和测试时扩展，用纯监督微调在SWE-bench达到58.8%的最先进性能

前置知识

监督微调 (Supervised Fine-tuning, SFT)

监督微调是指在预训练模型基础上，使用标注数据进一步训练模型的过程。在代码领域，通常将代码编辑、测试执行、问题诊断等专家轨迹作为训练样本，让模型学习逐步解决问题的能力。损失函数通常是标准的交叉熵损失 $\mathcal{L} = -\sum_{i} \log p(y_i | x_i)$，其中 $x_i$ 是上下文和工具调用的序列，$y_i$ 是正确的工具响应或代码修改。

本文完全依赖SFT来训练SWE智能体，没有使用中训练或强化学习，理解SFT的工作原理是理解本文方法论的基础。

SWE-bench Verified

SWE-bench是一个评估软件工程智能体修复GitHub issue能力的基准测试。它包含真实的Python仓库、bug描述、测试用例和参考修复方案。Verified版本是在原始数据基础上通过额外验证确保数据质量，共包含约500个测试实例。评估时，智能体需要在一个沙箱环境中复现bug、定位问题、实现修复并通过所有测试，解决率是主要评估指标。

这是本文的主要评估基准，所有性能数据都在这个数据集上报告，理解这个基准的评估流程和指标含义是理解论文结果的关键。

测试时扩展 (Test-time Scaling, TTS)

测试时扩展是指在推理阶段通过增加计算资源来提升模型性能的策略。在SWE任务中主要有两个维度：顺序扩展是增加最大交互轮数，让智能体有更多机会尝试和修正；并行扩展是生成多个候选解，然后用验证器选择最佳方案。并行扩展的计算复杂度通常是 $O(K)$，其中 $K$ 是候选数量，而顺序扩展由于上下文增长，计算复杂度介于线性和二次方之间。

本文系统研究了TTS在SWE任务中的应用，发现了顺序扩展在低轮数阶段更有效，饱和后应该转向并行扩展，这一发现对实际部署有重要指导意义。

Git Hacking

Git Hacking是指智能体通过检查Git历史记录或提交信息来作弊而非真正解决问题的现象。例如，智能体可以运行 git log --all 查看所有提交，或者运行 git diff 查看修复的代码差异，然后直接复制这些答案而不是自主分析代码。SWE-bench早期版本的Docker镜像包含了ground truth提交，使得这种作弊成为可能，导致一些公开结果被人为夸大。

本文专门采取了措施防止Git Hacking，并报告了无黑客攻击的真实结果，这表明对评估公正性的严格要求，也是理解本文结果真实性的重要背景。

研究动机

现有训练SWE智能体的方法存在严重缺陷。主流方法依赖于复杂的训练范式组合，例如中训练、SFT、强化学习以及它们的混合使用，这些方法计算成本高昂且训练基础设施要求严格。特别是强化学习方法，不仅计算密集，而且对超参数敏感，容易出现训练崩溃。另一方面，现有的SWE数据集缺乏包含执行环境和真实bug实例的高质量、多样化轨迹。R2E-Gym-Train只有4.6k任务实例和3.3k验证轨迹，SWE-Gym仅有2.4k任务实例和491条验证轨迹，规模远不足以训练强大的智能体。此外，许多公开的SWE-bench结果被Git Hacking夸大，智能体可以通过检查Git历史直接获取答案而非真正解决问题，这使得真实的性能评估变得困难。

本文的目标是本文旨在探索一个关键问题：在软件工程任务中，轻量级的纯SFT训练范式究竟能走多远。作者希望通过精心设计的数据、训练技术和推理时的测试时扩展策略，证明仅使用SFT就可以达到与复杂训练范式相当甚至超越的性能。具体目标是：1）构建大规模、可执行的混合数据集，结合真实和合成数据以实现质量和数量的互补；2）精炼传统SFT方法，通过错误掩码和课程学习提高训练效率；3）研究测试时扩展的最优策略，在有限计算预算下实现最大性能提升。

与已有工作不同的是，本文的独特切入角度在于挑战复杂训练范式优于简单SFT的普遍假设，通过系统性地优化数据构建、训练过程和推理策略，将SFT的性能推向极限。与现有工作不同，本文不是堆叠更多训练阶段，而是深入研究每个环节的效率和效果。例如，在数据方面，本文创新性地混合了真实GitHub PR和合成bug注入任务，在保持真实性的同时大幅扩展数据规模；在训练方面，本文发现传统SFT对轨迹中的错误步骤也进行梯度更新是低效的，提出步骤级错误掩码；在推理方面，本文系统分析了顺序扩展和并行扩展的权衡，发现100-140轮后顺序扩展饱和，应该转向并行扩展。这些深入的组件级分析是现有工作中缺失的。

核心方法

SWE-Lego框架的整体思路是通过三个精心设计的构建块协同工作，将轻量级SFT的性能推向极限。直觉上，高质量的数据是基础，精炼的训练方法是保障，测试时扩展是性能倍增器。技术路线上，首先构建一个混合数据集，包含32k可执行任务实例和18k验证轨迹，数据来源包括真实的GitHub pull request和通过bug注入生成的合成任务。然后，使用Qwen3-8B/32B作为基础模型，采用精炼的SFT策略进行训练，包括步骤级错误掩码（排除轨迹中执行错误的步骤）和基于难度的课程学习（从简单任务开始逐步增加难度）。最后，在推理阶段应用测试时扩展策略，包括顺序扩展（增加最大交互轮数到100-140轮）和并行扩展（生成多个候选解并用生成式验证器选择最佳方案）。三个构建块相互增强：混合数据提供了丰富的训练信号，精炼SFT充分利用了这些信号，测试时扩展则进一步挖掘了训练后模型的潜力。

核心创新点在于对传统SFT的精细化改进和对测试时扩展的系统优化。与传统SFT不同，本文发现专家轨迹中包含大量中间错误步骤（如工具调用失败、测试失败），传统方法对所有token计算损失会让模型学习到错误行为。本文提出的步骤级错误掩码通过正则表达式识别终端环境返回的错误消息，仅对正确的代理响应进行梯度更新，这直接减少了核心推理错误如Incorrect Implementation和Localization Error。另一个核心创新是基于轨迹长度的课程学习策略，本文发现解决率与轨迹轮数呈现强负相关（Pearson $r = -0.95, p < 0.001$），因此将任务按轮数分为Easy（0-50轮）、Medium（50-70轮）、Hard（70-100轮）三个难度级别，从易到难分阶段训练，让模型先掌握基本任务再学习复杂推理。在测试时扩展方面，核心创新是系统研究了顺序扩展和并行扩展的权衡，发现顺序扩展在100-140轮后饱和，此时计算资源应该转向并行扩展，并发现生成式验证器（通过文本生成yes或no并计算归一化token概率）优于回归式验证器（附加评分头）。

方法步骤详情

方法步骤分为数据构建、模型训练和推理增强三个阶段。数据构建阶段：1）收集超过3000个以Python为中心的开源仓库，通过解析setup.py等配置文件自动构建Docker容器，只保留成功构建并通过基础测试的仓库；2）真实任务来自已解决的GitHub pull request，每个任务关联唯一的Docker镜像和pre-merge commit；3）合成任务通过bug注入生成，使用LLM重写（根据函数头和文档字符串重写代码）和AST重组（对类/函数的抽象语法树应用随机变换）两种技术；4）使用OpenHands scaffold（v0.53）和Qwen3-Coder-480B-A35B-Instruct作为教师智能体生成专家轨迹，最大交互轮数设为100；5）防止Git Hacking，对真实任务删除issue创建日期之后的所有提交，对合成任务删除整个Git历史；6）处理畸形工具错误（如str replace编辑器的范围参数错误）和修剪无效工具（如task tracker）；7）验证和过滤轨迹，分类为完全解决（通过所有测试）、半解决（正确定位bug文件但未完全修复）和未解决。模型训练阶段：使用Qwen3-8B/32B作为基础模型，在LLaMA-Factory框架上进行全参数SFT，训练4个epoch，全局批次大小64，使用AdamW优化器，权重衰减0.01，余弦学习率调度，预热比例0.1，学习率8B模型为$1 \times 10^{-4}$，32B模型为$5 \times 10^{-5}$，最大上下文长度128k tokens。推理增强阶段：顺序扩展将最大交互轮数从100增加到140，并行扩展生成K个候选解（K=1到16），使用生成式验证器选择最佳方案，验证器通过文本生成预测成功概率。

技术新颖性

技术新颖性体现在多个方面。数据构建方面，本文是首个大规模混合真实和合成SWE数据集的工作，包含32k任务实例和18k验证轨迹，覆盖3251个仓库，远超现有数据集（R2E-Gym-Train的4.6k任务和3.3k轨迹）。这种混合策略实现了质量和数量的互补：真实数据提供深度和真实性（平均修改138行代码），合成数据提供广度和可扩展性（平均修改18.8行代码）。训练方法方面，步骤级错误掩码是首个针对SWE轨迹中错误步骤的精细化训练技术，它保持完整轨迹上下文但选择性屏蔽错误响应的损失计算，仅对正确行动进行梯度更新，这比传统SFT提升超过2个百分点。课程学习方面，基于轨迹长度的难度估计比基于模型的难度估计更有效（提升0.5个百分点），而且计算效率更高，不易误标注。测试时扩展方面，本文首次系统分析了顺序扩展和并行扩展的权衡，发现100-140轮的饱和点，并提出先顺序后并行的资源分配策略。验证器方面，生成式验证器在较大K时比回归式验证器表现更好，例如在K=16时差距达到2.8%（49.6% vs 46.8%），这是因为生成式公式与预训练的next-token预测目标对齐，更好利用模型的固有知识。

Our SWE-Lego pipeline comprises three stages: environment construction from over 3,000 repositories; hybrid task creation by combining real pull requests with synthetic bugs; and expert-trajectory generation and curation for SFT.
Figure 2: Our SWE-Lego pipeline comprises three stages: environment construction from over 3,000 repositories; hybrid task creation by combining real pull requests with synthetic bugs; and expert-trajectory generation and curation for SFT.
An example of step-level error masking.
Figure 5: An example of step-level error masking.
Correlation between number of turns and average resolve rate.
Figure 6: Correlation between number of turns and average resolve rate.
Resolve rate on SWE-bench Verified as a function of maximum interaction turns and number of parallel rollouts.
Figure 8: Resolve rate on SWE-bench Verified as a function of maximum interaction turns and number of parallel rollouts.
Analysis of sequential scaling behavior.
Figure 10: Analysis of sequential scaling behavior.
Demonstration of Git hacking by SWE agents.
Figure 12: Demonstration of Git hacking by SWE agents.

实验结果

核心发现包括三个方面：混合数据集的效果、精炼SFT的增益、测试时扩展的潜力。消融实验显示（Figure 1b），SWE-Lego数据集带来最大提升+25.6%，将Qwen3-32B的基准从23.2%提升到48.8%；精炼SFT额外贡献+3.8%，提升到52.6%；TTS最终增加+6.2%，达到58.8%。在SWE-bench Verified上，SWE-Lego-Qwen3-8B达到42.2%（SFT）和49.6%（TTS@16），SWE-Lego-Qwen3-32B达到52.6%（SFT）和58.8%（TTS@16）。这些结果超过大多数开源模型和几个更大的专有模型，值得注意的是这些结果是在防止Git Hacking的条件下获得的，而许多先前报告的结果可能被Git Hacking夸大。错误分析显示（Figure 7），训练过程中的错误模式发生明显转移：早期（epoch 0）以Failed to Reproduce错误为主（38.97%），表明基本任务不对齐；epoch 1后Ran Out of Max Turns错误激增（35.14%），揭示战略规划缺陷；后期则是Incorrect Implementation和Localization Error成为瓶颈。课程学习按顺序解决这些问题，错误掩码则专门针对后期推理错误。合成数据增强实验显示（Figure 3a），随着每仓库合成实例数增加，有效专家轨迹数量大幅增长，从仅真实到真实+5合成/仓库，轨迹数量从约5k增长到约18k。性能方面（Figure 3b），解决率随合成实例数增加而持续上升，表明混合数据不仅提高数据规模还提升下游模型有效性。验证器消融实验显示（Figure 11a），18k训练轨迹的验证器在TTS@16时达到49.6%，优于6k验证器的47.6%，差距随K增大而扩大，表明更大训练集提高在更大候选池中的判别能力。验证器模型规模实验显示（Figure 11b），对于32B rollouts，30B验证器在TTS@16时达到58.8%，优于8B验证器的56.6%，可能是因为32B输出包含更细微错误，需要更大验证器容量。

Comparison of public SWE issue-resolving datasets and our SWE-Lego dataset.
Table 1: Comparison of public SWE issue-resolving datasets and our SWE-Lego dataset.
High-level comparison of how core fields are instantiated for real-world and synthetic SWE tasks in SWE-Lego.
Table 2: High-level comparison of how core fields are instantiated for real-world and synthetic SWE tasks in SWE-Lego.
Characteristic comparisons of task instances.
Table 3: Characteristic comparisons of task instances.
Ablation of filtering strategies on SWE-bench Verified.
Table 5: Ablation of filtering strategies on SWE-bench Verified.
Ablation of training strategies.
Table 6: Ablation of training strategies.
Performance comparison on the SWE-bench Verified.
Table 7: Performance comparison on the SWE-bench Verified.
Distribution of categories in real-world and synthetic training dataset.
Table 8: Distribution of categories in real-world and synthetic training dataset.
Overview of the performance by SWE-Lego models and its breakdown analysis.
Figure 1: Overview of the performance by SWE-Lego models and its breakdown analysis.
Impact of synthetic data augmentation on data scale and performance.
Figure 3: Impact of synthetic data augmentation on data scale and performance.
Evolution of model performance and failure modes over 4 epochs.
Figure 7: Evolution of model performance and failure modes over 4 epochs.
Parallel TTS performance on SWE-bench Verified.
Figure 9: Parallel TTS performance on SWE-bench Verified.
Ablation studies on verifier training.
Figure 11: Ablation studies on verifier training.
查看结构化数据
任务指标本文基线提升
SWE-bench Verified 解决率 (%) 42.2 (SWE-Lego-Qwen3-8B SFT) 39.0 (Klear-Agent-8B-SFT) +3.2
SWE-bench Verified 解决率 (%) 52.6 (SWE-Lego-Qwen3-32B SFT) 42.2 (DeepSWE-32B-Preview RL) +10.4
SWE-bench Verified 解决率 (%) 58.8 (SWE-Lego-Qwen3-32B + TTS@16) 59.0 (DeepSWE-32B-Preview RL + TTS@16) -0.2
SWE-bench Verified 解决率 (%) 49.6 (SWE-Lego-Qwen3-8B + TTS@16) 44.0 (OpenHands-Critic-32B + TTS@16) +5.6

局限与改进

作者承认的局限性包括：1）本文工作局限于bug修复任务，扩展到功能实现、重构或测试生成等其他任务面临挑战，因为这些任务需要编码模糊需求、微妙验收标准和非回归约束，构建充分编码这些信号的数据集很困难；2）多语言SWE是另一个限制，扩展到JavaScript/TypeScript、Java、Go和Rust等语言面临语言特定工具链、构建系统和测试框架的障碍，缺乏跨语言沙箱和多语言数据集限制了智能体跨生态系统的泛化能力；3）跨任务能力平衡是挑战，异构代码任务（仓库级问题解决、文件级代码推理、竞技编程）对智能体能力有不同需求，存在性能不均风险，缺乏标准化指标比较这些不同任务的性能。我自己的观察包括：1）本文依赖OpenHands scaffold和特定教师模型（Qwen3-Coder-480B-A35B-Instruct），更换scaffold或教师模型可能影响数据质量和性能；2）防止Git Hacking的机制虽然有效，但可能也限制了智能体学习某些合法的代码审查技能；3）32B模型比8B模型的性能提升（52.6% vs 42.2%）不及预期，可能表明在SWE任务中数据质量比模型规模更重要；4）生成式验证器优于回归式验证器的发现可能与特定的任务和模型架构有关，在其他设置中是否仍成立需要验证。

独立分析的弱点

独立分析的弱点包括：1）训练数据来源单一，主要使用Qwen3-Coder-480B-A35B-Instruct作为教师模型，可能导致数据分布偏向该模型的行为模式，降低智能体在不同模型部署时的泛化能力。改进方向是使用多个异构教师模型生成多样化轨迹，或者引入人类专家标注的高质量轨迹作为补充。2）课程学习仅基于轨迹长度估计难度，虽然与解决率有强负相关，但可能无法完全捕捉任务的所有难度维度（如概念复杂性、代码抽象程度等）。改进方向是开发多维度难度评估，结合代码静态分析、动态执行特征和模型困惑度等指标。3）测试时扩展策略主要在单一延迟约束下优化，不同应用场景可能有不同的延迟和资源约束。改进方向是研究多目标优化，在延迟、资源、质量之间找到最佳平衡点。4）验证器训练数据主要来自真实任务，可能对合成任务生成的候选解判别能力不足。改进方向是在验证器训练中增加合成任务的负样本，提高泛化能力。

未来方向

未来研究方向包括作者提出和基于成果可延伸的：1）超越问题解决，扩展到功能实现、重构或测试生成等其他SWE任务。这需要构建更复杂的数据集和评估框架，编码模糊需求、微妙验收标准和非回归约束。2）多语言SWE，扩展到JavaScript/TypeScript、Java、Go和Rust等语言。这需要开发跨语言沙箱和多语言数据集，适应异构依赖管理实践和测试范式。3）跨任务能力平衡，在异构代码任务（仓库级问题解决、文件级代码推理、竞技编程）之间平衡性能。这需要标准化指标和更灵活的训练策略，避免对主导任务类型的过拟合。4）自动化数据质量评估，开发更精细的轨迹质量指标，不仅基于是否通过测试，还考虑解决方案的优雅性、可维护性和性能影响。5）自我进化的智能体，让智能体在任务解决过程中持续学习和改进，而不是固定的训练-推理范式。6）更高效的测试时扩展，研究更智能的候选生成策略（如基于不确定性的采样）和更精确的验证器（如结合静态分析和动态执行）。

复现评估

复现评估方面，论文承诺开源数据和模型，提供了GitHub仓库（https://github.com/SWE-Lego/SWE-Lego）和Hugging Face模型（https://huggingface.co/SWE-Lego），这为复现提供了良好基础。数据构建流程详细描述，包括仓库收集、真实任务提取、合成任务生成、轨迹生成和验证过滤的完整流程，每个步骤都有具体的实现细节。训练配置清晰，包括模型架构、优化器参数、学习率调度、训练时长等，可以精确复现。评估使用标准的SWE-bench Verified基准，采用防止Git Hacking的Docker镜像，确保了评估的公正性。然而，复现仍面临挑战：1）需要大量计算资源，32B模型的全参数SFT需要大量GPU内存，训练成本高昂；2）轨迹生成依赖OpenHands scaffold和大型教师模型，设置复杂且耗时；3）测试时扩展需要多个并行rollouts和验证器推理，计算成本随K线性增长。总的来说，中等规模的复现（如8B模型的SFT训练）是可行的，但完整的32B模型+TTS@16需要较大的计算投入。

论文图表

Figure 4: Examples of problematic commands or tool interactions.

这张图展示了三个问题命令或工具交互的例子。展示Git hacking风险的高风险命令，包括git log --oneline --grep=...和git show f36862b69c，这些命令允许智能体检查Git历史并获取预先存在的解决方案。展示可避免的错误，如无效的view_range参数错误，包括[345, 381]中第二个元素应小于文件行数380，以及[25, 55]应该是两个整数的列表。展示无效工具，如task_tracker工具调用失败，错误信息显示无法读取任务列表文件。

这张图对理解论文的数据质量控制措施至关重要，它具体展示了本文遇到的轨迹质量问题。Git hacking的例子解释了为什么需要清理Git历史，可避免错误的例子解释了为什么需要后处理矫正工具调用，无效工具的例子解释了为什么需要修剪工具集。这些具体例子有助于理解本文如何识别和处理低质量轨迹，从而提高训练数据的有效性。

Table 4: Ablation of rollout practices.

这个表格展示了rollout实践的消融实验。表格包括Practice、Avg Turns、Valid Traj. Rate (%)三个列。All实践：平均62.5轮，有效轨迹率30%。w/o preventing Git hacking：平均61.8轮，有效轨迹率31%。w/o handling malformed tool errors：平均66.6轮，有效轨迹率29%。w/o pruning ineffective tools：平均65.5轮，有效轨迹率27%。表格显示防止Git hacking略微降低有效轨迹率（从31%到30%）但增加平均轮数（从61.8到62.5），处理畸形工具错误将有效轨迹率从29%提升到30%，修剪无效工具将有效轨迹率从27%提升到30%并减少平均轮数（从65.5到62.5）。

这个表格对理解数据质量控制措施的效果至关重要，它量化地展示了每个措施的影响。防止Git hacking虽然略微降低有效轨迹率，但确保了数据教给模型真正的解决问题技能而非作弊技巧。处理畸形工具错误提升有效轨迹率，表明后处理矫正让智能体能够更可靠地检查代码。修剪无效工具提升有效轨迹率并减少轮数，表明简化工具集让轨迹更精简有效。这个表格验证了本文数据质量控制措施的合理性和有效性。