Q: 如何设计一个 Agentic RAG 的规划策略？如何评估规划的好坏

P2 · rag

🏷 标签：agentic-rag, planning, evaluation, re-act

1️⃣ 考察意图

面试官想考察你对 Agentic RAG 中“规划”这一核心模块的工程化理解，而非单纯背诵 ReAct 论文。刁钻点在于：规划策略不是简单的“LLM 写步骤”，而是涉及检索时机、任务分解粒度、错误恢复的复杂系统设计。答好了能展示你从“调 API”到“设计可评估、可迭代的规划引擎”的硬实力，包括对 trade-off（如灵活性与可控性）的把握，以及用指标驱动优化的工程思维。

2️⃣ 标准答

设计 Agentic RAG 的规划策略，核心是解决“何时检索、检索什么、如何组合结果”三个问题。我从策略分类、设计细节、评估体系三个层面展开。

一、规划策略设计：三种主流范式

ReAct 式（动态规划）：LLM 在每个推理步骤前输出“思考（Thought）→ 动作（Action）→ 观察（Observation）”循环。动作可以是“检索”、“计算”或“搜索”。优势是灵活，能根据中间结果动态调整。坑：容易陷入无限循环，需设置最大步骤数（如 10 步）和超时机制。工程上常用 stop token 控制动作输出，或用 function calling 模式绑定检索工具。
Plan-and-Solve 式（先规划后执行）：先让 LLM 生成一个完整计划（如“步骤1：检索签证类型；步骤2：检索材料清单；步骤3：合并答案”），然后按顺序执行。优势是步骤可控、可缓存。坑：计划可能过时或错误，需引入“计划验证”步骤（如用另一个 LLM 检查计划是否合理）。实际落地中，我见过用 DAG 任务图表示计划，允许并行执行独立子任务（如同时检索“费用”和“时间”）。
固定流水线式（规则驱动）：硬编码检索顺序（如“先查百科，再查新闻”）。优势是零延迟、可预测。坑：无法处理复杂问题。适用于 QA 场景固定的内部工具（如“先查订单状态，再查物流信息”）。

二、关键设计细节：检索时机与查询重写

检索时机：ReAct 中，每次动作前都检索会引入高延迟（每次检索约 200-500ms）。优化策略：只在 LLM 输出“不确定”信号时触发检索（如用 confidence score 阈值 0.7）。另一种做法是“延迟检索”：将多个检索请求合并为一次批量查询。
查询重写：原始问题可能模糊（如“它”指代不明）。用 LLM 将用户问题重写为多个子查询（如“签证类型” → “美国B1签证类型”），再用 BM25 或 DPR 分别检索。坑：重写可能引入噪声，需用 query expansion 技术（如添加同义词）平衡召回与精度。

三、评估规划好坏：指标与实验设计

任务完成率：最终答案准确率（如 HotpotQA 的 F1）。这是最直接的指标，但无法反映规划效率。
规划效率：平均步骤数、平均检索次数、端到端延迟。例如，ReAct 可能用 5 步完成，Plan-and-Solve 用 3 步，但后者计划生成耗时 1 秒。需用 加权成本函数 综合评估（如 score = accuracy - 0.1 * steps）。
检索质量：用 NDCG@10 或 Recall@5 评估每次检索的相关性。如果规划策略导致检索结果不相关（如 ReAct 中错误动作触发错误查询），NDCG 会显著下降。
鲁棒性测试：引入噪声查询（如拼写错误、歧义代词）或错误检索结果（如故意返回无关文档），观察规划能否恢复。例如，在 ReAct 中注入一次错误检索，看 LLM 是否能在下一步纠正（通过“观察”发现矛盾并重新检索）。
消融实验：对比三种策略在相同数据集上的表现。我做过一个实验：在 HotpotQA 上，ReAct 的准确率比固定流水线高 12%，但步骤数多 40%。Plan-and-Solve 在步骤数上最优，但计划生成失败率约 8%（需重试）。

