11-GraphRAG、Self-RAG、CRAG 和 Agentic RAG：普通 RAG 的下一步

前面十篇基本把普通 RAG 的工程链路拆完了。从文档处理、chunking、embedding、向量检索，到 Query Rewrite、Hybrid Search、Rerank、上下文工程、幻觉治理、评测体系，再到知识库动态更新、权限、版本和回滚，这些内容组成了一套相对完整的生产级 RAG 视角。

最后一篇适合把视野再往外扩一点。RAG 发展到现在，已经出现很多名字：Naive RAG、Advanced RAG、Modular RAG、GraphRAG、Self-RAG、CRAG、Agentic RAG。第一次看到这些概念时，很容易把它们当成一堆新术语。更稳的理解方式，是先看普通 RAG 暴露了哪些短板，再看这些范式分别在补哪一块。

这一篇的核心判断可以先放在前面：

高级 RAG 范式的价值不来自名称本身，而来自它们对普通 RAG 短板的补位。GraphRAG 强化关系和全局结构，Self-RAG 强化模型自我判断，CRAG 强化检索纠错，Agentic RAG 强化多步规划和工具调用。

从普通 RAG 到高级范式

普通 RAG 的基础链路可以概括成：用户问题进入系统，检索相关文档片段，把片段放进上下文，再让模型生成答案。这个链路很直观，也足够支撑大量知识库问答场景。

但随着问题变复杂，普通 RAG 的局限会逐渐显现。用户可能问跨多个文档的关系问题，单个 chunk 里没有完整答案。用户可能要求总结一个主题在整个知识库里的全局变化，简单 topK 召回很难覆盖全貌。检索结果可能质量不稳定，模型却缺少自我判断。任务可能需要多轮搜索、调用工具、读取结构化数据、逐步验证，而单次检索加单次生成的流程太短。

这些问题推动了不同高级范式出现。它们大致可以放在这样一条能力演进线上：

Naive RAG
  -> Advanced RAG
  -> Modular RAG
  -> GraphRAG / Self-RAG / CRAG / Agentic RAG

这条线不表示严格替代关系。很多系统会同时使用多种能力。比如一个生产 RAG 可以采用 Advanced RAG 的 Query Rewrite 和 Rerank，也可以在部分场景加入 GraphRAG 的关系检索，再用 Agentic RAG 处理复杂任务。关键在于识别问题类型，而非追求范式堆叠。

范式	主要补位
Naive RAG	跑通最小检索增强链路
Advanced RAG	强化检索、排序、上下文和生成约束
Modular RAG	把链路拆成可组合、可路由的模块
GraphRAG	补关系网络、多跳和全局总结
Self-RAG	补是否检索、证据是否足够等自我判断
CRAG	补检索结果评估和纠错
Agentic RAG	补多步规划、工具调用和复杂任务执行

Naive RAG 是最小可用链路

Naive RAG 可以理解为最朴素的检索增强生成。它通常包括文档切分、embedding、向量检索、Prompt 拼接和大模型回答。

这个链路的优势是简单直接。它让模型从只依赖参数知识，变成可以参考外部知识库。对于事实型问答、文档助手、FAQ 检索、内部制度查询，Naive RAG 往往能快速验证价值。只要文档质量还可以，问题也比较直接，向量检索命中相关 chunk 后，模型就能给出比纯生成更可靠的回答。

Naive RAG 的问题也很明显。它通常默认用户 query 已经适合检索，默认向量相似能找到正确证据，默认 topK 候选足够干净，默认模型会忠实使用上下文。这些默认在真实系统里经常被打破。

用户表达和文档表达不一致时，需要 Query Rewrite。关键词、错误码、接口名这类精确匹配场景，需要 Hybrid Search。候选池有噪声时，需要 Rerank。上下文太长或重复时，需要压缩和去重。答案可能越界时，需要引用、拒答和后校验。

所以 Naive RAG 适合做基础链路和概念验证。进入生产后，它通常会自然演进到 Advanced RAG。

Advanced RAG 把检索链路做细

Advanced RAG 的核心，是在基础 RAG 上补齐检索和上下文质量控制。前面几篇已经覆盖了它的大部分内容。

Query Rewrite 让用户问题更适合检索。Hybrid Search 把向量检索和关键词检索结合起来。多路召回从不同角度扩大候选覆盖。Rerank 用更精细的模型或规则重新排序候选。上下文压缩、去重、引用编号和证据布局，让模型看到更清晰的材料。生成阶段再通过 Prompt、拒答和答案校验约束模型。

Advanced RAG 的目标，是把**“找一些相似片段”推进到“组织一组可用证据”**。它仍然主要围绕文本 chunk 工作，但会显著提高普通问答、技术支持、制度查询和产品文档助手的稳定性。

