RAG入门指南：收藏版，小白程序员快速掌握大模型检索增强技术

高级绘画师PP

494人浏览 · 2026-03-30 11:40:39

高级绘画师PP · 2026-03-30 11:40:39 发布

一、RAG

1.1 简介

RAG (Retrieval-Augmented Generation)，全称为“检索增强生成”，近年来已成为大语言模型（LLM）在实际部署中占据主导地位的技术架构。该方案有效克服了模型知识滞后、生成内容不准确（即“幻觉”现象）以及难以接入私域数据等核心痛点。

尽管大模型具备强大的推理能力，其知识储备仍受限于训练数据的截止时间。当被问及最新事件或涉及企业内部资料时，模型往往因缺乏依据而生成虚构内容。RAG的运作机制恰好弥补了这一短板：它在模型输出回答之前，会先从外部知识库中“检索”相关资料，将这些信息作为参考上下文提供给模型，从而引导模型生成基于事实的可靠回复。

参考文档：https://datawhalechina.github.io/all-in-rag/#/

1.2 核心思想

RAG 的核心思想可以理解为：“开卷考试”。

传统生成： 闭卷作答，完全依赖内在记忆，一旦记错或知识盲区便容易胡编乱造。
RAG模式： 开卷考试，面对问题先在知识库中检索相关内容，再依据查到的信息组织语言、生成答案。

1.3 实现原理

实现 RAG 通常分为两个阶段：数据准备（离线） 和 检索生成（在线）。

A. 数据准备阶段（建立知识库）

文本分割 (Chunking)： 将长文档拆解为较小的文本单元（例如每段设定为 500 字左右）。
向量化 (Embedding)： 借助向量模型将文本单元转化为对应的向量表示。
存入向量数据库： 将这些向量数据存入向量数据库中，以便后续执行高效的相似性检索。

B. 检索生成阶段（查询与作答）

问题向量化： 采用与数据准备阶段相同的向量化模型，将用户问题转化为向量。
相似检索 (Retrieve)： 在向量数据库中搜索与问题向量最相似的文本片段（通常基于欧氏距离或余弦距离进行度量）。
上下文增强 (Augment)： 将检索到的相关内容与原始问题组合，构建成一个包含参考信息的提示词（Prompt）。
结果生成 (Generate)： 将该提示词输入大语言模型，模型依据所提供的参考资料生成最终的答案。

1.4 优势

准确性高： 回答内容均有据可依，能够显著减少模型生成幻觉的可能性。
实时性强： 仅需更新外部数据库即可让模型获取最新知识，无需进行重复训练。
成本低： 相比于微调（Fine-tuning）方案，RAG 在实际部署与后期维护上的投入要低得多。
隐私保护： 敏感信息可存放于本地数据库中，仅在必要时才提供给模型调用。

1.5 挑战

虽然原理简单，但在实际应用中仍面临难题：

检索遗漏**：尽管数据存在于库中，但未能通过合理的搜索有效获取。**
检索偏差**：搜索出的结果中混杂大量不相关内容，干扰判断。**
整合不足： 即便获取了资料，模型也可能理解不到位，或遗漏掉其中的关键信息。

二、高级RAG

在当前的RAG应用中，所暴露出的种种不足，正逐渐成为众多企业与开发团队在实际落地过程中绕不开的挑战。为应对这些瓶颈，行业内逐步探索并形成了多个维度的优化策略。整体来看，这些优化工作主要围绕三个阶段展开，分别是：预检索阶段、检索阶段、后检索阶段。

1. 预检索优化（Pre-Retrieval）

预检索优化主要聚焦于正式检索开始前的数据处理与准备环节，该阶段涉及的方法主要有：

1.1 摘要索引(Summary Index)

简介：

摘要索引 (Summary Index) 作为 RAG 架构中的一种重要索引策略，其核心目标在于提升检索过程的高效性与准确性。与传统方式不同，它并非直接在原始文本块上进行搜索，而是通过对文档内容预先处理，提炼出“摘要”作为检索的主要锚点。

在常规 RAG 中，当文档篇幅冗长、内容繁杂时，直接对原始切片（Chunks）进行检索，极易引发信息碎片化或检索深度不足的问题。

摘要索引的应对机制是：首先为每一份文档（或文档中的大段落）生成一份内容精炼的摘要，并为这些摘要建立专门的索引。当检索请求发起时，系统优先匹配最相关的摘要，锁定目标文档后，再进入该文档内部获取所需的详细信息。

核心思想：

摘要索引的核心理念可概括为 “由简入繁，层级定位”：

语义提炼： 原始文档往往夹杂冗余信息，摘要有助于剥离噪音、保留精髓，从而提升向量检索时的语义纯度。
全局映射： 摘要作为一个“锚点”，指向其背后整段或整篇文档的核心主旨，有效避免因切碎文本而导致的“顾点失面”问题。
多层级检索： 借助 “摘要 -> 原始文本” 的映射关系，构建起从宏观意图捕捉到微观细节定位的精准路径。

实现原理：

实现摘要索引一般包含以下四个关键环节：

A. 文档切分与摘要生成 (Summarization)

将长文档按语义完整性划分成较大的单元（例如章节或页面群组）。
借助大语言模型为每个语义单元提炼出一段简明扼要的摘要。
核心点： 摘要内容通常涵盖原文中的核心关键词、关键实体及主要观点。

B. 索引构建与关联 (Indexing)

摘要向量化： 仅对生成的“摘要文本”进行 Embedding（向量化）处理，并存入向量数据库。
建立映射关系： 在数据库中构建父子层级关联，即：摘要 ID -> 原始文本块 IDs。

C. 执行检索 (Retrieval)

首轮检索（摘要匹配）： 根据用户的提问，系统会先在摘要库中检索出最相关的摘要信息。
次轮检索（原文提取）： 一旦命中相关摘要后，系统随即调取与该摘要关联的全部原始文本片段（或经过细分的切片）。

D. 结果生成 (Generation)

将提示词、用户问题、检索出来的经过筛选且与问题高度契合的原始文本进行合并，发送给LLM，LLM使用这些内容最终生成准确答案。****

优势：

