SWE-Swiss:北大、字节跳动等联手实现中等规模AI模型软件Bug修复新SOTA

SWE-Swiss:小尺寸模型达到代码修复SOTA,配方和模型已开源。

原文标题:北大、字节跳动联手发布SWE-Swiss:一把修复代码Bug的「瑞士军刀」,完整配方直指开源SOTA

原文作者:机器之心

冷月清谈:

北京大学、字节跳动等机构联合发布了“SWE-Swiss”项目,旨在高效训练解决软件工程问题的AI模型。该项目提出了一套完整的“配方”,使得一个中等规模的32B参数模型SWE-Swiss-32B在权威基准SWE-bench Verified上达到了60.2%的顶尖准确率,刷新了同尺寸模型的SOTA记录。SWE-Swiss的核心在于将代码问题解决流程解构为代码定位、代码修复和单元测试生成三项关键技能,并通过验证性拒绝采样确保训练数据质量。其训练方法分为两阶段:首先通过多任务监督微调(SFT)构建基础能力,随后通过两阶段强化学习(RL)提升核心修复技能。在评估阶段,该模型还引入了“增强自我一致性”策略,进一步提升了性能。该研究不仅证明了小模型也能实现顶级性能,更为软件工程领域AI应用提供了新思路,并已将模型和数据集全部开源,以促进社区发展。

怜星夜思:

1、SWE-Swiss这种能自动修复代码bug的AI,你觉得它未来会怎么改变我们敲代码的方式?是会帮我们提速,还是说会让我们这些“码农”压力更大了?
2、文章提到自动化解决真实软件问题是个大挑战。SWE-Swiss现在能修bug,但像软件架构设计、复杂需求分析这些更“高级”的活儿,你觉得AI啥时候能挑起来大梁,甚至有没有可能?
3、SWE-Swiss把模型和数据都开源了,这对我们普通开发者或者小团队来说,除了研究意义,还有啥实际用处没?比如能直接拿来干点啥,或者能省多少钱省多少事儿?

原文内容


图 1: SWE-bench Verified 上的性能与模型尺寸对比。该研究的 32B 模型 SWE-Swiss,取得了 60.2% 的顶级分数,与更大的模型如 Kimi-Dev, DeepSeek-R1-0528 处于同一梯队。这证明了该研究的训练配方能让一个小得多的模型达到同样的 SOTA 性能级别,凸显了其卓越的效率。


近日,一项由北京大学、字节跳动 Seed 团队及香港大学联合进行的研究,提出了一种名为「SWE-Swiss」的完整「配方」,旨在高效训练用于解决软件工程问题的 AI 模型。研究团队推出的 32参数模型 SWE-Swiss-32B,在权威基准 SWE-bench Verified 上取得了 60.2% 的准确率,在同尺寸级别中达到了新的 SOTA。该工作证明,通过精巧的方法论设计,中等规模的模型完全有能力实现顶级性能,为 AI 在软件工程领域的应用提供了新的思路。为促进社区发展,该研究的模型、数据集将全部开源。



  • GitHub 地址: https://github.com/zhenyuhe00/SWE-Swiss

  • Hugging Face 模型和数据: https://huggingface.co/SWE-Swiss


引言:软件工程 AI 的挑战与机遇


自动化解决真实世界的软件问题,是大型语言模型(LLM)面临的一项艰巨挑战。相较于纯粹的代码生成,这项任务要求模型具备理解复杂上下文、定位问题、生成修复并进行验证的综合能力。现有框架(如 Agentless)已证明,将此复杂任务分解为结构化工作流是一条可行的路径。然而,如何高效地训练一个模型以精通所有环节,是当前研究的核心问题。


本项工作提出的 SWE-Swiss 配方,正是为了解决这一问题。其核心原则是,通过对软件工程中的核心能力进行显式建模和训练,来构建一个功能强大且高效的问题解决模型。


方法概览:结构化的「SWE-Swiss 配方」


图 2: 由三个核心能力驱动的 LLM 补丁生成流程图示。模型首先利用问题描述和代码库结构进行代码定位和测试生成,随后修复模块利用定位和检索到的文件生成补丁,最后所有生成的测试和已有测试被用来过滤和验证最终的补丁。


