2、模型版本管理基础：版本控制概念、模型版本化与代码版本化的区别、常见版本管理工具

2.1 版本控制的核心概念

版本控制（Version Control）的本质是对变更进行记录、追踪与回溯。在软件工程中，它解决了“谁、在什么时候、为什么、改了什么”这一系列问题。对于MLOps而言，版本控制的对象从单纯的源代码扩展到了数据、特征、模型参数、超参数、训练脚本、评估指标以及部署配置等更广泛的资产。

一个完整的版本控制体系需要具备以下三个基本能力：

• 快照（Snapshot）：在特定时间点保存全部相关文件或对象的状态，形成可恢复的“存档点”。
• 变更记录（Change Log）：记录每次提交（Commit）之间的差异（Diff），包括变更内容、作者、时间戳和提交信息。
• 分支与合并（Branch & Merge）：允许在独立的分支上进行实验性开发，完成后将变更合并回主线，从而支持并行迭代与风险隔离。

2.2 模型版本化与代码版本化的关键区别

很多团队最初尝试用Git管理模型文件，但很快发现行不通。模型版本化与代码版本化存在本质差异，理解这些差异是选择正确工具的前提。

对比维度	代码版本化（Git）	模型版本化
对象类型	纯文本文件（源码、配置）	二进制大文件（权重、梯度）、结构化元数据
变更粒度	行级差异（Diff），可逐行审查	无法做有意义的行级Diff，只能比较指标或哈希值
存储体积	通常为KB～MB级	单个模型可达数百MB～GB级
关联信息	代码逻辑、依赖关系	训练数据版本、超参数、评估指标、框架环境
回滚验证	回滚后运行测试即可验证	回滚后需重新评估模型效果，验证成本高
分支合并	文本合并算法成熟，冲突易解决	二进制文件无法自动合并，只能整体替换

从上表可以看出，模型版本化更强调“血缘关系”（Lineage）的追踪——即模型是由哪份数据、哪个训练脚本、哪组超参数产生的，而不仅仅是文件内容的变化。

2.3 常见版本管理工具与选型

针对模型版本化的特殊需求，业界出现了多种工具。根据管理层次的不同，可以将其分为三类：

2.3.1 基于Git的扩展方案：DVC（Data Version Control）

DVC 并不替代 Git，而是作为 Git 的补充层。它将模型文件、数据集等大文件存储在远程存储（如S3、OSS、本地磁盘）中，而在 Git 仓库中只保存一个轻量的 元数据文件（.dvc 文件），记录大文件的哈希值和存储位置。

# DVC 典型工作流
dvc init                                # 初始化 DVC
dvc add models/model_v1.pkl             # 跟踪模型文件，生成 model_v1.pkl.dvc
git add models/model_v1.pkl.dvc .dvc/config
git commit -m "track model v1.0"
dvc remote add myremote s3://mybucket/models
dvc push                                # 将大文件推送到远程存储

# 回滚到某个历史版本
git checkout v1.0-tag
dvc checkout                            # 根据 .dvc 文件自动拉取对应的大文件

优点：与 Git 工作流无缝集成，学习成本低。缺点：不提供模型评估指标、实验参数等结构化元数据的自动记录。

2.3.2 实验跟踪平台：MLflow Model Registry

MLflow 提供了完整的模型生命周期管理。其 Model Registry 组件专门用于模型的注册、版本标注（Staging / Production / Archived）和阶段转换。

# MLflow 记录模型及元数据
import mlflow
from mlflow.tracking import MlflowClient

mlflow.set_experiment("fraud_detection")
with mlflow.start_run():
    mlflow.log_param("n_estimators", 200)
    mlflow.log_metric("auc", 0.923)
    mlflow.sklearn.log_model(model, "model")

client = MlflowClient()
client.transition_model_version_stage(
    name="fraud_detection_model",
    version=3,
    stage="Production"
)

优点：内置模型注册表、阶段管理、Web UI 可视化。缺点：模型文件本身仍建议配合 DVC 或对象存储使用。

2.3.3 数据血缘追踪：LakeFS / Nessie

这类工具将数据湖的版本控制能力提升到 Git 操作级别，支持对数据集的分支、提交、合并和回滚，适合需要精细控制训练数据版本的场景。

2.4 实战案例：一个典型的模型版本化流程

假设某金融风控团队需要管理信用卡欺诈检测模型，他们采用 DVC + MLflow 的组合方案：

1. 数据准备阶段：使用 DVC 跟踪训练数据集 fraud_data_v2.3.csv，并记录其哈希值。
2. 实验阶段：在 MLflow 中启动多次实验，每次运行记录超参数（如 max_depth、learning_rate）和评估指标（AUC、F1）。
3. 模型注册：当某次实验的 AUC 达到 0.938 时，将该模型注册到 Model Registry，标记为 Staging 阶段。
4. 上线审批：经过离线评估和影子测试后，将模型版本从 Staging 转为 Production。
5. 追溯与回滚：线上监控发现模型效果下降，通过 MLflow 查看 Production 模型的元数据，发现其训练数据版本为 fraud_data_v2.3，而当前最新数据为 fraud_data_v3.0。团队决定回滚到上一个 AUC 为 0.925 的模型版本，同时用 DVC 拉取对应的旧数据集进行问题复现。

2.5 常见误区与复盘