[关闭]
@vivounicorn 2021-09-08T16:21:21.000000Z 字数 16910 阅读 4931

机器学习与人工智能技术分享-第十四章 金融风控

机器学习 金融风控

回到目录


14. 金融风控应用

14.1 风控概述

14.1.1 风控在行业上的区别

不同行业的风控有不同的区别，大致区别如下图。其实大家也可以很直观的感觉到：比如，你去银行贷款，银行会让你提供各种材料，恨不得知道你祖宗八代的信息，而你去贷现金贷，恨不得提供个身份证号就给你放贷。不同业务场景下，面对的用户不同，风险不同，收益不同，在合适场景下做合适的事儿。


14.1.2 风控审批流程逻辑框架


风控是整个金融业务的核心之一，而贷前、贷中、贷后是风控切入的三个场景。风控很大的工作量就是在判断用户的还款能力（比如，授信流程）和还款意愿（比如，反欺诈流程），技术角度，目前纯基于模型去做的公司我认为没有，大部分都是规则辅以模型的方式，但这里面数据是重中之重，一般会借助于自有数据、第三方数据等。一般系统架构上会是这样：

14.1.3 风控是需要动态闭环的

风控是数据、模型/策略和监控的动态闭环，通过三要素不断迭代运转。

14.1.4 数据是风控的核心


不同的数据刻画用户不同方面，好的数据事半功倍，差的数据事倍功半。

其中：DPD：Days past due，M：month，C：cycle，从这个月还款日到下个月还款日中间的30天。
逾期相关指标是风控中非常核心的部分，直接决定了公司资产减值情况，好的风控能很好的拿捏逾期与收益之间的平衡。

14.1.5 融资租赁业务需要以风险为中心考虑收益和产品发展策略

Risk Adjusted Return on Capital：将未来可预计的风险损失量化为当期成本。

Economic Value Added：全面评价企业经营者有效使用资本和为股东创造价值的能力，是一种管理理念和企业文化。


这两个公式意味着我们需要在风险控制大框架下最大化压榨资本的剩余价值。

14.1.6 风险政策是分层级联的



风控政策（规则）是分场景分级级联的，不同场景下的策略打法不尽相同。政策制定会通过实验决定我们的投入产出比。

14.1.7 风控是以若干假设为前提的

就像所有统计或机器学习的应用一样，规则和模型都是建立在一定的建设下才能成立的。
1、空间假设——度量意义，例如，“距离”这个定义是在欧式空间下的长度、角度还是在希尔伯特空间下的长度、角度。
2、样本量假设——统计意义，例如，达到什么样的样本量规模下，产生的实验结果才是有统计意义的。
3、样本标注假设——“坏”的意义，例如，我可以假设所有到期未还款的用户为坏样本，也可以假设所有被拖车的用户为坏样本，这与具体使用场景也有关系。
4、分布一致性假设——学习意义，例如，我们会假设近期历史数据的概率分布会和未来一段时间的数据分布一致。
5、概率分布假设——函数意义，例如，我们常常会假设，数据服从高斯分布。
6、极大似然假设——求解意义，例如，我们假设求得的参数能最大程度复现已有样本是我们想要的理想模型，那么使用极大似然即是合理方法。

14.1.8 风控是个最优化问题

毫无疑问，现实当中的大部分问题都可看做最优化问题，只是复杂度不同而已。风控可以看做是在权衡通过率、花费数据成本、产生的收益、逾期坏账、用户授信额度等等诸多要求的限制下的一个优化问题。

14.1.9 风控是在不停的做实验

在我看来风控是一门实验科学，金融行业里叫冠军者挑战赛，互联网行业叫AB Test、Bucket Test，一篇经典的论文如下：《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》，是源自Google的分层实验架构，它影响了整个互联网的AB Test工程架构。


14.1.10 保证风控实验的置信度在于正确分割流量

实验要保证结果的置信度，是需要正确分割流量的，一旦不合理则实验结果无效甚至误导，比如著名的Simpson's Paradox，就是违反了分布一致性假设的典型例子，明明单独看商学院和法学院，男生录取率都远高于女生，但从整体看女生录取率却远高于男生：


也有一些基于统计的方法估计流量切分置信度，例如下面这种方法：




14.1.11 评价指标在风控中是至关重要的

