构建自然语言与大语言模型（LLM）流水线——深入理解大语言模型上一章帮助我们建立了一个概念基础，使我们能够通过流水线和生

上一章帮助我们建立了一个概念基础，使我们能够通过流水线和生成式 AI 项目生命周期来解决与 LLM 相关的问题。

在本章中，我们将进一步深化对 LLM 的理解，追踪它们从 2023 年基础基线演化到 2025 年专用化、智能体化架构的发展路径。我们将首先回顾定义上一代模型与框架的核心原理，包括 Transformer 架构，以及对 RAG、提示（prompting）和微调（fine-tuning）的最初定义。随后，我们将探讨 2024 至 2025 年的大分化：范式从单体模型转向两类新的主导模型——超高效率的小语言模型（SLMs） 与 强大的推理语言模型（RLMs） 。这一分析还将深入剖析 2025 年发布的 DeepSeek-R1，这是一个向整个开发者社区开源高级推理能力的技术事件。对于开发者而言，这意味着“一种模型包打天下”的时代已经结束；架构师现在必须根据运营成本、时延与认知深度之间的具体权衡来选择模型。

接下来，我们将追踪开发者交互方式的演进，梳理一个关键性的概念转变：从 2024 年“提示工程”的技艺，转向 2025 年“上下文工程”的正式学科，并定义这一学科所要求的新策略。

最后，我们将分析编排框架生态如何为了适应这一新现实而完成专门化。我们将考察 2025 年时点上的 LangChain / LangGraph 1.0 与 Haystack 2.0 的状态，详细说明它们分别在智能体编排与稳健数据流水线上的战略侧重点。这个分析最终将引出对本书所提出的混合架构的论证：Haystack 用于工具层，LangGraph 用于编排层，这一模式已在第 1 章中提出。

到本章结束时，你将理解 LLM 发展中的那些基础性架构与概念转变。你将能够超越简单的 RAG 流水线，开始设计构成现代 AI 工程核心的复杂、可靠且带状态的智能体系统。

本章将涵盖以下主题：

LLM 概览
与语言模型交互
数据存储、检索与记忆：向量存储的作用
理解 LLM 部署的经济学：推理成本

技术要求

在整本书中，我们将使用 uv 进行包管理（https://docs.astral.sh/uv/getting-started/installation/）。这样可以帮助我们在本书基于代码的练习中管理依赖。

你还需要安装 Python 3.11 或更高版本（https://www.python.org/downloads/）。

包含练习的 GitHub 仓库地址如下：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines

从第 2 章开始，每一章都会配套 Jupyter Notebook、.py 脚本以及详细文档，以帮助你练习并应用学到的概念。举例来说，第 2 章的练习位于该仓库的 ch2 文件夹中：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/tree/main/ch2

后续章节也遵循同样的模式。

我们建议你安装 Miniconda 和 VS Code。这样可以帮助你运行 Jupyter Notebook、脚本，并管理依赖。

Miniconda 安装：https://docs.conda.io/projects/miniconda/en/latest/
VS Code 安装：https://code.visualstudio.com/docs/setup/setup-overview

我们还建议你创建一个 GitHub 账号（https://github.com/），并确保你可以克隆和拉取该仓库，这样你就能在本地获得一份可以执行和交互的代码副本。Windows 用户请使用 GitBash，Linux 和 macOS 用户请使用 Git，这样会更方便在本地访问这些材料。

要获取代码和练习，请按如下方式克隆仓库：

打开 VS Code，点击 File | New Window，然后点击 Terminal | New Terminal。确保你的终端是 Bash 或命令行类型。

在终端中，依次输入以下命令（命令以前面的 $ 符号标识），每输入一条后按回车：

$ git clone https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines.git
$ cd building-natural-language-and-LLM-pipelines/
$ cd ch2
$ uv sync
$ source .venv/bin/activate

这将创建并激活一个虚拟环境，其中包含执行 Jupyter Notebook 和脚本所需的依赖。每个文件夹的依赖会有所不同。对于每个章节目录，推荐的工作流是：在 VS Code 中打开一个新窗口，打开对应章节目录，初始化终端，运行 uv sync 安装依赖，然后运行：

source .venv/bin/activate

随后，这个环境将作为 Jupyter Notebook 的内核来使用。

请在 VS Code 的扩展市场中启用 Jupyter Notebook 扩展。当你打开一个 Notebook 时，点击 Select Kernel，再点击 Python Environments，然后选择本地虚拟环境。它会命名为 rag-with-haystack-ch2，并指向路径 .venv/bin/python。

此外，我们还将创建一个 .env 文件。在你的 ch2 目录中，点击 File 选项卡，选择 Create new file，并在克隆下来的仓库中创建一个名为 .env 的文件，最好放在 jupyter-notebooks 子目录下。这个 .env 文件包含诸如 OpenAI API 以及其他将要探索的 API 服务凭证。示例可参考：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/.env.example

在动手练习过程中，你可以选择使用 Ollama（https://ollama.com/）来运行本地 LLM，或者使用托管在 OpenAI 上的模型。若要获取本地模型，请下载并安装 Ollama 客户端（https://ollama.com/download），然后在终端中运行 ollama pull <model-name> 来选择并拉取模型。可用模型见：
https://ollama.com/search

如果你更愿意使用 OpenAI API，请创建一个账号并生成 API key（https://openai.com/api/）。

LLM 概览

LLM 是一类深度学习模型，专门用于以类似人类交流的方式处理和生成文本。这些模型通常采用诸如 Transformer 之类的深度学习架构（Vaswani et al. 2017, 2023），参数规模从数亿到数十亿不等。它们通常在多样化数据集上进行训练，这些数据集可能包括书籍、网站或文章的集合。这使它们能够生成句子、回答问题、撰写文章以及创作故事。它们的训练使其能够结合上下文并进行推断。由于规模庞大，LLM 在训练阶段以及推理阶段都需要大量计算资源。

在接下来的小节中，我们将更仔细地考察 LLM 的常见应用，并更深入地理解它们是如何工作的、存在哪些不同类型的架构，以及我们可以采取哪些步骤来评估其结果。

LLM 的使用场景

我们将 LLM 的应用概括为四大类：理解、生成、检索、交互。

理解——经典 NLP：LLM 可用于分析客户评论、社交媒体帖子或问卷回复，以判断情感倾向（正面、负面、中性）。它们还可用于文本分类（如垃圾信息检测、主题分类），以及命名实体识别，也就是识别并分类文本中的人名、组织名和地名等命名实体。

生成——文本生成：在这种情况下，内容创作包括各种帮助用户生成书面内容的任务，例如营销材料、社交媒体帖子等。它也包括帮助开发者根据自然语言描述生成代码片段等任务。

GitHub Copilot 就是一个由 LLM 驱动的典型应用，它帮助开发者生成代码片段和文档。然而，近年来，Copilot 已经远远超越了简单的代码补全，演化为一个复杂的智能体系统（GitHub, 2025）。这种演化是更大趋势的一部分，这一趋势被称为 agentic DevOps（Microsoft, 2025），其核心是一种新范式：智能体与开发者协作，自动化并优化软件生命周期的每一个阶段。

另一大模型家族是 Anthropic 的 Claude，包括 Claude 3.5 系列（Sonnet、Opus 和 Haiku）。以 Claude 3.5 Sonnet 为例，它在研究生水平推理（GPQA）和代码能力（HumanEval）等方面刷新了行业基准，在某些评测中往往超过 GPT-4o 等竞争模型（Anthropic, 2025; Galileo, 2025; Dev, Nik L, 2025）。

检索——让模型扎根于数据：在将 LLM 用于信息检索时，其应用包括通过理解查询上下文来增强搜索引擎的检索结果，也包括构建基于文档集合的问答系统。此外，LLM 还可用于从一组文档中提取信息并进行转换，例如用来填充结构化数据库。

交互——对话式智能体与助手：当 LLM 被用于对话智能体时，常见应用包括聊天机器人（如 ChatGPT）、虚拟助手，以及内容审核机器人。这些应用可用于提供客户支持、回答常见问题，并以自然语言与用户互动。它们也可用于自动检测和过滤文本中的不当内容。

接下来，我们将考察 2023 到 2025 年间 LLM 发生的关键变化，以理解 AI 如何从简单的文本生成器演变为复杂的推理编排器。这一时期标志着一个战略转变：从单体式、“一刀切”的模型，转向一个高度专门化的格局，在这里，开发者必须在适合低成本边缘部署的超高效 SLM 与 用于复杂多步逻辑推演的强大 RLM 之间做出选择。

2023 年基线：回顾 LLM 的基础原理

为了理解 2024 到 2025 年间发生的深刻变化，首先有必要建立起 2023 年的基础知识基线。

LLM 是一类深度学习模型，专门用于以类似人类交流的方式处理和生成文本。驱动 LLM 革命的引擎，是 Transformer 架构。这一架构最初在 2017 年论文 Attention Is All You Need（Vaswani et al. 2017, revised 2023）中提出，其设计从循环式顺序处理转向了对 token 的并行处理。通过摆脱循环结构，Transformer 在训练时可以实现更高程度的并行化，并且无需逐个位置处理序列中的符号，就能够建立输入与输出之间的全局依赖关系。

图 2.1——Transformer 架构，灵感来自 Vaswani 等人所描述的过程

下面是该架构中的关键组成部分：

