LLM 应用程序的新兴架构

大型语言模型是一个新的软件构建的强大原语。但是由于它们非常新，其行为也不同于普通的计算资源，所以它们的用法有时候并不是那么容易搞清楚。

在这篇文章中，我们将分享一个新兴的 LLM 应用程序技术栈的参考架构，其中包括在 AI 初创企业和成熟的科技公司中最常见的系统、工具和设计模式。该技术栈还处于非常早期的阶段，可能会随着底层技术的发展而发生根本性的变化，但我们希望这个参考架构能够为正在使用 LLM 的开发人员带来帮助。

技术栈简介

下图是当前 LLM 应用程序技术栈的概览：

以下是相关项目的链接清单，方便读者朋友们快速查阅：

使用 LLM 进行构建的方法有许多，包括从头开始训练模型、对开源模型做一些微调或者使用托管 API。本文要介绍的技术栈是基于上下文学习的。大多数开发人员都是从这个设计模式入手的（现在只有基础模型才有可能）。

下一节将简单介绍下这种模式；有经验的 LLM 开发人员可以跳过。

设计模式：上下文学习

上下文学习的核心思想是使用现成的 LLM（即不做任何调整优化），然后通过私有的“上下文”数据进行巧妙地提示和调节，从而控制它们的行为。

例如你正在构建一个聊天机器人，用于回答和一系列法律文档相关的问题。最简单的方法是将所有文档粘贴到 ChatGPT 或 GPT-4 中，然后询问有关这些文档的问题。如果数据集非常小，这是可以的，但这种方法无法扩展。最大的 GPT-4 模型也只能处理大约 50 页的输入文本，而且当接近这个限制（上下文窗口）时，它的性能（通过推理时间和准确性来度量）会严重下降。

上下文学习用一个巧妙的技巧解决了这个问题：它不会在每个 LLM 提示中都发送所有文档，而是只发送少数相关度最高的文档，而哪些文档相关度最高是在 LLM 的帮助下确定的。

概括地讲，这个工作流可以分为三个阶段：

• 数据预处理/嵌入：该阶段包括存储稍后用于检索的私有数据（本例中的法律文档）。通常，文档被分割成块，通过嵌入模型进行传递，然后存储在名为向量数据库的专用数据库中。
• 提示构建/检索：当用户提交查询（本例中的法律问题）时，应用程序构建一系列提示并提交给语言模型。通常，编译后的提示会与开发人员硬编码的提示模板相结合；称为 few-shot examples 的有效输出样本；从外部 API 检索到的其他一些必要的信息；还有从向量数据库中检索出的一组相关文件。
• 提示执行/推理：编译完提示后，将它们提交给预训练的 LLM 进行推理——包括专有模型 API 以及开源或自训练模型。有些开发人员还在这个阶段中添加了日志记录、缓存和验证等。

看起来，这个过程的工作量很大，但通常这比训练或微调 LLM 本身要简单。上下文学习不需要一个专门的机器学习工程团队，你也无需托管自己的基础设施或从 OpenAI 购买昂贵的专用实例。这种模式有效地将人工智能问题简化一个大多数初创公司和大公司都知道如何解决的数据工程问题。在数据集相对较小的情况下，它的性能往往也优于微调——因为特定的信息片段要在训练集中至少出现 10 次，LLM 才能借助微调记住它——并且可以近乎实时地吸纳新数据。

关于上下文学习，一个最大的问题是：如果我们只是通过改变底层模型来扩大上下文窗口的话，会发生什么？实际上，这是可能的，而且是一个活跃的研究领域（感兴趣的话，可以看下这篇关于Hyena的论文或这篇最近发表的文章）。但这里需要做一些权衡——主要是推理的成本和时间随提示长度的增加呈非线性增长。如今，对于许多应用程序来说，即使是线性增长（理论上最好的结果），成本也是过高的。以目前的 API 费率计算，超过 1 万页的单个 GPT-4 查询将花费数百美元。因此，别指望基于扩展上下文窗口对技术栈进行大规模地更改。关于这一点，下文会进一步的讨论。

如果想更深入地了解上下文学习，AI canon提供了许多不错的资源（特别是“LLM 应用实践指南”这一部分）。在本文接下来的部分中，我们将顺着上面的工作流，逐阶段地看下这个参考技术栈。

数据预处理/嵌入

 LLM 应用程序的上下文数据包括文本文档、PDF，甚至是结构化的格式，如 CSV 或 SQL 表。在我们交谈过的开发人员中间，这些数据的加载和转换解决方案存在着很大的差异。大多数人使用传统的 ETL 工具，如 Databricks 或 Airflow。有些人还使用编排框架中内置的文档加载器，比如 LangChain（基于 Unstructured）和 LlamaIndex（基于 Llama Hub）。不过我们认为，技术栈的这个部分相对还不够成熟，专门为 LLM 应用程序构建的数据复制解决方案还有机会。

