生成式 AI 应用落地小结：高估的模型能力，低估的工程实施

Posted by: Phodal Huang Dec. 3, 2023, 5:08 p.m.

虽然 ChatGPT 已经诞生了一周年，但是大量的人依旧对于生成式 AI 没有足够的认识。在研发领域，Thoughtworks 一直在与不同的大型企业合作，保持开放性的探索。

在我负责的 Thoughtworks 开源社区，我们与外部的几家大型企业一起探索和构建了 Unit Mesh 的诸多开源项目，作为开源 AI 研发体系的一部分。

与生成式 AI 在其它领域落地不同的是，有大量的企业已经由小作坊的开发方式，转变为规范化、标准化的开发方式。在具备规范化的项目开发流程与验收流程，生成式 AI 可以更好地提升整体的效能。

而从我们观察的情况来看，人们总希望：微调后的模型能一次解决的所有问题。但是，这几乎是不可能的，不论是生成文本还是生成代码，都需要依赖于模型的能力与体验的设计。

应用能力：模型能力受限下的体验设计

2023 年年初，我们开始构建 AutoDev 这个插件时，由于响应速度是我们的主要弱项，毕竟 GitHub Copilot 可以做到 ~300ms 内的响应速度。所以，我们更多的探索是在：如何通过其他项来弥补模型的差距？

根据我们的算力，以及不同的模型场景，我们所能提供的

响应速度有限的 AI 增强编码：AutoDev

在缺乏足够 GPU 资源的情况下，即在你不能提供足够快的模型响应速度，我们探索的一些合适的模式：

• 强相关上下文，生成高质量代码。通过构建强相关的上下文，生成质量更高的上下文。Copilot 采用的是相似式搜索的上下文，因此在生成构建函数、测试等场景效果不好。于是 AutoDev 采用了静态代码分析的相关上下文，构建更好质量的上下文，以生成更高质量的代码和测试等。
• 高价值点探索与赋能。如结合 CoUnit 作为扩展服务器，将内部的文档作为知识的一部分，与当前代码相关联。诸如可以生成特定内部框架下的代码。
• 自定义 AI 动作与交互。IDE 中自带代码相关的上下文，以在团队认为的高价值场景上，借助 AI 来提效，诸如各类数据转换、遗留系统迁移等。

为此，我们相信在 IDE 中的体验可以带到其他软件研发场景，诸如于需求编写、测试用例等等。

AI 全方面增强创作体验：Studio B3

在经过了 RLHF 之后，各个主要的模型，在写作这一件事上，并没有特别大的差异，只是 50 分和 100 分的区别。不过受限于语料的原因，有些模型写出来的内容还是一言难尽。所以在 Studio B3 中，我们探索的是，如何从零打造 AI 原生的工具：

• AI 增强人类的交互体验。即探索人们是如何完成日常工作的，再结合 AI 来增强人类，让人类来做主要的决策。
• 集成日常活动。诸如于资料检查、互联网搜索，工具集成。
• 准一线、二线模型的探索。在 AI 应用开发上，我的观点一直是：优先使用最好的大模型探索可行性，再考虑结合开源模型运行微调。在有足够的数据、算力和人力时，可以结合已有语料进行基于基础模型的训练。

我们计划将 Studio B3 作为日常文档、需求文档、测试用例的编辑器，所以考虑的几乎是与 AutoDev 相似的背景下。

模型能力：一个够用，两个刚好，三个最佳。

只要我们打开看开发人员、业务人员的日常活动，你会发现完成他的工作 —— 不论是编码，还是编写需求，都需要一系列的子任务支撑。

诸如 JetBrains 的《2023 开发者生态系统现状》中的：”您使用以下现有 AI 助手功能进行编码的频率如何？“一节所介绍的：

（PS：我相信由于 ChatGPT 在国外是免费注册的，由 GitHub Copilot 是需要收费的，也是一小小小部分原因）

考虑一下，为了完成上面的一系列子任务，我们需要几个模型？

工具分析：GitHub Copilot 与 JetBrains AI Assistant

所以，要实现类似于 GitHub Copilot 这样的工具，需要用几个模型？答案是 2~3 个：

