从任务识别、模型分层、质量闸门、降级升级、成本预算到线上观测，理解生产 AI 系统为什么不能“一把大模型打天下”
| 环节 | 它决定什么 | 常见风险 | 工程动作 |
|---|---|---|---|
| 请求识别 | 任务类型、复杂度、语言、风险、SLA 和预算 | 分类错导致便宜模型误接高风险请求 | 规则 + 小模型分类、置信度、兜底升级 |
| 路由策略 | 请求走哪个模型、哪个供应商、哪个部署池 | 策略散落在业务代码里，难审计难回滚 | 集中策略表、版本化、灰度和审计 |
| 模型分层 | 小模型、大模型、专用模型和人工流程怎样配合 | 所有任务都走最强模型，成本失控 | 按价值、复杂度、风险和延迟分 tier |
| 质量闸门 | 输出是否足够可信，是否需要重试或升级 | 只看模型返回成功，不看内容质量 | schema、引用、规则、Judge、置信度校验 |
| Fallback | 超时、失败、低置信或高风险时怎样处理 | 无节制重试造成成本和延迟雪崩 | 最大重试、退避、降级模板、升级强模型或人工 |
| 观测回流 | 路由是否真的降低成本、保持质量 | 不知道错路由、误降级和隐藏退化 | 记录 route decision、候选模型、分数、成本和结果 |
模型路由不是“便宜模型先试试”，而是一套带质量证据、失败处理和发布治理的决策系统。
| 证据组 | 字段示例 | 回答的问题 | 关联治理 |
|---|---|---|---|
| 请求画像 | request_type、task_type、language、context_tokens、risk_tier、tenant_id | 这次请求为什么被归为这类任务和风险？ | 风险分级、请求 Trace |
| 候选集合 | candidate_models、excluded_models、exclusion_reason、region_policy | 有哪些模型可选，哪些因为能力、区域、合规或容量被排除？ | 治理 / 合规 |
| 策略命中 | router_policy_version、matched_rule、quality_floor、budget_cap、latency_slo | 命中了哪条路由规则，它要求的质量、成本和延迟边界是什么？ | 成本 / 性能 |
| 最终选择 | selected_model、model_version、provider、deployment_pool、route_reason | 最终为什么选这个模型，而不是更强、更便宜或备用模型？ | 模型服务 / 网关 |
| Fallback 轨迹 | attempt_no、failure_type、retry_count、fallback_model、fallback_reason、user_visible_degradation | 如果发生降级、重试或升级，触发原因和用户可见影响是什么？ | 灰度 / 回滚 |
| 结果回填 | ttft_ms、total_latency_ms、input_tokens、output_tokens、quality_signal、feedback_label | 这次路由实际是否达到了质量、成本和延迟目标？ | LLMOps / 评测 |
模型变更、价格变化、供应商故障、风险策略调整都会改变路由结果。把候选模型、排除原因、命中规则、最终模型、fallback 轨迹和结果指标放进同一份证据包，才能在事故、成本异常或质量退化时复现当时的决策。
| 请求类型 | 适合模型 | 为什么 | 要兜住什么 |
|---|---|---|---|
| 分类 / 打标签 / 轻量抽取 | 小模型或规则优先 | 结构明确、成本敏感、可批量 | schema 合法率、低置信升级 |
| 复杂推理 / 多约束规划 | 强模型或推理模型 | 需要长链路推理和更高可靠性 | 预算上限、步骤验证、失败解释 |
| 代码生成 / 修复 | 代码专用模型 + 测试执行 | 质量最终要靠编译、测试和上下文匹配 | 单测、静态检查、权限边界 |
| RAG 问答 | 中强模型 + 引用校验 | 关键在证据使用，不一定永远靠最大模型 | 检索命中、忠实度、不可回答识别 |
| 安全 / 合规判断 | 规则 + 专用审核模型 + 人工升级 | 责任边界高，不能只靠通用模型自由判断 | 误拒误放、审计证据、人工复核 |
| 长文档总结 | 长上下文模型或分块流水线 | 受上下文长度、成本和忠实度共同约束 | 覆盖率、引用定位、遗漏检查 |
| 闲聊 / 低风险文案 | 低成本通用模型 | 质量容忍度较高，成本更重要 | 品牌语气、安全底线、用户体验 |
| 触发条件 | 不好的做法 | 更稳的 Fallback | 观测指标 |
|---|---|---|---|
| 模型超时 | 无限重试同一模型 | 退避重试、切备用池、降级短回答或异步完成 | 超时率、重试次数、P95 / P99 |
| 供应商限流 | 所有流量继续打满主供应商 | 按优先级排队，低价值请求降级，关键请求切备用 | 限流率、队列长度、请求等级分布 |
| 输出格式错误 | 把错误文本直接给用户 | schema 修复、低温重试、换模型或返回可解释失败 | schema 合法率、修复成功率 |
| 低置信 / 高风险 | 强行生成自信答案 | 检索补证据、升级强模型、拒答或人工复核 | 低置信占比、人工升级率、严重错误率 |
| 成本预算接近上限 | 继续完整链路执行 | 缩短上下文、停用非必要工具、切小模型或提示用户收窄问题 | 预算命中率、降级后满意度 |
| 质量闸门失败 | 只要有输出就放行 | 用 Judge / 规则 / 引用校验决定重跑、升级或中止 | 闸门失败率、升级收益、坏例复发率 |
生产系统要明确“失败类型、下一步动作、最大次数、用户可见文案、审计记录”。否则重试和降级会变成不可解释的成本黑洞。
| 目标 | 路由倾向 | 可能牺牲 | 需要的证据 |
|---|---|---|---|
| 最高质量 | 强模型、并行候选、Judge 复核 | 成本、延迟、吞吐 | 关键任务成功率、人工验收、业务结果 |
| 最低成本 | 小模型、规则、缓存、级联 | 复杂任务质量和边界能力 | 切片 Eval、坏例率、用户满意度 |
| 最低延迟 | 近端部署、小模型、短上下文、少工具 | 上下文完整性和推理深度 | TTFT、P95、完成率 |
| 最高安全 | 审核模型、规则、人工升级、保守拒答 | 可用性、响应速度 | 误拒率、误放率、审计样本 |
| 高可用 | 多供应商、多区域、降级策略 | 一致性、输出风格、治理复杂度 | SLA、Fallback 命中率、供应商差异评测 |
路由策略不要只按“模型价格”写，也要按请求价值、失败成本、用户等待容忍度和可验证性来写。
| 评测项 | 回答的问题 | 样本设计 | 指标 |
|---|---|---|---|
| 路由准确性 | 请求是否被送到合适模型 | 按任务、风险、语言、长度和租户分层 | 误路由率、低置信率、人工纠正率 |
| 升级收益 | 升级强模型是否真的改善结果 | 便宜模型失败样本、边界样本、高价值样本 | 升级后通过率、增量成本、增量质量 |
| 降级损失 | 降级后质量是否仍可接受 | 低风险场景、缓存命中场景、供应商故障场景 | 满意度、错误率、任务完成率 |
| 供应商差异 | 备用模型是否能替代主模型 | 同一批样本在多个模型上跑 | 风格差异、格式差异、能力差异 |
| 成本收益 | 路由策略是否降低单位价值成本 | 真实流量回放和灰度实验 | 单位请求成本、单位成功成本、预算命中率 |
| 安全边界 | 路由是否放大风险 | 高风险、提示注入、隐私、越权和误拒对照 | 误放率、误拒率、人工升级率 |
一个平均成本下降的策略，可能只是在低风险流量上很好，但在长尾语言、复杂任务或高价值客户里退化。路由策略上线前至少要看任务、语言、风险、长度和租户切片。
模型服务 / 网关解释多模型能力怎样被统一接入，成本 / 性能解释单位价值怎样优化，LLMOps / 评测解释线上怎样观测。本页补中间的决策层：请求怎样被分流、失败怎样被处理、质量怎样被守住。