概述
在前面的章节中，我们讨论了如何通过调用次数限制来防止成本失控。但实际生产环境中还会遇到另一个问题：主模型可能因为各种原因（限流、宕机、网络问题等）突然不可用了，这时候怎么办？
如果只是简单报错，用户体验会很差。更聪明的做法是自动切换到备用模型，确保服务不中断。这就是模型回退（Model Fallback）中间件要解决的问题。
它的核心思路很简单：为主模型配置一个或多个备用模型，当主模型调用失败时，自动按顺序尝试备用模型，直到成功或所有模型都失败。这样就能保证服务的高可用性，同时还能实现成本优化和跨供应商的冗余保护。
使用场景
高可用性保障
在生产环境中，服务中断是不可接受的。通过配置备用模型，即使主模型出现问题，服务也能自动切换到备用模型，保证业务连续性。
成本优化
主模型可能很贵（如GPT-4o），当主模型失败时，可以回退到更便宜的模型（如GPT-4o-mini）。在保证可用性的同时，还能控制成本。
跨供应商冗余
配置不同供应商的模型（如OpenAI → Anthropic → Google），避免单点故障。即使某个供应商的服务出现问题，也能自动切换到其他供应商。
核心功能需求
回退链设计
回退链就是备用模型的顺序列表。我们需要设计一个合理的回退链，平衡可用性、成本和性能。
回退顺序
- 第一个备用模型：通常是成本适中、性能较好的模型
- 后续备用模型：可以配置多个，按顺序依次尝试
- 建议：配置2-3个备用模型即可，链路过长会导致延迟累积
模型能力匹配
备用模型应该具备与主模型相近的能力，特别是：
- Tool Calling支持：如果主模型支持工具调用，备用模型也应该支持
- Structured Output支持：如果使用了结构化输出，备用模型也需要支持
- 上下文窗口：备用模型的上下文窗口应该足够大，避免因窗口限制导致失败
产品建议：在PRD中明确要求备用模型的能力要求，确保回退后功能不会降级。
触发条件
我们需要明确什么时候触发回退。通常包括：
API错误
- 4xx错误：客户端错误（如401认证失败、429限流）通常不应该触发回退，因为这些是配置问题
- 5xx错误：服务器错误（如503服务不可用、500内部错误）应该触发回退
网络问题
- 超时：请求超时应该触发回退
- 连接错误：网络连接失败应该触发回退
内容过滤
部分供应商可能会因为内容审核拒绝生成内容，这种情况也应该触发回退。
产品建议：在PRD中明确哪些错误应该触发回退，哪些不应该。比如429限流可能只需要等待重试，不需要立即回退。
PRD需求描述
功能需求
FR-1: 回退链配置
- 描述：支持为主模型配置一个或多个备用模型，形成回退链
- 配置方式：支持通过配置界面或配置文件设置回退链
- 模型格式：支持模型标识符字符串或模型实例对象
- 优先级：P0（核心功能）
FR-2: 自动回退触发
- 描述：当主模型调用失败时，自动触发回退流程
- 触发条件：API错误、网络超时、连接错误、内容过滤等
- 回退逻辑：按顺序尝试备用模型，直到成功或所有模型都失败
- 优先级：P0（核心功能）
FR-3: 跨供应商支持
- 描述：支持配置不同供应商的模型作为备用模型
- API Key管理：确保各供应商的API Key已正确配置
- 供应商切换：自动处理不同供应商的API差异
- 优先级：P0（核心功能）
FR-4: 回退状态记录
- 描述：记录每次回退事件的详细信息
- 记录内容：主模型失败原因、使用的备用模型、是否成功等
- 优先级：P1
非功能需求
NFR-1: 回退性能
- 延迟控制：回退过程不应显著增加响应时间，建议总延迟 < 5秒
- 快速切换：主模型失败后应快速切换到备用模型，减少用户等待时间
NFR-2: 成本监控
- 回退成本：监控备用模型的调用成本，评估回退对整体成本的影响
- 成本对比：对比主模型与备用模型的成本差异，优化回退链设计
NFR-3: 监控与告警
- 回退率监控：监控回退触发率，如果回退率过高（>10%），可能表明主模型配置有问题
- 回退成功率：监控回退后的成功率，评估回退策略的有效性
- 告警机制：当所有模型都失败时，触发告警通知
产品设计要点
回退链设计建议
成本优化场景：
- 主模型：GPT-4o（高成本，高质量）
- 备用模型1：GPT-4o-mini（低成本，中等质量）
- 这样在主模型失败时，可以降级到更便宜的模型
高可用场景：
- 主模型：OpenAI GPT-4o
- 备用模型1：Anthropic Claude 3.5 Sonnet
- 备用模型2：Google Gemini 2.0 Flash
- 跨供应商冗余，避免单点故障
产品建议：根据业务场景选择合适的回退链设计。如果是成本敏感场景，优先考虑成本优化；如果是高可用场景，优先考虑跨供应商冗余。
触发条件设计
应该触发回退的情况：
- 5xx服务器错误
- 请求超时
- 网络连接失败
- 内容过滤拒绝（部分供应商）
不应该触发回退的情况：
- 4xx客户端错误（如401认证失败、404资源不存在）
- 这些通常是配置问题，回退到备用模型也无法解决
产品建议：在PRD中明确区分不同类型的错误，只有临时性的、可以通过切换模型解决的问题才触发回退。
成本与质量平衡
成本考虑：
- 如果主模型是高成本模型，备用模型可以选择中等成本模型
- 回退虽然能保证可用性，但可能影响质量，需要权衡
质量保障：
- 备用模型应该具备与主模型相近的能力
- 如果回退导致质量明显下降，需要记录日志并考虑优化
产品建议：在PRD中明确成本和质量的要求，根据业务特点选择合适的回退策略。
使用建议
什么时候应该使用
- 高可用要求：服务中断不可接受的场景
- 成本优化需求：在主模型失败时，可以降级到更便宜的模型
- 跨供应商冗余：需要避免单点故障的场景
配置建议
- 回退链长度：建议配置2-3个备用模型，避免链路过长
- 模型能力匹配：确保备用模型具备主模型的关键能力
- API Key配置：确保各供应商的API Key都已正确配置
注意事项
- 回退不是万能的：只对临时性错误有效，配置错误、认证失败等问题无法通过回退解决
- 监控回退率：如果回退率过高，可能表明主模型配置有问题，需要优化
- 成本监控：定期查看回退成本，确保在预期范围内
与其他中间件的配合
模型回退可以与其他中间件配合使用：
- 与ModelRetryMiddleware配合：先重试主模型，失败后再回退到备用模型
- 与ModelCallLimitMiddleware配合：回退不会重置调用计数，备用模型的调用也会计入限制
- 与Human-in-the-loop配合：回退过程对用户透明，不需要人工干预
后续优化方向
- 智能回退：根据错误类型和业务场景，智能选择最合适的备用模型
- 回退预测：基于历史数据预测主模型可能失败的情况，提前准备
- 质量监控：监控回退后的响应质量，如果质量下降明显，及时告警
- 成本优化：根据回退率和成本数据，动态优化回退链配置