RAG 分块策略

• 1. Simple RAG 简单切块
  • 1.1 目标与示例
• 2. Semantic Chunking 语义切块
  • 2.1 示例对比
  • 2.2 效果评估
• 3. Context Enriched Retrieval 上下文增强检索
  • 3.1 问题背景
  • 3.2 示例场景
  • 3.3 检索逻辑
  • 3.4 返回给模型的上下文
  • 3.5 效果评估
• 4. Contextual Chunk Headers 上下文分块标题
  • 4.1 核心概念
  • 4.2 示例说明
  • 4.3 如何使用这些标题进行更好的检索
  • 4.4 效果评估
• 5. Document Augmentation 文档增强
  • 5.1 核心概念
  • 5.2 示例说明
  • 5.3 检索流程优化
  • 5.4 效果评估
• 6. Query Transformation 查询转换
  • 6.1 核心概念
  • 6.2 查询转换的主要类型
  • 6.3 示例说明
  • 6.4 效果评估
• 7. Reranker 重排序
  • 7.1 核心概念
  • 7.2 为什么需要 Reranker
  • 7.3 工作流程与示例
  • 7.4 效果评估
• 8. RSE（语义扩展重排序）
  • 8.1 核心概念
  • 8.2 RSE 执行流程
  • 8.3 效果评估
• 9. Feedback Loop 反馈闭环
  • 9.1 核心概念
  • 9.2 为什么需要 Feedback Loop
  • 9.3 核心流程
  • 9.4 效果评估
• 10. Adaptive RAG 自适应检索增强生成
  • 10.1 核心概念
  • 10.2 为什么需要 Adaptive RAG
  • 10.3 核心流程
  • 10.4 效果评估
• 11. Self RAG 自反思检索增强生成
  • 11.1 核心概念
  • 11.2 为什么需要 Self RAG
  • 11.3 核心流程
  • 11.4 效果评估
• 12. Knowledge Graph 知识图谱
  • 12.1 核心概念
  • 12.2 为什么需要 Knowledge Graph
  • 12.3 示例说明
  • 12.4 实施建议与成本分析
  • 12.5 效果评估
• 13. Hierarchical Indices 层次化索引
  • 13.1 核心概念
  • 13.2 为什么需要 Hierarchical Indices
  • 13.3 工作流程
  • 13.4 效果评估
• 14. HyDE 假设文档嵌入
  • 14.1 核心概念
  • 14.2 为什么需要 HyDE
  • 14.3 核心流程
  • 14.4 局限性
  • 14.5 效果评估
• 15. Fusion 融合检索
  • 15.1 核心概念
  • 15.2 为什么需要 Fusion
  • 15.3 核心流程
  • 15.4 效果评估
• 16. CRAG 纠错型 RAG
  • 16.1 核心概念
  • 16.2 为什么需要 CRAG
  • 16.3 核心流程
  • 16.4 效果评估
• 17. Multi-Modal RAG 多模态检索增强生成
  • 17.1 核心概念
  • 17.2 为什么需要 Multi-Modal RAG
  • 17.3 工作流程
  • 17.4 效果评估
• 18. RAG 技术对比与评分总览表

1. Simple RAG 简单切块

Simple RAG（简单切块）的核心思想是通过简单的文本分块和相似度匹配来查找相关内容。这是最基础的 RAG 流程，适用于结构简单、语义明确的文档。

为了更直观地理解这一过程，我们可以参考以下流程图：

1.1 目标与示例

本节通过一个具体示例来展示 Simple RAG 的工作流程。假设我们的目标是回答用户的问题："北京有什么著名的景点？"

第一步：准备原始文档

假设我们有如下一段关于北京的介绍：

北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。故宫是明清两代皇帝居住的地方，非常宏伟壮观。颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

第二步：将文档按句子拆分（文本分块）

为了方便检索，我们将这段文字按句子进行拆分，形成一个个"知识块"：

1. 北京是中国的首都，有着悠久的历史和丰富的文化。
2. 北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。
3. 故宫是明清两代皇帝居住的地方，非常宏伟壮观。
4. 颐和园是一座皇家园林，风景优美。
5. 长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

这些句子可以看作是一个小型的知识库。

第三步：用户提问

用户问："北京有什么著名的景点？"

第四步：相似度匹配（检索）

RAG 的第一步是"检索"，也就是在知识库中找到与问题最相关的句子。我们可以使用简单的相似度方法（如余弦相似度 + 向量化），或者关键词匹配来找相关句子。

余弦相似度的计算公式如下：

$$\text{similarity} = \cos(\theta) = \frac{A \cdot B}{\|A\| \|B\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}}$$

在这个例子中，第 2 句最直接地回答了问题：

"北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。"

这就是我们检索到的内容。

第五步：生成答案（增强生成）

接下来是"生成"部分。我们把检索到的相关内容作为上下文输入给语言模型，让它结合这个信息来生成答案。

输入给语言模型的内容：

问题：北京有什么著名的景点？

相关信息：
北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。

语言模型输出的答案：

北京有许多著名的景点，包括故宫、天安门广场、颐和园和长城。这些地方不仅具有深厚的历史文化底蕴，也吸引了大量国内外游客前来参观。

2. Semantic Chunking 语义切块

Semantic Chunking（语义切块）是一种基于语义进行文本分块的方法，而不是简单地按固定长度或句子数量拆分。这样能更好地保持信息的完整性和相关性，避免将一个完整的语义割裂到两个不同的块中。相比于机械的固定长度分块，语义切块能够识别文本的主题边界，确保每个 Chunk 都包含完整且独立的语义单元。

2.1 示例对比

固定分块（不推荐）

这种方式机械地按照字符数截断，容易导致语义断裂：

