本文探讨了大语言模型（LLM）应用的新兴架构，提供了一种参考架构，展示了 AI 初创公司和技术公司常用的系统、工具和设计模式。文章主要讨论了如何利用上下文学习模式，通过巧妙的提示和私有“上下文”数据来控制 LLM 的行为，而无需进行模型微调。

➡️ 上下文学习设计模式

  1. 数据预处理/嵌入：

    • 将私有数据（如法律文件）存储起来，通常将文件分块，经过嵌入模型处理后存储在向量数据库中。

  2. 提示构建/检索：

    • 当用户提交查询时，应用程序构建一系列提示提交给语言模型，提示通常包括开发者硬编码的模板、示例输出、从外部 API 检索的信息以及从向量数据库检索的相关文件。

  3. 提示执行/推理：

    • 提示被提交给预训练的 LLM 进行推理，可能会添加操作系统如日志记录、缓存和验证。

➡️ 数据预处理与嵌入

  • 向量数据库：如 Pinecone、Weaviate、Vespa 和 Qdrant 等，用于高效存储、比较和检索嵌入。
  • 嵌入模型：如 OpenAI 的 text-embedding-ada-002 模型、Cohere 和 Hugging Face 的 Sentence Transformers。

➡️ 提示构建与检索

  • 提示策略：从简单的零样本提示和少样本提示到复杂的链式思维、自我一致性等高级策略。
  • 编排框架：如 LangChain 和 LlamaIndex，用于抽象提示链、接口外部 API 和检索上下文数据。

➡️ 推理与操作

  • 主流语言模型：OpenAI 的 GPT-4 和 GPT-3.5-turbo，Anthropic 的 Claude 模型等。
  • 开源模型：如 Meta 的 LLaMa 模型及其变体。
  • 操作工具：如缓存（基于 Redis）、日志跟踪工具（Weights & Biases、MLflow、PromptLayer 和 Helicone）以及验证工具（Guardrails 和 Rebuff）。

➡️ 代理框架

  • AI 代理：如 AutoGPT，尽管目前大多处于概念验证阶段，但它们具有解决复杂问题、在外部世界中采取行动和从经验中学习的潜力。

➡️ 未来展望

  • 预训练的 AI 模型是自互联网以来软件领域最重要的架构变革，使得个体开发者能够在短时间内构建出超越传统监督学习项目的 AI 应用。本文提出的工具和模式可能只是起点，未来随着技术的发展会有更多的更新和优化。

大语言模型应用的新兴架构

大语言模型 (Large Language Models, LLMs) 是构建软件的一种强大新基础构件。但由于它们非常新颖且行为与普通计算资源截然不同，如何使用它们并不总是显而易见。

在这篇文章中，我们分享了一个新兴的大语言模型应用堆栈的参考架构。它展示了我们在 AI 初创公司和先进科技公司中见到的最常见的系统、工具和设计模式。这个堆栈仍处于非常早期阶段，可能会随着底层技术的发展而发生重大变化，但我们希望它能为现在开发大语言模型的开发者提供有用的参考。

这项工作基于与 AI 初创公司创始人和工程师的对话。我们特别感谢以下人员的意见：Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei Zaharia 和 Jared Zoneraich。感谢你们的帮助！

注意：这些组件的更全面和动态的版本可在我们 GitHub 上的 LLM App Stack repo 找到。

堆栈

这是我们目前对 LLM 应用堆栈的看法（点击放大）：

以下是每个项目的快速参考链接列表：

有许多不同的方法可以使用大语言模型，包括从头训练模型、微调开源模型或使用托管 API。我们展示的这个堆栈基于 上下文学习 (in-context learning)，这是我们看到大多数开发者开始使用的设计模式（现在只有基础模型才可能实现）。

下一部分简要解释了这一模式；有经验的大语言模型开发者可以跳过这一部分。

设计模式：上下文学习

上下文学习的核心思想是使用现成的大语言模型（即无需任何微调），然后通过巧妙的提示和私有的“上下文”数据来控制它们的行为。

例如，假设你在构建一个聊天机器人来回答关于一组法律文件的问题。采用一个简单的方法，你可以将所有文档粘贴到 ChatGPT 或 GPT-4 提示中，然后在末尾问一个问题。这可能适用于非常小的数据集，但它无法扩展。最大的 GPT-4 模型只能处理约 50 页的输入文本，并且随着接近这个限制（称为上下文窗口），性能（通过推理时间和准确性测量）会严重下降。