输入（Inputs） ：准备一段自然语言文本序列，并对其进行分词；每个 token 会被分配唯一 ID。这些 ID 再通过嵌入层转化为向量。
位置编码（Positional encoding） ：Transformer 模型本身并不天然理解词语在序列中的顺序，因此必须显式地将位置信息融入 token 嵌入中。位置编码会向输入 ID 序列中的每个 token 注入其相对或绝对位置的信息，从而使模型能够利用序列结构。位置编码可以是绝对式，也可以是相对式。绝对位置编码是在原始 Transformer 架构中提出的。相对位置编码则是在之后引入的（Shaw et al., 2018），以提升 Transformer 在某些任务上的表现，尤其是在那些词与词之间的相对位置比其在句中的绝对位置更重要的任务中。
注意力机制（Attention mechanism） ：主要有两种类型：
- 自注意力（Self-attention / 点积注意力） ：这一技术的核心在于自注意力机制，它使模型能够根据特定编码，为每个词分配相关性权重。该机制有助于获取每个词相对于句中所有其他词的上下文，并量化它在某一任务下相对于其他词的重要程度（也就是该关注多少）。
- 多头注意力（Multi-head attention） ：这就是把自注意力并行运行多次的过程。对于每一个“头”（自注意力层），都会使用不同的注意力权重，最后再将结果拼接起来。这样模型就能够以不同方式关注序列中的不同部分。
前馈神经网络（Feed-forward neural networks） ：每一层都包含一个全连接前馈网络，该网络在每个位置上独立且相同地应用，通过两个线性变换及其间的 ReLU 激活，对表示进行处理。这个子层有助于模型进一步细化其对每个具体位置输入的理解。
层归一化（Layered normalization） ：这一技术用于在加速学习的同时稳定学习过程。它会应用在每个多头注意力块和前馈神经网络之后。随着信息在层间流动，模型会不断细化对输入文本的理解，从而捕捉词语之间的关系与依赖。
输出层（Output layer） ：线性层会将解码器输出投影到一个更大的 logits 向量中，而 softmax 函数则将这些值转化为对下一个 token 的预测概率。两者结合起来，用于确定模型词表或类别上的最终概率分布。输出以向量形式存在，其中每个向量对应输出序列中的一个词。输出格式取决于具体应用类型。例如，当目标是文本生成时，结果是对词表的概率分布；当目标是分类时，结果则是对类别的概率分布。
后处理（Post-processing） ：在某些情况下，最后一步是将向量中的 token ID 转回人类可读的语言。

这种架构设计催生了三大主要“家族”的模型，它们主导了 2023 年的格局：

生成式预训练 Transformer（GPT） ：这是 OpenAI 开发的模型，包括拥有 1.1 亿参数的 GPT、15 亿参数的 GPT-2、1750 亿参数的 GPT-3（Radford et al., 2018, 2019, 2020），以及拥有 1.7 万亿参数的 GPT-4（OpenAI, 2023）。它的特点是自回归模型，即通过预测句子中的下一个词来进行训练。GPT 在聊天机器人中的使用，以 OpenAI 的 ChatGPT 为代表。这类模型适用于各种生成性任务，例如故事生成、摘要生成和代码生成。
双向编码器表示模型（BERT） ：这是 Google Research 开发的模型（Devlin et al., 2018）。它是一个多层双向编码器，其架构与 GPT 类似，但加入了双向掩码机制，并将下一句预测作为额外的预训练任务。类似 BERT 的模型适用于那些需要理解输入内容的任务，例如问答应用。
双向与自回归 Transformer（BART） ：这是 Facebook AI 提出的模型（Lewis et al., 2019），它将自回归 Transformer 与双向 Transformer 结合了起来。作者观察到，BERT 的双向与自编码性质非常适合分类等下游任务，但不适合生成任务，因为在生成任务中，当前生成的词应只依赖此前已生成的词。另一方面，GPT 的单向自回归方法非常适合文本生成，但不适合那些需要理解整个序列信息的任务，如分类。BART 则将这两种方法结合了起来。

表 2.1 总结了流行的 Transformer 模型、它们的架构以及适用场景：

Transformer 类型	架构	类模型	关注点	示例
自回归	Decoder	GPT-like	生成类任务	聊天机器人
自编码	双向 Encoder	BERT-like	对输入的理解	问答
序列到序列	Encoder-decoder	BART-like	需要输入条件的生成任务	语言翻译

表 2.1——流行的 Transformer 模型

当人们开始尝试使用这些模型时，一个问题变得越来越突出：如何让模型适配具体需求。下面我们就来看这个问题。

2023 年的交互工具箱：提示、微调与 RAG

在 2023 年，使用这些庞大的单体模型所面临的主要挑战有两个：其一是幻觉（生成看似合理、但事实上错误或毫无意义的内容），其二是训练、微调和推理的巨大计算成本。为了应对这些挑战，出现了多种彼此竞争的缓解策略：
提示（prompting） ，也就是通过提供特定输入或指令（即“提示”）来引导 LLM 生成响应；
微调（fine-tuning） ，即在一个较小的、领域特定的“指令—输出”数据集上，进一步训练一个预训练 LLM；
以及 检索增强生成（RAG） （Lewis et al. 2021），这是一种结合预训练参数化模型与外部文档的非参数稠密向量索引的方法，用于提升性能和事实性。

下面列出几种流行的 LLM 微调技术：

指令微调（Instruction tuning, IT） ：Zhang 等人（2023；https://arxiv.org/abs/2308.10792）综述了截至 2023 年 8 月的指令微调相关文献。该方法会使用“指令—输出”对对 LLM 进行进一步训练，其中指令包含人类给出的任务说明，输出则是对该说明的期望回应。
基于人类反馈的强化学习（RLHF） ：Ouyang 等人（2022；https://arxiv.org/abs/2203.02155）将 RLHF 应用于 GPT-3，作为一种微调技术。该技术包含三个关键步骤：收集示范数据以训练监督策略；收集比较数据以训练奖励模型；再利用强化学习，基于奖励模型对策略进行优化。

为了在控制计算成本的同时提升 LLM 的性能，人们还探索了以下技术：

参数高效微调（PEFT） ：Lialin 等人（2023；https://arxiv.org/abs/2303.15647；https://huggingface.co/docs/peft/index）对 PEFT 方法进行了系统比较。这一技术旨在只针对模型参数的一个子集进行适配或微调，而不是调整全部参数。由于 LLM 的参数总量可达数十亿级，对每个参数都进行微调既昂贵，也并非总是必要。因此，通过 PEFT，我们能够在降低调参计算成本的同时，让模型适配我们的具体场景。
低秩适配（LoRA） ：Hu 等人（2021；https://arxiv.org/abs/2106.09685）提出了这项技术，其核心目标是冻结 Transformer 架构中的预训练层（Vaswani et al. 2017, 2023），从而减少下游任务中的可训练参数数量。LoRA 的意义在于，它使我们能够以更少的内存消耗加速 Transformer 架构下的 LLM 微调。该技术通过低秩分解，用矩阵表示权重更新。新的矩阵会被训练来适应新数据，其优点是整体引入的改动数量较少。最终结果由原始权重与适配后的权重共同组成。详见：https://huggingface.co/docs/peft/main/en/conceptual_guides/lora
模型蒸馏（Model distillation） ：这种方法试图弥合大语言模型与较小语言模型之间的精度差距。其核心思想是把大语言模型当作教师模型来训练学生模型，最终目标是让学生模型的行为尽可能接近教师模型。
RAG：正如 Lewis 等人 2021 年论文（https://arxiv.org/abs/2005.11401）中介绍的那样，检索增强生成（RAG）是一种微调配方，它为预训练、具有参数化记忆的生成模型赋予了非参数记忆。在这种架构中，参数化记忆是一个预训练的序列到序列（seq2seq）Transformer（具体来说是 BART），而非参数记忆则由一个通过神经检索器访问的 Wikipedia 稠密向量索引构成。通过把检索到的文档视为潜变量，模型可以端到端训练，从而兼具“闭卷生成”的灵活性与“开卷检索”的事实性。与标准 seq2seq 模型相比，RAG 已被证明能够生成更具体、更多样且更符合事实的语言，从而有效减少幻觉，同时还能通过简单替换检索索引的方式轻松更新世界知识。本书所讨论的 2025 年现代 RAG 流水线，则使用了像 GPT-4o-mini 这样的更新模型。

在 2023 年的语境中，RAG、PEFT 与 LoRA 常常被视作一组同层级、彼此竞争的选择。面对幻觉问题时，开发者通常会问：“我是该用 RAG，还是该微调模型？”为了做出选择，开发者通常会参考以下标准：

RAG：当模型需要访问最新的、事实性的或专有的数据，而这些数据并未包含在其初始训练中时，就适合使用 RAG。它是通过让模型扎根于外部文档的非参数稠密向量索引来减少幻觉的主要工具。
PEFT 与 LoRA：当模型需要适配特定领域风格、遵循特定指令—输出格式，或在一部分任务上提升表现，而又不想承担微调全部参数的成本时，就适合使用这类技术。LoRA 尤其通过冻结预训练层并采用低秩分解，降低内存消耗并加快过程。

RAG 已经从一种简单的缓解策略，演化为企业可靠性的基础架构模式。与此同时，微调与新的强化学习方法，也已经成为模型创建流水线本身的一部分。现代技术栈不再是“RAG 还是微调”的选择题，而是要构建一种同时使用 RAG 与专用模型的系统。

