梅宏：大语言模型能否带来软件自动化的新机遇

摘要：基于现有的大语言模型技术途径，利用当前人们积累的软件工程数据，能否实现人们心目中的软件自动化？这是软件工程界和机器学习界共同关心的问题。本文对“基于大语言模型的代码生成的研究现状和存在问题”，特别是“程序语言和自然语言固有差异导致的问题”，以及“现有代码数据的

基于现有的大语言模型技术途径，利用当前人们积累的软件工程数据，能否实现人们心目中的软件自动化？这是软件工程界和机器学习界共同关心的问题。本文对“基于大语言模型的代码生成的研究现状和存在问题”，特别是“程序语言和自然语言固有差异导致的问题”，以及“现有代码数据的质量、覆盖度问题”进行探讨，分享了个人认识和思考。

人类是否有机会实现软件自动化？十年前，在大数据热潮的顶峰，我曾问过类似的问题。2014年10月，在日本国立情报学研究所主办的湘南会议(NII Shonan Meeting)1上，我作为共同主席组织了一个主题为“Computational Intelligence for Software Engineering”的研讨会(Seminar No.53)。会上我作了一个题为“Can Big Data Bring Us New Opportunities for Software Automation？”的报告，讨论的主题是我长期从事的研究领域“软件工程”的追求目标，即“高效率地开发出高质量的软件”，而这个目标的终极形态便是“软件自动化”。

软件自动化（根据需求规约自动生成程序）一直是计算机科学家们的梦想，今天仍然如此。我国软件界的先驱、南京大学徐家福先生曾给出“软件自动化”的定义：“软件自动化的广义理解指的是，尽可能借助计算机系统，实现软件开发。”其中，“软件开发指的是，从问题的非形式描述，经形式的软件功能规格说明、设计规格说明，到可执行的程序代码、调试，及至确认、交付使用的全过程。”同时，徐先生也给出了“软件自动化”的狭义理解，指的是“从形式的软件功能规格说明到可执行的程序代码这一过程的自动化”。

历史上，曾有很多研究人员为软件自动化这一目标付出努力，也取得了一些令人兴奋的成果，例如，编译器和词法分析器生成、声明式语言、程序综合、领域特定的编程、模型驱动的体系结构，等等。这些研究几乎都是采用基于“规则”的技术路径，虽然也取得了许多重要的学术成果，但仍未寻找到普遍适用于软件开发的自动化方法。这些工作所能合成的程序的规模依然较小，通常只能在有限的场景下（或狭窄的领域）实现程序的自动合成，而要合成真正实用的大型程序，仍极具挑战性。

大数据热潮的兴起，源于人们意识到，大数据为我们认识复杂系统带来了一种新思维和新手段。当时，无论是从科学研究还是商业应用视角，大数据应用在众多行业领域均已取得令人瞩目的成效。鉴于软件产业几十年的快速发展，特别是开源软件的蓬勃发展，我们已经积累了海量的软件工程大数据（包括代码、文档、注释、配置信息、错误报告等），一个自然的问题是：“可否发展出一种数据驱动的方法，自动地合成满足实际需求的大型程序”？

我在湘南会议报告的目的是提出这个问题供与会者讨论，也为解决这个问题探讨一下可能的路径。我在报告中针对该问题设计了两个场景：“单个功能代码的添加”和“多个功能代码的组合”。进而，考虑从前一个场景起步，针对若干特定领域，构建包含足够相似项目的多个版本的代码和需求文档的库，并基于该库将符合某个功能描述的代码自动添加到同领域的被开发系统中。