Chunk 1: 北京是中国的首都，有着悠久的历史和丰富的文化。
Chunk 2: 北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。
Chunk 3: 故宫是明清两代皇帝居住的地方，非常宏伟壮观。

北京是中国的首都，有着
悠久的历史和丰富的文化。

可以看到，"有着"和"悠久的历史"被强行分开了，这会影响模型对上下文的理解。

语义分块（推荐）

这种方式根据内容的语义边界进行划分：

Chunk 1:
北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。

Chunk 2:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

两个 Chunk 分别表达了"北京概况"和"主要景点介绍"，具有清晰的主题边界。

2.2 效果评估

通过对比可以看出，语义切块相比固定分块具有明显优势。固定分块的评分较低（0.2 / 1.0），主要是因为它容易破坏语义完整性。而语义分块通过识别主题边界，能够保持每个 Chunk 的语义独立性，从而在实际应用中获得更高的检索准确率和生成质量。

3. Context Enriched Retrieval 上下文增强检索

Context Enriched Retrieval（上下文增强检索）是一种改进的检索策略，其核心思想是在检索时不仅返回最相关的文本片段，还一并提供其前后相邻的上下文 Chunk，以增强语义完整性与生成质量。这种方法解决了单个 Chunk 信息不完整的问题，能够为语言模型提供更丰富的背景信息。

3.1 问题背景

在传统的检索系统中，单个 Chunk 可能信息不完整，导致检索结果不够准确或生成回答时缺乏上下文支持。例如，如果只检索到"它非常宏伟壮观"，模型可能不知道"它"指的是什么。这种代词指代不清、缺乏前置信息的情况会严重影响答案质量。

3.2 示例场景

假设用户提问："故宫有什么特点？"我们有如下三个 Chunk：

Chunk 1:
北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。

Chunk 2:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

Chunk 3:
颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

3.3 检索逻辑

检索过程如下：

1. 用户查询关键词：故宫
2. 最匹配 Chunk：Chunk 2
3. 同时返回：Chunk 1 + Chunk 2 + Chunk 3

3.4 返回给模型的上下文

[上下文窗口]
Chunk 1:
北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。

Chunk 2:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

Chunk 3:
颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

3.5 效果评估

上下文增强检索的评分为 0.6 / 1.0，相比 Simple RAG 有了明显提升。通过提供相邻的上下文 Chunk，模型能够获得更完整的信息，从而生成更准确、更连贯的答案。这种方法特别适用于文档内容紧密相关、需要联系上下文理解的场景。

4. Contextual Chunk Headers 上下文分块标题

Contextual Chunk Headers（上下文分块标题）是一种为文本块添加元数据的策略。它为每一个文本块（Chunk）添加一个简洁、描述性强的标题，用于概括该 Chunk 的核心内容。这个标题作为额外的元信息，在检索时可作为关键词或语义线索使用。

4.1 核心概念

这种方法的主要目的包括：

• 增强 Chunk 的可检索性，通过标题快速定位相关内容
• 提供更丰富的语义提示，帮助检索系统理解 Chunk 主题
• 提高检索系统的匹配准确率，减少误匹配情况

4.2 示例说明

我们继续以之前的北京旅游文档为例进行说明。

原始文本：

北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。故宫是明清两代皇帝居住的地方，非常宏伟壮观。颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

按句子拆分后的 Chunks：

Chunk 1:
北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。

Chunk 2:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

Chunk 3:
颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

添加 Contextual Chunk Headers 后：

Chunk	Header（上下文标题）	内容
Chunk 1	北京概况与主要景点概述	北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。
Chunk 2	故宫：明清皇家宫殿	故宫是明清两代皇帝居住的地方，非常宏伟壮观。
Chunk 3	颐和园与长城简介	颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

4.3 如何使用这些标题进行更好的检索

检索流程优化

通过添加标题，检索流程得到了优化：

1. 用户提问："故宫有什么特点？"
2. 检索器行为：不仅查找内容中包含"故宫"的 Chunk，还查找标题中含有"故宫"或"皇家宫殿"的 Chunk
3. 结果：更加精准地定位到 Chunk 2

模型输入示例

[Header] 故宫：明清皇家宫殿
[Content] 故宫是明清两代皇帝居住的地方，非常宏伟壮观。

这样，语言模型不仅能理解内容本身，还能利用标题提供的额外语义信息来生成更准确的回答。

4.4 效果评估

Contextual Chunk Headers 的评分为 0.5 / 1.0。这种方法通过添加描述性标题，提升了检索的精准度，但由于标题本身需要人工设计或模型生成，存在一定的成本和准确性权衡。

5. Document Augmentation 文档增强

Document Augmentation（文档增强）是一种通过自动生成相关查询来扩展检索能力的策略。在构建高质量的检索增强生成系统（RAG）时，一个常见的挑战是：如何在用户提问方式多样、关键词不一致的情况下，仍能准确地找到相关知识？Document Augmentation 正是为了解决这个问题而设计的。

5.1 核心概念

定义：在原始文档的基础上，自动生成与其内容相关的问题-答案对或潜在查询语句，并将这些"虚拟查询"作为额外的检索入口加入到知识库中。

目的：

• 提高系统对不同表达方式的鲁棒性，应对用户的多样化提问
• 扩展检索入口，提升匹配准确率，减少漏检情况
• 增强模型对上下文的理解能力，提供更多语义线索

5.2 示例说明

原始文本：

北京是中国的首都，有着悠久的历史和丰富的文化。北京有很多著名的景点，比如故宫、天安门广场、颐和园和长城。故宫是明清两代皇帝居住的地方，非常宏伟壮观。颐和园是一座皇家园林，风景优美。长城是中国古代伟大的建筑之一，吸引着世界各地的游客。

对应 Chunk 示例：