对于嵌入，大多数开发人员都在使用 OpenAI API，特别是 text- embeddings -ada-002 模型。它的用法很简单（特别是如果你已经在使用其他 OpenAI API），结果也相当不错，并且越来越便宜。有些比较大的企业也在研究 Cohere（它专注于嵌入这个相对狭窄的领域，并且在某些场景下提供了更好的性能）。对于喜欢开源的开发人员来说，来自 hug Face 的 Sentence Transformers 库是一个标准。也可以针对不同的用例创建不同类型的嵌入；这是一个小众的做法，但是一个有前途的研究领域。

从系统的角度来看，预处理管道最重要的组成部分是向量数据库，它负责高效地存储、对比和检索多达数十亿个嵌入（即向量）。市场上最常见的选择是 Pinecone。人们默认就会选择它，因为它完全是云托管的，上手很容易并且提供了许多大型企业在生产环境中需要的特性（例如，大规模情况下的良好性能、SSO 和正常运行时间 SLA）。

不过，可供选择的向量数据库还是不少的，尤其是下面这些：

• 像 Weaviate、Vespa 和 Qdrant 这样的开源系统：它们通常都提供了出色的单节点性能，并且可以针对特定的应用程序进行定制。因此，在喜欢构建定制平台的经验丰富的 AI 团队中，它们很受欢迎。
• 像 Chroma 和 Faiss 这样的本地向量管理库：它们提供了很好的开发体验，并且很容易应用于小型应用和开发实验。在规模比较大的时候，它们可能无法完全代替完备的数据库。
• 像 pgvector 这样的 OLTP 扩展：对于那些熟悉数据库并试图添加 Postgres 的开发人员，或者从单个云提供商那里购买了大部分数据基础设施的企业来说，这是一个很好的向量支持解决方案。目前还不清楚，从长远来看，将向量和标量工作负载紧密耦合是否有意义。

大多数开源向量数据库公司都在开发云产品。我们的研究表明，面对各种各样可能的用例，要想在云中实现强大的性能非常困难。因此在短期内，这个选项集可能不会有太大的变化，但长远来看可能会有。问题的关键是向量数据库是否会像 OLTP 和 OLAP 一样，围绕一两个流行的系统进行整合。

另一个悬而未决的问题是，随着大多数模型可用上下文窗口的扩大，嵌入和向量数据库将如何发展。人们很容易会说，嵌入将变得不那么重要，因为上下文数据可以直接放到提示中。然而，专家对这个话题的反馈却表明，随着时间的推移，嵌入管道可能会变得越来越重要。大型上下文窗口是一种强大的工具，但它们的计算成本也很大。因此，当务之急是如何有效地利用它们。我们可能会看到，不同类型的嵌入模型开始流行，并直接针对模型相关性进行训练，而向量数据库在设计时就已经考虑到要利用这一点。

提示构建/检索

提示 LLM 并整合上下文数据的策略正变得越来越复杂，而且作为产品差异化的来源，也变得越来越重要。在启动新项目时，大多数开发人员都是尝试一些简单的提示，包括直接指令（零提示）或一些示例输出（小样本提示）。通常，这些提示可以给出很好的结果，但无法达到生产部署所需的准确性水平。

按照设计，提示的下一个层次是基于一些事实来源创建模型响应，并提供模型训练时未涉及的外部上下文。《LLM提示工程指南》列出了超过 12 种更为高级的提示策略，包括思维链、自我一致性、生成知识、思想树、定向刺激等等。我们还可以搭配使用不同的策略，为不同的 LLM 用例提供支持，如文档问答、聊天机器人等。

这就是 LangChain 和 LlamaIndex 等编排框架的用途所在。它们抽象了提示链的诸多细节；与外部 API 交互（包括确定何时需要调用 API）；从向量数据库中检索上下文数据；跨多个 LLM 调用维护内存。它们还为上面提到的许多常见的应用程序提供了模板。它们的输出是提交给语言模型的一个或一系列提示。在希望从零开发 LLM 应用程序的爱好者和初创公司中，这些框架的应用非常广泛，而 LangChain 是其中的佼佼者。

目前，LangChain 还是一个相对比较新的项目（当前版本 0.0.201），但我们已经看到，已经有人开始用它构建生产应用。有些开发人员，特别是 LLM 的早期采用者，更喜欢在生产环境中使用原始 Python，为的是消除额外的依赖。但我们预计，随着时间的推移，在大多数用例中，这种 DIY 方法会逐步减少，就像传统的 Web 应用技术栈一样。

眼尖的读者会注意到，编排框中有一个看似奇怪的条目：ChatGPT。通常来说，ChatGPT 是一个应用程序，而不是开发工具。但它也提供了可供访问的 API。而且，如果你再仔细看一下，就会发现它的功能与其他编排框架相同，例如：抽象掉对定制提示的需求；维护状态；通过插件、API 或其他数据源检索上下文数据。虽然与这里列出的其他工具之间不存在直接的竞争关系，但 ChatGPT 可能会被看作是一种替代的解决方案，并且它最终可能成为一种简单可行的提示构建替代方案。

提示执行/推理

如今，OpenAI 是语言模型的领导者。在开始构建新的 LLM 应用程序时，我们交谈过的几乎所有开发者都在使用 OpenAI API，通常使用 gpt-4 或 gpt-4-32k 模型。它们提供了理想的解决方案，并且易于使用，因为其输入域非常广，通常不需要微调或自托管。

