3. 模型异常概述
在信贷风控体系中,模型异常并不是一个孤立的技术故障,而是模型输出与业务预期、监管要求或统计规律发生显著偏离的状态。很多团队在遇到异常时,第一反应是“模型坏了,赶紧重训”,但真正的问题可能出在数据链路、客群迁移、策略耦合甚至外部欺诈攻击上。因此,建立一套清晰的异常认知框架,是后续根因定位与整改闭环的前提。
一、异常的定义:偏离基准且具备业务含义
从工程视角看,模型异常是指模型在监控周期内的关键指标超出预设阈值或历史稳定区间。但从风控视角看,仅有统计偏离还不够,必须同时满足“可解释的业务影响”才值得启动根因定位。例如,某评分卡PSI从0.02升至0.08,若客群本身发生正常季节性变化,可能只是提醒;若同时伴随通过率骤降、逾期率上升,则构成实质性异常。
核心公式:模型异常 = 指标偏离 × 业务影响 × 可复现性。三者缺一,优先级都应下调。
二、异常分类:按来源与影响维度拆分
为了快速定位,建议将异常分为四类,每类对应不同的排查入口:
| 异常类别 | 典型表现 | 常见根因方向 | 排查优先级 |
|---|---|---|---|
| 数据异常 | 缺失率飙升、字段分布突变、主键重复 | 上游埋点变更、ETL延迟、口径不一致 | 高 |
| 模型异常 | PSI超限、KS下降、评分分布偏移 | 客群迁移、特征失效、过拟合 | 高 |
| 策略异常 | 通过率骤变、额度集中、拒绝原因堆叠 | 规则冲突、阈值误配、模型与策略耦合 | 中 |
| 外部异常 | 多头突增、设备聚集、地域集中 | 欺诈攻击、渠道污染、黑产试探 | 中高 |
分类的价值在于:它决定了你第一步是查数据、查模型、查策略还是查外部情报。很多团队把策略异常误判为模型异常,导致重训后问题依旧。
三、异常表现:从监控指标到业务信号
异常表现通常分为三层:
- 统计层:PSI、KS、AUC、评分均值/方差、特征缺失率、IV值突变。
- 策略层:通过率、拒绝率、额度使用率、定价分布、人工复核率。
- 业务层:首逾率、FPD、DPD、回收率、投诉量、渠道进件量。
三层之间存在传导关系。例如,数据层缺失率上升 → 模型层评分偏移 → 策略层通过率下降 → 业务层进件量减少。定位时不能只看最终业务指标,而要沿着传导链逐层回溯。
# 典型监控日志片段
[2024-06-01 08:00:00] model_psi=0.021 status=OK
[2024-06-02 08:00:00] model_psi=0.087 status=WARN
[2024-06-03 08:00:00] model_psi=0.153 status=ALERT
[2024-06-03 08:00:00] feature_missing_rate=0.34 threshold=0.10
[2024-06-03 08:00:00] approval_rate=0.18 baseline=0.42
当PSI连续三天上升且缺失率同步恶化时,优先怀疑数据链路,而非模型本身。
四、异常与风险事件的关系:不是所有异常都等于风险
异常是“偏离”,风险事件是“已造成或可能造成损失”。二者关系可概括为:
- 异常未必是风险事件:如节假日进件量下降导致评分分布偏移,属于正常波动。
- 风险事件往往伴随异常:如欺诈攻击导致多头指标突增,通常先表现为外部异常。
- 异常是风险事件的早期信号:监控的价值在于把风险事件拦截在损失发生之前。
建议在监控体系中设置“异常—预警—事件”三级升级机制:异常自动记录,预警触发人工复核,事件启动根因定位与整改闭环。
五、常见触发场景与复盘误区
以下场景在信贷模型中高频出现,值得作为排查清单:
- 上游数据口径变更:如收入字段从“税前”改为“税后”,导致评分整体下移。
- 客群结构突变:渠道切换、营销活动带来大量低质量进件。
- 特征时效性失效:如某三方数据源停更,特征值长期不变。
- 策略与模型耦合:模型分被硬编码进规则,阈值调整后未同步更新。
- 外部欺诈攻击:设备指纹聚集、IP异常、申请时间集中。
常见误区:一看到KS下降就重训模型。实际上,若根因是数据缺失或策略冲突,重训只会掩盖问题,甚至引入新的过拟合风险。正确顺序是:先确认数据质量,再验证模型稳定性,最后才考虑迭代。
复盘时建议回答三个问题:异常首次出现的时间点是什么?当时有哪些同步变更?如果回滚变更,异常是否消失?这三个问题能快速缩小根因范围,避免在错误方向上消耗大量人力。
六、核心方法流程:从发现到定级的闭环起点
异常概述的最终目的是为根因定位提供输入。建议采用以下五步流程:
- 发现:通过自动化监控捕获指标偏离。
- 确认:排除数据延迟、计算错误等假阳性。
- 分类:按数据、模型、策略、外部四类归因。
- 定级:结合业务影响面与紧急程度确定优先级。
- 触发:进入根因定位与整改闭环流程。
本章的核心结论:异常不是故障的同义词,而是需要被分类、定级和传导分析的业务信号。只有先建立统一的异常语言,后续的根因定位才不会变成“谁声音大谁有理”的扯皮。