Wiki Notes

Appearance

模型路由与策略引擎专题 ​

版本：v1.2

最后更新：2026-07-08

AI 系统一旦从 Demo 走向真实流量，几乎都会遇到一个现实问题：

  • 不是所有请求都应该走同一个模型

有的请求更在意：

  • 成本
  • 延迟
  • 吞吐

有的请求更在意：

  • 推理能力
  • 工具调用稳定性
  • 高风险场景下的正确率

这篇专题聚焦的不是“怎么选一个最好模型”，而是：

  • 如何让不同请求走不同模型和不同工作流
  • 如何把这些决策沉淀成可治理、可观测、可回退的策略系统

1. 什么是模型路由 ​

模型路由本质上是在回答：

  • 这个请求，应该交给哪个模型、哪条工作流、哪组参数

它通常不只决定模型，还会一起决定：

  • prompt 模板
  • 是否启用检索
  • 是否暴露工具
  • 是否走缓存
  • 是否进入审批
  • 是否允许升级更强模型

所以成熟系统里的“路由”其实是一次运行时决策，而不只是静态选个模型名。

2. 为什么生产系统几乎一定会走向路由 ​

根据 OpenAI 官方关于 model selection、reasoning best practices、latency optimization、cost optimization 的资料，真实系统必须在质量、成本、时延之间做取舍。

这意味着一个直接的工程结论：

  • 成熟系统通常不是单模型，而是组合路由

原因很简单：

  • 简单分类不值得走最强推理模型
  • 高风险复杂任务又不能只靠便宜快模型
  • 长任务、批处理、实时交互对路线要求也不同

如果所有请求都走同一路线，常见后果通常是：

  • 成本失控
  • 时延过高
  • 高峰吞吐扛不住
  • 高风险场景质量仍然不够稳

3. 路由真正要决定的对象，不只是“模型” ​

更好的路由对象通常至少包含这些维度：

json
{
  "model": "medium-default",
  "workflow": "rag_answer_v3",
  "tools": ["search_docs", "lookup_policy"],
  "prompt_variant": "policy_strict_v2",
  "cache_policy": "prefix_cache_on",
  "approval_policy": "finance_review_required",
  "fallback": "large_reasoning"
}

也就是说，路由系统真正决定的是：

  • 这次请求应该用什么能力组合

而不是只决定：

  • 这次请求叫哪个模型

4. 什么是策略引擎 ​

如果说模型路由回答的是：

  • 走哪条路径

那么策略引擎回答的是：

  • 在什么条件下走哪条路径
  • 哪些路径禁止某些请求进入
  • 出问题时怎么升级、降级或转人工

它更像系统的控制面，负责把“选型经验”沉淀成可执行规则。

一个简单的策略引擎通常会控制：

  • 任务分类
  • 风险分层
  • 模型与 workflow 选择
  • 缓存与超时策略
  • fallback 策略
  • 审批策略
  • observability tags

4.1 更成熟的路由系统，其实更像“运行控制面” ​

OpenAI 当前 Models and providers、Production best practices、Flex processing、Priority processing 这些官方资料放在一起看，会发现生产系统真正需要控制的不只是：

  • 选哪个模型

而是整条运行 lane：

  • 同步还是后台
  • 普通 lane 还是 priority lane
  • 在线实时还是 batch / flex
  • 单 agent 默认模型还是 run 级覆盖模型
  • 失败后是升级更强模型、切文本兜底，还是转人工

也就是说，成熟的“路由”更像一套运行控制面，而不是一个 if/else 模型表。

4.2 route bundle 往往比单独 route key 更有治理价值 ​

很多团队只记录：

  • route=large_reasoning

但这在生产里通常不够，因为真正影响结果的往往还有：

  • prompt 版本
  • reasoning effort
  • 工具暴露范围
  • cache policy
  • approval policy
  • timeout / retry
  • service lane

更稳的做法通常是把这些组合沉淀成：

  • route bundle

也就是一套可版本化、可灰度、可回滚的运行模板。

这样后面才能更清楚地回答：

  • 这次变差是模型换了
  • 还是 lane 变了
  • 还是 approval / tool / prompt 一起变了

5. 建立路由前，先拆任务而不是先选模型 ​

很多团队一开始就问：

  • 我们到底用哪个模型

更稳妥的顺序通常是：

  1. 先拆出请求里的关键任务节点。
  2. 再看每个节点对质量、时延、成本的要求。
  3. 最后为每个节点选择默认模型、升级模型和回退模型。

例如一个知识库问答流程，真实上线路径可能是：

