返回知识库

AI 与提示 · 安全与运营

模型路由Model Routing

模型路由(routing)是 AI 调用层的策略:先读请求特征(意图/风险/工具/成本/数据地域),按版本化规则把一次请求分发到合适的模型、工具和地域;首选不可用只做有限幂等降级,敏感数据在发送前阻断跨域,循环用 hop 上限切断;每次选择都带 request id、规则版本和原因可审计。它不是按 IP 转发数据包的 network routing。

处理一个客服收件箱:快问快答,复杂工单深度路由

两张真实工单等待分派:积分 FAQ 应走快模型,重复扣款要走强模型 + 只读订单工具。处理完再模拟强模型 503,看一次有限降级怎样保留同一工单、查询证据与人工退款边界。

这是一个真实客服收件箱。路由器不是让运营先填参数,而是从工单本身读取复杂度、风险和工具需求:简单 FAQ 走快通道,重复扣款核验走深度通道,供应商故障只回退一次。

1 快通道2 深度通道3 有限降级

Support InboxAI 分派 · routing.rules/v3

2 new
L

林晓会员中心 · 1 分钟前

#2846 · FAQ

活动积分什么时候到账?

周末参加了活动,但积分还没显示。

WAITING待分派低风险 · 固定政策
W

吴辰账单与退款 · 3 分钟前

#2847 · 重复扣款

同一订单出现三笔扣款,能帮我核对吗?

需要核对三笔订单、判断重复扣款并给退款下一步。

WAITING待分派高复杂度 · 需只读工具
request规则待命中结果待分派

客服收件箱有两张新工单。路由器会先读每张工单的风险、复杂度和工具需求,再把结果写回工单;先处理第一张简单 FAQ。

这条任务弧直接证明三件事:路由按工单特征分级、模型选择与工具权限一起落单、失败只做有限幂等 fallback。地域与 PII 属于发送前硬边界,命中时应直接阻断而不是偷偷跨域。

离开这页,只记这几条

收件箱已经演示了分级、工具权限、审计和一次降级;这里给它们命名,并补上地域与循环等不适合塞进同一工单的硬边界。

按特征分发
路由先读意图、风险、工具需求、敏感字段、预算和地域,再决定一次调用去哪——不是固定走某一个模型。
能力 / 成本分级
档位 = 风险需求与预算上限的较高者。低风险短答走经济模型,高风险或需要工具至少走标准,紧预算压不过高风险。
工具权限受控
路由同时决定工具能不能调、调只读还是写入。退款这类副作用永远不交给模型自动执行,只走人工批准。
地域是发送前的硬边界
含敏感字段的请求,目标区域必须在 allowlist 内;不在就阻断跨域调用,脱敏或改用批准区域,而不是隐式发出去再补救。
故障只做有限幂等降级
首选供应商 429/5xx 只切换一次已批准的 fallback,不重放写入动作,新 request id、模型版本和原因都记进路由表。
循环用 hop 上限切断
模型触发工具、工具再回模型,容易死循环。用 hop / attempt / 总耗时上限停止,停止后转人工或安全模型。
每次选择可审计
request id、规则版本、命中规则、模型 / 工具 / 地域、fallback 次数和原因都要落盘;敏感内容不进日志。

什么时候要盯路由,盯这些信号

出现下面这些情况,路由才值得单独建;否则直接调一次模型可能更省。

  • 多模型 / 多供应商:有经济、标准、强多档可选,或多家供应商互为兜底——路由负责按请求挑合适的。
  • 成本敏感:账单随请求量起飞。用路由把低风险请求压到经济档,强模型只在必要时用。
  • 合规地域:处理 PII、医疗、金融数据,必须按地域 allowlist 发送——路由在发送前替你把门。
  • 故障要降级:供应商会 429/5xx。路由做有限幂等 fallback,比让用户看到原始错误更稳。
  • 不适合:只有一个模型、一个供应商、请求量很小、且无合规约束——直接调一次,比维护规则表便宜。

怎么把一次路由做对

从一条请求到可审计的结果,最短路径是这五步。

  1. 提取特征:意图、风险、PII、工具需求、token 长度、预算、数据地域。
  2. 命中版本化规则(R-SUPPORT / R-BUDGET / R-REGION / R-DEFAULT),不要靠隐式判断。
  3. 选定模型 + 工具权限(只读 / 禁止)+ 区域 allowlist;写入动作交人工。
  4. 发送;首选 503 只降级一次,循环到 hop 上限停止,地域不合规直接阻断。
  5. 落审计:request id + 规则版本 + 命中规则 + 模型/工具/地域 + fallback 次数 + 原因;敏感内容最小化。

同一目标,差一个关键选择

都要处理「退款工单」。差别只在能不能让模型直接写退款。

正例标准模型 + 只读订单工具,退款交人工

模型读订单状态并生成解释;退款这个副作用必须经过权限和人工批准。首选故障只降级一次,敏感字段只去批准区域。可审计、可回滚。

反例强模型 + 可写工具,自动退款

为了让请求「一条龙完成」把写入权限交给模型,路由不做边界。一次 prompt 注入或幻觉就能直接动用户的钱;出了问题也说不清是哪条规则放行的。

快速自测

一个低风险 FAQ 改写请求,预算很紧;候选的强模型返回更快但更贵。路由该怎么走,为什么不能默认用强模型?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。