LLM技术栈分层详解

当下，预训练大语言模型（LLM）的热度已经不用多说，像是 OpenAI 的 GPT-4 和 Meta 的 Llama 系列，正在被越来越多的开发者拥抱。相比早期版本，它们的可用性有了质的飞跃，在生成式 AI 应用开发中扮演着核心角色。

作为软件开发者，问题来了：怎么才能快速把 LLM 的能力嵌入到自己的应用里？答案恐怕离不开“上下文学习”——围绕这个思路，一套新兴的 AI 技术栈正在成型。本文就打算顺着这个方向，一层层摸清这个技术栈的底细。

1、预训练LLM的定制

我们可以先回想一下，像 GPT-4 和 Llama 2 这样的开箱即用型 LLM，本质上是基于海量公开数据预训练出来的基础模型。数据来源包括 Common Crawl（数十亿网页的存档）、Wikipedia（社区驱动的在线百科全书），以及古腾堡计划（公共领域书籍的集合）。

GPT-4 的模型规模大概有 1.76T 参数，而 Llama 2 则是 70B 参数。得益于预训练数据的广度，它们对大多数场景都能应付。不过，想让模型精确匹配你的特定应用需求，可能还需要做些调整。

调整预训练 LLM 来适配专属场景，目前主要有两条路径：微调与上下文学习。

1.1 微调

微调的本质，就是在预训练模型的基础上，喂给它一份更小、更聚焦的私有数据集，再做一次额外训练。这个过程会改变模型的参数，相当于让它的“知识储备”变得更加专业化。

从 2023 年 12 月起，OpenAI 的官方 API 已经支持对 GPT-3.5 Turbo 进行微调。GPT-4 的微调则走实验性访问通道，符合资格的用户会在微调界面看到“请求访问”的选项。

至于 Llama 2，可以通过 Google Colab 或 Hugging Face 这类机器学习平台来完成微调。

• 输出质量通常优于单纯依靠提示词
• 能容纳的训练示例数量远超提示词的极限
• 微调后的提示词更短，意味着成本更低、延迟更小

• 过程需要机器学习方面的专业知识，资源消耗也大
• 存在“灾难性遗忘”风险——获得新技能的同时，可能会丢失预训练模型原来学会的东西
• 容易过拟合，也就是模型过于贴近训练数据集，失去泛化能力

1.2 上下文学习

上下文学习则完全不改动底层的预训练模型。它通过精心设计的提示词和检索回来的相关信息来引导大模型输出，好比在“正确的时间给模型正确的信息”。

想让 LLM 完成更具体的任务，并以特定格式输出，可以用“少样本提示”技术。除了主查询，还要把几组预期的输入输出对作为示例，一起塞进输入上下文里。可以把这些示例对看成一个小型的、精准的训练集。

由于预训练模型只在公开数据和有截止日期的许可数据集上训练，它们对最近的事件和私有数据是完全不知情的。

为了给 LLM 补充额外知识，还可以用上检索增强生成（RAG）技术。LLM 自身视野之外的那些信息，比如矢量数据库、SQL 数据库、内部或外部 API，甚至是文档存储库里的资料，都可以作为输入上下文的一部分检索出来传给模型。

截至 2023 年 12 月，GPT-4 Turbo 的最大上下文长度达到 128,000 个 token，而 Llama 2 只有 4,096 个。

• 不需要机器学习专业知识，资源需求也低得多
• 不会破坏底层预训练模型
• 专业数据和私有数据可以独立管理

• 输出质量通常不如微调
• 受 LLM 最大上下文长度的限制
• 提示词变长，导致成本更高、延迟更大

2、LLM技术栈

这套新兴的 LLM 技术栈可以拆成三个主要层和一个补充层：

• 数据层 —— 负责预处理和存储私有数据的嵌入
• 编排层 —— 协调各个部件，检索相关信息，构建提示词
• 操作层（补充层）—— 提供监控、缓存、验证等工具
• 模型层 —— 实际执行任务的 LLM

为了直观，我们拿一个简单的应用来穿针引线：一款了解公司产品、政策和常见问题的客服聊天机器人。

2.1 数据层

数据层的核心任务，是对私有信息和补充信息做预处理和存储。整个过程可以分为三大步骤：提取、嵌入、存储。

• 提取

相关数据可能来自多个源头、多种格式。所以第一步是建立连接器，从数据存放的地方把它们抓出来。

拿客服聊天机器人来说，我们可能有个云存储桶，里面既有内部的 Word 文档和 PDF，也有公司网页抓下来的 HTML。CRM 系统里存着客户信息，需要通过外部 API 访问；SQL 数据库里是产品目录。更零散的还有协作 wiki 里记录的团队流程、以往的用户支持邮件……总之，得把所有适合场景的数据都收集起来。

之后，有一个可选步骤：剔除掉不必要的或机密的部分，把数据清理干净。另一个可选步骤，是将数据转换成统一的格式（比如 JSON），方便下游处理。

数据复杂度和规模不同，工具选择也不同。如果数据源不多、不常改动、格式也简单（文本、CSV、HTML、JSON、XML 等），那么轻量的文档加载器就够用了。它们能连接到数据源，完成基本的提取和转换。但如果需要聚合大量多样化的、甚至实时流式的数据，并且处理过程比较复杂，那就得上数据管道了。数据管道在扩展性、灵活性方面更强，延迟也更低。

• 嵌入

嵌入是一种数字表示，能捕捉语义信息，表现为向量。通过计算嵌入之间的距离，可以判断它们的相关程度。为提取的数据创建嵌入，能帮助我们快速分类和搜索非结构化数据。

