a16Z：大模型应用程序的新兴架构

?智源社区日报关注订阅?

本文来自a16z分析，原文链接：

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

在这篇文章中，我们分享了新兴LLM应用程序堆栈的参考架构。它展示了人工智能初创公司和尖端科技公司见过的最常见的系统、工具和设计模式。这个堆栈还很早，随着基础技术的进步，可能会发生重大变化，但我们希望它将成为现在使用LLM的开发人员的有用参考。

这项工作基于与人工智能初创公司创始人和工程师的对话。我们特别依赖以下人员的意见：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、Materi Zaharia和Jared Zoneraich。谢谢你的帮助！

堆栈

以下是我们目前对LLM应用程序堆栈的视图（点击放大）：

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

使用LLM构建有许多不同的方法，包括从头开始训练模型、微调开源模型或使用托管API。我们在这里显示的堆栈是基于上下文学习，这是我们看到大多数开发人员开始的设计模式（现在只有基础模型才有可能）。

下一节简要解释了这种模式；经验丰富的法学硕士开发人员可以跳过这一节。

设计模式：上下文学习

上下文学习的核心思想是使用现成的LLM（即没有任何微调），然后通过对私人“上下文”数据的巧妙提示和调节来控制它们的行为。

例如，假设您正在构建一个聊天机器人来回答有关一组法律文件的问题。采取一种天真的方法，您可以将所有文档粘贴到ChatGPT或GPT-4提示中，然后在最后询问有关它们的问题。这可能适用于非常小的数据集，但它不会扩展。最大的GPT-4模型只能处理约50页的输入文本，当您接近这个称为上下文窗口的极限时，性能（由推理时间和准确性衡量）会严重下降。

上下文学习用一个聪明的技巧解决了这个问题：它不是用每个LLM提示发送所有文档，而是只发送少数最相关的文档。最相关的文件是在……你猜对了……的帮助下确定的……大模型。

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

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

这看起来工作量很大，但通常比替代方案更容易：培训或微调LLM本身。你不需要一个专门的ML工程师团队来进行上下文学习。您也不需要托管自己的基础设施或从OpenAI购买昂贵的专用实例。这种模式有效地将人工智能问题简化为大多数初创企业和大公司已经知道如何解决的数据工程问题。对于相对较小的数据集，它还倾向于优于微调——因为一条特定信息需要在训练集中至少发生约10次，然后LLM才会通过微调记住它——并且可以近乎实时地合并新数据。

关于上下文学习的最大问题之一是：如果我们只是更改底层模型以增加上下文窗口，会发生什么？这确实是可能的，而且这是一个活跃的研究领域（例如，请参阅鬣狗论文或最近的帖子）。但这伴随着一些权衡——主要是推断的成本和时间与提示的长度相等。今天，即使是线性缩放（最佳理论结果）对许多应用来说也是成本高昂的。以当前的API费率计算，超过10,000页的单个GPT-4查询将花费数百美元。因此，我们不期望基于扩展上下文窗口对堆栈进行大规模更改，但我们将在帖子正文中对此进行更多评论。

如果您想深入了解上下文学习，人工智能佳能中有许多很棒的资源（特别是“使用LLM构建的实用指南”部分）。在这篇文章的其余部分，我们将使用上述工作流程作为指南来浏览参考堆栈。

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

对于嵌入，大多数开发人员使用OpenAI API，特别是文本嵌入ada-002模型。它易于使用（特别是如果您已经在使用其他OpenAI API），效果相当好，并且越来越便宜。一些大型企业也在探索Cohere，该公司将产品工作更狭隘地集中在嵌入上，并在某些场景中具有更好的性能。对于喜欢开源的开发人员来说，Hugging Face的句子变形金刚库是一个标准。也可以为不同的用例创建不同类型的嵌入；这是当今的利基实践，但也是一个有前途的研究领域。

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

不过，有大量的矢量数据库可供选择。值得注意的是：

• Weaviate、Vespa和Qdrant等开源系统：它们通常具有出色的单节点性能，并且可以为特定应用程序量身定制，因此它们受到经验丰富的人工智能团队的欢迎，他们更喜欢构建定制平台。
• Chroma和Faiss等本地矢量管理库：它们拥有丰富的开发人员经验，并且易于为小型应用程序和开发实验进行旋转。它们不一定能取代大规模的完整数据库。
• OLTP扩展，如pgvector：对于看到每个数据库形状的漏洞并尝试插入Postgres的开发人员，或从单个云提供商购买大部分数据基础设施的企业，这是一个很好的矢量支持解决方案。从长远来看，紧密耦合向量和标量工作负载是否有意义还不清楚。

展望未来，大多数开源矢量数据库公司正在开发云产品。我们的研究表明，在可能的用例的广泛设计空间中，在云中实现强大的性能是一个非常困难的问题。因此，期权集在短期内可能不会发生巨大变化，但从长远来看可能会发生变化。关键问题是矢量数据库是否会与他们的OLTP和OLAP对应方相似，围绕一两个流行的系统进行整合。