Chunk:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

使用语言模型生成的问题（Query-Augmented Queries）：

[Generated Questions]
- 故宫的历史背景是什么？
- 故宫在哪个朝代被使用？
- 明清时期的皇宫在哪里？
- 故宫有什么特色？
- 故宫为什么著名？

将其加入检索索引中：

Chunk ID	内容	附加问题
Chunk 2	故宫是明清两代皇帝居住的地方，非常宏伟壮观。	1. 故宫的历史背景是什么？ 2. 故宫在哪个朝代被使用？ 3. 明清时期的皇宫在哪里？ 4. 故宫有什么特色？ 5. 故宫为什么著名？

5.3 检索流程优化

假设用户提问："故宫以前是谁住的？"

如果没有文档增强，可能无法直接匹配到"故宫是明清两代皇帝居住的地方"。但有了增强的问题入口，例如：

• "故宫在哪个朝代被使用？"
• "明清时期的皇宫在哪里？"

就可以更精准地定位相关内容。

模型输入增强示例

[Original Content]
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

[Augmented Queries]
- 故宫在哪个朝代被使用？
- 明清时期的皇宫在哪里？
- 故宫有什么特色？

这样，检索器可以从多个角度理解用户的意图，提高召回率和准确性。

5.4 效果评估

Document Augmentation 的评分为 0.8 / 1.0，是目前评分最高的方法之一。通过自动生成多样化的查询问题，这种方法显著提升了系统对不同表达方式的适应能力，大幅降低了因措辞不同导致的检索失败。这种方法特别适合用户查询模式多样、需要高召回率的应用场景。

6. Query Transformation 查询转换

Query Transformation（查询转换）是一种在检索前对用户查询进行优化的技术。它通过对原始查询进行语义理解、扩展、重写或多样化处理，生成更适合匹配知识库内容的查询形式，从而提高检索效果。

6.1 核心概念

定义：在进行知识库检索前，对用户的原始查询进行语义理解、扩展、重写或多样化处理，以生成更适合匹配知识库内容的查询形式。

目的：

• 提高检索器的召回率和准确率，减少检索失败
• 增强模型对模糊提问、口语化表达的理解能力
• 拓展多种检索路径，应对不同表达方式

6.2 查询转换的主要类型

类型	描述	示例
Query Expansion (查询扩展)	添加同义词、相关实体或上下文信息。	"故宫" → "故宫的历史、建筑风格、开放时间"
Paraphrasing (释义/重述)	将原句用不同语言结构表达。	"故宫以前是谁住的？" → "明清时期皇帝住在哪里？"
Translation (翻译)	多语言支持下的跨语言检索。	英文问题："What is the history of the Forbidden City?"
Decomposition (分解)	将复杂问题拆解为多个子问题。	"北京有哪些景点？它们各自的特点是什么？" → 分为两个查询分别检索
Hypothetical Document Generation (假设文档生成)	生成一段可能包含答案的"假想文本"，用于向量匹配。	生成一段关于"故宫是明清皇宫"的描述，用于相似度匹配

6.3 示例说明

用户提问：

"故宫以前是谁住的？"

这个句子虽然清晰，但在知识库中未必能直接匹配到"故宫是明清两代皇帝居住的地方"。

经过 Query Transformation 后的版本：

转换方式	转换结果
扩展	故宫的历史用途、谁曾居住在故宫、明清时期的皇宫是哪里
重述	明清时期的皇帝住在哪个宫殿？
分解	故宫的作用是什么？明清皇帝住在哪里？
假设文档生成	"故宫是中国明清两代的皇家宫殿，曾是多位皇帝的居所。"

6.4 效果评估

Query Transformation 的评分为 0.5 / 1.0。这种方法通过对用户查询的多样化处理，提升了检索的灵活性和准确性。不过，过度的查询转换可能会引入噪声或改变原始意图，因此需要在转换程度和准确性之间找到平衡。这种方法特别适合处理口语化、模糊或复杂的用户查询。

7. Reranker 重排序

在构建高质量的检索增强生成系统（RAG）时，我们常常会遇到这样的问题：初步检索出的结果虽然相关，但最匹配的内容并未排在第一位，导致最终生成的答案质量下降。为了解决这个问题，我们引入一个关键优化步骤：Reranker（重排序）。

7.1 核心概念

Reranker（重排序）是指在初步检索出 Top-K 个候选 Chunk 后，使用更精细的语义模型对这些候选进行重新打分和排序的过程。

它的主要目的在于：

1. 提高相关性：将真正与用户问题最相关的文档排在前面。
2. 弥补向量缺陷：向量相似度（如余弦相似度）有时无法捕捉复杂的语义匹配，Reranker 可以进行更深层次的语义分析。
3. 优化用户体验：确保生成模型（LLM）接收到的上下文是最精准的，从而生成更高质量的回答。

7.2 为什么需要 Reranker

单纯依赖向量检索存在一定的局限性，如下表所示：

问题	描述
向量检索的局限性	使用向量相似度排序时，可能忽略局部语义匹配或关键词的精确匹配。
表达方式差异	用户提问方式多样（如口语化、模糊表达），与知识库中的标准表达不一致。
上下文缺失	单个 Chunk 可能信息不足，向量模型难以准确判断其与问题的深层关联。

7.3 工作流程与示例

为了直观展示 Reranker 的作用，我们来看一个具体的示例。

用户提问："故宫有什么特点？"

1. 初步检索结果（Top-3）

在使用 Reranker 之前，基于向量相似度的检索结果可能如下：

Rank	Chunk 内容	初始得分
1	颐和园是一座皇家园林，风景优美。	0.75
2	故宫是明清两代皇帝居住的地方，非常宏伟壮观。	0.72
3	北京有很多著名景点，比如故宫、天安门广场、颐和园和长城。	0.68

