3. 版本管理基础概念

在工业AI项目中，模型不是一次性交付物，而是伴随数据采集、标注、训练、调参、验证、部署、回滚持续演进的“活资产”。如果团队只用文件名区分，例如 model_final_v2_new.h5，很快就会陷入“谁覆盖了谁、哪一版上线、为什么指标下降”的混乱。版本管理基础概念正是用来把这种混乱转化为可追溯、可复现、可审计的工程秩序。

一、核心术语的工业含义

版本（Version）是对某一时刻模型资产整体状态的正式命名，通常对应一次可发布或可交付的成果。工业场景中，一个版本不仅包含权重文件，还可能包含训练数据版本、特征工程配置、超参数、评估报告和部署镜像。版本强调“整体一致性”，即这些要素必须绑定在一起才有意义。

修订（Revision）是版本内部的细粒度变更记录，类似Git中的commit。例如调整学习率、修正标签映射、替换一个预处理算子，都会产生修订。修订回答“从上一状态到当前状态改了什么”，是审计和问题定位的最小单位。

分支（Branch）是从某个基线或版本分出的独立演进线。工业AI常见分支包括：main用于稳定发布，exp/lr-sweep用于学习率实验，hotfix/defect-detection用于产线缺陷模型紧急修复。分支让实验与稳定发布互不干扰，但必须约定合并与废弃策略，否则分支会失控膨胀。

标签（Tag）是给某个修订或版本起的不可变别名，例如 v1.3.0-prod、2024Q3-质检模型。标签一旦创建不应随意移动，它是发布、回滚和审计的锚点。工业场景中，标签常与产线、工厂、客户合同绑定，具有法律和运维双重意义。

基线（Baseline）是被正式确认、可作为后续比较和开发起点的版本。基线不是“最新”，而是“被批准稳定”。例如某缺陷检测模型在A产线达到召回率98.5%后，被定为基线；后续所有优化都需与它对比，避免“越改越差”。

快照（Snapshot）是对某一时刻完整环境状态的保存，包括代码、数据指针、依赖库、容器镜像和配置。快照强调“可还原”，即使上游数据被删除、依赖被升级，也能重建当时环境。工业现场常要求“三个月前那批模型必须能重新跑出来”，快照就是答案。

元数据（Metadata）是描述版本属性的结构化信息，如作者、时间、数据集ID、准确率、召回率、训练时长、GPU型号、审批人、适用产线。元数据让版本从“一个文件”变成“可检索、可比较、可治理的资产”。

二、版本、修订、快照的协作流程

在工业AI平台中，三者通常按以下顺序协作：工程师在分支上提交修订，系统自动记录元数据；当实验达到目标指标后，创建快照并打标签；经审批后，该标签对应的版本被提升为基线，进入发布流程。发布后若产线出现异常，可依据标签快速回滚到上一基线，并用快照重建当时环境进行复现。

# 工业AI模型版本管理典型操作序列
1. git checkout -b exp/defect-v4        # 创建实验分支
2. git commit -m "r7: 增加夜间光照样本"   # 产生修订
3. ai-registry snapshot create \
     --data-version ds-2024-09-18 \
     --image registry.local/defect:cu121 \
     --config train_v4.yaml              # 创建快照
4. ai-registry tag create v1.4.0-rc1 \
     --snapshot snap-7f3a                # 打标签
5. ai-registry baseline promote v1.4.0-rc1 \
     --line A --approver zhang           # 提升为基线
6. ai-registry deploy --tag v1.4.0-prod  # 发布到产线

三、工业场景案例：缺陷检测模型的三次迭代

某汽车零部件工厂的缺陷检测模型经历三次迭代。第一次，工程师在 main 分支直接修改并覆盖旧文件，导致产线回滚时找不到原模型；第二次，团队引入标签 v1.0-prod 和快照，但元数据只记录了准确率，未记录数据版本，复现时发现训练集已被清洗；第三次，团队建立完整规范：每个版本必须绑定数据版本、镜像、配置和评估报告，基线由质量工程师审批，标签不可移动。结果，模型回滚时间从4小时缩短到8分钟，审计通过率显著提升。

四、常见误区与复盘清单

理解版本、修订、分支、标签、基线、快照和元数据，本质上是为工业AI建立一套“可追溯、可复现、可审批、可回滚”的资产治理语言。只有把这些术语落到平台字段和日常操作中，版本管理才不会停留在概念层面，而成为产线稳定运行的基础设施。