构建产品副驾驶（Copilot）的痛点 [译]

直译

2/4/2024

这篇文章是我们论文《构建你自己的产品副驾驶（Copilot）：挑战、机遇与需求》的非正式总结。更多详情请见预印本。感谢我的合作者们，来自 Microsoft 的 Chris Parnin、Gustavo Soares、Rahul Pandita、Jessica Rich 和 Sumit Gulwani。

各地的公司正在推出_副驾驶_——利用大语言模型 (LLMs) 来协助任务的 AI 助手。例如，Office 副驾驶帮助你使用 Word 和 Excel，GitHub 副驾驶帮助你编写代码，Intuit Assist 在 TurboTax 中帮助你报税，Adobe Firefly 帮助你生成和编辑图片，Dropbox AI 回答有关你文档的问题。

鉴于生成式 AI 被整合到产品中的突然激增，我们想知道软件工程师构建这些产品的过程是什么，有哪些痛点，以及工具有哪些机遇。

为此，我们对来自各种公司、正在研发副驾驶的 26 名开发者进行了半结构化访谈。我们定性分析了他们的回应以识别主题。然后，我们与工具构建者进行了两次焦点小组会议，会议内容包括回顾我们的访谈发现和头脑风暴可能的解决方案。

构建副驾驶的过程

鉴于大语言模型的非确定性特性，它改变了典型的软件开发过程。我们模拟了我们访谈中的开发者所遵循的高层过程：探索、实施、评估和产品化。它不是线性的，而是杂乱且迭代的。

例如，产品团队需要承担额外的风险。他们必须识别他们认为使用大语言模型可行解决的业务场景，尝试各种技术以看看是否有效（例如，大语言模型、嵌入、向量数据库），评估是否足够好，然后他们必须将其推送给实际用户。

所有这些任务中的每一个都给开发者带来了痛点。

痛点

我们将开发者在构建副驾驶时面临的痛点归类为 6 个基本主题：

提示工程耗时并需要大量的试错。此外，解析输出是乏味的，需要在使用更多上下文和使用更少的 token 之间找到平衡。另一个问题是管理提示、提示模板、什么有效、什么无效，以及为什么对它们进行了更改。正如一位开发者所说，"这更多是一门艺术而非科学"。
编排多个数据源和提示并非易事。系统尝试检测用户的意图并通过多个提示引导工作流程，但这增加了失败案例的表面积。规划和多轮工作流也受到追求，但证明更难以控制。正如许多开发者告诉我们的，它会_"脱轨"_。
测试是软件开发的基础，但涉及到大语言模型时变得艰难。每个测试都是一个不稳定的测试。一些开发者进行多次单元测试并寻求共识。其他人试图构建可以用来衡量提示或模型如何影响结果的大型基准，但这需要专业知识并且成本高昂。什么时候算是_"足够好"_？
最佳实践是许多开发者寻求的，他们通过关注 Twitter 标签或阅读 arXiv 论文来学习，但这并不可扩展，他们也不知道哪些资源是好的。该领域发展迅速，需要开发者_"抛弃他们所学的一切并重新思考。"_
安全、隐私和合规是每个人心中的担忧。它需要防护栏以防止副驾驶造成损害，但你也不能收集关于其使用方式的遥测数据，因为这会引起用户数据的隐私问题。安全审查是软件工程师正在经历的一项新的、通常是乏味的任务。
开发者体验是任何参与构建副驾驶的人的痛点。虽然有新工具，如 Langchain，但它们经常不会超越原型。例如，提示通常只是源代码中的字符串变量。开发者不得不学习并比较许多新工具，而不是专注于客户问题。然后他们必须将这些工具粘合在

一起。

工具的机遇

在我们与专业工具构建者的焦点小组会议中，我们确定了几个工具、流程和技术的机遇，以帮助开发者构建副驾驶。

需要对提示进行编写、验证和调试支持。例如，一个提示 linter 可以提供快速反馈。开发者还请求一个常见任务提示片段的库或_"工具箱"_。此外，追踪提示更改的效果将具有巨大价值。
缺乏透明度和控制经常让用户感到困惑。例如，用户通常不清楚 AI 可以访问哪些信息或可以执行哪些操作。
开发者希望自动化方法来衡量他们的 AI 或一个捕捉用户反馈的工具。不幸的是，开发者也表达了不想学习统计学或机器学习指标，如 BLEU。
为项目整合 AI 的一站式解决方案仍然是一个挑战。开发者正在寻找一个快速入门的地方，从游乐场过渡到 MVP，将他们的各种数据源连接到提示中，然后高效地将 AI 组件移入他们现有的代码库。

这仍然是产品副驾驶的狂野西部。看到软件工程将如何通过新流程或工具在接下来的几年内演变，将会非常有趣。

反思

直译过程中，有几个方面的问题需要注意并在意译中进行调整：

专业术语和概念的翻译：在直译中，尽管保留了原文的术语（如 LLMs, embeddings, vector databases），但对于中文读者而言，这些术语可能仍旧难以理解。在意译时，可以在第一次出现这些术语时提供简短的解释或等价的中文术语，以增强文章的可读性。
文本流畅性和表达习惯：直译的结果在一些地方可能读起来不够流畅，或者表达方式与中文习惯不符。例如，"prompt engineering is time consuming" 直译为 "提示工程耗时"，在中文中可能更自然的表达是 "构建提示过程耗时且复杂"。
上下文的清晰度：有些句子在直译后可能会失去一部分上下文的清晰度，比如在讨论痛点时，需要更明确地指出这些痛点是在开发副驾驶的过程中遇到的，以及它们为什么会成为痛点。
例子和比喻的本地化："wild, wild west of product copilots" 这样的表达在中文中可能没有直接的对应表达，需要找到更符合中文读者习惯和文化背景的比喻来替换。

