RAG 架构的演进起点：朴素流水线的致命缺陷
RAG（Retrieval-Augmented Generation，检索增强生成）本质是解决大模型知识截止问题的技术方案——通过在提问时向量检索企业内部文档，将相关片段拼入 prompt 供 LLM 生成答案。最朴素的 RAG 实现是三条固定流水线：用户问题 → 向量检索 top-k → 拼接 prompt → LLM 生成答案。在 LangGraph 中，这表现为两个写死 next 状态的节点，使工作流无法动态调整。
五个典型卡壳场景暴露了固定架构的根本局限：
- 简单问题仍执行完整检索生成流程，浪费计算资源与 token 开销
- 检索结果无评估环节，错误内容直接误导 LLM 输出
- 多步推理问题（如《天龙八部》角色关系链推理）因单次检索而失效
- 纯语义检索无法区分「高血糖」与「低血糖」等精确实体的语义对立
- 知识库缺失内容时，LLM 会虚构答案而无 fallback 机制
演进逻辑：控制权从代码交给系统自身
这五个瓶颈指向同一根因：流程写死，缺乏决策能力。要突破这些限制，需将 RAG 升级为可思考、可判断、可纠错的智能系统。文章提出三层演进路线图：
- Naive RAG：固定三件套流水线，无决策逻辑
- Advanced RAG：在固定流程中优化组件（如查询改写、HyDE、混合检索、重排），将检索精度打磨到极限，但控制权仍在开发者预设规则中
- Agentic RAG：引入决策模块动态决定是否跳过检索、切换检索策略、甚至调用外部工具（如联网搜索），控制权从写死代码转向系统自主判断
值得注意的是，升级核心不在于「加了多少组件」，而在于「控制权交给谁」。当检索结果质量差时，Naive RAG 被迫用错误数据生成，而 Agentic RAG 可动态启动纠错机制——这本质上是系统从「执行者」向「思考者」的质变。
意外反差：最简单方案反而最耗资源
矩阵语义检索在专业术语场景暴露出反直觉缺陷：「高血糖」与「低血糖」向量相似度极高，导致语义检索将「低血糖该吃什么」错误匹配到高血糖文档片段。此时，传统关键词匹配（如 BM25、like 查询）反而更准——语义相近≠概念正确，这种反差揭示纯向量检索的天然盲区。
另一层反差在于资源消耗：语义上简单的数学题（1+1=？）触发完整 RAG 流程，经历向量检索、prompt 拼接、LLM 生成三阶段，而人类工程师一眼可判定无需检索的简单问题，在固定流程中毫无例外。朴素 RAG 的「万能」恰恰是其低效根源——统一处理所有问题剂量的思维，忽视了问题复杂度的连续谱系。
落地建议：按场景选择演进阶段
- 适合即刻采用 Agentic RAG 的场景：需处理混合复杂度问题（含简单问答、多步推理、外部知识补充）、对幻觉敏感（如金融/医疗客服）、知识库覆盖不完整（需联网兜底）
- 适合继续使用朴素 RAG 的场景：问题类型高度单一（纯文档问答）、计算资源极度受限、容错率高且输出不影响业务决策
- 值得观望 Advanced RAG 的团队：已有稳定知识库且追求检索精度优化，但尚未准备好引入决策复杂度
写在最后
RAG 从流水线走向智能体，反映的是 LLM 应用从「功能实现」到「可靠交付」的范式转移。当企业级 Agent 普遍接入 RAG 时，系统的容错能力与决策灵活性，将成为比单一模型性能更重要的竞争力载体。