2024—2025 年模型架构的演进：SLM 与 RLM

2023 年那种“一种模型适用于所有场景”的范式已经瓦解，取而代之的是一个由高度专门化定义的 2025 年市场。这个模型谱系针对不同任务、成本与部署目标进行了优化，并分叉出两个主要且看似相反的方向：超高效 SLM 与 超先进 RLM。

SLM 代表着“更小、更快”的趋势，其特征不仅仅体现在参数量较小（通常低于 100 亿），还体现在其精简高效的架构上。这些紧凑型系统，如微软的 Phi-3-mini（38 亿参数）、清华的 MiniCPM-2.4B，以及苹果的 OpenELM，都是为了在尽量小的计算与内存开销下提供高性能而专门设计的。通过在分类、抽取和轻量推理等高吞吐场景中提供强劲表现，SLM 使得在 IoT、汽车和可穿戴设备等对成本敏感的场景中，实现实时、保护隐私的端侧 AI 成为可能，而这些场景对低成本推理的要求非常关键。

与之相对，RLM 代表的是“更聪明、更深入”的跃迁。这些模型是专门为多步逻辑推演而非纯粹的下一个 token 预测所设计的混合架构。到 2025 年，这一类别的代表包括 OpenAI 的 o3 和 o4-mini，以及开源的 DeepSeek-R1。总体而言，这些模型展示出一种新兴范式：它优化的目标不再只是速度或规模，而是推理本身。

SLM 的战略价值，来自明确的业务与产品需求：

成本效率：对于许多常见且高频的 AI 任务，例如文本分类、情感分析或简单的数据抽取，使用一个庞大而昂贵的模型是极其低效的。
边缘 AI 与端侧部署：SLM 的小体积使其能够在资源受限的硬件上本地运行。这是下一代 Edge AI 与 IoT 设备的关键使能因素，包括智能摄像头、车载助手和可穿戴健康监测设备。这种能力使得实时数据处理、零时延响应以及更高隐私性成为可能，因为数据无需发送到云服务器（Boston Institute of Analytics, 2025）。

与“更小、更快”的趋势并行，另一类“更聪明、更深入”的新模型也出现了。RLM 并不只是放大版 LLM；它们是一种新的混合架构（Besta et al., 2025）。RLM 被明确设计用来执行多步、逻辑性强且经过审慎思考的推理，超越了传统 LLM 所依赖的那种快速模式匹配。

Besta 等人（2025）概述了 RLM 的架构蓝图，它结合了三个不同组件：

LLM（作为知识库） ：传统大规模 LLM 的权重充当基础，提供世界知识与语言流畅性。
强化学习（RL）（作为策略 / 价值模型） ：使用 RL 框架来引导生成过程。与常规 LLM 只优化下一个 token 预测不同，RL 模型优化的是一个长期策略或结果。
搜索启发式（作为探索器） ：整合诸如 Monte Carlo Tree Search（MCTS）或 Beam Search 等算法，让模型能够探索“思维树”或“推理图”。模型可以生成多个潜在解路径，对其进行评估，并从无希望的路径上回溯。

2025 年开源生态中最重要的事件，是 DeepSeek 时刻（DeepSeek Moment） 。2025 年 1 月 20 日，中国公司 DeepSeek 发布了其 R1 模型（https://api-docs.deepseek.com/news/news250120），在 AI 世界引发了巨大震动。

它的重要性体现在两个方面：

性能：DeepSeek-R1 在推理表现上达到了与全球最顶级的闭源专有模型同等的水平，包括 OpenAI-o1（Deepseek et al., 2025）。
可及性：它采用宽松的 MIT 许可证发布，并且据报道其训练成本极其高效（低于 600 万美元）（Deepseek et al., 2025）。

这一事件从根本上民主化了高级推理能力，证明推理型 LLM 并非万亿美元级公司才拥有的专属能力。DeepSeek-R1 的成功并不是简单扩大规模的结果；正如其技术报告所揭示的，那是一次算法与架构上的突破。

首先，该模型构建于 2024 年 12 月发布的大型 DeepSeek-V3 基础模型之上。真正的创新在于它的训练流水线。

核心算法突破是 Group Relative Policy Optimization（GRPO） （Deepseek et al., 2025; Shao et al., 2024）。GRPO 是一种新型 RL 算法，它不再使用单独的 critic 模型，而是根据同一提示下采样输出组内部奖励的均值与标准差来计算基线和优势分数。在典型的 LLM 强化学习设置中，通常会使用一个 critic 模型（通常是神经奖励模型）来估算基线，并给策略模型提供反馈。这个基线是计算某个输出“优势”的必要条件，也就是判断某个答案比平均水平好还是差多少。由于 critic 模型通常与策略模型规模相当，这会使训练的内存与算力需求翻倍。GRPO 则通过用基于组的相对得分替代神经基线，消除了对独立 critic 模型的需求。

在训练中，对于提出的每一个问题，算法都会采样一组不同的输出。系统不再去问一个单独的 critic 模型“这个答案有多好”，而只是简单地比较这一组输出内部的奖励。某个答案的优势，是通过计算它的奖励相对于该组其他答案奖励均值和标准差的位置来得到的。通过使用这些组内统计量作为基线，GRPO 在大幅降低训练流水线计算与工程复杂度的同时，实现了与传统 RL 相当的优化信号。

其次，最终的 DeepSeek-R1 模型，是一个复杂多阶段训练流水线的产物：

阶段 1：纯 RL
团队首先在基础模型之上，仅使用 RL（GRPO）训练出了 DeepSeek-R1-Zero（https://huggingface.co/deepseek-ai/DeepSeek-R1-Zero）。这个实验取得了成功；但它存在可读性差和语言混杂的问题。
阶段 2：多阶段训练
为了打造最终完善版 DeepSeek-R1，团队设计了一个多阶段流水线：首先，用一小批冷启动数据进行监督微调（SFT） （https://huggingface.co/learn/llm-course/en/chapter11/1），这些数据由高质量、长链式思维示例组成，为模型提供了结构化推理的初始脚手架。接着，团队应用 GRPO，让模型超越模式模仿，鼓励其进行审慎的、逐步的问题求解。在此基础上，他们又采用拒绝采样（rejection sampling） ，从经过 RL 增强的模型中筛选最强输出，构建出一个更大、更干净的合成数据集，再进行第二轮 SFT，以进一步精炼基础模型。最后，他们在所有任务场景上又进行了一次全局 RL 训练，作为抛光阶段，以对齐模型的推理深度、格式一致性与整体表现。

这次开源发布证明：高级推理是一个算法与架构挑战，可以通过新型 RL 技术与精心设计的训练流水线来解决，而不仅仅是一个单纯扩大规模的问题。对于开发者而言，这一事件标志着：推理能力的力量已经成为一个开放、可获取的工具，可以被整合进他们的应用中。

这也自然引出了本章的下一部分：与语言模型交互。

与语言模型交互

从 2023 到 2025 年，模型架构的演进不仅重塑了 AI 版图；它还从根本上改变了开发者与语言模型协作的方式。随着 SLM 和 RLM 分化为两条专门化分支，那些指导早期 LLM 时代交互设计的假设已经不再成立。审慎推理模型、智能体流水线以及长上下文系统的出现，带来了新的失败模式、新的机会，也带来了新的工程挑战。

在一个以快速创新和专门化模型爆发为特征的环境中，传统意义上的提示工程已经不再足够。开发者的角色，已经从编写孤立的指令，扩展为对整个上下文进行编排：也就是现代 AI 系统所依赖的动态组合，包括提示词、检索得到的知识、工具定义、智能体状态，以及中间推理步骤。随着模型具备更深层的推理能力，智能体开始沿着长决策链运行，上下文窗口不再只是一个被动的输入缓冲区，而变成了一个主动的工程操作面。

这种从“写巧妙提示词”转向“设计可靠信息流”的变化，标志着 2025 年 AI 开发中最重要的概念跃迁之一。要在 SLM、RLM 或任何智能体系统之上构建稳健应用，开发者必须掌握上下文工程（context engineering） ——这是一门关于如何整理、组织、压缩、隔离并管理模型在时间过程中所消费信息的学科。

掌握上下文工程，会给构建 2025 年生产级 AI 系统的开发者带来几个关键收益：

提升可靠性与事实性：通过整理上下文窗口中的信息，开发者可以让模型扎根于经过验证、且最新的数据之上，这是企业级应用中抵御幻觉的首要防线。
缓解上下文腐化（context rot） ：系统化地管理这个主动工程面，可以防止由于输入过长或噪声过多而导致的性能下降，确保模型即便在复杂、多步任务中，也能聚焦于相关信息。
运营成本效率：诸如压缩（compress）之类的技术，可以让开发者把大型数据集提炼为 token 更高效的表示形式，从而降低持续性的推理成本。
把上下文窗口视为动态记忆层：借助这种方式，开发者能够构建能记住过去交互并随着时间更新其知识的智能体，从而在长时会话中保持行为一致性。

在探讨支撑这一学科的实际框架与技术之前，我们首先需要理解：为什么单靠提示词编写会失效，以及上下文工程是如何出现并取代它的。为了帮助你开始与 LLM 交互，我们已经创建了一组 Notebook：

