FDE W5 Day 6 学习手册 · 三路数据路由

W5 Day6 · A 级（必须掌握，面试核心）· 3h · 学完能讲透"一个问题怎么决定走 RAG / SQL / 业务 API"

一、为什么需要数据路由（上层编排）

企业 Agent 面对的问题类型混杂：有的问"特药目录怎么规定"（知识类），有的问"我上月特药报了多少"（结构化查询），有的问"我的理赔现在到哪一步了"（实时状态/写操作）。没有路由，所有问题都塞给一个能力，必然又慢又错：拿聊天问题去查库会查不到，拿知识问题去 SQL 会空跑。

二、三路能力全景

三、RAG 路由：知识类问答

当问题涉及文档内容、条款、政策、知识且需要"引用出处"时走 RAG。它从知识库检索相关片段，再让模型基于片段作答，降低幻觉。

• 触发信号：问题含"怎么规定""依据什么""目录说""条款"等关键词；或路由模型判定为"知识类"。
• 特药理赔示例："特药报销比例是多少""罕见病目录包含哪些"——答案在政策文档里，必须检索而非编造。
• 边界：RAG 不擅长实时数据（"现在额度剩多少"要看库/API）和写操作。

四、SQL 路由：结构化查询

当问题涉及聚合统计、条件筛选、跨表关联且数据在结构化库里时走 SQL（Text2SQL，详见 Day5）。

• 触发信号：问题含"多少""统计""Top""哪个保单""上个月"等聚合/筛选词。
• 特药理赔示例："我上月特药报了多少""哪些保单额度没用完"——答案在理赔库，需聚合。
• 边界：必须只读+白名单（Day5 已讲）；不适合知识类（查不到）和写操作（越权）。

五、业务 API 路由：实时状态 / 动作执行

当问题需要实时状态查询或写操作/动作执行时走业务 API（工具调用，详见 W2 Tool）。

• 实时状态：理赔进度、额度余额、审核状态——数据变化快，不能靠 RAG 索引（会过期），要查实时接口。
• 动作执行："帮我提交一笔理赔""发起申诉"——这是写操作，必须走有鉴权/审计的业务接口，绝不能 SQL 写库（越权+无业务校验）。
• 特药理赔示例："我的特药理赔现在到哪一步了"（查进度 API）、"帮我上传材料"（调提交 API）。

六、路由判断方式：LLM 分类 vs 规则

6.1 规则路由（确定性）

用关键词/正则/意图模板硬匹配：含"多少/统计"→SQL；含"规定/条款"→RAG；含"提交/进度"→API。快、可解释、零成本，但覆盖有限、泛化差。

6.2 LLM 分类路由（语义）

让一个（通常较小的）模型把问题分类到 RAG/SQL/API，可带 few-shot 和置信度输出。语义理解强、泛化好，但有成本、有概率判错。

6.3 混合（推荐）

先用规则兜底高频明确意图，规则不确定再交 LLM 分类；或 LLM 分类 + 置信度阈值，低于阈值走回退。

七、路由 Prompt 设计与 confidence

用 LLM 分类时，prompt 要明确输出路由类别 + 置信度，便于下游门控。

route_prompt = f"""
把用户问题分类到：RAG(知识条款) / SQL(结构化统计) / API(实时或写操作)。
只输出 JSON：{{"route": "RAG|SQL|API", "confidence": 0.0~1.0, "reason": "..."}}
问题：{question}
"""
res = llm(route_prompt, temperature=0, response_format="json")
if res["confidence"] < 0.6:
    return fallback(res)   # 低置信回退

八、低置信度回退：多路 or 人工

当路由 confidence 低于阈值，或两路得分接近（歧义）时，不能硬选一路，要有回退策略：

• 多路并行：同时走 RAG + SQL（或 Top-2），把多路结果汇总/让模型择优选。代价是多花成本，但更稳。
• 澄清反问：向用户追问"您是想查报销金额，还是看报销规定？"——把歧义抛回给用户。
• 转人工：高风险/仍不确定时，转人工坐席，绝不裸奔。

九、与 W2 Tool、W3 RAG 的关系：路由是上层编排

路由不是孤立的新东西，它是站在 W2 和 W3 之上的编排层：

• W2 Tool（工具调用）：提供"调用业务 API"的原子能力。路由的 API 一路，最终落到的就是 W2 定义的 tool。
• W3 RAG：提供"检索知识"的原子能力。路由的 RAG 一路，调用的就是 W3 的检索+生成。
• Day5 SQL：提供"查结构化库"的原子能力。路由的 SQL 一路调用它。

十、路由失败处理：不瞎猜

路由失败有几种形态，处理原则统一为"不瞎猜、可观测、能兜底"：

十一、路由评测与可观测

路由是 Agent 质量的"开关"，必须被评测和监控：

• 路由准确率：用标注集测"问题→正确路由"的命中率（RAG/SQL/API 分别算）。
• 置信度校准：confidence 低时是否真的更易错？看 ROC/阈值合理性。
• 回退率：低置信回退占比，过高说明路由模型太弱或意图太杂。
• Trace：每次记录"原始问题 / 路由类别 / confidence / 是否回退 / 最终走哪路 / 结果"。

十二、面试达标线①：三路各自适用 + 怎么判断走哪路

1. RAG：知识类、条款解释、需引用出处；如"报销比例怎么规定"。
2. SQL：结构化聚合/筛选/关联；如"上月报了多少"；进来仍过安全校验。
3. API：实时状态、写操作；如"理赔到哪步""提交理赔"；带鉴权审计，绝不用裸 SQL 写。
4. 判断方式：规则兜底高频意图 + 小模型 LLM 分类 + confidence 门控；写操作阈值更高。

十三、面试达标线②：路由失败 / 低置信度怎么处理（不瞎猜）

十四、Day 6 自测清单

十五、高频面试题速记卡