风控规则和模型会涉及各种变量，例如：
1、连续型变量——价格、时间等，值域在实数域，可进行加、减、乘、除、比较等算术运算；
2、二元离散型变量——只有两种状态，如：0/1、真/假、正/负、逾期/正常、点击/未点击等；
3、顺序离散型变量——逾期状态（M0、M1……）、年龄等，值域在整数域或自然数域，可进行比较运算；
4、无序离散型变量——性别、颜色等，值域在整数域或自然数域，可完全枚举，但不能进行比较运算。

但不管什么数据源、特征、策略、模型评价，都应该以业务需求为导向、能区分用户行为为目标。

各种评价指标体系如下，实际当中合理使用即可。


14.1.12 有效监控对风控业务保驾护航

毫无疑问，各种维度的数据监控是风控业务的保镖。


14.2 风控平台架构

实践中，我们自研风控系统的目标是以平台方式提供给公司内外业务人员做配置化风险政策制定、风控模型构建和实验、风控效果监测、风控能力输出、风险客户画像等等。
一般来说，了解一个公司风控能力的强弱有这么几点：

1、对公司业务场景及一线业务的理解深度
2、数据质量及由业务规模决定的标注数据规模
3、风控系统针对业务人员的自助程度、配置快速性
4、风控模型构建、实验及应用能力
5、涉及人工审核的运营能力
6、数据化监测及分析能力

从系统研发角度，市面上其实有很多做风控系统的公司，比如：大的有FECO，小的有各个创业公司，但坦白地讲，风控能力作为保证公司长治久安和业务稳步发展的核心能力之一，有一定业务量且有技术能力的公司一定会自研，这其实也是在国内做2B业务的一个难点，但凡有能力的公司，谁也不愿意核心被人卡着，此外国内企业对2B业务的付费意愿也不足，所以我真心佩服做2B业务还能做起来的公司。

14.2.1 风控系统发展概述

一般公司的风控系统的发展可能会有这么几个阶段：


1、采购现成系统显然是貌似最省事儿的，从短期来看，可以让公司业务快速展业，这个阶段抢占业务山头是最重要的，但长远来看，可能会遇到的问题不少，比如：和现有业务贴合度不够时，需要额外定制化开发，势必会产生一系列费用，此外数据使用、模型使用、系统咨询、系统培训等等都会产生费用，当业务量起来后，再想换系统那成本就很高了。
2、当公司具有开发能力时，基于采购的系统做定制化封装也不失为一条路，但是从可维护性、成本角度来看，未来的性价比依然很低。
3、开始就具有技术能力的公司，可能会选择基于开源框架做自研，好处是可控性和业务贴合度都比较好，但做技术的人都知道，当你基于一套开源框架想干好活儿时，你需要熟悉整个框架。举个例子，风控政策制定是业务强需求，那么系统必须支持规则配置和解析，于是很多公司会使用开源规则引擎，例如DRules，实际上你需要的可能只是它的一部分功能，但如果不对整个框架熟悉，未来出了线上问题你可能哭都没地儿去；更糟糕的是，不是每个团队成员都熟悉开源框架，当人员离职后可能带来系统上的风险。

所以只要有能力，我们会选择全套纯自研，进而迈向云端平台化，未来还可能成为一个技术盈利点，比如我们的很多线下合作渠道没有技术人员又想做自己的风控，乐观情况下，我们可以开个账号做个配置就能实现风控能力输出。

14.2.2 风控系统架构

其实万事万物都有其相通性，尤其在系统架构上，在我看来，广告投放系统、推荐系统与风控系统具有极高相通性，比如，系统需要有够好的稳定性、容错性（包括防雪崩）、扩展性、并发性（包括服务降级）、对算法的支持性、标准化日志、权限控制、实时数据采集、数据可视化、数据统计、指标监控、自动化运维等等，由于我们之前恰好都做过，整体架构类似云原生，比如大体可以有以下架构：