探索如何使用 Ollama 对本地模型进行提示：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/01_prompt-ollama-model.ipynb
探索如何使用 Ollama 上的本地模型创建一个智能体：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/02_create-simple-agent.ipynb
探索基于 Document 对象的 RAG 入门：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/03_document-qa-langchain.ipynb

这些资源有助于说明：如今，借助 Python 生态，已经可以创建智能体、增强 LLM，并使用 LLM、SLM 和 RLM。虽然这些例子比较简单，但它们很好地展示了下一步要进入的主题：上下文工程。

2025 年开发者交互方式的演进：从提示工程到上下文工程

要构建可靠的应用，理解从提示工程到上下文工程这一概念跃迁至关重要：

提示工程（Prompt Engineering），2024 年的“手艺” ：在 2024 年，提示工程被定义为设计有效提示词的艺术。它是一种通过编写精确指令（即 prompt），来诱发 LLM 生成一次性、特定且理想响应的实践。这种方法聚焦于微调单个词语，因此更准确地说，它应被称为提示词雕琢（prompt crafting） 。它对简单任务是有效的，但在复杂、多步应用中就会失效（Datacamp, 2024）。
上下文工程（Context Engineering），2025 年的“学科” ：这是 2025 年的新型正式学科。它是提示工程的超集。焦点不再只是 prompt 本身，而是转向一种细致的艺术与科学：如何把恰到好处的信息装入上下文窗口，以服务于当前这一步（LlamaIndex, 2025; Nearform, 2025）。

它是一门关于“如何从一个不断演化的可能信息宇宙中，筛选出要进入有限上下文窗口内容”的艺术与科学（Anthropic, 2025）。这个信息宇宙不仅包括 prompt，还包括通过 RAG 检索到的文档、工具（API）定义、聊天历史（记忆），以及前几步智能体执行产生的输出。

这种转变，是由简单提示法在智能体系统中的失效所推动的。一个在循环中运行的智能体，会不断生成越来越多的数据（Anthropic, 2025）。如果没有正式的工程纪律，这就会导致严重失败，例如上下文污染（context pollution） ：某一步中的幻觉会污染后续所有步骤的上下文，导致智能体追逐一套毫无意义的策略（Datacamp, 2025）。临时拼凑字符串的方式非常脆弱、难以调试，也无法扩展（Thatipalli, 2025），而且很快就会撞上上下文腐化问题（context rot） （Chroma Research et al., 2025）：模型在过长、噪声过多的上下文中性能下降。其他附加问题还包括上下文分心（context distraction） 、上下文混淆（context confusion） 和 上下文冲突（context clash） （Kubiya AI, 2025）。

接下来，我们将探讨当前围绕上下文工程的一些策略。这是一种正在形成中的实践，旨在解决上述挑战。

上下文工程的核心策略（2025）

上下文工程为开发者提供了一套实用工具箱，用于管理上下文窗口——而这已经成为现代 AI 系统中最有限、也最有价值的资源之一。到 2025 年，四个核心策略已经成为高效上下文管理的支柱：Write、Select、Compress、Isolate（Anthropic, 2025; Kubiya AI, 2025; Gibson AI, 2025; LangChain, 2025）。

Write（写入） ：把信息存储到当前上下文窗口之外，以便后续再检索。这是智能体记忆的基础。技术包括：
- scratchpads（草稿板） ：即智能体思考或计算所用的中间工作记忆；
- long-term memories（长期记忆） ：即把用户偏好、前次对话中的事实等，存储在外部数据库中（通常是向量存储）。
Select（选择） ：在真正需要的那一刻，动态地只把最相关的信息拉入上下文窗口，也就是一种“just in time”的检索策略。技术包括：
- RAG
- 记忆选择（从 write 阶段所写入的向量库中检索相关项）
- 动态工具选择，也就是只选择与当前任务最相关的工具
Compress（压缩） ：把大块信息提炼为更小、更节省 token 的表示，以压缩上下文并避免上下文腐化。技术包括：
- 总结（summarization）
- 工具结果清理（tool result clearing）
  比如，一个智能体调用某个工具后返回一大段 JSON。提取出所需的那一条信息之后，这种技术会把原始的大 JSON 从上下文中移除，只保留那条提取出来的事实。
Isolate（隔离） ：这是一个关键且高级的架构模式。它意味着把一个复杂任务拆分成若干彼此独立的隔间，每个隔间拥有一个干净、隔离的上下文窗口。这里使用的关键技术是子智能体架构（sub-agent architectures） ：主监督智能体接收一个复杂目标，例如深度研究。为了完成一个子任务，它会拉起一个子智能体。这个子智能体在自己独立、干净的上下文窗口中运行，完成深度研究，然后只把最终提炼后的总结返回给监督者。这样就能防止监督者的主上下文被子智能体那些细节繁杂、较为混乱的中间工作污染。这正是构建稳健、复杂智能体的关键。

这四种策略共同构成了现代上下文工程的核心，使智能体与推理模型能够在复杂、多步、真实世界应用中依然可靠地运行。

[进阶] 练习创建动态多智能体生成

探索多智能体创建：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/advanced-langchain-langgraph/03_multi-agent-workflow.ipynb

各种智能体架构的兴起，使得上下文工程成为保证这些架构可靠运行的一门正式学科。这也自然把我们带到了支撑这一新学科的框架层面。

2025 年框架架构的演进

2023 年这一代的框架包括 LangChain（https://www.langchain.com/）、LlamaIndex（https://www.llamaindex.ai/）和 Haystack（https://haystack.deepset.ai/），而它们在 2024 与 2025 年持续走向专门化。LangChain 过去那种临时拼接式的 chain 概念，已经随着 LangChain 1.0、LangGraph 和 LangSmith 的引入，被一个正式的智能体工程栈所取代：这是一套完整的开发、评估与部署智能体的工具体系。deepset 则把其开源框架从 Haystack 1.0 升级到了 Haystack 2.0，推出了用于可视化、管理和部署流水线的 deepset Cloud，并引入了智能体能力。

本书认为，各个框架的专门化——也就是 LangChain / LangGraph 专注于智能体工作流定义，Haystack 2.0 专注于流水线中心的能力——将促成如下的关注点分离：
编排层 用于智能体控制流，
工具层 用于稳健的数据流。

在本书中，我们会重点关注上述框架中的两个：LangChain 的 LangGraph 和 deepset 的 Haystack。虽然两个框架都提供了可导入的功能，用于处理 RAG、工具与智能体，但在本书中，我们将重点使用 Haystack 作为工具层，使用 LangChain 旗下的 LangGraph 作为编排层。

LangChain / LangGraph 1.0：智能体编排层

2025 年 10 月，LangChain 宣布发布 v1.0（LangChain, 2025），标志着其一次重大战略转向，也奠定了智能体工程栈的地位。这次转向的核心在于：高层 API 的 LangChain 1.0，被重构为建立在底层运行时 LangGraph 1.0 之上。下面我们更仔细地看一下。

LangGraph 是一个低层、基于图的智能体编排运行时。它存在的全部目的，就是构建高度可定制、可控且具持久性的智能体。

与其早期的 chain 概念不同（https://api.python.langchain.com/en/latest/langchain/chains.html），LangGraph 提供的是一个带状态的图（stateful graph） ，并显式支持：

循环（Loops） ：智能体的基本模式：
思考 → 行动 → 观察 → 思考
条件分支（Conditional branching） ：允许智能体做出动态决策。
持久状态与检查点（Durable state and checkpointing） ：智能体状态可以持久化，因此能够暂停与恢复，这对于长时间运行任务或人类在环（HITL）审批至关重要。

LangGraph 是 2025 年复杂、带状态控制流领域的领导者（Trixly, 2025）。LangChain 1.0 则被定位为构建 AI 智能体的最快方式。它的标志性特性，是新的 create_agent 抽象，它建立在 middleware（中间件） 之上。中间件是一组 hook，允许你在智能体循环中自定义行为，从而对智能体每一步行动实现细粒度控制（LangChain, 2025）。

[进阶] 练习在智能体中定义状态并引入中间件

探索一个包含状态和中间件的多智能体系统：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/advanced-langchain-langgraph/06_multi-agent-systems-middleware.ipynb

这个中间件，正是我们前面讨论的上下文工程策略的直接实现层。官方文档展示了中间件 hook（例如 before_model 和 wrap_tool_call）如何让开发者控制三类上下文：

模型上下文（model context） ：动态 prompt
工具上下文（tool context） ：动态工具选择
生命周期上下文（life-cycle context） ：总结、护栏（guardrails）

接下来，我们再看看 Haystack 在上下文工程这一领域中扮演什么角色。

Haystack 2.0：稳健的数据与工具层

Haystack 也在不断演进，并在 2025 年稳固了其市场定位：它是构建稳健、可衡量、可审计的数据处理流水线的“pipeline-first”框架（AlphaCorp, 2025）。它的架构是一个显式的有向图（DG）流水线，并带有严格的输入 / 输出数据契约，这使它非常适合复杂数据流。

2025 年的关键特性包括：

