模型路由（LLM Routing）

一句话定义：用便宜模型先判断”这条请求是什么”，再让代码决定它该交给哪个处理器——可能是纯确定性的代码、某个专用 LLM，或一个人。路由（Routing）的核心不是”让 AI 回答”，而是”让 AI 决定谁来回答”。

1. 要解决的问题

官方的意图路由（Intent Routing）模式开篇就说清了动机：

“Not every user request needs the same kind of handler. Some can be answered with a database lookup. Some need an LLM with domain-specific context. Some need a human. TypeSafe can sit in front of all of these as a fast, cheap classifier that determines which handler to invoke.”

翻译：并非每条用户请求都需要同一种处理器（Handler）。有些查一次数据库就能回答，有些需要带领域上下文的 LLM，有些需要一个人。TypeSafe 可以站在这些处理器前面，当一层快速、便宜的分类器（Classifier），决定该调起哪一个。

关键点：分类这一步必须便宜得快，否则”为了省大模型的钱，先花掉同样多的钱”就没有意义。Jev 的分类结果直接对应代码分支，不做自由文本生成。

2. 官方模式表里的定位

patterns.md 把意图路由和另外三个模式并列：

模式	做什么	好处
投机式扇出（Speculative Fan-out）	一次问很多问题（含投机性问题），让代码决定哪些相关	成本、速度
置信度门控（Confidence-Gated Routing）	把置信度当第二条决策轴，构建更安全的系统	可靠性、安全
复合评分（Composite Scoring）	把多个分析维度合成一个分数	成本、可靠性、速度
意图路由（Intent Routing）	分类用户意图，路由到合适的处理器	成本、速度

官方描述：“Classify a user’s intent and route to the appropriate handler”（分类用户意图并路由到合适的处理器）。

3. 官方示例一：客服路由（0.5 阈值）

patterns__intent-routing.md 的完整例子：一条客服消息进来，一次请求同时问两个问题——选择题（Choice）intent（订单状态 / 产品咨询 / 退换货 / 投诉），打分题（Score）complexity（3 档：简单查询 / 需要判断 / 边缘情况需升级）。

if intent.confidence < 0.5:
    # 连"这是什么意图"都没把握，直接转人工
    return route_to_human_agent(ticket_id)
 
if intent.choice == "order_status":
    handle_order_status(ticket_id)          # 确定性代码，不经过 LLM
elif intent.choice == "product_question":
    handle_with_llm(ticket_id, PRODUCT_SPECIALIST)   # 专用 LLM
elif intent.choice == "return_exchange":
    handle_with_llm(ticket_id, RETURNS_SPECIALIST)   # 专用 LLM
elif intent.choice == "complaint":
    if complexity.score > 1 or complexity.confidence < 0.5:
        route_to_human_agent(ticket_id)     # 太复杂或没把握 → 人工
    else:
        handle_with_llm(ticket_id, COMPLAINT_RESOLUTION)

“One intent routes to deterministic code with no LLM involved. Two route to different specialist LLMs, each loaded with different context. One uses the complexity score to decide between an LLM and a human. TypeSafe handles the classification all in a single quick call; the expensive resources only get invoked for the requests that actually need them.”

翻译：一个意图走纯确定性代码、完全不碰 LLM；两个走不同的专用 LLM，各自加载不同上下文；最后一个用复杂度分数在”LLM 还是人”之间做选择。分类全部在一次快速调用里完成，昂贵资源只为真正需要它的请求而启动。

注意这里出现了两条门槛：intent.confidence < 0.5 是”没把握就别猜”，complexity.confidence < 0.5 是”连难度都没把握也是一种没把握”。

4. 官方示例二：语音银行（0.6 / 0.85 阈值）

置信度门控模式（patterns__confidence-routing.md）给的是语音银行（Voice Banking）示例，同一个意图问题，不同动作配不同阈值：

动作	置信度要求	结果
任意动作	低于 0.6	转人工客服
check_balance（查余额）	≥ 0.6	直接读出余额
approve_transfer（批准转账）	0.6 ～ 0.85	先请用户确认
approve_transfer	> 0.85	自动执行
其他意图	—	转人工客服

官方解释：

“While you always want to have reasonable confidence in interpreting the user’s intent, some actions are riskier than others and thus demand a higher confidence threshold.”

翻译：虽然你总希望解读用户意图时有合理的置信度（Confidence），但某些动作风险更高，因此要求更高的置信度阈值。

这就是路由与置信度门控的接合点：路由决定”分支去哪”，置信度决定”这个分支到底走不走、要不要升级（Escalate）或回退（Fall back）。

5. 升级与人工兜底

concepts__how-to-build-with-system-one.md 把”按不确定性路由”列为构建步骤之一：

“Make code take different actions for confident and unconfident answers. Escalate uncertain cases to a person or a more expensive reasoning model. Test thresholds by plotting confidence against accuracy on your data.”

翻译：让代码对”有把握”和”没把握”的答案采取不同动作。把不确定的个案升级给一个人，或升级给一个更贵的推理模型。用你自己的数据把置信度对准确率画出来，去测阈值（该文档的示例代码用 confidence < 0.8 转人工复核）。

6. 官方用例地图里的模型路由

concepts__use-case-map.md 在”模型路由”条目下列出的用法：

• 用 Jev 构建自定义路由器，决定哪条 prompt 交给哪个 LLM；
• 为你的具体工作流设定路由规则与阈值；
• 分类意图与领域；
• 估计难度与风险；
• 把需要更贵模型的请求升级出去。

同一页把这归入工程框架增强（Harness Engineering）大类——路由是框架（Harness）的职责，不是模型的职责，参见 模型与框架分责。

7. 工程要点

• 先分类，再花钱：分类那一步必须足够便宜，否则省不下来；能查库解决的分支直接写代码，不碰 LLM。
• 一个请求装多个分类问题：意图与复杂度同一次调用问完，别串行问（见 投机式扇出）。
• 阈值不是一个数：低风险动作可以低，高风险动作必须高（见 置信度门控）。
• 给”不确定”留出路：转人工或转更贵的推理模型，别硬猜。

相关来源

• processed/jev-原始资料/官方-文档/patterns__intent-routing.md（客服路由示例、0.5 阈值）
• processed/jev-原始资料/官方-文档/patterns__confidence-routing.md（语音银行 0.6 / 0.85）
• processed/jev-原始资料/官方-文档/patterns.md（四种模式的官方定位）
• processed/jev-原始资料/官方-文档/concepts__use-case-map.md（模型路由用例）
• wiki/synthesis/Jev 知识.md（面向阅读的综合讲解）