1、统一的日志格式及服务，这个是要放在首位设计的，这里的统一体现在几个方面：

  • 统一的日志格式规范，每一个字段、每一个嵌套关系、每一个扩展段等等都有严格的规范定义，技术选型方面采用ProtoBuf，这样将来对日志的解析可以采用一套方法，管理方便且不容易出错，例如：
    syntax = "proto2";
    package pb_interface.fintech;
    import "pb_interface/fintech/*/*.proto";
    import "pb_interface/fintech/**/**.proto";
    import "pb_interface/fintech/***/***.proto";
    import "pb_interface/fintech/****/****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    import "pb_interface/fintech/*****/****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    import "pb_interface/fintech/*****/*****.proto";
    message FinTechPbLog{
    required string pbLogId=1; //log唯一标识
    required string createTime=2; //生成时间
    required string serveName=3; //服务名称
    optional int32 errCode=4; //返回码:0正常,非0异常
    optional string errMsg=5; //返回描述
    optional pb_interface.fintech.*.* *=6; //主引擎服务日志
    optional pb_interface.fintech.**.** **=7;//规则引擎服务日志
    optional pb_interface.fintech.***.*** ***=8; //数据处理服务日志
    optional pb_interface.fintech.****.**** ****=9;//配置更新服务日志
    optional pb_interface.fintech.***.*** ***=10; //引擎回调服务日志
    optional pb_interface.fintech.*.** ***=11; //数据源指标字段日志
    optional pb_interface.fintech.**.** **=12;//指定名单服务日志
    optional pb_interface.fintech.*.** **=13;//图像处理服务日志
    optional pb_interface.fintech.**.** **=14;//明细服务日志
    optional pb_interface.fintech.**.** **=15;//inference服务日志
    optional pb_interface.fintech.***.** ***=16;//异步交互服务日志
    }

  • 统一的采集、解析、分析、展示方案，包括提供给算法团队的特征字段，这样在使用层面极大地方便了自己和降低出问题的概率。

  • 统一的监控展示方案，对应用系统涉及的从前到后的一系列交互统一做监控，能够对每个请求的今生来世做到一通贯穿。
  • 统一的数据安全方案，包括脱敏方案、提取流程、加密方案、反显方案等，做到分层分级安全可控。

2、统一的版本及权限控制，包括以下几个方面：

  • 代码版本需要有一套管理流程，代码提交前必须做交叉Code Review
  • 所有的风控模型也需要做类似的版本管理，任何一个模型的特征、权重、参数、分流情况等都需要控制到
  • 对接入风控的业务系统做统一的接口认证和鉴权控制
  • 对使用系统的用户做统一的分组权限控制

3、风控对接系统

  • 对接业务系统服务，采用标准化的RESTful接口对接所有业务系统，由于受限于数据源的获取速度，所以风控审批执行会同时支持同步模式和异步模式
  • 业务配置服务，除非新增数据源，否则所有风控政策制定都采用可视化配置方式实现，无需代码开发，且实时生效。对于风控模型使用也是类似的逻辑，只要基本的特征数据没有增加，都以配置方式实现模型应用。



4、AB Test服务

  • 大的方面支持订单粒度和用户粒度随机或有策略AB，细的方面支持用户的灵活分组，例如：年龄、地区等以及这些条件的交叉
  • 每个分组的实验量必须具有统计意义，测试时间要足够，并明确每个实验的从前端到后端的全路径
  • 同一个用户在相同分流策略下可重入，不会出现一个用户一会儿审批通过一会儿审批拒绝，否则不仅用户体验差，还会招来用户投诉
  • 由于汽车的客单价比较高，实验表现期很长，所以每次实验要做到尽量降低实验成本，尽可能的利用历史数据
  • 所有实验都是可视化实时配置且有相应实验运营后台，展示每个实验的详细情况
  • 离线日志回放，每做一个新模型，能够将历史样本批量回放，一定程度模拟真实场景效率和效果表现

5、风控主服务

  • 初始化全局环境、串流程，调度和组合各个微服务的功能
  • 针对同步或异步场景对业务系统返回结果或做异步回调

