MVP 聚技站｜GitHub Copilot 产品经理和微软 MVP 告诉你：企业是否需要训练自己的代码大模型？
M
点击蓝字 / 微软开发者MSDN
关注我们
作者：徐磊
排版：Alan Wang
本文转载自：数字共生
徐磊
微软最有价值专家（MVP）
英捷创软 创始人/CEO/首架构师/AISE 产品经理
微软最有价值专家 MVP，微软区域技术总监 Regional Director
GitHub Star / GitHub Copilot 中国区授权服务资深顾问
开放原子开源项目 SmartIDE 创始人/核心贡献者
华为云MVP
资深软件工程/敏捷/精益/DevOps 专家，EXIN 认证 DevOps Master/Professional/认证讲师
书籍作者和译者《专业 SCRUM 基于 Azure DevOps 的敏捷实践》，《云原生应用开发实践》，《基础设施即代码 - 模式与实践》
提示：全文字数7104，如果您只希望了解标题所述的问题，可以直接跳到【私有化代码训练的6个基本要素】部分。
生成式 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 们在微软总部的合影
（从左至右：Ryan、Tony、张雅琪、李佳芮、刘海峰、苏震巍、苏繁和我）
当然，和老朋友们面基也是一件非常快乐的事情。在这里也见到了一些平时只在各种大会 keynote 和技术分享中才能见到的面孔。
图：Scott Hanselman，Adam Cogan（微软 MVP/RD）和 Martin Woodward（GitHub 开发者关系副总裁）
此行还有一个非常重要的任务，就是为本文开头部分的问题寻找答案。
我和 GitHub Copilot
2020年6月 OpenAI 发布了 GPT-3的基座模型，在2021年6月 [1] 时隔一年后，GitHub 也发布了内部预览版的 GitHub Copilot，第一代 GitHub Copilot 使用的是基于 GPT-3迁移训练（Transferred Training）出来的 Codex 模型。从那个时候开始，包括 Martin Woodward 在内的很多 GitHub 老朋友就开始活跃在我的联系人列表中。虽然彼时 GitHub Copilot 的能力和现在相比有很大差距，但当幽灵字体第一次出现在 Visual Studio Code 中时，那种兴奋还是让我记忆犹新。
如果你还没有接触过“AI 辅助智能编码”类产品，可以关注一下以下截图。下图是一个集成开发环境 IDE，里面所列出的代码到第10行之前是由开发者写出来的，第10行之后的灰色字体（Copilot 的叫法是幽灵字体）是由 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 的实际使用效果。
2022年11月，OpenAI 推出了 ChatGPT 并且在全球引爆了生成式AI 的技术革命。GitHub Copilot 也开始在国内受到关注。截止2023年5月，英捷创软（我的团队）已经帮助超过100家国内企业引入 GitHub Copilot 的企业版。这个过程中，我和我的团队也经常被问起两个问题。
- 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 的开发，Type 的发明者 Anders Hejlsberg 也在她的麾下工作。
- Ryan J. Salva - GitHub Product VP，GitHub Copilot 产品总监。
- Idan Gazit - GitHub 资深研究员/Heroku, Django 开源项目核心贡献者，主管 GitHub 下一代新产品的研发，其中就包括 GitHub Copilot X。
不出所料，这些问题也同样是微软/GitHub 在构建和推广 Copilot 过程中遇到的关键问题。他们3位也同时表达了对企业进行私有代码训练这条路径的不同看法，本文的后半部分是我根据和他们的对话整理而成，希望能够对正在阅读本文的企业管理者和开发者有所帮助。
私有代码训练的6个基本要素
大型企业有自己内部的个性化代码是一个行业现状和事实，也是作为 AI 辅助智能编码产品必须要解决的问题。但更加关键的问题是：是否一定要通过私有化训练才能达成这个目标？
企业需要的是定制化的大模型应用，这不等于定制化的大模型，更不等于大模型的私有化训练；这是3个不同层次的问题 。
和微软开发工具事业部总裁 Julia Lison 聊到大模型在微软内部的落地情况的时候，我提到一个看法，得到了 Julia 的认同：
大模型就好像电一样，是用来驱动工具解决各种问题的，它可以驱动电视、冰箱、电动汽车；这些不同的产品都可以解决不同场景下的问题，都是电的定制化应用。我们并不需要去修改电本身的特性，我们应该把目光放在如何创造新时代的电灯、电视和电动汽车上。
在微软内部有超过10万名软件工程师 [2]，使用标准 GPT-3.5和 GPT-4模型 [3] 的 GitHub Copilot 版本已经足以满足绝大多数微软内部开发团队的需要，同时也确实有部分团队需要对模型进行训练才能让 GitHub Copilot 更加正确地适配他们的代码。在为数不多的需要进行模型训练的部门中，O 产品开发团队是一个典型的例子。O 产品是微软最古老的产品之一，也是全球众多用户每天都在使用的超级应用。O 产品中的很多代码比正在修改这些代码的工程师年龄还大，大部分代码是 C/C++ 编程语言并且大量使用了宏 [4]。同时，作为一款巨型规模的产品，在 O 产品代码库上工作的工程师必须要遵守非常复杂详细的编码规范，包括很多的函数返回对象的结构都有特别的要求。
说明：C语言和很多大家熟悉的高级语言有很大区别，它非常接近底层操作系统，因此工程师如果要写出 O 产品这种量级的应用其实需要构建大量的可重用组件，这个过程有点像搭积木。这些组件从编程语言性质上来看和大家熟知的 Java 语言中的类和方法有非常大的区别。C语言的这些组件更像是创造了全新的编程语言和语法。鉴于本文的受众更多是企业的技术管理者，这里不再展开这个话题，有兴趣可以参考网上很多的分析，比如 [5]。
微软内部的实验结果说明，对 O 这种非常特殊的代码库进行模型训练确实可以一定程度地提高 Copilot 代码准确度，但提升的准确度仅有几个百分点，且训练成本巨大。Github Copilot 后台所使用的 GPT-3.5 Turbo 模型，单模型实例需要几十张高性能的 GPU 才能完成推理，一旦进行了私有训练，这个模型实例就只能用于 O 产品团队，不再适用于任何其他团队。训练所需要的 GPU 数量远高于推理的需求，这意味着为 O 产品提供私有化训练的模型成本极其昂贵。至于微软为什么仍然选择使用模型训练的方式，以下答案可以作为企业管理者判断是否要对大模型进行训练的一个标准，这里面包含6个基本因素，缺一不可：
- 团队规模巨大：即便只有几个百分点的准确度提升，放大到几千人规模的开发团队上，产生的效能提升和节省的成本/资源也是非常巨大的。
- 单一代码库：几千人规模的 O 产品开发团队全部都在一种开发语言和非常类似的代码库上进行工作，因为任何的模型只要进行了再次训练，就只能针对某一种开发语言提供服务，再次训练虽然会增强模型在 O 产品代码库上的能力，同时也会降低这个模型实例对其他编程语言的处理性能。这一点上，O 产品团队符合要求。
- 代码足够特殊：特殊到 GPT-3.5 Tubro 模型在训练的时候完全没有见过类似的代码。基于前面分析的，虽然是 C/C++ 语言，但是因为语言本身的高度灵活性和这个单一产品本身的规模，其代码库中代码是 GPT 完全没有见过的。
- 代码规模巨大：要通过训练对基座模型产生影响，至少需要几百万行规模的高质量单一语言代码。面对一个几十/上百亿参数量的模型，如果训练数据不够，则不足以影响模型的行为。即便采用非常高效的微调方式，也需要原有数据的1%左右规模的数据才能发挥作用。
- 容忍训练失败：即使在类似 GPT 这样高质量的模型上进行再次训练并且由非常有经验的工程师来操作，如果参数控制不到位也容易出现失败的情况。加上每次训练所需要的算力和时间消耗，这是一个非常高风险的投入。
- 足够的不可变基础代码：模型训练会让模型产生非常强的偏好，要修改这个偏好就必须要重新训练，因此用来训练的代码必须是那些在很长时间内（至少几年）中不会发生变化的代码。如果私有代码组件已经发生了改变，而模型还在一直生成老的代码，反而会对工程师的工作效率产生负面影响。O 产品因为有大量自行研发的可重用的基础组件代码，也符合要求。
对于普通的企业，其实大多数是不符合以上的条件的，特别是非软件/非 IT 行业的软件开发团队，最典型的就是大型银行/金融机构/电商等等。我将这些行业称为极度依赖 IT 的非 IT 行业。这些行业有几个普遍特点：
- 开发团队规模整体大但单个业务团队规模一般：因为业务足够复杂，确实需要庞大的开发团队来支撑整个业务系统；但是内部应用系统众多，虽然整体开发团队人数众多，但某个业务开发团队的规模都不大，基本都在几十人最多百人规模。如果针对这样的代码进行训练，那么就意味着需要给每个业务团队训练一个不一样的模型。这样来看，无论从成本收益的角度，还是训练数据量可行性的角度都行不通。
- 技术栈分散：分布式系统架构加上容器化的普及，企业中同时使用多种技术栈的状况非常普遍，最常见的 Java、Java、Node.js、Python、CSS/HTML 基本上每家企业都在用。虽然企业的总代码量很大，但是落实到具体某个编码语言上也没多少。代码训练其实是针对不同语言单独进行的，这种情况意味着每种语言的代码语料都不会太多。如果和第1点一并考量，那么单个业务团队内的某个编码语言的语料会更加的少。
大量使用通用框架和开源框架：国内使用最多的可能就是 Java Spring Boot，vue.js，React 这样的前后端组合。非常多的业务系统都是基于开源框架修改得来的；在某个项目中引用几十上百个 maven 或者 npm 包的情况非常普遍，这些包都是公开仓库中可以找到的。开发者多数时间是在不同的开源组件之间编写胶水代码。这种情况下，企业所谓的私有代码从编码语言特性上来说，实质上和这些开源代码库有非常强的相似性。这些代码其实已经在代码大模型的训练语料范围之内了，完全没有私有训练的必要。
这里所说的代码大模型指的是专门为代码生成而训练的大模型，无论是商用的代码大模型还是开源的代码大模型，其训练语料的来源都类似，也都已经将大多数大家常见的编码语言和框架纳入其中。企业自己的那一点业务逻辑对这些模型来说，没有实质上的特别之处。
4. 代码质量堪忧：因为都是业务系统，任务重时间紧，开发团队很少考虑太多架构、可维护性问题，基本上都是能上线就行。
5. 业务变更快，代码抽象度低：其实这些企业中的代码变更多数都是业务逻辑变更，很多情况下都是复制粘贴以后略加修改就提交上线。和第4点一并考量，意味着如果使用这样的代码对模型进行训练，反而会降低模型生成代码的质量。所谓 “垃圾入，垃圾出” 就是这个道理。
基于这些分析初步判断，这类企业的代码并不适合进行私有化训练，因为这些代码并不符合大模型再训练的6个基本条件。而且如果进行了训练，非常容易出现把本来很聪明模型训傻的结果。
总结来说：
我们不能因为需要造一款新的电视，去让发电厂修改电压。
如果你要造的是个电动航母，那么全新设计一款新的发电机也是值得的。
GitHub Copilot 是如何提升生成代码准确度的？
在大多数企业中，按照一个既定的方式来持续改进大模型的应用场景，最终都可以达到很好的应用效果。以 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 作为一个案例分析了针对企业私有化代码训练的可行性以及如何优化大模型应用的使用效果。后续，我会通过【数字共生】这个渠道和大家分享更多有关企业如何落地大模型应用的话题。
结尾
微软 MVP 西雅图峰会结束后，借参加英伟达 GTC2024大会的机会，我又在旧金山、硅谷和整个湾区见到了很多大模型创业者和投资人，交流中发现虽然国内和海外对大模型应用的切入点有很多不同，但是大家都认同一个观点：
大模型已经成为工业革命之后整个人类最重要的技术革命，这一次浪潮远比移动互联网要更加汹涌，更加持久，更加彻底。
下图是 GTC2024大会上，英伟达总裁黄仁勋和 Tansformer 的7位作者的访谈现场。难以想象2017年的这篇【Attention is All You Need!】论文彻底改变了整个行业的游戏规则。看着他们在台上侃侃而谈，突然觉得自己能够完整经历这次技术变革，而且还能在 AI 这股浪潮中跟上节奏，真的是一件很幸运的事情！
2024年3月21日于美国圣何塞，完稿于韩国仁川机场
微软最有价值专家（MVP）
微软最有价值专家是微软公司授予第三方技术专业人士的一个全球奖项。31年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和经验而获得此奖项。
MVP 是经过严格挑选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的热情并乐于助人的专家。MVP 致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人，并最大程度地帮助微软技术社区用户使用 Microsoft 技术。
更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn
微信公众号｜微软开发者MSDN
新浪微博｜微软中国MSDN
·END·