• 代码补全：OpenAI Codex 模型。
• 代码问答：OpenAI ChatGPT 3.5 / ChatGPT 4.0.
• （不确定）Embedding 模型：没有证据，我猜应该是打包在 agent 中，否则在没有打包 TreeSitter 的情况下，体积可以达到 40~50 M。

而在 JetBrains IDE 里，由于本身就是一个 IDE，所以存在的模型就更多了：

• 本地向量化模型。即可以做 Search Everywhere 的增强，也可以做其他场景的使用。
• OpenAI 问答模型。这就是为什么 AI Assistant 不能在国内使用的一个原因。
• 本地单行代码补全模型。离线模型，以提供不同语言的 full-line 支持。
• 云端代码补全模型。同上
• 拼写检查模型。

所以，取决于不同的场景，我们需要结合多种 ML 模型来增强人类。

AI 工具模型：三个最好

而从我们的两个沉浸性编辑器（代码编辑器 + 文本编辑器）的探索和落地来看，在两个场景上，为了达到最好的效果，需要三个模型：

• 高响应速度的补全大语言模型。我们需要在质量与速度之间，找到更好的平衡点，以实现速度优先。
• 易于结合 RAG 的高质量大语言模型。使用质量最好的模型，以能结合 Prompt、RAG 等，实现与用户的对话。
• 可选的本地向量化模型。本地意味着，使用 CPU 就能完成计算，以便直接与用户本地的语料相结合，从而相对减少数据风险。

对于开发人员的日常来说，理解代码也是工作的重要一项 —— 并非所有的代码都是自己写的。哪怕是自己写的，半年后也会忘记的 —— 比如我。

AI 原生应用工程化落地小结

现在，让我们回到正题上，结合上述的几个点，做一些小结。

观点 1 ：别指望 AI 一次生成，生成式 AI 提供的是全面辅助

其实不论是文本生成，还是代码生成，都涉及到生成式 AI 的能力问题：

1. 用户无法提供所有上下文给模型。既然能提供，提供的成本往往过高（大于 AI 生成的时间）
2. 模型无法理解你提供的所有上下文。

两个因素的共同作用之下，常用的一个衡量指标是：AI 一次生成的内容，用户能接受多少。而如果模型的能力不行时，则接受率会下降。而由于 AI 模型是需要持续反馈的，所以让更多的人使用 AI，会有限于反馈环的建立。

特别是，开源模型或者国内的模型在当前（2023 年年底），并不具备一线大语言模型（ChatGPT 3.5）的上下文理解能力。

观点 2：多模型共同协助，解决不同子任务的问题

如果你也用过 GitHub Copilot 来编写文档里，你会发现：它在生成一些概念性的内容时非常有用。当然了，他在生成一些废话进也特别有用。但是，你不能指望 GitHub Copilot（补全模型）能生成一个有用的大纲，但是 Copilot X 就能辅助你生成这个可用的大纲。

所以，我们需要区分在不同场景下，到底需要的是什么模型。不同场景下，对于性价比等等的要求是不同的。

在早先，我会使用 OpenAI + AutoDev 来生成测试文件的第一个规范化的测试用例，然后 GitHub Copilot 就可以根据规范化的测试用例，以及我们的注释 prompt，生成后续的其它测试。

观点 3：与工具、上下文相结合，持续微调模型

我相信这一点大家都已经很了解了。但是，我们想再强调的一点的是，对于不同的技术方案而言，这并不是一件容易的事。

回到 AutoDev 的场景，AutoDev 是通过静态代码分析（Intellij IDE 插件）来构建上下文的，即通过绑定 IDE，来追求准确性。而其它的 AI 辅助工具则是，通过失去准确性，来构建跨编辑器通用架构（在 JetBrains、VS Code 等编辑器上）。

简单来说，在 AutoDev 生成测试时，是通过对一个 Controller 进行静态分析，将输入和输出作为上下文，以生成准确的 API 数据。而在其它通用编辑器里，则是通过相似上下文，这时往往拿不到输入和输出作为上下文，也就只能凭空捏造数据。

生成式 AI 能提升个体的效率，但是它并不是银弹。我们不应期望 AI 一次生成所有内容，而是提供全方位的辅助。