MLOps 治理与可复现：模型注册、漂移监控与合规

模型训练好只是开始，真正考验工程的是「上线之后」：版本有没有记清、漂移有没有报警、坏了能不能回滚、审计能不能说清楚。本文把 MLOps 的治理面讲透。

从训练到上线：治理为什么重要

ML 系统的独特性在于：代码与数据是两套变化源。普通软件 bug 改代码即可，ML 系统的「bug」可能是上游数据分布变了、特征口径变了、或某个实验超参埋了雷。没有治理，你无法回答三个致命问题：

• 线上这个模型是哪版代码、哪份数据、哪个超参训出来的？
• 它的效果最近为什么下降，是数据变了还是模型废了？
• 出事时能不能一键回滚到上一个稳定版本？

治理的目标就是把这三问变成可操作的系统能力。它包含四根支柱：注册（Registry）、复现（Reproducibility）、监控（Monitoring）、发布（Release）。

实验跟踪与可复现

可复现的第一步是实验记录：每次实验必须能回答「用什么代码、什么数据、什么配置跑出了什么指标」。工具上常用 MLflow / W&B / Neptune，但工具只是载体，关键是记录哪些字段：

• 代码版本：git commit hash（必须精确定位到 commit，而非「最新代码」）。
• 数据版本：数据集快照或 manifest hash（数据会变，不锁版本等于没有实验记录）。
• 超参与配置：完整 hyperparameter 集，含随机种子。
• 环境：镜像 tag、CUDA/PyTorch 版本。

# 用 MLflow 记录一次实验的关键字段
import mlflow

with mlflow.start_run(run_name="v3-gpt-finetune"):
    mlflow.log_param("lr", 1e-5)
    mlflow.log_param("seed", 42)
    mlflow.log_param("data_version", "s3://data/manifest_20260901.sha")
    mlflow.log_metric("eval_accuracy", 0.913)
    mlflow.log_artifact("code/.git_rev", artifact_path="code")
    mlflow.pytorch.log_model(model, "model")

可复现 = 代码 × 数据 × 配置 × 环境四元组都锁定。只要任何一个维度松动，指标对不上，实验就是「黑盒」。种子没锁、数据没锁版本，是复现翻车最常见的两个原因。

模型注册表：版本、元数据与审批

**模型注册表（Model Registry）**是模型的「Git 仓库」：每个模型版本都记录来源实验、指标、数据集、审批状态，并提供下载与部署接口。

# MLflow 模型注册：登记与推进状态
from mlflow.tracking import MlflowClient

client = MlflowClient()
client.create_registered_model("fraud_model")
client.create_model_version("fraud_model", source=run_uri, run_id=run_id)
client.transition_model_version_stage(
    "fraud_model", version=3, stage="Production"
)  # Staging → Production 需要审批

注册表的核心价值是状态机：模型从 Staging（灰度验证）→ Production（全量）→ Archived（下线），每一步都有审批与审计痕迹。回滚时只需把流量切回 Production 前一个版本，而非「从硬盘找一个旧文件」。

实践中要防止注册表变成「只登记不治理」：没有指标准入的注册毫无意义。给每个模型版本绑定「上线前的强制检查」——离线指标达标、漂移基线建立、回滚预案就绪，三者齐全才允许进 Production。

数据漂移与概念漂移

模型效果衰减通常不是模型自己坏了，而是分布变了。两类漂移必须区分：

• 数据漂移（Data Drift）：输入特征分布变了（用户群变化、季节变化、采集口径变化）。模型还是那个模型，喂进来的东西不一样了。
• 概念漂移（Concept Drift）：输入分布没变，但「输入→标签」的关系变了（风控规则收紧、用户偏好迁移）。旧模型在旧数据上是对的，新数据上就错了。

检测方法分三类：

# 特征分布漂移：PSI（总体稳定性指数）常用阈值
# PSI = Σ (实际分布占比 - 基准分布占比) × ln(实际/基准)
# 经验阈值: PSI < 0.1 无漂移 | 0.1~0.25 需关注 | > 0.25 显著漂移

