大模型颠覆研发模式：字节跳动是如何在单元测试中落地大模型的?

大模型的出现引发了一场软件工程革命，它根本性地改变了软件开发的流程和方式。当下，越来越多的企业开始在实际的研发工作中，结合大模型增强软件开发在设计、需求、测试、发布和运维等各个环节中的能力，提高质量和效率。

在接受 InfoQ 采访时，字节跳动算法专家张树波表示，大语言模型是一项人工智能基础技术的突破，必然会带来多个行业的变革。2023 年初，字节跳动智能服务团队开始启动大模型 X 智能单测项目。目前，大模型生成单元测试已经在实际业务中落地。

单元测试是保障项目可靠性的重要手段。传统的智能单测生成依赖静态分析、动态分析等工具，对不同的语言需要重新适配。随着模型参数规模的提升，模型的代码理解、代码生成能力也大幅提升，使用模型端到端的生成单元测试，可以低成本地将单元测试覆盖到多种编程语言。然而大模型在单测生成任务上仍存在模型幻觉（随机生成不存在变量名、方法名）和测试分支覆盖不全的问题。

为解决以上问题，字节跳动智能服务团队发现通过任务微调、强化学习等技术可以提升语言模型的单元测试生成语法正确率和分支覆盖率。经过测试，他们的基于 Bloom 70 亿参数模型的生成效果不弱于通用版 ChatGPT 的水平，并且在低端显卡上的推理时延只有 ChatGPT 的 25%。且目前大模型单元测试生成分支覆盖率在实际项目中达到 56%，同时在抖音的 Android、iOS 双端落地，问题有效性达到 80%，修复率 65%。

在今年 9 月 3-5 日举办的 QCon 全球软件开发大会·北京站中，张树波将把以上经验分享给大家。张树波硕士毕业于清华大学，先后就职于 vivo、字节跳动，从事 NLP 算法多年，在智能单测、智能客服、语音助手等业务场景有丰富的落地经验。

在大会开始前，InfoQ 对张树波进行了专访，探索字节跳动是如何在单元测试中落地大模型的，以及大模型对软件研发工作流的改变。以下为对话实录，经编辑。

InfoQ：您在今年 9⽉举办的 QCon 全球软件开发⼤会·北京站上的演讲主题是《⼤模型助⼒智能单测⽣成》，为什么会选择这⼀主题？

张树波：2022 年底 OpenAI 发布 ChatGPT，其效果令人大为震撼，曾经让 NLPer 困扰的自然语言处理问题，例如歧义、长程依赖、知识缺失、推理能力不足等，都得到了很大程度的缓解和解决。大语言模型是一项人工智能基础技术的突破，必然会带来多个行业的变革。2023 年初，我们字节跳动智能服务团队启动了大模型 X 智能单测项目，探索至今，大模型生成单元测试已经在实际业务中落地。这其中我们总结出了一些经验，希望能够帮助听众。

InfoQ：对于这波⼤模型结合软件开发应⽤热潮，您观察到哪些有趣的趋势？

张树波：大模型会让开发更轻松。大模型代码生成会降低开发者编写重复性代码，但是不意味者开发门槛降低，开发者需要具备辨识模型生成是否正确，以及对最终上线负责。当前大模型生成的代码还不能保证绝对正确，甚至有些隐蔽的错误，不容易被新手开发者发现。从这个角度来看，大模型对有经验的开发者助益更大。

大模型如何改变传统单测生成？

InfoQ：在⼤模型出现以前，传统的智能单测⽣成⽅法是什么样的？存在哪些痛点？

张树波：传统的单测生成应用最广、最成功的是基于搜索的单测生成，也就是很多场景都会提到的（search based software testing - SBST），其中集成了非常多的程序分析技术，包括各种各样的静态分析、动态分析以及遗传算法甚至 constrain solving。但因为语言的特性不同，同样的分析技术对不同的语言是需要重新实现的。虽然测试生成的原理在不同语言是通用的，但是强依赖于软件分析技术，那么每新增一种新的语言支持，就需要适配一整套分析技术，成本较大。另外，精确的分析可能会依赖于编译产物，例如动态分析，因此要求目标项目进行编译后才能进行测试生成，提高了生成所需的前置准备要求。

而基于模型的生成可以直接分析源码，无需编译，降低生成的要求，大大扩大适应场景。近几年来应用 repository mining 提升 test generation 甚至 program  repair 效果的工作也在逐渐的增加，说明 NLP 中的一些假设在软工领域也是成立的，比如现有 repository 中包含了 test generation 甚至 program repair 中需要的知识，大家也做了相应的尝试，学习历史知识并应用到新的任务中在软工领域也是大家认可的思路。