上下文学习通过一个巧妙的技巧解决了这个问题：它不再每次发送所有文档，而是只发送几份最相关的文档。这些最相关的文档是通过……你猜对了……大语言模型来确定的。

在非常高的层次上，工作流程可以分为三个阶段：

  • 数据预处理/嵌入：此阶段涉及存储私有数据（在我们的例子中为法律文件）以便稍后检索。通常，文档被分成块，通过一个 embedding 模型，然后存储在一个专门的数据库中，称为向量数据库。
  • 提示构建/检索：当用户提交查询（在本例中为法律问题）时，应用程序构建一系列提示提交给语言模型。编译的提示通常结合了由开发者硬编码的提示模板；有效输出示例（称为少样本示例）；从外部 API 检索到的任何必要信息；以及从向量数据库中检索到的一组相关文档。
  • 提示执行/推理：一旦提示被编译好，它们会提交给预训练的大语言模型进行推理，包括专有模型 API 和开源或自训练模型。有些开发者还会在此阶段添加操作系统，如日志记录、缓存和验证。

这看起来工作量很大，但通常比训练或微调大语言模型要容易得多。你不需要一个专门的机器学习工程师团队来进行上下文学习。你也不需要托管自己的基础设施或从 OpenAI 购买昂贵的专用实例。这个模式有效地将一个 AI 问题简化为一个大多数初创公司和大公司已经知道如何解决的数据工程问题。它在相对较小的数据集上也往往表现优于微调，因为特定信息需要在训练集中出现至少约 10 次，才能通过微调被大语言模型记住，并且可以近乎实时地整合新数据。

围绕上下文学习的最大问题之一是：如果我们只是更改底层模型以增加上下文窗口会怎样？这确实是可能的，并且是一个活跃的研究领域（例如，参见Hyena 论文或最近的帖子）。但这带来了许多权衡——主要是推理成本和时间随着提示长度的二次方比例增长。今天，即使是线性扩展（最好的理论结果）对于许多应用来说也是成本过高的。在当前的 API 费率下，单个 GPT-4 查询处理 10,000 页将花费数百美元。因此，我们不期望基于扩展的上下文窗口对堆栈进行大规模的更改，但我们会在文章主体中对此做更多评论。

如果你想深入了解上下文学习，AI 规范中有许多很好的资源（尤其是“构建大语言模型的实用指南”部分）。在这篇文章的剩余部分中，我们将以上述工作流程为指南，逐步介绍参考堆栈。

数据处理/嵌入

LLM 应用的上下文数据包括文本文档、PDF 甚至结构化格式如 CSV 或 SQL 表格。对于这些数据的加载和转换解决方案在我们交谈的开发者中差异很大。大多数使用传统的 ETL 工具如 Databricks 或 Airflow。一些人还使用内置于编排框架中的文档加载器，如 LangChain（由 Unstructured 提供支持）和 LlamaIndex（由 Llama Hub 提供支持）。我们认为这一堆栈的这一部分相对不发达，LLM 应用的专用数据复制解决方案是一个机会。

对于embedding，大多数开发者使用 OpenAI API，特别是text-embedding-ada-002模型。它易于使用（特别是如果你已经在使用其他 OpenAI API），结果相当不错，并且变得越来越便宜。一些大型企业也在探索 Cohere，它专注于 embedding，在某些情况下性能更好。对于喜欢开源的开发者来说，Hugging Face 的 Sentence Transformers 库是一个标准。也可以创建不同类型的 embedding以适应不同的用例；这是一个当今的小众实践，但却是一个有前景的研究领域。

从系统的角度来看，预处理管道中最重要的部分是向量数据库。它负责高效存储、比较和检索多达数十亿个 embedding（即向量）。我们在市场上看到的最常见选择是 Pinecone。它是默认选择，因为它是完全云托管的——因此很容易上手——并且具有大型企业在生产中所需的许多功能（例如，规模良好的性能、单点登录和正常运行时间服务级别协议）。

