之前两篇文章介绍了一个最最最简单版本的RAG，它的思路简洁优雅，只是在落地的时候，每个步骤都可能会出错，导致效果比较“骨感”，被学术界归类为“Naive RAG”。
那还有一个非常重要的问题是，既然RAG的思维没有什么问题，那到底应该怎么做呢？！
我们需要做怎样的修改，才能让RAG从“too young too simple”进化到“可以在真实的生产环境中落地”呢？Naive RAG每个可能出错的环节，现在是不是已经发展出了“业界可用”的“标准答案”呢？
怀着这样的疑问，我去找了一下RAG的相关综述，我主要参考了来自23年和24年两篇综述文章，他们把RAG的每个模块定义得很清楚，对于RAG发展路径的描述极其清晰。
了解了综述文章之后，关于RAG各种方向的研究都可以归类在一套体系之下，不至于因为发展的方向太多觉得很懵逼、很碎片化，而且还能够根据自己遇到的问题去对应的板块查找解法。这就是我喜欢的感觉。
不过由于综述文章是在很多篇论文的之上提炼出来的，对于只了解了一个Naive RAG的我来说读起来还是很吃力的，又衍生出去查了很多内容。有错漏的地方欢迎批评指正~
这篇文章包含以下几个部分：
RAG的解剖图
Pre-Retrieval阶段优化
Retrieval阶段优化
我希望通过对这些内容的梳理，向着“生产级的RAG”再进一步。由于Text-Based RAG是RAG系统的基础，我会先围绕着Text-Based RAG来介绍，后续再添加多模态的内容。
以及由于写完前几个阶段字数已经比较多了，Post-Retrival、Generation和对于RAG系统的评估就拆到下一篇文章了。
01. RAG的解剖图让我们先把RAG解剖一下，看看它能够被分为哪几个阶段，然后再来详细看一下每一个阶段可以进行的优化操作。
我看了几篇综述，个人比较喜欢的一种分类来自24年的文章“The Survey of Retrieval-Augmented Text Generation in Large Language Models”，论文把RAG分为4个阶段：
Pre-Retrival（检索前）：这个阶段主要是做一些能够提升检索和生成效率的准备工作，比如处理知识库数据、构建知识库索引和处理用户Query；
Retrival（检索）：这个阶段就是为了把用户的Query和知识库里面的信息进行匹配，主要包含了一些特殊训练的Retriever，以及检索策略的选择；
Post-Retrival（检索后）：这个阶段是为了把上个阶段检索到的材料进行二次加工处理，最大化后面生成模型的回答质量，这里包括把检索到的材料进行重排、过滤技术；
Generation（生成）：这个阶段是为了把检索到的资料和用户的Query融合在一起，尽量生成高质量的答案，就涉及到融合策略（也叫增强策略）的选择；有时候也需要按照用户对于语言风格、回答格式的等要求做定制化处理。
一个标准的RAG系统至少要经历上述的4个阶段，在此基础之上，新一代的RAG系统可能会在某些阶段形成动态的循环，这种循环可能是迭代式的（iterative）、递归式的（recursive）、条件式的（conditional）或者是自适应式的（adaptive），以此形成一种更加智能的新RAG模式。
02. Pre-Retrival（检索前）：检索前阶段需要做3个动作，我们可以一一拆开来看：知识库数据处理、知识库索引构建和用户Query处理。这3个动作是互相影响的，在不同的RAG系统中交叉使用多种策略。
处理知识库数据
知识库就是RAG里面用于给模型补充知识的外挂，知识库的文章必须要经过处理才能够为后续的“检索”和“生成”环节打好基础，防止“garbage in，garbage out”屎上雕花。
知识库数据有多种形式，多种不同的来源。现代RAG从“简单文本”向着“多种类、多模态”扩展。不过在这里就先介绍一下“简单文本”类型的知识库数据，多模态的处理放在后面单独开一个章节来说明。
对知识库数据的处理可以分为“外部数据增强”和“内部数据增强”。
“外部数据增强”是指补充新的外部信息。比如业界标准的数据库都会支持“元数据”检索——把一条数据信息增加页码、文件名、作者、类别时间戳等“元数据”。能够通过这些数据实现很简单的检索范围缩减。
还有很多其他的RAG系统依据训练目的把数据库整理成专用形式。这种操作非常的灵活，由具体的“任务目标”来决定。获得这些数据的形式也很多变，比如有纯粹的“人工标注”，还有现在非常流行的使用现代大模型“合成数据”。
比如RARG创造了一个“解题思路数据库”，用来解决“推理类的问题”。它的数据不是 Wikipedia 的文本片段，而是精心构建的、结构化的“问题-思路-答案”三元组。其中每一条数据都包含：问题描述 (Problem)；推理链 (Reasoning Chain，它是一段详细的、人类可读的、分步骤的解题思路）和最终答案 (Solution)。
UPRISE使用的则是一个“范例数据库”，这个数据库收录多种类的任务，并且为每个类别的任务都分配了“回答范例”。当模型拿到任务的时候，模型会先去数据库找出“相似任务”及其“范例回答”，构建出Few shot prompts，再生成回答。
“内部数据增强”是指充分利用模型“已有的知识”提高问答的准确性，可以理解为用LLM自己生成的内容来辅助检索。
比较直观的技术包括：
改写（paraphrasing）：即通过重写内容以提高可读性或提供多种视角。
摘要生成（summarization）：即在保留核心内容的同时压缩信息。
引入假设性问题（Reverse HyDE）：使用LLM生成“与文档内容相关的假设性问题”，然后在检索过程中计算原始问题与假设性问题之间的相似度。这种方式被用来减少原始Query与文档内容之间的语义差距，从而提升检索的准确度。
另外一个类别的方法是使用LLM来“生成与上下文相关的补充内容或解释”。这种方法相当于让LLM在调用外部信息之前，先充分挖掘自己的内部知识，提高“内部知识”利用率，也是在引导模型写出“解题的步骤”，从而减小模型的幻觉。
比如GENREAD在拿到题目后，不直接回答，而是先在草稿纸上，把自己脑海里所有与题目相关的知识点、公式、论据全部写下来，形成一份“内部参考资料”。然后，他会只看着这份自己写的草稿纸来组织最终的答案。
RECITE则强调“写作-引用-批判-修正”的循环。在拿到一个问题之后，这个模型会先生成“初步答案”；再去（内部或者外部）“寻找”可以支撑这个回答的“引文”；然后会自己对于这个“回答”进行批判，最后把批判信息也吸收进去产生最终的“精炼答案”。
KnowledGPT则不直接生成一个自然语言段落作为上下文，而是先强制 LLM 将其内部知识以结构化的形式（如知识三元组）提取出来，然后再将这些结构化的知识“翻译”成一段流畅的自然语言上下文。它通过增加一个“结构化知识提取”的中间步骤，迫使模型将知识“梳理”成结构化的事实，从而生成一个事实更密集、更可控、幻觉更少的上下文，最终提升任务表现。
Selfmem框架则是一个在动态性和迭代性走得更远的框架。它把每次的问答做成“压缩记忆卡片”储存在一个“记忆池”中。在后续的每次生成中，都可以从“永久记忆池中”捞取相关的“记忆卡片”来生成针对性的上下文，从而让回答更加“定制化”，并且可以解决“非常复杂的、有长程依赖的问题”。
建立知识库索引
对于“检索”来说，构建“索引”是重中之重，因为“检索”往往意味着一个问题要面向极其庞大的知识库，只有索引构建得好，才能提升检索的效率，整个系统才具备可用性。
a.分块策略
在建立索引之前需要把知识库文章“分块”，“分块”会影响检索和生成的质量。
像是Naive RAG系统，使用了最简单的办法——“固定长度”进行分块（比如100、512个token为一个chunk），这种方法没有任何工作负担，就是几乎不可避免地会在单词中间或句子中间切断，严重破坏语义连贯性。
那改良当然就是要“尽量保留完整的语义模块了”。有以下几种比较常见的方案。
递归字符切分 (Recursive Character Splitting)
这是目前LangChain等框架中默认且最常用的方法，它试图在保持语义完整性和控制块大小之间取得平衡。
具体而言，是需要设定一个理想的块大小（例如200个字符）和重叠大小（例如20个字符）。
提供一个分隔符列表，按优先级排序，例如 ["\n\n", "\n", ". ", " ", ""]（段落 -> 换行 -> 句子 -> 单词 -> 字符）。
它会首先尝试用最高优先级的“\n\n（段落）”来切分。如果切分后的块仍然大于设定的理想大小，它就会在该块上使用下一个分隔符“\n（换行）”继续切分，以此类推，直到块的大小符合要求。
这种做法非常灵活，能尽可能地尊重文本的自然结构，同时保证块不会过大。在大多数情况下，它是一个非常可靠、效果不错的起点。不过它本质上仍然是基于规则的，不完全理解语义。一个没有换行的长段落里的长句子，仍然可能被从中间切开。
基于自然语言边界的切分 (Language-Boundary Splitting)
这种方法通过识别语言边界进行切分，尽力保留完整语义。
可以按句子切分 (Sentence Splitting)：使用NLTK、spaCy等自然语言处理库，将文本准确地切分成句子。每个句子或几个相邻的句子作为一个块。这些库能智能地识别句子边界“（., !, ?）”，并能处理“Dr. ” 或 “U.S. ”等特殊情况。
也可以按段落切分 (Paragraph Splitting)：以换行符（\n\n）为标志，将文本切分成段落。这通常能很好地保留一个完整的话题单元。
它的操作非常简单，能有效避免语义割裂问题。问题只是句子的长度和段落的长度可能变化很大，无法保证每个块的大小适中。
利用文档结构进行切分 (Document Structure-Aware Splitting)
当处理有明确结构的文件时（如Markdown, HTML, LaTeX），按照文档结构进行切分。比如下面几种文档就有明显的、可解析的结构：
Markdown：根据标题（#, ##, ###）来切分，每个标题及其下的内容作为一个块。
HTML：根据标签（如 <div>, <p>, <li>）来解析和切分。
JSON/Code：根据代码的函数、类或JSON的键值对结构来切分。
这种方式完美保留了文档的原始逻辑结构，对于问答、摘要等任务效果极佳。只不过这种方法的适用范围有限，不适用于纯文本（.txt）文件。
语义或内容感知的切分 (Semantic/Content-Aware Chunking)
这是更前沿的但是成本更高的方案，它根据文本的语义相似度来决定切分点。
具体做法是：将文档切分成非常小的单位，比如单个句子。为每个句子计算嵌入向量（Embedding）。比较相邻句子的嵌入向量的相似度（如余弦相似度）。
当相邻句子的相似度低于某个阈值时，就认为这里发生了一个话题转换，并在此处进行切分。将语义相似的连续句子合并成一个块。
这种方法能创建出语义高度内聚的文本块，每个块都围绕一个核心主题，质量非常高。问题就是计算量大，实现起来比前两种方法复杂，需要仔细选择 embedding 模型和设定合理的相似度阈值。
b.结构化索引
在分块之后要构建所有材料的索引。
首先要解决的问题是，要对一段材料的“什么特征”做索引？
现在公认的做法是，对“一段材料”的多个方面建立索引。就好比你通过“关键特征”来找东西，你总结出来的“关键特征”越多，就意味着这段材料越容易被找出来。
最为标准的起点是既建立“稠密索引”，又建立“稀疏索引”，形成一种混合检索。
（在介绍Naive RAG的文章中，我专门介绍了这两个概念：万字大白话RAG Retriever：从哪里来，要干什么（表格+图解邪修版））
稠密索引：是指把“知识库材料”Embedding成为一种“稠密向量”来建立的索引，比如Naive RAG就选用了BERT来做这个Embedding，还可以选用其他强大的模型来做Embedding。
稀疏索引：是指利用“关键字符匹配”的传统索引，比如使用BM 25算法来进行检索匹配。这种传统的方式不理解“近义词”，但对于查找产品型号等需要“精确匹配”的任务有奇效。
知识图谱索引：当数据中包含大量实体和复杂关系时（比如公司组织架构、产品依赖关系），将文本中的实体和关系抽取出来，存入图数据库（如 Neo4j）。检索时，查询会被转换成图查询语言（如 Cypher），从而能够进行多步、跨关系的复杂推理。这就是 Graph RAG 的基础。
除此之外，还有结合我们上面提到的“数据处理”办法形成的其他多维特征索引：
元数据索引 (Metadata Indexing)：在索引每个文本块的向量和内容时，同时为它附加丰富的结构化元数据，如 {"source": "Q3_report.pdf", "page": 5, "author": "Finance Dept", "timestamp": 1696118400}。这使得“先过滤，再搜索”成为可能，极大地提升了检索效率和精度。这是所有生产级 RAG 系统的必备功能。
摘要索引: 为每个大块或整个文档创建一个高质量的摘要，然后对摘要进行索引。
假设性问题索引 (Hypothetical Questions): 使用 LLM 预先为每个文本块生成几个它可能回答的问题，然后对这些问题的向量进行索引。这能极大地弥合用户提问方式与文档原文之间的鸿沟。
分层/父文档策略: 将文档切分成“子块”和“父块”。只索引精炼的“子块”向量，但在检索到子块后，用其对应的、包含更完整上下文的“父块”来增强 LLM。
在解决了“要对什么特征做索引”之后，还需要解决的问题是，要怎么快速在一大堆向量中找到我们想要的那个向量？
毕竟不管是用“稠密检索”还是用“稀疏检索”，都改变不了我们数据库量级很大的现实。量级很大的数据库直接去做相似度比较，计算量很大、速度很慢。
解决这个问题的核心思想是通过在数据入库时进行一次性的、精心的“预处理”和“组织”，构建出一个巧妙的数据结构，从而在查询时能够极大地“剪枝”，避免对绝大多数无关向量进行比较。
基于图的方案 (Graph-Based) ，是当前的事实标准。典型算法是HNSW (Hierarchical Navigable Small World)。
这种方法会把数据库所有向量组织成一个复杂的多层网络图。每个向量是一个节点，节点之间通过“边”连接。底层的图非常密集，包含了所有节点；顶层的图非常稀疏，只包含少数“交通枢纽”节点。
当一个查询向量进来时，它像一个智能导航系统，从最稀疏的顶层“高速公路网”开始，快速定位到大致区域，然后逐层向下，进入更密集的“主干道”和“小街道”，最终在很小的局部范围内进行精细搜索。
HNSW在召回率和查询速度（QPS, Queries Per Second）之间取得了目前公认的最佳平衡。对各种数据分布都有很好的效果。
只是它需要存储图的连接关系，索引本身会占用较大的内存空间，索引的构建过程相对较慢。
FAISS、ScaNN (Google) 以及几乎所有现代向量数据库 (Pinecone, Weaviate, Milvus, Qdrant 等) 都将 HNSW 作为其核心或默认的索引算法。
处理用户Query
用户的Query是一种神奇的东西，表达方式千变万化，是“人类”容易理解的东西。如果直接用Query的原文去做检索，机器可能会懵逼。所以把用户Query处理成为“模型”容易理解的形式至关重要。
对于用户Query的处理可以分为以下几种类别：扩写（Query Expansion）、转换（Query Transformation）和路由分发（Query Routing）。
Query Expansion：把单个的Query进行扩充，扩充成为多个Query或者是补充一些上下文，以此来减少相关文档的遗漏和更加准确的理解用户的意图。
拆解子问题（Sub-queries）：把复杂的问题，拆解成为很多个子问题，可以是多步骤的推理，可以是从多个不同的角度进行阐述。让LLM针对子问题来进行搜索，合并生成终版答案。 链式验证（Chain-of-Verification，CoVe）：根据用户的Query进行初步作答，然后把答案中需要资料支撑的地方都罗列出来一一进行提问。
Query Transformation：把用户原本的Query变形再查询。
Query rewrite：把一些口语化的词替换为跟“检索资料”更“匹配”的词语（比如把“小个子”替换为“XS码”）。或者是对某些词语进行近义词发散。 HyDE：构建“原始查询的假定答案”，将关注点从“问题与答案的向量相似性”转向“答案向量之间的相似性”。 Step-back Prompting：对原始查询进行抽象，生成高层次的概念性问题（即step-back问题）。这个step-back问题会与原始查询共同用于检索，两者的检索结果都将被纳入考量。
Query Routing：当系统需要处理多种任务时，通过路由判断用户意图，将其分发到不同的处理流水线（如摘要、问答、图谱查询等）。可以使用“元数据”进行分发，也可以使用“语义”进行分发。
03. Retrival（检索阶段）：在RAG系统中，检索动作是由Retriever来完成的，而Retriever有三个组成部分：负责把用户Query进行Embedding的Query Encoder；负责把知识库信息进行Embedding的Document Encoder；还有一个被构建出来的Document Index。这个Document Index没有训练参数，只是在知识库信息都被Embedding之后，被构建出的一种索引结构，用于提高检索的效率和质量。
RAG系统使用的Generator通常都是“参数非常多的现代大模型”，训练一次非常麻烦；或者RAG系统直接调用了外部商业大模型的API，没有办法直接干预Generator。业界以及学者们在改造自己可控的Retriever上面下了很多功夫。
Retriever的任务是把Query和知识库信息进行匹配。这个环节总结一下就是在解决“怎么找到一系列材料使得最终生成答案质量最大化”的问题。
可以从两个层面来看这个环节的优化：一个是对Retriever进行额外的训练（微调/使用其他轻量级方案）；另外一个是把Retriever从一个单调的流水线环节改造成为一个动态环节，这里涉及“检索策略”的选择。
微调
微调主要有两种目的，第一个是领域知识补充 (Domain Knowledge Adaptation)，通用的嵌入模型可能不认识你所在行业的“黑话”（专业术语），需要用专业领域数据（如医疗文献、法律文书）对嵌入模型进行继续训练，让它学会这些专业知识。
第二个是Retriever与Generator对齐 (Retriever-Generator Alignment)。Retriever认为相关的文档，LLM（Generator）在生成答案时可能觉得不好用。于是需要让Retriever学会“站在LLM的角度思考”，挑选出LLM最喜欢、最容易利用的文档。
用大语言模型（LM）作为监督信号来微调Retriever的方法叫做LSR (LM-supervised Retriever)，是一种非常流行的提升Retriever的方法。以下几种系统都使用了这种方法：
Atlas：主要通过两种“教学方法”来训练Retriever。
注意力蒸馏 (Attention Distillation)：让教师模型阅读问题和正确文档，并记录下它认为最关键的词句（即“注意力”集中的地方）。然后，训练Retriever去模仿这种注意力模式，学会“划重点”。
困惑度蒸馏 (Perplexity Distillation)：“困惑度”可以理解为模型对一句话的“意外程度”，程度越低代表内容越符合逻辑。训练Retriever的目标是，找到一份文档，这份文档能让语言模型在生成标准答案时感到“最不意外”（最低困惑度）。也就是说，Retriever要学会挑选那些能让答案“顺理成章”地被推导出来的文档。
LLM-Embedder：采用“硬标签 + 软奖励”双重监督信号。软奖励 (Soft rewards)是指LLM评估出来的“相关性得分”。硬标签 (Hard labels)就是指数据集中已有的、明确的“问题-正确文档”对。
REPLUG：认为一个好的Retriever，其对文档的“品味”（预测的概率分布），应该和一个强大的LLM尽可能相似。它通过计算两者的“品味”差异（KL散度），并以缩小这种差异为目标，来指导Retriever的训练。
轻量化对齐方案：Adapters & Others
完整地微调一个大型嵌入模型，计算资源消耗巨大，且技术门槛高。对于只能通过API调用模型，或者本地算力有限的用户来说，这几乎是不可能的。
对于这种情况，可以采用Adapter来提升检索能力。增加Adapter是指在保留主体模型“参数冻结”的情况下，在模型中加入一些“可以训练的”神经网络层，通过调节这些小的神经网络层来提升模型的效果。这种办法可以有效的减少算力消耗，训练起来非常轻量级。
UPRISE：认为当面对一个全新的、零样本（Zero-shot）的任务时，让一个通用的LLM发挥出最佳性能的关键在于为这个任务找到最完美的“指令”（Prompt）。
于是它设计的Adapter是一个Prompt检索器。它不去知识库里找资料，而是去一个预先构建好的“金牌Prompt库”里，根据任务描述，检索出最能激发LLM潜力的那个Prompt。
AAR：想要打造一款能够泛化到多种任务上的Retriever（比如，既要用于问答，也要用于摘要，还要用于对话），于是它设计的Adapter主要训练目的是“万能转换”。
这个Adapter通过在多种增强数据上进行训练，学会了如何调整检索器的输出，使其更能适应不同任务的需求，提升了Retriever的通用性和泛化能力。
PRCA：核心在于内容对齐（Content Alignment），想找到一款Adapter把检索回来的材料处理成下游Generator喜欢的形式。
它增加了一个奖励驱动的上下文Adapter。这个Adapter接收Retriever找来的文档，然后对其进行处理和重塑（比如生成摘要、提炼要点）。它的训练目标是：经过它处理后的内容，能让最终的黑箱LLM生成最高质量的答案。这个“质量”是通过一个奖励模型来打分的。
BGM (Bridge Model)：没有直接微调Retriever，而是在固定的检索器和LLM之间，插入了一个专门训练的“桥梁模型”。这个桥梁模型的任务是“承上启下”：它接收检索器返回的原始文档，然后对其进行加工处理（如重排序、摘要、筛选），转换成LLM最“喜欢”的格式，再喂给LLM。
检索策略
检索策略侧重于“应该在何时、以何种方式、执行多少次检索”。传统 RAG “一次性检索出所有资料，然后开始作答”的模式，在面临“复杂问题/多跳推理”时，往往捉襟见肘；于是学者们开发了更加灵活复杂的“检索策略”。
基础检索：最简单直接的“一步到位”流程。整个过程像一条线性流水线，严格按照“检索 -> 生成”的顺序执行一次，中间不回头、不分支。
适用于简单的事实问答，对答案的深度和精度要求不高的场景。
典型例子有Atlas / REPLUG：虽然这些模型的训练过程很复杂，但它们在实际工作时（Inference），都遵循一次检索、一次生成的基础流程。
迭代式检索：把一次大的、模糊的检索，分解成多次小的、精准的、相互关联的检索。每一次新的检索，都会借鉴和利用上一步的检索或生成结果，从而实现一种“滚雪球”式的、逐步逼近最终答案的智能信息收集过程。
适用于需要深度探索和多步推理的复杂问题，如科研辅助、报告撰写等。典型的例子有ITER-RETGEN、IRCOT、RQ-RAG/PlanRAG等等。
递归式检索：一种“自我调用”的检索模式。它将一个复杂的、大的检索任务，分解成一系列更小的、结构相同的子检索任务，并逐层深入，直到问题被解决。这个过程自然地形成了一个树状或层级的探索结构。这就像一个程序中的“递归函数”，函数为了解决问题 f(n)，会去调用自身来解决一个更小的问题 f(n-1)。
适用于处理具有层级结构的数据（如知识图谱、长文档的章节结构），需要深度挖掘和关联信息。
典型的例子：SURGE / MEMWALKER，它们分别在知识图谱和长文档记忆树上进行导航，完美体现了递归思想。IMRAG / Selfmem：这些方法通过模型的“内心独白”或构建“自回归记忆”，来决定是否需要对当前结果进行更深层次的递归挖掘。
条件式检索：“基于规则，按需行动”。检索流程中包含一个或多个“检查点”或“门卫”。只有当满足特定条件时，才会触发特定的检索动作或后续流程。
适用于需要保证合规性、事实准确性或满足特定规则的场景，如法律咨询、医疗诊断辅助等。
典型的例子如PRCA它通过“奖励模型”判断上下文是否满足“高质量”这个条件，来决定如何调整内容。CRAG引入了一个“检索评估器”作为门卫，它会给检索到的文档打分，根据分数（置信度）来决定是直接使用、进行补充检索还是完全忽略。
自适应式检索：它比我们之前讨论的迭代式、递归式、条件式都更进了一步，代表了 RAG 系统的最高形态。它是一种“随机应变”的检索模式。
它没有一套固定的流程，而是会像一个经验极其丰富的人类专家一样，根据当前问题的具体情况（问题的难易、主题，已有的信息是多是少），动态地、即时地调整和改变自己的“信息搜集策略”。这就像从“遵循固定菜谱做菜”升级到了“顶级大厨的临场发挥”。
适用于高度动态和个性化的环境，如个人智能助理、自适应学习系统等。
典型的例子如AAR / FLARE：它们会根据LLM的偏好或“不自信”的信号，来动态调整检索行为。
SelfRAG：引入了“自我反思”机制，LLM会评价自己生成的内容，如果发现有问题（如事实错误、内容不全），就会主动决定重新检索或补充检索，这是一种高级的自适应行为。
坦白来讲这几个动态规划的RAG系统我不是很能够明显区分得开，于是我询问了一下Gemini老师怎么来看待这几种分类，它的回答我觉得非常精彩，可以给大家作为参考，可能在实践中的大神会感受得更加明显。
学术分类的本质并非绝对互斥的“铁盒子”，而是为了强调不同技术框架最核心的创新点和驱动机制而贴上的“标签”。
它们“自适应”的层面、方式和灵活度有着本质的区别。我们可以把这几类技术看作一个智能和自主性不断提升的光谱。
让我们重新审视这几类技术的“决策驱动力”：
迭代式 & 递归式RAG都遵循一个“固定的高级流程”。
迭代式RAG（如 ITER-RETGEN）的决策逻辑: “我的上一步答案还不够好，我需要根据它来生成一个更具体的查询，以完善我的答案。”它是在适应答案的完善需求。整个过程是一个线性的、为了优化单一目标的精炼循环。它的“策略”——即“通过不断生成和检索来打磨答案”——是固定不变的。
递归式RAG（如 MEMWALKER）决策逻辑: “要解决这个宏观问题，我需要先解决它的下一个微观子问题。”它是在适应问题或数据本身的层级结构。它的决策是结构化的，即在预设的树状结构中“向下钻取”。它的“策略”——即“通过分解问题来层层深入”——也是固定不变的。
在这两种模式下，系统虽然是动态的，但它们都在忠实地执行一个预设好的、高级的算法流程。它们很智能，但更像一个严格遵循高级手册的专家。
条件式RAG (如 CRAG)则拥有“固定的决策关卡”。它的决策逻辑是: “在流程的这个节点，检查一下条件 X 是否满足。如果满足，走 A 路径；如果不满足，走 B 路径。”它是在适应一个明确的、可判断的外部条件（比如，检索回来的文档质量好不好）。
它比迭代/递归更进了一步，因为它引入了分支逻辑，使得整个工作流可以发生改变。但这个决策逻辑本身依然是基于一个固定的规则（“质量高于80分就通过”）。
自适应 (Adaptive)RAG能够“动态地改变策略本身”。这是最高级的形式，也是它与前几类的根本区别。自适应检索系统不仅是在执行一个流程，更是在“思考”并“选择”自己应该执行哪个流程。
它的决策逻辑是: “面对当前这个独特的问题和我的内部状态，我应该采取什么样的信息收集策略才是最优的？”它是在适应一个综合性的、实时的情境，包括：
问题的本质: 这个问题是常识吗？我需要检索吗？(如 Self-RAG 的第一步决策)
自身的内部状态: 我对接下来要说的内容有信心吗？(如 FLARE 的置信度监控)
外部环境的质量: 我检索回来的信息靠谱吗？我应该信任它，还是批判它，甚至完全抛弃它？(如 Self-RAG 的反思机制)
任务的进展: 我是否应该从中途改变我的检索粒度？(如 DRAGIN 的策略切换)
它们之间的核心区别就在于:迭代式和递归式是在一个固定的元策略（meta-strategy）下，动态地调整具体的操作（operation）。自适应则是在动态地调整元策略本身。
用一个终极比喻来总结。
想象一家餐厅的运营模式：
静态 RAG: 是一家快餐店。无论顾客点什么，流程永远是“点餐 → 收钱 → 从保温箱取餐”。
迭代式 RAG: 是一家高级牛排馆。厨师会先把牛排煎到五分熟（初步生成），端给顾客尝一下（获取反馈），顾客说“我想要再熟一点”（精炼需求），厨师再拿回去加工到七分熟（精炼生成）。整个流程是为了优化“牛排”这一件产品。
递归式 RAG: 是一家需要解谜才能吃饭的密室逃脱主题餐厅。要吃到主菜，你必须先打开前菜的盒子；要打开前菜的盒子，你必须先解开开胃酒的谜题。整个流程是层层嵌套、环环相扣的。
条件式 RAG: 是一家有“特殊规则”的餐厅。比如，“如果你能证明今天是你的生日（满足条件），你就可以选择隐藏菜单（触发新路径）。”
自适应 RAG: 这是一家由一位全能主厨经营的私房菜馆。
顾客进来，说“随便做点好吃的”。主厨先打量一下顾客（分析问题），判断他是想吃清淡的还是重口的。他甚至会判断：“这位客人看起来很懂行，我可能不需要完全按菜谱来。”（类似 Self-RAG 判断是否需要检索）。
在做菜的过程中，他尝了一下汤底（监控内部状态），觉得味道有点寡淡（类似 FLARE 的低置信度），于是他临时决定不加盐，而是加入一种特殊的菌菇来提鲜（动态改变策略）。
他不受任何固定流程的束缚，他的每一个动作，都是基于对当前所有信息的实时、综合判断而做出的最佳策略选择。
它们都有自适应的成分。但“自适应检索”这个标签，被用来特指那些自主性最高、决策逻辑最灵活、最接近人类“随机应变”能力的顶层系统。它适应的不再是流程中的某一个环节，而是整个解决问题的“道”与“术”。
04. 小结到这里RAG的Pre-Retrieval阶段和Retrieval阶段就介绍完了。
我们可以看见RAG自概念被提出，它的每个阶段就被拆分，然后不断精细化，由此从学术界的Naive RAG，进化到可用的Advanced RAG。
再此基础之上，生产环境中遇到了越来越多的需要多跳推理的问题/复杂问题，推动着RAG走向更加动态、智能的路径。它不仅在多个步骤提供多种成熟解法，还从海量数据中学会了“决策”和“判断”，可以组合调用检索和生成等动作。
LangChain, LlamaIndex等框架的核心 API 稳定支撑着“底层”应用；“中层”技术作为其高级模块被逐步推广；而“顶层”的 Agentic 框架（如 LangGraph）虽然强大，但学习曲线陡峭，定位为专家级工具。