InfoQ：应⽤⼤模型后，智能单测⽣成⽅法发⽣了哪些变化？实际效果如何？能完全替代传统的智能单测⽣成⽅法吗？

张树波：这里先补充一个业务应用背景，智能单测一般在开发者代码编写过程中(IDE)和在代码提交后(CI)发挥作用，前者要求可读性、正确性，后者要求正确性、覆盖率指标。应用大模型后，智能单测由传统模版生成+遗传算法的方式向端到端的模型生成方式演化。传统单测在正确性和覆盖率指标上仍然比大模型生成的要高，在 CI 过程中，仍占主导位置，大模型在其中作为补充。而在 IDE 中，大模型生成单测的可读性更好，便于开发者修改，因此在 IDE 中单测更倾向使用大模型生成的结果。

我们智能服务团队的主要基于 Bloom、starcoder 等开源模型做了测试以及微调，经过测试，其中基于 Bloom 的 70 亿参数模型的生成效果不弱于通用版 ChatGPT 的水平，并且在低端显卡（A30）上的推理时延只有 ChatGPT 的 25%。目前，我们的大型模型单元测试生成分支覆盖率在实际项目中达到 56%，同时在抖音的 Android、iOS 双端落地， 问题有效性达到 80%，修复率 65%。同时我们也正在试用火山方舟上大模型的单测生成能力，效果正在评估中。

整体来看，大模型仍有一定局限，发展有个过程，各有千秋，取长补短，可以融合应用 1+1>2，不同场景可以有不同的应用方式。

InfoQ：⼤模型在智能单测⽣成中的应⽤原理是什么？

张树波：大模型单测生成属于代码生成、文本生成的范畴，旨在通过大模型完成端到端的单测代码生成。大模型单测生成输入是待测方法、以及上下文，输出为单元测试函数。随着模型规模的提升，模型的代码理解、单测生成能力也大幅提升。

目前智能服务团队内使用的大模型基座主要是开源模型，例如 Bloom、Starcoder，基于以上大模型，我们对裸模型以及使用单测训练数据微调之后模型，分别做了评估，当前选择了基于 Bloom7B 的微调模型落地。同时我们团队在 Java、Swift、Go 等多种编程语言的大模型落地计划，广泛收集了公开数据集、业务数据集用于微调。

如何提升⼤模型单测⽣成准确性？

InfoQ：您提到⼤模型在单测⽣成任务上仍存在模型幻觉和测试分⽀覆盖不全的问题，对于这两个问题，字节有哪些解决思路？如何提升⼤模型单测⽣成准确性？

张树波：当前我们使用单测生成任务数据在大模型做了微调，让大模型专注单测生成。实验表明，通过构建高质量的训练数据，可以显著提升大模型单测分支覆盖率指标。基于微调后的大模型，通过引入以编译器、静态分析结果作为奖励的强化学习，可以进一步缓解模型幻觉的问题。

微调和强化学习的基本假设是模型在预训练阶段学习到了代码相关知识，通过微调或强化学习，可以激发模型的潜力，或让模型跟随特定偏好，输出更好结果。如果预训练阶段没有过多的对应任务领域的语料，通过继续预训练的方式可以让模型适配这一领域，然后进行后面的微调和强化学习，可以取得更好的结果。

除了以上方式，另外一种简单粗暴的方式是提升模型规模，规模越大，能力上限越高。

InfoQ：除此之外，⼤模型在单测⽣成中还有那些局限性？是否会遇到数据质量问题？是否需要考虑隐私和安全问题？有哪些措施可以确保数据安全？

张树波：大模型在单测生成瓶颈在能给大模型提供多少背景信息，如果是一个简单的函数，没有涉及任何其他自定义的类，大模型未来可以完美解决，但是涉及其他的类的，甚至是多层的，外层信息稀疏性，会提高输入的上下文输入长度，在实际落地中会在输入长度和生成效果之间做一个取舍。微调数据质量非常重要，决定模型是否可用的关键因素。关于数据安全问题，火山方舟提出了全方位的大模型安全架构，为模型训练方和使用者提供安全可信环境。

InfoQ：在⼤模型助⼒智能单测⽣成的过程中，字节团队内还积累了哪些经验和教训？对于希望在项⽬中应⽤⼤模型进⾏智能单测⽣成的团队，您会给他们提供哪些建议？