text
User Request
 -> intent classify
 -> query rewrite
 -> retrieve
 -> rerank
 -> answer generate
 -> citation check
 -> risk review
 -> final response

这些节点通常不应该全用同一个模型。

6. 常见路由维度 ​

6.1 按任务类型 ​

  • 分类任务
  • 检索问答
  • 复杂推理
  • 代码生成
  • 结构化抽取
  • 多模态任务

6.2 按任务复杂度 ​

  • 简单
  • 中等
  • 高复杂

复杂度可以来自：

  • 上下文长度
  • 需要多少步推理
  • 是否涉及多个工具
  • 是否存在模糊目标

6.3 按风险等级 ​

  • 普通请求
  • 受限请求
  • 高风险审批请求

高风险任务通常更适合：

  • 更强模型
  • 更严格 guardrails
  • 更高审批级别

6.4 按 SLA ​

  • 实时优先
  • 质量优先
  • 成本优先
  • 离线批处理

6.5 按用户或租户等级 ​

  • 免费用户
  • 付费用户
  • 企业客户
  • 核心业务租户

6.6 按运行 lane ​

OpenAI 当前官方资料已经把几种 lane 区分得比较清楚：

  • 普通同步请求
  • Priority processing
  • Background mode
  • Batch
  • Flex processing

这给模型路由很直接的启发是：

  • 不是所有任务都该只在“模型维度”上选路

很多任务更应该先判断：

  • 用户是否在等待
  • 是否允许更慢但更便宜
  • 是否适合离线批量处理
  • 是否应该进入高优先级 lane 保证时延

所以真实生产系统里的 route，往往至少会同时决定：

  • model
  • service_lane
  • execution_mode

7. 三种最常见的路由模式 ​

7.1 静态规则路由 ​

根据固定业务规则分配。

优点：

  • 简单
  • 可解释
  • 易审计

缺点：

  • 灵活性有限
  • 需要人工维护

7.2 分类器路由 ​

先用规则或轻模型识别请求类型，再决定下游路径。

优点：

  • 更适合复杂产品
  • 能把复杂度前置到一个轻量入口

缺点：

  • 分类器本身也会出错
  • 错误路由会把后续整条链路带偏

7.3 分层升级路由 ​

先走便宜快模型，只有在必要时才升级更强模型。

优点：

  • 成本控制好
  • 适合大流量系统

缺点：

  • 需要定义清晰的升级条件
  • 不然容易出现该升不升、不该升乱升

7.4 shadow route / 对照路由 ​

很多团队上线新路由时，最怕的是：

  • 一切看起来合理
  • 但真放量后才知道策略错了

更稳的做法通常是先做 shadow route：

  • 主路径继续服务用户
  • 新路径在后台并行决策或并行跑结果
  • 不直接对用户生效
  • 先比较质量、成本和时延差异

这类方式特别适合：

  • 新模型切换
  • 新分类器引入
  • 新 escalation 规则上线
  • route bundle 大改

8. 一套更实用的策略字段 ​

真正可维护的策略系统，建议至少显式化这些字段：

json
{
  "task_type": "rag_answer",
  "complexity": "medium",
  "risk": "high",
  "service_lane": "priority_sync",
  "latency_sla_ms": 4000,
  "budget_tier": "standard",
  "default_model": "medium-default",
  "escalation_model": "large-reasoning",
  "fallback_model": "small-fast",
  "reasoning_effort": "medium",
  "requires_approval": true,
  "max_tool_calls": 4,
  "cache_policy": "prefix_cache_on",
  "route_bundle_version": "rb_2026_07_08_01"
}

这样做的价值是：

  • 路由逻辑可观察
  • 问题更容易复盘
  • 灰度和回退更容易执行

8.1 route policy 最好显式区分“入场条件”和“升级条件” ​

很多路由系统最容易混乱的地方在于：

  • 初始怎么选路
  • 后续什么时候升级

被写成一锅。

更稳的字段设计通常会区分：

  • entry_conditions
  • escalation_conditions
  • fallback_conditions
  • manual_override_conditions

因为这几件事本来就是不同决策：

  • 先走哪条路
  • 走到一半何时升级
  • 失败后怎么降级
  • 什么时候直接交给人

8.2 人工 override 和 route freeze 也应该是策略字段 ​

生产事故里很常见的一类动作是：

  • 暂时冻结某条 route
  • 暂时强制所有高风险请求走更稳的 bundle
  • 暂时关闭某个升级规则

如果这些都只能靠临时改代码，平台会很难接住高频变化。

