11.4.2 模型、Prompt、索引升级时如何做回滚？

先给结论：回滚不是“出问题再想办法”，而是上线前必须具备的能力。模型、Prompt、索引这三类升级都需要版本化、可切换和可验证的回滚路径。

RAG 生产系统的升级通常分三类：

• 模型升级
• Prompt 升级
• 索引升级

这三类升级的共同点是：

• 一旦出问题，影响范围很大

所以回滚策略必须提前设计。

一、模型升级的回滚

模型升级的风险通常体现在：

• 回答风格变化
• 忠实性下降
• 成本和延迟变化

更稳的回滚方式包括：

• 保留旧模型版本
  确保可以快速切回

• 灰度发布
  先在小流量验证，再逐步放量

• 明确回滚阈值
  例如忠实性下降、满意度下降、成本激增

模型升级时，回滚必须是“秒级可切换”的能力，否则线上风险无法控制。

二、Prompt 升级的回滚

Prompt 升级看似轻量，但风险很常见：

• 回答结构变化
• 忠实性约束失效
• 生成内容偏离业务预期

更稳的回滚方式包括：

• Prompt 版本化
  每次改动有明确版本号

• 配置中心可切换
  避免重新发布应用才能回滚

• 小流量灰度
  验证后再放量

Prompt 回滚的关键是：

• 版本化 + 配置化

否则你无法快速切回上一版。

三、索引升级的回滚

索引升级的风险通常体现在：

• 召回质量波动
• 新旧版本混用
• 权限或时效问题

更稳的回滚方式包括：

• 双索引策略
  新索引构建完成后再切换

• 读写分离
  保证旧索引仍可回退

• 切换开关
  能够在不重建的情况下切回旧索引

索引升级的回滚通常是最重的一类，但也是最必须提前规划的一类。

四、回滚必须具备的三项基础能力

无论是哪一类升级，回滚都需要三项基础能力：

1. 版本化
   所有模型、Prompt、索引都必须有版本号

2. 可切换
   能够在运行时切回旧版本

3. 可验证
   回滚后能快速确认系统恢复正常

缺少任何一项，回滚都可能变成：

• 口号式回滚

五、一个最小回滚能力清单

rollback_capabilities = {
    "model": ["versioning", "config_switch", "canary_metrics"],
    "prompt": ["versioning", "runtime_switch", "rollout_guardrails"],
    "index": ["blue_green", "traffic_switch", "fast_fallback"]
}

这个示意强调的是：

• 不同升级类型的回滚能力各有侧重

六、最常见的回滚误区

误区一：回滚只在故障时才考虑

回滚必须在上线前设计好，否则等出问题再想办法就晚了。

误区二：没有版本化

没有版本化，你根本不知道回滚该回到哪一版。

误区三：回滚需要重新发布

如果回滚还需要重新发布应用，基本上就不算真正的回滚能力。

一句话总结

模型、Prompt、索引升级都必须具备版本化、可切换、可验证的回滚能力。没有回滚能力，生产升级就不可控。