4. 金融MLOps团队角色与职责
金融MLOps不是把模型训练脚本搬到生产环境那么简单。在银行、证券、保险等强监管场景中，一个模型从需求提出到上线运行，需要数据科学家、ML工程师、DevOps、合规官、业务方五类角色持续协作。理解每个角色的职责边界与协作接口，是团队交付规范能够落地的前提。
核心原理：为什么金融MLOps需要五方分工
金融MLOps的核心矛盾在于：模型迭代速度与合规审计要求之间存在天然张力。数据科学家追求快速实验，业务方追求指标提升，而合规官必须确保模型可解释、可追溯、可审计。如果由单一角色承担全部职责，要么牺牲迭代效率，要么埋下合规风险。
五方分工的本质是职责分离与接口标准化。每个角色在模型生命周期中拥有明确的输入、输出和决策权，通过制品仓库、特征平台、审批工单等标准化接口交接，避免口头传递和职责模糊。
方法流程：五方职责与协作接口
下面用一张职责清单明确每个角色的核心交付物与协作边界。
| 角色 | 核心职责 | 关键交付物 | 主要协作对象 |
|---|---|---|---|
| 业务方 | 定义业务目标、验收标准、风险偏好 | 需求说明书、KPI定义、验收报告 | 数据科学家、合规官 |
| 数据科学家 | 特征工程、模型训练、实验追踪、可解释性分析 | 模型包、特征定义、实验记录、SHAP报告 | ML工程师、业务方 |
| ML工程师 | 训练流水线、模型服务化、特征平台、版本管理 | CI/CD流水线、推理服务、特征存储 | 数据科学家、DevOps |
| DevOps | 环境管理、监控告警、发布回滚、资源调度 | K8s配置、监控看板、发布记录 | ML工程师、合规官 |
| 合规官 | 模型审计、公平性检查、数据合规、留痕审查 | 合规报告、审计日志、审批意见 | 全体角色 |
协作流程遵循“业务提需求 → 科学家做实验 → ML工程师做工程化 → DevOps做发布 → 合规官做审计”的主链路，但合规官并非只在末端介入，而是在需求评审、特征设计、模型上线三个关键节点设置检查点。
案例场景：信贷评分模型上线协作
某银行需要上线一个信贷评分模型。业务方提出“将审批通过率提升5%同时控制坏账率”。数据科学家在特征平台中选取近12个月交易流水、征信查询次数等特征，训练XGBoost模型并生成SHAP解释报告。ML工程师将模型封装为REST服务，编写训练流水线YAML配置：
pipeline:
name: credit_score_v2
stages:
- feature_ingest:
source: feature_store/credit_features_v3
- train:
image: ml-base:1.4
command: python train.py --model xgboost --seed 42
- evaluate:
metrics: [auc, ks, psi]
threshold: {auc: 0.78, psi: 0.1}
- register:
registry: mlflow/prod
require_approval: compliance_officerDevOps将该流水线接入GitLab CI，配置生产环境为双副本部署并设置PSI监控告警。合规官在审批工单中检查特征是否包含敏感字段、SHAP报告是否满足监管解释要求，确认后签字放行。整个链路中，每个角色的输出都作为下一个角色的输入，且全部留痕在制品仓库中。
误区与复盘：常见协作断裂点
- 误区一：合规官只在最后签字。合规检查前置到需求评审和特征设计阶段，可避免模型训练完成后因特征不合规而返工。
- 误区二：数据科学家直接交付模型文件给DevOps。缺少ML工程师的工程化封装，会导致推理服务性能差、版本混乱。正确路径是科学家交付到模型注册中心，由ML工程师构建服务。
- 误区三：业务方不参与验收。业务方需在影子模式阶段确认模型输出是否符合业务直觉，否则上线后容易出现“指标达标但业务不可用”的尴尬。
- 误区四：DevOps不参与模型监控设计。模型漂移监控与基础设施监控需要统一告警通道，DevOps早期介入可避免监控孤岛。
五方协作模式不是增加沟通成本，而是通过明确的职责边界和标准化接口，让每个角色在专业领域内高效工作，同时满足金融监管对可解释、可审计、可追溯的刚性要求。