如何为你的业务选择最合适的 RAG 架构？

最新推荐文章于 2025-08-04 13:50:50 发布

原创最新推荐文章于 2025-08-04 13:50:50 发布 · 1.1k 阅读

CC 4.0 BY-SA版权

文章标签：

#langchain #人工智能 #自然语言处理 #大模型训练 #AI #RAG #ai大模型

RAG（检索增强生成）系统，过去是，将来也很可能是企业应用大语言模型 (LLM) 最实用的方式之一。这篇文章会聊聊 RAG 从 基础 RAG 到 代理式 RAG 是怎么一步步发展过来的。读完后，你会明白每个版本的架构主要解决了什么问题。

基础 RAG 是怎么来的？

基础 RAG (Naive RAG) 差不多是和 LLM 在 2022 年底随 ChatGPT 一起火起来的。RAG 技术的出现，是为了解决 LLM 本身存在的一些问题，主要有这几个：

幻觉（也就是模型会“一本正经地胡说八道”）
上下文窗口大小有限
不能获取非公开数据 （比如公司内部资料）
模型的知识停留在训练数据截止的那个时间点

最简单的基础 RAG 流程大致是这样：

基础 RAG 流程图

数据准备阶段 (Indexing):

加载和切块 (Load & Chunk): 把你的知识库（比如 Confluence 文档、PDF 报告等）内容切成一个个小的文本块 (chunks)。每个块就是一个可以被检索的信息单元。
向量化 (Embed): 用嵌入模型 (Embedding Model) 把每个文本块变成一串数字，也就是向量嵌入 (Vector Embedding)。
存储 (Store): 把所有向量嵌入存到向量数据库 (Vector Database) 里。同时也要存好每个向量对应的原始文本和一些额外信息（比如来源是哪里）。

检索和生成阶段 (Retrieval & Generation):

问题向量化: 用和第 2 步一样的嵌入模型，把用户的问题也变成向量。
向量搜索: 用问题的向量，在向量数据库里找最相似的向量（通常用近似最近邻 ANN 搜索）。你要决定找出多少个（Top-K），这决定了给 LLM 多少参考信息。
获取上下文: 数据库会返回 K 个最相似的向量，然后根据这些向量找到对应的原始文本块。
生成答案: 把用户的问题和找到的 K 个文本块组合成一个提示 (prompt)，发给 LLM。提示词里要告诉 LLM 只能根据给的这些文本块 来回答问题。（提醒一下：这不代表提示词不重要了。你还是得好好设计提示词，让 LLM 的回答符合预期，比如，找不到答案时别瞎编。）

基础 RAG 系统的关键部分

就算是基础 RAG，真要做成能用的系统，也要考虑很多细节：

RAG 系统的关键组件

搜索阶段 (Retrieval):

F) 切块策略 (Chunking): 怎么切分文档？
- 块切多大（小块 vs. 大块）？
- 切块时要不要让相邻块内容有重叠 (Overlapping Windows)？
- 搜到块之后，要不要把整个文档或相邻块也关联上，还是只用搜到的那个块？
C) 嵌入模型 (Embedding Model): 选哪个模型把文字和问题变成向量？要考虑模型适不适合你的业务领域。
D) 向量数据库 (Vector Database):
- 用哪种数据库？
- 放哪里部署？
- 存哪些额外信息（元数据）？（用来提前筛选或后续过滤）
- 用什么索引方法？
E) 向量搜索 (Vector Search):
- 用哪种方法衡量相似度？
- 搜索时先过滤元数据还是先搜向量？
- 要不要用混合搜索 (Hybrid Search)？（结合关键词和语义搜索）
G) 搜索策略/规则 (Heuristics/Rules): 用在搜索过程中的一些规则或业务逻辑。
- 考虑信息新旧 (时效性)
- 去掉重复内容，让结果更多样 (上下文去重 / 多样性排序)
- 追踪来源，或者优先选择某些来源 (来源追踪 / 偏好)
- 根据情况预处理文档 (条件性文档预处理)

生成阶段 (Generation):