# 分类任务概念漂移: KS 检验比较两期预测分布
# from scipy.stats import ks_2samp
# ks_stat, pvalue = ks_2samp(preds_now, preds_baseline)

# 无监督漂移检测: 用 Embedding + 密度/聚类统计观察输入分布变化

工程关键是把漂移检测做成在线管道：每天对线上特征与标签抽样，对基线做统计检验，超过阈值自动告警。漂移告警不是终点，要联动「查原因」（哪个特征漂了、哪个群体漂了）才有价值。

模型效果监控与告警

漂移监控之外，还要直接盯业务指标：准确率、AUC、转化率、用户满意度。业务指标往往有延迟（标签滞后），监控策略要分层：

• 实时代理指标（Proxy）：响应延迟、空回复率、用户点踩率、重试率——立刻可得，适合秒级告警。
• 准实时指标：预测分布变化、置信度分布——分钟级。
• 延迟标签指标：AUC/NDCG 需要标签回流，按日/周聚合。

# 监控告警配置的示意（Prometheus + 告警规则）
# alert: ModelAccuracyDrop
#   expr: accuracy_7d < baseline_accuracy_7d - 0.05
#   for: 3d   # 连续 3 天低于基线才告警，减少误报

告警要设基线、设静默、防轰炸：无基线的告警没有意义，昼夜高峰抖动要区分对待，同一根因的告警要合并。目标是「漂移当天能发现」，而不是「月末复盘才发现已经烂了三周」。

金丝雀发布与回滚

模型上线最忌讳「一把梭」。成熟流程是金丝雀（Canary）发布：

1. 新模型先接 1%~5% 流量，旁路对比新旧两版输出与业务指标。
2. 观察若干天，新模型指标 ≥ 旧模型（或满足业务预期），再逐步放大比例。
3. 异常立即切回旧版本（回滚），评估原因后再决定是否重试。

# 流量切分逻辑（示意）
# if hash(user_id) % 100 < canary_percent:  用新模型
# else:                                      用旧模型
# 监控 canary 组指标；达标则 canary_percent += 10%，异常则整体回滚

回滚要快且可预期：模型注册表存好历史版本，回滚 = 切换路由到上一 Production 版本，分钟级完成。同时保留旁路日志（shadow traffic）——新模型与旧模型同时算但不影响线上，用来无风险评估候选模型。

AI 合规与审计

治理的最后一层是合规与可审计性：

• 模型卡（Model Card）：为每个模型写说明书——用途、训练数据、已知限制、偏见评估、适用人群。既是工程文档，也是合规材料。
• 偏见与公平性评估：分组指标（按性别/年龄/地域分组）对比，识别系统性偏差，高风险场景（信贷、招聘、医疗）必须做。
• 审计日志：谁在什么时候把哪个版本推进 Production、为什么、审批人是谁——全链路留痕。
• 可解释性留档：关键决策留存 SHAP 值等解释产物，出争议时有据可查。

# 模型卡的关键字段（示意）
# Model: fraud_model_v3
# Data: 2026-01~2026-08 交易样本（含人工抽样+规则扩样）
# Limitations: 对"新开账户"样本召回偏低；仅供内部风控参考
# Fairness: 按地域分组 AUC 差异 < 0.02（已通过评估）
# Version control: run_id=... , data_sha=...

合规不是「文档负担」，而是把模型生命周期变成可追溯的流程。出问题时能快速归因：是数据变了、代码改了、还是模型本身有偏见——这决定你修的是数据管线、训练管线还是产品策略。

总结

MLOps 治理把模型的「玄学」变成「工程」：注册表锁版本、实验跟踪锁复现、漂移监控锁健康、金丝雀发布锁风险、模型卡锁合规。落地顺序建议：先做注册表与实验跟踪（一切治理的地基），再做漂移监控（尽早发现数据变化），最后完善发布与合规（流程规范）。记住治理的目标不是流程本身，而是让任何一次模型事故都能被快速定位、快速回滚、说清责任。