然而，有大量的向量数据库可供选择。值得注意的是：

  • 开源系统如 Weaviate、Vespa 和 Qdrant：它们通常提供出色的单节点性能，并且可以为特定应用量身定制，因此在喜欢构建定制平台的经验丰富的 AI 团队中很受欢迎。
  • 本地向量管理库如 Chroma 和 Faiss：它们具有出色的开发者体验，并且易于为小型应用和开发实验启动。它们并不一定能替代大规模的完整数据库。
  • 如 pgvector 等 OLTP 扩展：对于那些看到每个数据库形状的洞都试图插入 Postgres 的开发者——或者那些从单一云提供商购买大部分数据基础设施的企业——这是一个很好的向量支持解决方案。从长远来看，将向量和标量工作负载紧密耦合是否有意义尚不明确。

展望未来，大多数开源向量数据库公司正在开发云产品。我们的研究表明，在云中实现强大的性能，跨越广泛的可能用例设计空间是一个非常困难的问题。因此，选项集在短期内可能不会大规模改变，但从长期来看可能会改变。关键问题是向量数据库是否会类似于它们的 OLTP 和 OLAP 同类产品，围绕一个或两个流行系统整合。

另一个悬而未决的问题是，随着大多数模型可用的上下文窗口的增长，embedding 和向量数据库将如何发展。说 embedding 会变得不那么相关是很诱人的，因为上下文数据可以直接放入提示中。然而，专家对这一主题的反馈表明相反的观点——embedding 管道随着时间的推移可能会变得更加重要。大型上下文窗口是一种强大的工具，但它们也需要显著的计算成本。因此，如何高效使用它们成为一个优先事项。我们可能会开始看到不同类型的 embedding 模型变得流行，直接为模型相关性进行训练，并且向量数据库设计用于实现并利用这一点。

Prompt 构建/检索

提示大语言模型和整合上下文数据的策略变得越来越复杂——并且越来越重要，成为产品差异化的来源。大多数开发者在启动新项目时通过实验简单的提示开始，这些提示由直接指令（零样本提示）或可能的一些示例输出（少样本提示）组成。这些提示通常会产生良好的结果，但在准确性水平上不足以满足生产部署的要求。

下一层次的提示技巧旨在使模型响应扎根于某些真实来源并提供模型未训练的外部上下文。提示工程指南记录了不少于 12 种更高级的提示策略，包括链式思维、自我一致性、生成知识、思维树、方向性刺激等。可以将这些策略结合使用，以支持不同的 LLM 用例，如文档问答、聊天机器人等。

这是编排框架如 LangChain 和 LlamaIndex 大显身手的地方。它们抽象掉了提示链接的许多细节；与外部 API 的接口（包括确定何时需要 API 调用）；从向量数据库中检索上下文数据；并在多个大语言模型调用之间保持记忆。它们还提供了许多上述常见应用的模板。它们的输出是一个提示，或一系列提示，提交给语言模型。这些框架在业余爱好者和初创公司中广泛使用，后者希望快速启动一个应用程序，而 LangChain 是其中的佼佼者。

LangChain 仍然是一个相对较新的项目（目前版本为 0.0.201），但我们已经开始看到使用它构建的应用程序进入生产。一些开发者，尤其是大语言模型的早期采用者，更喜欢在生产中切换到原始 Python 以消除一个额外的依赖项。但我们预计这种 DIY 方法会随着时间的推移而减少，就像传统的 web 应用堆栈一样。

敏锐的读者会注意到在编排框中有一个看似奇怪的条目：ChatGPT。在其正常状态下，ChatGPT 是一个应用程序，而不是开发者工具。但它也可以作为 API 访问。而且，如果你眯着眼睛看，它执行的某些功能与其他编排框架相同，例如：抽象掉定制提示的需要；保持状态；通过插件、API 或其他来源检索上下文数据。虽然它不是此处列出的其他工具的直接竞争对手，但 ChatGPT 可以被视为一种替代解决方案，并且它最终可能成为提示构建的简单替代方案。

Prompt 执行/推理

今天，OpenAI 是语言模型的领导者。我们交谈的几乎每位开发者都使用 OpenAI API 启动新的 LLM 应用，通常使用gpt-4或gpt-4-32k模型。这为应用性能提供了最佳情景，并且易于使用，因为它适用于广泛的输入域，通常无需微调或自托管。