意译

2024 年 2 月 4 日

这篇文章是我们关于《构建你自己的产品副驾驶：挑战、机遇与需求》论文的非正式概述。详细信息请参阅预印本。感谢我在 Microsoft 的合作伙伴：Chris Parnin、Gustavo Soares、Rahul Pandita、Jessica Rich 和 Sumit Gulwani。

全球各地的公司正纷纷推出_副驾驶_——这些基于大型语言模型 (LLM) 的 AI 助手旨在帮助人们完成各种任务。例如，Office 副驾驶能帮你处理 Word 和 Excel 文件，GitHub 副驾驶协助编程，Intuit Assist 在 TurboTax 中助你报税，Adobe Firefly 助你创作和编辑图片，而 Dropbox AI 则回答有关文档的问题。

鉴于生成式 AI 正快速融入各种产品，我们希望探索软件工程师在构建这些产品时的具体流程、遇到的挑战，以及开发工具的潜在机遇。

为此，我们对从事副驾驶开发的 26 名来自不同公司的开发者进行了半结构化访谈，通过定性分析他们的反馈识别出一系列主题。接着，我们又举办了两场与工具开发者的焦点小组讨论会，讨论访谈结果并集思广益寻找可能的解决方案。

构建副驾驶的过程

大型语言模型的非确定性特质，使得传统的软件开发流程发生了变化。我们根据访谈总结出开发者遵循的高层流程：探索、实现、评估和产品化。这个过程不是线性的，而是充满混乱和迭代的。

![展示构建副驾驶高层过程的图表，包括每个步骤的

示例活动。](https://austinhenley.com/blog/images/buildingcopilotprocess.png)

比如，产品团队需要面对额外的风险。他们得确定那些他们认为可以通过大型语言模型解决的业务场景，尝试各种技术（比如 LLM、嵌入技术、向量数据库）以验证其可行性，评估其效果是否达标，然后向终端用户推出产品。

开发者在执行这些任务时遇到了各种各样的挑战。

挑战

我们将构建副驾驶过程中开发者面临的挑战归类为六大主题：

提示工程不仅耗时，还需要反复试验。解析输出的过程也很繁琐，需要在提供更多上下文信息和减少 Token 使用之间找到平衡。还有就是管理提示、提示模板、哪些有效、哪些无效以及对它们所做更改的原因等问题。一位开发者形容，"这更像是一门艺术而不是科学"。
编排多个数据源和提示的过程复杂。系统尝试侦测用户意图并通过多个提示导向工作流程，但这增加了失败的可能性。规划和多轮工作流程同样备受期待，但实际操作起来更加困难。正如许多开发者所说，过程很容易_"偏离轨道"_。
测试是软件开发的基础，但在涉及到大型语言模型时变得格外困难。每次测试都可能出现不稳定的结果。有的开发者会进行多次单元测试并寻找一致性。还有些人尝试建立大型基准测试来评估提示或模型变化的影响，但这既需要专业知识也需要成本。什么时候算是_"足够好"_成了一个问题。
最佳实践是许多开发者寻求的，他们通过关注 Twitter 标签或阅读 arXiv 论文来学习，但这种方法无法扩展，且难以判断哪些资源是可靠的。这个领域发展迅速，让开发者感到需要_"放弃他们已有的所有知识并重新思考"_。
安全、隐私和合规是每个人都在关心的问题。需要设置防护措施来防止副驾驶造成损害，但同时不能收集用户数据的遥测信息，因为这会触及用户隐私。进行安全审查成了软件工程师的一项新的、通常很繁琐的任务。
开发者体验是所有参与构建副驾驶的人的一大挑战。虽然有如 Langchain 这样的新工具，但它们通常难以超越原型阶段。比如，提示往往只是源代码中的字符串变量。开发者必须学习和比较许多新工具，而不是专注于解决客户问题。然后，他们还需要将这些工具整合到一起。

工具发展的机遇

在我们与工具开发专业人士的焦点小组讨论中，我们发现了几个用于帮助开发者构建副驾驶的工具、流程和技术的机遇。

对于提示的编写、验证和调试需要更多的支持。例如，一个提示校验器可以提供即时反馈。开发者还希望有一个包含常见任务提示片段的库或_"工具箱"_。此外，追踪提示变更的效果也极具价值。
用户经常因为缺乏透明度和控制而感到困惑。例如，对于用户来说，AI 可以访问哪些信息或能执行哪些操作常常不明显。
开发者希望有自动化的方法来衡量他们的 AI，或是一个可以捕获用户反馈的工具。遗憾的是，他们也表示不愿意学习统计或机器学习的指标，比如 BLEU。
为项目整合 AI 的一站式解决方案仍然是个挑战。开发者正在寻找一个可以快速入门、从原型过渡到最小可行产品 (MVP)、将各种数据源与提示连接起来，然后高效地将 AI 组件融入现有代码库的解决方案。

这仍是产品副驾驶的探索初期。未来几年，软件工程的演变，无论是通过新流程还是新工具，都将是非常值得关注的现象。