3. 审计场景
模型参数代码与版本一致性审计并非抽象概念，它贯穿模型从训练到退役的完整生命周期。不同阶段对“一致性”的敏感点不同，一旦失配，其表现和影响也各有特征。本节将训练、部署、迁移、复现、合规检查五类场景逐一拆解，帮助学员建立“场景—表现—影响”的对应认知。
一、核心原理：一致性为何在五个场景中表现不同
一致性的本质是同一模型在代码、参数、配置、环境四个维度上的可追溯与可还原。训练阶段关注的是“参数是否由当前代码产生”；部署阶段关注的是“线上加载的参数是否与训练产物一致”；迁移阶段关注的是“跨环境后参数语义是否漂移”；复现阶段关注的是“他人能否用相同输入得到相同输出”；合规检查则关注“全链路是否有可审计的证据链”。
这五个场景共享同一套底层对象：权重文件、超参数配置、预处理代码、依赖版本、随机种子、数据版本。但每个场景的“失配触发点”不同，因此审计的切入点和证据类型也不同。
二、方法流程：五场景审计的差异化检查清单
审计不是一套固定动作，而是根据场景选择检查项。下表给出五类场景的核心检查点与证据要求，可作为审计执行时的对照清单。
| 场景 | 核心检查点 | 关键证据 | 典型失配影响 |
|---|---|---|---|
| 训练 | 代码提交哈希与权重文件是否同源；超参数是否记录 | 训练日志、git commit、config.yaml | 指标虚高，模型实际能力与报告不符 |
| 部署 | 线上权重哈希与训练产物是否一致；预处理代码是否同步 | 模型注册表、镜像标签、加载日志 | 预测分布偏移，线上效果骤降 |
| 迁移 | 依赖库版本、CUDA/驱动、算子实现是否一致 | requirements.txt、环境快照、算子对比 | 数值精度变化，推理结果不可比 |
| 复现 | 随机种子、数据版本、框架版本是否固定 | seed记录、数据快照、复现报告 | 结果不可重复，实验结论不可信 |
| 合规 | 参数变更是否有审批；全链路是否可追溯 | 审批记录、哈希链、审计日志 | 无法举证，面临监管风险 |
三、案例/场景：一次迁移引发的线上事故
某团队将训练好的推荐模型从PyTorch 1.12迁移到2.0环境部署。迁移后离线指标正常，但线上CTR下降约8%。审计发现：模型权重文件未变，但torch.nn.functional.interpolate在2.0中默认对齐方式有细微变化，导致特征图数值偏移。更关键的是，预处理代码中使用了numpy的随机采样，而迁移后numpy版本从1.23升到1.26，随机流实现不同，导致线上特征分布与训练时不一致。
# 审计时对比环境差异的关键命令
pip freeze > env_prod.txt
diff env_train.txt env_prod.txt
# 输出片段
- numpy==1.23.5
+ numpy==1.26.0
- torch==1.12.1
+ torch==2.0.0
# 权重哈希对比
sha256sum model_v3.pt
# 训练侧: a1b2c3...
# 部署侧: a1b2c3... （权重一致，问题在环境）该案例说明：权重一致不等于行为一致。迁移场景的审计必须把依赖版本、算子实现、随机流纳入检查范围，否则“参数没变”会成为掩盖问题的假象。
警示：迁移后仅验证权重哈希是不够的。建议同时固定随机种子、记录依赖版本，并在迁移前后用同一批输入做数值对比，偏差超过阈值即触发告警。
四、误区/复盘：常见审计盲区与改进建议
- 误区一：只审计权重文件。权重只是参数快照，代码、配置、环境同样决定模型行为。应建立“权重+代码+配置+环境”四元组审计基线。
- 误区二：复现失败归因于随机性。多数复现失败源于未固定种子、数据顺序变化或依赖版本漂移。应把随机种子和数据版本写入实验记录。
- 误区三：合规检查留到上线前。合规证据需要在训练、部署各环节持续采集，事后补录往往缺失关键哈希和审批链。
- 误区四：部署后不再审计。线上模型可能被热更新、回滚或替换，需定期比对线上权重哈希与注册表记录。
复盘建议：将五类场景的检查点固化为CI/CD流水线中的自动门禁。例如，训练完成后自动计算权重哈希并写入模型卡；部署前自动比对哈希与配置；迁移时自动生成环境差异报告。审计从“人工抽查”转为“自动拦截”，才能规模化落地。
综上，训练、部署、迁移、复现、合规检查五类场景的一致性审计，核心在于识别各自的失配触发点，并匹配相应的证据类型。只有把审计动作嵌入日常工程流程，才能在问题发生前发现不一致，而不是在事故后追溯原因。