大模型颠覆研发模式字节跳动如何在单元测试中实现大模型
【keywords start】智能化测评【keywords end】 大模型的出现引发了一场软件工程革命，从根本上改变了软件开发的流程和方法。 目前，越来越多的企业开始在实际研发工作中结合大模型，提升软件开发的设计、需求、测试、发布、运维能力，提高质量和效率。
字节跳动算法专家张树波在接受 InfoQ 采访时表示，大语言模型是人工智能基础技术的突破，必然会带来多个行业的变革。 2023年初，字节跳动智能服务团队开始启动大型Model X智能单测项目。 目前，大模型生成单元测试已在实际业务中落地。
单元测试是保证项目可靠性的重要手段。 传统的智能单测试生成依赖静态分析、动态分析等工具，需要重新适配不同的语言。 随着模型参数规模的增大，模型的代码理解和代码生成能力也得到了大幅提升。 使用模型端到端生成单元测试可以以较低的成本覆盖多种编程语言的单元测试。 然而，大型模型仍然存在模型错觉（随机生成的变量名和方法名不存在）以及单个测试生成任务中测试分支覆盖不完整的问题。
为了解决上述问题，字节跳动智能服务团队发现，通过任务微调、强化学习等技术，可以提高语言模型单元测试生成的语法准确性和分支覆盖率。 经过测试，他们的Bloom7亿参数模型的生成效果并不弱于普通版ChatGPT，并且在低端显卡上的推理延迟仅为ChatGPT的25%。 目前，实际项目中大型模型单元测试生成的分支覆盖率达到56%。 同时在抖音的Android和iOS上均已实现。 问题有效率达到80%，修复率65%。
在今年9月3-5日举行的QCon全球软件开发大会·北京上，张树博将与大家分享上述经验。 张树波毕业于清华大学，获硕士学位。 曾就职于vivo、字节跳动。 从事NLP算法多年，在智能单元测试、智能客服、语音助手等业务场景有丰富的经验。
会前，InfoQ 对张树波进行了独家专访，探讨字节跳动如何在单元测试中实现大模型，以及大模型如何改变软件开发工作流程。 以下是经过编辑的谈话记录。
InfoQ：您在今年9月北京举行的QCon全球软件开发大会上的演讲主题是“大模型辅助智能单测试生成”。 你为什么选择这个主题？
张树波：OpenAI在2022年底发布了ChatGPT，效果非常震撼。 曾经困扰NLPer的自然语言处理问题，如歧义、长程依赖、知识匮乏、推理能力不足等，都得到了很大程度的缓解和解决。 大语言模型是人工智能基础技术的突破，必然带来多个行业的变革。 2023年初，我们字节跳动智能服务团队启动了大型Model X智能单元测试项目。 目前，大模型生成单元测试已在实际业务中落地。 我们总结了一些经验，希望对观众有所帮助。
InfoQ：对于这波大型模型与软件开发应用相结合的浪潮，您观察到了哪些有趣的趋势？
张树波：大模型会让开发更容易。 大模型代码生成会减少开发人员编写重复代码的需要，但并不意味着开发门槛会降低。 开发者需要能够识别模型生成是否正确，并对最终的上线负责。 目前的大型模型生成的代码并不能保证绝对正确，甚至可能存在一些隐藏的错误，新手开发者不容易发现。 从这个角度来看，大型模型对经验丰富的开发人员更有帮助。
大型模型如何改变传统的单一测试生成？
InfoQ：在大型模型出现之前，传统的智能单元测试生成方法是什么样的？ 存在哪些痛点？
张树波：传统单元测试生成中应用最广泛、最成功的是基于搜索的单元测试生成，在很多场景中都会提到（基于搜索的软件测试——SBST），它集成了很多程序分析技术，包括各种静态分析、动态分析、遗传算法甚至约束求解。 但由于语言的特点不同，相同的分析技术需要针对不同的语言重新实现。 尽管测试生成的原理在不同语言中是通用的，但它强烈依赖于软件分析技术。 因此，每次增加一种新的语言，都需要适配一套完整的分析技术，成本高昂。 另外，准确的分析可能依赖于编译产品，例如动态分析，因此需要先编译目标工程才能进行测试生成，这增加了生成的准备要求。
基于模型的生成可以直接分析源代码，无需编译，降低了生成要求，大大扩展了场景的适应性。 近年来，应用存储库挖掘来提高测试生成甚至程序修复效果的工作逐渐增多，这表明自然语言处理中的一些假设在软工程领域也成立。 例如，现有存储库包含测试生成甚至程序修复。 知识方面，大家也做出了相应的尝试。 学习历史知识并将其应用到新任务中也是软工程领域大家认可的理念。
InfoQ：应用大模型后，智能单测试生成方法发生了哪些变化？ 实际效果如何？ 能否完全取代传统的智能单试生成方式？
张树波：这里是一个商业应用背景。 智能单元测试一般在开发人员的代码编写过程（IDE）和代码提交后（CI）发挥作用。 前者要求可读性和正确性，而后者则要求正确性、覆盖率指标。 应用大模型后，智能单测从传统的模板生成+遗传算法演变为端到端的模型生成。 传统单一测试的准确率和覆盖率指标仍然高于大型模型生成的结果。 在CI过程中，它们仍然占据主导地位，大型模型为补充。 在IDE中，大模型生成的单个测试更具可读性，更易于开发人员修改。 因此，IDE中的单次测试倾向于使用大模型生成的结果。
我们的智能服务团队主要基于Bloom、starcoder等开源模型进行测试和微调。 经测试，基于Bloom的70亿参数模型的生成效果并不弱于普通版ChatGPT，并且可以在低端显卡（A30）上使用，ChatGPT上的推理延迟仅为普通版ChatGPT的25% ChatGPT 的。 目前，我们的大型模型单元测试生成的分支覆盖率在实际项目中达到了56%。 同时在抖音的Android和iOS上均实现。 问题有效率达到80%，修复率65%。 同时，我们也在火山方舟上尝试大模型的单次测试生成能力，效果正在评估中。
总体而言，大型模型仍然存在一定的局限性。 有一个发展的过程。 每个都有自己的优点和缺点。 可以1+1>2集成应用，不同场景可以有不同的应用方式。
InfoQ：大模型在智能单元测试生成中的应用原理是什么？
张树波：大模型单测试生成属于代码生成和文本生成的范畴，旨在通过大模型完成端到端的单测试代码生成。 大模型单测试生成的输入是待测试的方法和上下文，输出是单元测试函数。 随着模型规模的增加，模型的代码理解和单测试生成能力也显着提高。
目前智能服务团队使用的大型模型库主要是开源模型，如Bloom、Starcoder等。 基于上述大型模型，我们使用单个测试训练数据对裸模型和微调后的模型进行了评估。 目前，我们选择了基于 Bloom7B 的微调模型来实现。 同时，我们团队正计划用Java、Swift、Go等多种编程语言实现大型模型，并广泛收集公共数据集和业务数据集进行微调。
如何提高大型模型单次测试生成的准确性？
InfoQ：您提到大型模型在单个测试生成任务中仍然存在模型错觉和测试分支覆盖不完整的问题。 针对这两个问题，Byte 有什么解决方案呢？ 如何提高大型模型单次测试生成的准确性？
张树波：目前我们利用单测试生成任务数据对大模型进行微调，使大模型能够专注于单测试生成。 实验表明，通过构建高质量的训练数据，可以显着提高大型模型的单测试分支覆盖指数。 在微调大模型的基础上，引入以编译器和静态分析结果作为奖励的强化学习，可以进一步缓解模型假象的问题。
微调和强化学习的基本假设是模型在预训练阶段已经学习了代码相关知识。 通过微调或强化学习，可以激发模型的潜力，或者模型可以遵循特定的偏好并输出更好的结果。 如果预训练阶段该任务领域对应的语料不是太多，可以通过继续预训练使模型适应该领域，然后进行后续的微调和强化学习，以达到更好的效果。
除了上述方法之外，还有一个简单粗暴的方法就是增加模型的规模。 规模越大，能力上限越高。
InfoQ：此外，大型模型在单次测试生成方面有哪些限制？ 您会遇到数据质量问题吗？ 是否需要考虑隐私和安全问题？ 有哪些措施来保证数据安全？
张树波：大模型单次测试生成的瓶颈在于能为大模型提供多少背景信息。 如果是一个简单的函数，不涉及任何其他自定义类，那么以后的大模型就可以完美解决，但是如果涉及到其他类，即使是多层的，外层信息的稀疏性也会增加输入上下文输入长度。 在实际实现中，会在输入长度和生成效果之间进行权衡。 微调数据质量非常重要，是决定模型是否可用的关键因素。 针对数据安全问题，火山方舟提出了完善的大模型安全架构，为模型训练者和用户提供安全可信的环境。
InfoQ：在大模型辅助智能单元测试生成的过程中，Byte团队内部还积累了哪些其他经验和教训？ 对于想要在项目中使用大型模型进行智能单元测试生成的团队，您有什么建议？
张树波：不仅是大模型辅助智能单测试生成这个方向，大模型X所有类似应用的落地都是一个系统工程。 在大模型的实施过程中，其他兄弟团队提供了很多经验和技术支持。
InfoQ：您认为在大型模型辅助智能单测试生成方面还有其他领域/挑战需要进一步研究和探索吗？ 智能单测生成领域大模型未来发展趋势如何？
张树波：目前我们对LLM的应用还比较初级，所以第一步是最基本的研究如何在单次测试任务中正确激发大模型的潜力，让大模型充分发挥作用。 我们目前正在探索的方法包括但不限于任务微调、提示工程、强化学习，然后下一阶段，如何不断增强模型在特定场景下的效果。 此外，大型模型的能力和发展为一些无法通过自动化解决的问题带来了新的可能性。 例如，经典的Oracle问题不仅困扰单个测试的生成，而且限制了GUI测试和程序修复的实施。 这个经典问题。 如果大模型能够解决Oracle问题，刚才提到的各种软工程技术将会迎来又一个落地的春天，我们对这个趋势充满信心。
“大模型将会给研发模式带来颠覆性的改变”
InfoQ：大型模型在软件开发工作流程中的最大价值是什么？ 大模型对软件开发工作流程的改变将如何影响软件开发行业未来的发展趋势？
张树波：毫无疑问，大模型会给研发模式带来颠覆性的改变，但这种改变不会一蹴而就。 这将是一个持续、渐进的过程，需要三年、五年甚至十年。 随着大型模型的不断发展和演变，其对研发工作流程的影响将逐渐加深和加强。 副驾驶Copilot是一种比较有可能的进入和进化方式。 最初，Copilot 会在一些合适的小场景中以半自动的方式赋能和改进特定任务（例如单个测试生成），然后不断随着模型对代码的理解和推理能力增强，以及对代码的信心增强。推理结果得到改善，模型在任务中的重要性逐渐增加，在某些任务中达到了与人类相同的参与水平。
同时，该能力可以推广到其他类似或相关的任务，例如缺陷检测、故障定位、程序修复等，成为开发人员的“增强型外骨骼”或最佳伙伴。 甚至在不久的将来或许可以通过提示来开发和调试软件，就像《西部世界》中的场景一样。
InfoQ：目前市场上有很多结合大型模型的研发效率工具。 但部分企业端到端的实施过程并不理想，效率上并未取得突破。 这背后可能存在哪些问题？ 不同规模的企业如何通过大模型达到最优的研发效率和质量？
张树波：大模型适合推理任务，这是以前单个小模型不具备的能力。 在此基础上，我们可以回顾一下大模型是否在做这种事情。 另外，目前市面上的开源大模型或者大模型API都是通用的大模型接口。 如果直接应用到某个领域，可能会出现领域空白。 大模型本身也存在问题。 例如，大模型生成的内容存在偏差，存在模型错觉、推理错误等问题。 同时，性能工具的开发需要与具体的业务实现相结合。 我们的智能服务团队在抖音、直播、剪辑等方面做了很多突破性的研发表现实践。 我们欢迎大家与我们合作。
大模型应用可以分为几个层次，包括API调用、模型微调、模型持续预训练、模型预训练。 成本依次呈指数级增长。 不同规模的企业可以简单地衡量投入产出比来确定处于哪个水平。 应用大型模型。
InfoQ：大型模型会对程序员产生什么影响？ 程序员和大模型如何更好地共存，达到1+1>2的效果？
张树波：我不认为大模型会减少对程序员的需求，因为现在大模型无法取代程序员，也无法对最终结果负责。 在我们智能服务团队的实际业务中，我们把程序员当作客户。 模型生成的单元测试为程序员服务。 自动化单元测试发现的问题需要程序员解决。 大模型和程序本身是共生关系。
在大模型生成代码能力增强的同时，程序员需要提升自己的专业能力，能够快速判断大模型生成的代码是否正确以及生成的质量。 程序员的能力越强，使用大模型生成的代码质量就越高，因为通过使用不同的提示，可以生成不同质量的代码。 程序员应该拥抱大模型，这样可以提高代码编写效率。 他们还可以提供一些常识性问题的答案，节省在线搜索的时间。
嘉宾介绍
张树波是字节跳动算法专家。 清华大学硕士，曾就职于vivo、字节跳动。 从事NLP算法多年，在智能单测、智能客服、语音助手等业务场景有丰富的实现经验。 将在 QCon 北京 2023 上分享题为“大型模型帮助智能单测试生成”的演讲。
