虽然 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 的能力问题：
用户无法提供所有上下文给模型。既然能提供，提供的成本往往过高（大于 AI 生成的时间）
模型无法理解你提供的所有上下文。
两个因素的共同作用之下，常用的一个衡量指标是：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 一次生成所有内容，而是提供全方位的辅助。
文章来源：https://www.toymoban.com/news/detail-752538.html
（由 Microsoft Designer 根据标题生成）
文章来源地址https://www.toymoban.com/news/detail-752538.html
到了这里，关于生成式 AI 应用落地小结：高估的模型能力，低估的工程实施的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