摘要索引是实现分层式 RAG 的核心基石。其作用犹如一本书的“详细目录”，引导 AI应用先通过目录锁定目标位置，再深入具体页面查阅细节，从而在应对长篇文本时显著提升检索命中率，并确保信息获取具有极高的纯净度。

1.2 父子索引(Parent-Document Retrieval / Parent-Child Indexing)

在这里插入图片描述
简介：

父子索引 (Parent-Document Retrieval / Parent-Child Indexing) 也称父文档检索或父子层级索引，是RAG应用领域中一种经典且高效的优化手段。它采用“切分粒度分离”的切分策略，巧妙地化解了检索精度与生成质量之间的固有矛盾。

在传统RAG在实践中常常面临一个“两难困境”：

若切片（Chunk）太小：虽然检索准确性较高，但上下文信息容易丢失，导致大模型在生成回答时出现逻辑断层。
若切片设置太大：文本块中夹杂的无关信息增多，向量检索的匹配精准度便会随之下降。

父子索引的核心思路在于将检索与生成两个环节解耦处理：即利用小切片（子块）执行精确检索，再依托大切片（父块）提供完整上下文用于生成回答**。**

核心思想：

其核心思想是 “分而搜之，合而答之”：

检索环节：采用较小的文本单元，以提升匹配的精准度和敏感度。
生成环节： 调用较大的文本单元，以确保上下文信息的完整性和连贯性。

该机制通过在数据库中预先构建 “父子层级关联”，使得系统一旦命中相关性最高的“子块”，便能自动溯源并提取其所归属的“父块”，最终将完整的父块内容提供给模型用于答案生成。

实现原理：

父子索引的实现流程通常可划分为以下四个关键步骤：

A. 分层切分 (Recursive Splitting)

设定父块：将文档按语义完整性或段落划分为较大的单元（例如1000至2000词元），确保段落信息相对完整。
生成子块：在每个父块内部，进一步细分为更小的片段（例如100至200词元）。
建立关联：为每个子块赋予一个父块标识parent_id，用以记录其归属于哪个父块。

B. 索引构建** (Indexing)**

仅向量化子块： 系统仅对“子块”进行向量化处理，并将其存入向量数据库用于检索。
存储父块： 父块的原始文本则存放于内存或简单的文档数据库（Docstore）中，无需参与向量计算，以降低资源消耗。

C. 检索与回溯 (Retrieval & Expansion)

子块检索查询： 用户发起查询时，系统首先在向量库中检索出最相关的若干子块。
父块回溯： 依据命中的子块所携带的父块的标识符 parent_id，从文档库中调取对应的完整父块内容。
结果合并： 若多个子块同属一个父块，则自动去重，仅保留一份父块文本。

D. 答案生成 (Generation)

大语言模型结合上述筛选出的、上下文完整的高相关度文本片段，最终生成准确的回答。

优势：

父子索引是当前工业级应用中最成熟的 RAG 增强手段之一。它不依赖复杂的模型推理机制，仅凭数据结构的巧妙设计，便能显著提升系统的回答质量与专业度，同时在很大程度上规避了上下文断裂的风险，并有效优化了信息的纯度与可读性。

1.3 假设性问题索引(Hypothetical Questions Indexing)

简介：

假设问题索引 (Hypothetical Questions Indexing)，是RAG架构中一种通过预先模拟用户提问来提升检索效果的策略。

在常规的RAG机制中，系统通常直接使用用户的提问去匹配对应的答案片段。然而，问题与答案在语义表达上往往并不对等——用户提问通常简短且可能不够明确，而答案内容则相对完整详尽。

假设问题索引则采取了不同的思路：它提前为每个知识段落构思出可能与之相关的“假设性问题”，并为这些问题建立专门的索引。在实际检索时，系统实际上是在用用户的提问去匹配这些预先构建的“假设性问题”。

核心思想：

其核心理念可概括为 “降低检索门槛”：

语义同维映射： 将原本“问题”与“答案”之间的跨维度匹配，转化为“用户问题”与“模拟问题”之间的同维度比对，使匹配过程更加直接。
意图预判机制：** 借助大语言模型模拟多样化的用户提问方式（包括口语化表述、行业术语、反问句式等），提前覆盖各种可能的检索路径，从而提升命中率。**

实现原理：

实现假设问题索引通常可分解为以下三个主要步骤：

A. 假设问题生成** (Generation)**

文本切片： 首先将原始文档划分为若干基础片段（Chunk）。
假设问题生成： 借助大语言模型分析每个Chunk的内容，并生成若干与之相关的假设性问题，例如询问模型：“针对这段文字，用户可能会以哪些方式提问？请列出3至5个示例。”

示例：若原文为“本公司差旅补助标准为每天 200 元”，则可能生成的假设问题包括：“出差补贴是多少？”、“每日补助标准是多少？”、“差旅费用如何报销？”等。

B. 向量索引构建 (Indexing)

假设问题向量化： 对生成的“假设性问题”进行向量化处理，存入向量数据库。
映射关联： 在数据库中建立“假设性问题”与“原始文本片段”之间的映射关系。

C. 检索与结果生成 (Retrieval)

相似度匹配： 用户提出真实问题后，系统将其向量化并与“假设问题库”进行相似度比对。
原文回溯：当匹配到合适的假设问题时，系统自动提取其所指向的原始文本片段。
生成回答：大语言模型依据获取的原始文本内容，生成最终的回答。

优势：

召回能力显著增强：特别适用于应对口语化、表达简练的用户提问场景。
语义匹配更为精准：问题与问题之间的语义相似度，通常高于问题与答案之间的直接匹配。
表达适配范围更广：能够有效兼容多样化的提问方式与表述习惯。

1.4 元数据索引(Metadata Indexing)

简介：

元数据索引 (Metadata Indexing) 是 RAG 系统中一项用于提升检索准确度与可控性的关键技术。其核心思路是为每个文本片段（Chunks）附加结构化的“标签信息”，使传统的语义检索进化为“语义匹配 + 条件筛选”的双重机制。

在常规 RAG 模式下，检索过程仅依赖于向量间的语义相似度。然而，当用户需要满足特定条件的结果时（例如查询“2026 年3月研发部项目支持报告”或“财务相关文件”），单纯依靠语义检索可能会混入其他年份或部门的无关内容。