可以看到，虽然第 2 条内容最相关，但由于向量匹配的某种偏差，它被排在了第 2 位。

2. 加入 Reranker 后的结果

引入 Reranker 模型对这 3 个结果进行重新打分后：

Rank	Chunk 内容	Rerank 得分
1	故宫是明清两代皇帝居住的地方，非常宏伟壮观。	0.95
2	北京有很多著名景点，比如故宫、天安门广场、颐和园和长城。	0.70
3	颐和园是一座皇家园林，风景优美。	0.45

通过 Reranker，最相关的信息被成功提升到了第一位。

7.4 效果评估

Reranker 的引入通常能显著提升 RAG 系统的准确率。在上述示例中，评分可达 0.7 / 1.0。虽然增加了一个计算步骤，但对于追求高精度的应用场景，这是非常值得的投入。

8. RSE（语义扩展重排序）

在构建高质量的检索增强生成系统（RAG）时，相关信息往往不是孤立存在于某个 chunk 中，而是分布在多个连续或上下文相关的段落中。为了解决这一问题，我们引入了 RSE（Re-ranking with Semantic Expansion，语义扩展重排序）。

8.1 核心概念

RSE 是一种结合向量检索、语义相似度分析与上下文连贯性判断的检索增强技术。它不仅关注单个 chunk 的相关性，还通过"向下查找"机制，寻找与其语义连贯的相邻片段，形成更完整的上下文。

其核心思想包括：

1. 跨 chunk 信息整合：识别相关信息可能跨越多个 chunk 的情况。
2. 上下文完整性：弥补单一 chunk 语义表达不足的问题。
3. 动态窗口扩展：利用上下文窗口进行语义扩展，提升整体匹配效果。

8.2 RSE 执行流程

RSE 的标准执行流程如下：

1. 固定切分与向量化入库

将原始文档按固定长度（如 256 token）进行切块，存入向量数据库。

• Chunk 1: 北京是中国的首都...
• Chunk 2: 北京有很多著名景点...
• Chunk 3: 故宫是明清两代皇帝居住的地方...
• Chunk 4: 颐和园是一座皇家园林...

2. 初步检索与过滤

用户输入查询后，返回 Top-K 个最相似的 chunks，并过滤掉低相关性内容。

Chunk	相似度得分
Chunk 3	0.82
Chunk 2	0.75
Chunk 4	0.58

3. 基于上下文窗口的连续片段查找

对于每一个高相似度 chunk，向下查找其相邻的 chunk，组成"候选上下文组"。例如以 Chunk 3 为中心：

上下文组：Chunk 2 + Chunk 3 + Chunk 4

4. 计算上下文组的总相似度得分

对上下文组中的 chunk 进行加权求和，筛选最终保留的组。

$$\text{Score}_{\text{group}} = \sum_{i \in \text{window}} w_i \cdot \text{Score}_i$$

例如：

• Chunk 2+3: $0.75 + 0.82 = 1.57$ (保留)
• Chunk 3+4: $0.82 + 0.58 = 1.40$ (可能丢弃)

5. 返回最终上下文

将满足条件的上下文组合并，作为语言模型的输入。

8.3 效果评估

RSE 策略通过重建上下文联系，显著提升了信息的完整性。评分可达 0.8 / 1.0。它特别适用于长文档问答和需要综合多段信息的场景。

9. Feedback Loop 反馈闭环

当前的 RAG 系统大多是静态的，无法根据用户的使用情况进行自我优化。Feedback Loop（反馈闭环）机制的引入，旨在解决这一瓶颈，实现系统的持续进化。

9.1 核心概念

Feedback Loop 是指在 RAG 系统中设计一套机制，收集用户对回答内容的反馈（如点击、评分、修改建议等），并基于这些数据不断优化检索策略、知识库内容和生成质量。

其主要目的为：

1. 提升准确性：通过用户反馈修正错误，提高回答的相关性。
2. 自我进化：使系统能够适应新的场景和需求。
3. 增强参与感：让用户参与到知识库的构建和优化中。

9.2 为什么需要 Feedback Loop

问题	描述
数据静态	知识仅来源于初始文档，无法适应新场景或及时修正错误。
模型盲区	语言模型可能生成幻觉或错误答案，缺乏实时纠错机制。
用户无参与感	缺乏反馈入口，用户难以表达满意度，系统无法获知真实效果。

9.3 核心流程

反馈闭环的建立通常包含以下四个步骤：

1. 用户交互与反馈采集

提供多种方式让用户表达反馈：

• 显式反馈：点赞（👍）、点踩（👎）。
• 隐式反馈：点击率、页面停留时间。
• 自由输入：用户提交的更正建议或补充信息。

2. 反馈结构化存储

将收集到的反馈进行结构化存储，便于后续分析。

字段	内容示例
查询语句	"故宫有什么特点？"
返回内容	"故宫是明清两代皇帝居住的地方..."
反馈类型	👎 错误
用户建议	"还应提到建筑风格、文物价值等。"

3. 数据分析与模型优化

定期分析反馈数据，用于：

• 优化检索策略：调整 Reranker 权重或 Chunk 分块逻辑。
• 更新知识库：添加缺失信息，修正错误内容。
• 微调模型：使用高质量的反馈数据对 LLM 进行微调（Fine-tuning）。

4. 更新系统并验证

将优化后的策略部署，并通过 A/B 测试验证效果。

9.4 效果评估

Feedback Loop 的初始评分可能为 0.7 / 1.0，但其价值在于随时间推移而递增。随着反馈数据的积累，系统的表现会越来越好，形成良性循环。

10. Adaptive RAG 自适应检索增强生成

