基于检索增强生成（RAG）的系统过去一直是、并且仍将是企业中利用大语言模型（LLM）的最实用应用之一。

因为啥，不是每个公司都能训练GPT4o/DeepSeek这样强悍的模型，不会SFT或者Post Training。清洗清洗数据，搞搞开源模型，调试一下RAG的embding模型，rerank模型，这就是很多企业AI的全部真相。

本篇博客将梳理检索增强生成（RAG）系统从简单直接的形式到具备智能体特性的演变历程。通读之后，你将了解到在这一演变的每一步中都解决了哪些挑战。

简单直接的检索增强生成（RAG）系统的出现

简单直接的检索增强生成（RAG）系统几乎是在 2022 年底 ChatGPT 推出，大语言模型（LLM）成为主流的同时出现的。检索增强生成技术的诞生是为了解决原生大语言模型所面临的问题。简而言之，这些问题包括：

• 产生幻觉（生成错误或不存在的信息）。
• 上下文窗口大小有限。
• 无法获取非公开数据。
• 参数知识仅限于模型训练时所使用的最新数据。

检索增强生成（RAG）系统最简单的实现方式可以按以下步骤来定义：

预处理：

1、将整个知识库的文本语料库分割成多个文本块 —— 每个文本块代表可供查询的一段独立上下文信息。相关数据可以来自多个来源，例如由 PDF 报告补充的 Confluence（一种企业知识管理和协作软件）中的文档。

2、使用嵌入模型将每个文本块转换为向量嵌入表示。

3、将所有的向量嵌入存储在向量数据库中。将表示每个嵌入的文本以及指向该嵌入的指针分别保存。

检索：

4、使用与嵌入知识库时相同的嵌入模型，对您想要提出的问题 / 查询进行嵌入处理。

5、利用生成的向量嵌入，针对向量数据库中的索引运行查询。选择您想要从向量数据库中检索的向量数量，这将等同于您将要检索并最终用于回答查询问题的上下文数量。

6、向量数据库针对所提供的向量嵌入，在索引中执行近似最近邻（ANN）搜索，并返回先前选定数量的上下文向量。该过程会返回在给定嵌入 / 潜在空间中最为相似的向量。将返回的向量嵌入映射到代表它们的文本块上。

7、通过提示将问题以及检索到的上下文文本块一起传递给大语言模型（LLM）。指示大语言模型仅使用所提供的上下文来回答给定的问题。这并不意味着不需要进行提示工程 —— 您需要确保大语言模型返回的答案在预期范围内，例如，如果在检索到的上下文中没有可用于回答的相关数据，要确保不会给出编造的答案。

简易检索增强生成（RAG）系统中的可变因素

即便不使用任何先进技术，在构建生产级别的检索增强生成（RAG）系统时，仍有许多需要考虑的可变因素。

检索：

F)Chunking分开

• 分块 —— 你如何对你将用于外部上下文的数据进行分块。
• 小块、大块。
• 分块时采用滑动窗口或滚动窗口方式。
• 在搜索时检索父块或相关联的块，或者仅使用最初检索到的数据。

C)嵌入模型选择

• 选择嵌入模型，以便将数据嵌入潜在空间并从中查询外部上下文，反之亦然。考虑上下文嵌入。

D)Vector Database向量库

• 选择哪个数据库。
• 托管在何处。
• 与嵌入向量一起存储哪些元数据。
• 用于预过滤和后过滤的数据。
• 索引策略。

E) 向量搜索。

• 选择相似性度量方法。
• 选择查询路径 —— 先使用元数据还是先使用近似最近邻（ANN）搜索。
• 混合搜索。

G) 启发式方法

• 应用于检索过程的业务规则。
• 时间重要性。
• 重复的上下文（多样性排名）。
• 来源检索。
• 有条件的文档预处理。

生成

A) 大语言模型（LLM）—— 选择合适的大语言模型为你的应用程序提供支持。
B) 提示工程 —— 即使有可用的上下文可用于提示中，也不能免除你在设计提示方面的艰巨工作。你仍然需要调整系统，以生成你期望的输出，并防止出现 “越狱” 情况（即模型产生不符合预期或有害的输出）。
完成所有这些工作后，我们就拥有了一个可用的检索增强生成（RAG）系统。

