RAG 选型最容易走偏的一步，是把“传统 RAG、Graph RAG、Agentic RAG、RAG-Fusion”当成一条单纯的技术代际路线。当前输入提供的 CSDN“RAG”搜索抽样中，共出现 29 条结果，近 180 天 2 条、近 365 天 5 条；Top 结果里同时出现了传统 RAG、Graph RAG、Agentic RAG、Advanced RAG、Modular RAG、Naive RAG、RAG-Fusion 等提法，日期跨度从 2024-01-07 到 2026-01-12。这个抽样更适合说明术语正在并行演化，而不是证明某一种形态已经形成统一官方分类。
需要先限定事实边界：这些结果只有标题和摘要，不是官方产品文档。因此下文不会给出“某产品支持 Graph RAG/Agentic RAG”的结论，也不会比较具体版本、参数或性能。下面讨论的是：在这些资料反复出现的形态之间，如何按业务约束做工程判断，以及真正选型前应该向官方资料核验什么。
先把形态拆成维度，而不是按名词站队
现有摘要中，传统 RAG、Graph RAG、Agentic RAG 被放在“工作原理、流程差异与适用场景”下讨论；Advanced RAG、Modular RAG、Naive RAG 被作为演进阶段或复杂度分类；RAG-Fusion 被描述为通过“多查询生成和倒数排序融合”改善搜索效率和搜索简化。把这些提法放在一起，至少可以抽出几个判断维度：
- 检索单元是什么：文本块、实体关系、多路查询结果。
- 控制流是单轮还是多轮：一次检索后生成，还是规划、迭代、工具调用。
- 知识结构是扁平还是图：向量库、关键词索引、图结构，或混合。
- 查询复杂度：单事实问答、多跳关系、全局聚合、含糊需求、需要执行动作。
- 可追溯要求：是否需要引用来源、关系路径、工具调用记录。
- 延迟、成本与运维上限：在线问答是否严格秒级，是否允许多次模型调用和检索。
- 更新与权限：知识更新频率、增量构建成本、实体级权限继承。
从工程角度看，这些维度比“传统、Graph、Agentic 哪个更强”更有用。因为几种形态并不是完全互斥：Agentic RAG 可以在控制流上引入代理，Graph RAG 可以在知识结构上引入图，RAG-Fusion 可以在检索层做多查询与融合；它们可以组合，也可以只选其中一个模块。
各形态的适用条件
传统 RAG
传统 RAG 在工程实现中通常可以按“查询—检索—拼接上下文—生成”来理解。它适合问题相对明确、答案主要来自文档片段、延迟敏感、希望快速验证链路的场景。摘要中把传统 RAG 与 Graph RAG、Agentic RAG 并列讲解，也说明它仍是基础参照。它的主要风险不在“老”，而在于：单查询召回不足时答案遗漏；跨文档关系、多跳推理、全局聚合类问题弱；如果知识库更新频繁，分块、索引和重排策略会迅速成为瓶颈。
进阶模块化 RAG
搜索结果中出现了 Advanced RAG、Modular RAG、Naive RAG 等提法，也提到分块策略、检索优化、混合策略。一个务实判断是：如果传统 RAG 已经能跑通，但评测显示召回、排序或查询表达有问题，不必直接跳到 Agentic。可以先加查询改写、混合检索、重排、路由等模块。这类演进的风险是模块越多，调试面越大，必须保留分阶段评测。
Graph RAG
当前摘要只明确说 Graph RAG 是并列形态之一，并提到“特点”和适用场景，没有提供官方图模式、查询语言或构建流程。因此可以做的工程判断是：当业务问题大量依赖实体关系、多跳路径、跨文档关联、主题聚合，而文本块检索反复漏召回时，才值得评估图结构。图结构会引入额外成本：实体与关系抽取、消歧、增量更新、权限映射、图查询性能。若知识更新频繁且实体不稳定，图的维护成本可能高于收益。
Agentic RAG
摘要中把 Agentic RAG 描述为将 AI 智能体引入 RAG 流程，并与普通 RAG 对比，还提到工作原理、架构与实施方法。它适合的不是“所有复杂问答”，而是需要规划、迭代检索、调用外部工具、处理含糊需求或多步骤任务的场景。代价同样明确：控制流复杂，错误会跨步骤传播；模型调用次数和检索次数可能上升；评测不能只看最终答案，还要看中间步骤是否合理。若业务对延迟和单位成本极敏感，Agentic RAG 应作为受控实验，而不是默认架构。
RAG-Fusion
摘要中 RAG-Fusion 的关键词是“多查询生成”和“倒数排序融合”，目标是改善搜索效率低和搜索简化。它适合用户表达多样、单查询召回覆盖不足、同义词和上下文改写影响较大的检索场景。工程上要重点核验：多路查询如何生成、融合时如何处理不同检索器的分数、去重和截断策略、额外检索带来的延迟与成本。它更像检索层增强，不一定需要改成 Agentic 控制流。
一个约束驱动的选型顺序
可以按下面顺序做判断，而不是按名词热度升级：
- 写下业务问题的失败模式。是漏召回、排序差、多跳断裂、全局总结不准，还是需要执行动作？不同失败模式对应不同形态。
- 默认从传统 RAG 或基础模块化 RAG 起步。只要业务问题以单文档片段问答为主，且延迟敏感，更复杂的控制流未必划算。
- 如果失败模式是“单查询召回不足”，优先评估查询改写、多查询、RAG-Fusion、混合检索和重排。
- 如果失败模式是“关系和多跳”，评估 Graph RAG，但先验证图数据源、更新频率和权限模型是否成立。
- 如果失败模式是“任务需要规划、工具调用、多轮澄清”，评估 Agentic RAG，同时设置最大迭代、预算和回退策略。
- 每次升级都保留离线评测集和线上观测。没有评测，形态升级只会变成不可解释的复杂度。
这里真正值得关注的是触发条件，而不是形态名称。一个团队可以考虑的升级信号包括：评测集中跨文档问题持续失败；答案需要列出关系路径或证据链；用户问题需要多轮澄清；检索后仍需调用外部业务系统；单查询融合后召回仍不足。反过来，如果只是普通 FAQ、政策查询、文档摘要，传统 RAG 加基础重排通常更可控。
选型前必须向官方资料核验的事实
当前输入没有提供任何具体产品的官方文档，因此下面这些不能从搜索结果摘要推出，必须逐项查官方资料：
- 是否支持图结构、多路检索、融合排序、重排和查询改写。
- Agent 控制流是否支持工具调用、迭代、最大步数、失败重试和中止。
- 检索与生成链路的可观测性：是否能看到召回片段、融合分数、工具调用和引用来源。
- 权限与数据隔离：实体、文档、图节点是否继承同一套权限。
- 成本模型：嵌入、向量存储、图存储、LLM 调用、检索调用分别如何计费。
- 限制条件：上下文窗口、并发、更新频率、索引重建、超时。
- 评测能力：是否支持离线评测、追踪或反馈闭环。
只有这些事实明确后，才能把“传统 RAG / Graph RAG / Agentic RAG / RAG-Fusion”变成可落地的选型，而不是术语选择。
从当前资料能得到的结论很有限：这些形态正在被并行讨论，且各自强调不同流程和适用场景。不能从摘要推出某形态一定优于另一形态，也不能推出具体产品支持范围、性能数字或企业采用率。更稳妥的路径是：先用业务约束定义失败模式，再从检索层、知识结构层和控制流层分别选择增强模块，最后用官方文档验证产品能力边界。