03｜Agent+RAG 系统中，Agent 如何决定何时调用 RAG

P1 · rag

🏷 标签：agent, rag, decision-making, react, tool-use

1️⃣ 考察意图

面试官想考察你对 Agent 自主决策机制的理解深度，而非简单背概念。核心是区分“规则驱动”与“模型驱动”两种范式，并理解它们在延迟、准确率、成本之间的取舍。刁钻点在于：Agent 不是“有问必查”，而是需要判断“何时查”才能平衡效率与效果。答好了能展示你对 ReAct、Function Calling 等框架的实战认知，以及处理多轮对话中“重复检索”和“幻觉抑制”的工程能力。

2️⃣ 标准答

Agent 决定调用 RAG 的核心是决策策略，分为三类，各有适用场景：

**基于规则的触发（Rule-based）**实现：用关键词（如“最新”、“2023年之后”）或正则匹配用户输入，命中则触发检索。
优点：延迟极低（<10ms），无需额外模型调用，适合高频、确定性场景（如客服系统查订单状态）。
缺点：僵化，无法处理模糊意图（如“这个产品怎么样？”可能隐含需要检索最新评论）。
工程坑：规则冲突时需优先级排序，例如“最新”和“历史”同时出现时，用权重或上下文消歧。基于模型自主判断（Model-driven）
实现：通过 ReAct 模式或 Function Calling，让 LLM 在推理过程中输出工具调用指令（如 search_knowledge_base）。
优点：灵活，能处理复杂意图（如“对比 GPT-4 和 Claude 3 的定价”会触发多次检索）。
缺点：增加延迟（每次决策需额外 LLM 调用，约 200-500ms）和成本；LLM 可能过度调用（如闲聊时也检索）。
取舍：在工具描述中明确“仅当需要外部知识时调用”，并用 stop token 限制调用次数。
实际落地坑：多轮对话中，Agent 可能重复检索已获取的信息。解法：在系统 prompt 中加入“记忆指令”，如“若用户问题与上一轮检索结果相关，直接引用，不再调用 RAG”。基于不确定性估计（Uncertainty-based）
实现：在 Agent 输出前，用模型置信度分数（如 logits 的熵）或额外分类器判断是否需检索。
优点：理论上最精准，能避免“模型自信但错误”的情况。
缺点：需要额外模型（如 BERT 分类器）或对 LLM 输出做后处理，增加工程复杂度；置信度阈值需调参（如设定熵 > 0.5 时触发）。
工程坑：LLM 的 logits 可能不可靠（如生成式模型对事实性问题的自信度与正确性无关）。解法：结合“自一致性”（Self-Consistency）采样多次，若答案不一致则触发检索。

综合实践：在字节跳动的客服 Agent 中，采用混合策略——先用规则快速过滤高频问题（如“退款流程”），未命中时用 ReAct 让 LLM 自主决策，并设置最大调用次数（如 3 次）防止死循环。多轮对话中，用 memory 模块存储已检索内容，通过 similarity check 避免重复。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，基于规则的触发，适合高频、确定性场景，延迟低但僵化；第二，基于模型自主判断，通过 ReAct 或 Function Calling 让 LLM 决策，灵活但增加延迟和成本；第三，基于不确定性估计，用置信度或自一致性判断，精准但工程复杂。总结一句：实际落地常用混合策略，规则兜底 + 模型决策 + 记忆抑制重复检索。”

4️⃣ 高频追问 & 应对

追问 1：如果 LLM 在 ReAct 中频繁调用 RAG，导致成本飙升，你怎么优化？

应对策略：首先，在工具描述中加限制，如“仅当用户问题包含事实性查询（如日期、数字、名称）时调用”。其次，用 预算控制：设定每轮对话最大调用次数（如 2 次），超出后强制用模型内部知识。最后，引入 缓存机制：对常见查询（如“公司地址”）预检索并缓存结果，避免重复调用。工程上，用 Redis 做 LRU 缓存，TTL 设为 1 小时。

追问 2：多轮对话中，Agent 如何判断当前问题是否依赖之前检索的信息？

应对策略：用 上下文压缩 技术——将历史对话和检索结果压缩成摘要（如用 LLM 生成“已知事实”列表），然后让 Agent 判断新问题是否与摘要相关。具体实现：在 ReAct 的 thought 步骤中，加入“检查记忆”指令，若问题包含“它”、“那个”等代词，则强制引用记忆。工程坑：摘要可能丢失细节，需保留原始检索结果的 key-value 对（如“key: 产品价格, value: 99 元”）。

追问 3：如果用户问“今天天气怎么样”，Agent 应该调用 RAG 还是直接回答？

应对策略：取决于 RAG 的知识源。如果 RAG 包含实时天气 API，则调用；否则不调用。关键在于 工具描述：在 Function Calling 中，为每个工具写清楚“适用场景”，如“search_weather：仅当用户询问当前天气时调用，返回实时数据”。Agent 通过 LLM 理解工具语义，自动决策。若工具描述不清晰，LLM 可能误判，所以描述要具体（如“输入格式：城市名，输出：温度、湿度”）。

5️⃣ 避坑 · 常见错误答法

❌ 说“Agent 应该总是调用 RAG，因为模型知识有限” → ✅ 正确切入：总是调用会导致延迟和成本爆炸，且对简单问题（如“你好”）浪费资源。应区分“事实性查询”和“闲聊”，用规则或模型决策。
❌ 说“用关键词触发就够，简单高效” → ✅ 正确切入：关键词触发无法处理模糊意图（如“这个怎么样？”），且需要维护大量规则。应结合模型自主判断，用 ReAct 处理复杂场景。
❌ 说“不确定性估计用 logits 熵就行” → ✅ 正确切入：LLM 的 logits 可能不可靠，需结合自一致性或额外分类器。工程上，logits 熵适合分类任务，但生成任务中答案长度会影响熵值，需归一化。

6️⃣ 简历呼应

如果你有 RAG 项目：从“混合策略”切入，强调你在项目中如何用规则过滤高频问题 + ReAct 处理复杂查询，并展示你优化了调用次数（如从平均 5 次降到 2 次）。
如果你只做过传统 NLP：用“意图分类”类比——规则触发类似关键词匹配，模型决策类似意图识别模型。强调你理解“何时调用”本质是“决策边界”问题，可迁移到 Agent 设计。
如果你是校招无项目：聚焦“ReAct 模式”的论文复现，用 LangChain 或 AutoGPT 实现一个简单 Agent，在 WebGPT 数据集上对比不同策略的准确率和成本，输出分析报告。
《ReAct: Synergizing Reasoning and Acting in Language Models》
《Toolformer: Language Models Can Teach Themselves to Use Tools》
《Self-Consistency Improves Chain of Thought Reasoning in Language Models》
《RAG vs. Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture》
《LangChain 官方文档：Agent 工具调用与记忆管理》

—— 本场面试完 ——