6、规则解析服务

  • 平台在设计时，业务流程和业务规则是完全分开不耦合的，所以规则解析服务只负责解析、检查和执行规则。在风控领域，政策规则的特点是：有大量规则（甚至规则的模式间有一定重复性），但变化并不那么多。而开源的类似Drools的框架，虽然基本能满足需求但一方面随着业务的复杂性越来越高，管理起来越来越费劲，另一方面它实在太重了，学习、维护成本高还不能从架构层面锻炼队伍。
    所以我们干脆以RETE算法（论文见：Charles Forgy的 《Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem》.）及编译原理的语法分析树解析算法为蓝本自研。
  • 在操作符方面，针对风控业务，至少需要支持：
    • &&
    • ||
    • !
    • null判断
    • ==/!=
    • in/not in
    • 包含/不包含
    • 前/后缀等
  • 在管理模式方面，至少需要支持：
    • 规则集合管理
    • 规则优先级
    • 规则互斥
    • 规则依赖
    • 规则循环
    • 规则有效期
    • 规则缓存等
  • 在取值管理上，至少要支持：
    • 常量
    • 变量
    • 自定义公式
  • 在服务部署和响应上，服务横向扩展、解析可以并行执行；单规则解析响应时间在整个规则执行耗时上要做到占比小于99.9%，实际当中，特征取数占执行时间的大头，规则解析时间忽略不计

7、Inference服务

  • 一系列微服务，实现y=f(x)的特征取数和计算。需要支持：
    • XGBoost/LightGBM（ATM类模型）
    • Logistic Regression
    • MLP及DeepFM类前向传播
  • 记录时点特征日志、inference日志和模型计算结果

8、关联及反欺诈服务

  • 在风控场景下，用户的申请能否通过，主要衡量两方面：
    • 用户的还款能力
      还款能力与国家经济情况、用户个人经济情况、家庭突发情况等有关系，可以围绕着用户的属性数据和消费行为数据做刻画
    • 用户的还款意愿
      真正影响公司资产质量的是对用户还款意愿的预判及用户是否会发生欺诈。欺诈行为往往不是个体行为，对于像汽车这样的大宗消费品，如果发生团体欺诈，损失可想而知。
  • 关联反欺诈，根儿上主要还是依赖能够拿到的数据，做法上大致有两大类方法：
    • 想象每个用户是一个圆点，每个实体（如某4s店、某银行）是个方点，圆点和圆点或圆点和实体之间的边是关系或行为，利用图算法可以查找异常聚集、多度的多头借贷等
    • 类似广告的look-alike，分析已有的欺诈种子用户，找到和他最类似的用户等

9、在线数据服务

  • 特征数据及实时数据服务，主要负责几个方面：
    • 离线生成的特征数据在线使用，风控模型中有一类特征是通过离线挖掘生成后导入线上的，这类特征大部分是T+1特征及月、季度、年时间范围特征
    • 反馈类特征数据在线使用，这类特征主要与用户行为有关，例如，某个渠道当天进件量，配合实时数据采集服务，这类特征需要伪实时或实时更新
    • 模型权重数据在线使用，包括离线模型权重和online learning模型权重。在机器学习相关工程应用中，特征的online更新（用的更多）和模型的online更新都可以起到捕捉实时数据概率分布的作用，可单独使用也可结合使用，但特征或权重监控必须做到位
  • 数据缓存服务，承担各类数据的缓存工作
  • 数据监控服务，主要监控以下几类：
    • 特征监控：监控特征分布是否有大波动、缺失特征是否有大波动等，例如，由于系统bug导致某个特征大量缺失，通过监控立刻报警并熔断
    • 权重监控：监控模型权重分布是否有大波动、权重重要性排序是否有大波动等，例如，在online learning（如：FTRL）中，本就使用类似SGD方式更新权重，虽然有L2正则在一定程度上帮助稳定权重更新，但依然无法避免权重可能学飞掉，所以有效的监控很重要，一旦波动过大就做一次批量样本的模型修正
    • 卡单监控：全流程描述一个单子从提报到生效的全链路，可视化的告诉运营和开发人员，单子到哪儿了，卡那儿了，由于全流程往往需要多个独立系统互相配合，所以开篇讲到的统一日志设计的重要性不言而喻
    • 运维监控：对系统做接口粒度监控，流量如何、响应时间如何等
    • 业务指标监控：监控核心业务指标，例如，实时自动审批率表现如何

