基础概念：模型发布、灰度发布、回滚与版本管理
在智慧工厂的数字化进程中，AI模型（如质检模型、预测性维护模型、工艺参数优化模型）从实验室走向产线，并非简单的“文件拷贝”。模型发布、灰度发布、回滚与版本管理，构成了模型全生命周期管理的核心骨架。这四者既有明确分工，又紧密咬合：版本管理是底层的数据与制品基线，模型发布是面向生产环境的交付动作，灰度发布是降低发布风险的策略，回滚则是应对异常的兜底机制。理解它们的区别与联系，是构建可靠MES/AI平台的前提。
核心原理：四者的定义与边界
模型发布是指将经过验证的模型版本从开发/测试环境迁移至生产推理环境，并使其对外提供服务的动作。它关注的是“部署到哪、如何加载、如何切换流量”。灰度发布是发布的一种策略，指让新模型先承接一小部分真实生产流量，在监控指标稳定后逐步扩大流量比例，直至全量。其本质是“渐进式暴露风险”。回滚是在新版本出现严重缺陷或指标劣化时，将流量快速切回至上一个已知良好版本的动作，目标是“最小化故障恢复时间”。版本管理则是对模型制品及其元数据（训练数据版本、代码版本、超参数、评估报告）进行唯一标识、存储、追溯和比较的机制，它是前三者的基础——没有版本管理，发布和回滚就无从谈起。
四者的关系可以概括为：版本管理是“仓库”，模型发布是“出库”，灰度发布是“分批出库”，回滚是“紧急退货换货”。在智慧工厂中，一个典型的场景是：质检模型v2.3版本经过版本库登记后，先部署到1号产线的光学检测工位（灰度），运行4小时后对比误判率，若指标达标则推广至全部6条产线；若发现某类缺陷漏检率上升，则立即将流量切回v2.2版本，同时保留v2.3的日志用于离线分析。
判断方法与操作流程：何时用何种策略
在智慧工厂的实践中，选择发布策略需要根据模型影响范围、失败代价和可观测性来决定。以下为判断路径与操作流程：
- 评估影响面：该模型是影响单台设备、单条产线，还是全工厂调度？影响面越大，越需要灰度。
- 评估失败代价：若模型出错，是导致产品返工（低代价）、设备停机（中代价）还是安全事故（高代价）？代价越高，灰度比例初始值应越低。
- 确定灰度策略：常见策略包括“按产线灰度”（先1条线，再全部）、“按流量百分比灰度”（5%→20%→100%）、“按时间窗口灰度”（白天低峰期先试）。
- 设定回滚条件：明确哪些指标（如准确率、误检率、平均推理延迟）达到什么阈值时触发自动回滚。
- 执行发布与监控：使用发布平台执行操作，并实时监控业务指标与技术指标。
案例拆解：汽车零部件工厂的质检模型灰度发布
背景与约束：某汽车零部件工厂有4条差速器壳体生产线，每条线配备2台AI视觉质检设备。原质检模型v1.8误检率偏高（过杀率3.2%），导致大量合格品被人工复检，浪费人力。工厂计划升级至v2.0模型，该模型在实验室数据集上过杀率降至1.1%，但工厂要求任何产线变更不得导致漏检率超过0.05%，且单次发布不可影响超过50%的产能。
初始现象与目标：v1.8模型在1号线和2号线的过杀率分别为3.5%和2.9%，目标是将全厂过杀率降至1.5%以下，同时保持漏检率不上升。
关键输入数据：v2.0模型在验证集上的准确率99.2%，过杀率1.1%，漏检率0.03%；v1.8模型对应指标为准确率97.8%，过杀率3.2%，漏检率0.04%。
分析判断过程：由于漏检率指标接近，且v2.0在过杀率上优势明显，决定采用灰度发布。但考虑到1号线和2号线的来料批次差异较大，不能简单按流量百分比，而应按产线灰度。
实际操作步骤：
- 在版本管理系统中锁定v2.0制品，并关联训练数据集版本、模型结构文件、推理引擎版本。
- 先在1号线A设备部署v2.0，配置为“影子模式”（旁路推理，不实际控制分拣），运行2小时对比输出与v1.8的差异。
- 影子模式确认无异常后，将1号线A设备切换为v2.0实际控制，B设备仍运行v1.8，形成同线对比。
- 监控4小时后，1号线A设备过杀率降至1.2%，漏检率0.03%，达标。随后将1号线B设备也切换至v2.0。
- 1号线稳定运行24小时后，将2号线两台设备同时切换至v2.0。
- 3号线和4号线在下一周内分批切换，期间每日对比各线质量报表。
结果对比：全量切换后，全厂过杀率降至1.3%，漏检率0.03%，未发生批量质量事故。人工复检工作量减少约60%。
风险与代价：灰度期间，1号线A设备和B设备使用了不同模型，导致同一产线出现短暂的质量判定标准不一致，需人工复核差异件。另外，影子模式需要额外的GPU资源，增加了约15%的推理成本。
复盘经验：按产线灰度比按流量百分比更适合离散制造场景，因为同一产线的来料批次相对一致，对比更科学。同时，必须提前准备“模型判定差异报告”，让质检员理解新旧模型的合理差异，避免误判为故障。
常见误区与总结复盘
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 将“发布”等同于“全量替换” | 一旦新模型有问题，产线直接瘫痪 | 默认采用灰度发布，除非影响面极小且可快速回退 |
| 回滚只回滚模型文件，不回滚配置 | 模型与预处理参数不匹配，推理结果异常 | 回滚时同时恢复模型、配置文件、依赖库版本 |
| 版本管理只记录模型文件，不记录数据 | 无法复现训练过程，问题排查困难 | 使用DVC或MLflow记录数据快照、代码版本、超参数 |
| 灰度期间不监控业务指标 | 只看了推理延迟，没发现误检率上升 | 同时监控技术指标（延迟、吞吐）和业务指标（误检率、过杀率） |
总结复盘：模型发布不是“一锤子买卖”，而是一个可逆、可观测、可追溯的工程过程。版本管理是地基，灰度发布是护栏，回滚是安全气囊。在智慧工厂中，由于产线连续运转、停机成本高昂，任何模型变更都应视为“高风险手术”。建议团队建立以下规范：所有模型必须经过版本登记才能发布；所有生产环境的发布操作必须通过自动化平台执行，禁止手工拷贝模型文件；每次灰度发布前，必须演练一次回滚流程，确保回滚脚本可用。