Agentic RAG 与朴素 RAG：当你的检索系统应当自主思考时
内容提要
大语言模型易产生幻觉，检索增强生成（RAG）通过外部知识降低错误。但标准RAG流程线性、仅单次检索，难以应对多步推理、跨文档综合等复杂查询。Agentic RAG将模型变为自主推理引擎，形成“规划—执行—评估—循环”，具备查询路由、查询分解、自我反思与工具调用四种机制。简单查询宜用标准RAG，复杂高精度场景宜用Agentic RAG，也可混合使用。
延伸解读
朴素 RAG 的线性瓶颈
朴素 RAG 采用“检索-读取-生成”的线性流程，仅执行一次检索。当查询需要多步推理或跨文档综合时，单次检索可能无法返回正确上下文，导致模型基于不完整信息生成答案。文章指出，这种架构无法识别检索失败，也无法尝试其他检索策略，因此在复杂场景下容易产生幻觉或给出无帮助的回复。
Agentic RAG 的四种核心机制
Agentic RAG 通过四种机制将检索变为自主循环：查询路由决定数据源，查询分解将复杂问题拆解为子问题，自我反思评估检索结果并决定是否重试，工具调用则允许模型在推理中调用外部 API 或数据库。这些机制共同解决了线性检索无法应对的多步推理和跨源综合问题，使系统能动态调整检索策略。
成本与能力的权衡
选择朴素 RAG 还是 Agentic RAG 需权衡成本与能力。朴素 RAG 延迟低、成本可预测，适合简单单跳查询和高并发场景；Agentic RAG 涉及多次 LLM 调用和工具使用，延迟和 token 成本更高，但能处理复杂、高精度的任务。文章建议混合使用：简单查询走快速管道，复杂或高风险查询启用智能体循环。
Q&A
什么是朴素RAG？它的基本流程是怎样的？
朴素RAG（标准RAG）遵循一个固定的三阶段流程：检索→阅读→生成。用户提交查询后，系统将其转换为向量嵌入，在向量数据库中进行相似性搜索，检索出最相关的top-k文档块，并将这些块作为上下文传递给大语言模型（LLM），模型基于检索到的内容生成回答。
朴素RAG在哪些情况下会失效？
朴素RAG的核心弱点是线性单次检索。当查询需要多步推理、跨多个文档综合信息，或者初始查询表述不佳时，它无法恢复。具体失败场景包括：单次检索限制（一次检索不成功就无法重试）、多跳推理失败（如需要先识别Meta收购了WhatsApp，再检索Meta的欧盟监管政策，单次向量搜索难以桥接）、以及检索结果不相关时，模型要么忽略上下文产生幻觉，要么回答“信息不足”。
Agentic RAG与朴素RAG的核心区别是什么？
核心区别在于：朴素RAG是一个线性管道，模型只看到一次检索到的上下文；而Agentic RAG是一个循环（规划→执行→评估→重复），将LLM视为自主推理引擎，主动编排整个检索过程。模型不再是被动的上下文消费者，而是决定检索什么、从哪里检索、结果是否足够好，以及如果不够好该怎么办。检索从固定的预处理步骤转变为动态的、自我纠正的过程。
Agentic RAG通过哪些机制实现自主性？
Agentic RAG通过四种机制实现自主性：1）查询路由：决定在哪个数据源或工具中搜索；2）查询分解：将复杂问题拆解为可独立回答的子问题，逐步检索；3）自我反思与批判：评估检索结果是否真正回答问题，若不足则重写查询并重新检索，直到达到置信度阈值或迭代上限；4）工具使用与函数调用：在推理过程中调用外部工具（如计算器、网络搜索、SQL执行器、内部API）来辅助回答。
在什么情况下应该选择朴素RAG而不是Agentic RAG？
选择朴素RAG的情况包括：查询定义明确且为单跳；速度是首要用户期望（如面向消费者的聊天机器人、内部FAQ系统）；知识库结构良好，单次语义搜索能可靠地找到正确信息；预算限制使得每次查询多次调用LLM不可持续。
在什么情况下应该选择Agentic RAG？
选择Agentic RAG的情况包括：查询需要跨多个文档或数据源进行推理；用例要求高准确性而非快速响应（如金融分析、法律研究、医学文献综述）；用户会提出设计时无法预料的复杂开放式问题；系统需要与外部工具、API或实时数据交互；错误答案会带来重大业务或声誉风险。
能否混合使用朴素RAG和Agentic RAG？
可以。对于许多生产系统，混合方法是有意义的：将简单、高容量的查询路由到快速的朴素管道，而将系统标记为复杂或高风险的查询保留给Agentic循环处理。这样可以在成本和能力之间取得平衡。
