RAG 并非一个静止的终点，而是一条在实践中不断优化的技术路径。从最初的概念验证到如今支撑关键业务，RAG 大致经历了三个阶段的迭代：Naive RAG（朴素检索增强）、Advanced RAG（高级检索增强）、Modular RAG（模块化检索增强）。每一代都针对上一代暴露出的痛点，在准确率、可控性和灵活性上向前迈进了一步。
1.5.1 Naive RAG：最简“检索 — 阅读”原型
Naive RAG 是 RAG 思想的最基础实现，也是大多数开发者的入门起点。它的流程极为直观：
- 索引阶段：将文档按固定长度（如 500 字）简单切分（chunk），用通用嵌入模型（如 text-embedding-ada-002）生成向量，存入向量库。
- 检索阶段：用户提问后，将问题向量化，用余弦相似度从库中召回 Top‑K 个内容片段。
- 生成阶段：把问题和这些片段直接拼成提示词，发送给大模型，要求它基于给定信息作答。
优点：搭建速度极快，几十行代码就能跑通一个 Demo，适合验证可行性和初期的快速试错。
局限：在生产环境中，Naive RAG 的不足会明显暴露出来。
- 检索精度低：单纯依赖向量相似度，容易被关键词蒙蔽，召回大量“看起来相关但实际无用”的片段；而用户问题的口语化、模糊化，更让检索效果雪上加霜。
- 上下文组装粗放：把所有片段一股脑塞进 prompt，既可能超长截断，也可能让模型在冗杂信息中找不到重点。
- 生成容易出现“妄用”：模型可能忽略检索到的资料，转而依靠自身训练记忆编造答案，或是因为片段质量差而给出含糊其辞的回复。
- 无法处理复杂意图：面对需要多步推理、多文档对比的问题，简单的一问一搜一答模式很难胜任。
真实写照：某团队用 Naive RAG 搭了一个政策问答 Demo，现场演示时效果尚可。但一旦上线，员工用自然口语提问：“那么之前那种老方案还能用不？”系统召回的多是“方案”二字的泛泛介绍，生成的答案也牛头不对马嘴。大家很快意识到，仅靠最原始的检索链路，远远不够。
1.5.2 Advanced RAG：从“搜到”到“搜准、用对”
Advanced RAG 针对 Naive RAG 的不足，在检索的前、中、后三个阶段引入了一系列增强技术，使系统回答质量得到质的提升。这个阶段并非某一项单一技术，而是多种优化手段的组合应用。
检索前：让问题更“可检索”
- 查询重写（Query Rewriting）：用小模型或 LLM 将用户的随意提问改写成更适合检索的关键词、短语或完整短句。比如将“那个之前说的报销新规是啥来着？”重写为“2024年差旅报销新规定”。
- 查询分解（Query Decomposition）：将复合问题拆解成多个子问题，分别检索，再综合回答。例如，“A产品和B产品在保修和价格上有什么区别？”可以被拆成“A产品保修条款”“B产品保修条款”“A产品价格”“B产品价格”分别召回。
检索中：提升召回的精准与多样
- 混合检索（Hybrid Search）：同时使用向量检索和关键词检索（如 BM25），兼顾语义相似度和精确术语匹配，避免遗漏重要文档。
- 多路召回路由（Routing）：根据问题类型，将查询发送给不同的检索器或知识库。例如识别到“财务”相关问题就走财务文档库，识别到“技术”则走技术文档库。
- 小文档粒度控制：对文档进行语义分块，保证每个片段有完整、独立的上下文信息，而不是生硬截断。
检索后：精筛信息，让模型聚焦
- 重排序（Re‑ranking）：用一个轻量级模型（如 cross‑encoder）对召回的 Top‑K 片段重新打分排序，只保留最相关的 Top‑N 送入生成阶段，滤除大量噪声。
- 上下文压缩（Context Compression）：对过长文档片段进行摘要，提取与问题最相关的核心句，在保持信息量的同时节省 prompt 长度。
效果：经过这些增强，Advanced RAG 在真实业务中表现出了令人满意的实用性。同一政策问答系统，在对查询重写和重排序引入后，员工随口问的问题也能精准定位到相关段落，回答的可信度和满意度都大幅上升。目前，多数成功落地的 RAG 应用都处于这一阶段。
1.5.3 Modular RAG：走向灵活可编排的体系
随着业务场景越来越复杂——多轮对话、多模态输入、动态知识更新、自适应推理——固定的流程渐渐显露局限。Modular RAG 顺应而生，其核心思想是：将 RAG 的各个环节拆解为可插拔的功能模块，让开发者能按需组装，甚至让系统自主决策要使用哪些模块。
Modular RAG 并不推翻 Advanced RAG 的优化技术，而是提供了更高维度的架构自由度。典型的新增模块与能力包括：
- 记忆模块（Memory）：记录多轮对话中的上下文，支持追问、澄清、连续话题的承载。比如用户先问“年假多少天？”，接着问“那未休完的呢？”，系统能利用记忆把第二问补全为“未休完的年假如何处理”。
- 自适应检索（Adaptive Retrieval）：由模型判断当前问题是否真的需要检索。对于纯粹闲聊或已知常识，可以跳过检索；对于事实性问题则执行检索，避免不必要开销。
- 任务编排与调度（Orchestration）：像 LangChain、LlamaIndex 等框架提供的“链”（Chains）与“代理”（Agents）能力，支持将检索、生成、验证、重查等多个步骤串联或条件触发，构成一个完整的推理工作流。
- 多模态与多源融合：将检索范围扩展到图片、表格、代码等，不再局限于纯文本。
- 自我纠错与迭代检索：模型生成答案后，可以再反过来验证答案是否与检索到的原文一致，若不一致则自动重查或修正。
特点：Modular RAG 不再是一个固定配方，而是一个可扩展的工具箱。它允许根据场景成本、延迟要求、准确性需求，灵活平衡各模块的使用程度。例如，一个内部 FAQ 系统可能只用到查询重写、混合检索和简单的记忆；而一个金融合规系统，则需要多路路由、重排序、上下文压缩、自我验证等多个模块协同工作。
演进逻辑与现状：从 Naive 到 Advanced，解决的是“检索效果不好”的技术问题；从 Advanced 到 Modular，则是将 RAG 从一种技术栈推向一套设计范式的升级。当前，Modular RAG 正处于快速演化中，越来越多框架和工具正围绕模块化理念提供原生支持，让开发者不必重复造轮子，即可像搭积木一样构建出高度适配业务的 RAG 应用。
三代路线并非替代关系，而是累进包容的关系。Modular RAG 体系下，开发者仍然可以只启用最朴素的链路，也可以随时引入高级增强模块。理解这一演进脉络，有助于在动手搭建时选择适合当下阶段的落地方案，并预留未来持续优化的空间。