当前,Copilot 已经成为国内开发者常用的辅助工具。就像有的开发者评价称, “编码时,我希望干扰最少。在这方面,Copilot 给我提供了巨大的帮助。它减少了我可能花在网络上寻找解决方案的时间,而且它们在我最喜欢的 IDE 中触手可及。”Copilot 带来了很多便利。
虽然人工智能和自动化很早就成为开发者工作流程中的一部分了,但由 GitHub 和 OpenAI 开发的、基于云的人工智能工具 Copilot 让大家真正感受到了“智能”的力量。根据 Stack Overflow 最新发布的开发者报告,Copilot 如今是最受欢迎的开发者搜索工具。那这样一款“划时代”的工具是如何打造出来的呢?
【资料图】
六个人的默默研发
“我们差不多就是个臭鼬工厂,没有人知道我们。”GitHub Copilot 创建者之一的 Alex Graveley 回忆道,Copilot 是根据创业原则,由一个小团队在不到一年的时间里,在“非常不正常的 GitHub/MSFT 组织中”开发出来的。在这个团队里,开发者只有 6 位,此外还有一个 PM 和一个 VP 主要负责登录页面和图标方面的工作。
Alex 不确定具体是从什么时候开始的,但当时 OpenAI 和微软已经就超级计算设施达成了协议,想要构建一套大型训练集群。他们还在制定另外的合作协议,可能会把 AI 相关条款引入 Office 和 Bing。GitHub 当然也不例外,他们想试试 AI 在开发中能发挥什么作用。
OpenAI 打算对模型做一点微调,看能不能用小模型更好地辅助编程。什么叫“小”模型?当时团队里的人都不知道该把规模控制在怎样的程度,但能确定的是绝不搞得参数巨多、体量巨大。Alex 回忆道,这个“小”模型还没有 Davinci 大。
OpenAI 的基础模型就像是个训练工件。他们想把代码引入进去,看看自己的基础模型会作何反应。“我觉得这对思维链产生了积极的影响。毕竟代码推理具有明确的线性,而 AI 模型应该比较适应这种一件件事做下去、前一件事对后一件事产生影响的应用场景。”Alex 表示。
但刚开始的效果并不理想,甚至可以说相当糟糕。毕竟这只是一款底层工件,又遇上了 GitHub 上的一小部分数据样本。当时就只有 Alex 和另一位机器学习工程师 Albert Ziegler 在摆弄这套模型。他觉得虽然多数情况下都不起作用,但这套 AI 模型似乎正在积蓄力量。
最开始,他们投喂的数据只有 Python 代码,想据此让它做出有用的输出。“我们啥也不懂,所以就先从简单处入手,投身去试。看看这样行不行,看看那样行不行。坦白讲,我们根本不知道自己在干什么。所以第一项任务就是多做测试,看它能做什么。”
Alex 他们在内部众包整理出一大堆 Python 问题,这些都是肯定不会出现在训练集中的内容。之后他们开始挑选 repo 并设计测试,看看模型生成的函数到底能不能过关。基本过程就是要求模型生成相应函数,然后运行测试看给出的函数能否通过。
刚开始的通过率很低,大概是 10% 的水平。之后团队开始给模型更多的尝试,试着让它慢慢摸索出解决思路。在其他独立测试中,Alex 他们还会编写测试函数,然后试着让它填充函数体。如果可以过关,就证明它确实有效。在野外测试中,他们会下载一个 repo 并运行所有测试,而后查看通过了哪些测试、调用了哪些函数、能否正确生成函数体,再重新运行测试看是否顺利通过。最后,把结果记录下来再核算百分比。
可以想见,前期测试的通过百分比相当低。因此,团队开始把 GitHub 上的所有代码都投喂给模型,还引入了其他一些新的、起步阶段根本没想到过的技巧。最终,它在野外测试中的通过率从不到 10% 提升到了 60% 以上。换言之,随便给它两项代码生成测试,它基本就能通过其中一项。“这是个循序渐进的过程,从 10% 到 20%,再到 35% 和 45%,就这样慢慢提升。”
在探索过程中,团队还尝试提高提示词的设计质量,在特定环节上对它作出引导。这套模型接触到的可是代码的所有版本,而不只是最新版本,配合 diffs 让模型能理解不同版本间的微小区别。
“总之,它最后变得更好、更强。但至少在起步阶段,一切都只能从零开始,我们就像懵懵懂懂的孩子。唯一的想法就是,也许这东西终有一天能取代 Stack Overflow 以及其他开发工作流工具。”Alex 说道。
再前进一步
Copilot 的首个迭代版本只能算是一种内部工具,能帮人们编写一些简单测试。之后团队开始试着生成常用的 UI。“毕竟刚开始它生成代码的通过率只有 10%,而 UI 设计其实是个比较开放的问题,也许能回避 AI 能力不行的事实。如果成功那就太棒了。”
所以,接下来,团队开始对模型做微调和测试。另外,他们又想让他实现 VS Code 扩展的功能,比如说代码自动补全?当时的 Alex 觉得这应该没有问题,而向自动补全的探索也代表着巨大飞跃的来临。“虽然终极目标仍然是替代 Stack Overflow,但起步阶段我完全想不出这一切要怎么实现,先在 VS 里实现点功能才是真的。”
“作为我们的一小步,自动补全功能实现了,而且有趣且有用。它会像其他自动补全功能一样弹出一个提示框,供大家选择其中的字符串。这种使用形式便捷且容易上手,很舒服。我们还试过其他一些功能交付方法,比如在空函数上添加一个小按钮,由它为开发者快速生成;或者开发者可以点击控制键,再从弹出的大列表中随意选择。总之,我们几乎试遍了自己能想到的所有 VS Code UI。” Alex 说道。
虽然一切暂时还处于起步阶段,但它提供的推荐列表可以说“日新月异”来形容。毕竟这时模型只接触过小部分样本,所以仅可作为技术爱好者和测试设计人员的玩具。团队希望它能变得像 Gmail 的文本自动补全功能一样好用。
“我特别喜欢那款产品。那可是大语言模型的首次部署成果,速度很快、效果也很好。谷歌还专门发论文分享了具体技术细节和细节调整。我们就朝着这个方向努力,刚开始补全效果很不好,但却让人感觉它一直在朝正确的方向前进。就这样反复尝试和调整之后,终于拿出了一段小小的演示视频。” Alex 表示。
Alex 回忆称,当时团队每天工作 12 小时,克服阻碍,忽略最佳实践。当时只有 CEO、副总裁和团队的人相信这件事,其他人比较质疑。
微软推向全球的努力
在发布通用版之前,Copilot 已经开放过公测,免费供大家使用,而且针对不同群体做了很多优化。比如经验丰富的程序员会怎么用,新人开发者会怎么用,还有不同国家的地区的用户会有怎样的习惯和倾向。
Copilot 团队收集了一大堆统计数据,并意识到速度在任何群体中都是最重要的指标。“我们发现延迟每增加 10 毫秒,就会有 1% 的用户放弃这项功能。另外在新功能公开发布的头几个月,印度的使用完成率是最低的——不确定为什么,但完成率确实明显低于欧洲。”
后来团队发现,这是因为 OpenAI 只有一处数据中心,而且位于美国得克萨斯州。可以想见,如果数据需要从印度穿过欧洲和大西洋再最终抵达得克萨斯,那来来回回的延迟肯定令人抓狂。这就会导致提示节奏和输入节奏脱节,功能完成率必然会受影响。
在找到症结之后,团队成员们也就释然了。而跟得州不远的用户们纷纷给出好评,比如有人会评论说,“我不会编程,但出于工作需要,我想了解怎么编写某个 100 行长的脚本。”事实证明,AI 模型特别擅长这种开发模式,而在找到模式之后,设计出来的 UI 就能派上用场。
后面就迎来了团队的“高光时刻”:发布成果,获得市场好评,然后尽快再更新和迭代。
“有客户表示,他们听说 Azure 打算在未来半年内全面承接 OpenAI,但他们等不及了,最好下个月就开放。”Alex 说道,团队当时就想办法满足这些要求,比如在欧洲和亚洲提供基础设施,把 AI 模型拉近到西海岸、得克萨斯乃至欧洲所有用户身边。微软在这方面投入了巨大努力,而在设施准备就绪并投入运行之后,Copilot 就这样正式跟大家见面了。
“没有 OpenAI 的天才和有原则的 VSCode 编辑人员,Copilot 是不可能的。”Alex 表示。