2、核心概念：模型版本、模型注册表、模型元数据、模型血缘

在构建企业级ML模型管理体系时，首先需要厘清四个相互关联的基础概念：模型版本、模型注册表、模型元数据与模型血缘。它们并非孤立的术语，而是构成模型生命周期管理的四根支柱。理解它们之间的关系，是后续设计版本策略、回滚机制与审计体系的前提。

2.1 模型版本：不可变快照与语义化标识

模型版本是对一次模型产物（如训练好的权重文件、推理图、预处理逻辑）的不可变快照。一旦发布，该版本的内容不应再被修改；任何变更都应产生新版本。企业实践中通常采用语义化版本号（Semantic Versioning）来标识：

主版本号.次版本号.补丁号
例：v2.3.1
- 主版本：模型架构或核心算法发生重大变化（如从XGBoost切换到Transformer）
- 次版本：新增特征、超参数调优、训练数据量显著变化
- 补丁号：修复bug、微调参数、重新训练但结构不变

版本不可变性是回滚机制的基础。如果版本内容可被覆盖，那么“回滚到v2.3.1”将失去意义——因为你无法确定当前v2.3.1是否还是当初验证过的那个模型。因此，企业级ML平台通常将模型文件存储于对象存储（如S3、OSS）或版本化文件系统中，并以内容寻址（如SHA-256哈希）确保完整性。

2.2 模型注册表：唯一可信的版本登记中心

模型注册表（Model Registry）是集中管理模型版本及其状态的服务。它类似于代码仓库中的Git，但针对模型产物增加了生命周期状态的管理。注册表的核心职责包括：

• 版本登记：记录每个版本的唯一标识、存储路径、上传时间、创建者。
• 状态流转：管理模型版本在Draft（草稿）→ Staging（预发布）→ Production（生产）→ Archived（归档）之间的转换。
• 审批与权限：只有具备权限的人员才能将模型从Staging提升至Production。
• 部署关联：记录当前生产环境实际部署的是哪个版本，支持一键回滚到历史版本。

以MLflow Model Registry为例，其核心操作如下：

# 注册新版本
client.create_registered_model("fraud_detector")
client.create_model_version(
    name="fraud_detector",
    source="s3://models/fraud_detector/v2.3.1/",
    run_id="d4f2c8e1a9b34f6a"
)

# 状态流转
client.transition_model_version_stage(
    name="fraud_detector",
    version=3,
    stage="Production"
)

注册表的存在，使得“当前哪个模型在服务”这一问题有了唯一权威答案，避免了团队中“我记得好像用的是那个版本”的混乱。

2.3 模型元数据：描述版本属性的结构化信息

模型元数据是附着于每个模型版本之上的键值对集合，用于描述该版本的来源、性能、配置与约束。没有元数据的模型版本，就像没有标签的集装箱——你知道里面是货物，但不知道是什么、来自哪里、能否使用。

企业级元数据通常包含以下类别：

元数据与版本是强绑定关系：元数据描述的是某个特定版本，而非整个模型。当版本被回滚时，其对应的元数据也应一并恢复，确保审计信息的一致性。

2.4 模型血缘：从数据到模型的全链路追溯

模型血缘（Lineage）记录了模型版本与上游数据、代码、配置之间的依赖关系。它回答了一个关键问题：“这个模型版本是如何产生的？”血缘关系通常以有向无环图（DAG）的形式表达：

原始数据表 (user_events_20250101)
    └─ 特征工程脚本 (feature_eng.py @ commit 8f3a2c)
        └─ 训练数据集 (train_data_v5.parquet)
            └─ 训练代码 (train.py @ commit 4b7e9d)
                └─ 模型产物 (fraud_detector_v2.3.1.pkl)
                    └─ 评估报告 (eval_report_v2.3.1.json)

血缘的价值体现在三个场景：

1. 问题溯源：当生产环境模型表现异常时，通过血缘回溯到训练数据或特征代码，快速定位根因。
2. 影响分析：当上游数据表结构变更时，通过血缘找出所有受影响的模型版本，提前评估风险。
3. 合规审计：监管要求解释模型决策依据时，血缘提供了完整的证据链。

2.5 四者协同：一个典型的企业级场景

假设某金融风控团队需要将信贷欺诈检测模型从v2.3.1升级到v2.4.0，完整流程如下：

• 数据团队发布user_events_20250201数据快照，并记录在数据目录中。
• 特征团队更新特征工程代码，提交至Git，生成feature_eng_v12。
• 算法工程师使用上述数据与代码训练新模型，将产物上传至模型注册表，自动生成版本号v2.4.0。
• 系统自动采集元数据：训练AUC=0.921、延迟P99=38ms、依赖库版本列表、训练耗时等。
• 血缘引擎记录：v2.4.0 ← feature_eng_v12 ← user_events_20250201 ← train.py@commit_8f3a2c。
• 模型在Staging环境通过验证后，由审核人批准提升至Production。
• 运行两周后，发现线上数据分布漂移导致AUC下降至0.87，团队决定回滚至v2.3.1。
• 注册表执行回滚操作，将生产流量切换至v2.3.1，同时保留v2.4.0的元数据与血缘记录，供后续分析。

这一流程中，四个概念各司其职：版本提供了回滚的目标对象，注册表提供了回滚的执行机制，元数据提供了回滚的决策依据（对比两个版本的指标），血缘提供了回滚后的审计证据。

2.6 复盘：常见实施误区