11.2.4 如何设计检索、重排、生成链路的降级策略？

先给结论：生产级 RAG 必须有可执行的降级链路。降级的核心不是“直接关掉生成”，而是按顺序减少成本和风险，同时尽量保留可用信息。

很多系统的降级策略只有一条：

• 出问题就关掉生成

这在紧急情况下可以救场，但更稳的策略应该是：

• 分层降级
  让系统逐步退化，而不是一次崩塌

一、降级策略的目标是什么

真正好的降级策略要同时满足三件事：

• 让系统还能回答或提供证据
• 避免错误扩大
• 把成本和延迟控制住

所以降级不是简单“变差”，而是：

• 有序退化

二、一个常见的降级顺序

下面是一个更实用的降级顺序示例：

1. 降低 TopK，减少候选池成本
2. 跳过 Rerank，直接使用初排结果
3. 收紧上下文长度，减少生成成本
4. 切换到更轻量模型
5. 只返回检索结果，不做生成

这个顺序的逻辑是：

• 先减少成本
• 再减少复杂度
• 最后才退回检索直出

三、不同链路的常见降级动作

检索链路的降级

• 降低 TopK
• 简化过滤条件
• 切换到更轻量的索引或检索路径

重排链路的降级

• 直接跳过 Rerank
• 只重排少量候选
• 使用更轻量的重排模型

生成链路的降级

• 缩短上下文长度
• 切换到轻量模型
• 返回证据片段而非完整回答

四、什么时候应该触发降级

触发降级通常不是靠主观感觉，而是通过指标阈值触发，例如：

• 延迟超过阈值
• 错误率上升
• 下游模型调用失败
• 并发队列积压

这意味着降级策略需要与：

• 监控指标
• 实时告警

绑定在一起，否则就只是“纸上降级”。

五、降级策略必须是可回退的

降级不是永久状态，而是：

• 暂时降低服务质量

所以你需要确保：

• 指标恢复后可以快速升回正常模式
• 不会因为降级导致系统长期停留在低质量状态

六、一个最小降级策略示意

def degrade(level):
    if level == 1:
        return "reduce_topk"
    if level == 2:
        return "skip_rerank"
    if level == 3:
        return "shorten_context"
    if level == 4:
        return "switch_to_light_model"
    if level == 5:
        return "retrieval_only"

这个示意的重点是：

• 降级有顺序
• 每一步都有清晰动作

七、最常见的降级误区

误区一：降级只靠人工触发

高并发下问题往往发生得很快，如果完全靠人工处理，很容易来不及。

误区二：只设计“最低级”降级

如果降级只有“开”和“关”，就很难在保证可用的同时控制风险。

误区三：降级后没有回升机制

降级如果无法自动回升，就会变成：

• 长期低质量服务

一句话总结

检索、重排、生成链路的降级策略必须分层、有序、可回退。先降成本与复杂度，再降功能；这样系统才能在高并发或故障时仍然可用。