构建企业级大语言模型应用的秘诀：GitHub Copilot 的实践之路

GitHub Copilot 的开发团队分享了他们在构建能够同时为个人和企业用户带来价值的大语言模型（LLM）应用的心得体会。

本文经授权转载宝玉老师的个人博客（微博@宝玉xp），链接：https://baoyu.io/translations/llm/how-to-build-an-enterprise-llm-application-lessons-from-github-copilot

责编 | 夏萌

出处 | baoyu.io

若你希望利用大语言模型 (LLM) 打造并扩展你的应用程序，这篇文章将是你的不二之选。

开发 GitHub Copilot 耗费了我们三年时间，直到最近我们才正式向大众推出。我们的开发历程遵循了三个阶段：发现、实现、扩展。这三个阶段的理念源自于创业产品开发的 "先实现，再扩展" 框架。

这个过程分为以下几个步骤：

发现阶段：确定大语言模型应用可以解决的重要问题

实现阶段：打造顺畅的 AI 产品体验

扩展阶段：准备好你的大语言模型应用，使之适用于广泛用户（普遍可用性，GA）

现在，让我们一起深入了解。

发现阶段：聚焦你想解决的问题

在创造解决方案的过程中，最难的部分往往是确定并缩小问题的范围。这个问题应该具有足够的专注度，以便能迅速产生影响，同时又要足够广泛，确保找到的解决方案能给用户带来惊喜。更重要的是，你需要找到一个适合应用大语言模型（LLM）的问题，并非仅仅为了提升产品的参与度。

明确你想帮助的对象。我们发现 AI 能够提高效率，因此我们决定优先帮助那些时间紧迫、需要快速编程的开发者，帮助他们减少在不同任务间的切换，提高编码速度。

先聚焦一个问题。我们没有试图用 AI 一次性解决所有开发者面临的问题，而是专注于软件开发生命周期中的一个特定环节——在集成开发环境（IDE）中编写函数。在当时，大多数 AI 编程助手仅能完成单行代码的编写。

平衡产品野心和质量。GitHub Copilot 团队最初尝试生成整个代码提交，但当时的大语言模型（LLMs）还无法以足够高的质量完成这一功能。经过进一步测试，团队最终决定在“整个函数”级别提供代码建议。

专注问题，加速产品上市

GitHub Copilot for Individuals 推出仅八个月后，我们就推出了 GitHub Copilot for Business，配备了一整套企业级功能（比如适用于整个组织的策略管理）。这一切都源于我们对一个明确问题的聚焦，这让开发者享受到了快速发布和迭代的好处，同时也催生了 GitHub Copilot for Business 更强大的功能。

迎合用户现有习惯。在为开发者设计产品时，一个 LLM 应用应该能增强现有工具的功能或者融入现有的工作流程。GitHub Copilot 团队有一个原则：“如果你在使用 GitHub Copilot 时需要改变编码习惯，那就是个问题。”实际操作中，这意味着开发者可以在不改变其工作方式的情况下，接收到代码建议。

实现阶段：通过迭代创造流畅的 AI 产品体验

利用生成式 AI 这类新兴技术进行产品开发，其过程往往是曲折多变的，而非一帆风顺。这是因为该领域充满未知且快速发展，不断为我们开启新的可能性。在产品开发过程中加入快速迭代环节，可以使团队迅速从失败中学习并成长。在 GitHub，我们通过 A/B 测试平台实现快速迭代。

据 Idan Gazit，GitHub Next（GitHub Next）的高级研究主管所述：“我们设计应用程序，不仅要考虑到需要人工评估的模型输出，还要考虑到那些正在学习如何与 AI 互动的用户。”

站在用户的立场上考虑。GitHub 的员工习惯于通过“吃自己的狗粮”来体验最终用户的感受，无论是在产品发布前还是发布后。具体来说，GitHub Copilot 团队建立了一个简易的网页界面，通过此界面他们可以实验基础模型，并探索如何将这些模型应用于自己的开发流程。

我们很快意识到，网页界面并不是最佳选择，因为它要求开发者在代码编辑器和浏览器之间频繁切换。因此，团队决定将重点转移到将 GitHub Copilot 集成至 IDE，并使其无需特定模式即可运行，也就是在后台默默工作。

我们团队的开发者还发现，在编程时他们经常需要查看 IDE 中多个同时打开的标签页。这一发现促使他们尝试了一种叫做相邻标签页的技术，通过这种方式，GitHub Copilot 能处理开发者在 IDE 中同时打开的多个文件，而不仅限于当前正在编辑的文件。这种相邻标签页的技术使 GitHub Copilot 的建议接受率提升了 5%。