当项目投入生产并开始扩展时，会有更广泛的选择。我们听到的一些常见选择包括：

  • 切换到gpt-3.5-turbo：它比 GPT-4 便宜约50 倍，并且比 GPT-4 快得多。许多应用程序不需要 GPT-4 级别的准确性，但需要低延迟推理和对免费用户的成本有效支持。
  • 尝试其他专有供应商（特别是 Anthropic 的 Claude 模型）：Claude 提供快速推理、GPT-3.5 级别的准确性、更多的大客户定制选项，以及高达 100k 的上下文窗口（尽管我们发现随着输入长度的增加，准确性会降低）。
  • 对部分请求进行开源模型的分流：在高流量的 B2C 用例中，如搜索或聊天，这特别有效，因为查询复杂度差异很大，需要便宜地为免费用户提供服务。
    • 这通常与微调开源基础模型结合使用最有意义。我们在本文中没有深入探讨该工具栈，但像 Databricks、Anyscale、Mosaic、Modal 和 RunPod 等平台正被越来越多的工程团队使用。
    • 有多种推理选项可用于开源模型，包括 Hugging Face 和 Replicate 提供的简单 API 接口；主要云提供商的原始计算资源；以及上面列出的更有见地的云产品。

开源模型目前落后于专有产品，但差距正在缩小。Meta 的 LLaMa 模型为开源准确性设立了新标杆，并引发了一系列变体。由于 LLaMa 仅被许可用于研究用途，一些新提供商已经介入训练替代基础模型（如 Together、Mosaic、Falcon、Mistral）。Meta 也在辩论是否真正开源发布 LLaMa 2。

当（不是如果）开源大语言模型达到与 GPT-3.5 相当的准确性时，我们预计会看到类似于文本领域的 Stable Diffusion 时刻——包括大规模的实验、共享和微调模型的生产化。像 Replicate 这样的托管公司已经在增加工具，以使这些模型更易于软件开发者使用。开发者中越来越普遍的观点是，较小的微调模型可以在狭窄的用例中达到最先进的准确性。

我们交谈的大多数开发者还没有深入研究大语言模型的操作工具。缓存相对常见——通常基于 Redis——因为它改善了应用响应时间和成本。像 Weights & Biases 和 MLflow（移植自传统机器学习）或 PromptLayer 和 Helicone（专为大语言模型设计）这样的工具也被广泛使用。它们可以记录、跟踪和评估大语言模型的输出，通常用于改进提示构建、调优管道或选择模型。还开发了一些新工具来验证大语言模型输出（如 Guardrails）或检测提示注入攻击（如 Rebuff）。大多数这些操作工具鼓励使用它们自己的 Python 客户端进行大语言模型调用，因此看看这些解决方案如何共存将很有趣。

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

智能体

这个参考架构中缺少的最重要组件是AI 智能体框架。AutoGPT，被描述为“一种实验性开源尝试，使 GPT-4 完全自主”，是这个春天增长最快的 GitHub 仓库，几乎今天的每个 AI 项目或初创公司都以某种形式包括智能体。

我们交谈的大多数开发者对智能体的潜力感到非常兴奋。我们在本文中描述的上下文学习模式在解决幻觉和数据新鲜度问题方面非常有效，以更好地支持内容生成任务。另一方面，智能体为 AI 应用程序提供了一套全新的能力：解决复杂问题，作用于外部世界，并在部署后从经验中学习。它们通过高级推理/规划、工具使用和记忆/递归/自我反思的组合来实现这一点。

因此，智能体可能会成为 LLM 应用架构的核心部分（如果你相信递归自我改进，甚至可以接管整个堆栈）。现有框架如 LangChain 已经纳入了一些智能体概念。只有一个问题：智能体还不能真正工作。今天大多数智能体框架处于概念验证阶段——能够进行令人难以置信的演示，但尚未可靠、可重复地完成任务。我们正密切关注它们在不久的将来如何发展。

展望未来

预训练 AI 模型代表了自互联网以来软件中最重要的架构变革。它们使个别开发者能够在几天内构建出色的 AI 应用程序，超过那些由大团队花费数月构建的监督机器学习项目。

我们在这里列出的工具和模式可能是整合 LLM 的起点，而不是终点。随着重大变化（例如，向模型训练的转变）的发生，我们将更新此内容，并在合适的地方发布新的参考架构。如果你有任何反馈或建议，请与我们联系。