在上一篇中，我们对比了 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 系统的生产化议题。