📚 课程目录第4章异常监控体系

4. 异常监控体系

信贷模型上线只是起点，真正决定模型能否持续创造价值的，是异常监控体系能否在风险恶化之前发出有效信号。一个成熟的监控体系不是“多埋几个指标”，而是围绕模型生命周期，把指标设计、阈值设定、预警机制、监控报表与自动化平台串成一条可执行、可追溯、可闭环的链路。本节将拆解这条链路的构建方法，并给出可直接落地的设计要点。

一、核心原理：监控体系的四层结构

异常监控的本质是回答三个问题：看什么、什么时候算异常、异常之后怎么办。围绕这三个问题，监控体系可拆为四层：

指标层：定义反映模型健康度的量化信号，覆盖数据、模型、业务三类。
阈值层：为每个指标设定正常波动区间与触发边界，区分统计波动与真实劣化。
预警层：定义触发条件、分级规则、通知渠道与响应时限。
平台层：通过报表与自动化平台实现采集、计算、告警、归档的持续运转。

四层之间是递进关系：指标设计不合理，阈值再精细也是噪声；阈值过松或过紧，预警就会失效或泛滥；预警没有响应机制，平台只是“看板装饰”。因此，监控体系必须与根因定位和整改闭环直接衔接，否则监控就只是事后记录。

二、监控指标设计：三类指标与关键清单

信贷模型监控指标通常分为三类，每类关注点不同，但必须同时覆盖，避免“只看业务、不看数据”或“只看模型、不看客群”的盲区。

指标类别	核心指标	监控目的	典型异常信号
数据类	缺失率、异常值占比、字段分布PSI、入模变量覆盖率	确保输入数据稳定、可用	某字段缺失率从2%升至15%
模型类	评分分布PSI、KS、AUC、分数迁移率、拒绝率	判断模型区分能力与稳定性	评分PSI连续3期超过0.1
业务类	通过率、逾期率、vintage、滚动率、额度使用率	验证模型决策与业务结果一致性	首逾率环比上升30%

指标设计要遵循可计算、可对比、可归因三原则。可计算指口径明确、数据可得；可对比指有历史基线或同期对照；可归因指异常时能下钻到客群、渠道、变量等维度。建议每个核心指标都配置“总览+下钻”两级视图，避免只看总数无法定位问题。

指标不是越多越好。建议每个模型先锁定8～12个核心指标，其中数据类3～4个、模型类3～4个、业务类2～4个，再按需扩展。指标过多会导致告警疲劳，反而掩盖真正重要的信号。

三、阈值设定与预警机制：从静态到动态

阈值设定常见三种方式：统计阈值、业务阈值、动态阈值。统计阈值基于历史分布，如PSI>0.1、KS下降超过20%；业务阈值来自风险偏好，如首逾率超过3%必须介入；动态阈值则结合季节、客群、渠道变化，用移动平均或分位数自动调整。

# 阈值配置示例（YAML）
metrics:
  score_psi:
    warning: 0.10
    critical: 0.25
    window: 30d
  ks_drop:
    warning: 0.15
    critical: 0.30
    baseline: rolling_90d
  first_payment_overdue:
    warning: 0.025
    critical: 0.035
    dimension: [channel, product]
alert:
  channels: [email, sms, webhook]
  escalation: 
    - level: warning
      notify: model_owner
      sla: 24h
    - level: critical
      notify: [model_owner, risk_head]
      sla: 4h

预警机制的关键是分级与响应。建议分为提示、警告、严重三级：提示级仅记录并日报汇总；警告级通知模型负责人，要求24小时内给出初步判断；严重级升级至风险负责人，4小时内启动根因排查。预警信息必须包含指标名称、当前值、基线值、触发时间、影响范围和建议动作，避免“只报数不报因”。

常见误区：阈值长期不更新。模型上线初期表现稳定，阈值按当时分布设定，但随着客群迁移，正常波动区间已变化，旧阈值会频繁误报或漏报。建议每季度复核一次阈值，并在重大业务调整后立即重估。

四、监控报表与自动化平台：从人工到闭环

监控报表分为日报、周报、月报三类。日报聚焦数据质量和实时业务指标，适合自动化推送；周报聚焦模型稳定性和客群迁移，适合模型团队分析；月报聚焦vintage和组合风险，适合管理层决策。报表设计要遵循“一页结论、下钻明细”的原则，首页展示红黄绿状态，点击可下钻到维度明细。

自动化监控平台的核心能力包括：数据采集调度、指标计算、阈值判断、告警分发、工单闭环、历史归档。平台不应只做展示，而应把异常事件转化为工单，记录处理人、处理动作、处理结果和复盘结论，形成可追溯的整改闭环。

平台落地时，建议先跑通“采集—计算—告警—工单”最小闭环，再逐步增加报表维度和自动化根因分析。不要一开始就追求大而全，否则容易陷入“平台建好但没人用”的困境。

五、案例与复盘：一次评分PSI异常的闭环处理

某消费信贷模型在月度监控中发现评分PSI连续两期超过0.15，触发警告级告警。平台自动生成工单并通知模型负责人。初步排查发现：数据类指标中“近6个月查询次数”缺失率从3%升至12%，模型类KS下降0.08，业务类通过率上升但首逾率同步上升。进一步下钻发现，某渠道新客占比从15%升至40%，该客群查询次数普遍缺失，导致评分偏高、通过率虚高。

整改动作包括：修复该渠道数据采集链路、对缺失字段增加默认策略、对该客群单独设定阈值并重新校准评分。两周后PSI回落至0.06，首逾率恢复至基线水平。复盘结论写入工单归档，并触发阈值复核流程，将渠道维度纳入动态阈值计算。

这个案例说明：监控体系的价值不在于“发现异常”，而在于把异常转化为可执行的整改动作，并把整改结果反哺到阈值和指标设计中。没有闭环的监控，只是数据展示。

最后需要强调，监控体系不是一次性工程。随着客群迁移、产品调整和监管变化，指标、阈值和预警规则都需要持续迭代。建议建立季度监控评审机制，由模型、数据、业务三方共同参与，确保监控体系始终与风险实质保持一致。