GPT-4带来新变革，aiXcoder赋能大型语言模型时代下的代码生成
3月24日，GTIC 2023中国AIGC创新峰会在北京成功举办。本届峰会以“AI新纪元 创造新世界”为主题，包括AIGC高峰论坛主论坛，大模型、中国类ChatGPT、AIGC应用创新三大专题论坛，是国内首场聚焦生成式AI（AIGC）的高规格创新峰会。大会汇集产学研众多专家，探讨大模型与生成式AI的前沿创新、商业前景、算力进化、创业机会与投资策略。
在AIGC应用创新专题论坛上，aiXcoder CTO 郝逸洋带来了主题为《大型语言模型（LLM）时代下的代码生成》的主题演讲。探讨了AIGC与代码生成的碰撞融合，GPT-4带来的代码生成新变革，未来将促进模型扩展到千亿级。
aiXcoder CTO 郝逸洋
随着人工智能技术的飞速发展，大型AI模型在代码生成的应用中逐渐成为唯一的技术手段，大模型加持下的代码生成，相比于使用小模型或传统方法来说，可以进一步提高代码质量，生成结构良好、高效且错误较少的高质量代码，有助于开发人员节省时间，并降低软件开发成本。
作为2018年就切入AI智能编程机器人赛道的创企，aiXcoder于2022年6月推出了国内首个代码生成预训练模型产品aiXcoder XL。该产品支持由完整功能自然语言输入到完整编程语言的输出。未来，aiXcoder将促进模型从百亿级扩展到千亿级，加入大量自然语言处理+代码的混合数据，针对编程中的各类场景专门构造指令数据集，从而得到综合性能更好的代码智能编程应用。
以下内容根据演讲实录整理：
一、GPT-4带来代码生成新变革
代码生成是指用AI 的方式去产生和补全代码，帮助程序员完成一部分的代码编写工作。在ChatGPT、GPT-4出来之前，我们用的办法很简单，就是将代码放到大型的自然语言模型里面去训练，用这个语言模型去生成代码。
GPT-3是一个1750亿的模型，它在自然语言数据、代码数据、自然语言代码混合数据上进行训练。OpenAI在GPT-3这样一个语言模型的基础上，用指令微调和RLHF去训练了一个ChatGPT，让它学到了对话的能力。OpenAI并没有公布GPT-4的训练细节，但从结果看，GPT-4支持更长序列、更多指令号微调、多模态（图片输入）等操作，展现出更适于泛用的效果。
01 GPT-4与代码生成
这是一个典型的代码生成样例，我们给出一段用自然语言描述的需求，再给它一个没有完成的代码片段，让GPT-4去完成这段代码，它完成的非常好。它不仅给出了代码结果，还给出了一段解释。
02 GPT-4与代码错误检测与修复
输入一段有问题的代码，然后问GPT-4这段代码的问题是什么？它回答了这段代码实际的问题是什么，这段代码应该改成什么样子，还解释了一下修改之后的版本为什么是可以正常运作的。这是用户最后真正想要的一个结果。
03 GPT-4与代码优化
在这个实验中，输入一段有缺陷的代码，循环100万次，往一个ArrayList里面去放东西。我希望它能发现这个100万次有点大，然后它应该是事先申请一遍内存，而不是不断去动态增加。结果GPT-4并没有发现这个问题，而是发现了两个其他问题。这跟用户想要的结果不一定是一致的，但它确实也对代码进行了优化，同时它也给出了综合的解释。
04 GPT-4对代码片段的理解能力
GPT-4对代码片段是有一个理解能力的，它可以告诉你这段代码究竟在做什么。
综上来说，GPT-4具有很泛用的代码功能，GitHub在前几天发布的Copilot X，本质上也是在做这样一件事情。除了刚才实验中提到的4个场景以外，Copilot X 还增加了两个场景，一是文档的搜索，二是做pull request，一个描述的生成，这两个功能都和自然语言相关。
GPT-3加入了RLHF，获得了很好的对话能力；GPT-4这些能力是在GPT-3的基础上训练出来的。
05 GPT-3到GPT-4的代码错误检测
例如，给GPT-3一段有问题的代码，并问它这段代码的问题是什么。前半部分它在描述我在做一件什么事情，后面就越说越不对劲。为什么GPT-3会有这样的行为呢？因为GPT-3就是一个往后续写的语言模型，输入一个问题，它续写的也是这个问题，并把问题更详细的描述了一遍。这些信息也有用，但并不是所期望的结果。
有一个办法可以避免出现这样的情况，比如输入一段代码，然后写上“Answer”，提示它要写答案了，让它去续写答案。这个操作叫做“prompt engineering”，针对我们的需求去专门构造一个提示，让模型可以根据提示去生成内容。这是在ChatGPT之前，我们去使用一个大型语言模型的方式。于是GPT-3也给出了答案，跟GPT-4的结果是一致的。如果我再告诉它接下来需要修复的问题是什么，它应该也可以用同样的方式给出答案。
所以我们可以看出来，GPT-4强就强在这里，它可以解决开发中遇到的各种问题。
06 GPT-4辅助开发的问题
在用GPT-4或者Copilot X去做代码辅助开发的时候，也会遇到一些实际的问题。
①很难理解真实的业务逻辑
如果我们想做一个在网页上可以运行的贪吃蛇程序，这对GPT-4是没有难度的，那真正有难度的是什么呢？写一个真正带业务逻辑的代码。比如，“我需要把用户购物车里的商品循环一下，把每一个商品的价格取出来，最后求一个和，获得一个总价，然后返回回去。”这个逻辑普通的程序员理解和实现起来没有任何问题，但如果让GPT-4去做这件事情，会发现很困难。
困难在于自然语言描述的需求很难去写，为什么呢？因为你理解“购物车”是你定义的一个实体类，这个实体类跟你的数据结构、数据库有关系；但GPT-4理解的“购物车”，它不知道是什么东西，你需要把数据结构告诉它。然后总价怎么去获取？它也不知道。你要对用户进行确权，需要用企业内部定义的一个库，去对用户的登录做调验。种种因素导致最后很难去跟它描述好这样一件事情，它生成的代码也很难直接使用。
②慢
把一个问题抛给GPT-4让它去补完一段代码的时候，你会发现它生成完这段代码可能要一分钟甚至更长，生成完之后还需要进行修改。
③信息安全
GPT-4部署在国外（美国），不受中国政府监管
④序列长度限制
默认情况下GPT-4有一个8192序列长度限制，对整个项目来说会不够。整个项目很大、相关文件很多、依赖库也很多，需求文档开发者知道，但GPT-4不知道。
综上，我们可以看到，GPT-4带来了代码生成的新变革，支持更长序列、更多指令号微调、多模态（图片输入）等操作，展现出更适于泛用的效果。同时也面临不少问题，包括缺乏相关文件、依赖库及需求文档，以及速度较慢、信息安全威胁等。
二、代码生成模型与语言模型的区别
01 模型的信息流不同
相较于语言模型，一个代码项目里的信息会大很多，除了输入和输出，代码生成模型的信息流向还包括同项目文件、依赖库、项目配置、数据库结构等整个综合的内容，这和语言模型是有区别的。
02 交互方式不同
普通的对话语言模型以问答、续写为主，代码生成模型则需要完成填空、补全、备份。代码生成模型会在当前光标所在的位置进行补全，并对IDE下拉框里生成的代码提示做一个排序。还可以通过读取上下文，去补全中间的代码，确保生成的代码和后面的功能是不重复、不冲突的。
03 训练任务的设计方式不同
这里举一个具体的例子：插入任务，给出前文、后文，让模型补出中间的内容。预训练模型最常用的一个办法是先确定一个长度，比如1024的长度，在这个长度上随机挖出一个空，这个空叫做SPAN，让模型去生成SPAN里的内容。这是常用的一种训练方式，但在代码生成模型中的训练效果并不好。
原因在于设置的这个SPAN，无论怎样生成，它都不会超过当前1024的长度。在实际中使用这样一个模型时就会发现，无论前后文是什么，它都会努力的用最短的代码去把前后文连接起来，因为训练的时候模型就没有见过很长SPAN的情况。
针对这种情况我们做了一个改进，随机在文件中设定一个1024长度的区间，SPAN可以超出当前的范围。但这样的设置，如果超出了后面，那后文的信息就没有了；超出了前文，那前文的信息也没有了。在实际的使用中，我们并不知道这个SPAN到底有多长，并且输入一定包含上文和下文，然后模型生成的SPAN长度永远不会超过1024，这也是个问题。
于是我们最后设计了一套方案：强制保留上下文，也不限制SPAN的长度。但这个模型也是有问题的，比如左边这张图，我们给局部的成员设置了一个值，但这个值是不存在的，我们期望模型能够定义这个不存在的值，并且补充出来。但实际上模型直接结束了当前函数，然后新建了一个函数，把代码给补上了。
这个操作比较讨厌的地方在于，你甚至没有办法通过多次采样的方式去获得左边你想要的结果。因为出现右边结果的概率非常高，而且看起来也非常的对，生成的也很长。这样的问题只能通过改变训练任务去解决，在设计训练任务的时候就要考虑到这种情况。
在训练GPT-3、GPT-3.5或者GPT-4的时候，OpenAI并没有考虑这些问题。如果把它当作一个背后自动触发的模型，让它去替代现在的Copilot，就会遇到这样的问题。
04 代码纠错的实时性
aiXcoder目前用一个几十万参数的模型就可以进行实时的代码纠错和修复。GPT-4从能力上说是可以的，但是从实际效果来说还不行。第一它慢，无法实时进行处理；第二它很少见到拼写错误和拼写错误修改的相关数据。GPT-4有一定泛化能力，但由于训练时是用网上抓取的页面和文件数据去训练，尤其是代码数据，提交上去的时候基本上是没有拼写错误的，所以训练的时候它也很难理解这个拼写错误应该怎么去修改。这可以通过人工反馈的强化学习的方式去训练它，但训练效果可能还不如用一个几十万参数模型去做这件事情。
综合来看，GPT-4在代码生成上还存在一些局限性：
1、GPT-4在某些需要实时反馈的代码纠错和代码补全场景中并不适用，只能写完代码后做一个整体性的分析
2、上下文序列有限，难以顾全中大型项目的全部上下文
在中大型项目中，一个30000多的序列长度是很致命的，这让模型无法看见项目里的所有信息。
3、代码项目的完整信息和网页爬取的文本差距大
整个项目的信息，包含项目配置、项目中各种文件放在一起的这样一个数据分布，和我们从网页上直接爬取的单个文本/文件的差异是很大的。OpenAI可以用RLHF的方式去把这些信息加进去，让它学到这些信息；但和我们直接去构造这样的数据相比，表现还是会差一些。
aiXcoder现在还是用一个130亿参数的类似语言模型的方式去做代码生成的一套工具，并免费提供给开发者使用。
下一步我们也是要汲取GPT-4在代码生成上的能力，增大模型的大小，逐步从百亿级增大到千亿级；加入更多的自然语言处理+代码的混合数据，针对编程中的各类场景专门构造指令数据集；解决代码中长序列依赖的问题，让它可以看见整个项目，包括项目外的文档的信息；为开发者打造出综合性能更好的智能编程应用。
关于GTIC 2023中国AIGC创新峰会
由智东西主办，智东西是智能产业第一媒体，专注报道人工智能主导的前沿技术发展，和技术应用带来的产业升级。聚焦智能变革，服务产业升级。
了解更多：