应该说，我在报告中并未明确回答我自己提出的问题，只是隐含了我的一个基本判断：基于软件工程大数据，不可能实现软件自动化的愿望，但有可能极大提升软件开发的效率和质量，也即是说，提供软件开发的“银弹2”。ACM图灵奖获得者、《人月神话》的作者弗雷德里克·布鲁克斯(Frederick Brooks)是在软件工程领域引入“银弹”概念的第一人。1987年，布鲁克斯曾预言：由于软件本质上的复杂性，未来十年内，不存在一种技术或方法能够使软件生产力得到10倍的提升；1995年，布鲁克斯在其著作《人月神话》新版中再次预言：“软件开发没有银弹的预言在下一个十年中仍然成立。”在软件工程发展历史上，曾有不少人希望发展出能作为“银弹”的软件开发方法和技术，如计算机辅助软件工程(ComputerAIded Software Engineering, CASE)环境、面向对象(Object Oriented, OO)方法等均曾被寄予厚望，然而它们最终都没能成为真正的“银弹”。也许，“软件工程大数据驱动的方法”有可能成为“银弹”！这是当时我在报告中隐含的判断，更是一个期望。

“软件”一词自1960年前后出现以来，逐步成为计算机学科的一个主要研究分支。1968年“软件工程”一词诞生，软件在各行各业日益得到广泛的应用。在一定意义上，软件人已经利用“软件”帮助众多行业领域实现了行业业务的“自动化”，但是，“软件”自身的开发却一直采用手工方式，软件工程领域始终面临着“鞋匠的孩子没鞋穿”的窘境。实际上，这也是20世纪80年代CASE环境出现的动因之一。迄今，软件人还在为实现自动编程或软件自动化而持续奋斗中！

时至今日，站在当下的视角，我对湘南会议的报告也有一些反思：总体上，当时的判断趋于保守，低估了“大数据”叠加“深度学习”的威力。同时，鉴于当时大数据和人工智能技术所处的发展状态，跨界思维不够，主要是从软件工程的视角看待问题，特别是所设想的场景和起点高度依赖于“库”的工程可行性。

在历史上，围绕软件自动化这一主题，北京大学曾开展了一系列研究工作，包括杨芙清院士领导的“青鸟工程”，我领衔的国家973计划项目开展的“网构软件”(Internetware)3研究，以及我提出的“基于体系结构、面向构件的软件开发方法ABC”等，其目标都是希望通过自动化手段提升软件开发的效率和质量。自2014年开始，北京大学软件工程研究所李戈团队开始进入基于深度学习的程序处理领域，发布/发表了该领域最早的一批学术论文，在基于深度学习的程序理解、生成，以及面向程序处理的预训练模型等领域，做出了多项原创性贡献。2017年起，该团队持续研发了一个基于深度学习的编码辅助系统aiXcoder，以生成或补全程序代码的方式辅助程序员完成编程任务。当前，该系统逐步演化为基于大语言模型的编程辅助工具。

随着人们关于大语言模型研究的进展和应用的探索，“基于大语言模型的代码生成”成为人们关心的话题，我也一直关心相关研究和应用的进展。恰逢今年的中国计算机大会(CNCC2024)在浙江横店举行，CNCC程序委员会主席胡振江教授邀请我作个大会报告，更为机缘巧合的是，胡振江也是NII湘南会议的发起人，于是，我决定重用十年前的题目，只是将“大数据”换成了“大语言模型”。实际上，这也是一个自然的延伸，因为“大语言模型=大语料数据+深度学习”。报告中，我重点对“基于大语言模型的代码生成的研究现状和存在的问题”，特别是“程序语言和自然语言固有差异导致的问题”，以及“现有代码数据的质量问题、覆盖度问题”等话题进行探讨，并分享若干个人的认识和思考。

基于大语言模型的代码生成：研究现状

大模型应用远未达到应用繁荣期

今年9月，我在《中国计算机学会通讯》(CCCF)上发表了一篇文章《对当前人工智能热潮的几点冷思考》，其中对当前大模型的发展现状给出了一个判断：大模型应用雷声隆隆，但雨点并不大，远未达到应用繁荣期。