企业级 RAG：Haystack 的主要强项，在于其在知识系统上的稳定性（Trixly AI, 2025）。它提供了一个丰富、经过实战检验的组件生态，支持混合检索（结合稀疏 / BM25 与稠密 / 嵌入检索）、重排，以及对接所有主流向量数据库。
可衡量性与可审计性：由于其流水线是显式的，因此透明且可调试。更重要的是，Haystack 具备内建的评估节点，可以跟踪 RAG 质量指标，这让它成为对合规性与受监管行业尤为合适的选择，因为这些场景中“可审计性”是不能妥协的。
部署（Hayhooks） ：Haystack 2.0 提供了 Hayhooks，这是一个可以“轻松”把任意 Haystack 流水线一键部署为生产级 REST API 或 MCP Server 的框架：
https://docs.haystack.deepset.ai/docs/hayhooks

虽然 Haystack 也拥有自己的原生智能体组件，但 2025 年的市场分析清楚地表明：LangGraph 是复杂、带状态编排的领导者，而 Haystack 则领跑于可靠、可衡量的数据流水线（AlphaCorp, 2025; LindyAI, 2025; TrixlyAI, 2025）。

这种市场专门化——也就是 LangGraph 赢在智能体控制流，而 Haystack 赢在企业级数据流——并不意味着冲突，恰恰相反，它说明生态正在走向成熟。这也直接指向了 2025 与 2026 年的混合架构。

混合架构：工具层 vs 编排层

本书将要探讨的生产级智能体系统混合架构，是一种解耦的、基于微服务的架构，它通过分离关注点来组织系统。这种架构并不是“LangGraph 或 Haystack”，而是“LangGraph 和 Haystack”。

表 2.2 展示了二者各自的特点：

特性	LangGraph 1.0：编排层	Haystack 2.0：工具层
核心关注点	智能体控制流与编排	可靠的数据流与流水线
关键架构	带状态、基于图的运行时；支持循环、持久化、人类在环	显式的、基于有向图的流水线
优势	复杂、多步、带状态的工作流；可控的智能体循环；持久状态与检查点	可衡量、可审计、高性能 RAG；企业级稳定性；混合检索；可靠且可扩展流水线的自定义开发
理想使用场景	构建复杂智能体的大脑；客服机器人和多步研究智能体	构建一个可靠、可部署、供智能体调用的工具（例如 RAG-as-a-service 微服务）
2025 v1.0 创新	LangGraph runtime	Hayhooks 部署框架
上下文管理	通过 LangChain 1.0 的中间件实现	通过显式流水线组件实现

表 2.2——2025 年框架专门化（LangGraph vs. Haystack）

你完全有理由问：为什么不只用一个框架？答案是，在 2025 年及以后，开发者会为合适的工作选用合适的工具。在本书中：

我们在工具层使用 Haystack，因为它的显式有向图、混合检索组件和评估节点，本就是为创建可审计、高性能且可靠的 RAG 流水线而设计的。它是数据流领域中的最佳框架。更重要的是，Haystack 允许把通用或自定义流水线部署为微服务，使其成为任何强调严谨性、数据来源可追溯性和可扩展性的智能体框架中的强大补充。
我们在编排层使用 LangGraph，因为它带状态、可循环的图运行时，是专门为当下上下文工程所需的复杂、持久且可控控制流而设计的。

试图强行让一个框架去做另一个框架最擅长的事，往往会带来摩擦。在 LangChain / LangGraph 中从零搭建一个可衡量的 hybrid-RAG 流水线当然可以，但那等于忽略了 Haystack 已经提供的、经过实战检验的一流组件。反过来，在 Haystack 中构建复杂、带状态、持久化的智能体循环也并非不可能，但这并不是该框架的核心专长。它优化的是有向图式数据流；虽然也支持循环图，但其中的组件流水线框架，使复杂智能体工作流的管理难度远高于 LangGraph 的对应实现。因此，本书认为，混合架构将成为一种主导性的设计模式，并体现出一种成熟的工程纪律。

本书将主要聚焦于工具层，并在这些工具以 MCP Server 或 REST 端点微服务方式暴露出来时，把上下文工程纳入编排层的一部分。我们将从掌握 RAG 流水线开发、自定义组件开发、流水线评估和流水线部署开始。本章也提供了使用 LangGraph 创建智能体的高级 Notebook 作为参考，后续章节中我们还会再次回到这些内容。

练习：理解状态

使用 LangGraph 创建一个简单图：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/advanced-langchain-langgraph/04_understanding-state-graph.ipynb

练习：定义一个有状态智能体

使用 LangGraph 创建一个带单一工具的简单有状态智能体：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/advanced-langchain-langgraph/05_graph-based-agent-with-tools.ipynb

[进阶] 练习：创建带状态和中间件的多智能体系统

使用 LangGraph 和中间件探索多智能体创建：
https://github.com/PacktPublishing/Building-Natural-Language-and-LLM-Pipelines/blob/main/ch2/jupyter-notebooks/advanced-langchain-langgraph/06_multi-agent-systems-middleware.ipynb

一个同时结合这两个框架的端到端工作流示例如下：

用户提出一个问题。这个问题会发送给我们的主智能体，而主智能体由一个 LLM 驱动。
智能体判断自己需要外部信息，因此它会调用一个可以搜索知识库的工具。
该工具把问题发送给我们的 API（也就是已部署的 Haystack 流水线）。这个 API 会在幕后运行一整套 RAG 流水线。
这个 RAG 流水线（以微服务形式部署）会执行以下工作：
- 把问题转换为嵌入向量
- 找到最相关的文档
- 构造一个有帮助的提示词
- 再调用另一个 LLM 生成一个基于事实的答案
API 以干净的 JSON 格式返回结果。
工具把这个结果返回给智能体。
此时，智能体手上有两样东西：
- 用户的原始问题
- 来自 RAG 工具的检索上下文
智能体结合二者，写出最终答案并完成这轮对话。

这当然也可以用简单的 LangChain Python 对象来完成，但使用 LangChain 与使用 Hayhooks + Haystack 的核心区别在于：我们的 RAG 工具不再只是一个从内存中读写文档的朴素 Python 对象。它是一个可扩展的服务，能够查询并处理成千上万份各种格式的文档，包括文本、表格、音频和图像。

这正好引出了我们接下来要讨论的、RAG 与智能体架构中的关键组成部分：向量存储（vector stores） 。

数据存储、检索与记忆：向量存储的作用

在探讨了面向 2025 年智能体技术栈所提出的混合架构之后，我们现在必须讨论支撑它的数据层。这已经超越了 2023 年把 RAG 仅仅视为一种简单缓解策略的看法，而是要分析向量数据存储在 2025 年所扮演的角色。这类专用数据库不仅是高级 RAG 的基础技术，更关键的是，它们还是前文所讨论的那些有状态智能体系统所需的持久长期记忆层的基础技术。

正式定义与 2025 年的功能

向量数据库，或称向量存储（vector store） ，是一种专门设计用于存储、管理和索引高维向量数据的数据库系统（IBM, 2025）。与存储标量数据（例如文本、数字、JSON）的传统关系型数据库或 NoSQL 数据库不同，向量数据库将数据存储为数学向量，也就是固定长度的数字列表（Wikipedia, 2025）。这些向量被称为嵌入（embeddings） ，它们是由嵌入模型生成的数值表示，能够捕捉文本、图像和音频等非结构化数据的语义含义与上下文细微差别（SingleStore, 2025）。

向量数据库的主要功能并不是进行精确匹配查询。相反，它实现的是一种或多种近似最近邻（approximate nearest neighbor）算法。这种设计使数据库能够依据高维空间中的概念相似性或语义相似性来检索记录，而不是仅靠简单的关键词匹配。这种能力，正是现代语义搜索背后的引擎（Wikipedia, 2025；SingleStore, 2025）。

在 2025 年的语境中，这些系统已经不再是小众技术。它们已被优化用于存储和查询 LLM 与神经网络应用中的向量嵌入（LakeFS, 2025）。它们的迅速普及，完全由生成式 AI 的扩散所推动，已经成为重要的行业趋势。作为这一转变的一个信号，Gartner（2024）预测，到 2026 年，将有超过 30% 的企业采用向量数据库，以便让它们的模型能够扎根于相关业务数据之上（IBM, 2025）。

接下来，我们深入看看：向量数据库如何适应 2025 年围绕 RAG 工具、智能体与上下文工程而快速变化的需求。

向量存储：企业级 RAG 的基础

在 2023 年的基线语境中，RAG 只是用来缓解幻觉问题的几种策略之一。到 2025 年，它已经变成了企业级可靠性的基础架构模式。而使这一模式成为可能的核心组件，就是向量存储。

虽然语言模型本身持有的是训练过程中学到的参数化知识，但向量存储提供的是一个非参数的、外部的、且保持最新的知识库。这使得语言模型能够扎根于真实的、私有的事实数据之上，而这正是 RAG 的核心前提。

在向量存储能够被查询之前，它必须先被填充。这条数据流流水线，是工具层中最关键、也最容易失败的组成部分。不了解这条流水线中各组件之间的相互依赖关系，是 RAG 实施中最常见的陷阱之一。设计糟糕的切分或 chunking 策略，会对性能和嵌入质量造成不可逆的损害。

摄取流水线（ingestion pipeline） ，也称为索引（indexing） ，而 Haystack 的框架正是为管理这一过程而设计的。它包含若干顺序阶段：

