RAG 可以说是把 LLM 应用于企业私有数据时，最有影响力的方法之一。在过去几年里，它已经从一种实验性技术，发展成企业构建“基于自身数据的 ChatGPT 式体验”时的标准架构模式，并且现在正快速从 POC 走向生产部署。
在本书中，你已经掌握了 RAG 的几个支柱：LLM、嵌入、向量存储和重排序。你也已经看到，一个可运行的概念验证可以在一个周末内完成。但从本地脚本跃迁到一个有韧性的、生产级生态系统，真正的工程才刚刚开始。它要求我们不再停留在“能跑就行”，而是要解决延迟、规模化准确性和长期可维护性问题。
生产级 RAG 不只是代码问题；它是一个分布式系统，需要严格的治理和安全机制。你必须管理大规模摄取，确保跨 TB 级多模态内容的数据完整性。更重要的是，你必须实施纵深防御的安全策略。这意味着，在数据进入模型之前，部署实体感知的脱敏机制来清除 PII；强制执行严格的基于角色的访问控制，确保初级分析师无法检索敏感的人力资源文档；并维护全面的审计轨迹，以满足 SOC 2、GDPR 和 HIPAA 等合规标准。
除了安全之外，你还要面对总拥有成本的运营现实。你必须管理供应商集成的复杂性，使用解耦的微服务优化延迟，并组建一个能够弥合机器学习、DevOps 和安全能力缺口的多学科团队。
我们希望，到现在为止，你已经深入理解了 RAG 的工作方式、每个组件的作用，以及——也许最重要的是——陷阱在哪里。但在生成式 AI 领域，地面一直在移动。每周，我们都会被大量新技术、新论文和供应商公告轰炸。要分辨什么是真正有意义的架构转变，什么只是“本周流行款”或供应商营销，往往并不容易。
在最后这一章，我们将向前看，并尝试从噪音中分离出信号，给出我们对那些将定义下一代 RAG 的重要趋势的洞察。
检索的演进
检索层不再是一个静态工具，而是一个快速演进的前沿领域。构成检索流水线的底层组件仍在持续改进。我们正在走出“够用就好”的检索时代，进入一个新的精确性标准：
后期交互嵌入
标准嵌入模型会把一个文档块压缩成单个嵌入向量。像 ColBERT 这样的“后期交互”模型会为每个 token 保留向量，并把最终嵌入计算推迟到查询阶段。这通常可以实现更细粒度的匹配，并提供更好的整体准确性，不过代价是需要更高的存储和内存资源。
更细腻的重排序器
我们正在看到更好的重排序器。它们不仅总体上比前几代重排序器更准确，而且还能遵循指令，从而允许它们按照法律、医疗等特定领域的细腻要求，对文本进行重排序。
原生多模态检索
随着多模态生成式 AI 的研究持续推进，多模态模型在准确性和速度上不断提升，我们正在走过那个“简单给图片生成 caption，然后索引文本”的时代。正如第 8 章所讨论的，RAG 流水线正在演进为使用原生多模态嵌入，把多模态数据映射到与文本相同的向量空间。ColPali 将后期交互方法适配到了视觉 patch 上，使复杂多模态文档的原生检索更加准确。
图增强检索
我们预计，用于构建和扩展知识图谱的工具和技术会越来越自动化。虽然知识图谱在那些拥有稳定、高价值结构化知识，并且团队愿意投入本体设计和实体解析的领域中仍然最有效，但这种自动化会推动更广泛的采用。反过来，知识图谱会让 RAG 流水线能够对复杂的多跳问题给出更准确的回答，例如：“Q3 报告中提到的供应商，与法律合规文档中列出的风险因素之间有什么关系？”
RAG 中检索的原始组件，终于开始追上其架构野心。检索层正在转变为一种高精度工具，可以在规模化场景下提供准确回答。
向 Agentic RAG 的转变
从历史上看，检索一直是 AI 的“系统 1”——快速、直觉化，但也是线性的。
无论它由语义搜索、词法搜索还是混合搜索驱动，目标都很简单：识别相关文本块，并把最相关的文本块传递给下游的生成式 LLM。它是一个“一次性”的流水线，对许多用例都有效，但在面对更复杂、更微妙的问题时可能会失败。
生产中 RAG 的未来，正在快速转向“系统 2”式思考，也就是使用 agentic RAG，正如我们在第 7 章中看到的那样。在这种模式下，系统不只是检索；它会以迭代方式进行规划、推理和工具编排。
在 agentic 工作流中，LLM 不再只是流水线末端的总结器；它成为了控制器。它可以把一个模糊的用户请求分解成一个具体计划，执行多个不同的检索步骤，也就是通过工具调用完成，并且甚至能够对自己的结果进行自我反思。
如果检索到的文档无法回答问题，标准 RAG 流水线通常会产生幻觉，或者拒绝回答，说“我不知道”。而 agentic 流水线会检测到这个缺口，然后发起一个新的、更新过的搜索查询。这个过程可能重复多次，直到它找到正确回答用户查询所需的信息。
这使 RAG 从“搜索引擎”变成了“推理引擎”。
更进一步说，由于工具可以采取行动，而不仅仅是检索数据，AI agent 所覆盖的用例范围更广，并且在很多情况下更有影响力。例如，一个基于 agentic RAG 的客服聊天机器人，不仅可以回答用户问题，还可以创建支持工单、更新工单优先级，等等。
尽管向“推理引擎”的转变很有吸引力，但它也引入了显著的工程税，使生产级 agent 与简单 demo 区分开来。从线性的、一次性 RAG 转向迭代循环，会造成可观测性缺口：调试一次失败不再只是查看一次检索结果，而是需要追踪由多个推理步骤、工具调用和自我反思组成的复杂轨迹。这也会影响延迟和成本：一个过去只需要两秒的查询，现在可能需要三十秒甚至更久，因此必须设置严格的确定性护栏，例如迭代次数上限和预算限制，以防止代价高昂的“失控循环”，也就是 agent 无法收敛到答案。
最终，向 agentic RAG 的转变代表了自主性和控制之间的权衡。虽然 agent 可以处理更广、更有影响力的用例，但一旦部署到生产环境，它们就需要更加成熟、更加复杂的基础设施。
数据引力与联邦检索的现实
随着企业继续采用 agentic AI，它们也必须面对企业数据的一个现实问题：数据引力。
在生产环境中，“把所有企业数据都索引进向量存储”这个想法通常是一种幻想：财务数据在 Snowflake 里；客户日志在 Elasticsearch 里；监管文档存放在专门的法律档案库里。把 PB 级的实时、受治理数据迁移进一个 RAG 数据存储，不仅是工程噩梦；如果处理不当，还可能导致合规违规。
我们预期，与其把数据移动到模型，不如转向联邦检索——让数据留在原处，把查询带到数据源。在这种模型中，agentic 系统使用工具，直接或通过 MCP server，在数据本来的环境中查询数据集，例如对数据仓库执行 SQL。
不过，这种联邦方法引入了一个关键依赖：原生环境是否能通过工具调用向 agent 提供准确数据？当你依赖联邦检索时，你就受制于工具所调用的外部系统本身的原生检索能力。如果一个 agent 查询一个依赖不准确关键词搜索，也就是 BM25 的遗留文档存储，并收到不相关结果，那么它准确回答用户问题的能力就会受到限制。
要让联邦检索成功，我们不需要更聪明的 agent；我们需要更好的方式来现代化遗留系统中的检索能力，将语义理解、混合搜索、重排序和 text2SQL 集成进去。
更长上下文的影响
如今，LLM 的上下文窗口已经达到一百万甚至一千万 token，一个常见问题随之出现：RAG 真的还有必要吗？为什么不直接把全文粘进 prompt？
现实是，争论不应该是“RAG 对比长上下文”——未来在于上下文感知型 RAG。
长上下文窗口不会杀死 RAG；它会让 RAG 更强大。RAG 不再只是为了在狭小的 4k 上下文窗口中找到很小、零散的片段，而是演进为一个高精度过滤器，向模型输入更大、更连贯的“叙事型”文本块。这让模型既能保留完整章节或完整技术规格的细微语义，又能继续受益于检索带来的低成本和降噪效果。
事实是，RAG 远未过时；它只是在把重心转向上下文工程。
从 Prompt Engineering 到 Context Engineering
即便上下文窗口看起来几乎是无限的，三个关键限制仍然存在：
成本
对每个用户查询都处理一千万 token，对于高流量企业用例来说是昂贵的。
延迟
在回答每个简单问题之前，都要等模型花 60 秒“阅读”一大批文档，这可能会造成不可接受的用户体验。
“中间遗忘”
研究表明，相比上下文窗口开头或结尾的信息，LLM 更难优先处理埋在巨大上下文窗口中间的特定细节。
此外，无论实际上下文窗口限制是多少，比如 1000 万 token，都很难想象你所有企业数据都能装进这个大小里。
因此，每一次 RAG 查询，本质上都是把庞大的企业数据集过滤成一个高质量的“信息候选清单”，这些信息片段可以舒适地放入 LLM 的上下文窗口，并且是 LLM 完成任务所需的最相关信息。
context engineering，也就是上下文工程，反映的正是这个想法：动态组装一个完美 prompt，把检索到的事实、用户历史和系统指令混合成一个包，从而在最小化成本和延迟的同时最大化准确性，如图 10-1 所示。
RAG 实际上成为了长上下文 LLM 的注意力机制，决定什么值得占用模型昂贵的注意力。
图 10-1 展示了 RAG 如何从更大的企业数据集中筛选和选择相关数据块，放入 LLM 的上下文窗口，突出它作为注意力机制的功能。
我们可以把 RAG 的过滤功能看作一种注意力机制，它允许我们从完整企业数据集中选择，或者说“关注”，最相关的文本块，供 LLM 的上下文窗口使用。
从被动 RAG 到主动 RAG 的转变
更大的上下文窗口还有另一个好处：它们让系统能够把用户的整个数字环境都当成 prompt。系统现在可以静默观察用户屏幕、最近日志和打开的文档——这些数据过去会撑爆标准窗口——从而隐式理解用户意图。
这就是主动 RAG 架构背后的思想：系统在后台运行。
例如，当一名人工客服打开一个关于“液压泵损坏”的工单时，RAG 系统会实时分析屏幕。甚至在客服输入查询之前，系统就可以检索该液压泵的结构图，以及最近三个类似且已解决的工单，并把它们显示在侧边栏中。在这种场景下，查询不是由最终用户明确输入的，而是由上下文隐含出来的。
主动 RAG 不等待被提问；它会在需要答案的那一刻提供正确答案。
边缘侧 RAG：小语言模型
传统上，构建高质量 RAG 系统意味着一个困难选择：要么依赖公有云 API，为了易用性牺牲数据隐私；要么维护大型内部 GPU 集群，自托管前沿级模型。虽然使用大型开源 LLM 构建气隙系统一直是可能的，但基础设施开销对大多数组织来说可能是一道巨大门槛。
小语言模型，也就是 SLM 的兴起，正在继续改变这种计算逻辑。SLM 是高度高效的模型，通常小于 32B 参数，但也常常小到 4B 或 8B 参数，却能表现出远超其规模的能力。
这些模型支持一种“本地优先”或气隙 RAG 架构，使企业无需数据中心级硬件，就可以完全控制数据和基础设施，并带来以下关键优势：
生产就绪与托管便利性
从托管 API 转向自建模型，虽然会引入管理推理硬件的责任，但 SLM 能降低长期运营风险。对生产工程师来说，SLM 最直接的优势是，它们把生成步骤从一个“黑盒”API 变成一个可预测的软件组件。
通过运行在普通商用硬件上，而不是昂贵的多 GPU 集群上，SLM 允许 RAG 流水线像应用程序其他部分一样，被纳入同一套 CI/CD 周期进行版本管理、测试和部署，从而消除外部 API 废弃或速率限制所经常导致的级联故障。
把引擎带到数据旁边
在医疗、国防和金融等受监管行业，把敏感 PII 或知识产权发送给公有云提供商通常是不可接受的。SLM 允许企业把推理引擎带到数据旁边，而不是把数据发送到引擎那里。
这种反转意味着敏感文档永远不会离开安全边界，从而解决许多 RAG 项目在 POC 阶段就停滞不前的隐私合规障碍。
改变经济模型
从云 API 转向本地 SLM，会从根本上改变生产级 RAG 的单位经济模型。你不再承担基于 token 定价的可变成本，而是转向硬件的一次性或固定成本。对于高流量 RAG 应用来说，这有可能把总拥有成本降低几个数量级。
这种经济转变对多模态 RAG 尤其关键，因为视觉语言模型 API 调用的高成本，以及传输大型视觉资产带来的延迟，可能会令人望而却步。随着本地 SLM 获得多模态能力，我们预计其采用会加速，因为组织可以绕过在云端处理敏感视觉或音频资产时面临的成本、延迟和数据驻留障碍。
本地推理还可以消除网络往返，从而带来不可忽视的延迟收益，并提供生产应用中用户所期待的体验。
最终，随着 SLM 在准确性和推理能力上不断提升，RAG 将能够覆盖更广泛的用例，甚至包括那些对数据隐私、延迟或正常运行时间有强要求，并且很难通过外部 API 调用实现的场景。
大规模治理与合规
正如第 4 章中讨论过的，从 POC 走向生产时，项目常常撞墙，而原因不是技术本身，而是治理、风险和合规，也就是 GRC。随着 RAG 和 AI agent 为更多关键企业应用提供能力，这些问题会从事后考虑项，变成核心架构要求。这一转变在很大程度上受到欧盟 AI 法案等新兴监管框架的推动。
RAG 系统必须在设计上具备“合规感知”能力，这涉及解决三个在 POC 中很少出现的复杂挑战：
数据主权
你不能简单地把全球数据都倒进一个数据库。生产级 RAG 应用很可能需要支持多个区域，智能地把用户查询路由到特定区域索引，例如把德国员工的查询路由到托管在法兰克福的向量存储，从而确保数据不会非法跨境。
“被遗忘权”，也就是 GDPR/CCPA
从标准数据库中删除一个用户很容易；但从编码了文档块的向量数据库和/或词法数据库中删除用户就更难。如果用户行使被遗忘权，你必须能够追踪并精确删除每一个源自其数据的文本块。这要求在摄取层有稳健的元数据标记策略，因为从头重新索引 TB 级数据不是一个可行的运营策略。
可审计性与可解释性
提供答案已经不够了；许多生产级企业 RAG 应用必须能够证明为什么给出了这个答案。我们预计 RAG 中不可变审计日志的采用会增加，用来捕获“来源链”：把具体 prompt、被检索到的精确文档版本，以及带引用的生成输出连接起来。在金融或法律等领域，这一点至关重要，因为幻觉可能带来重大的现实法律或金钱后果。
新的监管环境从根本上改变了我们构建 RAG 应用的方式，用严格的、由评估驱动的开发，取代主观的“感觉检查”。正如第 6 章讨论的，这种转变把评估从发布后的诊断手段，变成 CI/CD 流水线的核心组成部分：任何模型或 prompt 的变更，只有通过自动化评估门禁之后才能部署，这些门禁会基于黄金数据集测试忠实性和相关性。这样，治理就从一组静态规则，变成一种动态、自动化的安全防护，保护用户和组织双方。
底线是：在 RAG 的下一个时代中胜出的组织，不只是那些拥有最聪明 LLM 的组织，而是那些能够把模型包裹进一个可信、透明且安全的运营级 RAG 流水线中的组织。
结论：活的知识库
本书开篇讲的是 RAG 的机械结构：切分文本、存储嵌入向量、编写 LLM prompt，以及管理延迟。我们在结尾意识到，这些只是某种更大东西的基础。你不再只是构建“搜索引擎”或“聊天机器人”。你正在构建企业大脑。
纵观整个企业历史，组织知识一直是碎片化的——锁在现任或前任员工的大脑里，埋在被遗忘的文件夹中，或者隔离在彼此无法通信的系统里。你在未来几年将要构建的基于 RAG 的系统，其承诺就是统一这些知识。
在下一个时代，你设计的 RAG 流水线会从被动工具演进为主动伙伴。它们不只是回答问题；它们会连接人类可能错过的线索，并确保组织中的每一个决策，都受到整个企业集体智慧的支持。当你朝着这个未来构建时，要把我们探索过的核心模式——RAG、工具使用、agent、知识图谱和评估器——视为稳定基础，哪怕 LLM、向量数据库、agentic 框架和护栏仍在不断变化和演进。
当你合上这本书时，请记住，RAG 的组件会变化。向量数据库会商品化，上下文窗口会扩展，LLM 会以惊人的速度和准确性进行推理。不过，不要过度依恋某个技术栈——而要专注于使命。
RAG 的未来，不在于某个具体算法。它关乎软件在企业语境中的转变：从我们使用的工具，变成我们协作的智能体。
我们讨论过的陷阱——幻觉、漂移、安全、隐私、延迟——都是真实存在的。工程挑战很大，但机会更大。现在，你已经拥有了蓝图，可以把一座静态数据之山，转变成一个活着的、会呼吸的洞察引擎。
基础已经铺好。工具已经在你手中。现在，是时候开始构建了。
注释
- 当然，我们也意识到，正如 Niels Bohr 所说：“预测非常困难，尤其是关于未来的预测。”
- 后期交互嵌入模型通常需要 50 倍以上的存储空间，并且在查询时需要显著更高的计算量，因为它们执行的是 token 级别的 MaxSim 操作，而不是简单的向量点积。
- 当然，没有什么是真正无限的，但如果你想到 GPT-3 的上下文长度是 2048，那么 1000 万 token 感觉就像无限一样。
- 需要说明的是，Anthropic、Google 和 OpenAI 等许多 LLM 提供商都提供 prompt caching，这可以在长上下文 RAG 中降低一部分成本和延迟。这很有帮助，但并不能解决根本问题。
- 虽然主动观察可以最大化上下文相关性，但它也引入了数据隐私、持续同意，以及本地处理与云端处理之间选择的关键挑战。
