简介：本文系统对比16种主流RAG方案，从朴素检索增强到Agentic RAG，围绕架构、功能、性能、运维、成本等维度展开分析。读者将掌握各方案的核心差异、适用场景与选型依据，理解从简单原型到生产级系统的演进路径，并获得迁移注意事项与决策框架。
检索增强生成（Retrieval-Augmented Generation，RAG）已经成为大模型应用开发的基础范式之一。它的核心思路并不复杂：在生成答案之前，先从外部知识库中检索相关内容，再将其作为上下文交给大模型，从而缓解幻觉、知识过时、领域知识缺失等问题。
但真正进入工程落地阶段，开发者很快会遇到一个现实问题：RAG 不是一种方案，而是一大类方案的统称。 从最基础的“向量检索 + 拼接提示词”，到引入重排序、查询改写、多跳推理、工具调用、智能体编排的复杂系统，不同方案在效果、成本、延迟、运维复杂度上差异巨大。面试中如果只能说出“检索增强生成”六个字，往往说明缺乏对方案谱系的系统理解；而在技术选型中如果只凭直觉选择，轻则效果不达预期，重则系统难以维护。
本文围绕 16 种主流 RAG 方案展开对比，将它们按演进阶段划分为三大类：朴素 RAG、进阶 RAG、Agentic RAG，并从架构、功能、接入方式、性能、安全、运维、成本、适用场景等维度进行系统分析，帮助读者形成清晰的选型判断。
为了让对比更清晰，我们先将 16 种方案归入三个层次。需要说明的是，不同资料对 RAG 方案的分类和命名略有差异，本文采用业界较为通用的理解方式，重点在于对比其技术逻辑差异。
朴素 RAG 是最基础的形态，典型流程为：
用户问题 -> 向量化 -> 向量检索 Top-K -> 拼接提示词 -> 大模型生成
它通常包含以下方案或变体：
这一阶段的共同特点是：流程线性、组件少、实现简单，但召回质量和上下文利用效率有限。
进阶 RAG 在朴素 RAG 的基础上，针对“检索前、检索中、检索后”三个环节进行优化：
这一阶段的核心目标是：提升召回相关性、降低噪声、优化上下文质量。
Agentic RAG 将智能体（Agent）思想引入 RAG，使系统具备自主规划、工具调用、多轮推理和自我反思能力：
Agentic RAG 更接近“自主问题求解系统”，适合复杂任务，但架构复杂度和不确定性也显著上升。
尽管 16 种方案差异明显，但它们共享一些核心逻辑：
理解相同点有助于避免“为了复杂而复杂”——如果朴素 RAG 已能满足需求，就不必盲目上 Agentic RAG。
| 方案类别 | 架构特点 | 依赖组件 |
|---|---|---|
| 朴素 RAG | 线性流水线 | 嵌入模型、向量库、大模型 |
| 进阶 RAG | 多阶段流水线 | 增加重排序、查询改写、压缩等模块 |
| Agentic RAG | 循环/图状编排 | 增加智能体框架、工具调用、状态管理 |
朴素 RAG 的架构最简单，适合快速验证；进阶 RAG 引入多个处理节点，架构复杂度上升；Agentic RAG 则更接近有状态的工作流引擎，需要处理规划、工具路由、失败重试等问题。
朴素 RAG 通常几十行代码即可跑通原型；进阶 RAG 需要引入额外模型和编排逻辑；Agentic RAG 则需要设计智能体角色、工具接口、状态流转和异常处理，开发和调试成本显著更高。
需注意：具体延迟和吞吐取决于模型、数据规模、部署方式等因素，不能脱离实际环境做绝对判断。
所有方案都需要关注身份认证、权限控制、数据隔离、审计日志和加密。差异在于：
朴素 RAG 的运维重点是向量库和大模型服务；进阶 RAG 需要监控多个模块的质量和延迟；Agentic RAG 还需要监控智能体执行轨迹、工具调用成功率、循环次数等。运维复杂度随方案复杂度递增。
成本主要包括：
朴素 RAG 成本最低；进阶 RAG 因增加模型调用而成本上升；Agentic RAG 因多轮调用和工具执行，成本可能显著增加，需要结合业务价值评估。
| 编号 | 方案 | 核心思想 | 适用场景 | 主要优点 | 主要限制 |
|---|---|---|---|---|---|
| 1 | 基础向量检索 RAG | 稠密向量相似度 | 通用问答 | 实现简单 | 对关键词不敏感 |
| 2 | 关键词检索 RAG | 倒排/关键词匹配 | 术语精确匹配 | 可解释性强 | 语义泛化弱 |
| 3 | 混合检索 RAG | 向量+关键词 | 综合检索 | 兼顾语义与精确 | 融合权重需调优 |
| 4 | 滑动窗口分块 RAG | 固定窗口切分 | 长文档处理 | 实现直接 | 可能切断语义 |
| 5 | 语义分块 RAG | 语义边界切分 | 结构复杂文档 | 分块质量高 | 分块成本高 |
| 6 | 查询改写 RAG | 改写/扩展查询 | 模糊问题 | 提升召回 | 可能引入偏差 |
| 7 | 多查询 RAG | 多查询并行 | 多角度问题 | 召回覆盖广 | 延迟和成本上升 |
| 8 | 重排序 RAG | 召回后精排 | 高精度要求 | 提升 Top-K 质量 | 增加推理开销 |
| 9 | 上下文压缩 RAG | 压缩检索内容 | token 敏感场景 | 降噪省 token | 可能丢失信息 |
| 10 | 父子块 RAG | 子块检索父块生成 | 长上下文问答 | 兼顾精度与完整 | 索引设计复杂 |
| 11 | 多路召回融合 RAG | 多检索器融合 | 异构数据源 | 提升鲁棒性 | 融合策略复杂 |
| 12 | 知识图谱增强 RAG | 结构化关系推理 | 关系型问答 | 增强推理能力 | 图谱构建成本高 |
| 13 | 工具调用 RAG | 调用外部工具 | 实时/计算任务 | 扩展能力强 | 工具管理复杂 |
| 14 | 多跳推理 RAG | 多轮检索推理 | 复杂多跳问题 | 处理复杂问题 | 延迟高、易累积误差 |
| 15 | 自适应 RAG | 动态决定检索策略 | 混合难度场景 | 资源利用合理 | 决策逻辑复杂 |
| 16 | 多智能体协作 RAG | 多智能体分工 | 复杂协作任务 | 能力覆盖广 | 架构和调试成本高 |
选型时建议依次回答以下问题：
需要强调：没有“最好”的方案，只有“在当前约束下更合适”的方案。
如果计划从一种 RAG 方案迁移到另一种，需要关注：
RAG 不是单一技术，而是一个从简单到复杂的方案谱系。朴素 RAG 适合快速起步，进阶 RAG 适合对召回质量有更高要求的场景，Agentic RAG 则面向复杂任务和自主决策。理解 16 种方案在架构、功能、性能、安全、运维、成本和适用边界上的差异，才能在技术选型中做出理性判断。建议以业务需求为起点，以评估数据为依据，循序渐进地引入必要能力，避免过度设计，也避免能力不足。