10、实时数据采集服务

  • 外部合规数据接入服务，由于一家公司的数据积累毕竟有限，所以风控业务开展往往需要采购第三方数据：
    • 采购时首要考虑数据是否为一手数据、数据是否合规合法、获取时用户是否知晓且主动授权等
    • 其次考虑数据的覆盖率如何，例如，人群覆盖率
    • 然后考虑数据在风控政策或风控模型上的贡献度
    • 最后是商务谈判，这一步一定要有技术参与，尽可能保证数据接入标准化，方便接入服务，以上完成后，外部数据的接入从时间和质量上都会可控
  • 提报业务数据，采集销售或用户在提报时录入的信息
  • 用户及渠道行为数据，采集用户或者渠道业务时点的行为，例如：某个用户在几个渠道下过单，某个渠道当前进件量是否异常等

11、模型一键发布及数据导入服务，连接线上与线下的桥梁，导入效率要够高，对大数据量以mapreduce方式支持集群数据导入

  • 模型一键发布服务，管理和发布离线训练好的模型，可将模型一键发布到测试、UAT、生产等环境
  • 数据导入服务，将离线特征数据及其他必要数据导入线上

12、机器学习平台

  • 广义来说，整个风控平台就是个机器学习平台，同时包括离线和在线服务
  • 狭义来说，包括离线日志处理、数据标注、特征分析与提取、模型Pipline离线训练、模型测试验证、日志回放模拟、模型剪枝和压缩等等。我们把以上步骤封装成各种机器学习组件，一定程度上，用户不需要写代码，而是采取可视化、拖拽方式建模。

总的来说一套成熟的风控平台需要多年的技术打磨，以平台方式而不是软件方式打造，一方面要保证不被点状的需求带偏，另一方面重视业务通用性和使用体验、最后设计时要有一定高度，以适应未来未知的挑战。

14.3 风控建模方法

金融的本质是基于信用风险的生意，而金融天生又是厌恶风险的，不管是为有钱人理财还是为缺钱人融资。所以要做好这个生意，需要：

  • 尽量保证资产的安全，毫无疑问，这个是金融的基石但不是唯一目标
  • 尽量保证资源的最优化配置，不同机构最优化的目标不一样，比如，可以是企业利益最大化，或者兼顾社会责任等

虽然现在互联网金融一地鸡毛，但是从互联网行业（计算广告、智能推荐等）继承而来的建模方法和系统思维，私认为是远领先于传统金融机构的。

14.3.1 建模概述

风控建模的目的主要有：

  • 通过完备的理论将风险数据化，减少主观性，把过去依靠“经验”的授信变成数据化的授信，把判断过程中的物料全部数据化落地存储，做到有根有据、可查可追
  • 提高最优化资源配置能力，将风险考量放入到衡量公司每个项目的盈利能力中，风控一定不是一味地降低风险，而是tradeoff风险和收益
  • 提高运营效率、降低运营成本，显而易见，全自动的审核速度是秒级甚至毫秒级的，而人工审核是几分钟级、十几分钟甚至小时、跨天的。当然，现阶段受限于能够获取的数据规模和质量，人工审核依然必不可少，但风控建模依然可以很好的去辅助人工审核。

一般来说建模有以下几个步骤：


14.3.2 需求分析与目标定义

14.3.3 数据准备

规范化对数据分层、分主题管理，确定建模需要什么数据，这些数据从哪儿来放在哪儿了，字段含义是什么，缺失情况如何，是否能够直接使用，能回溯多久等等一系列数据需求，数据需要以统一模式存储和管理，体系化做数据积累，不要来一个项目做一个。
一般采用数据仓库+数据集市方式管理，架构如下：


其实这一步是贯穿公司数据管理整个过程的，建模只是受益方之一，机器学习领域成熟的模型足够多，但如果没有好的数据体系保证质量，往往事倍功半。
一般来说，风控数据来源主要有三部分：

  • 以订阅方式获取的业务数据，例如：用户进件时的用户信息、车辆信息、融资信息
  • 以采集方式获取的行为数据，例如：某个渠道、某些地域的进件行为、用户群申请行为
  • 以购买方式获取的合规数据，例如：中国人民银行征信数据

