为什么 RAG 不应该只是检索一次？Agent 如何自动改写问题、补充检索和验证答案？
先说清楚这道题在考什么：它考察你对 RAG 系统进化的理解深度。普通 RAG 的"问-查-答"线性流程你肯定知道，但面试官想看你是否理解为什么一次检索不够用、Agent 如何自主决策、以及 Query 改写和结果验证的具体机制。
这篇文章把 Agentic RAG 的核心逻辑讲透，帮你搞定这道综合深度题。
1. 普通 RAG 的单次检索为什么不够用
先看普通 RAG 的流程：
用户问问题 → 向量数据库检索 → 把检索结果塞给 LLM → 生成答案
这套流程处理"2023 年苹果公司的营收是多少"这种单跳查询没问题。但一旦问题稍微复杂一点，它就露馅了。
什么问题它处理不了？
"对比苹果和谷歌 2023 年的营收增长率"——这需要两步操作：先查苹果的数据，再查谷歌的数据，然后做计算对比。普通 RAG 只检索一次，根本完不成。
"过去三年营收持续增长的公司有哪些？"——需要跨多个时间点筛选，普通 RAG 做不到。
"这份合同里的关键风险条款是什么？"——需要理解文档结构并做摘要，普通 RAG 只会匹配关键词。
检索失败的隐形风险更可怕
普通 RAG 还有一个致命问题：它不知道自己检索失败了。
当返回的文档根本不相关时，它会硬着头皮基于错误信息生成答案，你以为它在认真回答，其实是在"一本正经地胡说八道"。
这种错误比直接说"不知道"危害大得多。
用一个场景来类比：想象你带着一本百科全书去考试，但规则是只允许翻一次就答题。"对比 A 和 B 的差异"这种问题，你根本没法答。
普通 RAG 就是这样被限制了。
2. Agentic RAG——让 Agent 自主决定"查什么、怎么查"
那怎么解决这个问题？
答案很简单：不要只查一次，让 Agent 决定要不要继续查。
Agentic RAG 的核心变化是把"检索-生成"的线性流程，变成 Agent 驱动的多轮循环。
它的逻辑是这样的：
- Agent 接收用户问题
- Agent 判断需要什么信息，生成查询语句去检索
- Agent 评估检索结果是否足够、是否相关
- 如果不够，Agent 会改写查询继续检索
- 如果相关但不够完整，Agent 会补充检索
- 最后 Agent 验证答案来源可靠，再生成最终回答
关键点在于：Agent 能判断检索结果的质量，能决定下一步行动。
用个类比：普通 RAG 像一个死板的考生，翻一次书就答题。而 Agentic RAG 像一个老练的考生——遇到不确定的题会先思考要查什么，查完会判断对不对，不对就换个角度继续查。
这才是 Agentic RAG 和普通 RAG 的本质区别：不是多了几次检索，而是有了判断和决策能力。
3. Query 改写的三种核心策略
Agentic RAG 之所以能"查得准"，Query 改写功不可没。
用户提问题和知识库表述往往不一致。比如用户问"苹果手机配置"，知识库里可能写的是"iPhone 14 硬件规格"。Query 改写就是解决这个"语言鸿沟"。
策略一：HyDE（假设性文档嵌入）
HyDE 的思路很巧妙：让 LLM 先根据问题生成一个假设性的答案片段，然后用这个假设答案去检索。
为什么这样有效？因为假设答案可能包含了知识库会用到的表述方式。比如用户问"如何训练大模型"，假设答案可能提到"fine-tuning"、"pre-training"这些术语，帮助检索命中相关文档。
策略二：任务拆解
对于复杂问题，直接检索往往效果差。任务拆解把问题分解成多个简单子问题。
"对比特斯拉和比亚迪的竞争优势"拆成：
- 子问题 1：特斯拉的竞争优势是什么？
- 子问题 2：比亚迪的竞争优势是什么？
每个子问题单独检索，最后再整合对比。
策略三：历史融合
多轮对话时，当前问题往往依赖上下文。用户先问"什么是 RAG"，再问"它怎么提升准确性"，第二个问题需要结合历史才能完整理解。
历史融合把当前问题和对话历史整合成一个完整的检索查询。
这三种策略各有适用场景：HyDE 适合开放式问题、术语多样时；任务拆解适合多跳问题、对比问题；历史融合适合多轮对话。
4. 结果验证——确保答案真的可靠
检索做得好不好，需要验证。Agentic RAG 引入了结果验证机制，核心思路是让模型学会"回头检查"。
Self-RAG 的反思 token
Self-RAG 是斯坦福提出的方案，它让模型在生成过程中输出特殊的反思 token。这些 token 有三种类型：
- Retrieve token：判断是否需要检索
- IsRel token：判断检索结果是否相关
- IsSup token：判断生成内容是否被检索结果支持
模型会根据这些 token 的评估结果决定下一步：检索结果不相关？改写查询继续查。生成内容不被支持？重新生成。
CRAG 的轻量级验证
CRAG 用一个轻量分类器（T5-large）给检索结果打分。如果相关性高，继续生成；如果相关性低，自动切换到网络搜索补充外部资源。
说白了就是：知识库查不到，就去网上搜。
这个设计很实用，因为实际系统中，检索失败是常态。CRAG 给了系统一个保底方案。
用考试的类比：写完答案要回头检查，确认每个论断都有依据才提交。Self-RAG 和 CRAG 就是在做这个"检查"环节。
5. 工程落地——不是所有场景都需要 Agentic RAG
讲到这里，你可能会觉得 Agentic RAG 完胜普通 RAG。但工程上有个重要原则：简单场景用普通 RAG，复杂场景才上 Agentic RAG。
为什么？因为 Agentic RAG 有代价：延迟增加、成本上升、系统复杂度提高。对于"查询产品功能"这种简单问答，普通 RAG 够用且更快。
Google 的建议是渐进式引入：先跑通普通 RAG，验证文档召回没问题，再逐步加上 Agent 能力。
另一个工程要点是工具扩展。MCP 协议（Model Context Protocol）支持动态集成计算器、API 等工具。Agent 不只是检索，还能调用外部工具完成计算任务。
比如用户问"我们公司去年营收增长了多少"，Agent 检索到营收数据后，可以调用计算器算出增长率，而不是让 LLM 硬算。
工程落地的检查清单：
- 先验证单库召回率和相关性
- 简单场景用普通 RAG，别过度设计
- 复杂场景逐步引入多轮检索和工具调用
- 加上验证机制，确保答案来源可靠
面试怎么答
基础版（能过的回答）：
普通 RAG 单次检索只能处理简单的事实查询，无法应对需要多步推理的问题。Agentic RAG 引入多轮检索循环，Agent 能判断检索结果是否相关、是否需要改写查询继续检索，直到获得足够信息才生成答案。
Query 改写解决"问不准"的问题。三种核心策略：HyDE 用假设答案引导检索方向；任务拆解把复杂问题分解为子问题分别检索；历史融合补全多轮对话的上下文。
Agent 还能验证检索结果质量。Self-RAG 用反思 token 评估相关性，CRAG 用分类器判断是否需要补充网络搜索。这些机制确保最终答案的可靠性。
加分版（让面试官眼前一亮）：
在基础版基础上，可以补充：
Self-RAG 的反思 token 机制让模型在生成过程中自我评估，决定是否需要继续检索或重新生成。这种"边想边做"的模式是 Agentic RAG 的核心。
CRAG 的设计很实用——知识库召回不好时自动切换到网络搜索，给系统加了保底。
工程上不是所有场景都要上 Agentic RAG。Google 的建议是先验证普通 RAG 的召回效果，再逐步引入 Agent 能力。简单问答场景用普通 RAG 更快更省成本。
ReAct 和 PlanAndSolve 等 Agent 工作流模式也有差异：ReAct 适合需要灵活决策的场景，PlanAndSolve 适合复杂任务的规划分解。实际选型要看具体场景。
MCP 协议支持工具动态集成，Agent 能调用计算器、API 等扩展能力，这往往是工程落地的加分项。
一句话总结
Agentic RAG 的本质是让检索从"问-查-答"的线性流程，进化为 Agent 驱动的多轮迭代循环，通过 Query 改写解决表达差异、通过结果验证确保答案可靠，实现从"查一次"到"查得准"的跨越。