张树波：不仅是在大模型助力智能单测生成这个方向，所有大模型 X 某某类似的应用落地都是一项系统工程。在大模型落地过程中，其他兄弟团队给予了大量的经验和技术支持。

InfoQ：您认为在⼤模型助⼒智能单测⽣成⽅⾯，还有哪些需要进⼀步研究和探索的领域/挑战？⼤模型在智能单测⽣成领域的未来发展趋势是什么样的？

张树波：目前，我们对于 LLM 的应用仍比较初级，所以首先是最基础的研究，如何正确激发大模型在单测任务上的潜力，让大模型发挥全部的效果。目前我们探索的手段包括但不限于任务微调、prompt engineering、RL，然后是下一个阶段，如何让模型不断地增强在特定场景中的效果。另外，大模型的能力和发展让原本一些无法通过自动化解决的问题有了新的可能性，比如经典的 oracle problem，不仅仅是困扰单测生成，GUI 的测试、program repair 的落地都受限于这个经典问题。如果大模型能够解决 oracle problem，刚才提到的多种软工技术，会迎来又一个落地的春天，而我们对于这个趋势充满信心。

“大模型将对研发模式产生颠覆性改变”

InfoQ：⼤模型在软件研发⼯作流中最⼤的价值是什么？⼤模型对软件研发⼯作流的改变，将会如何影响软件开发⾏业的未来发展趋势？

张树波：毫无疑问，大模型将对研发的模式产生颠覆性的改变，但这个改变并不会在一夜之间就发生，会是一个持续渐进的过程，三年五年甚至十年。随着大模型的不断发展和进化，对于研发工作流的影响程度会逐渐加深加强。副驾驶 Copilot 是一种比较可能的切入和演进方式，一开始会在一些比较合适的小场景，Copilot 以半自动化的方式对特定任务进行赋能和提效（比如单测的生成），然后随着模型对代码的理解能力和推理能力增强，推理结果置信度提升，模型在任务中的重要程度逐步增加，在一些任务上达到和人类同等重要的参与程度。

同时，能力可以泛化推广到其他相似或者相关的任务，比如 defect detection、fault localization、program repair 等等，成为开发者的“强化外骨骼”或者最佳搭档。甚至有可能在不远的将来，实现通过 prompt 研发和调试软件，就像《西部世界》中的场景一样。

InfoQ：⽬前市⾯上存在很多结合⼤模型的研发效能⼯具，但在⼀些企业的端到端落地过程中并不理想，也没有实现提效的突破，这背后可能存在哪些问题？不同规模的企业如何通过⼤模型实现最优的研发效率和质量？

张树波：大模型适合做推理任务，这是之前单体小模型不具备的能力。在这个基础上，可以反观大模型是否在做这类事情。另外当前市面上的开源大模型或者大模型 API 都是通用大模型接口，如果直接在某个领域应用可能存在领域的 gap。大模型本身也存在问题，例如大模型生成内容是有偏的，而且存在模型幻觉、推理错误等问题。同时研发效能工具的需要结合具体业务落地，我们智能服务团队，在抖音、直播、剪映做了很多开创性的研发效能实践，欢迎大家与我们合作。

大模型应用可以分为几个层次，API 调用、模型微调、模型继续预训练、模型预训练，成本依次呈几何级数递增，不同规模企业可以简单衡量下投入产出比，来确定在哪个层面应用大模型。

InfoQ：⼤模型会对程序员带来哪些冲击？程序员和⼤模型如何更好地共⽣，实现 1+1＞2 的效果？

张树波：我不认为大模型会减少对程序员的需求量，因为现在大模型还不能替代程序员，也不能为最终结果负责。在我们智能服务团队的实际业务中，我们把程序员当成客户，模型生成的单测为程序员服务，自动化单测检测出来的问题需程序员解决，大模型和程序本身是共生的关系。

大模型生成代码能力增强的同时，需要程序员提升自己的专业能力，能快速判断大模型生成的代码是否正确以及生成质量的高低。程序员能力越强，使用大模型生成代码的质量也会越高，因为通过使用不同的 prompt，可以生成不同质量的代码。程序员应该拥抱大模型，它可以提高代码编写效率，对于一些常识性的问题，它也能做到有问必答，省去网上搜索的时间。

嘉宾简介

张树波，字节跳动算法专家，清华大学硕士毕业，先后就职于 vivo、字节跳动。从事 NLP 算法多年，在智能单测、智能客服、语音助手等业务场景有丰富的落地经验。将在 QCon 北京 2023 分享题为《大模型助力智能单测生成》的演讲。