RAG 架构的演进之路

Naive RAG 架构剖析

2022年底，ChatGPT 的出现让大语言模型（LLMs）变得非常流行。差不多同一时间，一种叫做“检索增强生成”（RAG）的技术也出现了。这个技术主要是为了解决一些大语言模型本身存在的问题，比如：

1. 有时会“胡说八道”，也就是生成一些不准确或不真实的信息。

2. 能处理的信息量有限，就像一个人一次只能记住这么多东西。

3. 无法访问一些非公开的数据，比如公司内部的资料。

4. 无法自动获取模型训练之后的新信息，如果要更新知识，就需要重新训练模型，这既耗时又耗力。

RAG 的最简单架构设计的实现方式是这样的：

预处理阶段

1. 把整个知识库的文本资料分割成一个个小块，每个小块都是一段可以查询的文本。这些资料可能来自不同的地方，比如：公司内部的文档、PDF 报告等。

2. 用一个特殊的模型（嵌入模型）把这些文本块转换成一种特殊的代码（向量嵌入）。

3. 把这些代码存到一个特殊的数据库（向量数据库）里，同时保存每个向量对应的原始文本和指向向量的链接。

检索阶段

1. 在向量数据库里，用同一个嵌入模型处理知识库中的文档内容和用户的问题，确保查询和知识库中的信息能够准确匹配。

2. 在向量数据库的索引上运行查询，选择要检索的向量数量，这决定了你将用多少上下文信息来回答查询。

3. 向量数据库会执行一个搜索，找到最相似的向量，然后把这些向量映射回它们对应的原始文本块。

4. 把问题和检索到的上下文文本块一起通过一个提示词传递给大语言模型，告诉模型只用这些上下文来回答这个问题。这并不意味着不需要设计好的提示词--你还需要确保模型返回的答案符合预期，比如：如果检索到的上下文中没有相关信息，就不要编造答案。

Naive RAG 架构的模块组成

在搭建一个能用在实际工作（生产级）的 RAG 系统时，即使不使用什么高级技术，也要考虑很多会变化的部分（动态模块）。

检索部分

• 分块策略：决定怎么把用来提供额外信息的数据切成一块一块的。

  • 可以选择切小一点或大一点的块。

  • 可以用滑动窗口或固定窗口的方法来切。

  • 检索时，可以选择是否带上块的“亲戚”信息（父块/链接块），或者只用原始检索到的数据。

• 嵌入模型：选择一个模型，把额外信息转换成一种特殊的向量（嵌入到 latent space），或者用这个模型从这种向量中检索信息。这里需要考虑上下文嵌入。

• 向量数据库：

  • 选择用哪种数据库。

  • 决定数据库放在哪里。

  • 考虑除了向量嵌入，还要存哪些额外信息（元数据），这些信息可以用来在检索前筛选和检索后过滤结果。

  • 确定如何构建数据库的索引。

• 向量搜索：

  • 选择用什么标准来衡量相似度。

  • 决定查询时是先看元数据还是先做近似最近邻（ANN）搜索。

  • 可以考虑混合搜索方案。

• 启发式规则：在检索流程中应用一些基于经验的规则。

  • 根据文档的时间来调整重要性。

  • 对检索到的上下文进行去重，按多样性排序。

  • 检索时带上内容的原始来源信息。

  • 根据不同条件（比如：用户的查询意图、文档类型）对原始文本进行特别处理。

生成部分

• 大语言模型：为你的应用选择合适的大语言模型（LLM）。

• 提示词工程：即使可以在提示词中加入上下文信息，也需要精心设计提示词，调整系统，以生成符合预期的输出，并防止被“越狱”（即防止模型生成不适当的内容）。

完成所有这些步骤后，我们才能搭建起一个能运行的 RAG 系统。

但不幸的是，这类系统往往难以真正解决实际问题。由于各种原因，这种系统的准确性可能并不高。