SWE-Swiss 配方将问题解决流程解构为三项核心技能:


  • 代码定位 (Localization): 准确识别需要修改的文件。

  • 代码修复 (Repair): 生成能解决问题的正确代码补丁。

  • 单元测试生成 (Unit Test Generation): 创建单元测试以验证修复的有效性。


为确保训练数据的质量,研究团队采用验证性拒绝采样的来构建数据集。该过程首先生成大量候选数据,随后通过严格的、基于测试的自动化验证流程进行筛选,只保留被成功验证的样本用于模型微调


两阶段训练方法


SWE-Swiss 的训练分为两个主要阶段:


  • 第一阶段:通过多任务 SFT 构建基础能力


    此阶段将上述三种技能共 10,254 个高质量样本混合,对 Qwen2.5-32B 模型进行监督微调。这使得模型能够对整个问题解决流程建立全面的基础理解。完成此阶段后,模型在未进行测试时扩展的情况下,取得 36.0% 的基准性能。


  • 第二阶段:通过两阶段 RL 精通核心技能


    在 SFT 模型的基础上,此阶段专注于通过强化学习提升最关键的「修复」能力。受 POLARIS 的启发,团队设计了


两阶段 RL 课程:首先,模型在完整数据集上训练 200 步以建立广泛能力;随后,通过基于性能的剪枝,移除模型已掌握(准确率 > 90%)的简单样本,让模型在接下来的 90 步训练中专注于更具挑战性的难题。


这一阶段效果显著,在单补丁生成模式下,模型性能从 36.0% 跃升至 45.0%


图 3: 两阶段强化学习过程中的性能提升曲线。第一阶段(0-200 步)显示了在完整数据集上训练的稳定提升。第二阶段(200 步之后)则是在过滤后更具挑战性的数据集上继续训练,带来了进一步的性能增益。


测试时扩展


在评估阶段,类似 Agentless 和 Agentless Mini,SWE-Swiss 采用多补丁生成与过滤的策略。在自我一致性 (self-consistency) 的基础上,团队提出了一种「增强自我一致性 (Enhanced Self-consistency)」的最终选择方法。


传统的自洽性方法依赖于代码的「完全一致」匹配,这在语法细节多样的代码场景下存在漏洞。增强自我一致性则通过引入相似度度量,不仅奖励与最多数完全相同的候选者,也奖励那些处在「相似解决方案」密集区域的候选者。该方法的最终评分为:


图片

其中,图片 为精确匹配的频率计数,而  为与 top-k 个最相似邻居的平均相似度得分。


图 4: SWE-Swiss-32B 的测试时扩展性能,增强自我一致性在 120 个补丁时达到了 60.2% 的准确率。


结论与开源


本项研究工作的核心贡献在于提出并验证了一套完整的、高效的 SWE-Swiss「配方」。实验证明,该配方能够使一个 32B 的中等规模模型和更大的模型相媲美。从 SFT 后的 36.0%,到 RL 后的 45.0%,再到结合测试时扩展和增强自洽性的最终 60.2%,这一系列的性能提升清晰地展示了配方中每一个环节的价值,为业界提供了一条通过优化大模型软件工程能力的有效路径。


该团队将开源 SWE-Swiss-32B 模型、全部训练数据,以期为社区的后续研究提供支持。



© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com


楼上的说得对,直接用肯定能省钱。但我觉得更深层次的好处是“赋能”和“学习”。开源意味着代码和数据集都是透明的,普通开发者可以下载下来,不仅仅是使用,更可以研究它的实现原理、训练方法,甚至尝试在此基础上进行二次开发和定制化。这对于提升个人技术能力,或者让小团队探索AI+DevOps的更多可能性,都有巨大的价值。你可以根据自己的项目特点,微调模型,让它更适应你的特定需求,这就不是简单地“省钱”,而是提升了团队的技术栈和竞争力。