当项目进入生产阶段并开始规模化应用时，可选的范围就会更大，常见的选项包括：

• 切换到 gpt-3.5-turbo：成本是GPT-4的大约五十分之一，而且速度也快很多。许多应用程序并不需要 GPT-4 级别的准确性，但确实需要低延迟推理以及为免费用户提供具有成本效益的支持。
• 测试其他专有供应商的模型（特别是 Anthropic 的 Claude 模型）：Claude 提供了快速推理，GPT-3.5 级别的准确性，为大客户提供的更多的定制选项，以及高达 100k 的上下文窗口（尽管我们发现，准确性会随着输入长度的增加而降低）。
• 将一些请求提供给开源模型：在搜索或聊天等大量的 B2C 用例中这尤其有效，因为这些用例的查询其复杂性有很大的差异，需要以较低的成本为免费用户提供服务。通常，这要与微调开源基础模型结合才最有意义。本文中我们不会深入讨论那个工具栈，但是像 Databricks、Anyscale、Mosaic、Modal 和 RunPod 这样的平台为越来越多的工程团队所采用。可以用于开源模型的推理选项多种多样，包括来自 hug Face 和 Replicate 的简单 API 接口；来自主要云提供商的原始计算资源；以及像上面列出的那些更为个性化的云产品。

目前，与专有产品相比，开源模型还是落后一些，但差距正在缩小。Meta 的 LLaMa 模型为开源模型的准确性设定了新的标准，并催生了一系列的变体。由于 LLaMa 仅授权用于研究用途，所以有许多新的供应商已经着手训练替代的基础模型（如 Together、Mosaic、Falcon、Mistral）。Meta 也在探讨一个真正开源的 LLaMa 2 版本。

当开源 LLM 的准确性达到与 GPT-3.5 相当的水平时，我们希望可以看到文本的 Stable Diffusion 时刻，包括大规模的实验、共享和微调模型的生产应用。像 Replicate 这样的托管公司已经在补充工具，让软件开发人员可以更轻松地使用这些模型。越来越多的开发人员相信，小型的微调模型可以在特定的用例中达到更高的准备性。

与我们交谈过的大多数开发人员都还没有深入研究 LLM 的操作工具。缓存相对比较常见（通常基于 Redis），因为它可以减少应用程序的响应时间和成本。像 Weights&Biases 和 MLflow（从传统机器学习移植而来）或 PromptLayer 和 Helicone（专门为 LLM 构建）这样的工具应用也很广泛。它们可以记录、跟踪和评估 LLM 输出，通常是为了改进提示构建、优化管道或选择模型。还有一些正在开发中的新工具，用于验证 LLM 输出（例如 Guardrails）或检测提示注入攻击（如 Rebuff）。这些操作工具中的大多数都鼓励使用它们提供的 Python 客户端来进行 LLM 调用，因此，看这些解决方案如何随着时间的推移和谐共存会非常有趣。

最后，LLM 应用程序的静态部分（即除了模型之外的所有内容）也需要托管在某个地方。我们看到，到目前为止，最常见的解决方案是像 Vercel 或主流云提供商这样的标准选项。不过，有两种新的类型正在兴起。像 Steamship 这样的初创公司就为 LLM 应用程序提供了端到端托管，包括编排（LangChain）、多租户数据上下文、异步任务、向量存储和密钥管理。Anyscale 和 Modal 等公司允许开发人员在一个地方托管模型和 Python 代码。

代理呢？

在这个参考架构缺少的组件中，最重要的是 AI 代理框架。AutoGPT被描述为“一个使 GPT-4 完全自主的实验性开源尝试”。今年春天，它成了历史上发展最快的Github存储库。实际上，现如今，每个人工智能项目或初创公司都使用了某种形式的代理。

说到代理的潜力，与我们交谈过的大多数开发人员都感到无比兴奋。本文介绍的上下文学习模式可以有效地解决幻觉和数据新鲜度问题，从而更好地支持内容生成任务。另一方面，代理赋予 AI 应用一系列全新的功能：解决复杂的问题，对外部世界做出反应，部署后从经验中学习。为此，它们会搭配高级推理/规划、工具使用和记忆/递归/自我反省。

因此，代理有可能成为 LLM 应用程序架构的核心部分（如果你相信递归自我完善，它们甚至可以接管整个技术栈）。现在，像 LangChain 这样的框架已经包含了一些代理概念。问题只有一个：代理还没有真正发挥作用。目前，大多数代理框架仍处于概念验证阶段——能够进行令人难以置信的演示，但还无法可靠地重复完成任务。我们正在密切关注，在可见的将来，它们会如何发展。

未来展望

预训练的人工智能模型代表了自互联网出现以来软件领域最重要的架构变化。它们使个人开发人员能够在几天内构建出令人难以置信的人工智能应用程序，而且可以超过大型团队花费数月时间构建的有监督的机器学习项目。本文列出的工具和模式只能算是集成 LLM 的起点，而不是最终状态。

原文链接：

https://a16z.com/2023/06/20/emerging-architectures-for-llm-applications/