当前，由于技术发展状态和应用环境的限制，大语言模型的应用领域严重受限，当然，也有代码生成、图像/视频生成等少数领域被认为“具有商用潜力”，甚至成为很多模型厂商看好的应用落地的优先选项。但是，图像/视频生成的应用仍限于交互增强、文生图像/视频等方面，并且在技术原理上遇到了“如何符合物理规律”的挑战；基于大语言模型的代码生成，则面临着“如何进行本地部署”等一系列挑战。

机器学习界和软件工程界视角不同

针对“代码生成”，机器学习界和软件工程界在发展状态、关注重点等方面的认知，存在较大差异。机器学习界对代码生成的发展状态往往偏于乐观，认为代码生成已经取得了良好的效果；在相关研究和应用上，也往往将程序视同于文本，将代码和自然语言文本“一视同仁”地进行token化处理。而软件工程界对其发展状态的认知则更偏于保守，认为代码生成技术的当前状态与大型软件开发的实际需求仍存在较大差距，研究者们也往往把基于大语言模型的代码生成视为软件开发的辅助工具（AI for SE），而把大语言模型及其相应软件的工程化方法的研究（SE for AI）视为新的研究任务。

机器学习界当前的研究工作往往局限于“独立小程序”的生成，这一点从其研究工作所依赖的数据集的特征即可看出。机器学习界所使用的数据集通常具有以下特征：程序代码规模较小、代码依赖关系相对简单、编程需求的描述相对简单、对背景知识依赖较少、生成的代码缺乏或仅存在简单的上下文依赖、测试数据的规模较小、对生成结果的评估多借用自然语言处理领域的技术指标。

软件工程界的研究工作，则更多结合具体软件工程任务展开。相关研究工作通常有以下特征：数据采集自实际软件工程项目、代码规模相对较大、注重代码间的依赖关系、结合具体的软件开发任务（如代码补全、测试案例生成、代码注释生成等）、评估方式更多借鉴传统软件工程任务的评估方式（如测试案例通过率、代码覆盖度等）、注意观察和调研在实际软件开发项目中的应用效果。当然，需要指出的是，虽然软件工程界所关注的问题规模大于机器学习界，但与实际软件开发项目的规模相比，仍然较小，离实用仍有较大距离。

在机器学习界，一个常用的代码生成评估数据集是HumanEval，虽然研究者已经将该数据集上的Pass@1数值推升至超过90%，但如果我们仅仅给每个测试案例增加几个测试数据，其准确率就会大幅降低。而且，有些大模型为追求评估数据集上的准确率，还会进行有针对性的训练，从而造成了人们对代码生成准确率认知的偏差。而在软件工程界，研究者更倾向于利用一些来自真实开发项目的数据集进行测试，例如在北京大学推出的DevEval数据集中，GPT-4的Pass@1数值仅为53.05%，而在复旦大学推出的ClassEval数据集中，GPT-4的 Pass@1数值仅为37.6%。

关于代码生成在软件开发中应用的讨论

最近，关于基于大模型的代码生成应用，也产生了一些讨论，这些讨论一方面肯定了基于大模型的代码生成在提升软件开发效率方面的作用，另一方面也展现出开发者对相关应用的一些担忧。

2024年5月，由StackOverflow网站发起的一个关于代码生成工具应用情况的调查中，针对6万个开发者的调查显示：76%的开发者表示正在或计划采用AI工具，81%的开发者认为 AI工具提升了开发效率；同时，也展现出开发者对AI工具的一些担心：仅有2.7%的开发者对AI工具的准确性有较高信心，45%的开发者认为A工具无法解决复杂问题；此外，70%的开发者认为AI工具不会对他们的工作造成威胁，79%的开发者认为“虚假信息”是他们担心的重要问题。