切分与预处理（Partitioning and preprocessing） ：这是最初的数据流步骤，将原始、非结构化数据（如 PDF、HTML、.txt 文件）转换为干净、一致的格式。这包括文本抽取、去除伪影，以及把大文档按逻辑片段（例如按章节标题）拆分开来。
Chunking：这是整条流水线中最关键的战略决策。预处理后的数据必须被拆分成可管理的块，同时还要尊重所选嵌入模型的最大 token 输入限制（例如 text-embedding-ada-002 的 8,192 tokens；https://platform.openai.com/docs/guides/embeddings）。常见技术包括：
- 固定大小块（Fixed-size chunks） ：一种简单方法，预先定义固定大小（例如 200 个词）以及一定的重叠比例（例如 10%–15%）。
- 可变大小块（Variable-sized chunks） ：一种更关注内容的方法，根据语义边界来切分数据，例如句末标点或段落分隔。
嵌入（Embedding） ：完成 chunking 后，每一段文本都会被送入嵌入模型，例如 text-embedding-ada-002（https://platform.openai.com/docs/guides/embeddings），转化为一个捕捉其语义含义的数值向量表示。
索引（Indexing） ：最后一步，是把这些向量（embeddings）以及它们对应的文本（chunk）加载到向量数据库中。随后，数据库会建立高效的向量索引，以支持快速检索。整个过程通常可以被封装成一条统一的 ingest 流水线。

这概括了 RAG 的第一部分：把非结构化文本转化为可搜索的嵌入。第二部分则是检索，通常会为它再建立一条独立流水线。

查询嵌入（Embedding the query） ：当用户提出一个问题时，问题必须使用与索引阶段完全相同的嵌入模型转换成向量格式，这样检索过程才能准确发现语义相近的向量。
检索（Retrieving） ：这一阶段使用嵌入后的问题，从向量存储中找出距离该查询最近的嵌入。返回结果是包含最相关信息的那些 chunk。
增强（Augmenting） ：当这些 chunk 被返回后，它们会连同原始查询一起作为上下文传递给语言模型，后者再以自然语言生成最终答案。

值得注意的是，chunking 策略与嵌入模型的选择，都是极其重要的架构决策，它们会永久性地定义知识库与检索过程的“语义分辨率”。按照 RAG 的定义，它检索出来的是文本块，而不是原始文档。生成阶段中的 LLM 也只会看到这些检索到的 chunk。这就产生了一个根本性的设计难题。

如果一个 chunk 太大（例如整整一份 50 页文档），它就会包含过多的语义噪声和无关信息，从而污染上下文窗口，这与智能体循环中出现的上下文污染问题本质类似。相反，如果一个 chunk 太小（例如只有一个句子），它又会缺失 LLM 理解这一事实所需的周边上下文。因此，chunking 策略（例如“200 个词，15% 重叠”）实际上是把整个知识库的语义像素尺寸硬编码了下来。未来的所有检索，都会被这一联合决策所限制。

这也正是为什么工具层必须是一个稳健的数据流水线：它需要为这些复杂、高风险的摄取与提取过程提供治理与管理能力。而在检索过程中，还会暴露出额外一层复杂性。接下来我们就看这一点。

迈向高级检索模式

纯粹的语义搜索（稠密向量）有一个众所周知的关键弱点：它找不到精确关键词。如果周围语义上下文不够匹配，那么基于嵌入的检索往往无法找出包含特定产品 ID 的文档。相反，传统关键词检索（使用稀疏向量，例如 BM25 / TF-IDF）则刚好有相反的问题：它在查找精确关键词方面表现出色，但对查询几乎没有任何语义理解能力。

一个成熟的解决方案是混合搜索（hybrid search） （https://www.elastic.co/what-is/hybrid-search），也就是把语义搜索与关键词搜索结合起来的架构。这种方法同时利用了关键词搜索的精确匹配能力与语义搜索的上下文理解能力，从而给出更优的融合结果。

它的机制是：两种查询并行运行——一个针对稠密向量索引，一个针对稀疏向量索引（BM25）。这两套结果各自带有自己的相关性分数，随后会被智能地融合成一个更优的统一排序。最常见、也最有效的算法是Reciprocal Rank Fusion（RRF） （https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion），它根据结果在原始列表中的位置，对合并后的结果重新排序，从而避免了对不兼容分数进行归一化的麻烦。

这种模式，是生产级 RAG 的基础要求。一个定义清晰的工具层，使我们能够根据数据特点与使用场景，实现关键词检索、向量检索，或混合检索，并通过性能评估来选出最佳方法。第 5 章与第 6 章将通过深入的例子，帮助你从成本与性能两个维度评估并选择最适合特定数据集的方法。

Haystack 2.0 框架正是用来把整套数据流关注点——包括摄取、chunking、嵌入、索引和检索——封装为两个可部署工具的：
一个是索引流水线，
一个是检索流水线。
而且它们都可以通过 Hayhooks 作为独立微服务，经由 REST 端点部署出来。

编排层完全不需要知道底层复杂的检索是如何实现的；它只需要调用 RAG 工具，并得到一个干净的 JSON 对象，其中包含已经锚定好的上下文。

把智能体的有状态、持久化计算过程与向量存储的有状态、持久化数据系统解耦，正是构建可靠、可审计、可扩展 AI 智能体的关键。为了理解这一点，我们接下来会进一步展开：向量存储是如何被用来管理那些使用这些工具的智能体的记忆与状态的。

从 RAG 索引演化为智能体记忆

向量存储的角色，随着我们前面分析过的模型与框架一起演化。这种演化体现了一次根本性的转变：从一个静态、只读的数据源，转向一个动态、可读写的记忆层。

在 2023 年的基线中，RAG 主要是一种用来对抗幻觉的缓解策略。在那种架构里，向量存储扮演的是被动、只读的角色。它充当一个外部静态文档（如技术手册、公共网站）的非参数索引。它的作用是把 LLM 的输出扎根于经过验证的、上下文相关的数据之上，而这在 2025 年的 RAG 系统中依旧是核心实践（Hasan et al., 2025）。

但到了 2025 年，运行在有状态循环中的智能体系统，每循环一次都会生成额外的数据（Anthropic, 2025）。这带来了一个新的关键挑战：LLM 天生是无状态的，而且有限的上下文窗口无法承载一个长时间运行任务的全部历史与知识。已探索的解决方案是：把记忆架构拆成不同层次，通常包括短期记忆（即时上下文窗口）、工作记忆（智能体的“草稿板”）以及长期记忆（持久化的外部存储）（GibsonAI, 2025）。而向量数据库，已经被确定为这一长期记忆层的理想实现（CortexFlow, 2024）。

这种基于向量的长期记忆，其实是对 RAG 机制的一种再利用（DEV, Cesar, 2025）。此时，智能体检索的不再是外部事实，而是它自己过去的经历。按照 Cesar 的说法，它把对话历史、知识以及任务信息视为可搜索的向量。这让智能体能够回忆之前的交互，从中学习，更新自己的知识，并在时间跨度较长的过程中保持行为一致。这种模式最早在实验性智能体中出现，如今已成为现代智能体设计的基础性组件（Silicon Angle, Dotson K., 2025）。

向量存储：上下文工程的使能器

如前所述，2025 年提出的上下文工程，结合了 write、select、compress 和 isolate 四类技术，用于控制哪些信息能够进入 LLM 有限的上下文窗口。而向量存储，正是 write 与 select 这两种策略的物理实现。

Write 策略 涉及把信息存储到外部，以便后续检索。在实践中，这正是 Anthropic（2025）所说的结构化记笔记或智能体记忆。在一次交互之后，智能体会把关键信息——例如新学到的用户偏好、任务进行中的摘要，或中间结论——作为嵌入写入向量数据库。这使这些知识能够被持久化保存于上下文窗口之外，并独立于 LLM 当前的即时状态。
Select 策略 涉及动态地只把最相关的信息拉入上下文窗口。这就是记忆检索系统（DEV Cesar, 2025）。当智能体开始下一步推理时，它会先用当前目标去查询向量存储（也就是它的长期记忆）。数据库会筛选并返回语义上最相关的记忆，然后这些记忆会被重新注入 prompt 中，作为上下文。这样的检索策略既能保证智能体拥有执行任务所需的记忆，也旨在减少上下文腐化。

这一演化意味着一次根本性转变。向量存储的角色，已经从一个被动、只读的知识索引（2023 年的 RAG 模式），成熟为一个主动、可读写的记忆层（2025 年的智能体模式）。2023 年的模式是一次写入，多次读取（write-once, read-many） 。而 2025 年的智能体则不同，它会在每次交互之后把自己的经历和对话历史写入存储中。这使数据库的负载从只读，根本性地转变为读写并存，并由此引入新的、更加复杂的工程挑战。接下来，我们来看看 AWS 探索过的一种高级记忆架构（AWS, Sehwag et al., 2025）。

高级记忆架构与整合

这种面向智能体记忆的读写模式，带来了一个新的三阶问题：记忆整理（memory curation） 。如果一个智能体不断地把信息写入向量记忆，那么存储很快就会被冗余、冲突和琐碎的信息填满。这会污染记忆本身，而 select 策略也就会开始检索出低质量、无用的上下文，导致智能体失败——而这恰恰就是上下文工程原本试图解决的那种上下文污染问题。

AWS 在 2025 年探索出的解决方案，并不是简单地“持续写入”，而是实现一种整合（consolidation）过程（AWS, Sehwag et al., 2025）。这种高级架构模式，把智能体记忆视为一种需要整理和管理的资产，而不是一个简单的数据倾倒仓。正如 Amazon AgentCore 等架构所展示的那样（AWS, Sehwag et al., 2025），这种整合过程本质上是一个递归循环：

