2 什么是路由检索（Router Retrieval）
P1 · rag
🏷 标签：rag, router-retrieval, query-routing, llm, intent-classification
1️⃣ 考察意图
面试官想考察你对“动态检索策略”的理解深度，而非仅仅背诵概念。核心是看你能否设计一个路由决策机制，在查询意图、数据源异构性、延迟成本之间做工程取舍。刁钻点在于：路由本身是一个“元任务”，其准确率直接影响下游检索效果，且路由模型训练数据难以获取。答好了能展示你对 RAG 系统模块化设计和系统瓶颈的洞察力，以及处理多源异构数据的实战经验。
2️⃣ 标准答
路由检索（Router Retrieval）的核心思想是：不搞一刀切，而是根据查询意图动态选择最优的检索策略或数据源。它解决的是传统 RAG 中“所有查询走同一套检索流程”导致的低效和误召回问题。
1. 路由决策的三种实现方式
- 基于规则（Rule-based）：用关键词或正则匹配。例如，查询含“价格”“退款”则路由到 FAQ 索引；含“API”“SDK”则路由到技术文档索引。优点：零成本、可解释性强。缺点：无法处理模糊或复合意图（如“如何退款但 API 报错”）。
- 基于分类模型（Classifier-based）：训练一个轻量级意图分类器（如 BERT-base 微调），输出概率分布。例如，用 3 个类别（技术/产品/售后）做 softmax。优点：泛化能力优于规则，延迟低（<10ms）。缺点：需要标注数据，冷启动困难。
- 基于 LLM 路由（LLM-based）：用大模型（如 GPT-4 或 Llama-3）直接判断路由目标。例如，在 prompt 中定义“如果查询涉及代码，路由到代码库；如果涉及产品功能，路由到产品文档”。优点：零样本、能处理复杂意图。缺点：延迟高（几百毫秒）、成本高、可能产生幻觉。
2. 工程取舍：规则 vs 模型 vs LLM
- 规则路由适合高频、确定性高的场景（如客服系统），但无法应对长尾查询。
- 分类模型在延迟和准确率之间取得平衡，但需要持续维护训练数据。
- LLM 路由适合查询意图复杂、数据源多的场景，但必须做缓存和降级（例如，先用规则兜底，LLM 超时则回退到分类模型）。
3. 实际落地的坑与解法
- 坑 1：路由准确率低导致检索效果雪崩。例如，将技术问题误判为产品问题，导致召回一堆无关 FAQ。解法：引入置信度阈值。当路由模型输出概率低于 0.7 时，采用多路并行检索（同时查技术库和产品库），再通过 reranker 排序。这增加了延迟，但保证了召回率。
- 坑 2：路由模型训练数据难获取。解法：用弱监督 + 自训练。先用 LLM 对历史查询生成伪标签（如“这个查询应该路由到技术库”），再用这些数据训练一个轻量级分类器。迭代 2-3 轮后，分类器准确率可达 85% 以上。
- 坑 3：复合意图查询（如“如何用 Python 调用 API 并处理退款”）。解法：支持多路路由。将查询拆分为子意图（如“API 调用”和“退款流程”），分别路由到不同索引，最后合并结果。
4. 与 RAG 系统的集成路由检索通常放在检索前。一个典型流程是：查询 → 路由模块（输出目标索引） → 对应索引的检索（如 BM25 + DPR） → 结果合并 → reranker。路由模块本身可以是一个独立的微服务，通过 gRPC 或 HTTP 调用，方便扩展和监控。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，路由检索的定义——根据查询意图动态选择检索策略或数据源，解决传统 RAG 一刀切的低效问题。第二，实现方式——规则路由（关键词匹配）、分类模型路由（BERT 微调）、LLM 路由（GPT-4 零样本），各有取舍：规则快但死板，模型平衡延迟和准确率，LLM 灵活但成本高。第三，实战坑点——路由准确率低时需引入置信度阈值和多路并行检索，训练数据难获取时用弱监督自训练。总结一句：路由检索是 RAG 系统模块化设计的关键，核心在于根据业务场景在准确率、延迟、成本之间做工程取舍。”
4️⃣ 高频追问 & 应对
追问 1：如果路由模型准确率只有 70%，你怎么优化？
应对策略：首先，分析错误类型。如果是混淆类错误（如技术 vs 产品），可以增加训练数据或使用更精细的类别（如“API 调用” vs “SDK 配置”）。其次，引入置信度阈值：低于 0.7 的查询走多路并行检索，再通过 reranker 排序。最后，考虑级联路由：先用规则处理高频查询，剩余长尾查询交给模型。例如，在电商客服系统中，70% 的查询（如“退款”“物流”）可以用规则覆盖，剩下 30% 才用模型路由，整体准确率可提升至 90% 以上。
追问 2：路由检索和 Query Rewriting 是什么关系？能结合吗？
应对策略：两者是互补的。路由检索决定“去哪查”，Query Rewriting 决定“怎么查”。可以结合：先路由到目标索引，再对查询做改写（如扩展同义词、纠正拼写）以提升检索效果。例如，路由到技术文档库后，将“怎么装包”改写为“安装方法 pip install”，再执行 BM25 检索。注意顺序：先路由后改写，因为改写策略可能因数据源而异（如 FAQ 库需要更简洁的改写，文档库需要更详细的改写）。
追问 3：如何评估路由检索系统的效果？
应对策略：从三个维度评估。1）路由准确率：单独评估路由模块，用人工标注的测试集计算分类准确率。2）端到端检索效果：对比有路由和无路由的 Recall@K 和 MRR。例如，在混合数据集上，路由检索的 Recall@10 可能从 0.6 提升到 0.8。3）延迟和成本：记录路由模块的 P99 延迟和 API 调用成本。例如，LLM 路由延迟 500ms，分类模型路由仅 5ms。关键指标是路由准确率 vs 端到端效果的 trade-off：准确率每提升 5%，端到端 Recall 可能提升 2%，但延迟增加 10%。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“路由检索就是用一个模型判断查询属于哪个类别” → ✅ 正确切入：路由检索的核心是动态选择检索策略，类别只是其中一种方式。还要考虑数据源异构性（如结构化 vs 非结构化）、检索方法差异（如 BM25 vs 向量检索）、以及多路路由的合并策略。
- ❌ 说“路由模型准确率越高越好，所以直接用 GPT-4” → ✅ 正确切入：准确率不是唯一指标。GPT-4 路由延迟高、成本高，且可能产生幻觉。实际工程中，需要根据业务场景权衡：高频查询用规则，长尾查询用模型，并引入置信度阈值和降级策略。
- ❌ 说“路由检索只适用于多数据源场景” → ✅ 正确切入：路由检索也适用于单数据源但多检索策略的场景。例如，对同一个文档库，简单查询用 BM25，复杂语义查询用 DPR，路由模块根据查询长度和复杂度动态选择。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“多源异构数据”角度切入。例如，在项目中构建了路由检索模块，将用户查询路由到技术文档库、FAQ 库和 API 文档库，使用 BERT 分类器实现 85% 准确率，并通过置信度阈值和多路并行检索将端到端 Recall@10 提升 15%。
- 如果你只做过传统 NLP：用“意图识别”类比迁移。例如，将路由检索视为意图识别在检索场景的扩展，强调分类模型（如 BERT 微调）和规则引擎的结合，以及训练数据不足时的弱监督方案。
- 如果你是校招无项目：聚焦论文复现。例如，复现了《Query Routing in RAG: A Survey》中的路由策略，用公开数据集（如 MS MARCO）构建了一个基于 LLM 的路由 demo，对比了规则、分类模型和 LLM 路由的准确率和延迟。
- 《Query Routing in RAG: A Survey》（2024）—— 系统梳理路由检索的分类和 trade-off
- 《RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval》—— 涉及动态路由思想
- 《REPLUG: Retrieval-Augmented Black-Box Language Models》—— 路由与检索增强的结合
- 《Self-RAG: Learning to Retrieve, Generate, and Critique》—— 路由决策与自反思机制
- 《CRAG: Comprehensive RAG Benchmark》—— 包含路由检索的评估指标