更稳的做法通常是显式支持：

  • force_route
  • disable_route
  • freeze_bundle_version
  • tenant_override
  • incident_mode

这样值班同学在事故里才能：

  • 先止血
  • 再修根因

9. fallback 不是补丁，而是设计的一部分 ​

很多系统不是“从来不出错”，而是：

  • 出错时能不能优雅回退

常见 fallback 类型包括：

  • 强模型超时时降级到更快模型
  • 小模型低置信时升级到更强模型
  • 工具超时时切纯文本解释
  • 检索为空时切拒答或通用说明
  • 高风险任务直接切人工确认

这里最容易犯的错是：

  • 只定义 fallback 路径，不评估 fallback 效果

如果 fallback 触发后质量直接崩掉，它就不是“兜底”，只是“把失败换个样子表现出来”。

9.1 升级阈值最好来自可观测信号，而不是拍脑袋 ​

OpenAI 当前 Reasoning best practices、Models and providers 与 Evaluate external models 放在一起看，会指向一个很实用的工程结论：

  • 升级阈值最好由评测和线上信号共同校准

例如可以考虑：

  • 低置信分类
  • 检索证据分数不足
  • 需要工具次数超过阈值
  • structured output 多次失败
  • route 历史成功率对该 bucket 偏低

如果升级阈值只是“感觉这个场景复杂”，后面通常会出现：

  • 升级过多，成本失控
  • 升级过少，高风险请求仍然掉到便宜路径

9.2 fallback 也要分“质量兜底”和“风险兜底” ​

很多团队只把 fallback 理解成：

  • 模型失败时换一个模型

但真实系统里至少还有两种 fallback：

  • 质量兜底
    • 小模型不稳 -> 升到强模型
  • 风险兜底
    • 高风险请求 -> 切审批 / 转人工 / 只返回建议稿

这两类 fallback 不是一回事。

前者重点在：

  • 结果更好

后者重点在：

  • 副作用更可控

10. 路由系统必须绑定成本和延迟指标 ​

模型路由不是只为了省钱，也不是只为了提速，而是为了在目标边界内平衡质量。

建议至少关注这些指标：

  • route_accuracy
  • unnecessary_large_model_rate
  • escalation_success_rate
  • fallback_success_rate
  • cost_per_route
  • p50_latency / p95_latency / p99_latency
  • quality_delta_after_routing

其中很重要的一点是：

  • 不要只看平均值

生产系统里更危险的往往是：

  • P95/P99 延迟
  • 高风险任务上的错误路由
  • 大模型使用占比突然飙升

10.1 线上最值得额外盯住的是 route drift ​

很多团队只关注模型 drift，却忽略 route drift。

route drift 常见表现是：

  • 某个 bucket 进大模型的比例突然抬升
  • 某条 low-cost path 几乎不再命中
  • 某个租户被错误地持续打进高风险路径
  • 某次 prompt / workflow 变更后升级链路明显变长

也就是说，路由系统本身也是会漂移的。

更稳的监控方式通常会单独看：

  • route hit distribution
  • escalation distribution
  • fallback distribution
  • per-tenant route skew

11. 路由策略如何和 Prompt、工具、缓存联动 ​

成熟的路由系统不应只选模型，还应联动下面几件事。

11.1 Prompt 版本 ​

不同路径可能绑定不同 prompt 版本。例如：

  • 简单分类路径使用短 prompt
  • 高风险金融路径使用更严格规则 prompt

11.2 工具暴露范围 ​

不同路径应暴露不同工具集。

例如：

  • 低风险问答路径只给读工具
  • 审批执行路径才给写工具

11.3 缓存策略 ​

有些路径适合更强的 prefix caching，有些路径动态内容太多，缓存收益有限。

11.4 审批策略 ​

高风险路由不只该换模型，还应同步换 guardrails 和 approval policy。

11.5 reasoning effort 和服务优先级也应该进入联动面 ​

OpenAI 当前最新模型与 reasoning 官方资料已经明确把 reasoning.effort 作为性能 / 时延 / 质量曲线上的调节杆；Priority processing、Flex processing 和 Batch 又把服务优先级与成本形态拆得更清楚。

这意味着成熟系统里一个 route 真正联动的对象通常还包括：

  • reasoning effort
  • execution mode
  • service tier / priority lane
  • batch / flex eligibility

也就是说，很多时候你不是只在做：

  • 换模型

而是在做：

  • 换整条运行曲线

这也是为什么模型路由最终会和这些专题打通：

12. 评测路由，不要只评最终结果 ​

一个常见误区是：

  • 只比较“最后回答好不好”