面对复杂多变的用户查询，单一的检索策略往往难以兼顾效率与效果。Adaptive RAG（自适应 RAG）应运而生，它能够根据查询的类型动态选择最佳的处理流程。

10.1 核心概念

Adaptive RAG 是一种智能的 RAG 架构，它根据用户查询的类型、意图或复杂程度，动态选择不同的检索策略、模型配置和知识库来源。

其核心思想是：因地制宜。不同的问题需要不同的解法，不应"一刀切"。

10.2 为什么需要 Adaptive RAG

问题	描述
固定策略局限	所有查询走同一流程，简单问题浪费资源，复杂问题效果不佳。
多样化需求	用户问题涵盖事实性、解释性、推理性等多种类型。
多源异构数据	知识分布在数据库、PDF、网页等不同介质中。

10.3 核心流程

Adaptive RAG 的工作流程可以分为四个主要步骤：

1. 查询类型识别 (Query Type Detection)

通过分类模型判断用户查询的类别：

类型	描述	示例
Fact-based	事实性问题	"故宫建于哪个朝代？"
Exploratory	探索性问题	"北京有哪些值得一去的地方？"
Comparative	比较类问题	"故宫和卢浮宫有什么区别？"
Multi-hop	多跳推理类	"故宫建成后经历了哪些重大事件？"

2. 选择检索策略

根据识别出的类型，匹配最佳策略：

• Fact-based：精确关键词检索 + Reranker。
• Exploratory：语义扩展检索 + 上下文增强。
• Comparative：多文档对比 + 双向 chunk 匹配。
• Multi-hop：多阶段检索 + RSE。

3. 选择知识库与模型

• 知识库：事实类查结构化数据，探索类查长文本。
• 模型配置：简单问题用小模型（低延迟），复杂问题用大模型（高推理能力）。

10.4 效果评估

Adaptive RAG 通过灵活调度资源，显著提升了系统的整体表现，评分可达 0.86 / 1.0。它是构建企业级、通用型 RAG 系统的重要架构方向。

11. Self RAG 自反思检索增强生成

在构建高质量的检索增强生成系统（RAG）时，我们常常面临一个挑战：检索出的结果中可能包含大量不相关或冗余的信息，影响最终生成答案的质量和准确性。为了解决这个问题，我们引入一种更智能、具备"自我评估"能力的 RAG 架构：Self RAG（Self-Reflective Retrieval-Augmented Generation）。

11.1 核心概念

Self RAG 是一种具备"自反思"机制的 RAG 架构。它不仅依赖外部知识库进行信息检索，还能通过语言模型自身的判断能力，对检索结果进行筛选、评估和过滤，从而只使用最相关的片段来生成答案。

其核心思想在于：

• 不是所有检索结果都值得使用。
• 模型应具备"判断哪些 Chunk 有用"的能力。
• 在生成前主动过滤噪声，提升回答质量。

11.2 为什么需要 Self RAG

问题	描述
噪声干扰	检索结果中常包含无关内容，影响生成质量。
多跳推理困难	多个 Chunk 可能提供矛盾或部分信息，难以整合。
上下文浪费	低效使用 Prompt Token，输入了大量无用信息。

11.3 核心流程

Self RAG 的工作流程可以通过以下步骤实现：

1. 初步检索 Top-K Chunks

使用传统向量检索或关键词匹配方式，从知识库中获取多个候选 Chunk。

Chunk 1: 北京是中国的首都...
Chunk 2: 故宫是明清两代皇帝居住的地方...
Chunk 3: 颐和园是一座皇家园林...
Chunk 4: 长城是中国古代伟大的建筑之一...

2. 模型自主判断 Chunk 相关性

让语言模型（如 Qwen、ChatGLM、Llama3）逐条分析每个 Chunk 是否真正有助于回答用户问题，并给出理由。

用户问题："故宫有什么特点？"

Chunk	是否相关	理由
Chunk 1	❌	讲述北京整体情况，未提及故宫。
Chunk 2	✅	明确描述了故宫的历史地位。
Chunk 3	❌	谈论颐和园，与问题无关。
Chunk 4	❌	讲述长城，与问题无关。

3. 选择高相关性 Chunk 进行生成

仅将被判定为"相关"的 Chunk 输入给语言模型用于生成最终答案。

精选上下文：

Chunk 2: 故宫是明清两代皇帝居住的地方，非常宏伟壮观。

4. 生成最终答案并输出

故宫是明清两代皇帝居住的地方，非常宏伟壮观。它不仅是世界上保存最完整的古代宫殿建筑群之一，也是中国古代宫廷文化的代表。

11.4 效果评估

Self RAG 的评分为 0.6 / 1.0。虽然它能有效过滤噪声，但引入了额外的模型推理开销，可能会增加系统的延迟。

12. Knowledge Graph 知识图谱

在构建高质量的 RAG 系统时，我们常常面临一个深层问题：文本中的信息是相互关联的，但传统的"段落式"检索方式难以捕捉这些复杂的关系。为了解决这个问题，我们可以引入一种结构化表示方法：Knowledge Graph（知识图谱）。

12.1 核心概念

知识图谱是一种以图结构组织信息的方式，通过实体（Entity）、关系（Relation）和属性（Attribute）三元组来表达现实世界中事物之间的语义联系。

其核心形式为：(主体) —[关系]→ (客体)

例如：

• (故宫) —[建造于]→ (明朝)
• (北京) —[包含]→ (故宫)
• (皇帝) —[居住于]→ (故宫)

12.2 为什么需要 Knowledge Graph

优势	描述
更强的语义表达能力	不仅表达事实，还能表达因果、层级、时间等逻辑关系。
支持多跳推理	可以通过图遍历实现"从 A 推出 B 再推出 C"的推理过程。
提高检索效率	图数据库支持快速路径查找和关系挖掘。
增强生成连贯性	模型能理解上下文之间的依赖关系，生成更自然的回答。