评估你的测试工具。我们的实验进程中，我们不断改进内部测试工具，使其更加全面强大。虽然一开始主要用自己的工具测试，但最后我们转向 Microsoft 实验平台，这样做能更好地根据大规模用户反馈和互动来优化功能。

避免沉没成本谬误。这是指当你在某个项目上已经投入巨大，却因为不愿意放弃而继续坚持，哪怕明显转变方向更有利的情况。

一开始，GitHub 和 OpenAI 团队认为每种编程语言都需要一个专门调整的 AI 模型。但随着生成式 AI 领域的快速进步，这种想法被证明是错误的。最终，OpenAI 的大语言模型（LLM）取得了显著进步，一个模型就能处理多种编程语言和任务。

定期回顾过去的想法。在这个飞速发展的领域，今天大语言模型（LLM）做不到的事情，或许明天就能实现。

最初，我们尝试了为开发者提供一个聊天界面来咨询编程问题。但早期测试表明，用户对编码建议的期望远超 GitHub Copilot 当时的能力。因此，我们暂时搁置了这个功能。然而，随着用户对 ChatGPT 这样的 AI 聊天机器人越来越熟悉，加上大语言模型的不断发展，像 GitHub Copilot Chat 这样的迭代式聊天体验变得可行。

我们的研发团队 GitHub Next 如何记录灵感闪现？

GitHub 的首席机器学习工程师 Albert Ziegler 分享了他们是如何记录在众多头脑风暴会议中涌现的所有大语言模型（LLM）功能点的。

“我们在会议中进行了深入的头脑风暴。之后，我们小组中的几个人会把这些想法记录在电子表格里，以便进一步分析这些点子。

比如在 2020 年夏天，我们列出了一长串我们能够通过 LLM 实现的功能。在一个共享的电子表格中，我们为每个功能命名、阐述其必要性，并找出它们在 GitHub 平台上的合适集成点。通过回答这些问题，我们不仅迅速评估了每个功能的潜力，还留下了一个回头再探讨这些想法的记录。”

扩展阶段：优化 AI 的质量、可用性和负责任使用，助力产品达到正式发布 (GA)

早期反馈和技术预览对于推动产品改进、帮助应用达到正式发布 (GA) 阶段至关重要。下面是我们在发布 GitHub Copilot 技术预览前所采取的步骤，我们如何管理技术预览、优化用户反馈，以及我们为应对大规模需求做好内部基础设施准备的过程。

优化质量和可用性

确保结果的一致性。大语言模型 (LLM) 是基于概率的，这意味着它们并不总能产生一致、可预测的结果。为了应对这个挑战，我们需要基于统计方法来进行实验。比如，我们建立了一个专门的质量管道来应对大语言模型在构建时的特殊挑战。

以 GitHub Copilot 团队为例，当他们开始提供完整的函数编码建议时，必须保证输出的可预测性和一致性，即相同的输入条件下，AI 模型能够产生相同的建议。

团队采用了两种策略来实现这个目标：一是调整参数以减少输出结果的随机性，二是使用缓存响应。这不仅减少了建议的变化性，还提高了性能。

实施技术预览的等待名单。GitHub Copilot 团队通过等待名单来管理问题、反馈和评论，确保这些问题能得到有效处理。这也帮助我们吸引了各种经验水平的开发者作为早期采纳者，他们为我们提供了宝贵的反馈。

GitHub Copilot 让开发者能解决更大、更有意义的难题

作为全球首个大规模应用的生成式 AI 编码工具，GitHub Copilot 在 2021 年 6 月以技术预览版形式首次亮相，并于 2022 年 6 月向所有开发者全面开放。

自推出以来，我们在开发者的生产力和幸福感上看到了显著提升。在一个盲测试中，使用 GitHub Copilot 的开发者编码速度比未使用的开发者快达 55%。

但生产力的提升不止于速度，有 74% 的开发者表示，使用 GitHub Copilot 编程时感到挫折感减少，能更专注于更有成就感的工作。

重视真实用户的反馈。举个例子，开发者反映一次更新降低了模型编码建议的质量。GitHub Copilot 团队立即采取措施，引入了一个新的指标——多行与单行建议的比例，并对模型进行了调整，确保用户仍然能得到高质量的建议。

GitHub 团队不仅自己试用 GitHub Copilot，体验开发者的使用感受，还从 GitHub 之外的开发者那里获得了多样化的反馈。我们与技术预览用户早期、频繁地、在他们喜欢的平台上进行互动，这使我们能够实时、积极地回应问题和反馈。