除了上面两位说的,我觉得开源对整个技术社区的影响更大。SWE-Swiss的开源,就像是给社区提供了一把高质量的“锤子”和一份详细的“说明书”。其他开发者可以基于这个基石,去尝试新的训练方法、探索更广泛的应用场景,或者针对特定语言、特定框架进行优化。这就像搭建了一个乐高积木的底座,大家都能在上面发挥创意,共同推动这个领域的发展。对于小团队来说,如果能参与到这样的开源协作中,不仅能借力,还能提升自身影响力,最终实现“站在巨人肩膀上”的创新。

你这个问题触及到AI能力的边界。当前AI,包括SWE-Swiss,本质上是基于模式识别与概率生成。它擅长处理有明确输入、可量化输出且存在大量可学习模式的问题。软件架构和需求分析则包含大量的隐性知识、非确定性决策和人类的“意图理解”,这些通常难以被结构化和量化。AI或许能成为强大的“知识助理”,帮助我们整理信息、模拟场景,甚至推荐一些“最佳实践”,但最终的“拍板”和“创造性突破”依然需要人类的直觉和智慧。所以,AI“挑大梁”可能不在于“取代”,而在于如何通过其强大的信息处理能力,赋能人类在这些高级任务中做出更优决策。

当然有用了!这个问题太实际了。对于普通开发者或小团队来说,直接用开源模型意味着可以省去巨大的研发成本和时间,不需要从零开始训练一个代码修复模型。你可以把它集成到你的CI/CD流程里,让它自动跑代码审查,找出并建议修改一些常见的bug,尤其是在一些开源项目或者内部的小型工具开发中,这简直是开箱即用的“自动质检员”啊!省钱省事儿不说,还能大大提高代码质量和开发效率。

这个问题问得好!我觉得SWE-Swiss这种AI肯定能帮我们提速不少。你想啊,平时我们花很多时间在定位和修复那些小bug上,尤其是那种低级错误。如果AI能自动识别并给出补丁,甚至集成到IDE里,那我们就能把更多精力放在更复杂的逻辑设计和创新上了。相当于多了一个不知疲倦的初级“助手”,解放了生产力,而不是取代人,反而是让我们码农的工作更有价值吧。

我觉得这只是时间问题,虽然挑战巨大。就像SWE-Swiss从简单的代码生成到能定位、修复、生成测试一样,AI的能力是一步步演进的。现在可能还只是辅助我们做一些架构模式的推荐、代码规范的检查,或者从海量数据中提炼用户需求趋势。未来,随着AI对语义理解和推理能力的进一步提升,它可能会在架构决策的早期阶段提供更多有价值的洞察,比如评估不同架构方案的利弊,或者识别潜在的技术债务。完全“大包大揽”可能很难,但作为“超级大脑”提供决策支持,我觉得可能性很大。

关于SWE-Swiss对编码方式的影响,我认为这符合技术演进的一般规律。短期内,它无疑将作为辅助工具,显著提升开发效率,尤其是在重复性高、逻辑结构清晰的错误类型上。它能减少回归测试周期,加速迭代。然而,对于涉及深层业务理解、架构权衡或需要创造性解决方案的复杂缺陷,AI目前仍难以胜任。因此,对人类程序员而言,关键在于从低层次的“修复者”转向高层次的“设计者”和“决策者”,专注于AI无法触及的领域。压力更多来源于适应性而非消灭性竞争。

问得好!修Bug和架构设计、需求分析根本不是一个维度的事儿。修Bug某种程度上是“找茬+照章办事”,有明确的规则和上下文。但架构设计和需求分析,这涉及到对业务的深刻理解、预判未来的扩展性、考量非功能性需求(比如性能、安全),甚至还有人际沟通和权衡。这些都需要高度抽象思维、创造力和领域知识。虽然AI能生成代码,但在这种高度抽象和不确定性强的领域,我觉得AI要挑大梁还非常非常远,甚至可能永远无法完全取代,因为它们缺乏“意图”和“经验”。

哎呀,你这个问题一针见血!提速是肯定的,但压力会不会更大就不好说了。万一AI修bug修得比我还快,老板是不是会觉得我效率不够高?以后面试是不是还得考“你和SWE-Swiss比,优势在哪?” 哈哈,开玩笑的,但我觉得未来是不是要学着怎么“驾驭”这些AI工具,让它们为我所用,而不是被它们“卷”得更厉害,这可能是个新趋势。