A) 大语言模型 (LLM): 选个能满足你需求的 LLM。
B) 提示工程 (Prompt Engineering): 就算给了上下文，好好设计提示词还是很关键。需要优化提示，让输出的格式、风格符合要求，还要防止有人恶意输入搞破坏 (提示注入或越狱)。

把这些都弄好，一个能跑起来的 RAG 系统就有了。

不过，现实往往是 —— 只靠基础 RAG，通常还不够解决复杂的实际业务问题。这类系统的准确性可能因为各种原因不够好。

高级 RAG 技术：让基础 RAG 效果更好

下面这些是实践证明能有效提高基础 RAG 准确性的进阶玩法：

查询转换 (Query Transformation): 可以用几种技巧：
- 查询重写 (Query Rewriting): 用 LLM 把用户原始问题改写一下，让它更方便搜索。比如，改改错别字，或者把复杂问题拆成几个简单的小问题。
- 查询扩展 (Query Expansion): 用 LLM 根据原始问题生成好几个不同的问法。然后用每个问法都去搜一次，找到更多可能相关的资料。查询转换能更好地理解用户想问什么，提高搜索准确率。
重新排序 (Re-ranking): 第一步搜索时可以先多找一些结果（比如 Top-50，比最终需要的 K 个多），然后用一种算得慢但更准的模型（通常是 Cross-Encoder）对这些结果重新排个序，选出最终的 Top-K。这种方法对查询扩展特别有用（因为它会搜出更多候选内容）。这和推荐系统里的两阶段排序有点像。
嵌入模型微调 (Fine-tuning Embedding Models): 在特定领域里（比如医疗、法律），通用的嵌入模型可能效果不好。这时候，专门针对这个领域的资料训练（微调）一个嵌入模型，能大大提高搜索相关性。

下面，我们再看看其他几种高级 RAG 技术和架构。

上下文检索 (Contextual Retrieval)

上下文检索是 Anthropic 团队去年提出的概念，目的是提高 RAG 系统搜索信息的准确度和相关性。

我觉得这个方法挺直观简单的，实践中效果也不错。

具体做法是这样：

上下文检索流程图

准备阶段:

按照选好的策略把每个文档切成块。
对每个块，把它和它所在的整个文档内容一起组合成一个提示词。
提示词里要求 LLM 找到这个块在文档里的位置，然后生成一段关于这个块的简单上下文摘要。把这个提示词发给选好的 LLM。
把上一步生成的上下文摘要和原始的块合并在一起。
用 TF-IDF 处理合并后的文本（生成稀疏向量，主要用于关键词匹配）。
用基于 LLM 的嵌入模型处理合并后的文本（生成密集向量，主要用于语义匹配）。
把第 5 步和第 6 步生成的稀疏和密集向量，都存到支持混合搜索的数据库里。

搜索阶段:

用用户的问题，同时进行语义搜索（用密集向量）和关键词搜索（用稀疏向量）。
用排名融合 (Rank Fusion) 技术（比如 RRF）把两种搜索结果合并起来，去掉重复的，选出 Top-N 个结果。
对这 Top-N 个结果进行重新排序 (Re-ranking)，选出最终的 Top-K 个结果。
把 Top-K 个结果（通常是原始的文本块，而不是摘要）和用户的问题组合起来，输入 LLM 生成最终答案。

关于这个方法的一些想法：

第 3 步 生成摘要听起来可能挺花钱（要调用 LLM），确实是这样。不过可以用提示缓存 (Prompt Caching) 技术来节省重复计算的成本。
提示缓存不管用闭源 API 模型还是自己部署的开源模型，基本都能用。

缓存增强生成 (CAG) 简介

最近，有篇讲缓存增强生成 (Cache-Augmented Generation, CAG) 的论文火了一下，被称为 RAG 的新技术。我们知道了 RAG 是怎么回事，下面简单说说 CAG：

RAG 与 CAG 对比

