2. 风控模型监控体系基础：监控指标分类、数据采集与告警级别
风控模型上线后并非“一劳永逸”。随着客群迁移、欺诈手法演变、数据源波动，模型性能会持续衰减。一套完整的监控体系是灰度发布和日常运维的“仪表盘”。本章从指标分类、数据采集方式和告警级别三个维度，搭建监控体系的基础框架。
2.1 监控指标分类：性能、稳定性、效果
监控指标按关注维度分为三大类，每类对应不同的业务与技术视角：
| 分类 | 核心关注点 | 典型指标 | 监控频率 |
|---|---|---|---|
| 性能指标 | 模型计算效率与系统资源 | QPS、P99 延迟、CPU/内存占用、超时率 | 分钟级 / 实时 |
| 稳定性指标 | 模型输出分布与特征偏移 | PSI、特征空值率、特征均值漂移、IV 衰减 | 小时级 / 天级 |
| 效果指标 | 模型区分能力与业务结果 | KS、AUC、Lift、通过率、坏账率、FPR/TPR | 天级 / 周级 |
实践建议：灰度发布初期优先关注稳定性指标（PSI、空值率），因为性能问题通常由压测覆盖，效果指标需要积累一定样本量（通常 7~14 天）才有统计意义。
三类指标的关系可以概括为：性能保障系统可用，稳定性反映模型行为是否一致，效果验证业务价值。三者缺一不可。
2.2 监控数据采集方式
数据采集是监控体系的“传感器”。根据数据源和时效性要求，通常采用以下三种方式：
- 实时日志采集（流式）
- 数据源：模型服务日志、API 调用日志、消息队列（Kafka / RocketMQ）
- 采集工具：Filebeat / Fluentd + Logstash + Elasticsearch
- 适用场景：性能指标（QPS、延迟）、实时稳定性指标（特征空值率）
- 离线批量采集（T+1）
- 数据源：Hive / HDFS 数仓表、业务数据库（MySQL / PostgreSQL）
- 采集方式：Sqoop / DataX / Spark 定时任务
- 适用场景：效果指标（KS、AUC）、日级 PSI、通过率统计
- 在线查询采集（近实时）
- 数据源：Redis / HBase / ClickHouse 实时聚合表
- 采集方式：定时轮询或 API 查询
- 适用场景：分钟级聚合指标、特征分布快照对比
架构要点：建议采用“流批一体”架构——实时流处理用于告警，离线批处理用于深度分析和报表。两者使用同一套指标定义口径，避免“实时正常、离线异常”的口径不一致问题。
2.3 监控告警级别定义
告警级别决定了响应速度和升级路径。建议采用四级告警体系，与灰度发布的不同阶段对应：
| 级别 | 名称 | 触发条件示例 | 响应要求 | 灰度阶段 |
|---|---|---|---|---|
| P0 | 严重（Critical） | 模型服务不可用、QPS 降为 0、PSI > 0.25 | 立即响应，15 分钟内介入 | 灰度暂停 / 回滚 |
| P1 | 高（Major） | P99 延迟 > 500ms、特征空值率突增 20% | 30 分钟内响应，1 小时内修复 | 灰度暂停 / 降级 |
| P2 | 中（Warning） | KS 下降 > 0.03、通过率波动 > 5% | 4 小时内分析，日会同步 | 灰度继续，加强观察 |
| P3 | 低（Info） | 特征均值漂移 < 5%、AUC 波动 < 0.01 | 记录日志，周报提及 | 灰度继续，无需干预 |
避坑提醒：不要将所有指标都设为 P0/P1 告警。过度告警会导致“狼来了”效应，真正严重问题时反而被忽略。建议灰度初期只配置 P0/P1 告警，P2/P3 先以日报形式观察，待模型稳定后再逐步开启自动告警。
告警级别与灰度发布决策的联动逻辑如下：
- P0 触发 → 自动暂停灰度流量，触发回滚流程，通知模型负责人与 SRE。
- P1 触发 → 暂停新流量接入，保留现有灰度流量，触发降级策略（如切换到备用模型）。
- P2 触发 → 标记为“待观察”，灰度流量继续，但需在当日灰度日报中分析原因。
- P3 触发 → 仅记录，不阻断灰度流程，用于长期趋势分析。