12.3 示例说明

用户提问："故宫是哪个朝代建的？"

传统 RAG 检索结果

Chunk:
故宫是明清两代皇帝居住的地方，非常宏伟壮观。

虽然提到了"明清"，但没有明确指出"明朝初建"。

使用 Knowledge Graph 后的结果

这样，模型可以通过图查询直接获取"故宫建于明朝"，并进一步扩展相关信息。

12.4 实施建议与成本分析

实施建议

方法	描述	推荐程度
小规模图谱构建	适用于特定领域（如医疗、法律、金融）的结构化数据抽取。	⭐⭐⭐
大语言模型辅助提取	利用 Qwen、ChatGLM 等自动提取三元组。	⭐⭐
图数据库存储	使用 Neo4j、Amazon Neptune 等支持高效图查询。	⭐⭐
人工审核机制	对自动生成的图谱进行校验，避免错误传播。	⭐⭐⭐

成本分析

构建知识图谱的成本通常较高：

• 数据清洗：需要大量预处理以提取实体和关系。
• 关系定义：需要专家参与定义概念之间的语义关系。
• 维护更新：动态变化的信息需持续维护图谱。
• 技术门槛：图数据库使用、三元组建模对团队要求较高。

12.5 效果评估

Knowledge Graph 的评分为 0.78 / 1.0。它非常适合概念之间存在明确、复杂语义关系的场景，但对于快速搭建原型或关系模糊的场景，成本效益较低。

13. Hierarchical Indices 层次化索引

在构建 RAG 系统时，我们常常面临一个两难问题：小粒度 Chunk 检索更精准，但缺乏上下文；大粒度 Chunk 上下文丰富，但检索效率低、容易引入噪声。为了解决这个问题，我们引入一种结构化检索策略：Hierarchical Indices（层次化索引）。

13.1 核心概念

层次化索引是一种将文本数据按不同粒度组织成"多级索引"的方式。先用大块进行初步筛选，再在匹配的大块中对包含的小块进一步检索，从而在检索精度与上下文完整性之间取得平衡。

其核心思想是：

• 小块用于精确匹配关键词。
• 大块用于提供完整语境和扩展信息。
• 通过"粗筛 + 细选"两步法提升整体检索质量。

13.2 为什么需要 Hierarchical Indices

问题	描述
小 Chunk 检索准确但信息不足	虽然匹配准确，但可能缺少完整的上下文支持。
大 Chunk 上下文丰富但匹配不准	包含更多信息，但也更容易引入不相关内容。
单一粒度检索难以兼顾	难以同时满足准确性与完整性。

13.3 工作流程

1. 构建层次结构

将原始文档依次切分为：

• Leaf Chunk（叶子块）：最小单位，如句子或短段落。
• Parent Summary Chunk（父级块）：由多个叶子块合并并总结而成。
• Root Chunk（根级块）：更高层的汇总内容（可选）。

示例：

Leaf Chunk 1: 故宫是明清两代皇帝居住的地方。
Leaf Chunk 2: 故宫建筑群保存完好，是中国古代宫殿建筑的代表。
→ Parent Summary Chunk: 故宫是明清皇家宫殿，建筑保存完整。

2. 第一阶段检索（粗筛）

使用用户查询对 Parent Summary Chunk 进行初步检索，找出最相关的几个大块。

Query: "故宫有什么特点？" Matched Parent Chunk: "故宫是明清皇家宫殿，建筑保存完整。"

3. 第二阶段检索（细选）

在匹配到的 Parent Chunk 内部，对其包含的 Leaf Chunks 再次进行检索，找到最相关的小块。

Child Leaf Chunks:

• 故宫是明清两代皇帝居住的地方。
• 故宫建筑群保存完好，是中国古代宫殿建筑的代表。

Best Match: "故宫建筑群保存完好，是中国古代宫殿建筑的代表。"

4. 返回结果用于生成

最终使用筛选出的最相关小块作为输入，结合其所属的父级上下文，生成连贯且准确的回答。

13.4 效果评估

Hierarchical Indices 的评分为 0.84 / 1.0。这种方法有效地平衡了检索的精度和广度，是提升 RAG 系统性能的常用策略。

14. HyDE 假设文档嵌入

在构建 RAG 系统时，我们常常遇到一个挑战：用户的问题表达方式与知识库中的内容存在语义差异，导致检索结果不理想。为了解决这个问题，我们引入一种创新性的检索优化方法：HyDE（Hypothetical Document Embedding，假设文档嵌入）。

14.1 核心概念

HyDE 是一种通过先由语言模型生成一个假设性答案（Hypothetical Answer），再将这个答案进行向量化，并用它代替原始查询进行知识库检索的方法。

其核心思想是：

• 原始查询可能模糊或表达不清。
• 模型生成的答案更接近知识库中的表达形式。
• 使用"假想答案"的向量去匹配知识库中真正的相关内容。

14.2 为什么需要 HyDE

问题	描述
查询与文档语义不一致	用户提问方式与知识库表达方式不同。
向量检索依赖表达相似度	相似度排序对关键词和句式敏感。
多跳推理困难	单一查询难以覆盖复杂语义路径。

14.3 核心流程

1. 用户输入原始查询

Q: "故宫有什么特点？"

2. 模型生成一个假设性答案

A (假设): "故宫是明清两代皇帝居住的地方，建筑宏伟壮观，是中国保存最完整的古代宫殿建筑群之一。"

3. 对该假设答案进行向量化

使用嵌入模型（如 all-MiniLM-L6-v2）将其转换为向量表示。

4. 用该向量在向量数据库中进行检索

