选择一个主要的语言大模型可能只需要一个下午。而处理它失效时的情况，才是真正的工程挑战。
大多数团队都在为“理想路径”（happy path）进行优化。他们在干净的数据集上进行准确性基准测试，针对理想输入优化提示词，并充满信心地进行部署。随后，生产环境的流量涌入。模型在高峰时段开始超时，在周五晚上返回格式错误的 JSON，或者在价格更新后成本突然增加三倍。你精心设计的 AI 功能变成了一个负担，因为没有人预料到模型会崩溃。
在任何严肃的多模型应用中，回退规则（fallback rules）都不是事后才考虑的事情。它们是核心基础设施。当主模型遇到困难时，系统的表现决定了用户是留下还是离开。
从清晰的失败信号开始
如果你不知道自己究竟在对什么做出反应，就无法构建回退策略。首先，对每一次向外的模型调用进行监测，并将失败分类为具体的、可操作的信号。
留意供应商端点挂起时的 API 超时。留意速率限制错误——通常是 HTTP 429——这通常发生在流量激增或达到每月配额时。留意会导致解析流水线崩溃的无效 JSON 输出。留意那些在 HTTP 层看起来成功但实际上不包含任何可用内容的空响应或不完整响应。留意在任何硬性超时触发前就会降低聊天体验的高延迟。留意当用户输入超过模型窗口时的上下文长度溢出。还要留意质量退化，这是最微妙的一种失败：模型有响应，但其答案开始偏移、变得模糊，或者在供应商端更新后忽略了格式指令。
每种信号都应触发不同的响应。超时应当触发重试。JSON 格式错误应当切换模型。速率限制可能意味着你需要完全转向另一个供应商。
使回退机制匹配工作流
对所有任务使用相同的回退规则是灾难性的。聊天机器人和后台数据提取任务的需求截然不同。应围绕特定的工作流来设计你的回退机制。
聊天机器人需要速度和对话的连贯性。用户会原谅稍微平庸的回答，但不会原谅长达五秒的停顿。如果你的主模型变慢，请回退到快速的备份模型——通常是同一模型家族中的较小变体，或者是另一家供应商的速度级产品。保持对话的流畅。
RAG 系统需要准确性。你已经支付了检索的成本——向量搜索、重排序（reranking），可能还有网页爬取。如果生成器无法遵循提供的上下文，所有的工作都白费了。回退到以精确遵循指令和长上下文理解著称的模型，即使它速度较慢。
编程工具需要逻辑。开发者更看重正确的语法和有效的 API 调用，而不是华丽的解释。如果主模型开始产生函数幻觉或跳过边缘情况，请切换到在代码上进行过微调的模型。接受更高的延迟，以换取可编译的输出。
JSON 提取需要结构化。结构化生成非常脆弱。一个缺失的括号或未正确转义的引号都会导致下游数据库写入失败。如果你的主模型在遵循 Schema 方面出现偏差，请重试一次，然后切换到格式可靠性高的模型。奇怪的是，在这一特定任务上，经过服从性微调的小模型表现往往优于那些“创意巨头”。
自动化和批处理任务需要成本控制。后台分类器、日志摘要器和通知生成器是持续运行的。主模型价格的飙升可能将原本可控的每日账单变成一场预算危机。为这些非关键路径保留一个更便宜、更稳定的模型作为备选。如果输出质量略有下降，对业务的影响通常很小。
在切换之前了解你的约束条件
盲目更换模型会产生新问题。如果你从一个强大的模型降级到一个较弱的模型，备份模型可能会误解细微的提示词，并产生连锁反应导致下游错误的垃圾内容。如果你升级到更大的模型，你可能会解决质量问题，但会在几小时内耗尽预算。
在将任何模型提升为回退状态之前，请根据六个因素对其进行审计。
- 模型能力：它是否能真正处理该提示词类型，还是会以不同的方式失败？
- 语言支持：你的备选模型可能精通英语，但在印地语、西班牙语或日语中会出现幻觉。
- 上下文窗口大小：如果你的输入是 50,000 个 token，而备选模型的限制是 16,000 个 token，它会进行截断并悄无声息地破坏语义。
- 延迟：对于你所在的地区，某些供应商始终比其他供应商更快。
- 单次请求成本：设置一个硬上限。了解在高峰时段使用备选模型的成本。
- 输出可靠性：它是否每次都能遵循输出格式，还是只在周二才行？
四种行之有效的备选模式
并非所有的失败都需要同样的补救措施。构建一个备选类型工具包，并有目的地应用它们。
重试备选 (Retry fallback)。 对于瞬时网络错误和短暂的供应商停机，使用指数退避算法重试同一个模型。不要针对格式错误的输出或上下文溢出进行重试——发送两次相同的错误提示词几乎没有帮助。
等效备选 (Equivalent fallback)。 当你的主供应商宕机或受到限流时，切换到来自不同供应商的类似模型。从一个前沿模型切换到另一个大致同级别的模型，通常只需要极少的提示词重写，并能保持输出质量。
廉价备选 (Cheaper fallback)。 为非关键任务保留低成本模型。如果廉价选项表现不佳，请优雅地降级功能，而不是在低价值工作上浪费昂贵的 token。
更强备选 (Stronger fallback)。 这听起来有些反直觉，但至关重要。当中阶模型在处理复杂推理、多步数学或微妙的法律分析时持续表现不佳，请升级到能力更强的模型。仅在准确性关乎收入或安全的价值较高的用户路径中谨慎使用此策略。
将逻辑嵌入你的架构中
不要将备选逻辑散落在应用程序代码中数十个 try-catch 块里。将路由视为基础设施。构建一个中间件层，将任务类型映射到有序的模型列表，每个模型都有自己的超时阈值、重试策略和熔断器。
将备选事件作为一级指标进行跟踪。错误率告诉你模型何时宕机；备选率告诉你模型何时不适合这项工作。如果你的系统有 30% 或 40% 的时间在进行备选，说明你的主模型与工作负载不匹配。这是一个重新评估模型选择的信号，而不仅仅是重新评估错误处理。
设置明确的预算。备选方案绝不应是一张空白支票。如果在负载下升级到高级模型，请限制每分钟升级请求的数量。像保护系统可用性一样严谨地保护你的钱包。
真正的考验
你不是在为演示而构建。你是在为周二下午 3 点的情况而构建——那时 API 响应缓慢，用户正在等待，而财务团队刚刚询问为什么 AI 账单翻了一倍。成熟的备选策略能让产品保持稳定，保持用户体验的一致性，并让你的成本可预测。
仔细选择你的主模型。但要花两倍的时间去设计当它让你失望时该怎么办。
来源： How to Design AI Model Fallback Rules for Multi-Model Apps