预加载上下文: 把所有外部信息预先计算好，加载到 LLM 的 KV 缓存里。这个过程一般只需要做一次。
生成: 把用户问题和系统提示（告诉 LLM 怎么用缓存里的信息）一起发给 LLM。
返回与重置: 把生成的答案返回给用户。然后，清掉缓存里这次生成的内容，只留下原来加载的上下文，为下一次请求做准备。

CAG 想把所有上下文都直接放到 LLM 的“眼前”（KV 缓存里），希望这样能更准，不像 RAG 那样每次只搜一部分。但实际上：

CAG 解决不了 上下文太长时（就算在缓存里）“大海捞针”和准确率下降的问题。
在数据安全和权限管理方面有挑战。
想把大公司所有内部知识库一次性加载到缓存里几乎不可能。
缓存是静态的，更新数据（增量索引）很麻烦。

其实，现在主流 LLM 服务商（比如 OpenAI, Anthropic）都推出了提示缓存 (Prompt Caching) 功能，某种程度上我们已经在用类似 CAG 的思路了。这种更实用的方法可以看成是 CAG 和 RAG 的结合：

RAG 与 CAG 融合流程

数据准备:

选择性缓存: 选那些不经常变、又经常被用到的数据源。把这些选好的数据预加载到 LLM 的 KV 缓存里（如果 LLM 服务支持的话）。
常规 RAG 索引: 对其他数据（经常变或者不适合缓存的）做常规 RAG 处理（比如算向量存库里，或者准备成其他能查的数据格式）。

查询过程:

准备基础提示: 准备好包含用户问题和系统指令的提示词（告诉它怎么结合缓存信息和后面搜到的信息）。
执行 RAG 搜索: （如果需要）根据用户问题，从向量库或其他数据源（比如实时数据库、Web API）搜索相关数据。
组合最终提示: 把第 4 步搜到的外部信息加到第 3 步的提示词里。
生成答案: 把最终组合好的提示词发给 LLM，生成答案并返回给用户。

下面，我们来看看最新的玩法——代理式 RAG (Agentic RAG)。

代理式 RAG (Agentic RAG)

代理式 RAG 通过引入 “代理” (Agent) 的概念来处理更复杂的问题，减少答案不准或前后矛盾的情况。它一般有两个关键升级：

数据源路由 (Data Source Routing)
反思/修正 (Reflection)

我们来看看它是怎么工作的：

代理式 RAG 流程图

问题分析 (Query Analysis): 首先，把用户的原始问题交给一个基于 LLM 的代理 (Agent) 去分析。代理可能会：
- 把原始问题改写或拆分成一个或几个小问题，方便后面处理。
- 判断回答问题需不需要额外的外部信息，这体现了代理的初步规划能力 (planning)。
数据源路由与搜索 (Data Source Routing & Retrieval): 如果代理觉得需要外部信息，就会启动搜索。这时候，数据源路由就起作用了：
- 系统里可以有好几种不同的数据来源（比如：实时用户数据库、内部文档库、网页搜索接口等）。
- 代理会根据问题和自己的计划，自己选择一个或多个最合适的数据来源去查信息。这显示了代理的工具使用能力 (tool use)。
重新排序 (Re-ranking): 从一个或多个数据来源搜到信息后，对它们进行重新排序（和前面说的高级 RAG 类似）。这一步可以整合来自不同存储技术（比如向量库、SQL 数据库、API）的信息。各种搜索的复杂操作可以打包成代理能用的**“工具” (Tools)**。
生成初步答案/执行动作 (Initial Generation / Action): 代理用处理过的问题和搜到的信息，试着让 LLM 生成初步答案，或者按计划做点事（比如调用另一个 API）。
反思/修正 (Reflection): 这是代理式 RAG 和其他方式的一个关键不同点。代理会评估一下初步的答案（或动作结果）怎么样，看看它对不对、相关不相关、全不全：
- 如果答案没问题，就返回给用户。
- 如果答案不行，代理就会开始**“反思修正”**：可能会重新分析问题、换个搜索方法（比如选不同的工具或参数）、或者让 LLM 再生成一次答案，直到达到预设的标准或者试够次数为止。