孵化的明星项目ChatU.AI 产品可免费申请试用，作为企业级AIGC，支持企业私有部署，多引擎的AIGC操作系统，安全稳定，关注下方软积木AIGC公众号，一键体验！（试用链接：m.chatu.pro)
大型语言模型是构建软件的一种强大的新原语。但是，由于它们是如此新——而且表现得与普通的计算资源如此不同——如何使用它们并不总是显而易见的。
在这篇文章中，我们将分享一个新兴的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, Matei Zaharia, and Jared Zoneraich.
以下是我们对LLM当前的应用程序堆栈图（点击查看大图）:
Data pipelines Embedding model Vector database Playground Orchestration APIs/plugins LLM cache Databricks OpenAI Pinecone OpenAI Langchain Serp Redis Airflow Cohere Weaviate nat.dev LlamaIndex Wolfram SQLiteUnstructured Hugging Face ChromaDB Humanloop ChatGPT Zapier GPTCache pgvector
Logging / LLMops Validation App hosting LLM APIs (proprietary) LLM APIs (open) Cloud providers Opinionated cloudsWeights & 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开发人员可以跳过这一节。
设计模式：情境学习
上下文学习的核心思想是使用现成的LLM（即没有任何微调），然后通过巧妙的提示和对私人“上下文”数据的调节来控制它们的行为。
例如，假设你正在构建一个聊天机器人来回答关于一组法律文件的问题。使用一种简单的方法，您可以将所有文档粘贴到一个ChatGPT或GPT-4提示中，然后在最后询问有关它们的问题。这可能适用于非常小的数据集，但不能扩展。最大的GPT-4模型只能处理约50页的输入文本，并且性能（由推理时间和准确性衡量）随调用上下文的个极限增加，会严重退化。
上下文中的学习用一个巧妙的技巧解决了这个问题：它不是用每个LLM提示符发送所有文档，而是只发送少数几个最相关的文档。和最相关的文件是在帮助下确定LLM。
数据预处理/嵌入：这个阶段包括存储私有数据（在我们的示例中是法律文档），以便以后检索。通常，文档被分成多个块，通过嵌入模型传递，然后存储在称为向量数据库的专门数据库中。
提示构造/检索：当用户提交查询（在本例中是法律问题）时，应用程序构造一系列提示以提交给语言模型。编译的提示通常包含开发人员硬编码的提示模板、称为少量示例的有效输出示例、从外部API检索的任何必要信息以及从向量数据库检索的一组相关文档。
提示执行/推理：编译提示后，将其提交给预训练的LLM进行推理，包括专有模型API和开源或自训练模型。一些开发人员还在此阶段添加操作系统，如日志记录、缓存和验证。
这看起来是一个很大的工作量，但它通常比另一种方法更容易：训练或微调LLM本身。您不需要专门的机器学习工程师团队来进行训练。您也不需要托管自己的基础设施或从OpenAI购买昂贵的专用实例。这种模式有效地将一个人工智能问题简化为数据工程问题，大多数创业公司和大公司都已经知道如何解决。对于相对较小的数据集，它的表现也往往优于微调，因为一个特定的信息需要在训练集中出现至少10次，然后LLM才能通过微调记住它，并且可以近实时地合并新数据。
围绕在情境中学习的最大问题之一是：如果我们只是改变基础模型来增加情境窗口，会发生什么？这确实是可能的，而且是一个活跃的研究领域（例如，见Hyena的论文或者这篇最近的帖子）。但这也带来了一些折中——主要是推理成本和时间与提示长度成平方关系。即使是线性缩放（最好的理论结果），对于许多应用来说，成本也是令人望而却步的。按目前的API费率计算，一个超过10,000页的GPT-4查询将花费数百美元。所以，我们并不期望对基于扩展上下文窗口的堆栈进行大规模的更改，但我们会在文章正文中对此进行更多的评论。
如果您想更深入地了解上下文学习，在AI经典中有许多很好的资源（特别是"Practical guides to building with LLM"部分）。在这篇文章的其余部分中，我们将使用上面的工作流作为指导，遍历引用堆栈。
LLM应用程序的上下文数据包括文本文档、PDF甚至CSV或SQL表等结构化格式。针对这些数据的数据加载和转换解决方案在我们采访的开发人员中差异很大。大多数使用传统的ETL工具，如Databricks或Airflow。有些还使用了编排框架中内置的文档加载器，比如LangChain（由非结构化提供支持）和LlamaIndex（由Llama Hub提供支持）。不过，我们相信这一块的堆栈相对不发达，为LLM应用专门构建的数据复制解决方案是有机会的。
对于嵌入，大多数开发人员使用OpenAI API，特别是文本嵌入-ada-002模型。它易于使用（特别是如果您已经在使用其他OpenAI API），提供了相当好的结果，并且成本越来越低。一些较大的企业也在探索Cohere，Cohere将他们的产品精力更集中在嵌入式上，并且在某些场景中有更好的性能。对于喜欢开源的开发者来说，Hugging Face的Sentence Transformers库是一个标准库。也有可能在创建不同类型的嵌入为不同的用例量身定制；这在今天是一个利基实践，但也是一个有前途的研究领域。
从系统的角度来看，预处理管道中最重要的部分是矢量数据库。它负责有效地存储、比较和检索多达数十亿的嵌入（即向量）。我们在市场上看到的最常见的选择是松果。这是默认值，因为它是完全云托管的因此，它很容易上手，并且具有大型企业在生产中需要的许多功能（例如，良好的大规模性能、SSO和正常运行时间SLA）。
Weaviate、Vespa和Qdrant等开源系统:它们通常提供出色的单节点性能，并可针对特定应用进行定制，因此在喜欢构建定制平台的经验丰富的人工智能团队中很受欢迎。
像Chroma和Faiss这样的本地向量管理库：它们有很好的开发者体验，并且很容易启动小型应用和开发实验。它们不一定能大规模地替代完整的数据库。
OLTP扩展，如pgvector:对于那些看到每一个数据库形状的漏洞并试图插入Postgres的开发人员——或者那些从单一云提供商购买大部分数据基础设施的企业——这是一个很好的向量支持解决方案。从长远来看，还不清楚将向量工作负载和标量工作负载紧密耦合是否有意义。
展望未来，大多数开源矢量数据库公司都在开发云产品。我们的研究表明，在云中实现强大的性能，跨越可能的用例的广泛设计空间，是一个非常困难的问题。因此，期权集在短期内可能不会有很大的变化，但很可能会在长期内发生变化。关键的问题是矢量数据库是否会类似于它们的OLTP和OLAP，从而整合一个或两个流行的系统。
另一个悬而未决的问题是，随着大多数模型可用上下文窗口的增长，嵌入和矢量数据库将如何发展。很容易认为嵌入将变得不那么相关，因为上下文数据可以直接放到提示符中。然而，专家们对这个话题的反馈却表明了相反的观点——随着时间的推移，嵌入管道可能会变得更加重要。大上下文窗口是一个强大的工具，但它们也需要大量的计算成本。因此，有效地利用它们成为一个优先事项。我们可能会开始看到不同类型的嵌入模型变得流行起来，直接针对模型相关性进行训练，向量数据库的设计就是为了实现并利用这一点。
促进LLM和结合上下文数据的策略正变得越来越复杂——作为产品差异化的一个来源，也越来越重要。大多数开发人员在开始新项目时都会尝试一些简单的提示，包括直接指令（零触发提示）或一些示例输出（少量触发提示）。这些提示通常提供了很好的结果，但低于生产部署所需的准确性水平。
下一个级别的提示 jiu jitsu 是为了使模型的反应以某种真实的来源为基础，并提供模型没有经过训练的外部环境。“工程指南”不少于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-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的操作工具。缓存相对比较常见--通常基于Redis--因为它提高了应用程序响应时间和成本、重量和偏差、MLflow(从传统机器学习中移植)、PromptLayer和Helicone(为LLMS建立的目的)等工具也被广泛使用。它们可以记录、跟踪和评估LLM输出，通常用于改进快速构建、调整管道或选择模型。还开发了一些新的工具来验证LLM输出(例如护栏)或检测及时注入攻击(例如拒绝)。大多数这些操作工具都鼓励使用自己的Python客户端进行LLM调用，因此了解这些解决方案是如何随时间的推移共存是很有趣的。
最后，LLM应用程序的静态部分（即模型之外的所有内容）也需要托管在某个地方。到目前为止，我们看到的最常见的解决方案是标准选项，如Vercel或主要的云提供商。然而，两个新的类别正在出现。像Steamship这样的初创公司为LLM应用提供端到端的托管，包括编排（LangChain）、多租户数据上下文、异步任务、向量存储和密钥管理。像Anyscale和Modal这样的公司允许开发人员在一个地方托管模型和Python代码。
这个参考架构中最重要的组件是AI代理框架。自动GPT，被描述为“一个实验性的开源尝试，使GPT—4完全自治”，是历史上增长最快的Github回购今年春天，几乎每一个人工智能项目或创业公司都以某种形式包含了代理。
与我们交谈的大多数开发人员都对代理的潜力感到难以置信的兴奋。为了更好地支持内容生成任务，我们在本文中描述的上下文学习模式可以有效地解决幻觉和数据新鲜度问题。另一方面，代理为人工智能应用提供了一套全新的能力：解决复杂问题，对外部世界采取行动，以及在部署后从经验中学习。他们通过高级推理/计划、工具使用和记忆/递归/自我反思的组合来实现这一点。
因此，代理有可能成为LLM应用程序体系结构的中心部分(如果您相信递归的自我改进，甚至可以接管整个堆栈)。而像LangChain这样的现有框架已经包含了一些代理概念。只有一个问题：特工们还没有真正发挥作用。今天，大多数代理框架都处于概念证明阶段--能够进行难以置信的演示，但尚未完成可靠、可复制的任务。我们正在密切关注它们在不久的将来是如何发展的。
经过预训练的人工智能模型代表了自互联网以来软件领域最重要的架构变革。它们使个人开发者能够在几天内构建令人难以置信的人工智能应用，超越大型团队花费数月时间构建的受监督机器学习项目。
我们在这里列出的工具和模式很可能是集成LLM的起点，而不是终点。当发生重大变化时（例如，转向模型训练），我们将更新此文件，并在有意义的地方发布新的参考架构。如果您有任何反馈或建议，请联系我们。
这里所表达的是AH资本管理公司的个人观点，L.L.C.(“a16z”)人员引用的观点，而不是A16z或其附属公司的观点。这里包含的某些信息是从第三方来源获得的，包括来自a16z管理的基金的投资组合公司。虽然从被认为是可靠的消息来源获取，但a16z没有独立地验证这种信息，也没有对信息的持久准确性或其对给定情况的适当性作出任何陈述。此外，该内容可能包括第三方广告；a16z没有审查此类广告，也不支持其中所包含的任何广告内容。
本内容仅供参考，不应被视为法律、商业、投资或税务建议。关于那些事，你应该请教你自己的顾问。对任何证券或数字资产的引用仅用于说明目的，并不构成投资建议或提供投资咨询服务的要约。此外，本内容不针对任何投资者或潜在投资者，也不打算供其使用，并且在任何情况下，在作出投资a16z管理的任何基金的决定时，不得依赖本内容。（投资a16z基金的要约只能由私募备忘录、认购协议和任何此类基金的其他相关文件作出，并应完整阅读。）所提及、提及或描述的任何投资或投资组合公司并不代表a16z管理的所有投资工具，并且不能保证这些投资将是有利可图的，也不能保证将来所做的其他投资将具有类似的特征或结果。Andreessen Horowitz管理的基金进行的投资（不包括发行人未向a16z提供公开披露许可的投资，以及未公布的公开交易数字资产投资）的列表可在https://a16z.com/investments/.
内容提供的图表和图形仅供参考，在作出任何投资决定时不应依赖。过往表现并不代表未来的业绩。内容仅表示所示日期。这些材料中的任何预测、估计、预测、目标、前景和/或表达的意见如有变更，恕不另行通知，可能与其他人表达的意见不同或相反。请看https://a16z.com/disclosures以获取其他重要信息。
免责声明：
由于传播、利用本公众号软积木所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号软积木及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！