实际落地的坑 + 解法：一次项目中，ReAct 在“多跳推理”任务中频繁陷入“检索→思考→检索”的死循环。解法：引入 step budget（每步消耗 1 点预算，预算耗尽强制输出最终答案），并将 stop 条件设为“当连续 3 步检索结果无变化时终止”。

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

“这个问题我从规划策略设计、评估指标、工程取舍三个层面回答。策略上，ReAct 灵活但易循环，Plan-and-Solve 可控但计划可能过时，固定流水线简单但死板。评估时，不能只看准确率，还要看步骤数、检索 NDCG 和鲁棒性。总结一句：好的规划策略是‘在灵活性与可控性之间找到平衡，并用指标驱动迭代’。”

4️⃣ 高频追问 & 应对

追问 1：你提到 ReAct 容易循环，具体怎么检测和恢复？

检测：设置最大步骤数（如 10 步）和重复动作检测（如连续 3 次相同检索动作）。恢复：当检测到循环时，强制 LLM 输出“最终答案”或“放弃”，并记录失败原因。另一种做法是引入 memory 模块，将已检索过的文档摘要存入上下文，避免重复检索。工程上，用 state machine 管理状态（如“思考中”、“检索中”、“答案生成中”），循环时回退到上一状态。

追问 2：如何评估规划策略的“鲁棒性”？给个具体实验设计。

设计三组测试：1）噪声查询：随机替换 20% 的实体词（如“签证”改为“签注”），看准确率下降幅度。2）错误检索：在 30% 的步骤中返回无关文档（如用随机文档替换 Top-1 结果），看规划能否通过“观察”纠正。3）中断恢复：在规划中途插入一个无关问题（如“今天天气如何？”），看 LLM 能否回到原任务。指标：准确率下降率、恢复步骤数。例如，ReAct 在噪声查询下准确率下降 15%，但 Plan-and-Solve 下降 25%，因为后者计划依赖初始查询。

追问 3：你的规划策略如何扩展到多轮对话场景？

核心是维护 对话状态。用 slot filling 技术跟踪已收集的信息（如“签证类型已确认”），并动态调整规划。例如，用户问“签证需要多久？”，规划器先检查是否已有“签证类型”信息，若无则先检索类型，再检索时间。坑：对话历史过长时，LLM 会遗忘早期信息。解法：用 retrieval-augmented memory（如将历史摘要向量化存储），在规划时检索相关历史。

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

❌ 说“规划策略就是让 LLM 写步骤，然后执行” → ✅ 正确切入：规划策略涉及检索时机、查询重写、错误恢复等工程细节，不是简单的“LLM 生成计划”。
❌ 说“评估只看最终答案准确率” → ✅ 正确切入：还需评估步骤数、检索 NDCG、鲁棒性，并用消融实验对比不同策略。
❌ 说“ReAct 永远比固定流水线好” → ✅ 正确切入：ReAct 灵活但延迟高，固定流水线在简单场景下更高效，需根据任务复杂度选择。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在项目中用 ReAct 实现多跳问答，发现循环问题后引入 step budget”切入，展示工程优化能力。
如果你只做过传统 NLP：用“传统 QA 的流水线（检索→阅读）类比固定流水线，Agentic RAG 的规划相当于动态决策”迁移，强调对规划策略的理解。
如果你是校招无项目：聚焦“我复现了 ReAct 论文并在 HotpotQA 上做消融实验，对比了三种策略的准确率和步骤数”，展示动手能力和指标意识。
ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)
Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models (Wang et al., 2023)
Tree of Thoughts: Deliberate Problem Solving with Large Language Models (Yao et al., 2023)
LangGraph: A library for building stateful, multi-actor applications with LLMs (LangChain, 2024)
HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering (Yang et al., 2018)

—— 本场面试完 ——