面向大语言模型的检索增强生成技术：综述 [译+改]
5.19整理 原文：Retrieval-Augmented Generation for Large Language Models: A Survey
摘要
大语言模型 (大语言模型，LLMs) 虽展现出强大能力，但在实际应用中，例如在准确性、知识更新速度和答案透明度方面，仍存在挑战。检索增强生成 (Retrieval-Augmented Generation, RAG) 是指在利用大语言模型回答问题之前，先从外部知识库检索相关信息。
RAG 被证明能显著提升答案的准确性，并特别是在知识密集型任务上减少模型的错误输出。通过引用信息来源，用户可以核实答案的准确性，从而增强对模型输出的信任。
此外，RAG 有助于快速更新知识并引入特定领域的专业知识。
RAG 有效结合了大语言模型的参数化知识和非参数化的外部知识库，成为实施大语言模型的关键方法之一。本文概述了 RAG 在大语言模型时代的发展模式，总结了三种模式：初级 RAG、高级 RAG 和模块化 RAG。接着，本文梳理了 RAG 的三个主要组成部分：检索器、生成器和增强方法，以及每个部分的关键技术。同时，本文讨论了如何评估 RAG 模型的有效性，介绍了两种评估方法，强调了关键的评估指标和能力，并展示了最新的自动评估框架。最后，文章从垂直优化、水平扩展性和 RAG 的技术堆栈及生态系统三个方面，介绍了未来可能的研究方向。
1 引言
大语言模型 (LLMs) 在自然语言处理 (NLP) 领域的表现远超以往任何模型。
GPT 系列模型[Brown et al., 2020, OpenAI, 2023]、LLama 系列模型[Touvron et al., 2023]、Gemini[Google, 2023] 等大语言模型，在多个评估基准上展现了卓越的语言掌握和知识理解能力，甚至超越了多项人类评估基准[Wang et al., 2019, Hendrycks et al., 2020, Srivastava et al., 2022]。
然而，大语言模型也存在许多不足。
例如，它们可能产生不准确的信息[Zhang et al., 2023b]，并在处理特定领域或高度专业化的查询时表现出知识缺失[Kandpal et al., 2023]。当所需信息超出模型训练数据范围或需要最新数据时，大语言模型可能无法提供准确答案。这一限制在将生成式人工智能部署到真实世界生产环境中尤其成为挑战，因为仅依赖于黑盒式的大语言模型可能不够。
神经网络通常通过对模型进行微调来适应特定领域或专有信息，从而将知识参数化。尽管这种方法取得了显著成效，但它需要消耗大量计算资源，成本高昂，且需要专业技术知识，因此难以适应不断变化的信息环境。在这个过程中，参数化知识和非参数化知识各司其职。参数化知识是通过训练大语言模型（LLM）获得的，存储在神经网络的权重中，代表模型对训练数据的理解和泛化能力，是生成回应的基础。而非参数化知识则存储在外部的知识源，如向量数据库中，不直接编入模型，而是作为一种可更新的补充信息。非参数化知识使大语言模型能够访问和利用最新或特定领域的信息，提高回应的准确性和相关性。
纯参数化的语言模型（LLM）将其从大量语料库中学习到的世界知识储存在模型参数中。但这种模型存在局限性。首先，它难以保留训练语料库中的所有知识，特别是对于那些不太常见且具体的知识。其次，由于模型参数无法动态更新，参数化知识可能会随时间过时。最后，参数的增加会导致训练和推理的计算成本增加。为了解决纯参数化模型的局限，语言模型可以采取半参数化方法，将非参数化的语料库数据库与参数化模型相结合。这种方法被称为检索增强生成（Retrieval-Augmented Generation, RAG）。
“检索增强生成”（Retrieval-Augmented Generation, RAG）一词最早由 [Lewis et al., 2020] 提出。它结合了一个预训练的检索器和一个预训练的序列到序列模型（生成器），通过端到端微调来以更可解释和模块化的方式捕获知识。在大型模型出现之前，RAG 主要专注于直接优化端到端模型。例如，在检索方面使用基于向量的密集通道检索（Dense Passage Retrieval, DPR）[Karpukhin et al., 2020]，以及在生成方面训练较小的模型是常见的做法。
由于总体参数较少，检索器和生成器通常会进行同步的端到端训练或微调[Izacard et al., 2022]。
随着像 ChatGPT 这样的大语言模型的出现，生成式语言模型在各种语言任务中展现出卓越的性能，得到了越来越多的关注和应用[Bai et al., 2022, OpenAI, 2023, Touvron et al., 2023, Google, 2023]。
然而，大语言模型 (LLMs) 仍面临诸如幻觉式错误 [Yao et al., 2023, Bang et al., 2023]、知识更新以及数据相关问题的挑战。
这些问题影响了大语言模型的可靠性，在一些严肃的任务场景中，尤其是在需要广泛知识的知识密集型任务，例如开放领域问题回答 [Chen and Yih, 2020, Reddy et al., 2019, Kwiatkowski et al., 2019] 和常识推理 [Clark et al., 2019, Bisk et al., 2020]，它们表现出了挑战。
模型参数中的隐含知识可能不够完整或不足。
后续研究发现，将 RAG 引入大模型的上下文学习 (In-Context Learning, ICL) 中，可以有效减轻上述问题，这种方法具有明显且易于实施的效果。在推理过程中，RAG 动态地从外部知识源中检索信息，并利用这些检索到的数据作为组织答案的参考。这极大地提高了答案的准确性和相关性，有效地解决了大语言模型中的幻觉式错误问题。这项技术自大语言模型出现以来迅速受到关注，已成为提升聊天机器人效能和增强大语言模型实用性的前沿技术之一。RAG 通过将事实知识与大语言模型的训练参数分离，巧妙地结合了生成模型的强大功能和检索模块的灵活性，为纯参数化模型中固有的知识不完整和不充分问题提供了有效的解决方案。
本论文系统地审视并分析了检索增强生成（RAG）的现有研究方法和未来发展道路，把它们归纳为三大范式：初级 RAG、高级 RAG 和模块化 RAG。接着，论文提供了关于三个核心组成部分的综合概述：检索（Retrieval）、增强（Augmented）、生成（Generation），强调了 RAG 的改进方向和目前的技术特色。在论述增强方法的章节中，将现有工作分为三个方面：RAG 的增强阶段、增强数据源以及增强过程。此外，论文还概述了与 RAG 相关的评估体系、适用场景等内容。通过阅读这篇文章，读者可以更全面、系统地理解大语言模型和检索增强生成的概念，深入了解知识检索增强的发展历程和关键技术，从而能够辨析不同技术的优缺点，找出适用的场景，并在实际中探索典型的应用案例。值得一提的是，Feng 等人[2023b] 在他们的研究中系统回顾了结合大语言模型与知识的方法、应用和未来趋势，特别关注了知识编辑和检索增强方法。Zhu 等人[2023] 则介绍了针对大语言模型的检索系统增强方面的最新进展，尤其关注检索系统本身。
同时，Asai 等人[2023a] 针对“什么”、“何时”、“如何”等问题，分析并阐释了基于检索的语言模型的关键步骤。与之相比，本文的目的是系统性地概述检索增强生成（RAG）的整个流程，并特别关注通过知识检索来增强大语言模型生成的研究。
图 1：现有 RAG 研究的时间表。时间表主要根据发布日期确定。
图 1 展示了 RAG 算法和模型的发展。在时间线上，大部分与 RAG 相关的研究出现在 2020 年之后，尤其是在 2022 年 12 月 ChatGPT 发布之后，这一事件成为了一个重要的转折点。ChatGPT 发布后，自然语言处理领域的研究进入了大模型时代。初级 RAG 技术迅速受到重视，相关研究的数量也随之激增。在增强策略方面，自 RAG 概念提出以来，预训练和监督微调阶段的强化研究一直在进行。然而，在大语言模型时代，推理阶段的强化研究开始增多。这主要是因为高性能大模型的训练成本很高。研究者们试图在推理阶段通过加入 RAG 模块，以成本效益的方式将外部知识整合进模型生成中。
在探讨增强数据的使用方面，早期的 RAG 主要致力于非结构化数据的应用，特别是在开放域问答环境中。随着时间的推移，RAG 检索的知识来源变得更加广泛，其中包括高质量数据。这些数据作为知识源，有效避免了如大模型误采纳错误信息和产生错误假设（即“幻觉”）的问题。值得一提的是，RAG 也开始利用结构化知识，如知识图谱。近期，自我检索成为热点，这指的是利用大语言模型自身的知识库来提升其性能。
本论文的接下来章节安排如下：第 2 章介绍 RAG 的背景知识。第 3 章探讨 RAG 的主流模式。第 4 章分析 RAG 中的检索器功能。第 5 章着重讲述 RAG 中的生成器如何工作。第 6 章强调介绍 RAG 中的数据增强方法。第 7 章讲解 RAG 的评估体系。第 8 章展望了 RAG 未来的发展方向。最后，在第 9 章中，我们总结了本次调研的主要内容。
2 背景
本章节我们将介绍 RAG（一种模型优化技术）的定义，并将其与其他优化技术，如微调，进行对比。
2.1 定义
在技术进步的背景下，RAG 的概念也随之拓展。在大语言模型 (Large Language Models) 的领域中，RAG 特指一种模式：模型在回答问题或生成文本时，首先从广阔的文档库中寻找相关信息。然后，模型使用这些找到的信息来生成回答或文本，从而提高其预测的准确度。RAG 的方法使得开发人员无需为每一个特定任务重新训练整个庞大的模型。他们可以简单地给模型加上一个知识库，通过这种方式增加模型的信息输入，从而提高回答的精确性。RAG 特别适用于那些需要大量知识的任务。简而言之，RAG 系统包括两个主要阶段：
- 使用编码模型（如 BM25、DPR、ColBERT 等）根据问题找到相关的文档[Robertson et al., 2009, Karpukhin et al., 2020, Khattab and Zaharia, 2020]。
- 生成阶段：以找到的上下文作为基础，系统生成文本。
图 2：RAG 与其他模型优化方法的比较
2.2 RAG 与微调
在大语言模型的优化过程中，除了 RAG，微调也是一种重要的技术。
可以把 RAG 想象成给模型提供一本教科书，让它根据特定的问题去查找信息。这种方法适用于模型需要解答具体问题或执行特定信息检索任务的情况。但 RAG 并不适合于教会模型理解广泛的领域或学习新的语言、格式或风格。
而微调更像是让学生通过广泛学习来吸收知识。
当模型需要模仿特定的结构、风格或格式时，微调就显得非常有用。它可以提高未经微调的模型的表现，使交互更加高效。
微调特别适用于强化模型已有的知识、调整或定制模型的输出，以及给模型下达复杂的指令。然而，微调并不适合于向模型中添加新的知识，或者在需要快速迭代新场景的情况下使用。
微调 (Fine-tuning) 的过程就像是让学生通过深入持久的学习来吸收知识。这种方法适用于在模型需要精确模仿特殊的结构、艺术风格或者格式时。微调能够使模型的表现超越未经微调的模型，并提升交互效率。它尤其适合于突出模型基础知识库中已有的知识，调整或定制模型输出，并以复杂的指引来训练模型。然而，微调并不适合于向模型中增加全新的知识，或应对那些需要快速迭代新场景的情况。RAG (Retrieval-Augmented Generation) 和微调 (Fine-tuning) 的具体比较可以参见表 1。
RAG 和微调可以相互补充，而非相互排斥，从而在不同层次上增强模型的能力。在特定情况下，结合这两种方法可以达到模型性能的最佳状态。整个利用 RAG 和微调进行优化的过程可能需要多轮迭代才能获得满意的成果。
目前的研究已经表明，检索增强生成 (Retrieval-Augmented Generation, RAG) 在优化大语言模型 (Large Language Model) 方面，相较于其他方法具有显著的优势【Shuster et al., 2021; Yasunaga et al., 2022; Wang et al., 2023c; Borgeaud et al., 2022】：
- RAG 通过关联外部知识来提高答案的准确性，有效减少了语言模型中出现的虚假信息，使得生成的回答更加准确可信。
- 使用检索技术能够识别到最新的信息，这使得 RAG 在保持回答的及时性和准确性方面，相较于只依赖训练数据的传统语言模型有明显优势。
- RAG 的透明度是其一大优点。通过引用信息来源，用户可以核实答案的准确性，这增强了人们对模型输出结果的信任。
- RAG 具备高度的定制化能力。通过索引与特定领域相关的文本语料库，RAG 能够为不同领域提供专业的知识支持。
- 在安全性和隐私管理方面，RAG 通过数据库中设置的角色和安全控制，实现了对数据使用的更好控制。相比之下，经过微调的模型在管理数据访问权限方面可能不够明确。
- RAG 在处理大规模数据集方面更具有扩展性。它无需更新所有参数和创建新的训练集，因此在经济效率方面更具优势。
- 最后，RAG 提供的结果更加值得信赖。RAG 从最新数据中提取确定性的结果，而经过微调的模型在处理动态数据时可能会产生错误信息和不准确之处，缺乏透明度和可信度。
2.3 常见RAG方法
| Method | 检索来源 | | |<br>|---|<br>|检索|<br>|数据类型| | | |<br>|---|<br>|检索|<br>|粒度| | | |<br>|---|<br>|增强|<br>|阶段| | | |<br>|---|<br>|检索|<br>|过程| |
| CoG [29] | Wikipedia | Text | Phrase | Pre-training | Iterative |
| DenseX [30] | FactoidWiki | Text | Proposition | Inference | Once |
| EAR [31] | Dataset-base | Text | Sentence | Tuning | Once |
| UPRISE [20] | Dataset-base | Text | Sentence | Tuning | Once |
| RAST [32] | Dataset-base | Text | Sentence | Tuning | Once |
| Self-Mem [17] | Dataset-base | Text | Sentence | Tuning | Iterative |
| FLARE [24] | Search Engine,Wikipedia | Text | Sentence | Tuning | Adaptive |
| PGRA [33] | Wikipedia | Text | Sentence | Inference | Once |
| FILCO [34] | Wikipedia | Text | Sentence | Inference | Once |
| RADA [35] | Dataset-base | Text | Sentence | Inference | Once |
| Filter-rerank [36] | Synthesized dataset | Text | Sentence | Inference | Once |
| R-GQA [37] | Dataset-base | Text | Sentence Pair | Tuning | Once |
| LLM-R [38] | Dataset-base | Text | Sentence Pair | Inference | Iterative |
| TIGER [39] | Dataset-base | Text | Item-base | Pre-training | Once |
| LM-Indexer [40] | Dataset-base | Text | Item-base | Tuning | Once |
| BEQUE [9] | Dataset-base | Text | Item-base | Tuning | Once |
| CT-RAG [41] | Synthesized dataset | Text | Item-base | Tuning | Once |
| Atlas [42] | Wikipedia, Common Crawl | Text | Chunk | Pre-training | Iterative |
| RAVEN [43] | Wikipedia | Text | Chunk | Pre-training | Once |
| RETRO++ [44] | Pre-training Corpus | Text | Chunk | Pre-training | Iterative |
| INSTRUCTRETRO [45] | Pre-training corpus | Text | Chunk | Pre-training | Iterative |
| RRR [7] | Search Engine | Text | Chunk | Tuning | Once |
| RA-e2e [46] | Dataset-base | Text | Chunk | Tuning | Once |
| PROMPTAGATOR [21] | BEIR | Text | Chunk | Tuning | Once |
| AAR [47] | MSMARCO,Wikipedia | Text | Chunk | Tuning | Once |
| RA-DIT [27] | Common Crawl,Wikipedia | Text | Chunk | Tuning | Once |
| RAG-Robust [48] | Wikipedia | Text | Chunk | Tuning | Once |
| RA-Long-Form [49] | Dataset-base | Text | Chunk | Tuning | Once |
| CoN [50] | Wikipedia | Text | Chunk | Tuning | Once |
| Self-RAG [25] | Wikipedia | Text | Chunk | Tuning | Adaptive |
| BGM [26] | Wikipedia | Text | Chunk | Inference | Once |
| CoQ [51] | Wikipedia | Text | Chunk | Inference | Iterative |
| Token-Elimination [52] | Wikipedia | Text | Chunk | Inference | Once |
| PaperQA [53] | Arxiv,Online Database,PubMed | Text | Chunk | Inference | Iterative |
| NoiseRAG [54] | FactoidWiki | Text | Chunk | Inference | Once |
| IAG [55] | Search Engine,Wikipedia | Text | Chunk | Inference | Once |
| NoMIRACL [56] | Wikipedia | Text | Chunk | Inference | Once |
| ToC [57] | Search Engine,Wikipedia | Text | Chunk | Inference | Recursive |
| SKR [58] | Dataset-base,Wikipedia | Text | Chunk | Inference | Adaptive |
| ITRG [59] | Wikipedia | Text | Chunk | Inference | Iterative |
| RAG-LongContext [60] | Dataset-base | Text | Chunk | Inference | Once |
| ITER-RETGEN [14] | Wikipedia | Text | Chunk | Inference | Iterative |
| IRCoT [61] | Wikipedia | Text | Chunk | Inference | Recursive |
| LLM-Knowledge-Boundary [62] | Wikipedia | Text | Chunk | Inference | Once |
| RAPTOR [63] | Dataset-base | Text | Chunk | Inference | Recursive |
| RECITE [22] | LLMs | Text | Chunk | Inference | Once |
| ICRALM [64] | Pile,Wikipedia | Text | Chunk | Inference | Iterative |
| Retrieve-and-Sample [65] | Dataset-base | Text | Doc | Tuning | Once |
| Zemi [66] | C4 | Text | Doc | Tuning | Once |
| CRAG [67] | Arxiv | Text | Doc | Inference | Once |
| 1-PAGER [68] | Wikipedia | Text | Doc | Inference | Iterative |
| PRCA [69] | Dataset-base | Text | Doc | Inference | Once |
| QLM-Doc-ranking [70] | Dataset-base | Text | Doc | Inference | Once |
| Recomp [71] | Wikipedia | Text | Doc | Inference | Once |
| DSP [23] | Wikipedia | Text | Doc | Inference | Iterative |
| RePLUG [72] | Pile | Text | Doc | Inference | Once |
| ARM-RAG [73] | Dataset-base | Text | Doc | Inference | Iterative |
| GenRead [13] | LLMs | Text | Doc | Inference | Iterative |
| UniMS-RAG [74] | Dataset-base | Text | Multi | Tuning | Once |
| CREA-ICL [19] | Dataset-base | Crosslingual,Text | Sentence | Inference | Once |
| PKG [75] | LLM | Tabular,Text | Chunk | Inference | Once |
| SANTA [76] | Dataset-base | Code,Text | Item | Pre-training | Once |
| SURGE [77] | Freebase | KG | Sub-Graph | Tuning | Once |
| MK-ToD [78] | Dataset-base | KG | Entity | Tuning | Once |
| Dual-Feedback-ToD [79] | Dataset-base | KG | Entity Sequence | Tuning | Once |
| KnowledGPT [15] | Dataset-base | KG | Triplet | Inference | Muti-time |
| FABULA [80] | Dataset-base,Graph | KG | Entity | Inference | Once |
| HyKGE [81] | CMeKG | KG | Entity | Inference | Once |
| KALMV [82] | Wikipedia | KG | Triplet | Inference | Iterative |
| RoG [83] | Freebase | KG | Triplet | Inference | Iterative |
| G-Retriever [84] | Dataset-base | TextGraph | Sub-Graph | Inference | Once |
3 RAG 框架（范式）
RAG 研究范式在不断演变。本章重点介绍 RAG 研究范式的发展历程。我们将其分为三种类型：初级 RAG、高级 RAG 和模块化 RAG。虽然早期的 RAG 在成本效益上表现良好，并且性能优于传统的大语言模型 (LLM)，但它仍面临着诸多挑战。高级 RAG 和模块化 RAG 的设计是为了解决原始 RAG (Naive RAG) 的特定不足。
| 特征比较 | RAG（检索增强生成） | 微调（Fine-tuning） |
|---|---|---|
| 知识更新 | 直接更新检索知识库即可，无需重新训练模型，能够持续获取最新信息，特别适合动态变化的数据环境。 | 模型内部存储的是静态知识，若需更新知识，通常需要重新进行微调训练。 |
| 外部知识利用 | 擅长结合外部资源，特别适用于文档库、数据库等结构化或非结构化数据。 | 可将特定领域知识融入模型参数中，但对于频繁变化的数据源不够灵活。 |
| 数据处理要求 | 对训练数据要求较低，重点在于构建高质量的检索系统。 | 依赖高质量标注数据集，数据质量和规模直接影响效果。 |
| 模型定制能力 | 主要增强模型的信息获取能力，对行为风格的定制能力有限。 | 可以针对特定任务、术语体系、输出风格进行深度定制。 |
| 可解释性 | 回答可追溯到具体检索来源，可解释性和可验证性较强。 | 模型决策过程较为黑盒，可解释性相对较低。 |
| 计算资源需求 | 需要额外资源支持向量数据库、Embedding 和检索流程。 | 需要准备数据集并消耗较多 GPU 资源完成训练。 |
| 响应延迟 | 由于增加检索步骤，响应时间通常略高。 | 推理时无需检索，响应速度通常更快。 |
| 幻觉控制 | 基于外部证据生成回答，通常能显著降低幻觉。 | 在特定领域内可减少幻觉，但对未知问题仍可能产生错误信息。 |
| 伦理与隐私问题 | 外部知识库中若包含敏感数据，可能带来隐私与合规风险。 | 训练数据中的敏感内容可能被模型记忆，存在隐私泄露风险。 |
| 适用场景 | 知识更新频繁、需要引用依据、企业知识问答系统。 | 风格定制、垂直领域适配、任务能力强化。 |
表 1: RAG 与微调之间的对比
3.1 原始 RAG (Naive RAG)
原始 RAG (Naive RAG) 代表了早期研究方法，在 ChatGPT 广泛应用后迅速崭露头角。原始 RAG 的流程包括传统的索引、检索和生成步骤。原始 RAG 也被概括为一个“检索” - “阅读”框架 [Ma et al., 2023a]。
索引
指的是在离线状态下，从数据来源处获取数据并建立索引的过程。具体而言，构建数据索引包括以下步骤：
-
数据索引： 包括清理和提取原始数据，将 PDF、HTML、Word、Markdown 等不同格式的文件转换成纯文本。
-
分块： 将加载的文本分割成更小的片段。由于语言模型处理上下文的能力有限，因此需要将文本划分为尽可能小的块。
-
嵌入和创建索引： 这一阶段涉及通过语言模型将文本编码为向量的过程。所产生的向量将在后续的检索过程中用来计算其与问题向量之间的相似度。由于需要对大量文本进行编码，并在用户提问时实时编码问题，因此嵌入模型要求具有高速的推理能力，同时模型的参数规模不宜过大。完成嵌入之后，下一步是创建索引，将原始语料块和嵌入以键值对形式存储，以便于未来进行快速且频繁的搜索。
检索：
根据用户的输入，采用与第一阶段相同的编码模型将查询内容转换为向量。系统会计算问题向量与语料库中文档块向量之间的相似性，并根据相似度水平选出最相关的前 K 个文档块作为当前问题的补充背景信息。
生成：
将给定的问题与相关文档合并为一个新的提示信息。随后，大语言模型（LLM）被赋予根据提供的信息来回答问题的任务。根据不同任务的需求，可以选择让模型依赖自身的知识库或仅基于给定信息来回答问题。如果存在历史对话信息，也可以将其融入提示信息中，以支持多轮对话。
朴素 RAG 的挑战：
朴素 RAG 主要在三个方面面临挑战：检索质量、回应生成质量和增强过程。
-
检索质量： 该方面的问题多方面。最主要的问题是低精度，即检索集中的文档块并不都与查询内容相关，这可能导致信息错误或不连贯。其次是低召回率问题，即未能检索到所有相关的文档块，使得大语言模型无法获取足够的背景信息来合成答案。此外，过时信息也是一个挑战，因为数据冗余或过时可能导致检索结果不准确。
-
回应生成质量： 这方面的问题同样多样。最突出的问题是制造错误信息，即模型在缺乏足够上下文的情况下虚构答案。另一个问题是回答不相关，即模型生成的答案未能针对查询问题。进一步来说，生成有害或偏见性回应也是一个问题。
-
增强过程： 最终，增强过程面临几个重要挑战。特别重要的是，如何将检索到的文段的上下文有效融入当前的生成任务。如果处理不得当，生成的内容可能显得杂乱无章。当多个检索到的文段包含相似信息时，冗余和重复成为问题，这可能导致生成内容的重复。此外，如何判断多个检索到的文段对生成任务的重要性或相关性非常有挑战性，增强过程需要恰当地评估每个文段的价值。检索到的内容可能具有不同的写作风格或语调，增强过程需调和这些差异，以确保最终输出的一致性。最后，生成模型可能会过度依赖于增强信息，导致生成的内容仅是重复检索到的信息，而缺乏新的价值或综合信息。
3.2 高级 RAG
为了克服 Naive RAG 的局限性，高级 RAG 进行了针对性的改进。在检索生成质量方面，高级 RAG 引入了预检索和后检索的方法。它还通过滑动窗口、细粒度分割和元数据等手段优化了索引，以解决 Naive RAG 所遇到的索引问题。同时，高级 RAG 也提出了多种优化检索流程的方法。在具体实施上，高级 RAG 可以通过流水线方式或端到端的方式进行调整。
预检索处理
可以把图中的 Pre-Retrieval（检索前处理） 重新整理成两大类：
Pre-Retrieval
├── 一、用户输入问题的处理
│ ├── Query Rewrite / Clarification 查询重写与澄清
│ ├── Query Expansion 查询扩展
│ ├── Query Transformation 查询转换
│ ├── Metadata Router / Filter 元数据路由与过滤
│ ├── Semantic Router 语义路由
│ └── Mixed / Hybrid Retrieval 混合检索
│
└── 二、文档的处理
├── Fine-grained Data Cleaning 细粒度数据清洗
├── Chunking Strategy 切块策略
├── Sliding Window 滑动窗口
├── Small2Big 小到大检索
├── Add Metadata 添加元数据
├── Add File Structure 添加文件结构
├── Structural Index 结构化索引
└── Knowledge Graph Index 知识图谱索引
Advanced RAG 的检索前阶段，本质上就是同时优化 原始查询 和 索引结构。原文明确提到，pre-retrieval 的重点是优化索引结构和原始查询；索引优化包括增强数据粒度、优化索引结构、添加元数据、对齐优化和混合检索，查询优化则包括查询重写、查询转换、查询扩展等。
一、用户输入问题的处理
用户输入问题的处理，核心目标是：不要直接拿用户原始问题去检索，而是先把问题改造成更清晰、更完整、更适合召回的检索请求。
在 Naive RAG 中，用户问什么，系统就直接把这个问题向量化，然后去向量数据库里找相似 chunk。但真实场景下，用户问题往往有省略、歧义、口语化、上下文依赖或关键词缺失，所以直接检索容易召回不准。
1. Query Rewrite / Clarification：查询重写与澄清
Query Rewrite 是把用户原始问题改写成更适合检索的表达。
例如用户问：
“它和微调有什么区别？”
这个问题对检索系统来说太模糊，因为“它”指代不明。改写后可以变成：
“RAG 与 Fine-tuning 在外部知识需求、模型适配需求、更新成本和适用场景方面有什么区别？”
这样检索时更容易命中相关章节。
Clarification 则是对问题中的模糊部分进行澄清。例如：
| 原始问题 | 问题所在 | 澄清后 |
|---|---|---|
| “这个方法有什么问题？” | “这个方法”指代不明 | “Naive RAG 在检索、生成和增强阶段有哪些局限？” |
| “RAG 怎么优化？” | 范围太大 | “RAG 在检索前、检索后和生成阶段分别有哪些优化方法？” |
| “LLM 是什么意思？” | 缩写有歧义 | 在 RAG 论文语境下，LLM 指 Large Language Model |
原文也指出，用户原始查询并不总是适合 LLM 检索，因此可以提示 LLM 重写查询，或者使用专门的小模型进行查询重写。
它解决的核心问题是：
用户自然语言问题 ≠ 最佳检索查询
2. Query Expansion：查询扩展
查询扩展是把一个问题扩展成多个相关查询，以提升召回率。
例如用户问：
“Advanced RAG 做了哪些改进？”
可以扩展成：
Advanced RAG pre-retrieval optimizationAdvanced RAG post-retrieval rerank compressionAdvanced RAG indexing metadata sliding windowAdvanced RAG query rewriting query expansion
这样做的原因是，同一个问题可能在文档中以不同方式表达。如果只用一个查询，可能漏掉重要内容；扩展成多个查询后，可以覆盖更多相关表述。
常见方式包括：
| 方法 | 说明 |
|---|---|
| Multi-Query | 用 LLM 生成多个等价或相关查询，并行检索 |
| Sub-Query | 把复杂问题拆成多个子问题 |
| Chain-of-Verification | 对扩展出来的查询进行验证，减少幻觉 |
原文中提到，Multi-Query 会通过提示工程让 LLM 扩展查询，并并行执行；Sub-Query 则把复杂问题拆解为更简单的子问题。
查询扩展适合处理：
问题复杂问题覆盖多个方面原问题关键词不足需要多角度召回
3. Query Transformation：查询转换
查询转换的核心思想是：不直接用用户原始问题检索，而是用转换后的查询检索。
它和 Query Rewrite 很接近，但 Query Transformation 更强调“生成另一种检索对象”。
典型方法包括：
| 方法 | 说明 |
|---|---|
| HyDE | 先让 LLM 生成一个假设答案或假设文档，再用这个假设文档去检索 |
| Step-back Prompting | 把具体问题抽象成更高层问题，再同时检索原问题和抽象问题 |
| Rewrite-Retrieve-Read | 先重写，再检索，再阅读生成 |
例如用户问：
“为什么 Advanced RAG 比 Naive RAG 更稳定？”
HyDE 可能先生成一段假设回答：
“Advanced RAG 通过查询重写、元数据过滤、混合检索、重排序和上下文压缩提升检索质量……”
然后系统用这段“假设答案”去检索真实文档。这样做的好处是，答案式文本和文档中的相关段落往往更相似，比直接用问题去匹配更容易命中。
原文提到，HyDE 构造的是假设文档，也就是原始查询的假设答案，它关注的是“答案到答案”的嵌入相似度，而不是单纯寻找问题和文档之间的相似度。
4. Metadata Router / Filter：元数据路由与过滤
这是对用户问题进行结构化解析，然后利用文档元数据缩小检索范围。
例如用户问：
“请找出 2024 年之后关于 RAG 评估的论文内容。”
系统可以从问题中抽取：
时间：2024 年之后主题：RAG 评估文档类型：论文
然后只在符合这些元数据条件的 chunk 中检索。
常见元数据包括：
| 元数据 | 用途 |
|---|---|
| 文件名 | 只查某个文档 |
| 章节名 | 只查某个章节 |
| 页码 | 定位来源 |
| 作者 | 限定作者 |
| 时间戳 | 保证知识新鲜度 |
| 文档类型 | 区分论文、合同、网页、报告 |
| 领域标签 | 区分法律、医疗、金融、技术文档 |
| 权限标签 | 控制可访问范围 |
原文中提到，Metadata Router / Filter 的第一步是从查询中抽取关键词或实体，然后根据 chunk 中的关键词和元数据进行过滤，以缩小搜索范围。
它的价值在于：
先过滤，再检索
而不是在所有文档中盲目做向量相似度搜索。
5. Semantic Router：语义路由
Semantic Router 是根据用户问题的语义，把请求分发到不同的检索流程、数据源或工具。
例如：
| 用户问题 | 路由方向 |
|---|---|
| “这篇论文中 Advanced RAG 是怎么定义的？” | 论文文本向量库 |
| “表 I 中哪些方法使用 KG？” | 表格结构检索 |
| “某个实体之间有什么关系？” | 知识图谱检索 |
| “2024 年最新 RAG benchmark 有哪些？” | Web / 论文数据库 |
| “合同里付款条款是什么？” | 指定合同文件 + 元数据过滤 |
原文指出，Query Routing 会根据不同查询路由到不同 RAG pipeline，适用于能适配多种场景的通用 RAG 系统；Semantic Router 则利用查询的语义信息进行路由。
它解决的是：
不同问题不应该使用同一条检索路径
6. Mixed / Hybrid Retrieval：混合检索
混合检索是把多种检索方式结合起来，而不是只依赖向量检索。
常见组合是：
BM25 / keyword search + Dense vector search
也可以进一步扩展为：
关键词检索 + 向量检索 + 元数据过滤 + 图检索 + 表格检索 + rerank
不同检索方式擅长的东西不同：
| 检索方式 | 擅长 | 不擅长 |
|---|---|---|
| BM25 / 关键词检索 | 精确词、专有名词、编号、公式、法规条款 | 同义表达、语义相似 |
| 向量检索 | 语义相似、改写表达、自然语言问题 | 精确匹配、罕见实体、数字编号 |
| 元数据过滤 | 时间、文件、作者、权限、章节过滤 | 不能单独判断语义相关性 |
| 知识图谱检索 | 实体关系、多跳推理 | 构建和维护成本高 |
| 表格 / SQL 检索 | 结构化数据、统计查询 | 非结构化语义问题 |
例如用户问：
“表 I 中哪些方法的 Retrieval Source 是 Wikipedia，并且 Retrieval process 是 Iterative？”
这个问题如果只用向量检索，效果可能不好；更合适的是表格结构检索或 SQL 式查询。
又如用户问：
“RAG 中 LLM 和 retriever 的 alignment 是怎么做的？”
这类语义问题更适合向量检索。
混合检索的本质是：
用关键词保证精确召回用向量保证语义召回用元数据保证范围正确用 rerank 保证排序质量
原文提到，稀疏检索和稠密检索捕捉的是不同相关性特征，两者可以互补；稀疏检索还能帮助稠密检索处理包含罕见实体的查询，从而提升鲁棒性。
二、文档的处理
文档处理的核心目标是：在用户问题到来之前，先把知识库建设得更干净、更结构化、更容易被检索。
如果文档处理不好，后面的查询重写、混合检索、rerank 都只能在低质量数据上补救。
1. Fine-grained Data Cleaning：细粒度数据清洗
细粒度数据清洗是文档处理的第一步。
原始文档往往包含大量噪声，例如：
页眉页脚页码目录广告版权声明导航栏重复段落乱码无意义换行表格残缺OCR 错误参考文献噪声
如果这些内容直接进入向量库，会导致系统召回大量无关 chunk。
例如，一篇论文 PDF 中每页都有标题：
Retrieval-Augmented Generation for Large Language Models: A Survey
如果不清洗，这个标题会重复出现在很多 chunk 中，导致检索时大量 chunk 都看起来和 RAG 相关，但实际内容可能没有答案。
细粒度清洗的目标是：
删除噪声保留语义保留结构保留可追溯信息
它主要提升的是检索准确率和知识库质量。
2. Chunking Strategy：切块策略
文档不能整体塞进向量库，通常要切成 chunk。问题在于：chunk 太大或太小都会有问题。
| chunk 粒度 | 优点 | 缺点 |
|---|---|---|
| 太大 | 上下文完整 | 噪声多，检索不精准 |
| 太小 | 检索精准 | 语义不完整，容易丢上下文 |
| 固定长度切块 | 简单 | 容易切断句子、表格、段落 |
| 语义切块 | 更自然 | 实现成本高 |
原文提到，常见方法是按固定 token 数切分文档，例如 100、256、512 tokens；较大的 chunk 能捕获更多上下文，但噪声更多、处理成本更高；较小的 chunk 噪声较少，但可能无法完整表达必要上下文。
好的切块策略应该尽量遵循：
按标题切按段落切按语义单元切表格不随意切断代码块不随意切断图注和图片说明尽量绑定
3. Sliding Window：滑动窗口
滑动窗口是在相邻 chunk 之间保留一定重叠内容。
例如：
Chunk 1: token 1-500Chunk 2: token 401-900Chunk 3: token 801-1300
这样做可以避免关键信息刚好被切在两个 chunk 中间。
它适合处理：
上下文连续性强的文档论文法律文件技术文档长报告
缺点是会增加索引数量，导致存储成本和检索成本上升，也可能带来重复信息。
4. Small2Big：小到大检索
Small2Big 的思想是：
检索时用小粒度生成时给大上下文
例如，检索阶段用句子作为单位。如果命中某一句，就把它所在段落，甚至前后段落一起给 LLM。
这样可以兼顾两点：
| 阶段 | 使用粒度 | 目的 |
|---|---|---|
| 检索阶段 | 小粒度句子 / proposition | 提高匹配精度 |
| 生成阶段 | 大粒度段落 / 上下文窗口 | 保证语义完整 |
原文也提到，Small2Big 使用句子作为检索单元，并把前后句作为更大的上下文提供给 LLM。
它比单纯滑动窗口更灵活，因为它不是机械地重复切块，而是在命中局部信息后动态补充上下文。
5. Add Metadata：添加元数据
添加元数据是文档处理中的关键方式。它不是改变正文内容，而是给每个 chunk 添加附加信息。
例如一个 chunk 可以带有：
{ "file_name": "RAG Survey.pdf", "section": "II-B Advanced RAG", "page": 5, "author": "Gao et al.", "year": 2024, "doc_type": "paper", "topic": "Advanced RAG", "chunk_id": "rag_survey_0023"}
原文提到，chunk 可以通过页码、文件名、作者、类别、时间戳等元数据进行丰富，随后可以基于这些元数据进行过滤，从而限制检索范围；同时，给文档时间戳赋予不同权重，还可以实现 time-aware RAG，保证知识新鲜度，避免过时信息。
添加元数据的作用主要有四个：
- 第一，支持过滤
例如：
只检索 2023 年之后的文档只检索某个项目文件夹只检索某个作者的论文只检索“评估”章节
- 第二，支持溯源
回答时可以告诉用户答案来自哪个文件、哪一页、哪一节。
- 第三，支持权限控制
企业 RAG 中，不同用户能访问的文档不同。元数据可以记录权限标签。
- 第四，支持时间感知
对于法规、政策、产品文档、公司制度等内容，新旧版本非常重要。元数据可以帮助系统优先使用最新版本。
除了从原始文档中抽取元数据，还可以人工构造元数据。例如：
段落摘要关键词主题标签假设问题实体列表适用场景
原文也提到，可以给段落添加摘要，或者引入假设问题；这种方法也被称为 Reverse HyDE，即用 LLM 生成能被文档回答的问题，检索时计算原始问题与假设问题之间的相似度，以减少问题和答案之间的语义差距。
6. Add File Structure：添加文件结构
添加文件结构是把文档的层级关系保留下来，而不是把所有 chunk 平铺存储。
例如论文结构：
Title├── Abstract├── I Introduction├── II Overview of RAG│ ├── II-A Naive RAG│ ├── II-B Advanced RAG│ └── II-C Modular RAG├── III Retrieval│ ├── III-A Retrieval Source│ ├── III-B Indexing Optimization│ └── III-C Query Optimization
如果不保留结构，系统只知道某个 chunk 和问题相似，但不知道它属于哪个章节。保留结构后，系统可以先定位章节，再定位段落。
这对于长文档尤其重要。
例如用户问：
“Advanced RAG 的 pre-retrieval 包括什么？”
系统可以先定位：
II-B Advanced RAG
再在该节中检索：
pre-retrieval processindexing optimizationquery optimizationmetadatamixed retrieval
添加文件结构可以提升：
章节级定位层级检索多文档组织答案可解释性引用可追踪性
7. Structural Index：结构化索引
结构化索引是比“添加文件结构”更进一步的做法。它会把文档组织成树状或图状索引。
常见形式包括：
文档节点章节节点小节节点段落节点chunk 节点摘要节点表格节点图片节点
原文提到，层级索引结构中，文件被安排为父子关系，并与 chunk 相连接；每个节点存储数据摘要，帮助系统快速遍历数据，并判断应该抽取哪些 chunk。
结构化索引适合处理：
长论文技术手册法律法规合同产品说明书知识库页面多文档集合
它的检索方式通常是：
先粗检索文档或章节再细检索段落或 chunk最后补充上下文
这样可以降低全库检索的噪声。
8. Knowledge Graph Index：知识图谱索引
知识图谱索引是把文档中的实体、概念和关系抽取出来，形成图结构。
例如：
Advanced RAG → includes → Pre-RetrievalPre-Retrieval → optimizes → QueryPre-Retrieval → optimizes → Indexing StructureMetadata → supports → FilteringHybrid Retrieval → combines → Sparse RetrievalHybrid Retrieval → combines → Dense Retrieval
这种索引适合处理多跳推理问题。
例如用户问：
“Advanced RAG 如何通过元数据和混合检索提升召回质量？”
系统需要理解多个概念之间的关系：
Advanced RAG→ Pre-Retrieval→ Metadata Filtering→ Hybrid Retrieval→ Retrieval Quality
普通向量检索可能只能找到局部相似文本，而知识图谱可以帮助系统沿着实体关系进行推理。
原文提到，知识图谱索引可以帮助保持一致性，描述不同概念和实体之间的连接，减少幻觉，并将信息检索过程转化为 LLM 可以理解的指令，从而提升知识检索准确性和上下文连贯性。
嵌入 (Embedding)
-
微调嵌入： 微调嵌入模型的调整直接影响到 RAG 的有效性。微调的目的是让检索到的内容与查询之间的相关性更加紧密。微调嵌入的作用可以比作在语音生成前对“听觉”进行调整，优化检索内容对最终输出的影响。通常，微调嵌入的方法可以分为针对特定领域上下文的嵌入调整和检索步骤的优化。特别是在处理不断变化或罕见术语的专业领域，这些定制化的嵌入方法能够显著提高检索的相关性。BGE[BAAI, 2023]嵌入模型是一个经过微调的高性能嵌入模型，例如由 BAAI 3 开发的 BGE-large-EN。为了对 BGE 模型进行微调，首先使用诸如 gpt-3.5-turbo 这样的大语言模型（LLM）根据文档块制定问题，其中问题和答案（文档块）构成了微调过程中的训练对。
-
动态嵌入（Dynamic Embedding）：不同于静态嵌入（static embedding），动态嵌入根据单词出现的上下文进行调整，为每个单词提供不同的向量表示。例如，在 Transformer 模型（如 BERT）中，同一单词根据周围词汇的不同，其嵌入也会有所变化。研究发现，在 OpenAI 的 text-embeddingada-002 模型中，文本长度小于 5 个 Token 时，常出现意外高的余弦相似度。理想的嵌入应该包含足够的上下文，以保证良好的结果。OpenAI 的 embeddings-ada-02 是基于大语言模型（如 GPT）原理开发的，比传统静态嵌入模型更复杂，能够捕捉一定程度的上下文。尽管它在上下文理解方面表现出色，但可能不如最新的大语言模型（如 GPT-4）那样对上下文敏感。
检索后处理流程
在从数据库中检索出有价值的上下文后，将其与查询内容合并输入到大语言模型（LLM）会遇到挑战。一次性向大语言模型展示所有相关文档可能会超出其处理的上下文窗口限制。将多个文档拼接成一个冗长的检索提示不仅效率低，还会引入噪声，影响大语言模型聚焦关键信息。因此，需要对检索到的内容进行额外处理，以解决这些问题。
ReRank（重新排序）
ReRank 的作用是：在已经检索到一批候选文档后，再重新判断它们和用户问题的相关性，并调整顺序。
在普通 RAG 中，系统通常会先从向量数据库中取回 Top-k 个文档块。例如取回 10 个 chunk。但这些 chunk 的顺序不一定最适合 LLM 使用：有些真正重要的信息可能排在中间或后面，有些看起来相似但实际无关的内容可能排在前面。
ReRank 就是在这个阶段进行二次筛选和排序。
例如用户问：
Advanced RAG 中 pre-retrieval 的作用是什么？
第一次向量检索可能返回：
1. RAG 的总体介绍
2. Naive RAG 的流程
3. Advanced RAG 的 pre-retrieval 说明
4. Advanced RAG 的 post-retrieval 说明
5. Modular RAG 的模块介绍
ReRank 之后，顺序可能变成：
1. Advanced RAG 的 pre-retrieval 说明
2. Advanced RAG 的索引优化方法
3. Advanced RAG 的查询优化方法
4. RAG 的总体介绍
5. post-retrieval 说明
这样 LLM 在生成答案时，会优先看到最相关的信息。
ReRank 还常常和 “Lost in the Middle” 问题有关。LLM 在处理长上下文时，往往更关注开头和结尾，容易忽略中间内容。因此，一些重排序方法会刻意把最重要的文档放在上下文窗口的前部或后部。
例如：
上下文开头：最相关文档 A
中间：次相关文档 B、C、D
上下文结尾：最相关文档 E
这样可以降低关键信息被埋在中间而被模型忽略的风险。
常见的 ReRank 方法包括：
| 方法 | 作用 |
|---|---|
| Diversity Ranker | 根据文档多样性重新排序，避免多个 chunk 内容重复 |
| LostInTheMiddleRanker | 将重要文档放在上下文开头和结尾 |
| Cohere Rerank | 重新计算查询和文档之间的相关性 |
| BGE Reranker | 使用专门的重排序模型判断文档相关性 |
| LLM-based Rerank | 让大语言模型判断哪些文档更有用 |
可以简单理解为：
普通检索：先粗略找出可能相关的内容
ReRank：再精细判断哪些内容最值得给 LLM 看
Prompt 压缩
Prompt 压缩的作用是：把检索到的长上下文压短，只保留对回答问题真正有用的信息。
RAG 系统常常会检索出很多文档块，但不是所有内容都值得放进 prompt。过多无关信息会带来三个问题：
上下文太长
噪声太多
模型注意力被分散
例如用户问：
Naive RAG 有哪些缺点？
系统检索到了 5 个 chunk，其中包含：
chunk 1：Naive RAG 的检索问题
chunk 2：Naive RAG 的生成问题
chunk 3：Naive RAG 的增强问题
chunk 4：RAG 的历史发展
chunk 5：论文作者介绍
其中 chunk 4 和 chunk 5 对回答问题帮助不大。如果全部放进 prompt，LLM 可能会被无关内容干扰。
Prompt 压缩会把上下文变成：
Naive RAG 的主要缺点包括：
1. 检索阶段可能召回无关 chunk，或遗漏关键信息；
2. 生成阶段可能产生幻觉、无关内容、偏见或有害输出；
3. 增强阶段可能出现上下文冗余、不连贯，以及信息整合困难。
这样，LLM 得到的是更短、更干净、更聚焦的上下文。
常见压缩方式包括：
| 方法 | 说明 |
|---|---|
| 删除无关句子 | 去掉和问题无关的内容 |
| 保留关键词句 | 只保留包含答案线索的句子 |
| 摘要压缩 | 把多个 chunk 总结成短上下文 |
| Token 压缩 | 删除不重要 token，保留模型可理解的信息 |
| 层级压缩 | 先压缩段落，再压缩章节，最后形成摘要 |
例如 Selective Context、LLMLingua 等方法，会使用小型语言模型来判断哪些 token、句子或片段更重要，然后删除不重要内容。
不过，Prompt 压缩也有风险：压得太狠可能会丢掉关键细节。
例如原文中有一句：
Advanced RAG improves retrieval quality through pre-retrieval and post-retrieval strategies.
如果压缩后只剩：
Advanced RAG improves retrieval quality.
那么 “pre-retrieval and post-retrieval strategies” 这个关键机制就丢失了。
因此，好的 Prompt 压缩不是简单变短，而是要做到：
减少噪声
保留证据
保留逻辑
保留关键限定条件
Recomp 等方法通过训练不同粒度的压缩器来缓解这个问题。面对长篇上下文时，也可以采用分解、分层总结树等方式，让模型先理解局部内容，再整合全局信息。
递归检索与查询引擎（检索过程优化，不是严格的后处理）
递归检索的作用是：不是一次性完成检索，而是根据已有结果继续深入检索。
普通 RAG 通常只检索一次：
问题 → 检索 Top-k 文档 → 生成答案
但对于复杂问题，一次检索可能不够。
例如用户问：
Advanced RAG 和 Modular RAG 分别如何改进 Naive RAG？
这个问题至少涉及三个对象：
Naive RAG
Advanced RAG
Modular RAG
如果只检索一次，系统可能只找到 Advanced RAG 的内容，遗漏 Modular RAG 的内容。
递归检索会分多步进行：
第一步：检索 Naive RAG 的问题
第二步：根据第一步结果，检索 Advanced RAG 的改进
第三步：继续检索 Modular RAG 的改进
第四步：整合三部分内容
递归检索也可以结合文档层级结构使用。
例如：
第一层：先检索相关章节
第二层：在章节中检索相关小节
第三层：在小节中检索具体段落
第四层：把命中的段落和上下文交给 LLM
这就像人在读一本书时不会一开始就逐字搜索，而是：
先看目录
再找章节
再看小节
最后读具体段落
查询引擎则是对不同查询方式的封装。根据问题类型，系统可以选择：
| 查询方式 | 适合场景 |
|---|---|
| 向量查询 | 语义类问题 |
| 树状查询 | 长文档、层级文档 |
| 表格查询 | 表格、统计、对比 |
| 关键词查询 | 专有名词、编号、术语 |
| 子问题查询 | 多步骤复杂问题 |
例如用户问：
表 I 中哪些方法属于 Iterative retrieval？
这时用普通向量检索不一定最好，表格查询或结构化查询更合适。
递归检索的核心价值是：
先粗后细
逐步深入
边检索边缩小范围
3.3 模块化 RAG
模块化 RAG 结构打破了传统的“原始 RAG”框架，这个框架原本涉及索引、检索和生成，现在提供了更广泛的多样性和更高的灵活性。它不仅集成了各种方法来丰富功能模块，比如在相似性检索中加入了搜索模块，并且在检索器中采用了微调 (fine-tuning) 策略[Lin et al., 2023]。特别的问题也催生了重构后的 RAG 模块[Yu et al., 2022]，以及类似 [Shao et al., 2023] 的迭代方法。这种模块化的 RAG 范式正逐渐成为 RAG 领域的趋势，它支持从序列化流程到跨多个模块的端到端训练方法。三种 RAG 范式的对比在图 3 中进行了详细展示。
新模块
-
搜索模块： 与简单/高级 RAG 的查询和语料间的常规相似性检索不同，这个特定场景下的搜索模块融合了直接在（附加的）语料库中进行搜索的方法。这些方法包括利用大语言模型（LLM）生成的代码、SQL、Cypher 等查询语言，或是其他定制工具。其搜索数据源多样，涵盖搜索引擎、文本数据、表格数据或知识图等[Wang et al., 2023c]。
-
记忆模块： 本模块充分利用大语言模型本身的记忆功能来引导信息检索。其核心原则是寻找与当前输入最为匹配的记忆。例如，Self-mem [Cheng et al., 2023b]通过迭代使用增强检索的生成模型，创建了一个结合了“原始问题”和“双重问题”的无限记忆池。这种增强检索的生成模型能够利用其自身的输出来自我提升，在推理过程中使文本更加贴近数据分布，而非仅依赖训练数据[Wang et al., 2022a]。
-
额外生成模块： 面对检索内容中的冗余和噪声问题，这个模块通过大语言模型生成必要的上下文，而非直接从数据源进行检索[Yu et al., 2022]。通过这种方式，由大语言模型生成的内容更可能包含与检索任务相关的信息。
-
任务适应模块： 该模块致力于将 RAG 调整以适应各种下游任务。例如，UPRISE[Cheng et al., 2023a]能够自动从预先构建的数据池中为给定的零样本任务输入检索出适当的提示，从而提升任务和模型间的通用性。PROMPTAGATOR[Dai et al., 2022]则利用大语言模型作为少样本查询生成器，基于生成的数据创建针对特定任务的检索器。利用大语言模型的泛化能力，PROMPTAGATOR 使得仅凭几个示例就可以创建专门针对特定任务的端到端检索器。
-
对齐模块： 在 RAG 的应用中，查询与文本之间的对齐一直是影响效果的关键因素。在模块化 RAG 的发展中，研究者们发现，在检索器中添加一个可训练的 Adapter 模块能有效解决对齐问题。例如，PRCA[Yang et al., 2023b]通过强化学习训练了一个由大语言模型奖励驱动的上下文适配器，该适配器位于检索器和生成器之间。通过在标注的自回归策略中的强化学习阶段，它能够优化检索到的信息，实现在强化学习过程中最大化奖励。
AAR[Yu et al., 2023b] 提出了一种通用插件，这种插件能从已知来源的大语言模型 (LLM) 学习到语言模型的偏好，并用这些知识来辅助那些未知或尚未共同微调的大语言模型。
RRR[Ma et al., 2023a] 设计了一个基于强化学习的模块，该模块能够重写查询，使得这些查询更好地与语料库中的文档相匹配。
-
验证模块： 在现实世界中，我们无法总是保证检索到的信息的可靠性。检索到不相关的数据可能会导致大语言模型产生错误信息。因此，可以在检索文档后加入一个额外的验证模块，以评估检索到的文档与查询之间的相关性，这样做可以提升 RAG[Yu et al., 2023a] 的鲁棒性。
新模式 Modular
RAG 的组织方法具有高度灵活性，能够根据特定问题的上下文，对 RAG 流程中的模块进行替换或重新配置。在基础的 Naive RAG 中，包含了检索和生成这两个核心模块（有些文献中称之为阅读或合成模块），这个框架因而具备了高度的适应性和多样性。目前的研究主要围绕两种组织模式：一是增加或替换模块，二是调整模块间的工作流程。
-
增加或替换模块 在增加或替换模块的策略中，我们保留了原有的检索 - 阅读结构，同时加入新模块以增强特定功能。 RRR[Ma et al., 2023a] 提出了一种重写 - 检索 - 阅读的流程，其中利用大语言模型（LLM）的性能作为强化学习中重写模块的奖励机制。这样，重写模块可以调整检索查询，从而提高阅读器在后续任务中的表现。同样地，我们也可以在其他方法中选择性地替换模块，例如在生成 - 阅读[Yu et al., 2022]中，大语言模型的生成模块取代了检索模块。 背诵 - 阅读[Sun et al., 2022] 则是将传统的外部检索转变为从模型权重中检索，首先由大语言模型记忆与任务相关的信息，然后生成处理知识密集型自然语言处理任务所需的输出。
-
调整模块间的工作流程 在调整模块间流程的领域，重点在于加强语言模型与检索模型之间的互动。DSP[Khattab et al., 2022] 引入了展示 - 搜索 - 预测的框架，将上下文学习系统视为一个明确的程序，而不是简单的终端任务提示，以此来应对知识密集型的任务。 ITER-RETGEN[Shao et al., 2023] 则是使用生成内容来指导检索，通过迭代执行“检索增强生成”和“生成增强检索”，形成一种检索 - 阅读 - 检索 - 阅读的工作流。Self-RAG[Asai et al., 2023b] 则采用决策 - 检索 - 反思 - 阅读的流程，引入了一个用于主动判断的模块。这种适应性和多样性的方法使得在 Modular RAG 框架中可以动态地组织各种模块。
3.4 RAG增强路线
要理解 Agentic RAG 和 Graph RAG，最好不要把它们和 Naive RAG / Advanced RAG / Modular RAG 放在同一个分类层级里比较。更准确的理解是：三种 RAG 范式描述的是系统架构演进层级；Graph RAG 描述的是知识如何组织和检索；Agentic RAG 描述的是检索与推理流程由谁来动态决策。
可以用三条轴统一起来：
第一条轴：架构范式轴
Naive RAG → Advanced RAG → Modular RAG
第二条轴：知识组织轴
普通文本块 → 向量索引 → 混合索引 → 图结构 / 知识图谱 → 多模态知识结构
第三条轴：流程控制轴
固定流程 → 条件触发 → 迭代 / 递归 / 自适应 → Agentic 规划与工具调用
Graph RAG 主要属于第二条轴，Agentic RAG 主要属于第三条轴。它们都可以嵌入到 Advanced RAG 或 Modular RAG 中，不是互斥关系。
1. 三种 RAG 范式：回答“系统整体怎么组织？”
三种 RAG 范式是 RAG 架构复杂度的演进路线。
Naive RAG
= 检索 → 拼接上下文 → 生成
Advanced RAG
= 查询优化 → 检索 → 重排 / 过滤 / 压缩 → 生成
Modular RAG
= 多模块路由 + 多数据源 + 多轮检索 + 工具调用 + 动态控制
Naive RAG 是最简单的线性流程：用户提问后，系统直接从向量库中召回 Top-K 文档，再把这些文档拼进 Prompt 里让 LLM 回答。
Advanced RAG 在 Naive RAG 基础上加入了更多优化模块，例如查询重写、查询扩展、元数据过滤、混合检索、重排序、上下文压缩等。材料中也提到，朴素 RAG 直接依赖用户原始查询，而真实问题往往模糊、复杂或表达不佳，因此需要查询扩展、查询重写、HyDE、Step-back Prompting、查询路由等优化方式。
Modular RAG 则进一步把 RAG 拆成多个可组合模块。它不再是固定的“检索一次、生成一次”，而是可以根据任务动态决定用哪个检索器、查哪个数据源、是否继续检索、是否调用工具、是否进行多轮推理。
所以三种范式是一条“系统复杂度主线”。
2. Graph RAG：回答“知识怎么组织和检索？”
Graph RAG 的核心思想是：不要只把知识切成孤立文本块，而是把知识中的实体、概念、事件、关系组织成图结构，再基于图进行检索、推理和生成。
普通向量 RAG 通常长这样：
文档 → 分块 → 向量化 → 相似度检索 → 生成
Graph RAG 更像这样：
文档
→ 抽取实体 / 关系 / 事件
→ 构建知识图谱或文档图
→ 根据问题定位实体和关系
→ 检索相关子图 / 路径 / 社区摘要
→ 与原文证据融合
→ 生成答案
材料中提到，知识图谱索引可以刻画不同概念和实体之间的联系，降低幻觉可能性，并把信息检索过程转换为 LLM 更容易理解的指令，从而提升知识检索准确性和上下文一致性。KGP 这类方法还会用节点表示文档中的段落、页面、表格等结构，用边表示语义相似性或文档结构关系，以解决多文档环境中的知识检索和推理问题。
Graph RAG 适合解决普通向量 RAG 不擅长的问题。
例如，普通向量检索擅长回答：
“什么是 RAG？”
“这份制度里报销流程是什么？”
“这篇文章如何解释 Self-RAG？”
但 Graph RAG 更擅长回答：
“某个项目延期和哪些部门、负责人、风险事件有关？”
“公司 A 收购公司 B 后，哪些产品线受到影响？”
“论文 A、方法 B、数据集 C 之间是什么关系？”
“某个疾病、药物、靶点和副作用之间有什么关联？”
这些问题的重点不是“哪段文本和问题语义相似”，而是“多个实体之间如何连接”。这就是 Graph RAG 的价值。
3. Graph RAG 的关键模块
Graph RAG 通常包含以下几个核心模块。
第一，图构建。
系统需要从原始文档中抽取实体、关系和事件。例如：
原文：
“Self-RAG 引入 reflection tokens，使模型能够决定何时检索以及如何批判生成结果。”
可抽取为：
实体：Self-RAG、reflection tokens、模型、检索、批判
关系：
Self-RAG → 引入 → reflection tokens
reflection tokens → 控制 → 检索时机
reflection tokens → 支持 → 生成批判
这些实体和关系会被写入图数据库或图索引中。
第二，图检索。
当用户提问时，系统不是只做向量相似度，而是先识别问题中的关键实体，再沿着图结构查找相关节点、边、路径或子图。
例如：
问题：
“Self-RAG 和 Flare 都属于什么类型的 RAG 优化？区别是什么？”
Graph RAG 可能检索到：
Self-RAG → 属于 → 自适应检索
Flare → 属于 → 自适应检索
Flare → 通过 → 生成概率阈值触发检索
Self-RAG → 通过 → reflection token 控制检索和批判
这样生成器得到的不是一堆松散文本，而是结构化证据链。
第三，图推理。
Graph RAG 可以通过路径、多跳关系和子图做推理。例如：
A 方法使用了 B 技术
B 技术属于 C 类优化
C 类优化解决 D 问题
因此：
A 方法主要用于解决 D 问题
材料中也提到，多跳检索通常用于深入图结构数据源，抽取相互关联的信息；而知识图谱上的检索粒度可以是实体、三元组和子图。
第四，图证据与文本证据融合。
Graph RAG 不一定只用图。更常见的工程方案是：
图检索：找实体关系和推理路径
向量检索：找原文证据
BM25：找关键词、专有名词、编号
Rerank：统一重排
LLM：综合生成答案
所以 Graph RAG 往往不是替代向量 RAG，而是增强向量 RAG。
4. Graph RAG 和三种 RAG 范式的关系
Graph RAG 可以嵌入不同层级的 RAG 范式中。
Naive Graph RAG：
问题 → 图数据库查询 → 拼接图结果 → LLM 生成
这是最简单的形式。系统只是把知识图谱当作外部知识源，用图查询替代普通向量检索。
Advanced Graph RAG：
问题
→ 实体识别 / 查询改写
→ 图检索 + 向量检索
→ 子图筛选 / 路径重排 / 文本重排
→ 上下文压缩
→ LLM 生成
这个版本已经加入查询优化、混合检索、重排序、上下文整理等模块，因此属于 Advanced RAG。
Modular Graph RAG：
问题
→ 路由器判断问题类型
→ 如果是实体关系问题，走图检索
→ 如果是语义问答，走向量检索
→ 如果是精确编号，走 BM25 / SQL
→ 多源证据融合
→ 多轮推理
→ 生成并校验
这个版本已经具备模块路由、多数据源、多流程组合，所以属于 Modular RAG。
因此，Graph RAG 不是第四种 RAG 范式，而是可以嵌入 Advanced RAG 或 Modular RAG 的一种 知识组织与检索增强路线。
5. Agentic RAG：回答“流程由谁来决策？”
Agentic RAG 的核心思想是：让 LLM 不再只是被动接收检索结果，而是像 Agent 一样主动规划、检索、判断、调用工具、反思和修正。
普通 RAG 是固定流程：
用户问题 → 检索 → 生成
Agentic RAG 是动态流程：
用户问题
→ Agent 分析任务
→ 判断是否需要检索
→ 决定检索什么
→ 选择工具或数据源
→ 获取证据
→ 判断证据是否足够
→ 不够则继续检索或改写查询
→ 生成答案
→ 自我检查
→ 输出最终结果
材料中提到，自适应检索方法如 Flare 和 Self-RAG，会让 LLM 主动确定最佳检索时机和检索内容，从而提高信息获取效率和相关性。Graph-Toolformer、AutoGPT、Toolformer 等也体现了 LLM 在运行中主动判断和调用工具的趋势。
所以 Agentic RAG 可以看作是自适应检索的进一步工程化和系统化。
6. Agentic RAG 的关键模块
Agentic RAG 通常由以下模块组成。
第一，任务规划器。
Planner 负责理解用户问题，并决定解决问题需要哪些步骤。
例如用户问：
“帮我分析这个行业未来三年的机会，并结合最近政策变化给出建议。”
普通 RAG 可能直接检索几篇文档然后回答。
Agentic RAG 会先拆解任务：
1. 明确行业范围
2. 检索市场规模数据
3. 检索政策变化
4. 检索竞争格局
5. 综合机会与风险
6. 生成建议
第二，查询生成与改写。
Agent 不一定直接使用用户原始问题，而是会生成更适合检索的查询。
例如：
用户问题：
“Agentic RAG 和 Graph RAG 有啥区别？”
Agent 可能生成：
- Agentic RAG definition
- Graph RAG definition
- Agentic RAG workflow
- Graph RAG knowledge graph retrieval
- Agentic RAG vs Graph RAG
这与 Advanced RAG 中的查询扩展、查询重写是一致的，只是 Agentic RAG 会把它变成动态决策过程。
第三，工具选择。
Agentic RAG 的重点之一是工具路由。它可以根据任务选择不同工具：
事实查询 → 向量库 / 搜索引擎
关系推理 → 图数据库
结构化数据 → SQL
实时信息 → Web Search
代码问题 → 代码检索器
数学计算 → Calculator
企业系统 → API
这也是为什么 Agentic RAG 通常天然属于 Modular RAG：它需要多个模块和工具协同。
第四，证据评估。
Agent 不只是检索，还会判断检索结果是否足够回答问题。
例如：
证据是否相关？
证据是否冲突？
是否缺少时间信息？
是否需要更多来源？
是否可以生成最终答案？
这一步能减少“检索到一点东西就硬答”的问题。
第五，迭代检索。
如果证据不足，Agent 会继续检索。材料中提到，迭代检索会基于初始查询和目前已生成文本反复搜索知识库，为 LLM 提供更全面的知识基础；ITER-RETGEN 则结合“检索增强生成”和“生成增强检索”，让生成内容反过来成为下一轮检索的上下文。
这正是 Agentic RAG 常用的机制。
第六，自我反思与答案修正。
Self-RAG 引入了 “retrieve” 和 “critic” 两类 reflection token，使模型能够决定何时检索，以及如何批判自己的输出。材料中也提到，Self-RAG 不需要额外分类器或 NLI 模型，而是通过反思 token 简化检索触发决策，并提升模型自主判断能力。
这说明 Agentic RAG 不只是“会调用检索器”，而是能在生成过程中进行检查和修正。
7. Agentic RAG 和三种 RAG 范式的关系
Agentic RAG 通常不属于 Naive RAG，因为 Naive RAG 是固定线性流程，不具备主动规划和动态工具调用能力。
它可以出现在 Advanced RAG 的后期形态中，例如：
问题
→ LLM 判断是否需要检索
→ 查询重写
→ 检索
→ 判断结果是否够用
→ 生成
但更典型地，Agentic RAG 属于 Modular RAG，因为它需要多个模块动态组合：
Planner
→ Router
→ Query Rewriter
→ Retriever
→ Tool Caller
→ Reranker
→ Verifier
→ Generator
→ Critic
也就是说：
Agentic RAG ≈ Modular RAG 在流程控制轴上的高级形态
它强调的不是“用什么知识结构”，而是“让谁来控制 RAG 流程”。
8. Graph RAG 和 Agentic RAG 的核心区别
| 维度 | Graph RAG | Agentic RAG |
|---|---|---|
| 解决的问题 | 知识如何组织、关联和检索 | 检索与推理流程如何动态决策 |
| 所在轴 | 知识组织轴 | 流程控制轴 |
| 核心对象 | 实体、关系、图谱、子图、路径 | Agent、Planner、Tool、Critic、Memory |
| 擅长场景 | 多实体、多关系、多跳推理、全局知识组织 | 复杂任务、多步推理、多工具调用、动态检索 |
| 关键能力 | 图构建、图检索、子图推理、证据链 | 任务拆解、工具选择、反思、循环检索 |
| 与三范式关系 | 常见于 Advanced / Modular RAG | 主要属于 Modular RAG |
| 是否必须用知识图谱 | 是，或至少使用图结构索引 | 不一定 |
| 是否必须用 Agent | 不一定 | 是 |
一句话区分：
Graph RAG 关心“知识之间有什么关系”。
Agentic RAG 关心“模型应该怎样一步步找答案”。
9. 二者可以组合：Agentic Graph RAG
Graph RAG 和 Agentic RAG 不是互斥关系，它们非常适合组合。
组合后可以形成：
Agentic Graph RAG
= Agentic RAG 的动态决策能力
+ Graph RAG 的关系检索和多跳推理能力
典型流程如下：
用户提出复杂问题
→ Agent 判断这是一个多实体关系问题
→ 抽取问题中的核心实体
→ 查询知识图谱，找到相关子图
→ 如果子图证据不够，继续检索原始文档
→ 如果涉及结构化数据，调用 SQL
→ 如果涉及最新信息，调用 Web Search
→ 对图证据、文本证据、结构化数据进行融合
→ 检查是否存在冲突或缺失
→ 生成带证据链的答案
举个例子：
问题：
“某公司最近的战略调整会如何影响它的供应链风险？”
普通 RAG 可能只是检索几段相关新闻。
Graph RAG 会关注：
公司 → 供应商 → 地区 → 产品线 → 风险事件 → 政策因素
Agentic RAG 会进一步决定：
1. 先查公司战略变化
2. 再查供应商关系图
3. 再查受影响产品线
4. 再查相关政策和风险事件
5. 如果证据不足，继续检索
6. 最后综合判断
组合后，系统既有图结构的“关系理解能力”，也有 Agent 的“动态推理能力”。
10. 放到完整 RAG 增强路线中
可以这样把它们放进学习框架：
RAG 增强路线
├── 架构范式轴
│ ├── Naive RAG
│ ├── Advanced RAG
│ └── Modular RAG
│
├── 知识组织轴
│ ├── 文本块 RAG
│ ├── Hybrid RAG
│ ├── Metadata-aware RAG
│ ├── Graph RAG
│ └── Multimodal RAG
│
└── 流程控制轴
├── Fixed RAG
├── Iterative RAG
├── Recursive RAG
├── Adaptive RAG
└── Agentic RAG
它们之间的组合关系可以表示为：
Naive RAG
= 固定流程 + 文本块检索
Advanced RAG
= 查询优化 + 混合检索 + 重排压缩
Graph RAG
= 图结构知识组织 + 子图 / 路径 / 多跳检索
Agentic RAG
= Agent 主动规划 + 工具调用 + 反思 + 迭代检索
Agentic Graph RAG
= Agentic 流程控制 + Graph 知识组织 + Modular RAG 架构
最终可以归纳为：
三种 RAG 范式：定义系统复杂度
Graph RAG：增强知识结构
Agentic RAG：增强流程控制
Agentic Graph RAG：两者组合后的高级 Modular RAG
所以，在你的 RAG 知识体系中，建议这样记：
Naive / Advanced / Modular RAG 是主干。
Graph RAG 是知识组织分支。
Agentic RAG 是流程控制分支。
二者可以合并成 Agentic Graph RAG，通常属于 Modular RAG 的高级形态。
4 检索器
在 RAG（Retrieval-Augmented Generation）中，“R”代表检索。检索器的任务是从外部知识库、文档集合、结构化数据库或模型生成内容中，找到与用户问题最相关的前 K 个信息片段，并将其提供给后续生成器使用。
高质量检索器需要解决三个核心问题：
- 如何获得准确的语义表示；
- 如何让查询与文档处于可匹配的语义空间；
- 如何让检索结果更符合大语言模型的生成偏好。
检索质量直接决定 RAG 系统的上限。如果检索不到正确内容，生成器即使能力很强，也容易出现幻觉、遗漏或答非所问。
4.1 如何获得准确的语义表示？
在 RAG 中，查询和文档都会被映射到某个语义空间中。检索过程本质上是在这个空间中计算查询与文档片段之间的相似度，例如通过余弦相似度寻找最相关的文本块。因此，语义表示是否准确，是 RAG 检索效果的基础。
块优化。
处理外部文档的第一步通常是分块（Chunking）。文档会被切分成更小的文本单元，再通过嵌入模型转换为向量。块太大，容易引入无关信息，增加噪声和成本；块太小，又可能破坏语义完整性，导致检索结果缺少必要上下文。因此，分块策略需要根据文档类型、嵌入模型、问题复杂度和生成器上下文窗口综合选择。
常见分块方式包括固定 Token 分块、递归切分、滑动窗口、句子级切分、段落级切分、命题级切分和文档级切分。固定 Token 分块简单稳定，例如按 100、256、512 Token 切分；滑动窗口可以保留相邻块之间的上下文连续性；Small2Big 方法则先用小块检索，再把相关小块周围更大的上下文交给 LLM，从而兼顾检索精度和语义完整性。
除文本外，检索粒度还会随着数据类型变化。在知识图谱中，粒度可以是实体、三元组或子图；在推荐任务中，粒度可以是 Item ID；在复杂问答中，粒度甚至可以是命题，即一个自包含的原子事实。没有绝对最优的分块策略，只有最适合当前数据和任务的策略。
索引优化。
索引阶段会将文档处理、切分、嵌入并存储到向量数据库中。索引质量决定检索阶段能否获得正确上下文。除了基础分块，还可以通过元数据和结构化索引进一步优化。
元数据可以包括文件名、页码、作者、类别、时间戳、章节、权限、来源等。检索时可以先基于元数据过滤，缩小搜索范围。例如，在企业知识库中，可以先限定“产品文档”“最近一年”“某业务线”后再进行向量检索。时间戳还可以用于时间感知 RAG，使系统优先检索更新的知识，减少使用过时信息的风险。
结构化索引则通过层级结构或知识图谱组织文档。层级索引可以将文件、章节、段落、块建立父子关系，使系统先定位相关章节，再进入局部精细检索。知识图谱索引则通过实体和关系组织知识，适合多跳推理和复杂关联查询。例如，当问题需要同时理解“人物—机构—事件—时间”的关系时，图索引通常比单纯向量检索更稳定。
微调嵌入模型。
分块之后，需要使用嵌入模型将查询和文档块映射到语义空间。通用嵌入模型虽然在大规模语料上训练过，但在医疗、法律、金融、代码、企业内部知识等专业场景中，可能无法准确理解领域术语和任务意图。因此，针对领域语料和下游任务微调嵌入模型是提升检索质量的重要手段。
嵌入模型微调通常需要构造“查询—语料库—相关文档”的训练数据。模型根据查询检索候选文档，再通过相关文档是否命中来优化表示能力。领域知识微调让模型理解专业概念；任务微调则让模型更符合具体检索目标，例如问答、摘要、信息抽取或代码搜索。
混合检索。
仅依赖向量检索并不总是最优。稀疏检索方法，如 BM25，擅长处理关键词、稀有实体、编号、专有名词；密集检索方法擅长捕捉语义相似性。混合检索将二者结合，可以同时利用关键词匹配和语义匹配的优势。例如，用户查询中包含产品型号、法律条款编号或函数名时，BM25 往往能提供强召回；而当用户用自然语言描述意图时，向量检索更有优势。
4.2 如何协调查询和文档的语义空间？
用户原始查询往往并不适合直接检索。它可能过短、含糊、口语化、缺少背景信息，或包含多义词和缩写。例如，法律语境中的“LLM”可能指“法学硕士”，AI 语境中则指“大语言模型”。因此，RAG 系统需要对查询进行优化，使其更容易与文档空间匹配。
查询重写。
查询重写是最直接的查询优化方法。它会将用户原始问题改写为更清晰、更适合检索的表达。例如，用户问“这个怎么报销？”，系统可以结合上下文改写为“公司差旅费用报销流程、所需材料和审批步骤是什么？”这样可以显著提高召回质量。
Query2Doc、HyDE、RRR、Step-back Prompting 等方法都属于查询转换或查询重写范畴。HyDE 会让 LLM 先生成一个假想答案或假想文档，再用这个假想文档进行向量检索，其核心思想是用“答案式表达”缩小问题与文档之间的语义差距。Step-back Prompting 则会把具体问题抽象成更高层的问题，先检索原则性知识，再结合原问题生成答案。
查询扩展。
查询扩展会把一个查询扩展成多个查询，以覆盖更多可能的表达方式。多查询检索适合复杂问题或表达不确定的问题。例如，用户问“RAG 怎么优化检索效果？”，系统可以扩展为“RAG 分块策略”“RAG 查询重写”“RAG 重排序”“RAG 混合检索”“RAG 嵌入模型微调”等多个查询并行检索。
对于复杂问题，还可以使用子查询分解。系统先把原问题拆成多个子问题，分别检索，再综合答案。例如，“比较 RAG、微调和长上下文在企业知识库中的适用场景”可以拆成“RAG 的优势”“微调的优势”“长上下文的优势”“企业知识库的约束条件”等子问题。
查询路由。
查询路由指根据问题类型，将请求分配到不同的数据源、索引或 RAG 流水线。例如，产品问题路由到产品文档，财务问题路由到报销制度，代码问题路由到代码仓库，实时问题路由到搜索引擎。路由方式可以基于元数据、关键词、语义分类或混合策略。
元数据路由器通常先从查询中抽取实体、时间、类别等信息，再基于文档元数据过滤；语义路由器则根据查询意图选择最合适的检索路径。通用 RAG 系统往往需要查询路由，否则所有问题都走同一套检索流程，容易造成召回范围过大、噪声过多和响应成本过高。
嵌入变换。
除了改写查询本身，也可以对查询向量进行变换。例如，在查询编码器后增加适配器，使查询嵌入更贴合特定任务。对于结构化和非结构化数据混合的场景，嵌入变换尤其重要。SANTA 等方法通过结构化数据与非结构化描述之间的对齐训练，使检索器更好地理解表格、实体和文本之间的关系。
4.3 调整检索器结果以适应大语言模型的需求
检索器找到“相关文档”并不等于这些文档一定适合 LLM 使用。传统检索指标关注相关性，但 LLM 更关心信息是否完整、可读、可引用、无冲突、位置合理，以及是否能直接支持生成答案。因此，需要让检索器输出更符合生成器偏好。
LLM 监督下的训练。
一种方法是利用 LLM 的反馈信号训练检索器。检索器不只学习“哪些文档与查询相似”，还学习“哪些文档能帮助 LLM 生成正确答案”。例如，AAR、REPLUG、RA-DIT 等方法会借助语言模型的打分、交叉注意力分数、生成概率或 KL 散度等信号，对检索器进行监督训练，使检索结果更贴近生成器需求。
这种方法的优势是能够直接优化最终问答表现，而不是只优化检索相似度。它的局限是训练成本更高，并且可能依赖特定 LLM 的偏好。
插入适配器。
当无法微调嵌入模型或 LLM 时，可以在检索器与生成器之间插入适配器。适配器负责将检索结果转换为 LLM 更容易利用的形式，例如筛选关键信息、压缩上下文、重排段落、生成摘要或动态选择文档。PRCA、RECOMP、BGM、PKG 等方法都体现了这种思路。
适配器的工程意义很强：在企业场景中，很多模型通过 API 使用，无法直接微调；此时通过外部适配器对检索结果进行整理，往往比训练整个系统更现实。
4.4 如何通过后检索处理提升检索结果？（偏向检索与生成的中间层）
后检索处理指的是，在检索器召回候选文档之后，对这些文档进行二次加工，再交给生成器。它的目标是降低噪声、控制上下文长度、突出关键信息，并提升最终生成质量。
常见后检索处理包括重排序、过滤、上下文选择、上下文压缩和摘要。
文档重排。
重排序的目标是重新排列检索到的文档块，让最相关、最有用的信息出现在更容易被 LLM 注意到的位置。由于 LLM 通常更关注上下文开头和结尾，而容易忽略中间内容，因此将关键证据放在前部或前后边缘，可以提升生成质量。
重排序方法可以分为规则型和模型型。规则型方法依赖相关性、多样性、MRR 等指标；模型型方法可以使用 BERT 系列、Cross-Encoder、Cohere rerank、bge-reranker-large 或 GPT 类模型对候选文档重新评分。重排序不仅是“重新排顺序”，也常常承担过滤器角色，即减少低质量或低相关文档进入最终上下文。
上下文选择与压缩。
一个常见误区是认为检索越多越好。实际上，过多上下文会引入噪声，增加推理成本，并降低模型对关键证据的感知。上下文压缩的目标是保留与问题强相关的信息，删除冗余、无关或重复内容。
LLMLingua 和 LongLLMLingua 通过小模型识别并删除不重要 Token，将长提示压缩为 LLM 仍能理解的形式。PRCA 通过训练信息抽取器提取精简上下文；RECOMP 使用对比学习训练信息凝缩器，将多文档内容压缩成与查询相关的摘要。
除压缩单个文档外，还可以减少文档数量。Filter-Reranker 范式用小语言模型先过滤，再由大语言模型对困难样本进行重排。Chatlaw 等方法还会让 LLM 在生成前评估检索内容的相关性，通过自我批判过滤掉不可靠或不相关的引用。
过滤。
过滤是后检索处理中非常实用的一环。它可以基于元数据、相关性阈值、时间、权限、来源可信度、重复度和冲突程度筛选文档。比如在企业知识库中，过期制度、无权限文档和重复版本应在生成前被过滤，否则模型可能生成错误答案或泄露不该使用的信息。
5 生成组件
在 RAG 系统中，生成组件负责将检索到的信息转化为自然、准确、符合用户需求的回答。与普通生成式模型不同，RAG 的生成器不仅依赖参数化知识，还会利用检索器提供的外部上下文。
生成阶段的关键挑战是：检索内容可能过多、冗余、冲突或位置不合理；生成器可能忽略中间信息，出现“Lost in the middle”问题；不同格式的数据，如文本、表格、知识图谱，也会影响模型理解。因此，生成前通常需要进行上下文整理，并在必要时对 LLM 进行微调或对齐。
5.1. 上下文组织与 Prompt 构造
这部分虽然和后检索处理相邻，但重点不是“检索结果是否相关”，而是 如何把检索结果组织成 LLM 最容易理解、最不容易幻觉的输入。
例如：
用户问题：RAG 中重排序有什么作用？原始上下文：[doc3] ...[doc1] ...[doc7] ...优化后上下文：任务：仅基于以下材料回答。证据1：重排序用于重新排列文档块，使最相关结果优先出现。证据2：重排序还能减少整体文档池，承担增强器和过滤器作用。要求：回答时先给结论，再解释原因。
这一层的优化点包括：
- 证据排序：重要证据放前面或结尾，避免 Lost in the middle；
- 证据分组：按主题、时间、来源、观点分组；
- 引用标记：给每段证据加编号，方便生成时引用；
- 指令约束：要求“只基于上下文回答”“缺少证据时说明不知道”；
- 输出格式约束：要求按结论、依据、步骤、风险提示等结构输出。
它不是检索器本身，但也不是 LLM 微调，而是 生成输入工程。
5.2. 生成器对检索内容的利用能力
RAG 生成器的核心难点不是“会不会写”，而是 能不能正确使用检索内容。
普通 LLM 生成任务通常只输入一个问题；RAG 生成任务还会输入多篇文档、表格、结构化数据或多源证据。片段1也提到，RAG 的输入不仅包括查询，还包括检索器找到的多种文档，因此需要优化生成器，使其更好地利用这些文档。
这里可以补充：
- 证据选择能力：从多个片段中识别真正支持答案的内容；
- 证据整合能力：把分散在多个文档中的信息合并成完整答案；
- 冲突处理能力：当不同文档说法不一致时，指出差异而不是强行合并；
- 忠实生成能力：答案必须能被上下文支持，不能自由发挥；
- 不确定性表达能力：证据不足时能拒答或保守回答。
例如，好的 RAG 生成器不只是回答：
重排序可以提升 RAG 效果。
而应该回答：
重排序的作用是重新排列检索到的文档块，把最相关的信息放到更容易被 LLM 注意的位置，同时过滤掉低相关内容，从而减少上下文噪声并提升最终回答质量。
这才体现了生成器对检索内容的“吸收、整合和表达”。
5.3. 生成过程控制
生成组件还应包括 生成过程本身怎么被控制，而不只是训练模型。
常见优化包括：
- 分步生成：先分析问题，再组织证据，最后生成答案；
- 先生成草稿，再校验，再修正；
- 对复杂问题使用 CoT / 分解推理；
- 对多跳问题交替执行“生成中间结论 → 再检索 → 再生成”；
- 对低置信度内容触发补充检索；
- 限制输出长度、语气、格式、引用方式。
这部分和第 6 章的“增强过程”有交叉，比如迭代检索、递归检索、自适应检索，但从生成角度看，它们也可以理解为 生成过程编排。
比如：
一次性生成：问题 → 检索 → 生成答案过程控制后：问题 → 拆解子问题 → 分别检索 → 生成中间结论 → 汇总 → 校验 → 输出最终答案
后一种明显更适合复杂问答。
5.4. 事实一致性与幻觉抑制
这是生成组件非常核心的一块，上一版没有单独突出。
RAG 的目标不是让答案更长，而是让答案 更可信、更可追溯、更少幻觉。因此，生成阶段需要约束模型：
- 不能使用上下文之外的 unsupported claims；
- 每个关键结论最好能对应证据；
- 找不到答案时要拒答；
- 对冲突信息要说明冲突；
- 对推测性内容要明确标注“可能”“根据现有资料无法确认”。
可以加入一种“生成后验证”机制：
第一步：生成答案第二步：逐条检查答案中的事实是否被检索上下文支持第三步：删除无依据内容或补充免责声明第四步：输出最终答案
这部分严格属于生成侧，因为它处理的是 答案是否忠实于证据。
5.5. 输出格式与任务适配
不同任务对生成结果的要求不同。问答、摘要、法律咨询、代码解释、医学辅助、企业制度查询，生成格式都不一样。
因此生成组件还要优化：
- 答案结构；
- 引用格式；
- 解释深度；
- 专业术语使用；
- 是否给出步骤；
- 是否给出风险提示；
- 是否输出 JSON、表格、Markdown、SQL、代码等特定格式。
例如企业知识库 RAG 通常需要：
结论：依据：适用范围：例外情况：引用来源：无法确认的信息：
而代码 RAG 可能需要：
问题原因：相关代码位置：修改方案：修改后代码：测试建议：
这不是检索器能解决的，而是典型的生成侧优化。
5.6. LLM 微调与偏好对齐
这才是片段中第二部分提到的核心内容。片段1提到，生成器可以通过输入输出对训练，让模型学会基于查询和检索文档生成答案，也提到联合编码器、双编码器、负对数似然损失、对比学习等方式。
片段2也提到，LLM 微调可以让模型适配特定数据格式、生成特定风格答案，并可以通过强化学习或蒸馏对齐人类偏好、检索器偏好或更强模型的能力。
这一部分可以细分为：
- SFT：用“问题 + 检索文档 → 标准答案”训练模型；
- 对比学习：让模型区分好证据和坏证据；
- 偏好对齐：让模型生成更符合人类或任务要求的答案；
- 蒸馏：用 GPT-4 等强模型生成训练样本，训练较小模型；
- 结构化数据适配：让模型学会理解表格、知识图谱、实体关系；
- 风格微调：让模型按企业、法律、客服、教学等风格回答。
5.7 如何优化生成器应对输入数据？
RAG 生成器的输入比普通 LLM 更复杂。它不仅包含用户查询，还包含来自不同来源、不同格式、不同粒度的检索文档。因此，优化生成器的核心，是让它更好地理解、利用和忠实表达检索内容。
通用优化过程。
生成器训练通常基于输入输出对：输入包括查询和检索文档，输出是目标答案。Self-Mem 等方法会从记忆池中选择相关内容，与原始输入一起送入生成器，使模型学会利用外部记忆生成回答。
常见架构包括联合编码器和双编码器。联合编码器会把查询和文档拼接后统一编码，再由解码器生成答案；双编码器则分别编码查询和文档，再通过交叉注意力融合信息。前者建模充分但成本更高，后者结构更灵活，更适合大规模检索场景。
对比学习。
对比学习可以帮助模型区分有用上下文和无用上下文。它通过构造正样本和负样本，让模型学习哪些检索结果真正支持答案生成。SURGE 使用图文对比学习，使生成内容更忠实于知识图谱中检索到的子图；SANTA 则通过结构化数据和非结构化描述之间的对比学习，对齐表格、实体和文本语义。
对比学习的价值在于，它不仅训练模型“生成正确答案”，还训练模型“理解哪些证据支撑答案”。这对减少幻觉、提升可解释性和增强结构化数据理解都有帮助。
LLM 微调。
在特定领域或特定输出风格要求下，可以对 LLM 进行微调。例如，让模型更好地处理法律条文、医疗文献、企业制度、财务报表、代码库或知识图谱。微调还可以规范输出格式，例如要求模型按“结论—依据—引用—风险提示”的结构回答。
LLM 微调也可以与检索器微调协同进行。RA-DIT 等方法尝试同时对齐检索器和生成器，使检索评分与生成质量更一致。除此之外，还可以通过强化学习让模型输出更符合人类偏好、检索器偏好或事实一致性要求。
6 RAG 技术的增强手段
RAG 的增强手段可以从三个角度理解：增强发生在哪个阶段、增强使用什么数据源，以及增强过程如何组织。
从阶段看，RAG 可以用于预训练、微调和推理；从数据源看，RAG 可以使用非结构化文本、半结构化数据、结构化数据和 LLM 生成内容；从过程看，RAG 可以采用一次检索、迭代检索、递归检索和自适应检索。
6.1 RAG 在各个增强阶段的应用
预训练阶段。
在预训练阶段引入检索，目标是让模型在学习语言能力的同时，能够利用外部知识。REALM 将预训练和检索结合起来，把掩码语言建模视为“先检索再预测”的过程。RETRO 则在自回归语言模型中加入检索机制，通过从大规模数据库中检索相关片段，减少模型对参数规模的依赖。
预训练阶段 RAG 的优势是模型与检索机制融合更深，知识利用更自然；缺点是训练成本高、数据要求高、更新慢。虽然更新检索库可以部分缓解知识过时问题，但整体预训练仍然资源密集。
微调阶段。
微调阶段的增强主要用于让检索器和生成器适配特定任务。REPLUG 将语言模型视为黑盒，通过语言模型反馈优化检索器；UPRISE 训练轻量提示检索器，使模型能为零样本任务自动检索合适提示；Self-RAG 通过反思 Token 控制是否需要检索；RA-DIT 同时优化检索器和生成器，使二者偏好更一致。
微调阶段的优势是灵活，可以单独微调检索器、生成器或二者联合微调；也可以针对特定领域、任务和数据格式优化。缺点是需要专门构造训练数据，并消耗更多计算资源。
推理阶段。
推理阶段是当前 RAG 最常见的应用方式，即模型参数不变，只在回答时动态检索外部知识。Naive RAG 就属于这种形式：先检索，再把检索结果拼接到 Prompt 中生成答案。
推理阶段增强的优势是轻量、快速、无需训练，适合工程落地。它可以结合查询重写、重排序、上下文压缩、CoT、多轮检索和工具调用等方法提升效果。缺点是系统效果依赖基础模型能力、检索质量和上下文组织方式；如果检索结果错误，生成器也可能被误导。
6.2 数据增强来源
非结构化数据。
非结构化文本是最常见的 RAG 数据来源，包括 Wikipedia、网页、文档、论文、产品手册、法律条文、医疗资料、企业知识库等。它的优势是来源广、覆盖面大、易于切分和嵌入；缺点是信息可能重复、过时、冲突，且缺少显式结构。
对于开放域问答，Wikipedia Dump 是常用数据源；对于企业应用，内部文档、FAQ、工单、会议纪要和业务知识库更常见。非结构化数据通常需要经过清洗、分块、去重、元数据标注和索引构建。
半结构化数据。
半结构化数据通常同时包含文本和表格，例如 PDF、网页表格、报告、财报和说明书。传统 RAG 处理半结构化数据存在挑战：文本切分可能破坏表格结构，表格内容也难以直接通过语义相似度检索。
处理方式包括将表格转换为文本描述、使用 Text-to-SQL 查询结构化表格，或使用专门的文档解析模型保留版面、表格、标题和层级关系。半结构化数据是企业 RAG 中非常重要但仍较难处理的部分。
结构化数据。
结构化数据包括数据库、知识图谱、表格和业务系统中的实体关系。它通常经过验证，信息精确，适合需要严谨事实和多跳推理的场景。知识图谱可以通过实体、关系和子图帮助模型理解复杂关联，降低幻觉风险。
结构化数据的缺点是构建、维护和更新成本较高。它更适合高价值、强约束、长期稳定的知识场景，如法律、金融、医疗、供应链和企业主数据。
LLM 生成内容。
除外部数据外，RAG 也可以利用 LLM 自身生成的内容。GenRead 用 LLM 生成上下文替代传统检索器；Self-Mem 通过迭代生成和记忆选择构建无界记忆池；SKR 会判断问题属于已知还是未知，再决定是否启用外部检索。
这类方法的价值在于，当外部知识不足或检索成本较高时，可以挖掘模型内部知识。但它也更容易引入幻觉，因此通常需要与事实校验、外部检索或自我批判机制结合。
6.3 增强过程
标准 RAG 通常是“一次检索—一次生成”。但对于复杂问题，单次检索往往不够，因为用户问题可能需要多步推理、多个信息源或动态补充上下文。因此，增强过程可以进一步发展为迭代检索、递归检索和自适应检索。
迭代检索。
迭代检索会在生成过程中多次检索。系统先根据初始查询检索一批信息，生成中间答案或推理步骤，再根据当前生成内容继续检索。ITER-RETGEN 将“检索增强生成”和“生成增强检索”结合起来，使生成结果反过来帮助下一轮检索。
迭代检索适合多步问答、复杂分析和需要逐步补充证据的任务。它的风险是多轮检索可能累积无关信息，导致语义漂移，因此需要过滤、重排序和停止条件。
递归检索。
递归检索强调逐步细化查询和搜索范围。系统会根据已有检索结果继续拆解问题、优化查询，并深入更具体的文档或子结构。例如，先检索一本长 PDF 的章节摘要，再进入相关章节内部检索具体段落。
IRCoT 将思维链与检索结合，用推理步骤引导检索，再用检索结果修正推理；ToC 通过构建澄清树逐步处理模糊问题。递归检索特别适合长文档、多跳推理和需求不清晰的复杂搜索。
自适应检索。
自适应检索让模型自己判断是否需要检索、何时检索、检索什么以及何时停止。Self-RAG 引入反思 Token，让模型决定是否激活检索以及如何批判生成内容；Flare 根据生成过程中 Token 概率判断模型置信度，当置信度较低时触发检索；WebGPT 则通过强化学习训练模型使用搜索引擎、浏览结果并引用来源。
自适应检索接近 Agent 使用工具的模式。它不再把检索视为固定流程，而是把检索作为模型在推理过程中可调用的能力。
7 RAG 评估
RAG 评估不能只看最终答案是否正确，还要分别评估检索、上下文、生成和端到端效果。一个 RAG 系统可能答案看似流畅，但引用错误；也可能检索结果正确，但生成器没有利用；还可能短期表现好，但面对噪声、冲突或过期知识时不稳定。
7.1 评估方法
独立评估。
独立评估会分别评估检索器和生成器。检索器常用指标包括 Recall@K、Precision@K、MRR、NDCG、Hit Rate 等，用于衡量正确文档是否被召回以及排序是否合理。生成器则可以评估答案准确性、事实一致性、流畅度、完整性和引用正确性。
独立评估的优势是能定位问题。例如，如果正确文档没有被召回，问题在检索；如果正确文档被召回但答案错误，问题可能在上下文组织或生成器。
端到端评估。
端到端评估关注最终用户看到的答案质量。它衡量整个系统从查询、检索、重排、压缩到生成的整体表现。端到端评估更贴近真实应用，但问题定位不如独立评估清晰。
实际工程中，最好同时使用两类评估：先用独立评估定位模块瓶颈，再用端到端评估判断用户体验。
7.2 关键指标和能力
关键指标。
RAG 评估的核心指标包括：
- 上下文相关性：检索内容是否与问题相关；
- 上下文召回率：回答所需证据是否被检索到；
- 答案忠实性：答案是否由检索内容支持；
- 答案相关性：答案是否直接回应用户问题；
- 引用准确性：引用是否对应真实来源；
- 噪声鲁棒性：面对无关、重复或冲突文档时是否稳定；
- 事实一致性：答案是否避免编造；
- 时效性：是否使用最新、有效的知识。
关键能力。
RAG 系统应具备四类能力。
第一是噪声鲁棒性。系统需要在检索结果包含无关文档时仍能抓住关键证据。第二是负拒答能力。当知识库中没有答案时，系统应明确说明不知道，而不是编造。第三是信息整合能力。当答案分散在多个文档中时，系统应能综合多源证据。第四是反事实抵抗能力。当检索结果中存在错误或冲突内容时，系统应能识别风险并给出谨慎回答。
7.3 评估框架
RAGAS。
RAGAS 是常见的 RAG 自动评估框架，重点评估上下文相关性、答案忠实性、答案相关性和上下文召回率。它适合在缺少人工标注答案时快速评估 RAG 系统表现。
其基本思路是：用 LLM 判断检索上下文是否支持答案、答案是否回答问题、答案是否存在无依据内容。RAGAS 的优势是上手快、工程友好；局限是评估本身依赖 LLM，可能受到评估模型偏差影响。
ARES。
ARES 也是面向 RAG 的评估框架，强调通过自动化评估和少量人工标注结合，判断系统在不同任务中的表现。它适合构建更稳定的评测流程，尤其适合需要持续迭代的生产级 RAG 系统。
在实际应用中，RAGAS、ARES、人工评审、线上反馈、日志分析和 A/B 测试通常需要结合使用。单一指标无法完整反映 RAG 系统质量。
8 未来展望
RAG 已经成为大模型应用中的核心技术之一，但仍有许多值得深入研究和工程优化的问题。未来方向主要包括长上下文与 RAG 的关系、鲁棒性、RAG 与微调结合、生产化、多模态扩展和生态完善。
8.1 RAG 的垂直优化
RAG 与长上下文。
随着 LLM 上下文窗口不断扩大，一个自然问题是：当模型可以一次性读入大量文本时，RAG 是否仍然必要？答案是仍然必要。长上下文可以提升模型处理大材料的能力，但直接塞入全部文档会带来高成本、低效率和可解释性不足。RAG 的优势在于按需检索，只把最相关的信息交给模型，并保留可追溯引用。
未来更可能出现的是“长上下文 + RAG”的混合形态：RAG 负责定位和筛选，长上下文负责综合和推理。
RAG 鲁棒性。
检索结果中可能存在噪声、过期内容、错误内容和相互矛盾的证据。错误信息有时比没有信息更危险，因为它会诱导模型生成看似有依据但实际错误的回答。因此，鲁棒性将成为 RAG 的核心指标之一。
未来系统需要更强的证据校验、冲突检测、来源可信度建模和不确定性表达能力。
RAG 与微调的混合方法。
RAG 和微调不是互斥关系。RAG 擅长引入外部动态知识，微调擅长塑造模型能力、领域风格和任务偏好。未来主流方案很可能是二者结合：用 RAG 提供最新知识，用微调提升模型对领域任务和格式要求的适应能力。
同时，小语言模型也会更多参与 RAG 流程，例如用于查询分类、文档过滤、重排序、摘要压缩和检索质量评估。
RAG 的缩放规律。
目前大语言模型已经有较明确的缩放规律，但 RAG 系统的缩放规律仍不清晰。检索库规模、文档质量、块大小、嵌入模型规模、生成模型规模和重排模型能力之间如何相互影响，仍需要系统研究。未来需要回答的问题包括：更大的模型是否总是更适合 RAG？更大的知识库是否一定提升效果？检索深度和生成质量之间是否存在最优平衡？
8.2 RAG 生态系统
下游任务和评估。
RAG 最核心的任务仍是问答，包括单跳问答、多跳问答、长篇问答、领域问答和多项选择问答。但它已经扩展到对话生成、事实核查、文本摘要、信息抽取、代码搜索、推荐、机器翻译、数学推理、分类和多模态任务。
不同任务需要不同评估方式。问答任务关注答案准确性和证据支持；摘要任务关注覆盖率和忠实性；代码任务关注可执行性和语义匹配；事实核查任务关注证据链完整性。未来 RAG 评估会从通用指标走向任务特定指标。
面向生产的 RAG。
生产级 RAG 需要解决的不只是模型效果，还包括检索效率、权限控制、数据安全、延迟、成本、版本管理、监控、反馈闭环和可解释性。企业知识库尤其需要处理文档权限、数据隔离、敏感信息保护和来源追踪。
一个成熟的生产级 RAG 系统通常需要完整链路：数据清洗、解析、分块、元数据标注、索引构建、查询路由、混合检索、重排序、压缩、生成、引用、评估、监控和持续更新。
多模态 RAG。
RAG 正在从文本扩展到图像、音频、视频、代码和结构化知识。多模态 RAG 可以检索图片、图表、语音片段、视频片段和代码示例，并将其与文本生成结合。例如，视觉问答需要检索图像区域和文本说明；视频理解需要定位时间片段；代码任务需要检索函数、调用关系和示例。
多模态 RAG 的挑战在于不同模态之间的表示对齐、检索粒度设计、证据引用和生成一致性。未来它将成为 RAG 发展的重要方向。
技术栈。
RAG 的发展推动了相关工具链成熟。LangChain、LlamaIndex、Haystack 等框架提供了文档加载、索引、检索、重排、Agent 和评估能力；Weaviate、Milvus、Pinecone、Chroma 等向量数据库支持大规模语义检索；Flowise 等低代码工具降低了应用搭建门槛；云厂商也在将 RAG 能力整合到企业搜索和知识管理产品中。
总体来看，RAG 技术栈已经初步建立，但真正一体化、可评估、可监控、可治理的企业级平台仍在完善中。未来竞争重点不只是“能不能接入知识库”，而是能否稳定、可信、低成本地把知识转化为高质量答案。
9 结论
本篇论文深入探讨了检索增强型生成（Retrieval-Augmented Generation, RAG）技术。这种技术利用外部知识库来丰富大语言模型（LLMs）的上下文并生成答案。RAG 的特点在于，它结合了大语言模型中的参数化知识和外部的非参数化知识，有效减少生成信息的误差和虚假内容，利用检索技术获取及时信息，从而提升了答案的准确度。此外，RAG 通过引用资料来源，提高了模型输出的透明度和用户对结果的信任度。RAG 还可以根据特定的领域需要，通过整合相关的文本数据来进行定制。
RAG 的发展可以归纳为三种模式：基础型 RAG、高级型 RAG 和模块化 RAG。这三种模式各自拥有不同的模型、方法及其局限性。基础型 RAG 主要进行简单的“检索 - 阅读”操作。高级型 RAG 则在数据处理上更为精细，优化了知识库索引，并采用了多次或迭代式的检索方法。
随着技术的深入探索，RAG 开始融入微调等其他技术，形成了模块化 RAG。这一新模式通过引入新模块，使得 RAG 过程更加丰富和灵活。
在论文的后续部分，我们将深入分析 RAG 的三个核心组成部分。第四部分介绍了 RAG 的检索机制，包括如何处理文本数据以获得更准确的语义表示，缩小查询与文档间的语义差距，以及如何调整检索器以更好地配合生成器。第五部分阐述了生成器如何通过后处理检索到的文档来提升生成质量，避免信息处理过程中的缺失，并探讨了如何调整生成器以更好地适应检索器。第六部分回顾了目前提升检索效果的各种方法，从检索阶段、数据来源和检索过程等方面进行了探讨。
第七部分讲述了如何评估现有的 RAG 方法，包括评估标准、关键指标和目前的评估框架。最后，我们对 RAG 的未来研究方向进行了展望。作为结合了检索和生成的技术，RAG 在未来的研究中拥有广阔的发展空间。随着技术的不断完善和应用范围的扩大，RAG 的性能和实用性将得到进一步的提升。