Naive RAG 架构设计的高级技术

为了提升 Naive RAG 系统的精确度，我们尝试了一些有效的方法：

查询调整 

这里有几个技巧：

• 查询重写：让大语言模型（LLM）改写原始问题，让它更适合用来检索信息。这可能包括修正语法错误，或者把问题简化成更直接的表述。

• 查询扩展：让 LLM 对原始问题进行多次改写，生成多个不同的版本。然后，对每个版本都进行检索，以找到更多可能相关的信息。

重新排序 

对初次检索出来的文档，使用比普通搜索更复杂的方法来重新排序。这通常需要用到更大型的模型，并且在检索阶段故意获取比实际需要更多的文档。重新排序和前面提到的查询扩展一起用效果最好，因为查询扩展通常能返回更多的数据。这个过程有点像我们在推荐系统中的做法。

微调嵌入模型

在某些领域（比如：医疗），如果用基础的嵌入模型来检索信息效果不好，你可能需要对嵌入模型进行定制化的微调。

接下来，我们再看看其他一些高级的 RAG 技术和架构。

上下文检索

上下文检索这个想法是 Anthropic 团队去年提出来的，主要是为了让用检索来加强生成的 AI 系统更精确、更靠谱。

我觉得上下文检索既简单又直接，而且效果确实不错。

下面是上下文检索怎么操作的：

预处理阶段

1. 用你选好的方法把文档切成一块一块的文本。

2. 把每个文本块和整个文档一起放到一个提示词里。

3. 在提示词里加上指示，让大语言模型（LLM）找出文本块在文档里的位置，并给它写个简短的介绍。然后把这个提示词放到 LLM 里。

4. 把上一步做出来的介绍和原始文本块合在一起。

5. 把这些合并好的数据放到一个 TF-IDF 嵌入器里。

6. 再把数据放到一个基于 LLM 的嵌入模型里。

7. 把步骤5和步骤6做出来的东西存到一个能快速搜索的数据库里。

检索阶段

1. 用用户的提问去找相关的介绍。用一种叫近似最近邻（ANN）的方法来做语义匹配，同时用 TF-IDF 索引来做精确搜索。

2. 用排序融合技术把检索出来的结果合并、去重，然后选出前 N 个选项。

3. 对上一步的结果重新排序，缩小到前 K 个选项。

4. 把步骤3的结果和用户提问一起放到 LLM 里，生成最终的答案。

一些思考

步骤3听起来（实际上也是）很费事，但是用一个叫提示词缓存的技术可以大大减少这个成本。

提示词缓存这个技术可以用在私有（闭源）模型上，也可以用在开源模型上。

缓存增强生成（Cache Augmented Generation）

2024年底，社交媒体上出现了一份引起轰动的白皮书，介绍了一种可能彻底改变 RAG（检索增强生成）的技术--CAG（缓存增强生成）。我们先了解一下 RAG，再简单看看 CAG：

1. CAG 会把所有的外部预先信息计算好，存到大语言模型（LLM）的缓存里，并存到内存中。这个计算只需要做一次，之后就可以重复使用这个缓存，不需要重新计算。

2. 把用户的提问和一些系统提示词和怎么使用缓存信息的提示词一起输入 LLM。

3. 把 LLM 生成的答案返回给用户。完成后，清除缓存里的临时内容，只保留最初缓存的信息，这样 LLM 就可以准备生成下一个答案了。

CAG 承诺，通过把全部信息存在缓存里（而不是每次生成时只检索一部分），可以实现更精确的检索。但实际情况如何呢？

• CAG 并不能解决因为信息太长而导致的不准确问题。

• 在数据安全方面，CAG 有很多限制。

• 对于大公司来说，把整个内部知识库都加载到缓存里几乎不可能。

• 缓存不能动态更新，添加新数据非常困难。