1、Stage层，所有数据通过数据总线以既定的规范分主题接入，这一层是最原始的数据，原则上不对外提供服务。
2、ODS层，对Stage层数据做不带业务逻辑的加工和清洗，为将来抽象到上一层做准备，同样原则上不对外提供服务。
3、MDS层，原则上所有业务需求涉及的数据都应该能得到满足，这一层会分层、分主题的做数据加工，数据要尽可能复用。
4、公共主题，所有经过业务逻辑处理的、定义明确的、口径一致的可公共使用的数据会放在这一层，例如，用户的基本信息，年龄、性别、唯一标识等。
5、垂直集市，基于MDS数据，加工并抽象出来的某个垂直业务主题的数据，这层可认为是此业务主题下的标准数据，例如：名为dm_risk_secondhand_nobehavior_features_116_v1 的宽表为风控二手车业务场景下针对白户的v1.0含有116个特征的数据集合

14.3.4 数据标注

数据标注是数据准备里的一部分，这里单独拿出来做强调，它是风控建模里的一个难点和重点。目前工业应用里最多的还是监督学习supervised learning，需要对数据做样本标注，对分类问题，标注样本的目标类别，对回归问题，标注样本的目标值。
一般来说，对于正常业务量的汽车金融公司，以36期为主要产品的话，早期模型应用会较少（从已经有大量数据积累的场景transfer过来的模型除外），因为数据量级和数据表现都不充足，公司展业三年后开启模型应用之旅。
先介绍几个风控常用的指标和数据标注方法，会影响到样本选取和数据标注，进而影响风控建模质量或基于IFRS9的预期损失准备金拨备：

14.3.5 拒绝推断

风控与广告、推荐搜索有一个类似的问题，即幸存者偏差（Survivorship Bias），以广告CTR预估为例：影响其预估准确性的因素是AUC(Ads、User、Context)，建模中能被使用的样本是由有机会曝光的广告产生的，显然数据必然会有偏；此外不同的广告位产生的样本也会有位置偏差，在顶通栏的广告一定比在底通栏的更有机会被用户看到，从而被点击。所以最无偏的情况是每个广告对每个用户在每个上下文环境(如：位置、时段)下都曝光一次，之后看用户反应，但从经济成本、可行性等方面看显然不现实，所以广告会采用E&E的方式，边给曝光机会边探索，通过实时流采集投放效果(感知)并动态评价(决策)，总之是以一定成本尽可能让平台利益最大化(如：最大化eCPM)。
但对风控来说，最大的问题是用户逾期的滞后性及客单价。对现金贷场景可能还好些，可以先通过放款小额度贷款去试用户，但对汽车金融等大额消费贷场景就不行了，只能折中使用拒绝推断，尽可能的利用已有数据。


拒绝推断有很多种方法，不过实践当中我们认为最有效的还是Parceling，它有很多变体，举一个常用的方法：


例如：


1、利用”通过样本“训练”模型1“
2、按照置信度对”通过样本“做9个分组，置信度越高逾期率越低；
2、对每个分组统计”实际逾期率“及相应样本总数
3、利用”模型1“对”拒绝样本“做inference，同样按照置信度从高到低分9组
4、对每个分组统计样本总数，根据该组的逾期率，抽样得到”推断坏样本“，剩余的为”推断好样本“
5、合并”通过样本“和”推断好、坏样本“
6、训练”模型2“
总的来说，使用拒绝推断方法一方面可以部分修正训练数据的数据分布，让模型表现的更加稳定，泛化性更强；另一方面充分利用了历史数据，节省未来线上实验的成本。

14.3.6 风控建模

1、基本框架
风控建模的方法和广告、推荐及搜索的建模方法没区别，只是整体会更加保守些，因为风控这个业务很注重可解释性，表现在以下两个方面：

  • 对风控业务可解释
    找到影响风险水平的原因，可以有的放矢的调整业务走向，例如，发现地区+车型组合特征对逾期率模型贡献高，则可进一步看哪个地区哪个车型，然后做业务判断。
  • 对销售业务可解释
    例如，在前端业务发生拒单时，帮助销售向客户解释原因；销售利用可解释的模型变量，有的放矢的和用户面聊，帮助控风险。

一般的建模框架如下：


与传统机器学习类似，数据及特征准备耗费80%以上建模时间(即使使用AutoML框架辅助特征发现)，而模型方面，由于对可解释性的强烈需求及实际建模效果，早期的baseline是Logistic Regression，现在的baseline是Additive Tree Models(如，各种版本GBDT模型、RF模型，详情可见《建模方法回顾-Additive Tree Models》)。
需要说明的是，深度学习模型，诸如：

