如果你的项目已经在用 RAG,大概率会有这种体验:最基础的”向量检索 + LLM 生成”能跑,但准确率不够高——用户问个稍微复杂的问题,系统要么检索不到相关内容,要么检索到了但 LLM 没正确理解。怎么办?改 embedding?改 prompt?改 chunk size?
这些”打补丁”的做法只能缓解表面问题。要真正提升 RAG 的能力,你需要从架构层面理解”RAG 不是一个单一方案,而是一整套方案谱系”——不同方案适合不同场景,选对方案比优化单个参数有效 10 倍。
2026 年的 RAG 方案谱系已经非常丰富。从最基础的 Naive RAG,到模块化的 Modular RAG,到 Agent 主导的 Agentic RAG,再到知识图谱增强的 GraphRAG,业界至少有 16 种主流方案。本文就是给你一张完整的”方案图谱”,让你看完能立刻判断:你的项目该选哪种方案,怎么演进。
一、为什么需要”方案图谱”
传统的 RAG 教学只讲”向量检索 + LLM 生成”,但实战中你会发现:
- 简单问句能答,复杂问句答不好(用户问”这两者的关系”,检索系统返回单独片段)
- 多跳问题答不了(问”A 公司和 B 公司收购案的关键人物”,需要组合多个文档)
- 时效性差(文档更新后,旧向量还在用,答案不准)
- 幻觉仍在(LLM 还是会编内容)
这些问题的根源不是 RAG “不够好”,而是”基础 RAG 本来就解决不了这些问题”。要解决,需要更复杂的方案——Naive RAG、Advanced RAG、Modular RAG、Agentic RAG、GraphRAG,各自有不同的设计理念。
理解这个谱系的目的是:让你知道什么时候该”上更复杂的方案”,什么时候”留在基础方案 + 优化参数”就行。盲目上 GraphRAG 可能是过度工程,死守 Naive RAG 又解决不了问题。
二、方案总览:16 种 RAG 方案的分类图谱
下面这张表是业界 2026 年的主流 RAG 方案汇总。我把它们分成 5 大类,共 16 种:
| 大类 | 方案 | 核心特点 |
|---|---|---|
| 基础范式 | Naive RAG | 向量检索 + LLM 生成,最简单 |
| 高级范式 | Advanced RAG | 三阶段优化(预检索 / 检索 / 后检索) |
| 模块化 | Modular RAG | 自由组合模块,灵活度高 |
| Agentic | Simple Agentic RAG | 单 Agent 决定要不要检索 |
| Agentic | Multi-Agent RAG | 多 Agent 协作 + 各自独立检索 |
| Agentic | Adaptive RAG | 根据问题难度动态调整检索深度 |
| Agentic | Corrective RAG(CRAG) | 检索后评估,不对就重查 |
| Agentic | Self-RAG | 模型自己反思”要不要检索、够不够” |
| Agentic | FLARE | 生成中途检查,需要时主动触发检索 |
| GraphRAG | GraphRAG(微软) | 知识图谱 + 社区发现,适合关系问题 |
| GraphRAG | LightRAG | 轻量版 GraphRAG,降低构建成本 |
| GraphRAG | HippoRAG | 类脑记忆机制,适合长文档 |
| 结构化 | SQL RAG | 关系型数据库 + 自然语言转 SQL |
| 结构化 | Hybrid RAG | 向量 + 关键词 + SQL 多源融合 |
| 多模态 | Multi-Modal RAG | 同时支持文本/图像/表格检索 |
| 多模态 | Agentic Multi-Modal | 多模态 + Agent 自主决策 |
下面挑其中最值得深入理解的 8 种详细讲,其他给简要说明。
三、Naive RAG:最基础的范式
这是所有 RAG 的起点,也是大多数企业 RAG 系统的”现状”。
架构:Query → Embedding → 向量检索 → Top-K 文档 → Prompt 拼接 → LLM 生成
优点:
- 实现简单(30 行代码就能跑起来)
- 部署成本低(只要向量数据库 + LLM API)
- 适用面广(60% 简单问答场景够用)
缺点:
- 不擅长多跳问题
- 不擅长关系问题
- 不擅长时效性问题
- 检索质量受 chunk 粒度影响大
适用场景:FAQ、产品手册查询、简单客服问答。
四、Advanced RAG:三阶段优化
业界共识:Naive RAG 不够用,80% 的实战 RAG 至少要做 Advanced RAG 级别。
三阶段优化:
阶段 1:预检索优化(Pre-Retrieval)
在用户问问题后、检索前做的优化:
- Query 改写(查询重写):用 LLM 把口语化查询改成检索友好的形式
- Query 分解:把复杂查询拆成多个子查询
- HyDE(Hypothetical Document Embeddings):让 LLM 先生成”假设答案”,用假设答案的 embedding 去检索
- Query 分类:判断问题类型(简单问句 / 多跳 / 对比),用不同检索策略
阶段 2:检索优化(Retrieval)
- 混合检索:向量 + BM25 关键词(已在 15-3 RAG 实战讲过)
- 多向量索引:同一文档用不同 embedding 模型索引,检索时融合
- 重排序(Rerank):用专门的 rerank 模型(如 Cohere Rerank)把 Top-K 重排
- 元数据过滤:在检索时加 metadata 过滤(日期、来源、类别)
阶段 3:后检索优化(Post-Retrieval)
检索到 Top-K 文档后、喂给 LLM 前做的优化:
- 上下文压缩:把长文档压缩成只含答案部分的短文本
- 重排序:基于多样性和相关性的 MMR(Maximal Marginal Relevance)
- 引用追踪:让 LLM 在生成答案时标注每句话的来源
- 幻觉检测:用辅助模型检测答案中的幻觉
优点:在 Naive RAG 基础上做这些优化,准确率通常能提升 30-50%。
适用场景:大多数企业内部知识库项目都应该做到这一级。
五、Modular RAG:模块化重组
Modular RAG 把检索、生成、压缩、重排等做成了”模块”,你可以在运行时根据需求动态组合。
架构:Routing → 检索模块(可选) → 处理模块链 → 生成模块 → 校验模块
核心思想:把每个环节看成一个独立模块,根据 query 类型动态决定走哪些模块。
举个例子,系统可以这样处理不同 query:
| Query 类型 | 走模块 |
|---|---|
| 简单问句 | 向量检索 → 生成 |
| 多跳问题 | Query 分解 → 多路检索 → 融合 → 生成 |
| 对比问题 | 多路检索 → 结构化对比 → 生成 |
| 时效性问题 | 当前时间检索 + 知识库检索 → 融合 → 生成 |
Modular RAG 的代表实现是 RAGFlow(开源框架),把每个步骤做成可插拔的 Operator,运行时根据 query 选择合适的链路。
优点:灵活度高,适合复杂业务场景。
缺点:实现复杂度也高,需要专门团队维护。
六、Agentic RAG:Agent 主导的动态检索
这是 2026 年最前沿的方案。核心思想:让 Agent 决定”要不要检索、检索几次、用什么工具”。
6.1 Simple Agentic RAG
单 Agent + 检索工具。最简单的形式:
llm=model,
tools=[retrieval_tool, web_search_tool],
)
Agent 自己决定要不要检索、用哪个工具。已在 15-1 LangGraph 实战讲过,这里不重复。
6.2 Multi-Agent RAG
多 Agent 各自检索 + 协作:
- 数据 Agent 查数据库
- 文档 Agent 查知识库
- 网络 Agent 查实时信息
- 主 Agent 汇总所有结果
适合”跨数据源问答”场景。
6.3 Adaptive RAG(自适应检索)
根据问题难度动态决定:
- 简单问题 → 不检索或只检索 1 次
- 中等问题 → 检索 3-5 次
- 复杂问题 → 检索 + 多步推理
代表论文:Adaptive RAG(2024, Soyeong Jeong 等)。核心是用一个轻量级分类器判断”问题复杂度”,再决定检索策略。
6.4 Corrective RAG(CRAG)
检索后评估,不对就重查:
docs = retriever(query)
relevance = evaluator(docs, query) # 评估检索质量
if relevance < threshold:
docs = web_search(query) # 触发网络搜索补救
return generator(docs, query)
关键创新:不假设第一次检索就准。如果质量低,自动触发另一种检索(Web Search、其他知识库)。
6.5 Self-RAG(模型自反思)
让模型自己决定要不要检索、自己评估答案质量:
↓
如果 YES:检索 + 评估证据是否支持[YES/NO/PARTIAL]
↓
评估答案质量 [1-5]
↓
如果 < 阈值,重新检索
Self-RAG 输出答案时附”反思 tokens”,让你能看到模型的判断过程。
6.6 FLARE
边生成边检索,主动补充:
↓
预测下一句(草稿)
↓
如果草稿"置信度低"(用 token 概率判断)
↓
立即检索相关文档 + 重写该句
↓
继续生成
FLARE 适合长答案生成(完整报告、长文章),在生成过程中动态补充信息。
七、GraphRAG:知识图谱增强
普通 RAG 检索”相似文档”,但答不了”实体之间的关系”。GraphRAG 通过知识图谱解决这个问题。
7.1 GraphRAG(微软)
微软研究院 2024 年发布,核心思想:
- 文档 → 图谱:用 LLM 从文档抽取实体(entity)和关系(relation),构建知识图谱
- 社区发现:用 Leiden 算法把图谱分成”社区”
- 多层级摘要:对每个社区生成摘要
- 回答问题时:先定位相关社区,再融合社区摘要 + 具体文档
GraphRAG 特别适合”跨文档、跨实体的关系问题”。比如:
> “我们公司供应链上有哪些公司最近出过负面新闻?”
纯向量 RAG 答不好(需要按关系追溯),GraphRAG 能通过图谱清晰追踪。
7.2 LightRAG
微软 GraphRAG 的轻量版:
- 不预生成社区摘要(降低构建成本)
- 检索时动态构建子图
- 适合中等规模知识库(10 万文档以内)
7.3 HippoRAG
借鉴人脑海马体机制,适合长文档检索:
- 用 PageRank 算法在图谱上做”激活传播”
- 从种子实体出发,扩散到相关实体
- 解决”问 A 但答案藏在跟 A 间接相关的实体”的问题
八、结构化方案:SQL RAG 和 Hybrid RAG
很多企业内部数据同时存在向量库和关系数据库。
8.1 SQL RAG
让 LLM 把自然语言转 SQL,然后查关系数据库:
↓
LLM: SELECT customer, SUM(amount) FROM orders WHERE year=2026 GROUP BY 1 ORDER BY 2 DESC LIMIT 1
↓
执行 SQL
↓
LLM 把结果转自然语言
适合数字/事实类查询(销售额、库存、客户数),这种问题向量检索效率很低。
8.2 Hybrid RAG(混合源)
把 SQL RAG + 向量 RAG + 关键词检索融合,根据问题自动路由:
"上个月退款总额?" → SQL RAG
"产品 X 的退款政策 + 上个月退款次数" → 向量 + SQL 融合
企业场景下,Hybrid RAG 是最常见的形态,因为企业数据天然就是多源的。
九、多模态方案
9.1 Multi-Modal RAG
支持检索图片、表格、扫描 PDF 中的图表:
- 用多模态 embedding 模型(如 CLIP、SigLIP)
- 把图片/表格的描述也向量化
- 检索时同时返回文本+图片+表格片段
9.2 Agentic Multi-Modal
多模态 + Agent 决策:Agent 看到一张图,可以主动生成 OCR / 图像描述 / 表格提取,辅助后续检索。
适合医疗影像、产品设计图、监控视频等场景。
十、实战决策:怎么选对方案
看完 16 种方案,你大概率会问”我到底选哪个?”。下面的决策框架能帮你。
决策流程
├─ 简单 FAQ → Naive RAG
├─ 中等查询 → Advanced RAG
└─ 复杂多跳/关系问题 → Advanced RAG + 进一步选下面
2. 数据源是结构化还是非结构化?
├─ 全部文档 → 向量 RAG
├─ 全部数据库 → SQL RAG
└─ 混合(文档 + 数据库) → Hybrid RAG
3. 有关系/实体问题吗?
├─ 极少 → Advanced RAG
└─ 经常 → GraphRAG
4. 需要 Agent 自主决策吗?
├─ 固定流程 → Modular RAG
└─ 动态判断 → Agentic RAG
实操建议
- 大多数项目:从 Advanced RAG 开始,准确率够用
- 关系类问题多:加 GraphRAG
- 数据源复杂:加 Hybrid RAG
- 需要自适应:加 Agentic RAG
不需要一开始上最复杂方案。先 Advanced RAG 跑通,再根据痛点加分模块。演进路径:
↓ 准确率不够
Advanced RAG(2 周:加混合检索 + 重排 + 改写)
↓ 关系类问题答不好
+ GraphRAG(3 周:构建图谱,接入)
↓ 数据源多源
+ Hybrid RAG(2 周:接 SQL、关键词)
↓ 复杂查询
+ Agentic RAG(3 周:让 Agent 自主决策)
总周期 3 个月,从 Naive 到企业级。
十一、常见误区
误区 1:以为上 GraphRAG 就能大幅提升准确率——错。GraphRAG 解决的是”关系问题”,如果你没有这种问题,上 GraphRAG 是浪费。
误区 2:以为 Self-RAG 一定比 Advanced RAG 好——错。Self-RAG 适合”答案需要谨慎”的场景(医疗、法律),很多企业内部 RAG 用不到这种能力。
误区 3:以为 Agentic RAG 是终极方案——错。Agentic RAG 增加了复杂度和延迟(每次要 Agent 决策),简单场景反而拖慢响应。80% 的企业项目,做到 Advanced RAG + GraphRAG 就够了。
误区 4:以为”上越复杂的方案越好”——错。复杂度是负债。每多一个模块,debug 难度 +1,维护成本 +1。只选你需要的复杂度。
十二、评估:怎么知道哪种方案对你最有效
光看方案没用,得用评估说话。
评估指标
- 检索指标:
- Recall@K:Top-K 包含正确答案的比例
- MRR(Mean Reciprocal Rank):正确答案的平均排名
- NDCG(Normalized Discounted Cumulative Gain):综合排名质量
- 生成指标:
- 答案忠实度(答案是否被检索到的内容支持)
- 答案相关性(答案是否回答了问题)
- 幻觉率(答案中无支持内容的比例)
- 端到端指标:
- 用户满意度
- 首次命中率
- 平均对话轮数
评估工具
- RAGAS:开源 RAG 评估框架,使用简单
- TruLens:提供 LLM-as-judge 评估
- DeepEval:支持多种 RAG 评估指标
- 自建 test set:50-100 个真实用户问题,人工评分
实操流程
- 准备 test set(100 个真实问题 + 标准答案)
- 跑每种 RAG 方案,记录指标
- 对比不同方案,选效果最好且复杂度可接受的
- 持续评估,每次改动后回归
十三、行业趋势:2026 下半年的 RAG 方向
趋势 1:Agentic RAG 成为主流
越来越多企业级项目用 Agentic RAG 替代 Advanced RAG,主要因为 Agent 决策更灵活、能处理复杂场景。
趋势 2:多模态 RAG 进入企业
视觉/表格/扫描件的多模态检索成为标配(尤其是金融、法律、医疗行业)。
趋势 3:GraphRAG 与 Agentic 融合
GraphRAG + Agent 自主决策是 2026 下半年最前沿的组合——Agent 在图谱上游走,动态决定查哪些实体。
趋势 4:RAG 与 Fine-tuning 边界模糊
越来越多项目用 RAG + Fine-tuning 混合模式:
- RAG 提供实时知识
- Fine-tuning 提供领域表达风格、术语习惯
十四、下一步
学完这篇,你已经掌握整个 RAG 方案谱系。接下来的几个方向:
方向 1:选一个方案,跑通你的项目
别再纠结”哪个最好”,先用 Advanced RAG 跑通生产,再根据痛点演进。
方向 2:学 GraphRAG 实战
下次我会写一篇 GraphRAG 实战,讲清楚怎么从 0 搭建企业级 GraphRAG 系统。这是 2026 年最硬核的 RAG 形态。
方向 3:搭评估体系
没有评估的 RAG 系统是瞎做。优先把 RAGAS / TruLens 集成进项目。
方向 4:学 Agentic RAG 实战
基于 LangGraph 搭一个完整的多 Agent RAG 系统,把 RAG + Agent + MCP 都用上。
推荐路径
- 想从零开始:回看 15-3《RAG 实战》,搭基础版
- 想选对方案:对照本文的决策流程,选最合适的 1-2 种
- 想搭生产级:GraphRAG + Agentic + 评估,这是 2026 年的标配
- 想成为 RAG 专家:学 LangGraph + 多 Agent + 可观测性
最后一句话:RAG 不是”一个工具”,而是”一类方案”。你做的不是”一个 RAG 系统”,而是”选择一套适合你业务的 RAG 方案组合”。理解这点,你的 RAG 项目才不会成为又一个”准确率永远卡在 70%”的失败品。
下次我们会讲 GraphRAG 实战——把今天的方案图谱具体化,让你看到怎么从 0 搭一个能回答”跨实体、跨文档、关系类问题”的 RAG 系统。那会是整个 AI 学习系列的最后一篇,也是最难的一篇。
(综合 RAGAS、TruLens、LangChain RAG 文档、微软 GraphRAG 论文、Agentic RAG 综述、2026 RAG 行业调研整理)
我要评论