考察点
这道题考的是你有没有把 RAG 从「固定流水线」思维升级到「闭环决策」思维。传统 RAG 是一条直线：检索→拼 prompt→生成，一次成形，错了就错了。面试官想听到你怎么把检索变成一个可观察、可纠偏、可多轮迭代的循环，以及具体有哪些调整策略、各自什么时候触发。追问常往「循环怎么收敛」「成本和延迟怎么控制」「工具调用怎么设计」走。
参考答案
本质区别：流水线 vs 闭环
传统 RAG 是一条无状态的流水线：用户 query → 向量检索 top-k → 塞进 prompt → LLM 生成。它有三个结构性短板：query 不好就检索不好，没人纠正；检索结果差照样强行生成，产生幻觉；只能做单轮单源检索，复杂问题（多跳、对比、聚合）天然不行。
Agentic RAG 把 LLM 放到回路中间，让它作为决策者控制检索过程：决定要不要检索、检索哪个源、用什么 query、结果够不够用、不够用接下来怎么办。核心变化是三个：
- 检索从「一次调用」变成「工具」，模型可以多次、带不同参数调用；
- 每一步结果都会被评估（relevance check），形成反馈闭环；
- 有了规划能力：复杂问题先拆成子问题，逐个检索再综合。
常见的几种 Agent 模式
- 路由（Routing）：先判断 query 该去哪——是查知识库、查 SQL 库、调 API，还是根本不用检索直接答。实现上可以用小模型分类或 LLM function calling 选工具；
- 检索后反思（Self-RAG 思路）：检索回来先让模型判断文档是否相关，不相关就改写 query 重检；生成后再反思答案有没有依据、需不需要补充检索；
- ReAct 循环：思考→行动（调检索工具）→观察→再思考，适合多跳问题，「A 公司的竞对 B 在 2023 年的营收是多少」这种问题需要先查 A 的竞对是谁，再查 B 的营收；
- 规划式（Plan-and-Execute）：开局把问题拆成有依赖关系的子任务 DAG，逐个执行，适合报告生成类重任务。
检索失败后的策略调整
这是题目后半问的核心。定义「失败」是前提，常见信号有：检索 top-1 分数低于阈值、rerank 后相关文档数不足、模型自检回答「根据已有信息无法回答」。触发后按成本从低到高依次升级：
- 改写 query 重检：同义改写、补全实体（「它」→ 具体产品名）、换表述角度。这一步成本最低，一轮对话里可以允许 2-3 次；
- 扩大检索范围：调大 top-k、降低相似度阈值、换检索方式（向量换 BM25 或混合检索）、跨 collection 检索；
- 拆解问题：原问题可能太复合，拆成子问题分别检索再聚合；
- 换数据源：向量库没有就查结构化库、查搜索引擎、查实时 API；
- 承认失败并交还用户：明确告诉用户知识库里没有，给出缺什么信息、建议补充什么，这比硬编一个答案强得多。
工程上这套升级策略通常实现成状态机或带最大步数的循环，而不是指望模型自己想到——模型自主决策做探索，确定性规则兜底防失控。
必须配套的两个工程机制
收敛控制：Agent 循环最怕死循环——反复改写 query 检索同一个库。必须有最大迭代次数（比如 5 轮）、相似 query 去重（改写后和已试过的 query 太像就跳过）、总 token/耗时预算。生产上还会记录每条轨迹的成功率，离线分析哪种失败模式最多，针对性优化。
可观测性：每一次工具调用、每次改写的 query、每次反思的结论都要落日志（LangSmith、Langfuse 或自建 trace），否则效果差了根本定位不了是检索问题还是决策问题。
什么时候值得上 Agentic RAG
不是所有场景都需要。query 类型单一、知识库质量高、问题基本都是单跳的，传统 RAG 加好 rerank 就够了，Agent 化的成本（延迟翻几倍、token 消耗翻几倍、调试复杂度上一个台阶）不划算。Agentic RAG 的价值在 query 分布杂、问题复杂度高、数据源多样的场景——客服知识库通常前者，投研/法律咨询通常后者。
可能的追问
- 怎么评估一次检索「失败」了？——硬信号：向量分数阈值、rerank 分数阈值；软信号：让 LLM 对检索结果做相关性判断（CRAG 的做法）。生产上两者结合，单靠向量分数不可靠。
- Agentic RAG 延迟太高怎么优化？——简单 query 走快速通道（分类器先判断，简单问题直接传统 RAG 一遍过）；并行化独立的子检索；反思/改写用小模型，只最终生成用大模型。
- 怎么防止 Agent 乱调工具？——工具描述写清楚适用边界，系统 prompt 里给明确的停止条件；外加硬性规则：最大步数、预算上限、重复调用检测。
- 和微调一个「会检索的模型」比呢？——RAG 工具调用能力可以通过 SFT 内化（类似 Search-R1 这类工作），减少编排复杂度，但工具集和数据源经常变的话，外部编排的灵活性更好。