元数据索引的解决方式是在每个文本片段的向量表示之外，额外关联结构化的描述信息（例如文档产生时间、责任作者、所属类别或关键词等）。借助这些标签，系统在执行向量匹配的同时，也能像操作电子表格筛选功能一样，精准锁定符合条件的目标范围。

核心思想：

其核心理念可归纳为 “先限定范围，再查找内容”（或两者同步执行）：

多维筛选： 在保证 “语义相关” 的基础上，进一步要求各项 “属性条件” 必须匹配。
精准去混淆： 即便两个文本片段意思接近，借助时间、来源等元数据信息，也能有效区分彼此，避免误召回。
逻辑强****约束：为语义层面的“模糊匹配”补充了一层确定性的规则过滤，提升了检索结果的可靠性。

实现原理：

元数据索引的实现流程一般包含以下三个主要环节：

A. 元数据提取 (Extraction)

在构建索引的过程中，为每个文本片段采集关键属性信息：

人工定义： 记录基础信息，例如文档存储路径、创建时间戳、文件名称等。
智能抽取： 借助大语言模型对文本内容进行解析，自动识别并提取关键词、产品型号、关联部门等信息，将其作为元数据标签一同存储。

B. 元数据存储 (Storage)

在向量数据库中（例如 Pinecone、Milvus、Weaviate 等平台），每个向量条目均可关联一个 JSON 格式的元数据对象。存储结构示例如下：

{
"vector": [0.17, 0.35, ...],
"text": "本问编写于2026年3月，是一份关于Oracle数据库的...",
"metadata": {
"year": 2026,
"type": "legal_contract",
"department": "Dev"
}
}

C. 执行混合检索 (Filtered Search)

当用户发起查询时，系统会生成一个带有过滤条件的查询请求：

用户问题： “今年3月的研发支持了哪些现场？”
意图解析： 系统从中识别出时间限定条件，例如 year: 2026，mon: 03。
检索执行： 向量数据库仅在满足 year == 2026 && mon == 03的范围内进行向量相似度匹配。

优势：

检索精准度显著提升： 有效消除因时间、地区、版本等因素引发的匹配偏。
权限管理更精细： 借助元数据标记文档的访问等级，确保用户仅能触及权限范围内的内容。
查询响应更高效： 在限定范围内进行检索，相比遍历全量数据，大幅提升了搜索速度。

1.5 各种索引优化适用场景总结

索引优化	适用场景	案例
摘要索引	适合用于需要快速获取信息并生成精炼回答的场合	例如在新闻资讯平台中，系统需从海量报道里迅速提炼要点，借助摘要索引可高效生成简短概述，帮助用户第一时间把握新闻主旨。
父子索引	适合用于对语义连贯性和分层检索有较高要求的场景	以法律检索系统为例，当用户查询相关法条时，父子索引通过分级匹配精准定位所需内容，并召回对应的大段原文，确保上下文不被打断，避免因切分过细而造成信息缺失
假设性问题索引	适合用于应对表达方式多样、查询较为复杂的情形	如在药品咨询系统中，用户可能以“感冒了该用点什么药？”等方式提问。假设性问题索引通过为每款药品预构多种可能的提问形式，帮助用户更精准地找到所需信息
元数据索引	适合用于需要分类筛选和快速定位的应用场景	在电商推荐系统中，平台可借助元数据索引快速筛选出契合用户偏好的商品，从而提升推荐效果与响应速度

2. 检索优化（Retrieval）

检索优化主要聚焦于提升查找过程本身的质量与效率，常用的策略包括：

2.1 Enrich完善问题

简介：

Enrich（完善问题 / 增强查询） 是指在RAG处理流程中，在执行检索操作之前，对用户原始输入进行“扩展”或“优化”的一项技术。它的主要目的是解决因用户提问过于简单、表达含糊不清或缺少必要语境而导致的匹配失败问题。

用户在日常提问时往往习惯使用简洁的表达方式（例如询问“如何开申诉？”），而知识库中存储的文档通常内容完整、用词专业（例如“员工在绩效确认过程的事项详解”）。

Enrich 技术的的核心思路是在检索之前增加一个“预处理环节”，借助大语言模型所掌握的语言理解能力，将原本信息量不足的简单问题，转化为包含具体语境、关键术语及相关概念的“富查询（Rich Query）”。

核心思想：

Enrich 的核心目标在于“消除信息差”：

补全潜在信息： 当用户的提问内容过于简略、信息量不足时，系统可通过交互式追问等方式，引导用户进一步补充和完善问题细节。

实现原理：

实现问题完善（Enrich）通常包括以下几个环节：

A. 大模型评估问题完整性

前置大语言模型首先对原始提问的信息充分性进行评估：

原始提问： “蔚来多少钱？”
模型对问题完整性分析：识别出问题缺少关键限定信息，例如具体地区或车型。
触发补充询问： 模型向用户发起追问，以获取更完整的上下文，例如：“您想了解哪个地区、哪一款蔚来汽车车型的价格？”

B. 基于多伦交互来完善问题

前置模型根据与用户的若干轮问答，逐步补全原始提问中缺失的信息：

完善后的问题： “上海地区蔚来ES8车型的起售价是多少钱？”

C. 完善问题后执行检索并生成最终答案

当前置模型判断问题已具备足够信息后，系统基于完善后的查询问题从向量数据库中检索相关内容，并生成最终回答返回给用户。

优势：

大幅增强对模糊查询的解析能力，确保检索结果与用户意图高度匹配。
有效应对多条件、逻辑性较强的复杂提问，提升系统在专业场景下的适用性。

2.2 多路召回(Multi-Query Retrieval)

简介：

多路召回 (Multi-Query Retrieval) 的核心在于查询扩展（Query Expansion）。它基于这样一个理念：用户最初提交的原始问题往往信息有限，难以覆盖全面。因此，系统借助大语言模型将单一问题“衍生”为多个不同角度的子问题，以此在向量数据库中检索出更加丰富多样的候选文档。

核心思想：

多路召回的核心思路在于“多角度互补”：

多维语意覆盖： 当用户提问可能较为模糊，大语言模型生成的多个相关问题可以从不同角度、采用不同的表达方式来全面捕捉知识点。
提升召回率： 通过增加查询的多样性和数量，有效降低因单次向量计算偏差而错失正确答案的可能性。

