说在前面：
GitHub Copilot 团队分享了其构建LLM应用程序的经验教训，其作为目前应用最为广泛的 LLM 应用之一，相信我们能从中学到很多。如果您想使用大型语言模型（LLM）构建和扩展应用程序，那么本文就是为您准备的。
引言：
GitHub Copilot 项目从定位，实现到最终对外发布，他们花费了三年时间，经历了三个阶段：
- 寻找问题:寻找LLM应用能够解决的具有影响力的问题
- 优化产品:打造流畅的AI产品体验
- 规模化:让LLM应用能够面向大众使用
文章将分享我们在每个阶段的做法及经验教训,帮助您更好地构建企业级LLM应用。
第一阶段：寻找问题 - 锁定您想解决的问题
有时最难的部分就是缩小问题范围。问题应该具有足够关注度可以快速实现影响,同时也需要规模大到最佳解决方案能吸引用户。此外,您需要找到LLM真正适合解决的问题(而不是仅为增加产品参与度而整合LLM)。
有时候，创建解决方案最困难的部分是确定问题范围。这个问题应该足够集中，以便迅速产生影响，但也应该足够大，以便正确的解决方案会让用户惊叹。此外，您还需要找到一个真正适合用LLM解决的问题（而不是为了集成AI而集成）。
那具体该怎么做呢？这里有四点建议：
- 明确你想帮助谁。我们看到 AI 可以提高效率，所以我们想优先帮助那些一直在注重效率问题的开发人员，使他们能够更快地编写代码，减少上下文切换。
- 一开始只关注一个问题。我们没有试图解决所有开发者问题，而是专注于软件开发生命周期的一部分：IDE中的编码功能。当时，大多数 AI code assistant 只能完成一行代码。
- 平衡产品野心和质量。虽然GitHub Copilot团队最初探索生成完整的代码提交，但LLM的状态当时无法以足够高的质量支持该功能。通过进一步的测试，团队决定聚焦在函数级别的代码建议上。
- 在人们所在的地方与他们见面。当涉及到为开发人员设计产品时，LLM应用程序应该扩大现有的工具或集成到现有的工作流程中。GitHub Copilot团队的一句口头禅是，“如果你在使用GitHub Copilot时必须改变编码方式，那就是一个错误。”在实践中，这意味着让开发人员能够在不改变工作方式的情况下收到代码建议。
第二阶段：不断迭代 - 打造流畅的AI产品体验
新兴技术的产品开发，如生成式AI，往往更像是一条曲折的道路和一段线性的旅程，因为有太多未知的事情，而该领域的快速进步可以迅速打开新的大门。在产品开发过程中构建快速迭代周期以支持团队快速试错与进步。在GitHub，我们快速迭代的主要机制是A/B实验平台。
GitHub Next高级研究总监Idan Gazit表示，“我们不仅要为输出需要人类评估的模型设计应用程序，还要为正在学习如何与人工智能交互的人类设计应用程序。”
- 设身处地为用户着想。GitHub的员工有一种文化，即在产品发布之前和之后，通过吃自己的“狗粮”来设身处地为最终用户着想。在实践中，这意味着GitHub Copilot团队建立了一个简单的web界面，可以在其中修改基础模型，并探索在自己的开发人员工作流程中利用这些模型的方法。
- 我们很快发现，web界面不是合适的交互方式，因为这意味着开发人员必须在编辑器和web浏览器之间来回切换。因此，该团队决定专注于将GitHub Copilot引入IDE，并使AI功能无感知地在后台工作。
- 我们团队的开发人员还注意到，他们在编码时经常引用IDE中的多个打开的选项卡。这一见解使他们尝试了一种名为相邻选项卡的技术，GitHub Copilot处理在开发人员的IDE中打开的多个文件，而不是开发人员正在处理的单个文件。相邻选项卡有助于将GitHub Copilot建议的接受率提高5%。
- 评估测试工具。随着实验规模增大,我们不得不优化内部测试工具使其更多变和强大。最初我们依赖自有工具,但最后转向使用Microsoft Experimentation Platform来优化产品功能。
- 避免陷入沉没成本陷阱。即使发现一种方法不可行,但由于投入已十分庞大,仍很难放弃。团队在最开始的时候，就投入了巨大精力为每个编程语言训练 AI 模型，后来发现大语言模型变强了后，一个模型就可以处理多种语言和任务，于是马上调整方向切换到大语言模型，而不纠结于在单一编程语言上训练消耗的沉没成本。
- 养成重温旧思想的习惯。在一个快速发展的领域，今天的LLM不可行的功能可能会在明天实现。
一开始，我们探索了一个聊天界面，供开发人员提出编码问题。然而，在早期测试中，用户对编码建议的功能和质量的期望远高于GitHub Copilot当时所能提供的。因此，我们取消了该功能的优先级。但随着ChatGPT和LLM的出现，客户对AI聊天机器人的熟悉程度不断提高，像GitHub Copilot chat这样的迭代聊天体验成为可能。
第三阶段：扩展 - 优化AI的质量、可用性和负责任的使用，以实现GA(正式发布)
当功能开发出来后，还需要考虑到投入生产环境大量用户使用的情况。GitHub Copilot 团队采取了一些有效手段来保障产品的发布和扩展。
他们通过 waiting list 的方式逐步放开测试，并且在测试过程中收集反馈并及时调整。
由于大语言模型是基于概率预测的，这意味着它们并不总能产生一致、可预测的结果。所以它们做了缓存，以及调整了参数降低随机性。另外还有很重要的一点是他们建立了数据监测机制，通过明确了产品的关键绩效指标，如代码的接受率和代码保留率（这是衡量开发者对原始代码建议的保留或编辑程度的指标），这样在发布测试或者新版本时，就能通过数据监测来及时了解版本的质量是否符合预期，出现问题可以及时回滚或者调整。
除此之外，他们也做了很多优化在不降低质量的前提下降低成本，比如前面提到的缓存，还有一个有一的案例，就是最开始他们在 AI 建议代码的时候，会生成 10 条建议结果（如果你用过早期版本应该记得），但是发现这样成本很高但大部分用户只会选择第一个，所以他们优化为只显示 1 个结果。
总结：
- 缩小范围，聚焦在特定的问题，并深入分析 AI 的潜在应用场景。这样做可以帮助应用程序产生更大的影响，并更快地推向市场。
- 在设计时就考虑到如何快速测试功能和收集数据反馈，因为对于大模型来说输出结果具有不确定性，而且绝大部分用户还在学习如何与 AI 互动。
- 在扩大规模时，持续收集用户反馈，考虑用户需求，确保能够提供真正有价值的功能。
原文：How to build an enterprise LLM application: Lessons from GitHub Copilot
