RAG作为工具时，如何设计Query路由策略

P1 · rag

🏷 标签：rag, agent, query-routing, tool-use

1️⃣ 考察意图

面试官想考察你对 Agent 工具调用中“决策层”的设计能力，而非单纯背诵 RAG 流程。刁钻点在于：路由不仅仅是“分类”，而是涉及延迟、成本、准确率的工程取舍。答好了能展示你从系统设计角度理解 Agent 架构，能区分简单规则与智能路由的适用场景，并具备处理边界情况（如路由不确定、多工具协同）的实战经验。这是 P1 进阶题，核心是看你对“工具选择”这一 Agent 核心能力的深度思考。

2️⃣ 标准答

Query 路由的核心目标是根据用户查询的意图和类型，将请求分发到最合适的工具（如 RAG、计算器、API、LLM 直接生成等），以平衡准确性、成本和延迟。设计策略分三个层次：

1. 路由目标与查询分类

事实性查询（如“2024 年奥运会金牌榜”）：路由到 RAG（检索外部知识库）。
总结/推理查询（如“分析这篇论文的贡献”）：路由到 LLM 直接生成（或 RAG + 摘要）。
计算/结构化查询（如“计算 25 * 4 + 10”）：路由到计算器或 SQL 引擎。
实时/动态查询（如“北京现在天气”）：路由到 API 调用。
多跳/复杂查询（如“对比 GPT-4 和 Claude 3 的推理能力”）：路由到多工具协同（先 RAG 检索，再 LLM 分析）。

2. 路由策略：规则 vs. 模型

基于规则（关键词/正则）：适合高频、意图明确的查询。例如，查询包含“天气”则路由到天气 API；包含“计算”则路由到计算器。优点是延迟低（<10ms）、成本几乎为零；缺点是泛化能力差，无法处理同义表达（如“今天冷不冷”）。
基于模型（轻量分类器）：训练一个 BERT 或 DistilBERT 分类器，将查询映射到工具 ID。例如，使用 5000 条标注数据微调，准确率可达 95%+。优点是泛化好，能处理模糊意图；缺点是需要标注数据、训练和部署成本。
基于 LLM（Few-shot 路由）：在 prompt 中给出工具描述和示例，让 LLM 直接输出路由决策。例如，使用 GPT-4 或 Claude 3，通过 3-5 个 few-shot 示例，准确率可达 98%+。优点是零数据、灵活；缺点是延迟高（500ms-2s）、成本高（每路由一次消耗 tokens）。

3. 工程取舍与落地坑

取舍：规则 vs. LLM 路由。规则路由适合延迟敏感场景（如实时对话），但需要持续维护规则库；LLM 路由适合意图复杂场景，但成本高。实际方案：采用“规则优先 + LLM 兜底”的级联策略。先尝试规则匹配（如关键词、正则），若置信度低于阈值（如 0.7），则 fallback 到 LLM 路由。
实际坑：路由不确定时的兜底。当 LLM 路由输出“不确定”或置信度低时，不要硬选一个工具。解法：采用“多路并行检索后融合”（Multi-Route Fusion）。例如，同时调用 RAG 和计算器，将结果通过一个轻量 reranker（如 Cohere Rerank 3）排序后输出。虽然延迟增加 200ms，但准确率提升 10-15%。
另一个坑：路由循环。当 Agent 路由到工具后，工具返回结果可能再次触发路由，导致死循环。解法：在路由层加入“最大跳数限制”（如最多 3 跳），并在 prompt 中明确“如果工具返回结果已足够回答，直接输出”。

4. 评估与优化

路由准确率：计算路由到正确工具的比例。使用混淆矩阵分析分类边界（如“计算”和“推理”的混淆）。
端到端成功率：最终回答是否满足用户需求。例如，路由到 RAG 后，检索结果是否覆盖答案。
优化：对于 LLM 路由，通过 prompt 工程（如加入“如果查询包含数字，优先路由到计算器”）或 fine-tune（如使用 LoRA 微调一个 7B 模型）提升准确率。

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

“这个问题我从三个层面回答：第一，路由目标，根据查询类型（事实性、总结性、计算性）分发到不同工具；第二，路由策略，包括基于规则（关键词匹配）、基于模型（轻量分类器）和基于 LLM（Few-shot 路由），实际中采用‘规则优先 + LLM 兜底’的级联策略；第三，兜底与评估，当路由不确定时用多路并行检索后融合，并评估路由准确率和端到端成功率。总结一句：Query 路由的核心是平衡准确性、成本和延迟，没有银弹，需要根据场景做工程取舍。”

