大语言模型LLM的涌现架构

大语言模型LLM的涌现架构

预训练的人工智能模型代表了自互联网以来最重要的软件架构变化。它们使个人开发人员能够在几天内构建出令人难以置信的人工智能应用程序，超越大型团队需要数月才能构建的监督机器学习项目。

我们在这里列出的工具和模式可能是整合大语言模型LLM的起点。在这篇文章中，我们将分享新兴 LLM 应用程序堆栈的参考架构。它展示了我们所见过的人工智能初创公司和尖端科技公司使用的最常见的系统、工具和设计模式。

设计模式：语境中学习
上下文学习的核心思想是使用现成的LLM（即没有任何微调），然后通过巧妙的提示和对私人 "上下文 "数据的调节来控制其行为。

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

上下文学习通过一个巧妙的技巧解决了这个问题：它不是在每个LLM提示下发送所有的文件，而是只发送少数几个最相关的文件。而这些最相关的文件是在LLMs的帮助下确定的。。

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

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

这看起来是一个很大的工作，但通常比另一个选择更容易：训练或微调LLM本身。
你不需要一个专门的ML工程师团队来做语境中的学习。
你也不需要托管你自己的基础设施或从OpenAI购买昂贵的专用实例。

这种模式有效地将人工智能问题减少为大多数初创企业和大公司已经知道如何解决的数据工程问题。

对于相对较小的数据集，它的表现也往往优于微调--因为一个特定的信息需要在训练集中出现至少~10次，然后LLM才会通过微调记住它，并且可以近乎实时地纳入新数据。

围绕上下文学习的最大问题之一是：如果我们只是改变底层模型以增加上下文窗口会怎样？这的确是可能的，而且这也是一个活跃的研究领域。

但是，这也有一些代价：主要是推理的成本和时间随着提示长度的增加而呈四次方扩展。

今天，即使是线性扩展（最好的理论结果）对许多应用来说也是成本过高。按照目前的API价格，一个超过10000页的GPT-4查询将花费数百美元。

因此，我们不期望基于扩展的上下文窗口对堆栈进行全盘的改变，但我们会在文章的正文中对此进行更多的评论。

如果你想更深入地了解上下文学习，人工智能大典中有许多很棒的资源（尤其是 "使用LLM构建的实用指南 "部分）。

1、数据预处理和嵌入
LLM应用程序的上下文数据包括文本文件、PDF，甚至是CSV或SQL表等结构化格式。在我们采访的开发者中，这些数据的数据加载和转换解决方案差别很大。大多数人使用传统的ETL工具，如Databricks或Airflow。也有一些人使用LangChain（由Unstructured提供）和LlamaIndex（由Llama Hub提供）等协调框架中的文档加载器。我们认为，这部分的堆栈相对来说还没有得到充分的发展，为LLM应用程序专门设计的数据复制解决方案是一个机会。

对于嵌入，大多数开发者使用OpenAI的API，特别是文本嵌入-ada-002模型。它很容易使用（特别是如果你已经在使用其他的OpenAI API），给出合理的好结果，而且越来越便宜。一些大型企业也在探索Cohere，它将产品的努力更狭隘地集中在嵌入上，在某些场景下有更好的表现。对于那些喜欢开源的开发者来说，来自Hugging Face的Sentence Transformers库是一个标准。也可以针对不同的使用情况创建不同类型的嵌入；这在今天是一个小众的做法，但却是一个有前途的研究领域。

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

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

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

展望未来，大多数开源的矢量数据库公司正在开发云产品。

我们的研究表明，在云中实现强大的性能，跨越可能的使用案例的广泛设计空间，是一个非常困难的问题。因此，选项集在短期内可能不会有大的变化，但在长期内可能会有变化。关键问题是矢量数据库是否会像它们的OLTP和OLAP一样，围绕一两个流行的系统进行整合。

另一个开放的问题是，随着大多数模型的可用上下文窗口的增加，嵌入和矢量数据库将如何发展。说嵌入将变得不那么重要是很诱人的，因为上下文数据可以直接丢到提示中。

然而，专家们对这个问题的反馈表明，情况恰恰相反，随着时间的推移，嵌入管道可能会变得更加重要。

大的上下文窗口是一个强大的工具，但它们也带来了巨大的计算成本。
因此，有效地利用它们成为一个优先事项。

我们可能会开始看到不同类型的嵌入模型变得流行，直接为模型的相关性进行训练，而矢量数据库的设计就是为了实现和利用这一点。

2、提示构建/检索
提示LLM的策略和纳入上下文数据的策略正变得越来越复杂，而且作为产品差异化的来源也越来越重要。大多数开发者在开始新项目时都会尝试使用简单的提示，包括直接指令（零次提示）或可能的一些示例输出（几次提示）。这些提示往往能带来良好的效果，但却达不到生产部署所需的准确度。

下一层次的提示术旨在将模型的响应建立在一些真相来源上，并提供模型没有被训练的外部环境。提示工程指南》列出了不少于12种（！）更高级的提示策略，包括思维链、自洽性、生成的知识、思维树、方向性刺激和其他许多策略。这些策略也可以结合使用，以支持不同的LLM用例，如文档问题回答、聊天机器人等。

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

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

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

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

当项目进入生产阶段并开始扩大规模时，一系列更广泛的选择就开始发挥作用。我们听到的一些常见的选择包括：

• 切换到 gpt-3.5-turbo：它比 GPT-4便宜约 50 倍，而且速度明显更快。许多应用程序不需要 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的真正开放源代码版本。

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

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

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

代理呢？
该参考架构中缺少的最重要组件是人工智能代理框架。AutoGPT被描述为“一项让 GPT-4 完全自治的实验性开源尝试”，是今年春天历史上增长最快的 Github 存储库，而且如今几乎每个人工智能项目或初创公司都包含某种形式的代理。

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

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