降级设计与数据飞轮

降级是正常运行的一部分

在传统软件中，降级通常意味着系统出了问题——数据库连接池耗尽、第三方服务不可用、内存不足。降级是异常状态下的应急措施。

在 LLM 应用中，降级是正常运行的一部分。LLM 调用可能因为速率限制、超时、格式错误或语义偏离而需要降级处理。在概率性系统中，这些都是常态。把降级当作系统的正式功能来设计，而不是事后打补丁——这是 LLM 应用可靠性设计的一个重要思路。

降级层级

降级不是全有全无的，中间有多个档位。设计多个降级层级，让系统在不同程度的故障下多少还能提供点服务。

层级	策略	质量	成本	适用场景
完整功能	最强模型、完整上下文、复杂推理链	最高	最高	正常运行
简化推理	更小的模型、更短的上下文、更简单的 prompt	中等	较低	延迟敏感或成本受限
缓存	返回之前计算过的结果，零 LLM 调用	可能过时	零	常见请求、输出无需实时更新
规则	预定义的规则和模板，完全不使用 LLM	僵硬但可靠	零	模板能覆盖的场景
兜底	通用的"无法处理"响应，引导用户联系人工	最低	零	所有方案都失败

降级的执行逻辑是从最高层级开始尝试，失败则逐级回退。每一层返回的响应都应携带当前的服务级别标识（用户需要知道当前的服务级别）。

降级触发条件

何时从高层降级到低层？触发条件应该是明确的、可量化的。

延迟触发。 LLM 调用超过 N 秒未返回，切换到更快的方案。对面向用户的应用，3-5 秒是通常的耐受上限。

成本触发。 单次请求的 token 消耗超过预算，切换到更经济的方案。防止复杂请求（超长上下文、多轮推理）导致成本失控。

质量触发。 LLM 输出未通过验证（结构验证失败、置信度过低），尝试降级到更可靠的方案。

熔断触发。 一段时间内失败率超过阈值，暂时跳过 LLM 调用，直接使用降级方案。与传统的熔断器模式相同——给过载的 LLM 服务"喘息"的时间。

透明度

降级最重要的设计原则是透明度。用户应该知道他们收到的是完整服务还是降级服务。

不透明的降级是一种欺骗——用户以为得到了 AI 分析的结果，实际上得到的是基于规则的模板回复。这种欺骗短期看用户感受不到差异，长期会损害用户信任。

透明的方式可以很简洁：在响应中附加服务级别标识，在 UI 中用不同的视觉提示区分完整服务和降级服务，在 API 响应的元数据中标注降级信息。

降级与重试的选择

降级和重试解决不同的问题。重试假设"再试一次可能成功"——适合瞬时故障（网络抖动、速率限制的短暂触发）。降级假设"当前条件下无法获得高质量结果"——适合持续性问题（模型对该类输入表现不佳、上下文超出处理能力）。

判断标准：如果失败原因是随机的（网络问题、API 偶尔超时），重试；如果失败原因是系统性的（输入类型超出模型能力、prompt 设计缺陷），降级。重试解决偶然问题，降级解决结构性问题。

两者可以组合：先重试 1-2 次，如果仍然失败，再降级。但不要无限重试后才降级——用户不会等待。设定明确的重试预算（时间或次数），预算耗尽立即降级。

数据飞轮：从降级数据到质量改进

降级不仅是防线，也是数据来源。系统运行中产生的所有数据——正常输出、降级事件、用户反馈——只要收集和利用得当，就能形成正反馈闭环：系统的输出数据经过收集、评估和筛选，变成改进系统的输入。用得越多，数据越多，系统就越好。

这个闭环能不能真正转起来，取决于每个环节之间的信息传递是否顺畅——垃圾数据进去，出来的也是垃圾。

反馈信号的质量层级。 并非所有用户行为都构成等价的反馈信号。最粗糙的是隐式信号——完成率、复制率、会话放弃率。这些数据不花钱就能拿到，但噪声极大，只有攒够量才有统计意义。往上一层是显式反馈，比如评分、点踩、重新生成。信噪比好得多，但用户往往不满意时才会反馈，所以数据偏负面。信息密度最高的是结构化标注——按质量维度打分，但标注成本也最高。实践中的策略是分层用：隐式信号做粗筛，显式反馈做确认，结构化标注做诊断。

冷启动。 正反馈闭环存在启动阈值——初期没有用户数据，无法评估质量，无法识别改进方向。三种破解策略：合成数据引导（用模型自身或更强的模型生成测试数据，积累真实数据后逐步退出）；小规模高质量标注（50 条精确标注的诊断价值可能超过 5000 条隐式信号）；内部狗粮测试（团队成员同时承担使用者和评估者的双重角色）。

加速与停滞的判据。 闭环并非启动后就必然加速。加速的信号：质量指标随数据量增长而持续改善，新增数据中高质量样本的比例在上升。停滞的信号：质量指标不再随数据量增长而改善——可能是反馈信号的信息量已被充分利用，也可能是改进策略遇到了瓶颈（prompt 优化已收敛，需要升级到微调或架构调整）。倒转的信号：质量指标恶化，最常见的原因是反馈数据的分布偏移——早期用户与后期用户的使用模式不同。

闭环模式天然偏向"讨好多数"——改进方向由数据中的多数模式驱动，少数但可能同样重要的使用场景容易被忽略。