从知识库中找到与"假设答案"最相似的 Chunk，而不是直接匹配原始问题。

5. 返回检索结果并用于最终生成

结合检索到的真实内容，生成最终答案：

"故宫是明清两代皇帝居住的地方，非常宏伟壮观。它不仅是世界上保存最完整的古代宫殿建筑群之一，也是中国古代宫廷文化的代表。"

14.4 局限性

• 若模型生成的假设方向错误，会导致检索结果偏离真实答案。
• 生成过程引入延迟，影响实时性。
• 不适用于逻辑推理类任务（如数学计算）。

14.5 效果评估

HyDE 的评分为 0.5 / 1.0。虽然它能解决语义鸿沟问题，但其效果高度依赖于 LLM 生成假设答案的质量，且增加了系统的延迟。

15. Fusion 融合检索

在构建高质量的 RAG 系统时，我们常常面临一个现实问题：单一的检索方式（如向量检索或关键词检索）都有其局限性。向量检索能理解语义但可能漏掉关键词精准匹配，而关键词检索命中准确但容易忽略表达差异。为了解决这个问题，我们引入一种综合型检索策略：Fusion（融合检索）。

15.1 核心概念

Fusion 是一种将多种检索方法（如向量检索、关键词检索、布尔检索等）的结果进行加权融合的技术。它利用不同方法的互补优势，提升整体召回率和相关性。

其核心思想是：

• 没有一种检索方式是"万能"的。
• 多种方法联合使用可以显著减少"漏检"。
• 融合打分机制可更精确地排序结果。

15.2 为什么需要 Fusion

检索方式	优势	劣势
向量检索	理解语义相似度，能匹配"意思相近但表达不同"的内容。	对精确关键词（如人名、型号）不敏感。
关键词检索	精确匹配特定词汇（BM25、TF-IDF）。	无法理解同义词或语义变化。
单一方法	实现简单。	容易出现漏检，难以应对复杂查询。

15.3 核心流程

1. 多路并行检索

分别执行以下两种检索方式：

• 方法 A：向量检索（Vector Retrieval）

  • 使用 FAISS / Milvus / Pinecone 进行语义匹配。
  • 示例：用户问"故宫有什么特点？" → 匹配到"明清皇帝居住的地方"。

• 方法 B：关键词检索（Lexical Retrieval）

  • 使用 Elasticsearch / BM25 / Whoosh 进行关键词匹配。
  • 示例：用户问"故宫有什么特点？" → 匹配到"故宫建筑宏伟壮观"。

2. 结果合并与打分融合

将两组结果合并，并对每个 Chunk 计算融合得分：

$$Score = \alpha \cdot Similarity*{Vector} + \beta \cdot Score*{BM25}$$

其中：

• $\alpha$ 和 $\beta$ 是权重系数（如 0.7 和 0.3）。
• $Similarity_{Vector}$ 是向量相似度。
• $Score_{BM25}$ 是关键词匹配得分。

3. 重排序 Top-K 结果

根据融合得分重新排序，选出最终 Top-N 个最相关 Chunk：

Chunk ID	Vector Score	BM25 Score	Fusion Score	结果
Chunk 1	0.85	0.40	0.70	✅ 保留
Chunk 2	0.60	0.90	0.69	✅ 保留
Chunk 3	0.50	0.30	0.38	❌ 丢弃

4. 返回结果用于生成答案

将最终筛选出的 Chunks 输入给语言模型，生成高质量回答。

15.4 效果评估

Fusion 的评分为 0.83 / 1.0。它通过结合不同检索技术的优势，显著提升了系统的鲁棒性和召回率，是目前工业界最常用的 RAG 优化策略之一。

16. CRAG 纠错型 RAG

在构建高质量的 RAG 系统时，我们常常面临一个核心挑战：随着时间的推移，检索结果可能包含不准确、模糊甚至错误的信息，导致最终生成的回答质量下降。为了解决这个问题，我们引入一种具备"纠错能力"的 RAG 架构：CRAG（Corrective Retrieval-Augmented Generation）。

16.1 核心概念

CRAG 是一种通过对检索结果进行评估和筛选，动态识别并纠正不可靠信息的 RAG 架构。它不仅依赖检索内容生成答案，还能主动判断哪些知识是可信的，并据此调整生成过程。

其核心思想是：

• 不是所有检索结果都值得信任。
• 应该让模型具备"评估—筛选—修正"的能力。
• 在生成前主动纠错，提升回答准确性。

16.2 为什么需要 CRAG

问题	描述
检索结果含错误	知识库可能包含过时、矛盾或虚假信息。
LLM 缺乏事实判别力	即使提示"仅基于检索内容回答"，LLM 仍可能无法识别隐含错误。
高相关 ≠ 高正确	一个文档可能语义匹配但关键事实错误，误导生成结果。

16.3 核心流程

1. 初始检索（Retrieval）

使用任意检索器（如 BM25、向量检索或 Fusion）从知识库中获取 Top-K 文档。此阶段不强调精度，优先保证高召回。

示例：用户问 "Who is the current CEO of Twitter?" 检索器返回包含 "Elon Musk is CEO" 和 "Parag Agrawal was CEO in 2022" 的多个片段。

2. 分解与校正（Decompose & Correct）

对每个检索到的文档：

1. 分解：将其切分为独立的事实单元（如句子）。
2. 校正：对每个单元，调用轻量级网络搜索（如 Bing API）或知识图谱进行验证。

• 若单元与外部权威源一致 → 保留。
• 若不一致 → 尝试用权威源内容替换或修正该单元。
• 若无法验证 → 标记为低可信度。

示例：

• 原句："Parag Agrawal is the CEO of Twitter."
• 校正后："As of 2025, Elon Musk is the CEO of Twitter (formerly X Corp.). Parag Agrawal served until late 2022."

