在上一篇中我们对比了 LangGraph 与 Ollama 在 Agent 编排与本地推理层面的选型差异。当 Agent 需要接入外部知识时RAG 仍是当前最主流的方案。但传统 RAG 的“一次检索、一次生成”范式在面对多跳推理、半结构化数据、复杂关系查询时已显乏力。本篇作为系列第 24 篇基于公开资料中出现的六类 RAG 变体梳理其核心思想与差异并给出面向中国 AI 开发者的选型决策框架。六类 RAG 变体的核心思想根据资料当前前沿 RAG 变体主要包括以下六类Agentic RAG引入智能体实现多轮推理与工具调用。它不再将检索视为一次性动作而是让 Agent 根据中间结果自主决定是否继续检索、调用何种工具、如何整合信息。资料指出Agentic RAG 使 RAG 从静态流程转向具有理解、推理、决策能力的动态系统。AUTO-RAG基于 LLM 自主决策迭代检索。与 Agentic RAG 的智能体架构不同AUTO-RAG 更强调由 LLM 判断何时需要检索、检索什么、是否满意形成“检索-评估-再检索”的迭代循环。ChunkRAG通过语义分块与混合过滤提升准确性。传统 RAG 的固定长度分块容易割裂语义ChunkRAG 在分块阶段引入语义边界识别并在检索阶段结合多种过滤策略减少无关上下文注入。FastRAG融合模式学习与 KG 查询优化半结构化数据处理。资料提到 FastRAG 面向半结构化数据结合知识图谱查询与模式学习在保证速度的同时提升对结构化信息的利用效率。Graph RAG结合向量与图检索增强关系推理。它利用知识图谱中的实体关系弥补向量检索在关系推理上的不足适合需要多跳关系查询的场景。HtmlRAG保留 HTML 结构信息。资料显示 HtmlRAG 在检索与生成过程中保留 HTML 的层级与标签信息而非简单抽取纯文本从而提升对网页类文档的理解精度。从传统 RAG 迁移的工程维度选型不是选“最先进”而是选“最匹配”。从传统 RAG 迁移到上述变体时建议从以下维度评估检索策略传统 RAG 是单次向量检索。Agentic RAG 和 AUTO-RAG 引入多轮迭代需要 Agent Runtime 支持工具调用与状态管理Graph RAG 需要图查询引擎FastRAG 需要 KG 查询优化。检索策略的变化直接决定系统复杂度。数据形态如果知识库以纯文本为主ChunkRAG 的语义分块收益明显如果包含大量网页HtmlRAG 的结构保留更有价值如果实体关系密集Graph RAG 或 FastRAG 更合适。数据形态是选型的第一约束。系统复杂度Agentic RAG 和 AUTO-RAG 需要额外的规划、评估与循环控制逻辑对 Agent Runtime 的 Checkpoint、Memory 能力要求更高。Graph RAG 需要维护图谱构建与更新管道。FastRAG 需要模式学习与 KG 查询的协同。复杂度越高运维与调试成本越大。延迟与成本多轮检索与图查询会显著增加延迟。Agentic RAG 的迭代次数不可控时Token 消耗可能成倍增长。生产环境需设置最大迭代次数与超时回退。可解释性与可追溯性Graph RAG 的关系路径天然可解释Agentic RAG 的决策链需要额外日志记录。若业务要求答案可追溯需在选型时纳入考量。选型决策框架结合系列定位——构建可进入生产环境的 AI Agent 系统——建议按以下顺序决策明确查询类型事实型单跳查询传统 RAG 或 ChunkRAG 足够多跳关系查询优先 Graph RAG需要动态决策的复杂任务考虑 Agentic RAG 或 AUTO-RAG。评估数据形态纯文本、网页、半结构化数据分别对应不同变体。核算系统预算包括延迟预算、Token 预算、运维人力预算。设计回退路径任何变体都应保留降级到传统 RAG 的能力避免单点故障。小流量验证在生产环境用真实查询分布做 A/B 测试而非仅凭离线指标决策。需要强调的是上述六类变体的具体技术细节如 ChunkRAG 的分块算法、FastRAG 的模式学习机制在本次资料中仅有概述后续需通过官方论文或文档核验。选型框架本身是工程分析不构成对任一变体性能的绝对判断。在下一篇文章中我们将继续深入 Agent 系统的生产化议题。
