GitHub Copilot产品经理和微软MVP告诉你：企业是否需要训练自己的代码大模型？- 微软MVP全球峰会纪行

生成式AI（GenAI）自从2022年11月被ChatGPT的发布引爆以来，已经成为了全球技术人最关心的话题。本文记录了我在生成式AI的一个细分领域：AI辅助智能编码 上的一些实践和经验。2024年3月，在时隔7年之后，我再次来到了微软位于西雅图的总部，主要目的是为了找寻一个关键问题的答案，那就是：

针对组织内部的个性化代码，
私有的框架、公用代码组件、内部编码规范、内部接口说明；
企业是否需要训练自己的代码大模型？

带这个这个问题，我分别拜访了几位重量级人物，包括：主管微软开发工具事业部的 微软全球副总裁 Julia Liuson 潘正磊，如果问谁是对这个世界上的开发者最有影响力的人，那就非潘正磊莫属了，包括：VSCode，GitHub 和 GitHub Copilot都在她的管辖范围，更重要的是她承担着为整个微软13万内部工程师的AI赋能任务。第二位是 GitHub Copilot的产品经理 Ryan J. Salva，作为AI辅助智能编码产品的天花板，GitHub Copilot不仅仅是 生成式AI 最早的生产级产品（甚至早于ChatGPT）,同时也在用户数量，产品能力和实际应用效果上超越了所有同类产品。最后一位是 Idan Gazit ，作为 GitHub Next 团队的负责人，GitHub Copilot X正是出自他的团队。我相信，这3位一定可以帮助我找到问题的答案，同时我也非常希望能够和他们一起探讨企业落地大模型应用从战略，战术，设计和前沿研究各层次上的经验。

本文的后半部分，是我根据和这几位的交流整理而成，这些内容对于企业是否需要私有化训练的大模型这个话题进行了比较深入的分析，希望能够对企业管理者和AI行业的从业者有所帮助。

微软最有价值专家全球峰会2024纪行

自从2015年创建英捷创软（leansoftx.com）后，工作繁忙也少有机会来西雅图参加微软最有价值专家MVP和Regional Director的全球峰会。过去一年间，由ChatGPT所掀起的生成式AI（GenAI）浪潮，使得 OpenAI/微软/GitHub Copilot成为了大家普遍关心的新技术话题，我的技术方向和公司的业务也转向AI驱动的软件工程（AISE）领域，能够和微软开发工具团队（DevDiv）以及GitHub Copilot产品组一起交流最新的技术趋势和经验，成为我在7年之后再次来到西雅图的动力。

图：微软MVP们在微软总部的合影

2020年6月OpenAI发布了GPT3的基座模型，在2021年6月 [1] 时隔一年后，GitHub也发布了内部预览版的 GitHub Copilot，第一代GitHub Copilot使用的是基于GPT3迁移训练（Transferred Training）出来的Codex模型。从那个时候开始，包括 Martin Woodward 在内的很多GitHub老朋友就开始活跃在我的联系人列表中。虽然彼时GitHub Copilot的能力和现在相比有很大差距，但当幽灵字体第一次出现在Visual Studio Code中时，那种兴奋还是让我记忆犹新。

如果你还没有接触过 AI辅助智能编码 类产品，可以关注一下以下截图。下图是一个集成开发环境IDE，里面所列出的代码到第10行之前是由开发者写出来的，第10行之后的灰色字体（Copilt的叫法是幽灵字体）是由 OpenAI 的GPT模型根据前面的内容自动生成的，开发者按下Tab键即可接受这些代码内容。这就是当前 AI辅助智能编码 类产品最主要的工作模式：代码补全。

使用GitHub Copilot之后，你就好像有一个编程伙伴（Pair Programmer），他会持续观察你写的代码，并通过幽灵字体的方式向你推荐他“编写”的代码。这种方式可以实现非常流畅的“人+AI”的互动方式，提高开发者的工作效率。作为使用GitHub Copilot的开发者，与其说是在使用工具，这种感觉更像是和AI进行互动。