3. 可信度重排序（Re-ranking）

为每个校正后的事实单元计算可信度分数，例如：

• 来自权威源（维基百科、官网）→ 高分。
• 与多个独立来源一致 → 高分。
• 无法验证或存在冲突 → 低分。

然后按可信度重新排序，仅保留 Top-N 高可信单元用于生成。

4. 生成最终答案（Generation）

将校正后、高可信的事实单元作为上下文输入 LLM，生成最终回答。

16.4 效果评估

CRAG 的评分为 0.82 / 1.0。它的优势在于避免复述错误信息，自动融合最新事实，即使原始知识库过时，也能通过在线校正实现"自我更新"。

17. Multi-Modal RAG 多模态检索增强生成

17.1 核心概念

Multi-Modal RAG 是一种能够同时处理文本和图像的检索增强生成系统。它通过提取、理解并关联文档中的多模态元素（文字+图片），实现更完整、更直观的知识服务。

其核心思想是：

• 图文一体：PDF 中的图像不是装饰，而是关键知识载体。
• 跨模态理解：建立文本描述与图像内容的语义关联。
• 视觉增强生成：在答案中智能融合文字说明与图像引用。

17.2 为什么需要 Multi-Modal RAG

挑战	描述
信息丢失	传统 RAG 往往忽略文档中的图表、流程图，导致关键信息缺失。
交互单一	纯文本交互无法直观展示复杂结构或视觉信息。
理解受限	某些概念（如机械结构、数据趋势）仅靠文字难以准确描述。

17.3 工作流程

1. 提取文本和图像

从 PDF 中并行提取文本内容和所有图像。

2. 生成图像标题

使用具备视觉能力的多模态大模型（如 GPT-4V, Qwen-VL）为每张图像生成准确的文本描述（标题）。

3. 创建嵌入

为提取出的文本块和图像标题分别创建向量嵌入。

4. 嵌入模型

选择合适的嵌入模型（如 text-embedding-3-large）进行向量化。

5. LLM 模型生成

为了生成响应和图像标题，我们将使用 Qwen3/DeepSeek 等支持多模态输入的模型，最终输出包含图文的丰富答案。

17.4 效果评估

Multi-Modal RAG 极大地扩展了 RAG 的应用边界，特别是在处理技术手册、财务报表等富含图表的文档时表现出色。虽然实现复杂度较高，但其带来的用户体验提升是巨大的。

18. RAG 技术对比与评分总览表

为了帮助大家更直观地选择适合自己业务场景的 RAG 策略，我们将上述 17 种技术进行了汇总对比。

编号	技术名称	核心假设 / 改进思路	得分	实现难度	推荐理由
1	Simple RAG (简单切块)	将文档直接按固定长度切分为多个 Chunk。	0.3	⭐	实现简单，适用于初步尝试或小规模项目。
2	Semantic Chunking (语义切块)	按照语义单元进行分块，避免断章取义。	0.2	⭐⭐	提升语义完整性，适合需要理解上下文的任务。
3	Context Enriched Retrieval (上下文增强检索)	在检索时考虑更多上下文信息，提升相关性。	0.6	⭐⭐⭐	提高检索结果的相关性和准确性。
4	Contextual Chunk Headers (上下文标题)	为每个 Chunk 添加描述性标题，提供额外线索。	0.5	⭐⭐	增强 Chunk 的可理解性，便于模型判断。
5	Document Augmentation (文档增强)	自动补充文档中的关键信息，丰富表达。	0.8	⭐⭐⭐	扩展知识入口，提高命中率。
6	Query Transformation (查询转换)	对原始查询进行改写，增强语义表达。	0.5	⭐⭐	提升检索多样性，成本低见效快。
7	Reranker (重排序)	使用更精细模型对初检结果重新打分排序。	0.7	⭐⭐⭐	提升最相关 Chunk 的排名，是高质量 RAG 的标配模块。
8	RSE (语义扩展重排序)	通过上下文窗口扩展检索范围，处理跨 Chunk 问题。	0.8	⭐⭐⭐⭐	更好处理复杂问题，提升整体匹配效果。
9	Feedback Loop (反馈闭环)	用户反馈能持续优化系统性能。	0.7	⭐⭐⭐⭐⭐	系统具备自我进化能力，适合长期运营。
10	Adaptive RAG (自适应检索)	不同查询类型应采用不同策略和知识源。	0.86	⭐⭐⭐⭐	最灵活、最智能的 RAG 架构，适用于复杂业务场景。
11	Self RAG (自反思检索)	模型自主筛选高相关性内容，减少噪音。	0.6	⭐⭐⭐⭐	提升生成准确性，具备"判断力"。
12	Knowledge Graph (知识图谱)	利用图结构表达信息间的语义关系。	0.78	⭐⭐⭐⭐⭐	强大的语义结构化工具，适合深度推理任务。
13	Hierarchical Indices (层次化索引)	结合小块精准与大块上下文优势。	0.84	⭐⭐⭐⭐	在精度与上下文之间取得最佳平衡。
14	HyDE (假设文档嵌入)	先生成假设答案再检索，弥补表达差异。	0.5	⭐⭐⭐	适合模糊表达类问题，提升召回率。
15	Fusion (融合检索)	结合向量 + 关键词检索，减少漏检。	0.83	⭐⭐⭐	结合语义与关键词双重优势，提升检索效果。
16	CRAG (纠错型 RAG)	评估并修正检索结果中的错误信息。	0.82	⭐⭐⭐⭐	显著提升生成准确性与系统可信度。
17	Multi-Modal RAG (多模态检索)	将 PDF 中的图像生成文本描述和标题。	0.79	⭐⭐⭐⭐⭐	显著提升 PDF 内容的读取能力。