输入“/”快速插入内容

LLM应用程序的新兴架构

2024年7月25日修改

作者：向量检索实验室 | AI 搜索引擎

原文：https://mp.weixin.qq.com/s/CFIqEtvk...

原文链接：https://a16z.com/emerging-architectures-for-llm-applications/

大语言模型（LLM）为软件构建提供了一种强大的新方法。由于这种技术相对较新，且其运作方式与传统计算资源大相径庭，如何有效利用它们并不是显而易见的。​

在这篇文章中，我们将分享LLM应用开发中新兴的参考架构。这一架构展示了AI初创企业和技术巨头常用的系统、工具和设计模式。虽然这一架构还处于初期阶段，未来可能会随着技术进步而有较大变化，但我们希望它能为目前从事LLM开发的开发者提供有价值的参考。​

这项工作基于我们与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提供的宝贵意见。​

LLM应用程序技术栈

以下是我们对LLM应用堆栈的当前理解（点击放大查看）：

common.docs_name - LarkCCM_Docs_Menu_Image

为方便快速查阅，以下是各项目的链接列表：

数据流水线	嵌入模型	向量数据库	沙盒环境	业务流程编排	API/插件	LLM缓存
Databricks	OpenAI	Pinecone	OpenAI	Langchain	Serp	Redis
Airflow	Cohere	Weaviate	nat.dev	LlamaIndex	Wolfram	SQLite
Unstructured	Hugging Face	ChromaDB	Humanloop	ChatGPT	Zapier	GPTCache
		pgvector

大语言模型运维	过程验证	App托管	LLM APIs (私有)	LLM APIs (开放)	云服务提供商	预配置云服务
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。我们展示的技术栈基于 上下文学习 [1]这一设计模式，这是目前开发者入门的首选方法，并且现在只能通过基础模型实现。​

下一节将简要解释此模式；有经验的LLM开发人员可以跳过此部分。​

设计模式：上下文学习（In-context learning）

上下文学习的核心思想是直接使用LLM（即不进行任何微调），通过精心设计的提示词和依赖特定“上下文”数据来控制其行为。​

例如，若你想构建一个能回答法律文件问题的聊天机器人，一个简单的方法是将所有文件内容输入到ChatGPT或GPT-4中，然后在最后提出问题。这种方法对小数据集来说可能行得通，但难以扩展。GPT-4最大模型仅能处理大约50页的输入文本，且当输入接近这个上限时，性能（以推理时间和准确度衡量）会大幅下降，这就是所谓的上下文窗口限制。​

上下文学习通过一个巧妙的方法解决了这个问题：不是每次都发送全部文档，而是仅发送几份相关性最强的文档。而这些最相关的文档是通过LLM来确定的。​

大体上，工作流程分为三个阶段：

•
数据预处理/嵌入 ：此阶段涉及存储后续需要检索的私有数据（如法律文件）。通常，文档被分割、通过嵌入模型处理后存储于一个专门的向量数据库中。​

•
构建提示词/检索 ：用户提交查询（如法律问题）时，应用会构建一系列提示发送给语言模型。构建的提示通常包括开发者预设的模板、有效输出的示例（少量样本示例）、必要的外部API信息以及从向量数据库检索的相关文档。​

•
执行/推理 ：编译好的提示被提交给预训练的LLM进行推理，这包括专有模型API和开源或自训练模型。此阶段，一些开发者还会加入日志记录、缓存和验证等操作。​

虽然听起来步骤繁多，但实际上这比直接训练或微调LLM要简单得多。进行上下文学习不需要专门的机器学习工程师团队，也无需自建基础设施或向OpenAI购买昂贵的专用实例。这种模式有效将AI问题转化为大多数初创企业和大公司已经熟悉的数据工程问题，对于相对较小的数据集，它的性能也往往优于微调——因为一条特定的信息需要在训练集中至少出现约 10 次，LLM 才会通过微调记住它，此外这样做还可以可以近乎实时地拟合新数据。​

关于上下文学习的一个主要疑问是，如果我们改变底层模型以增加上下文窗口会怎样？这确实是可能的，也是一个活跃的研究领域（例如，参见 Hyena论文 [2]或 近期的这篇文章 ）。但这需要权衡——主要是推理的成本和时间与提示的长度呈二次方关系。目前即使是线性增长（理论上的最佳结果）对许多应用来说也是成本过高的。单次GPT-4查询处理10,000页文档的费用会在当前API定价下达到数百美元。因此，我们不预期会因扩大上下文窗口而对技术栈进行根本性改变，但我们将在文章主体中进一步讨论此事。​

LLM应用程序的新兴架构​

LLM应用程序的新兴架构