打造「Copilot for X」究竟需要什么？[译]

原文：What Building "Copilot for X" Really Takes

来自首支真正的 Copilot 替代方案团队的指南

编者注（来自 swyx）：我很高兴为大家呈现我们第一篇来自嘉宾的文章！本文由 Codeium 团队撰写。过去一年里，我有幸结识了这个小团队，他们在短短一个月内就做出了一个完整的 Copilot「克隆版」（不是夸张——我个人已经把 GitHub Copilot 给关掉而改用他们的产品，一方面为了测试 Hey Github，另一方面是因为 Codeium 速度更快一些！）。如今，市面上几乎每个做 AI 产品的人都在列「Copilot for X」的愿望清单（示例），所以我邀请他们来分享在实践中的经验！

要点（TL;DR）：要想打造一个“Copilot for X”，你需要：

  • 估算推理规模：在延迟和输出质量之间做好权衡

  • 自己掌控模型：使用第三方 API 会毁了你的单位经济成本

  • 搞定实时基础设施：ChatGPT、DALL-E 等服务的速度对保持“流畅状态”来说太慢了

  • 优化 Prompt：上下文窗口非常有限；要判断哪些信息对输出提升效果最好

  • 整合模型输出与用户体验：原始模型输出往往直观度不足，你需要处理大量长尾的 UX 问题

最终，你会想要超越“Copilot for X”的模式，因为 Copilot 只是 AI 产品化后各种可能模式的一个起点。

（以下正文中，我会在部分内容处插入一些简短评论，其余部分由 Anshul 和他的团队呈现。）

如果你最近几个月在 Twitter 的某些 AI 领域关注过动态，你或许见到过类似的内容：

以前的创业公司喜欢把自己称作「Uber for X」。
现在则变成了「Copilot for X」。
如果你还不了解 Copilot，它能让编程工作更轻松。
—— Ben Tossell

GitHub CoPilot 是真正了不起的技术。
只要写一个函数名，它往往能把函数的实现直接写出来。人们或许还无法想象 AI 会如何极大地提升我们的生产力。
—— Whole Mars Catalog

Copilot 是 Github 推出的基于生成式大型语言模型的工具，它能在你写代码时给出提示，减少样板代码、减少查 StackOverflow 的频率，并在整体上让编程不再那么枯燥。“Copilot for X”指的就是借助同类 AI 技术来减少某个特定职业（比如法律、金融、学术申请等）中那些琐碎繁复工作的潜在新创业项目。

那么，真正做一个属于你自己的“Copilot for X”产品时，你究竟需要考虑哪些问题？

我们是谁？

我们是 Codeium 的创建者。Codeium 是一个免费、可替代 Copilot 的 AI 代码生成工具。在过去三个月里，我们从零开始构建了一个 AI 代码生成工具，它支持 20 多种编程语言和多个主流 IDE，拥有极低的延迟并且提供了与 Copilot 相当的建议质量。

在过去一年里，我们还一直在为一些极其复杂、高度计算密集型的企业级机器学习应用（如自动驾驶仿真）搭建可扩展的 ML 基础设施服务。伴随着生成式模型的爆发，我们意识到可以将我们的前沿 AI 与强大的 ML 基础设施结合，推出面向消费者的 AI 产品，于是就有了 Codeium。现在，已有数千名开发者在使用 Codeium，我们也希望能得到更多反馈，帮助我们共同打造 AI 驱动的编程新生态。

打造 Copilot for X 的要点