2024年4月，开源操作系统Gentoo Linux理事会发出了第一个关于“AI生成代码”的禁令，其考虑的主要因素包括版权、质量、道德等方面的问题。该理事会成员提出：“鉴于最近人工智能泡沫的蔓延，……目前唯一合理的行动是完全安全地禁止AI支持的贡献。……应明确禁止开发者使用ChatGPT、GithubCopilot等创建在Gentoo中使用的代码、文档、消息、错误报告等。”最终，该理事会以6赞成票对0反对票通过了禁令。

2023年5月，纽约《华尔街日报》的科技记者伊莎贝尔·布斯克特(Isabelle Bousquette)发表了一篇采访文章，采访对象包括一些全球500强企业的CIO。其中，麻省理工学院计算机科学与人工智能实验室的教授阿尔曼多·索拉尔-莱萨马(Armando Solar-Lezama)表示：“我认为存在着机器写出大量低劣代码的风险。”EXL公司的执行副总裁维韦克·杰特利(Vivek Jetley)认为：“随着代码量的激增，需要努力控制和管理那些代码，并确定保留什么、丢弃什么……”Genpact公司的首席数字策略师桑杰·斯瑞瓦斯塔瓦(Sanjay Srivastava)表示：“不要将代码的加速交付与生产力等同起来。”该文章给出的结论是：“许多企业虽然在积极推进生成式智能编程工具的使用，但也保持着谨慎态度。”

国内软件工程界的观点

2024年1月，在CCF的支持下，软件工程界的学者们组织了第九期CCF秀湖会议，主题为“大模型下的软件工程：机遇与挑战”，相应的一些观点和结果发表在2024年第8期CCCF上。这里仅摘录其中若干观点：（1）虽然“编程终结论”目前还存在很大的争议，但大模型给软件开发带来的巨大变化正在逐渐成为事实；（2）简单和重复性的编码任务（如功能逻辑主要是数据库查询更新及常用API调用的任务）将主要通过生成式的方式完成；（3）大模型为我们打开了智能化软件工程的想象空间，但实现这一梦想还需要深入思考软件工程的根本性问题，例如需求和设计的复杂性、软件的正确性保证等；（4）大模型并不会带来编程的终结，而是会复兴软件工程领域的一些根本性的技术，如需求分析、精确的规格说明以及软件验证；（5）如何将代码大模型与企业软件开发流程相结合以进一步提高软件开发效率和质量，仍然是一个需要探索的问题。

基于大语言模型的代码生成：存在问题

应该说，当前基于大语言模型的代码生成应用已经取得了不少进展，但距离人们的期待仍存在较大差距。原因可归为两个方面：程序语言代码的建模问题和构建大模型的数据问题。

现有大语言模型是否有利于程序语言代码的处理？

站在软件工程的视角，我们可以看到，当前的大语言模型在程序语言代码的建模层面，仍然存在如下一些问题：

1.丢失了代码的强结构化特性。当前的大语言模型将代码视为文本字符串，并利用与自然语言相同的方式进行建模，忽略了代码的强结构化特性，丢失了程序语言不同成分之间的关联性和明确的约束关系。

2.丢失了代码的严格形式定义。编程语言可以利用语法产生式进行严格定义，编写代码的过程是在一个受限的形式化语法空间中描述程序语义的过程，而在现有大语言模型的建模过程中并未充分考虑程序语言的这一特性。

3.忽略了代码语义的强局部性。程序代码具有强局部性，程序语义通常被约束在局部空间中，诸多语言成分仅在受限的上下文环境中才具备特定的语义。例如，程序代码中相同的变量名，在不同的环境中可能具有不同的含义；而不同的变量名称，在不同的环境中可能具有相同的语义。程序语言代码的语义对局部环境的依赖远强于自然语言文本。

4.忽略了代码对编程环境的强依赖性。程序代码与其所依赖的软件框架、代码库等具有强依赖、强绑定的关系。虽然自然语言中涉及的概念也具有领域性，但其依赖强度远低于代码。例如，脱离领域知识的自然语言文本片段，仍具备一定的可理解性，但脱离软件框架或代码库的代码，将导致其语义无法理解。

