# FDE W5D6 评测题 · 三路数据路由
> 配套《FDE-W5D6-三路数据路由-学习手册.html》。场景统一为「特药理赔 Agent」。
> 每个题目含：**考察点**、**评分维度**（1~5 分）、**参考答案**（折叠展开）。
> 评分维度通用：① 正确性 ② 完整性 ③ 工程与风险意识（是否想到回退/安全/成本/可观测）。
---
## L1 基础（概念识别）
### Q1. 为什么企业 Agent 需要"数据路由"？没有路由会怎样？
- **考察点**：路由的存在意义。
- **评分维度**：
- 正确性（3 分）：分而治之，问题类型混杂。
- 工程意识（2 分）：没路由会"把所有问题塞给一个能力，又慢又错"。
参考答案（点击展开）
用户问题类型混杂（知识/数据/实时写），没有路由会把所有问题塞给单一能力，导致又慢又错（如拿聊天问题去查库查不到，拿知识问题去 SQL 空跑）。
路由是"总调度"，只决定"这个请求交给谁"（RAG/SQL/API），下面挂的三类能力才是干活的。本质分而治之，在成本、延迟、可控性上都优于"一个大模型全包"。
参考答案（点击展开）
- **RAG**：知识类、条款解释、文档内容，需引用出处。如"特药报销比例怎么规定"。
- **SQL**：结构化、可聚合、条件筛选、跨表关联，数据在库里。如"我上月特药报了多少"。
- **业务 API**：实时状态查询、写操作/动作执行，带鉴权审计。如"理赔到哪步了""帮我提交理赔"。
参考答案（点击展开）
- **规则路由**：关键词/正则硬匹配。优点：快、零成本、可解释；缺点：覆盖有限、泛化差。
- **LLM 分类路由**：小模型把问题分类到 RAG/SQL/API，可带置信度。优点：语义强、泛化好；缺点：有成本、会判错。
- **混合（生产推荐）**：规则兜底高频明确意图，不确定再交 LLM 分类 + 置信度门控。
参考答案（点击展开）
路由是站在 W2/W3/Day5 之上的"编排层/大脑"：
- W2 Tool 提供"调用业务 API"的原子能力 → 路由的 API 一路落到的就是它；
- W3 RAG 提供"检索知识"的原子能力 → 路由的 RAG 一路调用它；
- Day5 SQL 提供"查结构化库"的原子能力 → 路由的 SQL 一路调用它。
W2/W3/Day5 是"肌肉"，路由是"大脑"。讲清层级体现对企业 Agent 架构的整体观。
参考答案（点击展开）
让路由模型同时输出 confidence，是把"不确定"显式化——低置信（如<0.6）走回退，避免"瞎猜一路导致查错或误写"。
写操作（API）误判的代价最大（可能真实提交/改状态），所以这类意图的置信度阈值应设得更高，宁可提高回退率也不盲执行。另外路由用小模型即可，别为路由浪费大模型 token。
参考答案（点击展开）
三种回退：
1. **多路并行**：同时走 RAG+SQL，汇总/让模型择优选（代价是多花成本，但更稳）。
2. **澄清反问**：向用户追问"您是想查金额还是看规定"，把歧义抛回用户。
3. **转人工**：高风险/仍不确定（尤其写操作、敏感数据）直接转人工坐席，绝不裸奔。
核心原则："宁可多问一句/多花成本，也不瞎猜一路执行"。多路并行要控制成本，小问题不必三路全跑。
参考答案（点击展开）
裸 SQL UPDATE 直接改库，会绕过业务层的额度校验、资质校验、审批流，且无审计、无幂等——这是事故源（如重复提交理赔、超额赔付）。
业务 API 走的是带完整业务规则的 Service 层，具备鉴权、参数校验、审计日志、超时重试与幂等（防重复提交）。这正是企业级与玩具 Demo 的分界：写操作必须经由业务编排，而非裸 SQL。
参考答案（点击展开）
需要。路由只解决"这个问题该走 SQL 路"的决策，不解决"这条 SQL 安不安全"。进入 SQL 路后，仍要过 Day5 的安全校验五关：只读(AST)、白名单表(含 JOIN/子查询)、参数化、行数 LIMIT、EXPLAIN。
路由与安全是两层独立防线：路由防"走错路"，安全防"走对的路但执行危险 SQL"。两者不能互相替代。
参考答案（点击展开）
1. **规则层**：用关键词/正则覆盖高频明确意图（如"多少/统计"→SQL，"规定/条款"→RAG），零成本秒回。
2. **LLM 分类层**：规则不确定时，调小模型输出 `{route, confidence, reason}`（T=0，JSON）。
3. **门控**：confidence ≥ 高阈值→直接执行；低于阈值或两路接近→回退（多路/反问/人工）。写操作类阈值设更高。
4. **可观测**：每次记 Trace（问题/类别/置信度/是否回退/最终路/结果），用于复盘与阈值调优。
这样既保成本（高频不调模型），又保覆盖（长尾靠语义）。
参考答案（点击展开）
失败形态：① 置信度低；② 两路歧义；③ 路由到某路但该路报错；④ 完全无法归类。
统一原则"不瞎猜、可观测、能兜底"：
- 低置信/歧义 → 多路/反问/人工；
- 下游报错 → 换路重试（如 SQL 失败转 RAG 给概览）/ 降级 / 转人工，不静默返回空；
- 无法归类 → 友好拒答 + 审计日志；
- **红线**：绝不默认执行最危险的写操作(API)一路；所有决策记 Trace 便于复盘。
参考答案（点击展开）
指标：
- **路由准确率**：标注集测"问题→正确路由"命中率（三路分别算）；
- **置信度校准**：低 conf 时是否真的更易错（ROC/阈值合理性）；
- **回退率**：低置信回退占比，过高说明路由模型弱或意图太杂；
- **Trace**：问题/类别/conf/是否回退/最终路/结果全记录。
为什么权重高：路由是 Agent 质量的"开关"，一旦走错路，下游 RAG/SQL/API 全错，代价被放大。所以路由的监控与优化优先级应高于单路能力——不可观测就不能优化。
参考答案（点击展开）
1. **"特药目录怎么规定"** → RAG。属知识/条款类，答案在政策文档，需检索+溯源，不能让模型硬编。走 W3 检索生成。
2. **"我上月报了多少"** → SQL。属结构化聚合，数据在理赔库。路由决定走 SQL 后，仍要过 Day5 安全校验五关（只读/白名单/参数化/行数/EXPLAIN），结果再由模型解释成"您上月报了 ¥X"。
3. **"理赔到哪步了"** → 业务 API。属实时状态查询，数据变化快不能靠 RAG 索引（会过期）。走 W2 工具调用查进度接口，带鉴权，返回当前状态。
三者最终都由编排层统一组织成自然语言回用户。这体现"路由是大脑、下面是肌肉"的架构。
参考答案（点击展开）
confidence 0.45 远低于阈值，不能瞎猜执行。处理：
1. **澄清反问**："您是想查报销金额、看理赔进度，还是其他？"把歧义抛回用户。
2. 或**多路并行**：只读地并行查 RAG（政策）与 API 状态查询（进度），汇总后让模型择优选（注意：并行也只用"读"类 API，绝不包含写操作）。
3. 仍不确定则**转人工**。
**误判成 API 去"提交理赔"的后果**：那是无意间触发了写操作——可能真实创建一笔理赔申请、绕过用户本意、产生业务后果与资损，且无用户确认、审计缺失。这正说明：写操作类意图的置信度阈值必须设高，低置信宁可反问/转人工，绝不盲执行。