这个阶段最重要的工程意识，是链路可观测。每一次 query 改写、每一路召回、每一次 Rerank、每一段进入上下文的证据，都要能被记录和回放。否则系统变复杂以后，回答错了反而更难排查。

Advanced RAG 能解决很多生产问题，但它对知识结构的理解仍然有限。它主要把文档切成片段，再从片段里找证据。遇到跨文档关系、实体网络、多跳推理和全局总结时，单纯 chunk 检索就会吃力。

Modular RAG 把链路拆成可组合模块

Modular RAG 更像一种工程组织方式。它把 RAG 拆成多个可组合模块：query 理解、query 改写、路由、召回、融合、Rerank、上下文压缩、生成、校验、反馈回流。不同问题可以走不同模块组合。

普通 RAG 往往是一条固定链路，所有请求都走同一套流程。Modular RAG 更强调路由和组合。简单事实问题可以走轻量检索和直接生成，复杂排障问题可以触发多路召回和 Rerank，需要计算或查数据库的问题可以路由到工具调用，高风险问题可以触发严格后校验和人工兜底。

这种模块化有两个好处。第一，它让系统更容易扩展。新增一个关键词检索器、图检索器、SQL 查询器或答案校验器，不需要重写整条链路。第二，它让评测和排查更清楚。每个模块都有输入输出和指标，失败时能定位到具体环节。

Modular RAG 也带来复杂度。模块越多，路由策略越重要，日志和评测也越重要。否则系统会变成一团难以解释的流程。它适合已经有一定规模、需要支持多类问题和多种知识源的场景。

可以把 Modular RAG 理解为 RAG 的工程骨架。GraphRAG、Self-RAG、CRAG 和 Agentic RAG 这些能力，都可以作为模块被接入这个骨架里。

模块	负责什么
Query 理解 / 改写	把用户问题变成可检索表达
路由	判断该走普通检索、图检索、工具调用还是严格校验
召回 / 融合 / Rerank	找证据并排序候选
上下文压缩 / 组织	把证据整理成模型可用的材料
生成 / 校验 / 反馈	生成答案、检查证据支撑并回流失败样本

GraphRAG 补的是关系和全局结构

GraphRAG 的核心思路，是把知识从纯文本片段扩展到实体、关系和图结构。

普通 RAG 主要依赖 chunk 检索。它擅长从局部文本里找答案，但不擅长处理关系网络和全局问题。比如用户问“某个客户相关的所有项目风险有哪些”“这个技术方案影响了哪些下游系统”“A 团队和 B 团队在几个项目里有哪些协作关系”“某个主题在整个知识库里的主要演化脉络是什么”，答案往往散落在多个文档、多个实体和多条关系中。

GraphRAG 会先从文档中抽取实体和关系，例如人、组织、项目、产品、接口、事件、概念，以及它们之间的依赖、归属、影响、引用、协作关系。再围绕这些实体和关系构建图谱。查询时，系统可以沿着图结构找邻居、走路径、做社区摘要，或者把图检索结果和文本 chunk 一起交给模型。

它的价值主要体现在三类问题上。第一类是多跳推理，答案需要从多个实体关系串起来。第二类是全局总结，答案需要覆盖一个主题在整批文档中的整体结构。第三类是关系网络问题，用户关心的核心从单段原文转向实体之间的连接。

问题类型	GraphRAG 的优势
多跳推理	沿实体和关系把分散证据串起来
全局总结	通过社区、主题或图结构覆盖更大范围
关系网络问题	回答实体之间的依赖、影响、归属和协作

GraphRAG 也有明显成本。实体抽取会出错，关系边可能不完整，图谱更新成本高，社区摘要可能过期，权限治理也更复杂。前一篇提到过，图里的实体、关系边和摘要都可能泄露原文权限外的信息。因此 GraphRAG 需要来源追踪、权限继承、版本管理和更新机制。

适合 GraphRAG 的场景，通常是知识之间关系密集、问题经常跨文档、需要全局归纳或多跳推理。对于简单 FAQ 和单文档问答，纯文本 RAG 加上 Rerank 往往已经足够。

Self-RAG 补的是自我判断能力

Self-RAG 关注的是让模型在生成过程中参与判断：是否需要检索、检索结果是否相关、证据是否足够、回答是否被证据支持。

普通 RAG 的流程通常由系统固定控制。用户一问，系统检索，模型回答。这个流程里，模型更多是最终生成器。Self-RAG 的思路是让模型具备一定反思和选择能力，在需要外部证据时触发检索，在证据不足时继续检索或拒答，在回答后判断自身输出是否被证据支撑。