实现原理：

实现多路召回通常包括以下几个环节：

A. 问题改写与扩展 (Query Rewriting)

大语言模型首先对用户原始提问进行多角度扩展，生成若干个语义相近但表达方式不同的问题：

原始问题： “如何防止触电？”
改写问题 1： “触电的预防措施有哪些？”
改写问题 2： “电线裸露在外时如何处理？”
改写问题 3： “掌握哪些安全要点可以防止因用电不当导致的伤害？”

B. 并行检索 (Concurrent Retrieval)

将原始问题与改写生成的多个问题（共计 N+1 个查询）同时提交给向量检索系统执行搜索。

C. 结果召回与整合 (Retrieval & Collection)

多路召回： 每一路查询分别返回若干相关文档片段（如 Top-K）。
去重融合： 将所有路径召回的文档汇集到一起，并剔除重复内容。

D. 答案生成** (Read & Respond)**

将整合后的文档集合作为参考上下文，输入大语言模型，生成最终准确回答。

优势：

有效缓解信息遗漏问题：显著改善了因单一路径检索而导致的内容覆盖不全。
提升模糊表达适配能力：对于提问不够明确的用户，仍能提供较为准确的检索结果。

2.3 问题分解 (Query Decomposition)

简介：

问题分解 (Query Decomposition)是指将一个内容较为复杂或结构多层的提问（即主任务），拆分为若干个相对简单、易于处理的子问题（即子任务）。这一思路与人类处理复杂问题时的惯用方式类似：先分步解决各个小环节，再整合得出最终结论。

在 RAG 应用中，该方法能够有效规避因问题过于宽泛和笼统而导致的检索偏差，从而提升对复杂查询的整体应答质量。

核心思想：

其核心理念可概括为“分步拆解”与“层层递进”：

化繁为简： 复杂的提问通常对应知识库中多个分散的信息点。通过将问题拆解，使每一次检索的目标更加清晰具体。
逻辑窜联： 部分提问需要先了解前提问题（A），才能回答后续问题（B）。分解有助于理清这种先后依赖关系。
**整合输出：**将多个局部信息汇总融合，最终形成一个完整且具有深度的综合性答案。

实现原理：

A. 串行执行 (Sequential/Chain of Thought)

该模式下，各子任务之间存在逻辑先后关系：

分解阶段： 大语言模型将原始问题拆分为若干个存在依赖关系的子问题（如：子问题1、子问题2……子问题N）。
逐步执行：先处理“子问题1”，获得对应的答案内容“答案1”。
信息传递：将“答案1”作为提示词（Prompt），并与“子问题2”一起输入模型。
递进处理：模型在回答后续子问题时，能够借助之前已获取的信息进行推理。

适用场景： 适用于需要多步推理的任务。例如提问“梁文锋创立的公司现在市值多少？”——需先确定该公司为宇树科技，再进一步查询其市值。

B. 并行执行 (Parallel/Multi-Query)

该模式下，各子任务之间相对独立，无先后依赖：

分解阶段： 大语言模型将原始问题拆分为多维度的多个彼此不干扰的子问题。
并发处理：将所有子问题同时提交给检索系统，并为每个子问题分别获取对应的“局部结果”。
结果整合 (Aggregation)：最后再由大语言模型将所有局部结果汇总，生成最终的综合性回答。

适用场景：适用于对比分析或综合类问题。例如提问“对比苹果手机和华为手机的优缺点”——可拆分为“苹果手机的优缺点”和“华为手机的优缺点”两个独立子任务并行处理。

优势：

问题分解 (Decomposition)使得 RAG 从原本简单的“提问—回答”模式，升级为具备“任务处理”能力的系统。它借助大语言模型的规划机制，将一个难以直接跨越的复杂问题，拆解为多个易于执行的小步骤，从而逐步完成整体解答。

2.4 混合检索(Hybrid Search)

简介：

混合检索 (Hybrid Search) 指的是在同一RAG系统中，并行采用多种不同类型的检索算法进行信息获取（常见的组合方式为：传统关键词匹配 + 向量语义相似度计算）。该方法通过多条检索路径协同工作，从多个维度全方位捕捉文档内容与用户查询意图之间的匹配关系。

核心思想：

其核心理念可概括为 **“字面匹配搜索”与“语义相似度理解”**的双剑合璧：

关键字检索 (如 BM25)： 侧重精准定位，擅长捕捉专有名词、型号代码、缩写等特定词汇。例如搜索“iPhone 17”，能够有效筛除与“iPhone 16”相关的内容。
向量检索 (Vector Search)： 侧重语义理解，能够感知用户提问背后的意图，即使查询中未出现原文的精确用词，也能召回语义相近的信息。
结果融合 (Fusion)： 将多路检索返回的候选结果汇总整合，并借助重排序算法筛选出综合质量最优的文本片段。

实现原理：

混合检索的实现通常遵循以下标准工作流：

A. 并行检索 (Parallel Retrieval)

系统接收到问题查询请求后，将其同时发送至两个（或多个）独立的检索模块：

关键字检索模块 (BM25)： 基于词频和逆文档频率算法，筛选出包含相关关键字的文档内容。
向量检索模块 (Embedding)： 将查询问题转换为向量表示，在向量数据库中检索距离最近的文本片段。

B. 结果整合与生成

将多路检索返回的文档汇集融合后，输入大语言模型生成最终答案。

优势：

**高鲁棒性：**能够有效应对多种提问形式，无论是表述简略还是语义模糊，均能保持稳定表现。
**幻觉抑制：**通过精准的关键词匹配，将模型限定在正确的信息源范围内，减少内容张冠李戴的风险。
**冷启动支持：**对于新出现的专有名词或术语（向量模型可能尚未学习），关键词检索可快速填补这一空白。
**召回更全面：**兼顾“语义相关”与“字面匹配”两方面，整体召回效果显著优于单一检索路径。

2.5 查询优化对比

查询优化	详情
Enrich完善问题	借助大语言模型对用户原始提问进行补充和润色，生成更便于系统理解的优化后查询内容。
多路召回	围绕同一问题生成多种表达方式，分别执行检索后对结果进行去重与整合。
问题分解	将复杂提问拆分为若干个相对简单的子问题，通过串行或并行方式逐一求解，最终整合得出完整答案。
混合检索	通过多种检索方式的协同作用（如词频匹配与向量相似度计算的结合），扩大相关文档的覆盖范围。