实际上，自从很多 LLM 供应商引入了提示词缓存技术后，我们实际上已经在用 CAG 的一种变体了。我们的方法可以说是 CAG 和 RAG 的结合，具体操作如下：

数据预处理

1. 在 CAG 中，我们只使用变化不大的数据源。除了要求数据更新不频繁，我们还会考虑哪些数据源最常被查询用到。确定了这些信息后，我们才会把所有选定的数据预先计算好，存到 LLM 的缓存里，并缓存在内存中。这个计算只需要做一次，之后就可以多次使用，不需要重新计算。

2. 对于 RAG，如果需要，我们可以把向量嵌入预先计算好，存到兼容的数据库里，供之后检索用。有时候对于RAG来说，只需要更简单的数据类型，常规数据库就足够了。

查询路径

1. 构建一个包含用户提问和系统提示词的提示词，明确指导大语言模型怎么利用缓存的信息和外部检索到的信息。

2. 把用户提问转换成向量嵌入，用来在向量数据库里进行语义搜索，并从存储中检索相关数据。如果不需要语义搜索，就查询其他来源，比如实时数据库或互联网。

3. 把步骤4中获取的外部信息整合到最终的提示词中，以提高回答的质量。

4. 把最终生成的答案返回给用户。

接下来，我们将探讨最新的技术发展方向--Agentic RAG。

Agentic RAG 架构设计

Agentic RAG 引入了两个新的关键部分，目的是在处理复杂的用户问题时，让结果更加稳定可靠。

这两个部分是：

1. 数据源选择（Data Source Routing）。

2. 答案检查和调整（Reflection）。

下面我们看看这两个部分是怎么工作的。

Agentic RAG 的工作流程：

1. 分析用户的问题：把用户的问题交给一个基于大语言模型的智能助手来分析。在这个阶段：

   • 原始问题可能会被改写，有时候需要改写好几次，最后变成一个或几个新的问题，送到下一步处理。

   • 智能助手会判断是否需要额外的数据来回答这个问题。这是它展现自主决策能力的第一步。

2. 如果需要其他数据，就会开始检索步骤，这时会进行数据源选择。系统里可以预先设置一个或多个数据集，智能助手可以自己选择哪个数据源最适合当前的问题。比如：

   • 实时的用户数据（比如：用户现在的位置）。

   • 用户可能感兴趣的内部文件。

   • 网络上的公开数据。

3. 一旦从多个数据源中检索到数据，我们就会像在普通的  RAG 中一样对这些数据进行重新排序。这也是一个关键步骤，因为不同存储技术的数据源都可以整合到这个 RAG 系统中。检索过程的复杂性都被智能助手用的工具所隐藏。

4. 尝试直接用大语言模型生成答案（可能是一个答案，也可能是多个答案，或者是一组操作指令）。这个过程可以在第一轮就完成，或者在答案检查和调整之后进行。

5. 对生成的答案进行检查，总结并评估它们的正确性和相关性：

   • 如果智能助手认为答案已经很好，就直接返回给用户。

   • 如果智能助手觉得答案还需要改进，就会尝试重新改写用户的问题，并重复这个生成循环。这是 Agentic RAG 和 Naive RAG 的第二个主要区别。

最近，Anthropic 的开源项目 MCP，将会大大推动 Agentic RAG 的开发。

总结

我们已经回顾了检索增强生成（RAG）技术的发展过程。RAG 技术不仅没有过时，而且我认为它在未来还会继续发展。掌握这些技术架构，并知道什么时候该用哪种方案，会是一笔很值得的投资。

通常来说，方案越简单越好，因为系统的复杂性增加会带来新的挑战。一些新出现的挑战包括：

• 评估整个系统从开始到结束的性能变得困难。

• 多次调用大语言模型导致整个过程的延迟变长。

• 运营成本也随之增加。

总之，虽然 RAG 技术在不断进步，但我们在选择和应用时，还是需要考虑到这些新挑战。