现有代码数据是否足以支持大模型训练？

当前的大语言模型对数据存在严重的依赖。我在2024年第9期CCCF上发表的文章中提到，“大模型可被视为由已有语料压缩而成的知识库，生成结果的语义正确性高度依赖于数据的空间广度、时间深度以及分布密度，更高度依赖于数据的质量。”这同样适用于大模型对代码数据的建模。

首先，当前能够用于大模型训练的可用代码数据，无论从数量上还是质量上，都远远不足以支持建立一个可以用于实际软件开发的通用大模型。虽然互联网上的开源代码数据不断增长，但从中能够合法提取到的高质量代码数据仍然不多。例如，Github上的“公开代码库”按每年22%的速率增长，但迄今总数仍不超过300M。经互联网软件资产收录机构Software Heritage收录的代码文件数到目前为止仅有20B+，而且经过筛选、去重处理后，最终能够用于训练的代码仅占所收集原始代码数据的一小部分。根据华盛顿大学、苹果公司等23家研究机构和公司最近发布的研究论文DataComp-LM中的统计，最终用于训练的代码数据仅占原始数据的1.4%。

其次，面向不同特定行业领域的代码数据的可用性差距巨大。当前的大语言模型主要利用互联网上的公有代码数据进行训练，无法覆盖特定行业领域的私域数据。利用公开代码数据训练的模型，通常仅能支持通用领域的软件开发，然而，更多的软件开发需求来源于特定行业领域，需要支持特定的业务逻辑，利用公开代码数据训练的大语言模型无法充分支持特定行业领域的软件开发需求。

近期的研究数据也说明了大语言模型在“通用孤立小程序”与“领域工程项目”测评数据上的差异。例如，对于GPT-3.5而言，虽然其在HumanEval数据集上的BLEU(Bilingual Evaluation Understudy)值可以达到39%，但在领域相关的数据集上，该值却降低至5%，甚至更低。

这些问题的存在，影响了人们对大语言模型在代码生成领域应用的信心，也让我们意识到，大语言模型用于代码生成，其能力仍存在较大提升空间。

一些个人观点

不能重新从数据起步，忘了我们已有的知识积累

人们在长期的软件技术研究和软件开发实践中，积累了大量的编程规则和关于软件开发的知识。我们不应抛弃这些积累，更不应该完全回到从原始数据中重新学习。当前大语言模型以自然语言文本为主要建模对象，并未考虑编程语言代码的特点，丢失和忽略了程序代码中蕴含的诸多信息。我认为以这样的方式处理和生成程序代码并不合适，我们应重视软件工程领域已有知识和规则的利用，将大语言模型与已有的软件工程技术和知识结合起来，以更好地解决问题。例如，把模型生成与程序代码的语法规则、编程规则结合起来，提升生成代码的正确性和稳定性；把模型生成与程序代码分析技术结合起来，提升生成代码的可靠性；把模型生成与软件领域知识结合起来，提升生成代码的领域适用性；把模型生成与形式化方法等技术结合起来，提升生成代码的可信性。

此外，在基于模型生成解决软件开发问题的过程中，我们还应该充分利用大模型生成速度快、迭代快的优势，在新的软件开发中持续凝练并积累新的被人类开发者确认的、可规则化或可确定重现的知识成果，将其融入到已有的软件工程知识体系中。

生成代码不等于生成软件

软件工程过程是一个涉及很多工序的复杂过程，包含了需求获取/分析、系统设计、开发、测试、运维等众多复杂任务，编码只是其中一个环节。研究表明，在实际的软件开发任务中，编码工作仅占全部工作时间的10%左右。而且，在软件工程过程中，相较于其他工作，编码是一类相对简单的工作。20世纪70年代，日本就曾提出“软件工厂”的概念，其中涉及的“编程工作”被限定为“将软件设计转换为程序代码”的过程。当时，软件开发人才短缺，日本很多高中生毕业后，经过短时间的编程培训，就可以从事编程工作。编程工作在当时往往被看作一种“短工”性质的任务，是软件开发流程中的后端环节。相对于编程工作，他们更重视需求分析和系统设计等前端环节，而这些工作需要的技术和知识含量更高，需要依赖高端人才。

