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