模型回滚流程：版本能切回去，数据也要对得上
一、模型回滚不只是把镜像换回旧版本
模型上线后发现效果退化，常见反应是回滚镜像。但 AI 服务的版本不只在镜像里。模型权重、tokenizer、prompt 模板、后处理逻辑、向量索引和评测阈值都可能参与结果。只回滚容器镜像，未必能恢复到旧行为。
因此模型回滚需要一套版本清单。每次发布要记录运行镜像、模型文件摘要、配置版本、依赖数据版本和流量策略。回滚时按清单恢复，而不是靠人临时回忆。
二、把模型发布对象做成不可变快照
平台可以把一次模型发布抽象为 Release。Release 包含所有影响结果的组件引用。线上服务只引用 Release ID，回滚就是把流量切回旧 Release。
flowchart TD A[模型权重] --> E[Release 快照] B[Tokenizer] --> E C[Prompt 模板] --> E D[后处理配置] --> E E --> F[灰度流量] F --> G{指标异常} G -->|是| H[切回旧 Release] G -->|否| I[扩大流量]Release 一旦发布就不应被修改。需要修复时创建新 Release。这样审计和回滚才不会混乱。
三、控制面要拒绝不完整的发布
下面示例展示一个发布校验函数。它要求关键组件都有摘要，避免“引用了一个路径但不知道内容是什么”。
type ModelRelease struct { ID string ImageDigest string ModelDigest string PromptVersion string ConfigChecksum string } func ValidateRelease(r ModelRelease) error { if r.ID == "" || r.ImageDigest == "" || r.ModelDigest == "" { return fmt.Errorf("release missing immutable identity") } if !strings.HasPrefix(r.ImageDigest, "sha256:") { return fmt.Errorf("image digest must be immutable") } if r.PromptVersion == "" || r.ConfigChecksum == "" { return fmt.Errorf("release missing prompt or config version") } return nil }这里强制使用 digest，而不是 tag。镜像 tag 可以移动，digest 才能保证回滚时拿到同一份产物。
四、回滚前后都要保留对比窗口
回滚不是结束，还要确认指标是否恢复。平台需要在回滚前后保留同一组指标：错误率、延迟、输出拒答率、业务转化、用户反馈和成本。只看服务是否 200，无法证明模型行为恢复。
还要处理数据兼容。新模型可能写入了新的缓存、向量或日志结构。回滚旧版本后，如果旧代码不认识这些数据，会出现二次事故。发布前就要定义向后兼容策略，尤其是共享存储和缓存 key。
灰度也要可撤销。流量切换最好走统一控制面，不要手改多个 Ingress 或服务配置。手工回滚越多，事故中越容易漏一处。
五、总结
模型回滚流程要围绕不可变 Release 设计。一次发布应记录镜像、模型、prompt、配置和依赖数据的版本摘要，回滚时切换 Release，而不是只换镜像。回滚前后要对比行为指标，并提前处理数据兼容。AI 平台的可靠性，体现在出问题时能准确退回去。
