分类：大模型
当大模型接口不可用时，用户看到的往往是一个 502 页面。对 AI 应用来说，模型服务失败并不只是技术问题，也会直接打断产品体验。掘金技术文章《AI 应用生产化手册》第 13 篇提出了一种更偏工程化的处理方式：在回滚之外建立“降级链”，让系统在模型故障时先保持响应，再逐步恢复完整能力。
上线治理不能只靠灰度和回滚
文章将提示词版本、灰度、A/B、回滚降级视为上线治理的四个组件。灰度发布和 A/B 实验解决的是“如何谨慎上线”，但生产环境还需要回答另一个问题：出事后如何快速止血。作者认为，恢复能力应当与上线能力同等重要；缺少“1 分钟止血”手段的上线，接近裸奔上线。
这里的降级并不是主动降低产品质量，而是在故障期间维持最低限度的可用状态。与直接报错相比，系统可以先切换到备用模型；如果备用模型也不可用，再用规则兜底给出明确反馈。
三层降级链：主力模型、备用模型、规则兜底
素材中给出的链路分为三层。第一层是主力模型，例如 chat-strong，承担正常质量要求；第二层是备用模型，例如 chat-cheap，在主力失败后接管，功能仍可用，但质量可能略降，成本更低；第三层是规则兜底，例如 rule-fallback，用于在前两层都失败时避免用户面对 502。
- 主力模型：保完整质量，成本较高。
- 备用模型：保基本功能，质量略降，成本较低。
- 规则兜底：保“有响应”，无智能回复能力，需要向用户明示服务降级。
文章同时提出三条原则：备用模型必须定期验证，未经过验证的备用只是心理安慰；降级过程必须可观测，需要标记和日志；规则兜底是最后防线，不能成为常规路径。
用配置开关控制降级，而不是等发版
在实现上，降级链与功能开关绑定。例如，FEATURE_BACKUP_MODEL=1 用于开启备用模型降级，FEATURE_RULE_FALLBACK=1 用于开启规则兜底，CANARY_ROLLOUT=10 用于灰度放量。作者强调，开关应通过配置管理，修改开关不需要重新发版；每开启一个功能前，都要先想清楚如何关闭它，并且开关状态应可观测。
故障处理的顺序也被拆成三层：先自动重试，再根据配置降级，最后才考虑回滚。能用配置解决的问题，不依赖发版解决。
演示部分展示了真实演练：当网关不可用时，请求不再返回 502，而是返回固定话术，字段中带有 model: rule-fallback 和 degraded: true。如果关闭规则兜底，系统会恢复 502，使错误重新暴露出来。文章提醒，规则兜底是一把双刃剑：它能救用户体验，也可能掩盖故障，因此兜底话术需要与告警同时配置。
日志方面，素材给出了 llm_fallback、llm_rule_fallback、chat_response 等事件字段，并可通过 degraded 标记识别降级状态。对 llm_rule_fallback 计数，可用于发现“降级风暴”。
AI 应用生产化的关键：把故障处理变成工程流程
这篇内容属于该系列“模块三（上线治理）”的收尾部分。它将提示词版本、灰度、A/B、回滚降级合并为一套完整流程，核心目标不是消除故障，而是让故障发生时有明确路径。对 AI 应用而言，模型服务本身具有外部依赖，外部故障可能需要等待供应商恢复。如果只依赖回滚，恢复路径会过窄；把重试、降级、开关、告警纳入同一套机制，才能让系统在异常状态下仍有边界清晰的行为。
按照文章的说法，生产化的目标是把“变更”从带有一定偶然性的行为，变成有版本、有灰度、有实验、能止血的工程流程。该系列后续还将进入“Token 成本模型”模块，继续讨论调用成本如何计算。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/mo-xing-fu-wu-chu-gu-zhang-shi-bie-zhi-kao-hui-gun-jiang-ji