3. 后检索优化（Post-Retrieval）

在完成初步检索之后的阶段，为进一步提升内容质量，而进行的优化称为后检索优化，具体方式如下：

3.1 Rerank重排序-RRF(Reciprocal Rank Fusion)

简介：

RRF (Reciprocal Rank Fusion)，即“倒数排名融合”，是混合检索（Hybrid Search）场景下应用最为广泛且稳定性比较高的重排序（Rerank）算法。其核心作用是将来自不同检索方式（例如关键词匹配与向量语义搜索）的多个独立排序结果，合并为一个综合性的、质量更优的排序列表。

在 RAG 系统中，多路召回（Multi-Route Retrieval）往往会带来多组检索结果。然而，由于不同检索器采用的评分机制各不相同（例如BM25的得分通常为大于 0 的实数，而向量相似度则多落在 0 到 1 之间），这些分数难以直接进行比较和叠加。RRF正是为了应对这一评分不统一的问题而设计的——它摒弃原始分值，仅依据文档在各检索结果列表中的相对排名进行融合计算。

核心思想：

RRF 的核心思想可以概括为“多数排序共识”：

排名决定权重： 文档在任一结果列表中排名越靠前，其对最终分数的贡献就越大。
多路共鸣： 若某文档在多种检索路径（例如向量检索和关键词匹配）中均名列前茅，其综合排名将显著高于仅在单一路径中排名第一的文档。
弱化分值差异： 通过忽略不同模型间的评分尺度差异，仅依据文档的相对位置来评估其相关性。

实现原理：

具体执行步骤：

汇总排名信息： 收集各检索路径返回的 Top-K 文档及其对应的排序位置。
计算融合得分： 遍历所有被召回的文档，依据 RRF 公式对每个文档在各路径中的排名进行倒数得分累加。
重新排序： 根据融合后的总分对所有文档进行降序排列（排序可直接使用ReRerank模型实现）。
截取结果： 选取总分排名前 N 的文档片段，作为后续生成答案的参考上下文。

优势：

极强的鲁棒性： 经大量实践验证，RRF 在多种类型及规模的检索任务中均表现稳健，其效果往往不逊于甚至超越部分复杂的排序学习模型。
无偏融合： 能够有效整合关键词检索的精确匹配能力与向量检索的语义覆盖优势，弥补单一路径检索可能存在的偏差。
广泛兼容： 只需获取各检索器的排名信息，RRF 即可融合任意数量的检索结果（例如将向量检索 + 关键词匹配 + 知识图谱查询相结合）。

3.2 长上下文重排序（LongContextReorder）

简介：

根据《Lost in the Middle: How Language Models Use Long Contexts》这篇论文的研究，大语言模型在处理长上下文输入时，对信息所处的位置表现出明显的敏感度。实验表明，当关键内容出现在输入上下文的起始或末尾位置时，模型往往能够更准确地利用这些信息。为缓解这种“中间信息丢失（lost in the middle）”现象，可以在完成初步检索后对文档顺序进行重新调整，将相关性最高的内容放置在上下文的开头和结尾两端，而将相关性较低的内容排布在中间区域。

核心思想：

其核心思想可以归纳为 “高可信内容上下文首尾放置”：

应对“中间遗忘”： 针对模型在长上下文中段注意力下降的问题，通过人工干预避免重要信息落入这一区域。
位置权重优化： 将检索得分最高（最相关）的文档片段交错安排在上下文的起始与末尾位置，形成一种两端高、中间低的“凹”形分布结构。

实现原理：

假设在重排序 Rerank 阶段已筛选出了 N 个最相关的文档片段（按相关度从 1 到 N 排序），LongContextReorder 的重新排序逻辑通常如下：

确定初始排序： 获得一组按得分降序排列的文档列表（序号 1 代表相关性最高，序号 N 代表相关性最低）。
交叉重排分配：

将第 1 名放在上下文列表的最前面。
将第 2 名放在上下文列表的最后面。
将第 3 名放在第 1 名之后。
将第 4 名放在第 2 名之前。

最终分布形态： 经过上述交叉放置后，相关性最高的文档集中在上下文的首尾两端，而相关性较低的文档则被调整至中间区域。

优势：

召回质量****显著增强： 即便大语言模型拥有较大的上下文窗口，合理的重排策略仍能大幅提升其从检索材料中提取有效信息并生成准确回答的能力。
实现成本低： 该过程仅涉及文档位置的逻辑调整，无需调用大模型参与，也不依赖额外计算资源，几乎不引入延迟。
模型鲁棒性提升： 有效缓解了模型在处理大量上下文时因注意力分散而遗漏关键信息的问题。

3.3 上下文压缩与过滤(Context Compression & Filtering)

简介：

上下文压缩与过滤 (Context Compression & Filtering) 是RAG流程中一项精细化的数据处理技术，主要用于应对因检索内容过多而引入的噪声干扰和无效Token消耗。

在常规的RAG模式下，检索器往往直接返回完整的文本片段（Chunks）。然而，这些片段中常常夹杂着与用户问题关联度较低的内容，例如背景介绍、补充说明或冗余描述。上下文压缩与过滤的作用类似于一个“内容提纯器”——它在完成检索之后、生成答案之前，对召回的信息进行再次筛选和精简，仅保留与问题高度相关、对生成回答真正有价值的关键信息。

核心思想：

其核心理念可概括为 “精准投喂，降噪提纯”：

剔除冗余干扰： 有效过滤检索结果中的无关信息，避免模型因噪声干扰而出现注意力分散。
节约 Token： 仅将精简后的核心内容输入大语言模型，既减少了 Token 开销，也缓解了长文本带来的处理负担。
语义聚焦： 通过提取与问题高度相关的句子或片段，帮助模型快速锁定关键信息，提升回答的精准度。

实现原理：

要实现上下文压缩与过滤策略通常包括以下三个环节：

A. 初步检索 (Initial Retrieval)

首先通过基础检索方式（例如向量检索或混合检索）从知识库中获取一批相关的文档片段（假设返回 5 个长度为 500 字的文本块）。