当智能体的 write 策略生成一条新记忆时，它不会立刻被提交进数据库。
相反，系统会先执行一次检索，查询向量存储，找出语义上最相近的若干现有记忆。
然后，新产生的待写入记忆与这些旧记忆会被一起打包，发送给一个 LLM，并附带一个整合用的 prompt。
这个 LLM 在这里扮演的是数据库管理员的角色：它评估新旧信息，并根据 prompt 判断正确的动作应该是什么：
- ADD（如果信息是新的）
- UPDATE（如果新信息是对现有记忆的补充、修正或合并）
- NO-OP（如果信息是冗余的）
只有在这一步之后，诸如更新向量存储这样的动作，才会真正被执行。

这类智能体系统是递归式的。它们利用一个 LLM，并结合类似 RAG 的检索过程（这个过程本身也可以是作为工具部署出来的 RAG 流水线），来智能地管理那个充当其长期记忆的向量存储的内容。这种有状态、自我整理的循环，正是 2025 年智能体的一个标志性特征。

而这也正是为什么一个与工具层解耦的专用编排层会变得特别有用。LangGraph 的状态管理、中间件以及基于图的智能体工作流定义，都能够支持这一模式的实现。

在概述了向量存储及其在经典 RAG、智能体短期记忆和长期记忆中的作用之后，我们已经准备好进入本章的最后一节，讨论部署基于 LLM 的应用的成本。

理解 LLM 部署的经济学：推理成本

在建立了数据层之后，我们现在必须分析：运行那些查询这些数据的模型，其经济账究竟该怎么算。模型分化为 LLM、SLM 和 RLM，不仅仅是一次架构层面的变化；它同样也是一次深刻的经济层面的变化。要构建可靠系统，架构师必须正式地区分训练成本与推理成本，并理解决定 AI 应用总拥有成本（TCO, Total Cost of Ownership） 的市场动态与技术驱动因素（https://en.wikipedia.org/wiki/Total_cost_of_ownership）。

对于刚进入这个领域的人来说，一个常见误解是：语言模型的主要成本在于训练。对于 2025 年的应用开发者和企业而言，这种看法并不正确。真正占主导地位、持续发生、并具有战略意义的成本，是推理（inference） 。我们先来看两者的区别：

训练成本（Training cost） ：这是创建基础模型所需的一次性、巨额资本支出（capital expenditure） （https://en.wikipedia.org/wiki/Capital_expenditure）。一个有用的汽车类比是：训练就像造一辆车所投入的一切，包括设计、工程、生产等等（Mangusta Capital, 2024）。这一过程需要由大量 GPU 组成的超级计算集群，成本可达数十亿美元。这基本上是 OpenAI、Google、Anthropic 这类 AI 工厂的专属领域。
推理成本（Inference cost） ：这是使用模型时持续发生的运营支出（operating expense） （https://en.wikipedia.org/wiki/Operating_expense）。沿用同样的类比，推理就像开车时的使用成本，例如汽油（Capital, 2024）。对于绝大多数属于 AI 消费者、而不是生产者的组织来说，这才是真正决定一个应用在经济上是否可行的反复性成本。

2025 年的推理经济格局，是由一个深刻的悖论定义的：训练模型的成本还在持续飙升，而推理的单位成本却在自由落体般下跌。这种市场动态，被称为“2025 年 AI 成本大压缩（The Great AI Cost Compression of 2025） ”。它本质上是一场 API 价格战，由老牌厂商（OpenAI、Google）的激烈竞争、开源阵营（Meta、Mistral）的进攻，以及一批新型“推理即服务”创业公司共同推动（Skywork, 2025）。

对于系统架构师而言，AI 模型价格下跌只是故事的一部分。真正重要的是 TCO，因为它描述的是运行一个模型的全部成本，而不仅仅是“买它”或“调用它”需要花多少钱。对于基于 API 的模型，TCO 相对直接，因为你按 token 付费，因此公式基本上就是：输入 token 成本 + 输出 token 成本。而对于自托管模型，TCO 就复杂得多，它涉及硬件基准测试、能耗、网络，以及持续性的工程支持成本（Latitude, Miguelanes C, 2025）。

影响 TCO 的一个重要因素，是时延—吞吐量权衡（latency–throughput trade-off） （Nvidia, 2025）。架构师必须在时延（用户感受到的响应速度）与吞吐量（系统必须处理的请求量）之间取得平衡。提升吞吐量（例如把更多请求打包批处理）总是会提高时延。因此，架构师的工作，就是先定义一个最大可接受时延，然后在这一约束下把吞吐量做到最大。这个选择，会决定需要部署多少模型实例，而这又会直接塑造总成本。

SLM 在控制 TCO 方面发挥着重要作用。这类模型并不只是学术上有意思，它们在经济上同样具备明显优势。研究表明，一个 70 亿参数的 SLM，其服务成本比 700 亿到 1750 亿参数的大模型低 10 到 30 倍（Nvidia Research, Belcak et al., 2025）。这种成本优势来自更快的速度、更低的能耗，以及显著减少的计算需求。正因如此，SLM 市场正在迅速扩张。

最后，当前的 API 价格战，可能会让团队忽略更深层的经济现实。虽然 API 模型的前期成本很低，但其按使用量计费的模式意味着，成本会持续增长，并且在规模上升后变得难以预测。自托管模型虽然前期更贵，但它提供的是稳定、可预测的长期成本。在某个使用规模之上，公共托管 API 的累计调用成本，最终会超过你自己拥有并运营基础设施的成本。这个 TCO 交叉点 或 盈亏平衡点（breakeven point） ，是现代成本分析中的核心概念，它帮助架构师判断：在什么时点，自托管在财务上开始更划算（Pan et al., 2025）。

对于架构师而言，最终的决策，是把技术与财务综合起来，转化为战略判断。私有自托管模型 与 公共托管 API 之间的选择，本质上是**主权（sovereignty）与便利性（convenience）**之间的一项复杂权衡。

这个决策主要由三个因素驱动：数据安全、模型定制能力，以及性能。对这些驱动因素的分析，也支持了本书所提出的混合架构，说明它是一个适用于 2025 年的可行模式。表 2.3 概述了在私有部署（自托管语言模型）与托管部署（调用外部 API）之间，围绕主要因素的决策对比。

决策标准	私有部署	托管部署
数据安全与合规	完全可控。数据永远不会离开本地环境。对于 HIPAA、GDPR 和 SOC 2 等场景是必需的。	存在风险。数据会发送给第三方。可能被用于训练。不适合高监管数据。
模型定制	完全可控。可以通过 PEFT / LoRA 进行深度、参数级微调，也能创建专用模型。	能力有限。通常只能依赖提示工程（而且成本高），或厂商提供的微调 API。
性能（时延）	低且可预测。通常是几十毫秒。适合边缘 AI 与实时 UI。	高且可变。往往是数秒级，而且会受网络与服务商负载影响，难以预测。
TCO（低 / 不规则流量）	成本非常高。TCO 无法被摊薄。闲置硬件的“挂钟时间成本（wall-clock）”会主导整体开销。	最理想。按需付费，闲置时为零成本。
TCO（高 / 稳定流量）	成本有效。TCO 能被大量调用摊薄，最终比 API 费用更便宜。	成本非常高。成本随调用量线性增长，在高 token 量场景下尤其明显。
MLOps 负担	非常高。需要专门团队来管理硬件、利用率与优化。	没有。基础设施与 MLOps 都由服务提供商负责。
最适合的场景	安全要求高、低时延、高吞吐或专门任务（例如端侧、本地内部工具、核心功能）。	通用推理、原型开发、低流量任务，或非核心功能。

表 2.3——决策矩阵：私有部署 vs 托管部署

这个决策矩阵，实际上把核心架构挑战明确成了部署四大支柱之间的直接权衡：能力、成本、时延和隐私。

总的来说，LLM 部署的经济学关键在于理解：现代 AI 系统真正的财务引擎是推理，而不是训练。API 价格战也许会让前沿模型看起来廉价且唾手可得，但可持续的架构需要一种更深层的视角——要把时延—吞吐量现实、SLM 在压低单位成本中的日益重要角色，以及自托管在何时会变得更具经济优势的战略盈亏平衡点统统考虑进去。到了 2026 年及以后，胜出的架构不再由模型大小或新奇程度定义，而是由经济上的清晰性以及技术决策与真实、持续成本结构之间的纪律性对齐来定义。

小结

在本章中，我们追踪了 LLM 版图从 2023 年基线到 2025 年专门化智能体技术栈的快速演进。我们看到，过去那些单体式模型（如 BERT、GPT-3）已经让位于一个新的专门化谱系：一端是面向边缘计算的超高效 SLM，另一端是像 DeepSeek-R1 这样的先进 RLM。

我们也看到，开发者与模型的交互方式，已经从提示工程，发展为上下文工程这一正式学科。它是一套管理智能体信息环境的策略，包括 write、select、compress、isolate。同时，我们也分析了框架市场如何为了服务这一新现实而走向专门化：LangGraph 1.0 已成为智能体控制流的领导者，而 Haystack 2.0 则稳固了其在可靠、可审计数据流领域的领先地位。

