多数据源（向量库 / SQL / 图谱 / API）的检索路由怎么设计？
谁在问：二面·架构向；数据团队、平台组尤其关注
口语化问法
- 你们的知识不只在文档里，还有数据库，怎么决定去哪查？
- 用户问『我上个月订单多少钱』，你的 RAG 怎么办？
- 路由是用大模型判断吗？成本受得了吗？
考察意图
三个观察点：① 有没有意识到很多问题的答案根本不在知识库里（这是 RAG demo 到生产的典型断层）；② 路由的实现选型是否有成本意识——每个 query 都让大模型判一次，是成本悄悄失控的常见来源；③ 路由判错怎么兜底——这题能区分「设计过」和「想过」。
参考答案
60 分答案（及格线）
路由是在检索前判断这个问题该去哪个数据源查：
用户问题 ├─ 事实性知识问答 → 向量库 / 混合检索 ├─ 结构化数据（金额、订单）→ SQL 查询（NL2SQL） ├─ 关系推理（谁和谁有关） → 图谱查询 ├─ 实时信息（今天股价） → Web 搜索 / 业务 API └─ 闲聊 / 无需检索 → 直接回答
实现方式有三种，成本递增：规则/关键词匹配、轻量分类器（小模型或 embedding 相似度）、LLM 直接判断。
90 分答案（有生产经验的回答）
补四层：
「无需检索」这一路常被忽略但很实用：「你好」「谢谢」「换个说法再讲一遍」这类输入根本不需要检索，直接放行既省钱又快。生产系统里这类流量占比往往不低。
成本纪律：不要一上来就每个 query 都让大模型判一次。正确做法是分层——先用规则或轻量分类器覆盖高频意图（通常能吃掉 70–80% 的流量），尾部长尾再交给 LLM。这一句话能直接体现成本治理意识。
判错的兜底（关键）：路由是有错误率的，设计时必须回答「判错了怎么办」。实用做法：① 分类置信度低于阈值时默认走全量检索（多路都查，用融合合并），而不是赌一条路；② 允许多路并发命中，让下游 rerank 去裁决；③ 记录路由决策日志，用于离线复盘和优化分类器。「不确定就全查」比「赌错一次答不出来」的用户体验好得多。
每条路的下游校验不一样：SQL 那一路要做执行结果校验（生成的 SQL 能不能跑通、结果是否为空、有没有全表扫描风险）和权限校验；Web 搜索那一路要做时效和来源可信度过滤；这些不是「路由完就结束」，而是每条支路都要有自己的兜底话术。
追问链
规则、轻量分类器、LLM 判断，你会怎么组合？
期望分层漏斗：高频且模式明确的走规则（最省最稳）→ 意图种类多但相对固定用轻量分类器（小模型或 embedding 相似度，毫秒级）→ 长尾复杂意图才交 LLM；用流量占比反推，前两层吃掉越多越便宜信号只说「用 LLM 判断，它最准」→ 缺成本视角路由判错的代价有多大？怎么降低？
期望代价是直接答不出或答错（订单金额问题被路由去文档库，捞回一堆无关制度文件）；降低靠置信度阈值 + 不确定走全量多路，金额、权限这类关键路径做双重确认，badcase 回流训练分类器信号主动提「不确定就全查」→ 是设计过的；只画得出一张路由图 → 只是想过NL2SQL 那一路准确率不高怎么办？
期望喂完整表结构 + 字段注释 + few-shot → 生成后语法校验 + 执行前安全检查（禁写操作、限扫描范围）→ 执行结果回显给用户确认 → 仍不达标就降级为「给候选 SQL 让用户确认」而非直接返数字。数据类问题上，错答比不答更危险信号说得出「宁可不答也别给错数字」→ 有业务风险意识路由和 Agentic RAG 是什么关系？
期望路由是 Agentic RAG 里的 Router 组件，但两者不等同：路由一次性决定去哪查，Agentic 是查完看结果再决定要不要重查、换哪查，多了循环与自我修正；轻量路由 + 固定管线是 Agentic 的低成本替代信号说得清「路由是决策的静态版、Agentic 是动态版」→ 知识成体系用户问「对比一下我们和竞品的售后政策」，这该路由到哪？
期望这是陷阱，单一路由答不了：先识别为复合查询 → 子问题拆解（己方政策在知识库、竞品信息走 Web 搜索）→ 多源并行检索 → 结果综合对比。这已经进入 Agentic RAG 的领域，硬塞进单路由会答残信号张口「路由到知识库」→ 没有复合问题的概念；能认出「这题得先拆」→ 判断力到位
评分要点
- 能列出至少三类数据源及对应判断依据
- 包含「无需检索」这一路
- 给出三种实现方式并有成本递增的认识
- 有判错兜底策略（不确定走全量）
- 知道每条支路下游还需各自校验（SQL 执行校验、Web 时效过滤）
- 加分：能说清路由与 Agentic RAG 的关系与边界
- 加分：能识别出「复合查询」需要拆解而非单路由