在上一篇中，我们讨论了Agent类型选型与架构设计中的伦理安全约束。当Agent需要基于外部知识回答问题时，RAG几乎是绕不开的组件。但打开技术社区，传统RAG、Graph RAG、Agentic RAG、AUTO-RAG、ChunkRAG、FastRAG、HtmlRAG等名词扑面而来，开发者很容易陷入“哪个先进选哪个”的误区。本篇作为系列第36篇，不重复概念科普，而是从工程落地视角，梳理不同RAG形态的适用场景与迁移判断框架。
一、先厘清三类主流形态的核心差异
根据公开资料的系统梳理，当前RAG技术形态可归为三个层次：
传统RAG：最基础的“检索-拼接-生成”流水线。资料指出其能为大模型提供背景信息以减少幻觉，但存在局限。适合知识库相对静态、问题类型集中的场景。
Graph RAG：结合向量检索与图检索，增强关系推理能力。资料提到其利用知识图谱处理实体间关系，适合需要多跳推理或关系型知识查询的任务。
Agentic RAG：引入智能体实现多轮推理与工具调用，基于LLM自主决策迭代检索。资料将其描述为从静态流程走向具有理解、推理、决策能力的形态，可克服传统RAG的局限。
此外，资料还提及AUTO-RAG（LLM自主决策迭代检索）、ChunkRAG（语义分块与混合过滤提升准确性）、FastRAG（融合模式学习与KG查询优化半结构化数据处理）、HtmlRAG（保留HTML结构信息）等变体。这些可视为在特定环节的优化方案，而非替代性架构。
二、选型判断框架：从问题特征出发
工程选型不应以“技术先进度”为唯一标尺，而应回到业务问题的特征。资料中提到的落地四步框架（知识库构建、检索优化、混合策略、落地实施）提供了可操作的切入点。结合工程经验，建议从以下维度判断：
- 查询复杂度：若用户问题多为单点事实查询（如“某产品保修期多久”），传统RAG加良好分块即可满足。若问题涉及多实体关系（如“A供应商的零件在B工厂的质检记录”），Graph RAG的关系推理能力更有价值。
- 知识库动态性：静态知识库适合传统RAG；若知识频繁更新且需要多轮澄清，Agentic RAG的自主迭代检索更合适。
- 对可追溯性的要求：资料强调RAG能提升回答的可追溯性。传统RAG的检索片段可直接引用；Agentic RAG因多轮工具调用，需额外设计轨迹记录机制，否则追溯链会变长。
- 延迟与成本预算：Agentic RAG的多轮推理与工具调用必然增加延迟和token消耗。资料未给出具体数值，但工程上需在体验与成本间权衡。
三、从传统RAG迁移到复杂形态的工程因素
当传统RAG效果触顶，考虑升级时，以下工程因素比算法选择更关键：
知识库构建的代价：Graph RAG需要构建知识图谱，涉及实体识别、关系抽取与图存储。资料提到知识库构建是落地四步框架的第一步。迁移前需评估：现有文档能否支撑图谱构建？维护图谱的持续成本是否可接受？
检索优化的混合策略：资料提及混合策略是落地框架的一环。从传统RAG迁移时，可先引入混合检索（如向量+关键词）和重排序，再考虑图或Agent。ChunkRAG的语义分块与混合过滤可作为过渡优化，成本低于架构级改造。
Agentic RAG的编排复杂度：Agentic RAG引入智能体后，检索不再是单次调用，而是多轮决策。工程上需考虑：工具调用的超时与重试、多轮检索的终止条件、检索失败时的降级路径。这些在传统RAG中不存在，需在Agent Runtime层增加相应控制逻辑。
评测与监控的适配：传统RAG的评测相对直接（检索命中率、答案相关性）。Agentic RAG需评测多轮决策质量，Graph RAG需评测关系推理准确性。资料未提供具体评测指标，但工程上应在上线前建立对应评测集，否则无法判断迁移是否真正带来收益。
四、可执行的选型建议
综合资料与工程实践，给出以下判断路径：
- 起步阶段：优先传统RAG，配合语义分块与混合检索，快速验证业务价值。
- 遇到关系推理瓶颈：评估Graph RAG，先小范围构建领域图谱，验证关系查询收益。
- 需要多轮澄清或工具协同：引入Agentic RAG，但必须在Agent Runtime中设计好检索工具的超时、重试与降级。
- 半结构化数据为主：可关注FastRAG的模式学习与KG查询优化思路。
- 网页内容保留结构：HtmlRAG的HTML保留策略值得参考。
需要强调的是，资料中提及的各类变体均有其核心思想，但官方资料未提供统一的性能对比数据。选型时应以自身业务评测为准，避免盲目追新。
五、与系列后续的衔接
本篇聚焦RAG形态的选型判断。无论选择哪种形态，检索工具最终都要接入Agent的Tool Calling体系，并受Memory与Checkpoint机制管理。后续文章将继续深入Agent Runtime中检索工具的生命周期管理，以及如何在Control Plane中监控RAG链路的健康度。