但路由本身至少要被单独评测：

12.1 路由正确率 ​

  • 是否把请求分到了合适路径

12.2 成本节约率 ​

  • 和统一大模型方案相比节约了多少

12.3 质量损失 ​

  • 成本下降后质量是否出现不可接受退化

12.4 升级与回退成功率 ​

  • 小模型失败后升级是否真能兜住
  • fallback 是否仍满足最低业务标准

12.5 路由解释性 ​

  • 你能不能回答“为什么这次走了这条路线”

如果解释不清楚，后续上线问题通常也难复盘。

12.6 route bundle 也应该有自己的回归集 ​

很多团队会给模型建回归集，但不会给 route bundle 建回归集。

更稳的做法通常是按这些维度准备路由专项集：

  • 简单但高频请求
  • 高风险复杂请求
  • 易误判 bucket
  • fallback 高频 bucket
  • 大客户 / 大租户专属 bucket

这样你评测的就不只是：

  • 模型本身强不强

而是：

  • 这套路由策略在关键分桶上会不会把请求送错地方

13. 一个简单但可执行的路由示例 ​

json
{
  "rules": [
    {
      "if": "task_type in ['classification', 'simple_extract'] and risk == 'low'",
      "route": "small_fast_path"
    },
    {
      "if": "task_type == 'rag_answer' and evidence_score >= 0.8 and latency_sla_ms <= 3000",
      "route": "medium_rag_path"
    },
    {
      "if": "risk == 'high' or complexity == 'high'",
      "route": "large_reasoning_with_approval"
    }
  ],
  "default_route": "medium_default",
  "fallback_route": "safe_text_only"
}

关键不是规则写得像不像代码，而是这些规则是否：

  • 可追踪
  • 可评测
  • 可灰度
  • 可回退

14. 上线后要观察什么 ​

路由系统上线后，建议持续记录：

  • 本次命中的 route
  • route 命中原因
  • 使用的模型与版本
  • 是否发生升级
  • 是否发生 fallback
  • 成本和时延
  • 最终质量信号

14.1 更成熟的路由观测最好保留“决策证据” ​

至少建议再保留：

  • 命中 route bundle 版本
  • 命中规则或分类器标签
  • 为什么升级
  • 为什么 fallback
  • 是否被人工 override
  • 是否在 incident mode 下被强制改道

否则上线后你可能知道：

  • 这次走了 large_reasoning

但仍然不知道：

  • 是规则命中的
  • 分类器打错了
  • 还是值班同学临时强制切过去的

没有这些观测，团队就很难判断：

  • 是模型退化了
  • 是路由规则变差了
  • 还是上游请求结构变了

15. 常见反模式 ​

15.1 所有请求走同一模型 ​

短期省事，长期一定在成本或质量上出问题。

15.2 路由逻辑散落在业务代码里 ​

最后没人知道系统完整策略到底是什么。

15.3 只看成本，不看质量 ​

这会把“优化”做成“退化”。

15.4 fallback 从不评测 ​

出了事故才发现 fallback 根本兜不住。

15.5 模型升级后不更新路由策略 ​

旧规则可能已经不再适配新模型行为。

15.6 把 route 当成模型名别名，而不是版本化控制面 ​

如果 route 只是：

  • 一个模型 slug

那后面几乎一定会遇到这些问题：

  • prompt、tool、cache、approval 一起变了却没记录
  • 新旧 bundle 无法并行灰度
  • 事故后不知道该回滚模型还是回滚整条运行模板

16. 一个更稳的落地顺序 ​

如果团队正在把模型路由做进生产，比较建议按这个顺序推进：

  1. 先拆任务节点。
  2. 为每类节点定义质量、成本、时延目标。
  3. 为候选模型建立能力画像。
  4. 先做静态规则路由。
  5. 为高价值路径补升级和 fallback。
  6. 跑路由专项评测。
  7. 再做灰度、观测和持续调优。

17.1 一个更稳的演进顺序，往往是“显式路由 -> bundle 化 -> shadow -> override” ​

很多团队一上来就想做“智能路由引擎”，但更稳的顺序通常是：

  1. 先把显式规则和 bucket 说清楚。
  2. 再把 route 决策沉淀成 bundle。
  3. 再给高价值路径做 shadow route。
  4. 再补人工 override、route freeze 和 incident mode。

这个顺序的好处是：

  • 每一步都能解释
  • 每一步都能回退
  • 每一步都能单独评测

这个顺序通常比“一上来做智能路由引擎”更稳得多。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下入口已按 2026-07-08 的 OpenAI 官方资料重新整理：