RAG 演进路线
RAG 的演进可以分成三个阶段，先有全局地图再谈细节：Naive RAG 解决了“有没有”，Advanced RAG 解决“准不准”，Modular RAG 解决“能不能编排”。
RAG 三阶段演进
Naive RAG：一切的原点
最朴素的形态，就是概述篇的 Indexing-Retrieval-Generation 线性流程，也叫 Retrieve-Read 框架。用户问题做一次向量检索，召回片段拼进 Prompt，LLM 生成答案。
简单直接，问题也直接：
- 召回不准：语义检索匹配到主题相近但答非所问的块
- 片段冗余：Top-K 块之间信息重叠，浪费上下文
- 表述差无从纠正：用户问题口语化、指代不清，检索质量直接崩
Advanced RAG：生产环境的默认选择
Advanced RAG 仍是固定流水线，但在检索前后各加了一层优化：
检索前（pre-retrieval）：
- 查询改写（Query Rewrite）：LLM 把模糊口语化的问题改写成适合检索的陈述句
- 查询扩展（Query Expansion）：生成多个角度的查询并行检索
- 子问题分解：复杂问题拆成多个子查询分别检索再合并
- 查询路由：判断走向量检索、关键词检索还是直接生成
- 索引优化：滑动窗口、细粒度分段、元数据注入（来源、页码、章节）
检索后（post-retrieval）：
- 重排序（Rerank）：召回 Top-50，交叉编码器精排取 Top-5 到 10
- 上下文压缩：去掉与问题无关的句子，只留关键片段
- 去冗余：合并重叠块
多数生产系统停在这一档就够用。评估不达标，先升级到这里。
Modular RAG：从流水线到积木
Modular RAG 是范式层面的升级：检索、记忆、路由、融合、重排、生成全部抽象成可替换、可编排的模块。不再是一条单向直线，模块之间可以有迭代循环、条件分支，甚至嵌入 Agentic 决策，由模型动态决定走哪条路径、是否再检索一次。
挂在 Modular 框架上的典型范式：
| 范式 | 解决什么 | 机制 |
|---|---|---|
| 迭代检索 | 多跳问答 | 多轮“检索-生成-再检索”，中间结论指导下一轮查询 |
| Self-RAG | 幻觉 | 模型对检索内容和自己的输出做评估，决定要不要再检索 |
| CRAG | 检索质量差 | 评估发现召回不可靠时触发纠正：改写后重检索或转外部搜索 |
| HyDE | 短问题与长文档的语义鸿沟 | 先让模型生成假设答案，用假设答案的向量去检索 |
| GraphRAG | 跨文档、需全局视角的问题 | 知识图谱组织语料，实体和关系做结构化检索与全局摘要 |
| Agentic RAG | 何时检索、查什么、是否再查 | Agent 自主决策，Modular 思想的 Agent 化落地 |
面试追问
- 三阶段的区别？ Naive 是线性检索生成；Advanced 在固定流水线两端加优化（检索前改写路由、检索后重排压缩）；Modular 把各环节变成可编排模块，支持迭代、分支和 Agentic 循环
- Advanced 和 Modular 怎么区分？ Advanced 的主干仍是单向直线，只是两端加模块；Modular 的关键是结构本身被打开，可循环、可条件分支。别把两者混为一谈
- 生产环境从哪档起步？ 从 Naive 开始，用数据证明不够好再升级。混合检索加重排是性价比最高的第一步投资，确有多步、多源、需纠错的需求再上 Modular
- Self-RAG 和 CRAG 什么区别？ 前者偏自评驱动，模型评估自己的输出质量；后者偏兜底，检测到检索不可靠就触发纠正流程
- 复杂范式为什么挂在 Modular 下？ 因为它们都需要模块间的动态交互：迭代需要循环，Self-RAG 需要条件分支，Agentic 需要自主路由。只有 Modular 的结构支持这些