模型版本管理：MD5 锁定与灰度发布

"客户说线上模型效果变差了"——排查的第一步永远是：现在线上跑的是哪个版本？如果这个问题答不出来，后面的排查全部无从下手。版本管理不是工程洁癖，是模型可运营的前提。

为什么版本化是刚需

模型交付涉及两个会变化的东西：数据（标注在增补、清洗在进行）与模型（在持续迭代训练）。没有版本化时，三件事必然发生：问题无法复现（不知道当时用的什么数据训的）；责任无法界定（改动前后边界模糊）；升级无法回退（只能向前硬修）。版本化把这三件事全部变成"查记录"。

MD5 锁定的作用

我们对两类东西做 MD5 锁定：数据集版本包与模型交付包。MD5 的价值有三层：完整性——传输或存储过程中任何损坏都会暴露；一致性——训练用的数据包与记录的 MD5 对上，实验才可复现；契约性——交付包的 MD5 写进合同与验收单，交付的"是什么"不再有争议。训练平台在打包与导出时自动计算并登记，不需要人工维护。

数据集版本 ↔ 模型版本

单独给模型编版本号是不够的，还要记录"它用什么数据训出来的"。我们要求每个模型版本登记对应的数据集版本：v2 模型 = 数据集 v3 + 新增 badcase 批次 + 训练参数 X。这条对应链让两件事变得简单：精度回归时可以对比"同一数据集上两代模型"的纯净差异；客户询问模型行为时，可以精确回答"它是见过哪类样本之后变这样"的。

灰度发布操作

1. 新版本交付包与 License 下发到测试点位（1~2 个门店/通道）；
2. 新旧版本并行或按日切换，跑一周对比：验证集指标 + 线上误报/漏报双口径；
3. 达标则分批推全（每批观察一天）；不达标则该批暂停，badcase 回流。

灰度的本质是"用最小代价获取真实环境的数据"。它要求交付体系支持点位级授权——这正是 License 体系设计时预留的能力。

回滚：留后路的能力

版本化的最后一块拼图是回滚：历史交付包与 License 记录保留，全量后发现异常，切回上一版是分钟级操作。建议的纪律是永远保留最近三个版本可随时启用；回滚不是失败，是把风险控制在业务可承受范围内的常规手段。有了版本、MD5、灰度与回滚四件事，模型交付从"凭勇气"变成"有流程"。

多客户场景的一致纪律

同时服务多个客户时，版本纪律要升级为跨客户的一致规范：每个客户的模型版本号独立编制、互不混用；数据集严格按租户隔离，A 客户的 badcase 不经脱敏同意不得用于 B 客户的模型；交付记录（版本、MD5、License、时间）按客户归档，随时可出对账清单。这套纪律在客户数少时显得繁琐，但它是把"项目式交付"升级为"规模化运营"的分水岭——平台化的价值恰恰在于让这些纪律由系统自动执行，而不是靠人记住。

延伸阅读：模型交付的三道关、License 授权体系详解。