创建日期：2026-09-24 ｜ 最近更新：2026-09-26 三代划分（Naive / Advanced / Modular）及各自的定义、缺陷，均引自综述论文 Retrieval-Augmented Generation for Large Language Models: A Survey（arXiv 2312.10997v5），逐字原文留档于
source/rag-arch-lab/official-rag-survey-paradigms.txt（抓取日期 2026-09-24）。 文中引用的实测数字来自本专题第 1 篇与第 4 篇，脚本与真实输出在source/rag-lab/、source/rag-boundary-lab/。我自己的推断一律标注「推断」。
RAG 的架构演进之路：Naive → Advanced → Modular
一句话：Naive RAG 是一条直线；Advanced RAG 是在这条直线的几个固定位置上补工序；Modular RAG 则不再是一条线——走哪条路由，交给运行时决定。
入门篇讲了链路有五个环节，第 1 篇拆了重排，第 2 篇拆了切片，第 3 篇拆了相似度这把尺子本身，第 4 篇用 22 条 query 量了边界，第 5 篇拆了六个坏案例。这六篇都在讲「某一环」。
这篇把它们放回整条链路，回答一个上位问题：这条链路是怎么一步步长成今天这样的？ 判断一个新方案该不该上，前提是先看清自己现在这条链路长什么样、缺口在哪一段。
0. 先给结论
| 环节 | Naive RAG | Advanced RAG |
|---|---|---|
| 索引 | 定长切分 → 向量化 → 向量库 | 语义 / 层级切分、补元数据、父子块；向量库 ＋ 关键词索引 |
| 检索入口 | query 直接 embedding | 先做查询理解：改写 / 扩展 / 路由 |
| 召回 | 单路稠密向量 top-k | 多路混合召回：dense ＋ BM25 |
| 召回之后 | 直接拼进 prompt | RRF 融合 → Rerank 重排 → 压缩去重 |
| 生成 | 拼 prompt → LLM → 答案 | 同上，另加引用标注 |
| 检索次数 | 1 次 | 仍是 1 次（但每路召回更贵） |
一句话概括差别：Naive 把「相似」当成「相关」；Advanced 承认这两件事不一样，于是在链路的几个位置各插了一道工序来纠正它。
这个三段式不是我编的。综述论文的原话（逐字）：
The RAG research paradigm is continuously evolving, and we categorize it into three stages: Naive RAG, Advanced RAG, and Modular RAG... The development of Advanced RAG and Modular RAG is a response to these specific shortcomings in Naive RAG.
也就是说：后两代不是「更先进的替代品」，而是针对 Naive 具体缺陷的补丁。 所以这篇的顺序是「先看清 Naive 缺什么，再看补丁补在哪」。
1. Naive RAG 的架构
综述给 Naive RAG 的定义（逐字）：
The Naive RAG follows a traditional process that includes indexing, retrieval, and generation, which is also characterized as a "Retrieve-Read" framework.
三段式：索引（离线）→ 检索（在线）→ 生成。一条直线，没有分支，也没有回头路。
1.1 Naive 的三个缺陷
综述把 Naive 的问题归成三类（逐字，节选）：
Retrieval Challenges. The retrieval phase often struggles with precision and recall, leading to the selection of misaligned or irrelevant chunks, and the missing of crucial information.
Generation Difficulties. In generating responses, the model may face the issue of hallucination, where it produces content not supported by the retrieved context.
Augmentation Hurdles. ... Determining the significance and relevance of various passages and ensuring stylistic and tonal consistency add further complexity. Facing complex issues, a single retrieval based on the original query may not suffice to acquire adequate context information.
这三条在本专题的前几篇里都有对应的实测，不是纸面推理：
| 综述的缺陷分类 | 本专题的实测对应 |
|---|---|
| Retrieval Challenges（召不准 / 漏召） | 第 4 篇：稠密在 A 语义型上 hit@1 只有 1/6，B 精确串型 1/6 |
| Generation Difficulties（幻觉） | 第 5 篇：六个坏案例里，多数根因其实在检索侧而非模型侧 |
| Augmentation Hurdles（拼不进去） | 第 1 篇：双塔把 gold 与负例的分差压在中位 +0.11，下游没法做阈值过滤 |
最后一句尤其值得圈出来——「单次检索可能不够」。这正是通向第三代（Modular / Agentic）的那道门，第 5 节再展开。
2. Advanced RAG 的架构
综述的定义（逐字）：
Advanced RAG introduces specific improvements to overcome the limitations of Naive RAG. Focusing on enhancing retrieval quality, it employs pre-retrieval and post-retrieval strategies.
它把优化明确切成检索前和检索后两段。检索前又分两支（逐字）：
Pre-retrieval process. In this stage, the primary focus is on optimizing the indexing structure and the original query. The goal of optimizing indexing is to enhance the quality of the content being indexed... While the goal of query optimization is to make the user's original question clearer and more suitable for the retrieval task.
Post-Retrieval Process. Once relevant context is retrieved, it's crucial to integrate it effectively with the query. The main methods in post-retrieval process include rerank chunks and context compressing.
三道新工序，各补一个缺陷：
| 工序 | 位置 | 补的是哪个缺陷 |
|---|---|---|
| 更好的切分 ＋ 元数据 | 索引侧（检索前） | 块没被正确表达 → 召回里就没有正确答案 |
| 查询改写 / 扩展 / 路由 | 查询侧（检索前） | query 的表述和语料对不上 → 「问法」问题，不是「检索」问题 |
| 混合召回 ＋ 重排 ＋ 压缩 | 检索中 / 检索后 | 「像不像」不等于「答不答得上」；以及拼进 prompt 时的信息过载 |
但注意一件事：综述在对比图里对 Advanced 的定性是（逐字，Fig. 3 图注）：
(Middle) Advanced RAG proposes multiple optimization strategies around pre-retrieval and post-retrieval, with a process similar to the Naive RAG, still following a chain-like structure.
仍是链式的。 这句话是理解第二代和第三代分界的关键：Advanced 的工序再多，也是在构建时写死的——按固定顺序跑完就出结果，它不会因为「这次没召回到」而回头再试一次。那是第三代的事。
3. 每一道工序的代价
演进不是免费的。每加一道工序，都要多付一份延迟、成本或复杂度。这一节把账摊开——有实测的给数字，没测的明确说没测。
| 工序 | 你多付什么 | 本专题的实测 |
|---|---|---|
| 语义 / 层级切分 | 切分逻辑要按文档类型定制，不再是「按字数切」一刀切；语料一更新，切分逻辑要跟着维护 | 第 2 篇：6 类文档 6 种切法；定长切法把 8 个代码块、9 张表格切散 |
| 补元数据 / 父子块 | 索引体积变大；写入链路要保证元数据不丢 | 第 2 篇：PDF 抽取物里混着 457 个控制符、261 个康熙部首形近字 |
| 加关键词索引 | 多存一份索引、写入时多一路同步；BM25 主要吃 CPU 和内存，不占 GPU | 耗时未单独测（诚实交代） |
| 查询改写 / 扩展 / 路由 | 多一次 LLM 调用——延迟和 token 成本都上去了；「扩展」还会让召回量成倍增加，把成本传导给后面的重排 | 未测 |
| 混合召回 | 多跑一路检索 ＋ 一套融合逻辑（RRF 只看位次，本身很轻） | 未单独测耗时 |
| Rerank 重排 | 每个候选都要过一次 cross-encoder 前向，代价是 O(N)，随候选数近似线性增长 | 第 1 篇：50 条约 39 ms / 100 条约 82 ms / 300 条约 217 ms（RTX 3090）；对照双塔侧编码 query 只要 5.3 ms 且与语料规模无关 |
| 上下文压缩 | 又一次模型调用；压过头会丢信息 | 未测 |
这张表里最该记住的是对照组：双塔那一路的开销与语料规模无关（只编码 query），而重排是随候选数线性涨的。按 N=300 的速率外推，10 万条语料全量走重排约 72 秒一次——所以「重排 top-k」不是省钱的优化技巧，它是这个结构唯一可行的用法。
推断（非实测）：查询改写那道工序的成本结构，和重排不一样——它是一次固定开销（一次 LLM 调用），不随候选数增长；但它的下游影响是乘性的（扩展出 3 条 query，后面每一路召回和重排都跟着 ×3）。所以「改写 + 扩展」要谨慎开，尤其在延迟敏感的场景。
4. 哪道工序最值：把工序对上 query 类型
「值不值」不能脱离 query 构成谈。本专题第 4 篇用 22 条 query 分四类，把四种检索组合并排测过（语料 1479 块，格式 hit@1 @ hit@3）：
| query 类别 | ① 稠密 | ② BM25 | ③ 混合(RRF) | ④ 混合+重排 |
|---|---|---|---|---|
| A 语义型（同义改写） | 1/6 @ 3/6 | 2/6 @ 4/6 | 2/6 @ 4/6 | 2/6 @ 5/6 |
| B 精确串型（编号/型号/日期串） | 1/6 @ 2/6 | 2/6 @ 3/6 | 1/6 @ 3/6 | 4/6 @ 5/6 |
| C 数值表格型（哪一天哪个价） | 2/4 @ 2/4 | 0/4 @ 4/4 | 2/4 @ 3/4 | 3/4 @ 4/4 |
| D 条件否定型（条款句式高度相似） | 5/6 @ 6/6 | 3/6 @ 5/6 | 5/6 @ 5/6 | 3/6 @ 5/6 |
| 合计 | 9/22 @ 13/22 | 7/22 @ 16/22 | 10/22 @ 15/22 | 12/22 @ 19/22 |
把这张表翻译成「该补哪道工序」：
| 你的 query 构成 | 该补哪道工序 | 依据 |
|---|---|---|
| 以条件 / 否定型条款为主（D 类） | 什么都别加——稠密单独用 | D 类：稠密 5/6，加重排反而掉到 3/6，是四种组合里最差的 |
| 常有型号 / 编号 / 日期串（B 类） | 混合召回 ＋ 重排 | B 类：重排 4/6，是四种里唯一像样的；BM25 只有 2/6 |
| 要答表格里的具体数值（C 类） | 结构化过滤优先，向量只兜底 | C 类：BM25 的 top-1 0/4，但 top-3 全中 |
| 数据来自 PDF / 扫描件且没洗干净 | 先清洗；清洗不了就靠混合互相兜底 | 污染实测：BM25 掉 3 个 top-1，稠密纹丝不动 |
| 不确定 query 构成 | 混合＋重排起步，再按类别抽样评测砍层 | 合计 12/22 @ 19/22 最稳 |
这里有一个反直觉但很重要的结论：总分最高的组合，没有任何一类拿第一。 混合＋重排（12/22 @ 19/22）是个「稳」的选择，不是「强」的选择。如果你的 query 八成是 D 类，加两层反而更差。
所以「Advanced RAG 比 Naive RAG 好」这句话是不成立的——正确的说法是：它在你缺的那个位置上有补丁，在你不缺的位置上是纯开销。
5. 演进还没有结束：Modular RAG
回到第 1 节最后那句伏笔——综述在讲 Naive 缺陷时已经埋了话（逐字）：
Facing complex issues, a single retrieval based on the original query may not suffice to acquire adequate context information.
Modular RAG 就是对这个「单次不够」的回应。综述的定义（逐字）：
The modular RAG architecture advances beyond the former two RAG paradigms, offering enhanced adaptability and versatility. It incorporates diverse strategies for improving its components, such as adding a search module for similarity searches and refining the retriever through fine-tuning... The overall process is not limited to sequential retrieval and generation; it includes methods such as iterative and adaptive retrieval.
| 代际 | 谁决定下一步 | 结构与代价 |
|---|---|---|
| Naive | 代码写死 | 一条直线。可预测、好评测、延迟可控 |
| Advanced | 仍是代码写死（只是工序变多） | 仍是链式（综述原话），但每道工序都是固定开销 |
| Modular | 运行时决定 | 迭代 / 自适应检索，能处理前者处理不了的开放式问题；代价是延迟与成本不可控、评测更难 |
分界点就一句话：Advanced 的工序是「构建时编排好的」，Modular 的工序是「运行时决定的」。
本栏目
docs/agent有 Agentic RAG 的专门一篇。Agentic RAG 是业界对这条路线的一个叫法，它对应的正是综述里的「迭代 / 自适应检索」这一类增强方式——两者不是两件事，是同一趋势的两种命名。
6. 该停在哪一代
把前面几节压成一张决策图。注意它的输入不是「最新的是哪个」，而是「你的 query 构成 + 延迟预算」：
这张图的用法是「砍」而不是「加」：先按最可能的那一类选一个起点，然后按类别抽样评测，把不起作用的那层砍掉。加层谁都会，砍层才需要依据。
7. 本专题的路线
| # | 篇目 | 状态 |
|---|---|---|
| 0 | 入门：一条链路的五个环节 | ✅ |
| 1 | Rerank：是什么、什么时候用、怎么用 | ✅ |
| 2 | 切片与向量化：不同类型文档怎么切、怎么算成向量 | ✅ |
| 3 | 检索能力边界：同一批问题，四种检索组合各在哪失效 | ✅ |
| 4 | 失败案例拆解：六个真实坏案例，一套固定模板 | ✅ |
| 5 | 架构演进之路：Naive → Advanced → Modular（本篇） | ✅ |
| 6+ | 待定：上下文组装与引用 / 召回评测的工程落地 | ⏳ |
8. 来源与核对
| 引用 | 来源 | 存档 |
|---|---|---|
| 三代划分、Naive 定义（Retrieve-Read）、Naive 三个缺陷、Advanced 的 pre/post-retrieval 定义、Fig. 3 图注「still following a chain-like structure」、Modular 定义与 iterative/adaptive retrieval（均为逐字） | arXiv 2312.10997v5《Retrieval-Augmented Generation for Large Language Models: A Survey》(Gao et al., 27 Mar 2024) | source/rag-arch-lab/official-rag-survey-paradigms.txt |
| 重排 50/100/300 条的 39/82/217 ms、双塔 5.3 ms、10 万条外推 72 秒、分差中位 +0.11 vs +4.86 | 第 1 篇实测 | source/rag-lab/（bench_rerank.py + run.log） |
| 四类 query × 四种检索组合的命中表、污染对照 | 第 4 篇实测 | source/rag-boundary-lab/（run.sh + run.log） |
| 切分踩坑（8 个代码块 / 9 张表格被切散、457 控制符、261 形近字） | 第 2 篇实测 | source/rag-chunking-lab/ |
本文没有引入新的外部事实，除了第 3 节里标注为「未测」的三项（查询改写、混合召回、上下文压缩的耗时）——它们没有数字，不承担事实主张。
一处需要说明的取舍：摘要与正文 HTML 两次抓取均为 HTTP 200，正文用的是 arXiv 官方 HTML 版（
arxiv.org/html/2312.10997v5）。逐字引用均自该版本；论文若有后续修订，以 arXiv 当期版本为准。