B. 进行文档压缩 (Document Compressor)

将初步检索到的原始片段送入专门的压缩器组件进行处理。该压缩器可由轻量级模型或特定提示词Prompt逻辑构成，例如采用 LLMChainExtractor 等方式。

C. 过滤与精炼 (Filtering & Refinement)

压缩器会根据具体策略执行以下操作之一：

语句过滤 (LLMChainFilter)： 逐句判断内容与问题的相关性，剔除无关部分。
内容提取 (EmbeddingsFilter)： 基于向量相似度，保留片段中与查询最接近的若干句子。
摘要生成 (Summary-based Compression)： 借助大语言模型对多个检索片段进行实时概括，生成一段高度浓缩的上下文信息。

优势：

回答质量显著提升： 得益于上下文的纯净度大幅提高，大语言模型生成幻觉内容或受到噪声干扰的概率明显下降。
突破上下文窗口限制： 在模型窗口容量有限的情况下，通过压缩可以纳入更多来源的有效信息，提升信息密度。
推理成本降低： 压缩处理后传输给模型的总字符数显著减少，从而有效控制推理过程的资源开销。

三、RAG思路拓展

1. T-RAG

1.1 简介

T-RAG**(Tree-based Retrieval-Augmented Generation)是一种借助层级树状结构来提升大语言模型检索效能的架构设计。**

与常规 RAG 将文档简单切分为碎片化片段的方式不同，T-RAG 通过构建具有层级关系的树形索引，使模型在处理长文本、复杂逻辑关系以及跨段落的全局信息时更加高效。

论文地址：https://arxiv.org/pdf/2402.07483

1.2 核心思想

T-RAG 的核心思想在于兼顾“全局概览****”与“局部细节”之间的平衡。

传统 RAG的局限： 容易陷入“只见树木不见森林”的困境，仅能匹配到语义相似的碎片化片段，难以把握文档的整体脉络。
T-RAG的优势： 将文档内容以树形结构重新组织——树根对应全文概要，树干概括章节主旨，树叶则承载具体细节。检索时，系统可沿着层级由上至下逐步定位，实现从宏观到微观的精准查找。

1.3 实现原理

实现 T-RAG 通常需要以下三个主要阶段：

A. 构建树 (Tree Construction)

节点切片： 将原始文档划分为若干较小的文本单元，作为树的叶子节点。
层级聚类： 借助大语言模型对相邻的文本块进行归纳总结，生成上一层的父节点，作为树干。
逐层递进： 重复上述归纳过程，直至形成唯一的根节点。由此构建的树状结构中，每一层对应不同粒度的信息摘要。

B. 树状检索 (Retrieval)

检索方式从传统的相似度匹配转变为层级遍历：

自上而下导航： 从根节点出发，依据与查询的相关性选择可能包含答案的分支路径。
多路并行探索： 可同时沿多个分支向下检索，以避免遗漏分布在不同路径中的相关信息。

C. 答案生成 (Generation)

将检索到的树节点内容（既包括具体细节，也涵盖上层节点的总结信息）一并输入大语言模型。由于融合了多层次的上下文信息，生成的答案在逻辑连贯性和整体性方面表现更优。

1.4 T-RAG 的优势

特点	描述
从容处理长文本	即使面对数十万字的长文档，仍能保持上下文的完整连贯，避免信息丢失。
宏观概括能力突出	对于“该文档主要阐述了什么？”这类整体性问题，能够进行有效的提炼与总结。
检索效率提升	借助树形层级结构，有效减少全局范围的逐项比对，使搜索过程更加精准高效。

1.5 适用场景示例

财务报告解读： 适用于跨章节、跨段落的数据比对与综合分析。
学术文献分析： 兼顾整体研究框架的理解与具体实验细节的把握。
法规条文检索： 能够在复杂的条款体系中实现精准定位与快速查阅。

2. CRAG

2.1 简介

CRAG (Corrective Retrieval-Augmented Generation)，即“可矫正的检索增强生成 ”。它是为了解决传统 RAG 容易引入“错误信息”或“无关干扰”而设计的改进方案。

在普通 RAG 中，如果检索器找回的内容质量很差，大模型（LLM）往往会“一本正经地胡说八道”。CRAG 的出现就像是给 RAG 加了一个“质量检测员”，它会在生成答案前，先评估检索到的内容准不准，如果不准，就去互联网寻找补救方案。

论文地址：https://arxiv.org/pdf/2401.15884

2.2 核心思想

CRAG 的核心在于“自我诊断”与“外部补救”：

不盲从： 对检索结果进行评分（置信度评估）。
分情况处理：

准确： 直接用。
错误： 扔掉，去网上搜。
模糊： 一边用现有的，一边去网上搜。

2.3 实现原理

CRAG 的工作流程通常分为以下四个关键环节：

A. 轻量级检索评估器 (Retrieval Evaluator)

当检索器返回文档片段后，CRAG 首先使用一个轻量级模型（或特定的 Prompt）对这些片段进行打分，将结果分为三类：

Correct (正确)： 检索结果与问题高度相关。
Incorrect (错误)： 检索结果完全跑题。
Ambiguous (模糊)： 检索结果沾点边，但不够全面。

B. 纠正策略 (Corrective Actions)

根据评估结果，CRAG 会采取不同的动作：

知识提炼 (Knowledge Refinement)： 对于“正确”的片段，进一步剔除无关废话，只保留核心信息。
网络搜索 (Web Search)： 对于“错误”或“模糊”的情况，触发搜索引擎（如 Google/Tavily）在互联网上实时抓取最新的正确信息。

C. 知识触发与整合

如果本地检索完全失败，则完全依赖搜索结果。
如果本地检索模糊，则将本地片段与搜索结果合并，取长补短。

D. 生成答案

最后，LLM 接收到的是经过筛选、纠正和补充后的“高质量”参考资料，从而输出准确的答案。

2.4 CRAG优势

CRAG 极大地提高了 RAG 系统的可靠性，尤其适合那些对事实准确性要求极高的场景（如医疗、法律）。它不再死磕本地库，而是具备了“发现自己错了并上网查证”的能力。

3. self-RAG

3.1 简介

