2. 基础概念

在模型研发与交付过程中，“模型”从来不是单一文件，而是一组相互依赖的资产集合：权重、配置、代码、数据、运行环境。任何一项发生漂移，都可能导致推理结果变化、指标不可复现，甚至线上事故。本节先建立六个基础术语的清晰边界，再给出一致性审计的基本框架。

一、核心术语的边界与关系

模型参数指模型在训练过程中通过优化算法自动学习得到的数值，例如神经网络中的权重矩阵与偏置项。它们通常以张量形式保存在权重文件中，是模型“知识”的载体。参数数量、数值精度（FP32、FP16、INT8）和存储格式（如 safetensors、ckpt）都会影响加载与推理结果。

超参数是训练前由人工设定、不通过梯度更新学习的配置项，例如学习率、批大小、训练轮数、优化器类型、正则化系数、网络层数与隐藏维度。超参数决定训练过程与模型结构，但不会在训练中被自动修改。它与模型参数的关键区别在于：参数是“学出来的”，超参数是“定下来的”。

代码版本指训练、推理、评估、预处理等环节所依赖的源代码在某一时刻的快照。常用 Git 提交哈希（commit hash）标识，也可结合分支、标签与补丁文件。代码版本决定了数据如何被读取、模型如何被构建、损失如何被计算。

数据版本指训练、验证、测试所用数据集的特定状态。它可以是数据文件的哈希、数据集的版本号、采集批次，或经过清洗、标注、切分后的快照。数据版本变化会直接改变模型学到的分布，是“模型变了”的常见根因之一。

环境依赖包括操作系统、Python 版本、CUDA 驱动、深度学习框架、第三方库及其精确版本，以及编译选项与硬件型号。环境依赖决定了算子实现、数值精度和并行行为，同一份代码在不同环境中可能产生不同结果。

一致性审计是对上述资产进行系统性核对的过程：确认模型参数、超参数、代码版本、数据版本与环境依赖在训练、评估、部署各阶段是否指向同一组确定状态，并记录差异、评估影响、给出修复建议。

二、一致性审计的方法流程

一致性审计不是一次性检查，而应嵌入研发流水线。推荐按以下五步执行：

1. 资产清单化：列出模型交付所需的全部资产，包括权重文件、配置文件、代码仓库、数据快照、依赖清单与硬件说明。
2. 标识唯一化：为每项资产分配可追溯的唯一标识，如权重 SHA256、Git commit、数据集版本号、requirements 锁文件哈希。
3. 状态采集：在训练、评估、部署三个关键节点自动采集上述标识，写入审计日志或元数据文件。
4. 差异比对：将各节点采集到的标识与基线清单比对，识别缺失、变更与不一致项。
5. 影响评估与修复：判断差异是否影响指标或线上行为，必要时回滚、重训或补充记录。

三、典型场景与审计清单

假设一个推荐模型在离线评估中 AUC 为 0.82，上线后却降到 0.79。排查时可按资产维度逐项核对：

审计日志可以设计为结构化记录，便于自动比对：

{
  "model_id": "rec-v3-20240612",
  "weights_sha256": "a1b2c3...",
  "git_commit": "9f8e7d6",
  "dataset_version": "ds-2024-06-01",
  "hyperparams": {"lr": 0.001, "batch_size": 512, "epochs": 30},
  "env": {"python": "3.10.13", "torch": "2.2.1", "cuda": "12.1"}
}

四、常见误区与复盘要点

复盘时建议追问三个问题：差异发生在哪个环节？该差异是否被记录？如果未被记录，流程中缺少哪个采集点？通过持续补齐采集点，一致性审计才能从“救火”转为“免疫”。