这类能力很适合处理问题类型不固定的场景。有些问题模型本身可以回答，比如简单格式转换或一般性解释；有些问题必须查知识库，比如公司制度、产品版本、内部接口。让模型判断是否需要检索，可以减少不必要检索，也能在需要证据时主动拉取材料。

Self-RAG 还可以用于证据充分性判断。模型看完召回结果后，如果发现证据只覆盖一部分问题，可以触发补充检索。如果证据互相冲突，可以进入拒答或冲突说明。如果答案生成后发现某些结论没有证据支撑，可以删减或重新生成。

它的风险在于判断本身也可能不稳定。模型可能误判自己知道，跳过检索；也可能误判证据足够，生成过度结论。Self-RAG 需要明确的评测、日志和兜底策略。它更适合作为决策辅助模块，而非完全放弃系统侧约束。

从工程角度看，Self-RAG 的价值是把一部分“是否检索、是否继续、是否拒答”的判断前置到模型内部或模型辅助决策中。它和前面讲的幻觉治理、后校验、拒答机制天然相关。

CRAG 补的是检索纠错能力

CRAG 可以理解为 Corrective RAG，重点在于对检索结果进行评估和纠错。

普通 RAG 往往假设检索结果可用。系统拿到 topK 后，就进入 Rerank、上下文和生成。CRAG 会在检索后加入一个判断环节：当前检索结果是否可靠，是否足以回答问题。如果结果质量不够，就触发纠正流程。

纠正方式可以有多种。系统可以重新改写 query，扩大或收紧 metadata filter，启用另一种检索器，使用外部搜索，过滤掉明显无关内容，或者把问题拆成多个子查询再召回。核心是先识别检索不可靠，再采取补救动作。

CRAG 适合检索质量波动较大的场景。比如知识库覆盖不完整，用户问题表达很开放，文档质量参差不齐，或业务需要在内部知识和外部公开信息之间做补充。它可以降低“拿到弱证据仍然硬答”的风险。

但 CRAG 也会增加延迟和链路复杂度。每一次纠错都可能多做一次检索、多一次模型判断、多一次外部调用。对于高频简单问题，没有必要每次都走复杂纠错。更合理的做法，是用置信度触发：只有当召回分数低、候选冲突、引用不足或后校验失败时，才进入纠正流程。

CRAG 和 08 里的幻觉治理关系很近。幻觉治理强调证据不足时要拒答，CRAG 则尝试在拒答前补救检索。它让系统先努力修正证据入口，再决定继续回答或收敛。

检索质量信号	CRAG 可能采取的动作
召回分数低	改写 query 或扩大召回
候选明显偏题	更换检索器或过滤无关候选
证据互相冲突	补充检索、标注冲突或触发拒答
引用不足	继续寻找可支撑结论的证据

Agentic RAG 补的是规划和工具能力

Agentic RAG 把 RAG 从一次检索加一次生成，扩展成可规划、可多步执行、可调用工具的过程。

普通 RAG 适合回答“查一段知识再总结”的问题。现实任务里，用户经常需要更复杂的流程。比如排查一个线上故障，需要先理解报错，再查日志，再查接口文档，再对照最近发布记录，再给出可能原因和处理步骤。又比如生成一份技术方案，需要查多个文档、比较多个版本、读取表格数据、调用计算工具，最后整理成结构化输出。

Agentic RAG 会让模型或调度器先规划任务，再决定调用哪些工具。工具可以是向量检索、关键词检索、图检索、SQL 查询、API 调用、代码执行、网页搜索、工单系统、监控系统。每一步拿到结果后，再决定下一步。

它的优势是灵活。对于多步骤、多数据源、多工具协同的问题，Agentic RAG 能比固定链路更自然。它可以先拆问题，再逐步收集证据，必要时回看前一步结果，最后综合回答。

它的难点也很明显。规划可能走偏，工具调用可能失败，循环次数可能失控，成本和延迟可能上升，安全边界也更复杂。工具权限、参数校验、调用审计、输出校验都要跟上。否则系统虽然看起来更智能，稳定性和可控性反而下降。

Agentic RAG 更适合复杂任务型场景，不适合作为所有问答场景的默认方案。简单知识问答走固定 RAG 链路更省成本，也更容易评测。复杂任务再触发 agentic 流程，通常更符合生产取舍。

这些范式之间可以组合

GraphRAG、Self-RAG、CRAG 和 Agentic RAG 并非彼此隔离。一个成熟系统可能同时使用它们。

比如用户问一个跨项目风险问题。系统可以先通过 Agentic RAG 规划任务，把问题拆成项目、依赖、风险事件几个子任务。每个子任务可以调用 GraphRAG 查实体关系，也可以调用普通向量检索查原文证据。检索结果质量不足时，CRAG 触发改写和补充检索。生成前，Self-RAG 或后校验模块判断证据是否足够，最终答案带引用和适用边界。