残酷的事实是 —— 即使研究的再清楚，这很少能足够好地解决实际的商业问题。由于各种原因，这种系统的准确性可能会很低。

提升简单检索增强生成（Naive RAG）的先进技术

为持续提高简单检索增强生成系统的准确性，一些已较为成功采用的技术如下：

查询修改 —— 有几种可以采用的技术：

• 查询重写 —— 让大语言模型（LLM）重写原始查询，使其更适合检索过程。可以通过多种方式进行重写。例如，修正语法，简化查询以保持简短精炼的表述。
• 查询扩展 —— 让大语言模型多次重写查询，以生成该查询的多种变体。然后，多次运行检索过程，以检索更多可能相关的上下文信息。

重新排序 —— 与常规的上下文搜索相比，使用更复杂的处理方式对最初检索到的文档进行重新排序。通常，这涉及使用更大的模型，并且在检索阶段检索比所需数量多得多的文档。重新排序与前面提到的查询扩展模式配合使用效果也很好，因为它会返回比平时更多的数据。整个过程与我们常见于推荐引擎中的情况类似。不久前我在这里（第二段）写过关于此类架构的内容：

嵌入模型的微调 —— 在某些领域（例如医疗数据）中，使用基础嵌入模型进行数据检索的效果不佳。在这种情况下，你可能需要微调自己的嵌入模型。

让我们继续探讨一些其他先进的检索增强生成（RAG）技术和架构。

Contextual Retrieval上下文检索

上下文检索这一概念是由 Anthropic 团队在去年年底提出的。其目的是提高在基于检索增强生成的人工智能系统中所检索数据的准确性和相关性。

我很喜欢上下文检索的直观性和简易性。而且它确实能产生不错的效果。

以下是具体的实施步骤：

预处理：

1、通过选定的分块策略将你的每一份文档拆分成多个文本块。

2、对于每个单独的文本块，将其与整个文档一起添加到提示词中。

3、添加说明以确定该文本块在文档中的位置，并为其生成简短的上下文。将该提示词输入到选定的大语言模型（LLM）中。

4、将上一步生成的上下文与生成该上下文所对应的文本块合并。

5、将数据通过词频 - 逆文档频率（TF-IDF）嵌入器进行处理。

6、将数据通过基于大语言模型的嵌入模型进行处理。

7、将在第 5 步和第 6 步中生成的数据存储在支持高效搜索的数据库中。

检索：

8、使用用户查询来检索相关上下文。使用近似最近邻（ANN）搜索进行语义检索，并使用词频 - 逆文档频率（TF-IDF）索引进行精确搜索。

9、使用排序融合技术对检索到的结果进行合并和去重，并生成排名前 N 的元素。

10、对之前的结果重新排序，并缩小范围至排名前 K 的元素。

11、将第 10 步的结果与用户查询一起输入到大语言模型（LLM）中，以生成最终答案。

一些思考：

第 3 步听起来成本极高，事实也确实如此，但通过提示词缓存，成本可以大幅降低。

提示词缓存既可以在专有模型的情况下实现，也可以在开源模型的情况下实现（请参考下一段内容）。

CAG缓存增强生成技术的简要出现

在 2024 年底，一篇白皮书在社交媒体上引起了短暂的轰动。一种将永远改变检索增强生成（RAG）技术的出现（真的会吗？）—— 缓存增强生成（CAG）。我们已经知道常规的检索增强生成（RAG）是如何工作的，以下是对缓存增强生成（CAG）的简要描述：

将所有的外部上下文预先计算到大型语言模型（LLM）的键值对缓存（KV Cache）中。将其缓存在内存里。这只需要进行一次，后续的步骤可以多次运行，而无需重新计算初始缓存。

传入包含用户查询的系统提示，以及带有关于大型语言模型应如何使用已缓存上下文的说明的系统提示。

将生成的答案返回给用户。在此之后，清除缓存中生成的所有内容，仅保留最初缓存的上下文。这使得大型语言模型为下一次生成做好准备。

CAG 承诺通过将所有上下文存储在键值（KV）缓存中，来实现更准确的检索，而不是在每次需要计算答案时仅检索部分数据。但实际情况如何呢？

