多模型路由、降级和 fallback 应该如何设计？
简化版
多模型路由是在不同模型之间按任务、成本、延迟、质量和可用性选择执行路径。生产系统通常用规则、分类器或打分器路由，并设计超时重试、备用模型、降级答案和人工兜底，避免单个模型故障拖垮业务。
详细版
- 简单任务可以走便宜快的小模型，复杂任务走强模型。
- 路由依据包括任务类型、用户等级、上下文长度、风险等级和实时可用性。
- fallback 要处理输出差异、能力差异和上下文窗口差异。
- 降级策略可以返回模板答案、排队、人工处理或只读模式。
- 多模型体系要有统一评测和日志，否则无法比较质量。
完整版教学
记忆钩子：模型路由像交通调度，目标不是永远走最强模型，而是在质量、成本和稳定性之间选路。
一、这题真正考什么
记忆钩子：模型路由像交通调度，目标不是永远走最强模型，而是在质量、成本和稳定性之间选路。
面试官真正想看的是你有没有生产工程视角：能不能把模型能力、业务流程、用户体验、成本和风险放在同一张图里思考。回答时不要只停留在工具名，而要讲出边界、链路和验收方式。
二、核心原理和工程边界
单模型系统简单但脆弱：价格波动、限流、超时和质量退化都会直接影响业务。多模型路由把请求分配给不同能力和成本的模型，再通过 fallback 处理失败。关键是提前定义哪些请求可以降级，哪些必须走强一致或人工确认。
LLMOps 的难点在于模型行为不是传统函数调用，输入稍变、模型版本稍变、上下文稍变，都可能让输出分布变化。因此工程系统必须把“可变的模型行为”包进“可管理的发布、监控和回滚流程”。
三、带数字的工程算例
某系统 70% 请求是简单改写，20% 是知识问答，10% 是合规高风险分析。若全部走强模型，成本高；若全部走小模型，高风险质量不足。可以让改写走小模型，问答走中模型+RAG，高风险走强模型并人工抽检。
这个算例的作用不是追求精确到小数，而是帮助你在面试中建立量级感。只要能估出 token、并发、延迟、成本或错误率的数量级，你的回答就会从概念题变成工程题。
路由得分 = w1*质量预估 - w2*成本 - w3*延迟 - w4*风险
fallback 触发 = 超时 || 限流 || 校验失败 || 质量分低于阈值
有效可用性 ≈ 主模型成功率 + 主失败率 * 备用模型成功率四、典型链路怎么跑
可以把这类问题拆成下面的链路来理解：
请求分类
|
估计复杂度和风险
|
选择主模型
|
执行并校验
| fail
选择备用模型或降级路径
|
记录路由结果用于评估链路图的价值在于暴露责任边界：哪一步做权限，哪一步算成本，哪一步可重试，哪一步必须审计。面试时能画出链路，通常就能自然回答故障排查和系统设计追问。
五、方案对比和选择标准
| 策略 | 优点 | 风险 |
|---|---|---|
| 固定规则 | 透明稳定 | 覆盖不了复杂语义 |
| 分类器路由 | 灵活 | 分类器自身会错 |
| 成本优先 | 省钱 | 质量可能下降 |
| 质量优先 | 稳定 | 成本和延迟高 |
选择方案时要先说评估维度，再说取舍。LLMOps 面试很看重这种思维，因为真实系统没有银弹，只有在质量、成本、延迟、安全和维护成本之间做平衡。
六、上线后最容易出问题的地方
- fallback 模型如果上下文窗口更短，直接重试可能截断关键输入。
- 不同模型输出风格不同，结构化 schema 和后处理必须保持统一。
- 只在少量 demo 上验证会低估风险，真实流量中的长尾输入、权限组合和外部依赖更复杂。
- 没有版本记录时，线上问题很难复现；prompt、模型、知识库、工具和配置都要纳入发布记录。
七、常见误区与追问
- 误区：fallback 就是失败后换个模型再试一次。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 误区：最强模型永远应该作为主模型。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 误区：路由只看成本就够了。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 追问：如何评估路由器是否选对模型？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问：备用模型输出不兼容怎么办？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问：降级答案如何避免误导用户？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
八、加强记忆
按“分类、路由、校验、fallback、降级、记录”六步记。多模型不是堆模型，而是把每类请求送到合适的能力和成本档位。
复习 LLMOps 题时，可以固定用“目标、链路、预算、风险、观测、回滚”六步组织答案。这样既能回答原理，也能自然延伸到生产系统设计。