回到最初的问题——做 Copilot for X 需要注意什么？以下是我们在 Codeium 的一些经验教训：

  1. 推理规模预估。
    这是我们首先要做的事，因为使用频次量级的差异会显著影响成本的计算方式。对我们而言，一个单个开发者平均每天可能需要数千条代码提示（包括所有自动弹出的建议，而不仅仅是最终接受的建议）。

    • 要估算你需要做多少次推理，可以先考虑互动频次以及延迟与输出质量之间的权衡。如果模型的输出无法几乎每次都正中用户需求，你就需要尽量降低延迟，避免用户失去信任。而鉴于这些模型往往规模巨大，这会牵扯到非同小可的计算量以及成本投入。

  2. 使用第三方 API 从长远看很难在财务层面站得住脚。
    如果你打算做 Copilot for X，那么你就需要针对某个基础模型做微调（finetune），就像所有这些可生成代码的模型最初都在大量自然语言数据上训练，然后再在代码数据集上做了微调（可能还分多阶段）。在初期冷启动时，用第三方 API 做微调加推理也许方便，但费用会很快变得难以承受。

    • 粗略估算：GPT-3 中的 Curie 模型价格是每 1K tokens 0.002 美元，假设每次生成（包括 Prompt + 输出）大约需要 2K tokens，那么每次推理就是 0.004 美元。如果每个用户每天需要 1K 次推理，那就是 4 美元/用户/天，折合一年每人超 1000 美元。长期来看，你无法把所有这部分成本都转嫁给用户（更不必提盈利了）。

    • [swyx 备注] @levelsio 最近的一篇复盘 提到，Lensa AI 在市场上（一天收入达 100 万美元）比他的产品（累计收入 25 万美元）取得了更大成功，主要原因在于 Lensa AI 使用自研模型，单位成本更低，因此能把 AvatarAI 30 美元的价格打到 2 美元，他估计对方单次处理的成本可能只要 0.50 美元。

  3. 如果你在做的 Copilot for X 需要实时响应，那 ML 服务端部署的重要性绝不亚于模型本身。
    这里所说的实时，是指用户需要在「心流」（flow）状态下获得价值，而无法容忍像 ChatGPT、DALL·E、Jasper 等那种动辄几秒钟的延迟。人类对于视觉的平均反应时间大约是 150 毫秒，对于一个几十亿参数的模型（更别提网络延迟），要把推理时间压在这个级别就相当困难。Copilot 本身之所以不使用最大的 Codex 模型，也是出于这个原因。要在一开始就着手优化模型结构、在用户所在区域部署服务、做量化（quantization）等各种努力。

  4. Prompt 和上下文非常重要。
    大家还记得我说过，每次生成大约要用 2K tokens？每次推理的 tokens 上限取决于模型规模和延迟要求。英语中每个 token 平均代表 0.75 个词左右，如果你还要预留一部分 tokens 来生成输出，那么留给输入的 tokens 可能最多也就相当于 3000 个英文单词左右。很多场景中，这其实不算多。而且，为了得到最好效果，你通常不只是把光标前的文本传给模型——有时还需要上下文中光标后的内容、其他相关文件/文档内容，以及额外的自然语言提示。如何在有限的 tokens 中做取舍并精准运用，是一门“艺术”，需要不断迭代和实验。

    • [swyx 备注] 比如，社区现在已经知道 Copilot 的 Prompt 处理管线 会包含文档的路径和语言、最近访问的 20 个同语言文件，以及对光标周围文本片段的优先级“前后缀”策略，并用 Jaccard 相似度 来做片段提取。

  5. 客户端实现同样重要。
    是的，提升模型本身，并搭建整套数据处理、训练和部署基础设施固然必要，但别忘了在将模型输出真正呈现给用户之前，还有大量逻辑需要处理。这就是我们最初拿开源模型 CodeGen 来试时（光标前文本→模型→输出），“开箱即用”的体验其实并不好（先不谈我们把它跑在本地 GPU 上导致延迟更高这件事）。举个简单的例子：在 Copilot 或 Codeium 这种工具中，如果模型在空括号内生成了函数参数与主体代码，工具会自动把右括号跟生成内容合并，避免让用户最后还要手动删除一个多余的括号。这类看似细枝末节的体验问题累积起来就很多，所以你会发现要在模型输出与用户界面的交互上投入大量时间与精力。

在 Codeium，我们正致力于为开发者提供 Copilot 级的体验。也因此要指出：这项技术以及它的产品化，还在非常早期的阶段。

其实大语言模型能做的不只是续写输入文本，还有很多其他用法，可以为最终用户带来更大的价值。这其中在开发者的工作流中可能诞生出许多有意义的功能，只要能做好产品化：

  • 解释复杂的代码？

  • 在上游改动后自动修复代码？

  • 在多语言之间翻译？

  • 把现有代码更新到更先进的特性或包依赖？

我们相信，这些都只是 AI 生成式代码工具以及大型生成式模型的早期形态。所以，与其只关注“Copilot for X”，不如考虑“（能超越 Copilot 的一切可能）for X”。也许在不久的将来，这也会成为“Codeium for X”。

做个小广告！

Codeium 目前对所有用户都免费开放 —— 如果想亲眼看看生成式大语言模型的威力，可以访问 codeium.com，也欢迎加入我们的Discord 社区，获取我们基于该技术所做的更多探索（以及分享你对 AI 编程工具的需求和反馈）！

非常感谢 Codeium 团队带来的干货！ 如果读完觉得不错，还请在 Twitter 或 Mastodon 上给我们一些支持。你也可以关注 Anshul 和 Codeium 的 Twitter 账号。

See all posts