要生成嵌入，需要用到嵌入模型，比如 OpenAI 的 Ada V2。这个模型接收输入文本（通常是字符串或 token 数组），返回嵌入输出。Ada V2 还能在单次请求中处理多个输入。截至 2023 年 12 月，Ada V2 可以通过 API 端点访问。

还有一个可选步骤是“分块”，也就是把大段文本切分成小片段。有各种分块方法，从简单的固定大小分块，到复杂的句子分割。如果输入文本太大，就必须分块，因为嵌入模型有大小限制。Ada V2 的最大输入长度是 8,192 个 token，数组维度不能超过 2,048。

• 存储

生成好的嵌入，连同原始提取数据，一起存到矢量数据库里，或者存到带有矢量搜索扩展的传统数据库中。

矢量数据库专门针对矢量数据的索引和存储做了优化，能实现快速检索和相似性搜索。它提供常规的数据库增删改查操作，并强调可扩展性、实时更新和数据安全。

如果只是需要简单的矢量搜索功能，直接给现有的传统数据库（SQL 或 NoSQL）加个矢量搜索扩展，往往更简单、更省事，还能利用上现有的数据库基础设施和经验。不过，这种做法的局限性也很明显——传统数据库和矢量数据库的优化方向不同。关系数据库侧重事务的一致性和原子性，而矢量数据库更看重搜索速度和可用性，对更新的最终一致性容忍度更高。硬把矢量搜索功能改造到传统数据库上，可能会拖累性能。而独立使用专用的矢量数据库，则意味着操作和维护都与现有数据库分离。

2.2 模型层

模型层就是那些开箱即用的 LLM，比如 GPT-4 或 Llama 2。选型时得根据你的特定目的、成本、性能和复杂度要求来权衡。对于客服聊天机器人，GPT-4 是个不错的选项——它在对话场景下经过优化，多语言支持很强，还有高级推理能力。

访问方法取决于具体的 LLM（是闭源的还是开源的）以及它的托管方式。通常，会有一个用于推理或提示执行的 API 端点，它接收输入并生成输出。

2.3 编排层

编排层是技术栈中的“主框架”。它负责协调其他层和外部的各种组件，提供处理 LLM 技术栈主要部分的工具和抽象。熟悉 MVC 架构的开发者，可以把它类比成其中的“控制器”。

走上下文学习路线时，编排框架的工作流是这样的：接收用户查询，根据模板和有效示例构建提示词，通过相似性搜索从矢量数据库里检索相关数据，必要时从 API 中获取额外信息，然后把整个上下文一起提交到指定 LLM 的端点，最后接收并处理输出。

拿简单的客服聊天机器人来举例，假设用户问的是退款政策：

1、框架里预设了一个包含指令和示例的提示模板。

• 指令是：“你是一位乐于助人且有礼貌的客服代表，回答用户的询问：{query}。下面是一些对话示例。”
• 少样本示例：[{input:“你们总部在哪里？”,output:“我们公司总部在加州洛杉矶。”},{input:“能查一下我的订单状态吗？”,output:“好的，我可以帮您查。”}]。

2、框架在矢量数据库中查询与“退款政策”相关的数据，得到结果：“购买后 30 天内，新的未使用商品允许退款。退款在 3-5 个工作日内按原始支付方式发放。”

3、框架把带上下文的整个提示发送给选定的 LLM（比如 GPT-4）进行推理。

4、GPT-4 返回：“购买后 30 天内，我们接受新的未使用商品退款。您预计在 3-5 个工作日内收到按原始支付方式返还的退款。”

5、框架把 LLM 的输出回复给用户。

LangChain 就是一个典型框架，它同时提供了 Ja vaScript 和 Python 两种语言的库，封装了通用组件的接口和集成，还能把多个步骤组合成“链”。除了编程框架，也有专门用于编排的图形化工具。

比如 Flowise，它建立在 LangChain 之上，提供了图形化布局，可以直接在视觉上把各个主要组件链接起来。

2.4 操作层

当基于 LLM 的应用进入生产环境、开始规模化的时候，操作层（LLMOps）就该登场了。它能提升性能和可靠性。下面是一些常见的 LLMOps 工具方向：

• 监控
  —— 记录、跟踪和评估 LLM 的输出，为改进提示构建和模型选择提供依据。

• 缓存
  —— 利用语义缓存来存储之前的 LLM 输出，减少重复调用，从而降低响应时间和成本。

• 验证
  —— 对 LLM 输入进行检测，防止提示注入攻击（一种恶意操纵模型行为的手段）。同时也可以根据规则对 LLM 的输出进行验证和修正。

还是拿客服聊天机器人来说：可以记录每次 LLM 的请求和响应，事后评估回答的准确性和有用性。如果很多用户都问同样的退款政策，答案直接从缓存里取就行，不用每次都去调 LLM 端点。为了防范恶意输入，可以在提示构建和推理之前验证用户消息。把这些 LLMOps 工具组合起来，我们的应用才能变得更高效、更健壮。

3、结束语

我们一起梳理了微调与上下文学习这两条路径，它们能帮助你在调整和预训练模型之间做出选择，也让上手变得更简单。

现在，一套流行的技术栈正在通过上下文学习的方式，连接起开发者与 LLM。这个技术栈由三个主要层（数据层、模型层、编排层）和一个补充层（操作层）构成。每一层都有现成的工具，能让基于 LLM 的应用开发真正跑起来。