另一个悬而未决的问题是，随着大多数模型可用上下文窗口的增长，嵌入和矢量数据库将如何演变。很容易说嵌入将变得不那么相关，因为上下文数据可以直接放入提示中。然而，专家对这一主题的反馈表明，情况恰恰相反，随着时间的推移，嵌入管道可能会变得更加重要。大型上下文窗口是一个强大的工具，但它们也需要大量的计算成本。因此，有效利用它们成为优先事项。我们可能会开始看到不同类型的嵌入模型变得流行，直接针对模型相关性进行培训，以及旨在启用和利用这一点的矢量数据库。

推动LLM和合并上下文数据的策略正变得越来越复杂，并且作为产品差异化的来源越来越重要。大多数开发人员通过尝试简单的提示来启动新项目，包括直接指令（零射击提示）或可能的一些示例输出（很少射击提示）。这些提示通常给出良好的结果，但低于生产部署所需的准确度。

提示柔术的下一个级别旨在将模型响应置于某种真理来源中，并提供模型未受过训练的外部上下文。及时工程指南目录不少于12（！）更先进的激励策略，包括思想链、自我一致性、生成的知识、思想树、定向刺激等。这些策略也可以结合使用来支持不同的LLM用例，如文档问题回答、聊天机器人等。

这就是像LangChain和LlamaIndex这样的编排框架闪耀的地方。他们抽象了提示链的许多细节；与外部API接口（包括确定何时需要API调用）；从矢量数据库中检索上下文数据；以及维护多个LLM调用的内存。他们还为上述许多常见应用程序提供了模板。他们的输出是提交给语言模型的提示或一系列提示。这些框架在业余爱好者和初创企业中被广泛使用，希望启动应用程序，LangChain是领导者。

LangChain仍然是一个相对较新的项目（目前在0.0.201版本中），但我们已经开始看到用它构建的应用程序进入生产。一些开发人员，特别是LLM的早期采用者，更喜欢在生产中切换到原始Python，以消除额外的依赖性。但我们预计，对于大多数用例来说，这种DIY方法会随着时间的推移而下降，其方式与传统的Web应用程序堆栈类似。

敏锐的读者会注意到编排框中一个看似奇怪的条目：ChatGPT。在其正常化身中，ChatGPT是一个应用程序，而不是一个开发人员工具。但它也可以作为API访问。而且，如果您斜视，它会执行一些与其他编排框架相同的功能，例如：抽象定制提示的需求；维护状态；以及通过插件、API或其他来源检索上下文数据。虽然ChatGPT不是这里列出的其他工具的直接竞争对手，但它可以被认为是一个替代解决方案，它最终可能成为快速构建的可行、简单的替代方案。

今天，OpenAI是语言模型中的领导者。与我们交谈的几乎每个开发人员都使用OpenAI API启动新的LLM应用程序，通常使用gpt-4或gpt-4-32k模型。这为应用程序性能提供了最佳方案，并且易于使用，因为它在广泛的输入域上运行，通常不需要微调或自我托管。

当项目投入生产并开始扩展时，更广泛的选项就会发挥作用。我们听到的一些常见内容包括：

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

开源模型现在落后于专有产品，但差距开始缩小。Meta的LLaMa模型为开源准确性设定了一个新的标准，并启动了一系列变体。自从LLaMa获得仅用于研究的许可以来，一些新的供应商已经介入培训替代基础模型（例如，Together、Mosaic、Falcon、Mistral）。Meta还在讨论LLAMa 2的真正开源版本。

当（不是如果）开源LLM达到与GPT-3.5相当的准确度水平时，我们希望看到文本的稳定扩散时刻——包括大规模实验、共享和微调模型的生产。像Replicate这样的托管公司已经在添加工具，使这些模型更容易被软件开发人员使用。开发人员越来越相信，更小的、微调的模型可以在狭窄的用例中达到最先进的准确性。

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

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

特工呢？

这个参考架构中缺少的最重要的组件是人工智能代理框架。AutoGPT被描述为“使GPT-4完全自主的实验性开源尝试”，是今年春天历史上增长最快的Github回购协议，今天几乎每个人工智能项目或初创公司都包括某种形式的代理。

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

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

展望未来

预先训练的人工智能模型代表了自互联网以来软件中最重要的架构变化。它们使个人开发人员有可能在几天内构建令人难以置信的人工智能应用程序，这些应用程序超过了大型团队花了几个月时间构建的监督机器学习项目。

我们在这里列出的工具和模式可能是集成LLM的起点，而不是结束状态。随着重大变化（例如，向模型训练的转变），我们将更新这一点，并在有意义的地方发布新的参考架构。如果您有任何反馈或建议，请联系。

* * *

这里表达的观点是引用的个别AH Capital Management，L.L.C.（“a16z”）人员的观点，而不是a16z或其附属公司的观点。此处包含的某些信息是从第三方来源获得的，包括由a16z管理的基金的投资组合公司。虽然来自被认为可靠的来源，但a16z没有独立核实此类信息，也没有对信息的持久准确性或其在特定情况下的适当性做出任何陈述。此外，此内容可能包括第三方广告；a16z没有审查此类广告，也不认可其中包含的任何广告内容。