Self-RAG (Self-Reflective Retrieval-Augmented Generation) 是一种”可自我反思的检索增强生成 “，是一种更进阶、更“聪明”的 RAG 框架。它的核心是让大模型（LLM）学会自我反思，通过在生成过程中插入特殊的“反思令牌（Reflection Tokens）”来控制自己的行为。

传统的 RAG 是被动触发的（问问题 -> 查文档 -> 回答）。Self-RAG 则赋予了模型“自主权”。它会自己判断：

我是否需要查资料？
查到的资料有用吗？
我写出来的回答是不是根据资料写的？
这个回答质量高吗？

论文地址：https://arxiv.org/pdf/2310.11511

参考: https://selfrag.github.io/

3.2 核心思想：反思令牌 (Reflection Tokens)

Self-RAG 引入了四种特殊的标签（Tokens），像开关一样控制流程：

IsRel (Is Relevant): 检查检索到的文档和问题是否相关。
IsSup (Is Supported): 检查生成的回答是否被文档内容所支持（防止幻觉）。
IsUse (Is Useful): 检查回答是否真的解决了用户的提问。
IsRet (Retrieve): 判断当前的查询是否需要去检索外部知识。

3.3 实现原理

Self-RAG 的运行过程可以分为三个动态步骤：

A. 判断是否需要检索 (Retrieve)

模型先评估问题。如果模型觉得自己已有的知识够用了，就直接生成；如果觉得不确定，就触发 IsRet 标签去数据库查资料。

B. 并行处理与评估 (Critique)

这是 Self-RAG 最强的地方：

它会针对一个问题，同时寻找多个文档片段。
对于每个片段，模型都会生成一个候选答案。
自我打分： 模型会利用 IsRel 和 IsSup 对这些候选答案进行“背书”检查，看谁最靠谱。

C. 选择最佳答案 (Generate)

模型收集所有候选回答及其分数，通过一个权重公式计算，剔除那些证据不足或无关的回答，最后输出得分最高的那一个。

3.4 优势

减少幻觉： 因为它会强制检查“我的回答是否有证据支持”。
更简洁： 如果问题很简单（如“1+1等于几？”），它会判断不需要检索，从而节省时间和计算资源。
质量高： 它通过多路生成和打分，筛选出逻辑最顺畅的答案。

4. GraphRAG

4.1 简介

GraphRAG 是由微软（Microsoft）提出的一种结合了知识图谱（Knowledge Graph）与 RAG 的进阶技术。它旨在解决传统 RAG 在处理海量文档时“只见树木，不见森林”的问题。通过构建知识图谱，将非结构化的文本转换成结构化的点（实体）和线（关系），让 AI 具备了全局视野和逻辑推理能力。

传统的 RAG 依赖于向量相似度搜索，擅长寻找“具体碎片”，但如果你问：“这份文档集的核心主题是什么？”或“人物 A 和人物 B 之间有什么复杂关系？”，传统 RAG 往往力不从心。这时候就要体现了GraphRAG的优势了。

参考文档：https://graphrag.com/concepts/intro-to-graphrag/

4.2 核心思想

GraphRAG 的核心思想是 “先索引，后聚类，再总结”：

提取实体与关系： 从文档中抓取人、事、物及其关联。
社区发现 (Community Detection)： 利用图算法（如 Leiden 算法）将相关的节点分群，形成不同的“语义社区”。
多层级总结： 为每个社区生成摘要。当你提问时，AI 会根据问题的宏大程度，选择在哪个层级的总结中寻找答案。

4.3 实现原理

GraphRAG 的实现通常分为四个关键阶段：

A. 索引阶段 (Indexing Pipeline)

文本切片： 将文档切成块。
元素提取： 利用 LLM 识别出切片中的所有实体（如：乔布斯、苹果公司）和关系（如：创立）。
图构建： 将这些实体和关系连成一张巨大的网。

B. 社区总结 (Community Summarization)

这是 GraphRAG 的精髓。它会自动将复杂的图谱切分成一个个“小组”（社区）。LLM 会预先为每个小组写一份“简报”。这样，即使你有几千篇文档，AI 也能通过阅读这些简报快速掌握全局。

C. 查询处理 (Query Engine)

GraphRAG 通常支持两种查询模式：

Global Search (全局搜索)： 处理宏观问题。它会扫描所有社区摘要来汇总答案。
Local Search (局部搜索)： 处理具体问题。它会沿着图谱中的节点和边，寻找与特定实体相关的直接证据。

D. 生成答案

将查询出来的数据和问题一起丢给大模型，让大模型总结出一个最佳答案给出。

4.4 优势与劣势

GraphRAG 就像是给 AI 准备了一份带详细索引和思维导图的百科全书。 它不仅知道信息在哪，还知道信息之间是如何交织的。

优点： 极强的概括能力和逻辑推理能力，能处理海量文档。
缺点： 索引过程非常耗费 Token（因为需要 LLM 辅助建图），响应速度相对较慢，且不支持知识更新。所以出现了一些替代方案（具有代表性的有LazyGraphRAG和LightRAG，宣称成本降低一千倍，但是效果较拉垮），如下：

5. RAG-Fusion

5.1 简介

RAG-Fusion 是一种通过多重查询生成和**重排序（Reranking）**来优化检索效果的进阶 RAG 技术。它解决了传统 RAG 的一个核心痛点：用户输入的搜索词往往不够精准，导致检索到的内容不全面。

RAG-Fusion 不仅仅是简单的“检索”，它在用户提问和数据库检索之间加了一个“头脑风暴”环节。它会把你的一个问题变成四个类似的问题，分别去查资料，最后把所有结果综合起来。

项目地址:https://github.com/Raudaschl/rag-fusion 参考:https://mp.weixin.qq.com/s/hxukMEeMzTEOVqd1P1fQLQ

5.2 核心思想

核心逻辑可以概括为：“多路并发，择优录取”。

弥补短板： 用户可能不知道怎么专业地提问，RAG-Fusion 帮用户把问题补全。
多维度搜索： 从不同的侧面去数据库里“捞”数据，防止漏掉关键信息。
融合排序： 使用 RRF (Reciprocal Rank Fusion) 算法，将多路检索回来的结果科学地合并，选出最相关的片段。

5.3 实现原理

RAG-Fusion 的工作流包含以下四个关键步骤：

A. 多重查询生成 (Query Generation)