随后，我们考察了这一新技术栈背后的关键经济现实，并澄清：对于开发者来说，占主导且反复发生的成本是推理，而不是训练。这要求我们把注意力放到 TCO 上，而 TCO 揭示了一项战略权衡：一边是托管 API 的按需付费便利性，另一边是自托管在长期经济性、安全性与低时延上的优势，而由于高性价比 SLM 的存在，自托管也变得更加可行。

最后，我们把这些线索综合起来，形成了本书提出的混合架构：由 LangGraph 编排器 调用一个 以 Hayhooks 微服务形式部署的 Haystack RAG 流水线。这一模式——我们将在第 8 章的动手实践中亲自构建——体现了定义现代、可靠、生产级智能体系统的两个关键原则：关注点分离与上下文隔离。

下一章中，我们将对 Haystack 库做一个整体概览，并开始深入进入工具层的构建。

延伸阅读

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, L., and Polosukhin, I. (2017, revised 2023). Attention Is All You Need.
Zhang, S., Dong, L., Li, X., Zhang, S., Sun, X., Wang, S., Li, J., Hu, R., Zhang, T., Wu, F., Wang, G. (2023). Instruction Tuning for Large Language Models: A Survey.
Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A. (2022). Training language models to follow instructions with human feedback.
Christiano, P. F., Leike, J., Brown, T., Martic, M., Legg, S., Amodei, D. (2017). Deep reinforcement learning from human preferences.
Stiennon, N., Ouyang, L., Wu, J., Ziegler, D. M., Lowe, R., Voss, C., Radford, A., Amodei, D., Christiano, P. (2020). Learning to summarize from human feedback.
Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-T., Rocktäschel, T., Riedel, S., Kiela, D. (2021). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
Lialin, V., Deshpande, V., Rumshisky, A. (2023). Scaling Down to Scale Up: A Guide to Parameter-Efficient Fine-Tuning.
Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., Chen, W. (2021). LoRA: Low-Rank Adaptation of Large Language Models.
Shaw, P., Uszkoreit, J., & Vaswani, A. (2018). Self-Attention with Relative Position Representations.
Radford, A., Narasimhan, K., Salimans, T., & Sutskever, I. (2018). Improving language understanding by generative pre-training.
Radford, A., Wu, J., Child, R., Luan, D., Amodei, D., Sutskever, I. (2019). Language models are unsupervised multitask learners.
Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., ... & Amodei, D. (2020). Language models are few-shot learners.
OpenAI. (2023). GPT-4 Technical Report.
Devlin J, Chang MW, Lee K, Toutanova K. (2018). BERT: Pre-training of deep bidirectional transformers for language understanding.
Lewis, M., Liu, Y., Goyal, N., Ghazvininejad, M., Mohamed, A., Levy, O., Stoyanov, V., Zettlemoyer, L. (2019). BART: Denoising Sequence-to-Sequence Pre-training for Natural Language Generation, Translation, and Comprehension.
Hinton, G., Vinyals, O., Dean, J. (2015). Distilling Knowledge in a Neural Network.
Jiao, X., Yin, Y., Shang, L., Jiang, X., Chen, X., Li, L., Wang, F., Liu, Q. (2020). TinyBERT: Distilling BERT for Natural Language Understanding.
Kirstain, Y., Lewis, P., Riedel, S., & Levy, O. (2021). A Few More Examples May Be Worth Billions of Parameters.
Muennighoff, N., Wang, T., Sutawika, L., Roberts, A., Biderman, S., Le Scao, T., Bari, M. S., Shen, S., Yong, Z.-X., Schoelkopf, H. (2022). Cross lingual generalization through multitasks finetuning.
Belkada, Y., & Dettmers, T. (2022). A gentle introduction to 8-bit matrix multiplication for transformers at scale using Hugging Face Transformers, Accelerate and bitsandbytes.
Heidloff, N. (2023). Efficient Fine-tuning with PEFT and LoRA.
Lin, C.-Y. (2004). ROUGE: A Package for Automatic Evaluation of Summaries.
Papineni, K., Roukos, S., Ward, T., & Zhu, W.-J. (2002). BLEU: A Method for Automatic Evaluation of Machine Translation.
Lavie, A., Agarwal, A. (2007). METEOR: An automatic metric for MT evaluation with high levels of correlation with human judgments.
Meister, C., & Cotterell, R. (2021). Language Model Evaluation Beyond Perplexity.
Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2020). BERTScore: Evaluating Text Generation with BERT.
Chung, H. W., Hou, L., Longpre, S., Zoph, B., Tay, Y., Fedus, W., Li, E., Wang, X., Dehghani, M., Brahma, S., Webson, A., Gu, S. S., Dai, Z., Suzgun, M., Chen, X., Chowdhery, A., Narang, S., Mishra, G., Yu, A., Zhao, V., Huang, Y., Dai, A., Yu, H., Petrov, S., Chi, E. H., Dean, J., Devlin, J., Roberts, A., Zhou, D., Le, Q. V., & Wei, J. (2022). Scaling Instruction-Finetuned Language Models.
See, A., Liu, P. J., & Manning, C. D. (2017). Get To the Point: Summarization with Pointer-Generator Networks.
Hermann, K. M., Kociský, T., Grefenstette, E., Espeholt, L., Kay, W., Suleyman, M., & Blunsom, P. (2015). Teaching Machines to Read and Comprehend.
Karpukhin, V., Oğuz, B., Min, S., Lewis, P., Wu, L., Edunov, S., Chen, D., & Yih, W.-T. (2020). Dense Passage Retrieval for Open-Domain Question Answering.
Jiang, A. Q., Sablayrolles, A., Mensch, A., Bamford, C., Chaplot, D. S., de las Casas, D., Bressand, F., Lengyel, G., Lample, G., Saulnier, L., Renard Lavaud, L., Lachaux, M.-A., Stock, P., Le Scao, T., Lavril, T., Wang, T., Lacroix, T., & El Sayed, W. (2023). Mistral 7B.
GitHub (2025). Agent mode 101: All about GitHub Copilot’s powerful mode.
Microsoft (2025). Agentic DevOps: Evolving software development with GitHub Copilot and Microsoft Azure.
Anthropic (2025). Claude 3.5 Sonnet.
Galileo (2025). Claude 3.5 Sonnet vs GPT-4o: Comprehensive AI Model Comparison.
Dev, Nik L. (2025). Claude 3.5 Sonnet vs. GPT-4o.
Corradini, F., Leonesi, M., & Piangerelli, M. (2025). State of the Art and Future Directions of Small Language Models: A Systematic Review.
Sakib TH, Hosain MT, Morol MK. (2025). Small Language Models: Architectures, Techniques, Evaluation, Problems and Future Adaptation.
Boston Institute of Analytics (2025). How Small Language Models (SLMs) Are Outperforming Giants in 2025?
Besta, M., et al. (2025). Reasoning Language Models: A Blueprint.
DeepSeek-AI et al. (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.
Shao, Z. et al. (2025). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models.
Datacamp (2024). What is prompt engineering? A detailed guide for 2025.
Nearform (2025). Beyond prompt engineering: the shift to context engineering.
LlamaIndex (2025). Context Engineering - What it is, and techniques to consider.
Anthropic (2025). Effective context engineering for AI agents.
Datacamp (2025). Context Engineering: A Guide With Examples.
Thatipalli, A. (2025). Context Engineering is the #1 Skill in 2025.
Kubiya AI (2025). Mastering Context Engineering: Best Practices for Reliable AI Performance in 2025.
Trixly (2025). Best Agentic AI Frameworks in 2025: Comparing LangChain, LangGraph, CrewAI, and Haystack.
LangChain (2025). LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones.
AlphaCorp (2025). Top 5 RAG Frameworks.
Lindy AI (2025). 10 Best AI Agent Frameworks: Picking the Right One.
IBM (2025). What is a vector database?
Wikipedia (2025). Vector Database.
SingleStore (2025). The Ultimate Guide to the Vector Database Landscape: 2025 and Beyond.
LakeFS (2025). Best 17 Vector Databases for 2025 [Top Picks].
Hasan, M. T., et al. (2025). Engineering RAG Systems for Real-World Applications: Design, Development, and Evaluation.
Gibson AI (2025). RAG vs Memory for AI Agents: What’s the Difference.
CortexFlow (2024). Long-Term Memory for AI Agents.
DEV, Cesar E. (2025). Long Term Memory for LLMs using Vector Store - A Practical Approach with n8n and Qdrant.
Silicon Angle, Dotson K. (2025). Memory for the machine: How vector databases power the next generation of AI assistants.
LangChain (2025). Context Engineering.
Chroma Research et al. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance.
AWS, Sehwag, A., et al. (2025). Building smarter AI agents: AgentCore long-term memory deep dive.
Wikipedia (2025). Total cost of ownership.
Mangusta Capital (2024). LLMs: Training vs. Inference.
Skywork (2025). Analysis of the Evolution Path of "Inference Cost" of Large Models in 2025: The API Price War Erupts.
Latitude, Miguelanes C. (2025). Best Practices for LLM Hardware Benchmarking.
Nvidia, Nguyen, V., Perez, S. (2025). LLM Inference Benchmarking: How Much Does Your LLM Inference Cost?
Belcak, P., et al. (2025). Small Language Models are the Future of Agentic AI.
Pan, G., & Wang, H. (2025). A Cost-Benefit Analysis of On-Premise Large Language Model Deployment: Breaking Even with Commercial LLM Services.
ElasticSearch. What is hybrid search?
ElasticSearch. Reciprocal rank fusion.