2. 评分模型生命周期管理：从训练到部署的完整流程、模型版本管理、模型注册与元数据管理
在风控评分通道中，模型并非一次性交付的产物。从特征工程、训练调优到生产部署，再到持续监控与迭代，构成了一个闭环的生命周期。本章聚焦于如何通过工程化手段管理这一生命周期，确保模型的可追溯性、可复现性与可审计性。
2.1 模型生命周期全景流程
一个完整的评分模型生命周期包含以下六个核心阶段，每个阶段都对应特定的工程交付物与质量门禁：
| 阶段 | 关键活动 | 产出物 | 质量门禁 |
|---|---|---|---|
| 1. 数据准备 | 特征工程、样本划分、缺失值处理 | 训练集/验证集/测试集、特征Schema | 数据质量报告、特征覆盖率 > 95% |
| 2. 模型训练 | 算法选择、超参调优、交叉验证 | 模型文件（pickle/ONNX）、训练日志 | KS/AUC 达到业务基线 |
| 3. 模型评估 | 离线回测、稳定性测试、公平性校验 | 评估报告、PSI 指标 | PSI < 0.1，拒绝率偏差 < 5% |
| 4. 模型注册 | 版本号分配、元数据录入、存储归档 | 注册记录、模型包（含签名） | 元数据完整性校验通过 |
| 5. 模型部署 | 容器化、A/B 测试、灰度发布 | 推理服务、路由规则 | 压测 QPS 达标、延迟 < 200ms |
| 6. 监控与迭代 | 实时监控、数据漂移检测、触发重训 | 监控看板、重训触发记录 | 报警响应时间 < 5分钟 |
工程要点： 每个阶段结束后，必须将产出物推送至中央存储（如 MinIO 或 S3），并记录操作日志到审计数据库。禁止在本地环境保留唯一副本。
2.2 模型版本管理策略
版本管理是模型生命周期的核心骨架。推荐采用语义化版本号 + 哈希指纹的双重标识机制：
- 语义化版本（Major.Minor.Patch）：Major 表示架构或算法变更（如从 XGBoost 切换到 LightGBM）；Minor 表示特征增减或超参调整；Patch 表示 Bug 修复或重训。
- 哈希指纹（SHA256）：对模型文件内容计算哈希，用于防篡改校验和精确回滚。
版本管理的关键规则：
- 每个版本必须关联唯一的训练任务 ID（Run ID）。
- 版本号一旦发布，禁止修改；如需更新，必须递增 Patch 号。
- 生产环境只允许引用已注册的版本，禁止直接加载未注册的模型文件。
实践建议： 使用 Git 对模型训练代码进行标签化管理，模型版本号与 Git Tag 保持一一对应关系。例如：模型 v2.1.0 对应 Git Tag
model/v2.1.0。
2.3 模型注册与元数据管理
模型注册中心（Model Registry）是生命周期管理的枢纽。它负责存储模型文件、版本信息以及丰富的元数据，为后续的部署、监控和审计提供统一入口。
一个完整的模型注册记录应包含以下元数据字段：
| 元数据类别 | 字段示例 | 说明 |
|---|---|---|
| 基础信息 | 模型名称、版本号、创建时间 | 唯一标识模型身份 |
| 训练溯源 | 训练代码 Git Commit、数据集版本、超参配置 | 支持复现训练过程 |
| 评估指标 | KS、AUC、PSI、Lift 值 | 用于版本对比与准入判断 |
| 部署状态 | 当前部署环境（Staging/Production）、部署时间 | 追踪模型在哪个环境生效 |
| 审批记录 | 审批人、审批意见、审批时间 | 满足合规与审计要求 |
| 存储路径 | 模型文件在对象存储中的 URI | 确保可下载与加载 |
避坑指南： 元数据中的超参配置必须使用 JSON 或 YAML 结构化存储，禁止以纯文本描述。否则在自动化部署时，解析失败会导致上线阻塞。
2.4 生命周期管理架构图
下图展示了从训练到部署的完整流程，以及模型注册中心在其中的枢纽作用：
2.5 模型注册与部署的交互流程
下图进一步细化模型注册中心与部署环境之间的交互细节，展示版本晋升（Promotion）的典型路径：
2.6 元数据管理最佳实践
元数据是模型可追溯性的基石。以下是经过生产验证的元数据管理规范：
- 自动化采集：训练脚本中嵌入元数据采集器（如 MLflow Tracking 或自定义 Decorator），自动记录超参、指标和代码版本，避免人工录入错误。
- 不可变存储：元数据一旦写入注册中心，禁止修改或删除。如需更正，只能新增一条修正记录并标记原记录为“已废弃”。
- 版本对比视图：提供 Web UI 或 API，支持任意两个版本之间的元数据对比（如 KS 变化、特征列表差异），辅助决策是否晋升。
- 审计日志：所有对模型注册中心的读写操作（包括查询、注册、晋升、回滚）必须记录操作人、时间、操作类型和变更内容。
生产案例： 某头部消金公司因未记录训练数据集版本，导致模型上线后特征分布与训练时严重偏离，PSI 高达 0.25。事后强制要求每次训练必须记录数据集快照 ID，并在注册元数据中校验该 ID 是否存在。
2.7 生命周期管理工具选型
| 工具/平台 | 核心能力 | 适用场景 | 注意事项 |
|---|---|---|---|
| MLflow | 实验跟踪、模型注册、部署 | 中小团队快速搭建 | 元数据存储依赖后端数据库 |
| Kubeflow | K8s 原生、Pipeline 编排 | 大规模、多租户场景 | 运维成本较高 |
| 自定义 Registry | 高度定制、与风控系统深度集成 | 有特殊合规或审计要求 | 需自研元数据采集与 UI |
| Neptune.ai | 元数据可视化、团队协作 | 注重实验对比与协作 | SaaS 模式，数据出境需评估 |
选型建议： 对于风控评分通道，推荐以 MLflow 作为起点，快速实现模型注册与版本管理；当团队规模超过 20 人且模型数量超过 100 个时，迁移至 Kubeflow 或自研平台以获得更好的权限控制与审计能力。