当接收到用户的 Query（如：“如何养好猫？”）时，LLM 会生成 3-5 个不同角度的相关问题：

“幼猫的饮食建议有哪些？”
“猫咪日常护理注意事项”
“如何创造适合猫生活的家居环境？”

B. 多路并发检索 (Vector Search)

系统会对这 5 个问题分别进行向量搜索。这时，你会得到 5 份不同的搜索结果列表。

**C. 倒数排名融合 (Reciprocal Rank Fusion, RRF)**这是最关键的一步。因为不同的查询会返回重叠的内容，RRF 算法会给这些结果重新打分：

如果一个片段在 5 次搜索中都排在前几名，它的权重会变得非常高。

D. 最终生成

LLM 拿到经过 RRF 排序后的 Top-K 片段，作为上下文生成最终答案。

5.4 优势

AG-Fusion 的实现门槛并不高，而且效果提升显著，还具有如下优势

提高召回率： 极大减少了因为提问方式不对而搜不到东西的概率。
更深入的回答： 因为参考了多个维度的资料，回答往往比普通 RAG 更全面。
自动对齐： 它能自动把用户的模糊意图转化为更精确的搜索语言。

6. Rewrite-Retrieve-Read RAG

6.1 简介

Rewrite-Retrieve-Read 是一种针对查询质量进行优化的 RAG 策略。它由微软提出，重点在于解决用户原始提问与知识库索引之间“语言不匹配”的问题。

在标准的 RAG（Retrieve-Read）中，系统直接拿用户的原始问题去数据库检索。但如果用户的问题含糊、口语化或者缺乏关键词，检索结果就会很差。

Rewrite-Retrieve-Read 在检索之前增加了一个 “重写（Rewrite）” 环节：先让 LLM 把问题优化成更适合搜索的表达方式，再进行后续操作。

论文地址:https://arxiv.org/pdf/2305.14283

6.2 核心思想

核心思想是：“磨刀不误砍柴工”。

Query 是关键： 认为检索的好坏很大程度上取决于问题的质量。
消除鸿沟： 用户使用的是“自然语言”，而知识库里存的是“专业文档”。重写器（Rewriter）的作用就是充当翻译官，将自然语言转化为检索友好的关键词或短语。

6.3 实现原理

该框架将 RAG 流程拆分为三个明确的步骤：

A. 重写 (Rewrite)

系统接收到用户的问题后，先交给一个 LLM（通常是一个较小的、专门微调过或带有特定 Prompt 的模型）进行重写。

任务： 补全上下文、纠正错别字、提取核心实体、将口语转为书面语。
示例：

原始问题： “那个做电车的那个人的公司去年赚了多少？”
重写后： “特斯拉（Tesla）公司 2025 年度的净利润是多少？”

B. 检索 (Retrieve)

使用重写后的高质量问题去向量数据库或搜索引擎中进行检索。由于关键词更准确，召回的文档片段（Chunks）相关度会显著提升。

C. 阅读 (Read)

LLM使用这些精准的文档片段，最后生成准确的答案。

6.4 优势

Rewrite-Retrieve-Read 就像是在你咨询专家之前，先让秘书把你的问题整理成专业术语。它是提高 RAG 系统鲁棒性（健壮性）最简单且有效的方法之一。侧重于问题的精准度，适合复杂或模糊的单次提问。

四、RAG思路总结

1. 总结

RAG（检索增强生成）技术已从最初简单的“检索-生成”管道，演进为一套涵盖数据预处理、检索策略优化、生成质量控制的系统工程方法论。通过本文的系统总结，我们可以看到RAG技术栈的丰富性与复杂性：

在预检索阶段，通过摘要索引、父子索引、假设性问题索引和元数据索引等策略，解决了原始文档结构混乱、语义粒度不匹配的问题，为高质量检索奠定了基础。这些方法本质上是在构建一个更符合人类认知逻辑的知识组织体系。

在检索阶段，Enrich完善问题、多路召回、问题分解和混合检索等技术，从不同维度提升了检索的覆盖率和精准度。它们共同指向一个核心目标：让系统能够理解用户的真实意图，而非仅仅匹配字面表达。

在后检索阶段，重排序（RRF）、长上下文重排（LongContextReorder）以及上下文压缩过滤，则是对检索结果的精细化打磨。这些技术深刻洞察了大模型处理长上下文时的注意力分布特点，通过优化信息呈现方式，最大限度地释放了生成模型的潜力。

在思路拓展层面，T-RAG的树形结构、CRAG的自我矫正、Self-RAG的反思机制、GraphRAG的图谱思维、RAG-Fusion的多路融合以及Rewrite-Retrieve-Read的查询优化，代表了RAG向智能化、自适应性方向演进的不同路径。这些进阶方案不再是机械的流程拼接，而是赋予了系统规划、判断和优化的能力。

2. 工程化实践启示

从工程化视角看，成功的RAG应用需要把握以下关键点：

没有银弹：不存在适用于所有场景的RAG方案。摘要索引适合快速概览，父子索引适合长文处理，GraphRAG适合全局洞察，CRAG适合高时效性场景。技术选型必须回归业务本质。

检索是瓶颈，也是突破口：RAG系统的上限往往由检索质量决定。投入更多精力优化索引结构、丰富元数据、设计混合检索策略，其回报往往高于调优生成模型本身。

系统思维至关重要：RAG不是简单堆砌组件，而是需要端到端的设计思维。从数据清洗、分块策略、向量化模型选择，到检索逻辑、重排序机制、提示词工程，每个环节都相互影响。

成本与效果的权衡：GraphRAG虽好，但建图成本高昂；Self-RAG虽智能，但增加了推理延迟。工程实践中需要在召回率、准确率、响应速度、计算成本之间找到平衡点。

3. 结语

RAG技术的蓬勃发展，本质上是人工智能从“记忆模式”向“理解与运用模式”跨越的缩影。它让大模型不再受限于训练数据的时效性和边界，能够以更开放、更灵活的方式拥抱动态变化的世界。对于开发者而言，掌握RAG工程化方法论，意味着拥有了构建可靠、可控、可解释AI应用的核心能力。在通往通用人工智能的道路上，RAG不是终点，但无疑是当前最具实用价值的关键路径之一。