当前大语言模型仍难以实现理想中的软件自动化，但有望成为软件开发的“银弹”

基于当前技术路径的大语言模型，其存在的问题是显性的，其能力“天花板”亦可预期，离实现理想中的软件自动化还有很远的距离，能否成为大幅提升软件开发效率和质量的工具呢？

十年前讨论大数据时，我曾认为数据驱动的技术路径有可能成为软件开发的“银弹”。现在看来，虽然大数据的确为软件开发提供了基础资源，但如果只依靠传统的数据处理方式，效率太低，难以满足需求。而深度学习提供了一种自动化的数据处理分析手段，效率得以大幅度提升，在有足够质量保障的前提下，有可能带来软件编码效率数量级的提升。换言之，大数据与深度学习二者的结合，有望成为软件开发的“银弹”。当然，我们还需要一个前提，即软件工程方法技术与深度学习技术充分融合，以尽可能提高基于大语言模型生成代码的可信性和可解释性。

在一些特定领域，基于大语言模型有可能实现终端用户编程(End-User Programming, EUP)。终端用户编程概念的提出，最早就是针对电子表格(spreadsheets)这一类应用。该概念提出的动机，是使终端用户不需要进行复杂的专业化程序设计就可以便捷地使用计算机提高日常工作效率，典型的案例如电子表格、计算机辅助设计、统计软件工具等。这类应用往往具有任务目标明确、操作流程可枚举等特性。可视化的人机交互是实现终端用户编程的主要方式，更理想的方式则是使用自然语言。按照终端用户编程的定义，大语言模型无疑具备相应的能力，实际上，现在的视频编辑软件、基于AI的图像/视频生成，均可归类为比较成功的终端用户编程应用。

软件承载人类文明，人类必须牢牢掌控

软件开发需要工具提升效率。通过AI工具的辅助，我们在软件开发效率的提升方面已经取得了令人兴奋的进展。软件工程界需要用开放的心态拥抱这些新型工具的使用，并引导开发者用好这些工具。但另一方面，我们也必须清醒地认识到，当前技术路径的AI还不可能完成软件开发中的创造性任务。更进一步，即使未来的AI有可能完成一些“创造性”的开发工作，我们也不应该追求用AI替代软件开发者，至少，人类必须掌握软件的“审核权”。这与我在文章《对当前人工智能热潮的几点冷思考》中强调的“科学家是人类的角色，科研是人类的专属责任，人类可以利用助手和工具来辅助科研，但是不能允许这些助手和工具越俎代庖掌控科研”的想法是一脉相承的。

软件是人类文明的载体。首个商业Web浏览器网景(Netscape)的发明人马克·安德森(Marc Andreesen)曾说过：“软件正在吞噬世界。”C++语言发明人比雅尼·斯特劳斯特鲁普(Bjarne Stroustrup)也说过：“人类文明运行在软件之上。”软件界在描述未来时也常说：“未来将是一个软件定义的世界。”软件已成为人类社会经济生活不可或缺的基础设施，必须牢牢地掌控在人类手上！因此，软件开发的主动权也必须掌控在人类的手中！

尾注：

1 NII湘南会议是由日本国立情报学研究所发起的一个国际化系列学术研讨会，风格类似于Dagstuhl Seminars会议。

2 在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银弹(silver bullet)往往被描绘成具有驱魔功效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。

3 2000年，笔者和南京大学吕建教授在联合申报国家973计划项目时提出的概念。2002年，我们获批了软件技术领域第一个973计划项目。