虽然在风控特征自动发现方面可以起到一定作用，但并不那么适合风控建模，一方面是金融领域并没有那么大的标注数据，而深度学习模型在数据量足够大时才有明显优势，另一方面就是可解释性太差了。

2、效果评价指标
风控建模本质上也是个排序问题，是更智能的狗熊掰棒子，同样也容易出现正负样本分布很不平衡问题(尤其是欺诈问题)，类似广告、推荐和搜索。

3、阈值选择
在风控审批场景中，大体会有三种处理方法：

  • 自动通过
    当模型或策略规则，输出很高的通过置信度时，则认为用户大概率不会逾期，此时一般会让进件直接通过，这样前端的时效性和用户体验会很好。
  • 自动拒绝
    当模型或策略规则，输出很高的拒绝置信度时，则认为用户大概率会逾期，此时进件一般会被直接拒绝，尤其是触碰红线的用户，则一票否决且不允许召回。
  • 转人工审核
    介于通过与否的置信度不那么高的用户，会依据人力情况被转到人工审核岗，之后通过电话、面聊等方式决定是否准予通过。

但由于风控模型输出的置信度是个概率值或连续值，所以需要通过做阈值截取得到以上三种结果。
例如，我们做自动拒绝判定(自动通过的逻辑与下面方法类似，不再赘述)，除了考虑业务量、人力情况等因素外，还需要考虑经济收益，即：我们希望被自动拒绝的订单尽可能多的是”坏“客户，尽可能少的是”好“客户，每拒绝一个”坏“客户，会挽回一单经济损失，而每拒绝一个”好“客户，会丢失一单经济收益，所以确定自动拒绝置信度的阈值要通过算法方式合理设定。
假设：

  • 训练了一个某场景下预测M1逾期率的模型，每一个订单的NPV值(或IRR值)已知，需要确定阈值以尽可能拒绝”坏“用户，让整体收益最大化；
  • 有一条曲线是描述拒绝”坏“客户后挽回的经济损失，另一条曲线是拒绝一个”好“客户后丢失的经济收益；
  • 横坐标是拒绝用户占总用户的比例，纵坐标是累积的平均NPV(IRR)值

那么：

  • 如果模型特别差，所有好样本置信分都低于坏样本置信分，意味着下图：


  • 如果模型特别好，所有好样本置信分都高于坏样本置信分，意味着下图，最优拒绝阈值是让两条曲线间距最大的点(有点类似KS值)：


  • 正常应用的模型，例如AUC达到0.8以上，大部分好样本置信分都高于坏样本置信分，意味着下图，同样，最优拒绝阈值是让两条曲线间距最大的点(有点类似KS值)：


最终确定的拒绝阈值会根据业务量、风险敞口大小、人力情况等因素，在这个最优点附近调整。

14.4 风控模型监控

模型监控大概包括几部分：监控模型训练和测试指标、监控模型在线应用时的指标、监控业务关心的指标。

14.4.1 离线模型监控

监控多次训练和测试模型本身的指标，包括不限于：

  • 标注数据分布稳定性
    正常情况下，每个建模周期（如，每天、每月）的正负样本标注数据应该是稳定的，例如，某个周期同样量级且表现充分的样本中突然多出大量负样本。
  • 特征稳定性
    包括每个特征的缺失率、样本覆盖率、权重PSI值、特征重要性排序等。
  • 置信分稳定性
    置信度分数变化趋势、每个置信度范围覆盖的人群和模型指标都应该是稳定的。
  • 人群分布稳定性
    每个决策区间（如，拒绝、通过、转人工）下的人群数应该是稳定的。
  • 模型指标稳定性
    模型训练及测试集中的：AUC、ACC、Recall、F1、Precision、决策点置信度分值等都应该是稳定的。

14.4.2 在线模型监控

  • 在线特征稳定性
    监控模型线上用到的特征实时分布是否与离线没有大的差距。
  • 在线评分稳定性
    置信分输出趋势是否稳定，各个决策区间下的人群是否稳定等。

14.4.3 业务监控

  • 每个模型AB后的进件量、自动通过、拒绝、转人工量/率监控
  • Vintage及滚动率监控
  • 各级逾期率监控
  • 模型特征花费监控
  • 业务达标率监控
    ......
添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注