• 在面对极长的上下文时，CAG 并不能解决检索不准确的问题。
• 在数据安全方面，CAG 存在诸多限制。
• 对于大型组织而言，加载整个内部知识库几乎是不可能的。
• 缓存会变得固定不变，并且添加新数据也存在问题。

实际上，在大多数大语言模型（LLM）提供商引入提示缓存之后，我们已经在一段时间内使用了 CAG 的一个变体。我们所做的事情可以描述为 CAG 和检索增强生成（RAG）的融合，并通过以下步骤来实现：

数据预处理：

对于缓存增强生成，我们仅使用很少发生变化的数据源。除了数据很少变化这一要求之外，我们还应该考虑哪些数据源经常被相关查询所访问。一旦掌握了这些信息，我们才会将所有这些选定的数据预先计算并存储到大型语言模型（LLM）的键值缓存（KV Cache）中。将其缓存在内存里。这一步骤仅需执行一次，后续步骤可以多次运行，无需重新计算初始缓存。

对于检索增强生成（RAG），如有必要，预先计算向量嵌入并存储在兼容的数据库中，以便在步骤 4 中进行后续检索。有时，对于检索增强生成（RAG）来说，较为简单的数据类型就已足够，常规数据库或许就能满足需求。

查询路径：

构建一个提示词，该提示词应包含用户查询内容以及系统提示词，系统提示词中需说明大型语言模型（LLM）应如何使用缓存的上下文和检索到的外部上下文。

对用户查询进行嵌入处理，以便通过向量数据库进行语义搜索，并查询上下文存储库以检索相关数据。如果不需要语义搜索，则查询其他数据源，例如实时数据库或网络。

用在步骤 4 中检索到的外部上下文来丰富最终的提示词内容。

向用户返回最终答案。

现在让我们来了解一下最新的发展 —— 智能体检索增强生成（Agentic RAG）。

Agentic RAG

智能体检索增强生成（Agentic RAG）添加了两个额外的组件，旨在减少在回答复杂用户查询时出现的不一致情况。

数据源路由。

自我反思（机制）。

让我们来探究一下它的端到端工作原理。

1、用户查询分析：我们将原始用户查询传递给基于大型语言模型（LLM）的智能体进行分析。在此过程中：

• 原始查询可能会被重写，有时会重写多次，从而生成单个或多个查询，以便沿着处理流程继续传递。
• 智能体决定是否需要额外的数据源来回答该查询。这是智能体发挥作用的第一步。

2、如果需要额外的数据，就会触发检索步骤。此时会进行数据源路由，对于智能体检索增强生成（Agentic RAG）系统，可能有一个或多个数据集可供使用，并且智能体有权决定应访问哪些数据集来回答这个特定的查询。举例如下：

• 实时用户数据。这是一个相当不错的概念，因为我们可能拥有一些用户的实时信息，比如当前位置。
• 用户可能感兴趣的内部文档。
• 网络上可获取的数据。
  ……

3、一旦从可能的多个数据源中检索到数据，我们会像在常规的检索增强生成（RAG）中那样对其重新排序。这也是一个重要的步骤，因为这里可以将使用不同存储技术的多个不同数据源集成到检索增强生成（RAG）系统中。检索过程的复杂性可以隐藏在提供给智能体的工具背后。

4、我们尝试直接通过大型语言模型（LLM）来组织答案（或多个答案，或一系列操作）。这可能在第一轮就完成，也可能在进行自我反思之后完成。

5、对答案进行分析、总结，并评估其正确性和相关性：

• 如果智能体判定答案足够好，就会将其返回给用户。
• 如果智能体判定答案需要改进，我们就会尝试重写用户查询，并重复生成循环。这就是常规检索增强生成（RAG）与智能体检索增强生成（Agentic RAG）的第二个不同之处得以体现的地方。

总结

我们回顾了现代检索增强生成（RAG）架构的演变历程。检索增强生成（RAG）并没有过时，而且在短期内也不会被淘汰。我认为，在未来一段时间内，这些架构将继续发展，学习它们并了解何时使用何种架构是一项不错的投资。

一般来说，架构越简单越好，因为当你把系统变得更复杂时，将会面临新的挑战。其中一些新出现的挑战包括：

• 难以对端到端系统进行评估。
• 由于需要多次调用大型语言模型（LLM），导致端到端延迟增加。
• 运营成本上升。