跳到主要内容

多模型路由

核对日期：2026-05-09。

1. 定义与边界​

多模型路由是在一个 Agent 系统中按任务、风险、成本、延迟、模态或供应商可用性选择不同模型。它不是简单“多个模型投票”，也不是越多越好。有效路由必须可解释、可回放、可评测、可降级。

2. 为什么重要​

单模型架构简单，但在生产中会遇到成本过高、延迟不可控、某些任务能力不足、供应商故障和合规限制。多模型路由可以降低平均成本并提升可用性，但会增加测试矩阵和故障排查复杂度。

3. 核心机制​

路由依据示例风险
任务类型摘要走快速模型，复杂规划走推理模型分类器错判
风险等级高风险任务走强模型 + 审批低估风险
置信度小模型低置信度升级强模型置信度不可校准
成本预算超预算降级或拒绝降级影响质量
可用性主供应商失败切备用行为差异和数据政策差异
模态视觉/语音/代码专用模型上下文转换损失

4. 架构模式​

5. 工程实现​

路由决策要写入 Trace：

{
  "route_id": "support_ticket_v4",
  "selected_model": "reasoning_primary",
  "reason": ["high_risk", "requires_tool_sequence"],
  "fallbacks": ["balanced_model", "human_review"],
  "policy_version": "2026-05-09"
}

路由器示例：

def route(req):
    profile = classify(req)
    if violates_data_policy(profile):
        return "local_or_private_model"
    if profile.risk == "high":
        return "reasoning_with_approval"
    if profile.estimated_tokens > LONG_CONTEXT_THRESHOLD:
        return "long_context_model"
    if profile.complexity == "low":
        return "fast_model"
    return "balanced_model"

6. 生产实践​

  • 路由规则、模型卡、提示词、工具 schema 必须版本化。
  • 每条路由都要有回归集，不能只测总成功率。
  • fallback 不应绕过权限、审计、脱敏和用户确认。
  • 对不同供应商输出做统一归一化，避免下游依赖私有字段。
  • 记录路由前后的成本、延迟、成功率，防止“复杂路由看似省钱但失败重试更贵”。

7. 常见反模式​

反模式后果
随机 A/B 多模型投票成本上升，无法解释
分类器未评测高风险任务被路由到低能力模型
fallback 只换模型不换提示词/工具约束错误重复
provider adapter 泄漏到业务层后续迁移困难

8. 评测方法​

多模型路由需要评测两层：路由选择是否正确，以及被选模型是否完成任务。建议单独统计 route accuracy、fallback rate、escalation rate、per-route cost、per-route latency 和安全违规率。

9. 安全与治理​

供应商路由必须考虑数据区域、数据保留、合同条款和日志策略。跨供应商 fallback 时，要确认敏感数据是否允许发送。对本地开源模型也要评估模型权重来源、推理服务隔离和输出审计。

10. 路由策略设计​

多模型路由至少包含三层：任务画像、策略约束、运行时反馈。

层输入输出常见错误
任务画像用户目标、模态、工具需求、风险task_profile分类器未校准
策略约束数据等级、租户、预算、SLAallowed_routesfallback 绕过合规
运行时反馈错误码、置信度、验证结果retry/fallback/escalate只看模型错误，不看工具错误

路由规则示例：

routes:
  low_risk_summary:
    when:
      risk: low
      requires_tools: false
      max_input_tokens: 12000
    primary: fast_model
    fallback: balanced_model
    gates: [format]
  enterprise_write_action:
    when:
      risk: high
      side_effect: write
    primary: reasoning_model
    fallback: human_review
    gates: [format, policy, approval, audit]
  sensitive_data_task:
    when:
      data_classification: restricted
    primary: private_model_or_region_locked_provider
    fallback: deny_with_explanation
    gates: [policy, redaction]

11. Fallback 矩阵​

失败点可自动 fallback不应自动 fallback
主模型限流切备用模型或排队切到不满足数据政策的供应商
输出格式失败修复重试一次无限重试或放宽 schema
质量验证失败强模型 + 证据补充直接执行高风险工具
安全策略失败无换模型绕过拒绝
预算耗尽降级为草稿/摘要继续执行写操作
上下文超限压缩、检索、拆任务截断系统策略或审批要求

12. 工程示例：可回放路由事件​

{
  "trace_id": "tr_20260509_001",
  "route_decision": {
    "task_profile": {
      "risk": "high",
      "requires_tools": true,
      "data_classification": "internal",
      "estimated_input_tokens": 18000
    },
    "selected_route": "enterprise_write_action",
    "primary_model": "reasoning_model",
    "blocked_models": [
      {"model": "external_fast_model", "reason": "restricted_data_policy"}
    ],
    "fallback_chain": ["human_review"],
    "policy_version": "model-route-2026-05-09"
  }
}

13. 路由评测与门禁​

路由器自身要像分类模型一样评测。

指标定义低于阈值的处理
route accuracy人工标注路由与系统路由一致率调整规则或分类器
unsafe downgrade rate高风险任务被降级到低能力/低治理模型比例阻断发布
fallback success ratefallback 后任务成功比例优化 fallback 条件
cost saving net节省成本扣除失败重试成本停用复杂路由
provider drift同一路由不同供应商行为差异增加归一化和回归集

上线建议：

  • 每条 route 至少 50 到 200 条代表性样例，按业务风险调整。
  • A/B 实验只对低风险路由自动放量，高风险路由先 shadow。
  • 路由变更与模型变更分开发布，便于定位退化。
  • route 结果必须写入 trace，支持按 route 回滚。

14. 安全补充：跨供应商治理​

跨供应商 fallback 会引入新的数据治理问题：

  • 数据是否允许出境或进入另一家供应商。
  • 日志保留和训练使用策略是否一致。
  • 工具 schema 是否会暴露内部系统结构。
  • 同一安全拒绝在不同供应商上是否表现一致。
  • 供应商错误消息是否会泄露请求内容。

因此，fallback 链必须先通过 policy engine 过滤，再进入模型调用。

15. 权威资料​