这类组合听起来复杂，但本质仍然围绕证据链路。系统先判断要解决什么问题，再选择合适的知识源和检索方式，再整理证据，再生成可追溯答案。高级范式只是把某些环节做得更强。

组合时要防止复杂度失控。每多一个模块，就多一层延迟、成本、日志和失败模式。高级范式应该由问题驱动。普通文本问答的短板在召回和排序，就优先做 Advanced RAG。短板在关系和全局总结，再考虑 GraphRAG。短板在检索不可靠，再考虑 CRAG。短板在复杂任务和工具调用，再考虑 Agentic RAG。

选型要从问题类型出发

选择 RAG 范式时，可以先看问题形态。

如果问题主要是单文档或局部事实查询，Naive RAG 加少量优化就可能够用。如果用户表达和文档表达差异大，或者精确匹配和语义检索都重要，就进入 Advanced RAG。若系统需要支持多种知识源、多类问题和不同处理路径，就需要 Modular RAG 的组织方式。

如果问题经常围绕实体关系展开，或者答案需要跨文档、多跳、全局归纳，GraphRAG 会更有价值。如果系统需要判断何时检索、证据是否充分、答案是否被支持，Self-RAG 的思想可以引入。如果检索结果经常不可靠，需要先评估再补救，CRAG 更贴合。如果任务需要拆解、规划和调用多个工具，Agentic RAG 更合适。

选型还要看工程条件。GraphRAG 需要实体抽取、图谱维护和权限治理。Self-RAG 需要模型判断能力和稳定评测。CRAG 需要可靠的检索质量评估和补救策略。Agentic RAG 需要工具编排、安全控制和执行 trace。没有这些基础，直接上高级范式容易引入新的不稳定。

主要短板	更值得考虑
用户表达和文档表达差异大，召回排序不稳	Advanced RAG
问题经常跨文档、跨实体、需要全局总结	GraphRAG
需要判断是否检索、是否继续、是否拒答	Self-RAG
检索结果经常不可靠，需要先评估再补救	CRAG
任务需要多步规划、查工具、查数据库或调用 API	Agentic RAG

更稳的路线是先把普通 RAG 的地基打牢。文档质量、metadata、chunk、embedding、检索、Rerank、上下文、引用、评测、更新和权限都稳定以后，再针对明确短板引入高级能力。

高级 RAG 怎么讲清楚

讲 GraphRAG、Self-RAG、CRAG、Agentic RAG 时，很容易陷入背定义。更好的方式，是先说普通 RAG 的边界，再说每个范式补什么。

可以先概括：Naive RAG 是基础检索加生成，Advanced RAG 加入 Query Rewrite、Hybrid Search、Rerank 和上下文压缩，Modular RAG 把链路拆成可组合模块。后面的 GraphRAG、Self-RAG、CRAG、Agentic RAG，分别对应关系结构、自我判断、检索纠错和任务规划。

然后展开适用场景。GraphRAG 适合跨文档关系、多跳推理和全局总结。Self-RAG 适合让模型判断是否需要检索、证据是否足够、答案是否被证据支持。CRAG 适合检索结果不可靠时先评估再纠正，必要时补充检索或外部搜索。Agentic RAG 适合多步骤任务，需要拆解问题、调用多个工具并综合结果。

最后补充工程取舍。高级范式会增加构建成本、评测难度、权限风险、延迟和调试复杂度。生产系统不应该因为名字新就引入，而应该从失败样本里找到明确短板，再选择对应模块。

这样的表达会比简单列术语更有说服力。它说明对 RAG 的理解已经从“会用框架”推进到“能按问题设计证据链路”。

小结

这一篇把高级 RAG 范式放回普通 RAG 的短板里理解。Naive RAG 提供最小链路，Advanced RAG 强化检索和上下文质量，Modular RAG 让链路可组合，GraphRAG 引入实体关系和全局结构，Self-RAG 引入模型自我判断，CRAG 引入检索纠错，Agentic RAG 引入多步规划和工具调用。

这些范式没有统一的最佳答案。它们都在回答同一个问题：当基础 RAG 的证据链路不够强时，应该在哪个环节补能力。

至此，这个系列从 RAG 的边界讲到文档入库，从 chunk、embedding、检索、Rerank、上下文工程讲到幻觉治理、评测、动态更新和高级范式。真正需要沉淀的主线仍然是证据链路。RAG 的价值不只在于让模型“多看一点资料”，而在于让问题、证据、生成和验证形成一条可追溯、可评测、可更新、可治理的工程链路。