LLM应用程序的新兴体系结构
- LLM应用栈
- 设计模式：In-context learning
- Data Preprocessing/Embedding
- Prompt Construction/Retrieval
- Prompt Execution/Inference
- What about agents?
- 展望
- 参考资料
大型语言模型是构建软件的强大新基元。但由于它们非常新颖且与常规计算资源的行为差异很大，如何使用它们并不总是显而易见。
在本文中，我们分享了新兴的大型语言模型应用栈的参考架构。它展示了我们在人工智能初创公司和高级技术公司中看到的最常见的系统、工具和设计模式。这个栈仍处于非常早期阶段，随着基础技术的进步，它可能会发生重大变化，但我们希望它能成为现在与大型语言模型一起工作的开发人员的有用参考。
LLM应用栈
以下是LLM应用程序堆栈的当前视图：
以下是指向每个项目的链接的列表以快速参考：
| Data pipelines | Embedding models | Vector database | Playground | Orchestration | APIs/plugins | LLM cache |
|---|---|---|---|---|---|---|
| Databricks | OpenAI | Pinecone | OpenAI | Langchain | Serp | Redis |
| Airflow | Cohere | Weaviate | nat.dev | LlamaIndex | Wolfram | SQLite |
| Unstructured | Hugging Face | ChromaDB | Humanloop | ChatGPT | Zapier | GPTCache |
| pgvector |
| Logging/LLMops | Validation | App hosting | LLM APIs (proprietary) | LLM APIs (open) | Cloud providers | Opinionated clouds |
|---|---|---|---|---|---|---|
| Weights & Biases | Guardrails | Vercel | OpenAI | Hugging Face | AWS | Databricks |
| MLflow | Rebuff | Steamship | Anthropic | Replicate | GCP | Anyscale |
| PromptLayer | Microsoft Guidance | Streamlit | Azure | Mosaic | ||
| Helicone | LMQL | Modal | CoreWeave | Modal | ||
| RunPod |
有许多不同的方法可以使用LLM构建，包括从头开始训练模型、微调开源模型或使用托管API。我们在这里展示的技术栈是基于上下文学习的，这是我们看到的大多数开发人员一开始的设计模式（现在只有基础模型才有可能）。
下一节将简要解释这种模式；有经验的LLM开发人员可以跳过本节。
设计模式：In-context learning
上下文学习的核心思想是使用现成的LLM（即，没有任何微调），然后通过对私人“上下文”数据的巧妙提示和条件调节来控制他们的行为。
例如，假设您正在构建一个聊天机器人来回答有关一组法律文件的问题。采取一种native的方法，可以将所有文档粘贴到ChatGPT或GPT-4提示中，然后在最后询问有关它们的问题。这可能适用于非常小的数据集，但不能扩展。最大的GPT-4模型只能处理大约50页的输入文本，并且性能（以推理时间和准确性衡量）随着接近这个极限（称为上下文窗口）而严重下降。
上下文学习用一个聪明的技巧解决了这个问题：**它不是在每个LLM提示下发送所有文档，而是只发送少数最相关的文档。**最相关的文件是在…的帮助下确定的。猜对了，就是LLM。
在很高的层次上，工作流程可以分为三个阶段：
- Data preprocessing/embedding: 这个阶段涉及存储稍后要检索的私有数据（在我们的示例中是法律文档）。通常，文档被分解成块，通过一个embedding模型传递，然后存储在一个称为
向量数据库的专门数据库中。 - Prompt construction/retrieval：当用户提交查询（在这种情况下是一个法律问题）时，应用程序会构造一系列提示以提交给语言模型。编译后的提示通常结合了由开发人员硬编码的提示模板；有效输出的示例称为few-show示例；从外部API检索到的任何必要信息；以及从向量数据库检索到的一组相关文档。
- Prompt execution/inference：一旦编译了提示，就将其提交给经过预训练的LLM进行推理，包括专有模型API和开源或自训练模型。一些开发人员还在这个阶段添加了日志记录、缓存和验证等操作系统。
这看起来需要做很多工作，但通常比其他选择更容易：训练或微调LLM本身。不需要专门的ML工程师团队来进行上下文学习。也不需要托管自己的基础设施，也不需要从OpenAI购买昂贵的专用实例。这种模式有效地将人工智能问题简化为大多数初创公司和大公司已经知道如何解决的数据工程问题。对于相对较小的数据集，它也往往优于微调，因为一条特定的信息需要在训练集中出现至少约10次，LLM才能通过微调记住它，并可以近乎实时地合并新数据。
上下文学习中最大的问题之一是：如果我们只是改变底层模型来增加上下文窗口，会发生什么？这确实是可能的，也是一个活跃的研究领域（例如，见Hyena论文或这篇最近的帖子）。但这需要进行一些权衡，主要是推理的成本和时间与提示的长度成二次关系。如今，对于许多应用来说，即使是线性缩放（最佳理论结果）也会导致成本过高。按目前API的价格，一个超过10000页的GPT-4查询将花费数百美元。因此，不希望基于扩展的上下文窗口对堆栈进行大规模更改，但我们将在文章正文中对此进行更多讨论。
如果你想更深入地了解上下文学习，AI canon中有很多很棒的资源（尤其是“LLM构建实用指南”部分）。在本文的剩余部分中，我们将以上面的工作流程为指导，浏览参考堆栈。
Data Preprocessing/Embedding
LLM应用程序的上下文数据包括文本文档、PDF，甚至CSV或SQL表等结构化格式。针对这些数据的数据加载和转换解决方案在我们采访过的开发人员中差异很大。大多数使用传统的ETL工具，如Databricks或Airflow。有些还使用构建在编排框架中的文档加载器，如LangChain（由Unstructured提供支持）和LlamaIndex（由Llama Hub提供支持）。不过，我们认为这一部分相对来说还不成熟，而且有机会为LLM应用程序专门构建数据复制解决方案。
对于嵌入，大多数开发人员使用OpenAI API，特别是text-embedding-ada-002模型。它很容易使用（尤其是如果你已经在使用其他OpenAI API），效果相当好，而且越来越便宜。一些较大的企业也在探索Cohere，它将产品重点放在嵌入上，并在某些场景中具有更好的性能。对于喜欢开源的开发人员来说，Hugging Face的句子转换器库是一个标准。还可以根据不同的用例创建不同类型的嵌入；这在今天是一个小众的实践，但却是一个很有前途的研究领域。
从系统的角度来看，预处理流水线中最重要的部分是向量数据库。它负责高效地存储、比较和检索多达数十亿个嵌入（即向量）。我们在市场上看到的最常见的选择是Pinecone。它是默认的，因为它是完全云托管的，所以很容易上手，并且具有大型企业在生产中需要的许多功能（例如，良好的规模性能、SSO和正常运行时间SLA）。
不过，有大量可用的向量数据库。值得注意的是：
- 像Weaviate、Vespa和Qdrant这样的开源系统：它们通常具有出色的单节点性能，可以针对特定应用进行定制，因此深受喜欢构建定制平台的经验丰富的人工智能团队的欢迎。
- Chroma和Faiss等本地向量管理库：它们拥有众多具有丰富开发经验的开发者，很容易在小型应用程序和开发实验中进行开发。但是它们不一定能取代大规模的完整数据库。
- OLTP扩展，如pgvector：对于那些看到每个database-shaped漏洞并试图插入Postgres或从单个云提供商购买大部分数据基础设施的企业的开发人员来说，这是一个很好的向量支持解决方案。从长远来看，将向量和标量工作负载紧密耦合是否有意义尚不清楚。
展望未来，大多数开源向量数据库公司都在开发云产品。研究表明，在可能用例的广阔设计空间中，在云中实现强大的性能是一个非常困难的问题。因此，可选的集合在短期内可能不会发生巨大变化，但在长期内可能会发生变化。关键问题是向量数据库是否会类似于OLTP和OLAP，围绕一两个流行的系统进行整合。
另一个悬而未决的问题是，随着大多数模型可用上下文窗口的增长，嵌入和向量数据库将如何发展。人们很容易说嵌入将变得不那么相关，因为上下文数据可以直接放入提示中。然而，专家对这一主题的反馈表明，随着时间的推移，embedding pipeline可能会变得更加重要。大型上下文窗口是一个强大的工具，但它们也需要大量的计算成本。因此，有效利用它们成为当务之急。我们可能会开始看到不同类型的嵌入模型变得流行，直接针对模型相关性进行训练，并设计向量数据库来实现和利用这一点。
Prompt Construction/Retrieval
作为产品差异化的来源，促进LLM和整合上下文数据的策略变得越来越复杂，也越来越重要。大多数开发人员通过试验简单的提示来启动新项目，包括直接指令（零样本提示）或可能的一些示例输出（few-shot提示）。这些提示通常会产生良好的结果，但达不到生产部署所需的准确性水平。
下一个级别的提示jiu jitsu旨在将模型反应建立在一些真实来源的基础上，并提供模型没有接受过训练的外部环境。《提示工程指南》列出了不少于12种更先进的提示策略，包括思维链、自洽性、生成的知识、思维树、定向刺激等。这些策略还可以用于支持不同的LLM用例，如文档问答、聊天机器人等。
这就是像LangChain和LlamaIndex这样的Orchestration框架大放异彩的地方。它们抽象掉了提示链接的许多细节；与外部API接口（包括确定何时需要API调用）；从向量数据库中检索上下文数据；以及跨多个LLM调用维护存储器。它们还为上面提到的许多常见应用程序提供了模板。它们的输出是提交到语言模型的提示或一系列提示。这些框架在业余爱好者和初创公司中被广泛使用，他们希望推出一款应用程序，其中LangChain是领导者。
LangChain仍然是一个相对较新的项目（目前版本为0.0.201），但我们已经开始看到使用它构建的应用程序投入生产。一些开发人员，尤其是LLM的早期采用者，更喜欢在生产中切换到原始Python，以消除增加的依赖关系。但我们预计，在大多数用例中，这种DIY方法会随着时间的推移而减少，其方式与传统的网络应用程序堆栈类似。
眼尖的读者会注意到orchestration框中有一个看似奇怪的条目：ChatGPT。在它的正常化身中，ChatGPT是一个应用程序，而不是一个开发工具。但它也可以作为API进行访问。而且，如果你仔细看的话，它执行一些与其他编排框架相同的功能，例如：抽象出对定制提示的需求；维持状态；以及通过插件、API或其他来源检索上下文数据。虽然ChatGPT不是这里列出的其他工具的直接竞争对手，但它可以被视为一种替代解决方案，它最终可能成为一种可行的、简单的替代方案，以代替即时构建。
Prompt Execution/Inference
如今，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的真正开源版本。
当（而不是如果）开源LLM达到与GPT-3.5相当的精度水平时，我们预计会看到文本出现类似稳定扩散的时刻，包括大规模实验、共享和微调模型的产品化。像Replicate这样的托管公司已经在添加工具，使软件开发人员更容易使用这些模型。开发人员越来越相信，更小、微调的模型可以在狭窄的用例中达到最先进的精度。
我们采访过的大多数开发人员还没有深入研究LLM的operational tooling。缓存相对常见，通常基于Redis，因为它提高了应用程序的响应时间和成本。像Weights&Biases和MLflow（从传统机器学习移植而来）或PromptLayer和Helicone（专门为LLM构建）这样的工具也得到了相当广泛的使用。它们可以记录、跟踪和评估LLM输出，通常用于改进即时构建、调整管道或选择模型。还有许多新工具正在开发中，用于验证LLM输出（例如Guardrails）或检测即时注入攻击（例如Rebuff）。这些操作工具中的大多数都鼓励使用自己的Python客户端进行LLM调用，因此了解这些解决方案如何随着时间的推移共存将是一件有趣的事情。
最后，LLM应用程序的静态部分（即模型以外的所有内容）也需要托管在某个地方。到目前为止，我们看到的最常见的解决方案是标准选项，如Vercel或主要的云提供商。然而，有两个新类别正在出现。Steamship等初创公司为LLM应用程序提供端到端托管，包括编排（LangChain）、多租户数据上下文、异步任务、矢量存储和密钥管理。像Anyscale和Modal这样的公司允许开发人员在一个地方托管模型和Python代码。
What about agents?
这个参考体系结构中缺少的最重要的组件是AI agent frameworks。AutoGPT被描述为“使GPT-4完全自主的实验性开源尝试”，是今年春天历史上增长最快的Github repo，如今几乎每个人工智能项目或初创公司都包括某种形式的代理。
大多数开发人员都对代理（Agents）的潜力感到无比兴奋。在本文中描述的上下文学习模式在解决幻觉和数据新鲜度问题方面是有效的，以便更好地支持内容生成任务。另一方面，代理为人工智能应用程序提供了一套全新的能力：解决复杂问题，对外部世界采取行动，并在部署后从经验中学习。他们通过高级推理/计划、工具使用和内存/递归/自我反思的组合来实现这一点。
因此，代理有可能成为LLM应用程序架构的核心部分（如果你相信递归自我完善，甚至可以接管整个堆栈）。像LangChain这样的现有框架已经包含了一些代理概念。只有一个问题：代理还没有真正工作。如今，**大多数代理框架都处于概念验证阶段，能够进行令人难以置信的演示，但还不能可靠、可复制地完成任务。**我们正在密切关注它们在不久的将来如何发展。
展望
经过预训练的人工智能模型代表了自互联网以来软件中最重要的架构变化。它们使个人开发人员有可能在几天内构建出令人难以置信的人工智能应用程序，超过了大型团队耗时数月构建的监督机器学习项目。
这里列出的工具和模式可能是集成LLM的起点，而不是终点。我们将在发生重大变化时对此进行更新（例如，向模型训练的转变），并在有意义的地方发布新的参考体系结构。
参考资料
- Emerging Architectures for LLM Applications
- in-context learning
