3. MLOps核心概念
在金融场景中，模型不是一次性交付的“分析报告”，而是一个需要长期运行、持续监控、定期迭代的生产系统。MLOps 的核心价值，就是把数据、代码、模型、配置和合规证据串成一条可追溯、可复现、可审计的流水线。本节围绕四个关键概念展开：机器学习生命周期、持续集成/持续交付/持续训练、特征存储、模型注册。
一、机器学习生命周期：从需求到退役的闭环
机器学习生命周期描述了一个模型从业务问题定义到最终退役的完整过程。与普通软件不同，它多了数据与模型两个变量，因此每个阶段都可能反向触发上游变更。典型阶段包括：
- 问题定义与合规评估：明确预测目标、业务指标、风险边界与监管要求，例如信贷评分需满足可解释性与公平性审查。
- 数据探索与特征工程：从原始数据中构造特征，并记录特征口径、时间窗口与数据血缘。
- 模型训练与实验：管理超参数、随机种子、训练数据版本，确保实验可复现。
- 模型评估与验证：除离线指标外，还需进行压力测试、偏差检测与业务规则校验。
- 部署与上线：通过灰度、影子流量或 A/B 测试逐步放量。
- 监控与运维：跟踪数据漂移、模型衰减、延迟与异常率。
- 再训练与退役：当性能下降或业务变化时触发迭代，最终安全下线。
二、CI/CD/CT：把模型迭代变成工程流水线
持续集成（CI）、持续交付（CD）与持续训练（CT）共同构成 MLOps 的自动化骨架。CI 负责代码与配置的自动构建、测试与镜像打包；CD 负责将验证通过的模型或服务自动部署到目标环境；CT 则是在数据或性能触发条件下自动完成训练、评估与候选模型产出。
三者的关系可以理解为：CI 保证“代码正确”，CD 保证“部署可靠”，CT 保证“模型新鲜”。在金融风控场景中，CT 通常由数据漂移告警或定时任务触发，训练完成后进入模型注册表，再由 CD 流程决定是否发布。
# 典型的 CT 触发配置示例（伪 YAML）
trigger:
schedule: "0 2 * * *" # 每日凌晨2点
drift_threshold: 0.15 # 特征漂移超过阈值触发
pipeline:
- fetch_features@feature_store
- train_model@training_image
- evaluate_model@validation_suite
- register_model@model_registry
- notify@risk_team需要强调的是，CT 不等于“自动上线”。训练产出的模型只是候选版本，必须经过评估门禁与人工审批，才能进入生产环境。
三、特征存储：让特征可复用、可一致
特征存储（Feature Store）是 MLOps 中解决“训练与推理特征不一致”的关键基础设施。它通常包含离线存储与在线存储两部分：离线存储用于批量训练，在线存储用于低延迟推理。特征存储的核心能力包括：
- 特征注册与发现：统一管理特征名称、类型、口径与负责人。
- 时间点正确性：训练时按事件时间回溯，避免未来数据泄露。
- 训练/推理一致性：同一特征定义同时服务离线与在线，减少“线上线下不一致”事故。
- 血缘与版本：记录特征来源、变换逻辑与版本变更。
四、模型注册：模型资产的唯一真相源
模型注册表（Model Registry）是模型资产的中央目录，记录每个模型的版本、阶段、指标、依赖与审批状态。它通常与 CI/CD/CT 流水线集成，形成“训练—注册—审批—部署”的闭环。一个实用的模型注册表应包含以下字段：
| 字段 | 说明 | 金融场景示例 |
|---|---|---|
| 模型名称 | 业务唯一标识 | credit_score_v2 |
| 版本号 | 语义化版本或时间戳 | 2025.06.01-rc3 |
| 阶段 | Staging / Production / Archived | Staging |
| 训练数据版本 | 数据集快照或特征视图 | feature_view_202505 |
| 评估指标 | AUC、KS、PSI 等 | AUC=0.82, KS=0.41 |
| 审批人 | 合规与业务负责人 | risk_lead_zhang |
模型注册表不仅是技术工具，也是合规证据链的一部分。当监管要求解释“某笔贷款为何被拒”时，可以通过注册表定位到具体模型版本、训练数据与特征口径。
五、常见误区与复盘
- 误区一：把 MLOps 等同于 DevOps。 模型会随数据变化而衰减，必须引入 CT 与监控，而不仅是代码部署。
- 误区二：特征工程各自为战。 没有特征存储，团队重复造轮子，且训练与推理口径不一致。
- 误区三：模型注册表只存文件。 缺少指标、审批与血缘，无法支撑审计与回滚。
- 误区四：CT 触发即上线。 自动训练必须配合评估门禁与人工审批，否则风险不可控。