4️⃣ 高频追问 & 应对

追问 1：如果用户查询是“帮我查一下昨天北京的温度，然后计算和今天温度的差值”，你怎么路由？

这是一个典型的多跳/复合查询。不能简单路由到一个工具。策略是：先通过 LLM 路由识别出这是一个“多工具协同”任务，然后拆解为两个子查询：1）路由到天气 API 获取昨天和今天的温度；2）将结果传给计算器计算差值。实现上，可以在 prompt 中定义“多工具调用”的格式（如 [{"tool": "weather_api", "params": {"city": "北京", "date": "2024-01-01"}}, {"tool": "calculator", "params": {"expression": "result1 - result2"}}]），让 LLM 一次性生成多步计划。注意：需要处理中间结果的传递，避免死循环。

追问 2：你的 LLM 路由准确率只有 90%，怎么提升到 99%？

从三个方向优化：1）数据增强：收集更多边界案例（如“计算”和“推理”的混淆），用 GPT-4 生成合成数据，然后微调一个轻量分类器（如 DistilBERT）作为第一层路由，LLM 只处理分类器置信度低于 0.8 的查询。2）Prompt 工程：在 LLM 路由 prompt 中加入“如果查询包含数字、单位或数学符号，优先路由到计算器；如果包含‘对比’、‘分析’，优先路由到 LLM 直接生成”。3）级联策略：引入一个“路由置信度”阈值，低于 0.7 时采用多路并行检索后融合，而不是硬选一个工具。这样虽然延迟增加，但准确率可提升到 99%+。

追问 3：路由决策的延迟要求是 100ms 以内，你怎么设计？

100ms 的延迟要求排除了 LLM 路由（至少 500ms）。只能采用基于规则或轻量模型的路由。方案：1）规则优先：使用 Aho-Corasick 算法进行多关键词匹配，延迟 <5ms。维护一个高频查询的规则库（如“天气”、“计算”）。2）轻量分类器：使用 ONNX Runtime 部署一个 DistilBERT 分类器，推理延迟约 20ms。3）缓存：对高频查询（如“今天天气”）做路由结果缓存，命中率可达 30%，延迟 <1ms。4）兜底：如果规则和分类器都匹配失败，默认路由到 RAG（因为 RAG 覆盖最广），而不是调用 LLM 路由。这样 99% 的查询可在 50ms 内完成路由。

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

❌ “直接用 LLM 做路由，准确率最高，延迟无所谓。” → ✅ “LLM 路由准确率高但延迟高、成本高。实际中需要根据场景做取舍，比如用‘规则优先 + LLM 兜底’的级联策略，或对延迟敏感场景用轻量分类器。”
❌ “路由策略就是分类，训练一个分类器就行。” → ✅ “路由不仅仅是分类，还包括多跳查询的拆解、工具协同、兜底策略（如多路并行检索后融合）。分类只是第一步。”
❌ “路由不确定时，随便选一个工具，反正有重试机制。” → ✅ “路由不确定时，不要硬选一个工具。应该采用多路并行检索后融合，或让 LLM 生成一个‘不确定’输出，然后 fallback 到默认工具（如 RAG）。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“多工具 Agent 的路由设计”角度切入，强调你如何根据查询类型（事实性、总结性）设计路由策略，并处理了路由不确定时的兜底（如多路并行检索后融合）。可以提你评估了路由准确率和端到端成功率。
如果你只做过传统 NLP：用“意图识别”类比迁移，说明路由本质是一个多分类任务，但需要结合工程约束（延迟、成本）。强调你如何用规则 + 轻量模型（如 BERT）实现路由，并处理了边界情况（如模糊查询）。
如果你是校招无项目：聚焦论文复现 demo，比如复现“ReAct”或“Toolformer”中的路由机制，用 Few-shot prompt 让 LLM 路由到不同工具。强调你理解了路由的 trade-off（规则 vs. 模型），并做了简单的准确率评估。
《ReAct: Synergizing Reasoning and Acting in Language Models》
《Toolformer: Language Models Can Teach Themselves to Use Tools》
《RAG vs. Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture》
《Query Routing in Multi-Tool Agents: A Survey》
《Cohere Rerank 3: Efficient and Accurate Document Reranking》

—— 本场面试完 ——