2022年6月，在很多人对 生成式AI（GenAI）还一无所知的时候，GitHub Copilot 作为全球第一款生产级的AI智能编码产品，已经正式发布了第一个公开版。这个时间点整整领先ChatGPT问世一年半的时间，而且这个时候GitHub Copilot已经有120万付费用户。作为其中的一员，我对AI智能编码产品将会彻底改变开发者的工作方式深信不疑，并且与GitHub团队一起多次改进这个产品。可以说，GitHub Copilot是全球第一款投入生产级使用的 AI辅助智能编码 产品，在软件工程领域首先证明了生成式AI的实际使用效果。

• GitHub Copilot 是否会将我们的代码发送出去？

• GitHub Copilot 使用公开代码训练的，如何让她更懂我的内部代码，是不是需要自己训练模型？

  
  

第一个问题的答案很明显，GitHub Copilot作为一款基于OpenAI大模型提供的生成式AI产品，只能通过SaaS服务的方式提供，为了完成代码生成，必须要将足够多的代码片段发送到GitHub的服务器才能完成推理。虽然对于很多教育类，游戏类，电商类用户并不是特别大的问题，但是对于金融/银行类用户这就成为了重要障碍。

在2023年6月，英捷创软和软通动力银行事业部合作组建了AISE开发团队，在我们的用户汇丰科技的支持下，启动了AISE（AI驱动的软件工程系统）和 SmartCode (AI智能编码产品）的研发工作。2023年9月，在汇丰内部已经有超过3500名开发者使用AISE和SmartCode。AISE可以实现完整的私有化部署和多种模型（包括开源和商业模型）的并行接入，提供和 GitHub Copilot类似的AI辅助智能编码体验。在2024年初，这个项目在信通院组织的AI4SE银弹最佳项目评比中获得优秀AI应用奖项。

第二个问题基本上来自大型银行，基金，通讯，运营商等企业。这些企业一般都有超过千人的开发团队而且有大量的内部代码，包括：私有的框架、公用代码组件、内部编码规范、大量内部接口说明等。对于这些用户的困扰是，虽然GitHub Copilot已经在巨量的开源代码和公开代码上进行了训练，也可以完成绝大多数编程语言的生成，但是它并没有见过我内部的代码，无法生符合内部编码规范、风格的代码，也无法正确调用私有代码框架/组件和接口的代码。这个问题成为了影响AI辅助智能编码产品在这类大型企业落地的主要障碍。

为了能够更加准确的回答这些问题，西雅图之行我特意拜访了3位非常重要的人物，他们作为微软/GitHub内部直接推动AI辅助智能编码工具落地以及GitHub Copilot产品能力体验的负责人们，一定也遇到过同样的问题。

• Julia Liuson 潘正磊 - 微软全球EVP President Developer Division at Microsoft，主管开发工具事业部DevDiv，微软所有的开发工具团队全部都在她的主管范围，包括：GitHub, GitHub Copilot, Visual Studio, Visual Studio Code，Azure DevOps等；说她是全世界对开发者最有影响力的人一点也不为过。大家熟知的很多大牛，比如：《设计模式》的作者Eric Gamma在她麾下主管Visual Studio Code的开发，TypeScript的发明者Anders Hejlsberg也在她麾下工作。

• Ryan J. Salva - GitHub Product VP，GitHub Copilot产品总监。

• Idan Gazit - GitHub 资深研究员/Heroku, Django开源项目核心贡献者，主管GitHub下一代新产品的研发，其中就包括GitHub Copilot X。

不出所料，这些问题也同样是微软/GitHub在构建和推广Copilot过程中遇到的关键问题。他们3位也同时表达了对企业进行私有代码训练这条路径的不同看法，本文的后半部分是我根据和他们的对话整理而成，希望能够对正在阅读本文的企业管理者和开发者有所帮助。

和微软开发工具事业部总裁Julia Lison聊到大模型在微软内部的落地情况的时候，我提到一个看法，得到了Julia的认同：

大模型就好像电一样，是用来驱动工具解决各种问题的，它可以驱动电视，冰箱，电动汽车；这些不同的产品都可以解决不同场景下的问题，都是电的定制化应用。我们并不需要去修改电本身的特性，我们应该把目光放在如何创造新时代的电灯，电视和电动汽车上。

说明：C语言和很多大家熟悉的高级语言有很大区别，它非常接近底层操作系统，因此工程师如果要写出O产品这种量级的应用其实需要构建大量的可重用组件，这个过程有点像搭积木。这些组件从编程语言性质上来看和大家熟知的Java语言中的类和方法有非常大的区别。C语言的这些组件更像是创造了全新的编程语言和语法。鉴于本文的受众更多是企业的技术管理者，这里不再展开这个话题，有兴趣可以参考网上很多的分析，比如[5]。

微软内部的实验结果说明，对O产品这种非常特殊的代码库进行模型训练确实可以一定程度的提高Copilot代码准确度，但提升的准确度仅有几个百分点，且训练成本巨大。Github Copilot后台所使用的GPT 3.5 Turbo模型，单模型实例需要几十张高性能的GPU才能完成推理，一旦进行了私有训练，这个模型实例就只能用于O产品团队，不再适用于任何其他团队。训练所需要的GPU数量远高于推理的需求，这意味着为O产品提供私有化训练的模型成本极其昂贵。至于微软为什么仍然选择使用模型训练的方式，以下答案可以作为企业管理者判断是否要对大模型进行训练的一个标准，这里面包含6个基本因素，缺一不可：

1. 团队规模巨大：即便只有几个百分点的准确度提升，放大到几千人规模的开发团队上，产生的效能提升和节省的成本/资源也是非常巨大的。

2. 单一代码库：几千人规模的O产品开发团队全部都在一种开发语言和非常类似的代码库上进行工作，因为任何的模型只要进行了再次训练，就只能针对某一种开发语言提供服务，再次训练虽然会增强模型在O产品代码库上的能力，同时也会降低这个模型实例对其他编程语言的处理性能。这一点上，O产品团队符合要求。

3. 代码足够特殊：特殊到GPT 3.5 Tubro模型在训练的时候完全没有见过类似的代码。基于前面分析的，虽然是C/C++语言，但是因为语言本身的高度灵活性和这个单一产品本身的规模，其代码库中代码是GPT完全没有见过的。

4. 代码规模巨大：要通过训练对基座模型产生影响，至少需要几百万行规模的高质量单一语言代码。面对一个几十/上百亿参数量的模型，如果训练数据不够，则不足以影响模型的行为。即便采用非常高效的微调方式，也需要原有数据的1%左右规模的数据才能发挥作用。

5. 容忍训练失败：即使在类似GPT这样高质量的模型上进行再次训练并且由非常有经验的工程师来操作，如果参数控制不到位也容易出现失败的情况。加上每次训练所需要的算力和时间消耗，这是一个非常高风险的投入。

6. 足够的不可变基础代码：模型训练会让模型产生非常强的偏好，要修改这个偏好就必须要重新训练，因此用来训练的代码必须是那些在很长时间内（至少几年）中不会发生变化的代码。如果私有代码组件已经发生了改变，而模型还在一直生成老的代码，反而会对工程师的工作效率产生负面影响。O产品因为有大量自行研发的可重用的基础组件代码，也符合要求。

   
   

对于普通的企业，其实大多数是不符合以上的条件的，特别是非软件/非IT行业的软件开发团队，最典型的就是大型银行/金融机构/电商等等。我将这些行业称为 极度依赖IT的非IT行业。这些行业有几个普遍特点：

1. 开发团队规模整体大但单个业务团队规模一般：因为业务足够复杂，确实需要庞大的开发团队来支撑整个业务系统；但是内部应用系统众多，虽然整体开发团队人数众多，但某个业务开发团队的规模都不大，基本都在几十人最多百人规模。如果针对这样的代码进行训练，那么就意味着需要给每个业务团队训练一个不一样的模型。这样来看，无论从成本收益的角度，还是训练数据量可行性的角度都行不通。

2. 技术栈分散：分布式系统架构加上容器化的普及，企业中同时使用多种技术栈的状况非常普遍，最常见的Java，JavaScript，Node.js，Python，CSS/HTML基本上每家企业都在用。虽然企业的总代码量很大，但是落实到具体某个编码语言上也没多少。代码训练其实是针对不同语言单独进行的，这种情况意味着每种语言的代码语料都不会太多。如果和第1点一并考量，那么单个业务团队内的某个编码语言的语料会更加的少。

3. 大量使用通用框架和开源框架：国内使用最多的可能就是Java SpringBoot，vue.js，react这样的前后端组合。非常多的业务系统都是基于开源框架修改得来的；在某个项目中引用几十上百个maven或者npm包的情况非常普遍，这些包都是公开仓库中可以找到的。开发者多数时间是在不同的开源组件之间编写胶水代码。这种情况下，企业所谓的私有代码从编码语言特性上来说，实质上和这些开源代码库有非常强的相似性。这些代码其实已经在 代码大模型 的训练语料范围之内了，完全没有私有训练的必要。

这里所说的 代码大模型指的是专门为代码生成而训练的大模型，无论是商用的代码大模型还是开源的代码大模型，其训练语料的来源都类似，也都已经将大多数大家常见的编码语言和框架纳入其中。企业自己的那一点业务逻辑对这些模型来说，没有实质上的特别之处。

1. 代码质量堪忧：因为都是业务系统，任务重时间紧，开发团队很少考虑太多架构、可维护性问题，基本上都是能上线就行。

2. 业务变更快，代码抽象度低：其实这些企业中的代码变更多数都是业务逻辑变更，很多情况下都是复制粘贴以后略加修改就提交上线。和第4点一并考量，意味着如果使用这样的代码对模型进行训练，反而会降低模型生成代码的质量。所谓 “垃圾入，垃圾出” 就是这个道理。

基于这些分析初步判断，这类企业的代码并不适合进行私有化训练，因为这些代码并不符合大模型再训练的6个基本条件。而且如果进行了训练，非常容易出现把本来很聪明模型训傻的结果。

总结来说

在大多数企业中，按照一个既定的方式来持续改进大模型的应用场景，最终都可以达到很好的应用效果。以GitHub Copilot 为例，这个优化过程基本上可以分成3个阶段 [1]：

• 第一阶段：最早期的GitHub Copilot只能识别当前文件中光标以上的代码内容，对代码的感知能力有限，生成效果也一般；但很快Copilot团队开始引入光标以下的内容作为提示词的补充内容，生成效果立即出现了较大改善。这个过程实际上同时使用了提示词工程和微调2种方法，通过IDE获取光标前和光标后的内容并且重构提示词，这个是提示词工程范畴；对模型进行FIM（Fill in the Middle）的训练（改变模型行为）属于微调范围

• 第二阶段，GitHub Copilot开始通过引入IDE中的更多上下文内容来优化提示词，包括处于开启状态的代码文件，在文件头引入文件的元数据等方式；这些优化为GitHub Copilot贡献了大致5%的代码准确率提升 [1]。这部分虽然仅仅用到的提示词工程，但是所贡献的准确度提升仍然非常可观。

• 第三阶段，在去年的GitHub Unvierse大会上发布的 @workspace 能力，是通过RAG的方式动态获取与当前代码相关其他代码片段，这个能力大幅提升了Copilot感知代码上下文的能力，开启了更多的使用场景。
  
  

在企业中引入AI能力是当前所有企业管理者都在考虑的问题，但并不是所有人都意识到，AI能力不是一个独立的，它需要融入到企业现有的管理和工程场景中，用全新的方式重构这些场景，最终演化出我们从未见过的新场景。

本文主要以GitHub Copilot作为一个案例分析了针对企业私有化代码训练的可行性以及如何优化大模型应用的使用效果。后续，我会通过【数字共生】这个渠道和大家分享更多有关企业如何落地大模型应用的话题。

大模型已经成为工业革命之后整个人类最重要的技术革命，这一次浪潮远比移动互联网要更加汹涌，更加持久，更加彻底。

下图是GTC2024大会上，英伟达总裁黄仁勋和Tansformer的7位作者的访谈现场。难以想象2017年的这篇【Attention is All You Need!】论文彻底改变了整个行业的游戏规则。看着他们在台上侃侃而谈，突然觉得自己能够完整经历这次技术变革，而且还能在AI这股浪潮中跟上节奏，真的是一件很幸运的事情！