考察点
这道题出自字节跳动 AI Agent 岗二面。Agentic RAG 是 2025 年以来的高频考点，面试官想确认你不是只会背概念，而是真的理解「多轮检索换准确率」这个 trade-off 的代价：延迟翻倍、token 成本翻几倍、链路变长带来失败点变多。追问一般往「什么时候值得上 Agentic RAG」「具体怎么省钱」「怎么做评测」走。
参考答案
核心区别：检索从一步变成闭环
传统 RAG 是一条直线：用户 query → embedding 检索 → top-k 文档拼进 prompt → 生成答案。整个过程检索只发生一次，检索质量在第一步就被锁死了——query 写得不好、用户问题需要多跳推理、召回的文档其实不相关，系统都没有自救机会，模型只能在不相关上下文上硬答或者开始编。
Agentic RAG 把检索变成了一个可循环的决策过程，模型在每步都能选择动作：
- 查询改写/分解：把「对比 A 产品和 B 产品的售后政策」拆成两个子问题分别检索；把多轮对话里的指代（「它的价格」）补全成独立 query。
- 检索后校验：拿到 top-k 后先判断文档和问题的相关性（用 LLM 打分或小型分类器），不相关就换关键词、换检索通道（向量换 BM25、换索引）重检，而不是硬着头皮生成。
- 多跳检索：第一轮检索到的内容里出现新实体，以此为线索做第二轮检索，处理「A 的供应商的产能」这类问题。
- 答案自检：生成后校验答案是否被检索内容支持，不支持就重检或拒答。
用一句话说：传统 RAG 是「检索增强生成」，Agentic RAG 是「把检索当成工具交给 Agent 按需调用」。CRAG、Self-RAG 这些论文路线本质上都是在给这个闭环加校验和反思节点。
成本怎么控
Agentic RAG 的代价很现实：一次请求从 1 次 LLM 调用变成平均 3-5 次，token 消耗和延迟都是数倍。我的控制手段：
- 分级路由，能不用就不用。入口先用一个轻量判断（规则或小模型分类）区分问题难度：事实型简单问题直接走传统 RAG 单次检索，只有多跳、模糊、对比类问题才进 Agentic 流程。线上大部分 query 是简单问题，这一步能省掉大头成本。
- 便宜的活用便宜的模型。查询改写、相关性判断、答案校验这些环节不需要最强模型，用小一档的模型（比如自家 7B/14B 或 Haiku 级别）就能干，只有最终生成用主力模型。相关性判断甚至可以用 bge-reranker 这类 rerank 模型替代 LLM 打分，一次调用几毫秒。
- 硬性预算。给循环设上限：最多改写 2 次、最多检索 3 轮、总 token 预算封顶，超了就用当前已有材料尽力回答或拒答，绝不让 Agent 无限反思。
- 缓存。改写后的 query 和检索结果做缓存，相似问题命中缓存直接复用，多租户 SaaS 场景下命中率可观。
稳定性怎么控
链路变长后，每个节点都是新的失败点，手段和 Agent 工程通用：
- 每个节点结构化输出 + schema 校验。改写、相关性打分都要求 JSON 输出，解析失败带错误重试 1 次，再失败走降级——降级路径很重要：Agentic 流程跑挂了要能退化成传统 RAG 的单次检索，保证有答案兜底。
- 并发检索降延迟。多路召回（向量 + BM25 + 改写后的多个 query）并发发出去再合并 rerank，把多轮的串行延迟摊薄。
- 可观测。每个节点的输入输出、检索轮数、改写前后的 query 都落日志。线上看两个指标：平均检索轮数（成本探头）和各节点失败率（稳定性探头）。
- 评测闭环。离线用带标准答案的评测集对比传统 RAG 和 Agentic RAG 的端到端准确率提升，确认多花的钱确实买到了准确率；如果提升只有一两个点，就不值得为这部分流量开 Agentic 流程。
可能的追问
- 什么场景明确不适合 Agentic RAG？ 答：高频简单问答（客服 FAQ 类）、延迟敏感场景（实时语音交互），单次检索的准确率已经够用，多轮循环纯粹是浪费钱。
- 相关性校验具体怎么做？ 答：两种路线——重一点的是 LLM 打分（prompt 里给判定标准，输出 relevant/irrelevant 加理由），轻一点的是 rerank 模型打分设阈值过滤；生产上通常 rerank 过滤为主，LLM 校验只在最后一道用。
- 多轮检索的上下文越来越长怎么办？ 答：每轮只保留 rerank 后的 top-k，淘汰低分文档；必要时对中间轮次的文档做压缩摘要，只把结论带入后续轮次，同时监控总 token 占用。