大模型服务如何设计降级和 fallback？

简化版

Fallback 不是“主模型报错就换另一个模型再试”，而是按故障类型、剩余 Deadline、业务风险和能力兼容性选择可接受的替代路径。目标是在局部故障或过载时保住核心任务，同时避免重试风暴和静默质量下降。

先分类：超时/限流可切同能力副本或供应商；上下文过长可压缩或转长上下文模型；结构化解析失败可做有限修复；检索无证据应保守拒答；高风险工具动作不能降级到无安全保障模型。每层都要有总调用、Token、时间和成本预算。

详细版

设计一张能力矩阵，标明候选模型的上下文、工具调用、结构化输出、安全认证、地域和成本。运行时根据错误码和任务属性选择路径，而不是捕获所有异常后盲目串行尝试。

request -> primary
   | success -> validate -> return
   | transient failure -> bounded retry / equivalent replica
   | overload -> smaller model or async queue
   | unsupported -> compatible specialist
   | unsafe/no evidence -> refuse or human

Fallback 必须共享总 Deadline，并使用熔断、指数退避、抖动和并发隔离。观测要记录路由原因、路径、额外调用、最终质量和成本；用户得到降级结果时按产品约定显式标识。

完整版教学

1. 先区分错误与能力不足

网络抖动、429、实例故障属于暂时不可用；上下文超限、缺少工具能力属于能力不匹配；无证据或政策禁止属于不应回答。

三类情况处理不同。把无证据当暂时故障换十个模型，只会得到十次幻觉机会。

2. Fallback 的正确目标

目标是“在约束内交付仍符合最低标准的结果”，不是把成功状态码做高。最低标准包括事实、格式、安全、时延和副作用边界。

对推荐文案可接受小模型降级，对资金操作或医疗建议则可能只能转人工或失败关闭。

3. 建立能力兼容矩阵

能力	主模型	小模型	备用供应商	规则系统
32K 上下文	是	否	是	否
工具调用	是	部分	是	固定动作
JSON Schema	是	是	需适配	是
特定地域	是	是	否	是
高风险认证	是	否	视合同	是

路由前硬过滤不兼容候选，不能把“接口相同”误当成语义能力相同。

4. 错误分类如何驱动策略

429/503 可进入等价副本或短退避；身份与参数 4xx 不应重试；上下文超限需缩短输入或换模型；安全拒答通常不应通过换模型绕过。

错误分类保留供应商原始码并映射为内部稳定枚举，避免上游文案变化破坏策略。

5. 重试预算为什么必须全局共享

若网关、应用 SDK 和模型客户端各自重试 3 次，最坏调用可能呈乘法增长。应由一个层负责策略，并共享总尝试次数、Token、费用和 Deadline。

remaining_time = request_deadline - now
retry only if estimated_next_attempt < remaining_time

超过预算立即返回可控失败，避免用户超时后后台仍持续花费。

6. 熔断器如何防级联故障

某模型连续超时或 5xx 超阈值时打开熔断，暂时不再发送新请求；经过冷却后放少量探测流量，成功再恢复。

熔断按区域、模型版本和错误类型细分。全局一个开关可能因单区故障屏蔽所有健康容量。

7. Hedging 何时可用

对严格尾延迟且请求幂等的读取类任务，可在主请求超过分位阈值后并发发送备用，并取消较慢者。它降低 P99，但增加成本和峰值负载。

工具写操作、付费动作和非幂等调用不能随意 Hedging。过载时也应关闭，否则会放大故障。

8. 小模型降级怎样守质量

只把经评测证明小模型可完成的任务路由给它，如分类、固定抽取或简单 FAQ。高复杂度、低置信和高风险输入继续使用强模型或转人工。

小模型输出仍要经过 Schema、事实和安全校验。降级阈值由离线评测与线上 A/B 校准，不靠直觉。

9. 上下文降级怎么做

输入超限时先去除重复文档、压缩历史、降低 RAG TopK，再考虑摘要。所有变换应保留系统规则和权限上下文。

若关键证据仍无法容纳，应切长上下文模型或返回“无法在当前限制下处理”，而不是静默截断头部或尾部。

10. 检索和工具失败如何降级

检索不可用时，事实型问题可明确说明暂时无法访问资料，不能让模型假装有证据。工具只读失败可重试或换等价服务；写操作则需幂等键和状态查询。

执行结果未知时不能自动重复扣款、发信或删除。应进入人工/补偿流程，保证副作用可审计。

11. 输出验证失败怎么处理

JSON 解析失败可在剩余预算内进行一次受约束修复，或使用同一内容做确定性解析；事实或安全失败不能只改格式后放行。

验证器也可能故障，应区分“模型不合格”和“校验服务不可用”。高风险场景通常失败关闭。

12. 用户是否需要知道降级

若降级影响能力、时效或证据，应该显式说明；后台切到等价副本且契约不变，可以透明。不要把缓存旧答案或弱模型结果伪装成完整实时结果。

API 响应可返回模型能力等级、数据时间和降级原因码，但避免暴露内部敏感拓扑。

13. 如何测试与发布

故障注入覆盖超时、429、单区不可用、上下文超限、检索失败、解析错误和备用也失败。验证总调用次数、Deadline、取消传播和副作用幂等。

线上监控 Fallback 率、原因、路径成功率、额外成本、质量差异和熔断状态。某路径使用率突增通常是主链路退化信号。

好的 Fallback 在故障时缩小承诺，并且明确知道哪些能力绝不能降级。

14. 常见误区与追问

误区：任何异常都换模型重试。 参数、安全和无证据问题不会因此消失。
误区：备用模型接口兼容就能力兼容。 上下文、工具、安全和格式能力可能不同。
误区：多层各自重试更可靠。 会形成重试放大和成本失控。
误区：Fallback 结果无需告诉用户。 能力或数据时效改变时应透明。
误区：高风险操作也可并发 Hedging。 非幂等副作用可能被执行两次。
追问：何时失败关闭？ 安全校验、权限或副作用状态不确定时。
追问：如何避免备用被主站流量压垮？ 预留容量、熔断、限速和定期演练。

15. 加强记忆

先分类：暂时故障、能力不匹配、不应回答。
再列矩阵：上下文、工具、格式、安全、地域。
再守预算：次数、Token、成本和总 Deadline。
再控扩散：熔断、退避、抖动与取消。
再分风险：读取可灵活，写操作必须幂等。
再做透明：能力下降时告知用户。
最后验收：故障注入看质量、尾延迟、成本和副作用。

简化版

详细版