在规模扩大时不断迭代。当 GitHub Copilot 对外普遍开放时，团队不仅需要改善产品本身，还需要改善其基础设施。在初期，GitHub Copilot 是直接与 OpenAI API 进行连接和迭代的。随着产品的发展，我们开始使用 Microsoft Azure 的基础设施，以确保 GitHub Copilot 成为一个具备大型企业级产品应有的质量、可靠性和安全保障。

明确产品的关键绩效指标。在优化 GitHub Copilot 的过程中，我们根据开发者的初期反馈，确定了一些关键绩效指标，如代码的接受率和代码保留率（这是衡量开发者对原始代码建议的保留或编辑程度的指标）。

成本优化。我们的团队在努力降低提供 GitHub Copilot 建议的成本的同时，也在考虑对开发者的影响。例如，在决定使用幽灵文本（即当你输入时会出现的一种灰色建议文本）之前，该工具会迅速生成 10 个建议并同时展示。这不仅意味着对第二到第十个建议的高前期计算成本（因为大部分用户只会选择第一个建议），而且还增加了用户体验的成本，因为这些建议会使开发者从他们的工作流程中抽离，进入评估模式。Gazit 表示：“这就像是为了搜索引擎的第二页结果付费，并让这些结果强行吸引你的注意，尽管多数人只会关注第一个结果。”

成本优化是一个持续的过程，我们正在探索新的方法来在提升用户体验的同时降低成本。

优化 AI 的负责任使用

重视安全和信任。GitHub Copilot 的技术预览阶段的反馈强调了提出安全代码建议的重要性。为此，团队加入了代码安全功能，筛选出可能含有安全隐患（如 SQL 注入和硬编码凭证）的建议，并使用 Azure OpenAI 服务的自然语言过滤器来排除冒犯性内容。*

让社区参与其中。在 GitHub，我们非常重视广大开发者社区的反馈，并与他们合作以改善我们的产品。在 GitHub Copilot 的案例中，开发者社区在理解 AI 的潜力及其引发的一些担忧方面发挥了关键作用。

比如，开发者社区曾担心 GitHub Copilot 的建议可能与公开代码重合。作为回应，GitHub Copilot 团队设置了一个过滤器，以阻止与 GitHub 公开仓库中超过 150 个字符的公开源代码相匹配的建议。

基于社区的反馈，GitHub Copilot 团队还开发了一个代码参考工具，提供与 GitHub Copilot 建议可能相符的公开代码链接，这样开发者就可以审查潜在的匹配情况（以及相关的许可信息），从而做出更明智的决策。

制定走向市场的策略

利用产品布道师来推出你的产品。在 2021 年推出 GitHub Copilot 的技术预览版之前，团队向软件开发社区的领军人物和 GitHub Stars 展示了产品原型。这样做不仅在推出技术预览版时就已经有了一定的支持基础，而且能让产品触及到更广泛的用户群体。

先面向个人用户推广产品，再考虑企业市场。团队最初决定直接向开发者出售许可证，因为这些开发者显然可以从 AI 编程助手中受益。我们结合了免费试用和基于用户调查的月付制定价策略，调查显示个人用户倾向于简单明了且容易预测的订阅方式。在个人用户群体中建立起支持基础，有助于推动产品在企业级市场的接受和使用。

关键经验

在生成式 AI 这个新兴领域，我们正密切关注市场需求和技术发展。在构建大语言模型（LLM）应用程序的过程中，每个公司和产品都有其独特的方法，但从我们与 GitHub Copilot 的合作中，我们总结了几点关键经验：

明确特定的问题，并深入分析 AI 的潜在应用场景。这样做可以帮助应用程序产生更大的影响，并更快地推向市场。

将实验性质的尝试和紧密的反馈循环融入设计过程。在大语言模型的开发中尤为重要，因为这些模型的输出结果具有概率性，而且多数用户还在学习如何与 AI 模型互动。

在扩展应用范围时，持续倾听用户反馈，优先考虑用户需求。这样可以确保产品能够稳定地提供真正有价值的结果。

如果你在寻找适合大语言模型应用解决的问题，不妨看看我们的文章，了解公司是如何通过生成式 AI 提高效率的。同时，你也可以参考GitHub 如何通过 GitHub Actions 帮助 AI 非营利机构 Ersilia，在低收入和中等收入国家推动药物研究，从他们的做法中获取灵感。