一次风控联合建模,我总结出了这些

最近雷帅慢银行着实愁坏了,行内消费信贷业务新增客户越来越少,活跃度也越来越低了。疫情长期结束不了,消费下滑经济下行,监管持续趋严,资产规模和质量都开始面临很大的增长压力。

雷帅慢银行寻思,这么下去不是办法,形势再差,也要人为,得主动出击去找优质资产。

怎么找,流量和质量都掌控在互联网大厂手上。

于是,找到了雷帅快大厂,你把优质用户给我,我们来做款产品,一起分润。

互联网公司都是在做流量变现,雷帅快大厂就爽快同意了。

win-win。

那快大厂怎么把优质用户给慢银行呢?

快大厂虽然自己也做消费信贷业务,也有内部风险评分。但风险是由用户和产品决定的,慢银行想要的是适合他们产品的优质用户,快大厂的优质用户虽然不错,但不是最优。

这就是合作中最重要的一环,联合建模

慢银行提供一批有风险表现的用户给快大厂去匹配特征,风险是慢银行的,特征是快大厂的。

由慢银行同学去建模,有了模型之后就可以对快大厂的流量做精准风险评估了。

一般来说,谁用模型谁建模。

于是慢银行和快大厂分别成立了一个小组,两方各自指定了个负责人,专项对接该模型开发工作。

一、立项会议

小组成立之后,马上开了一次语音会议,聊这个模型怎么建。

两方负责人先拉了个微信群,把慢银行和快大厂这次联合建模相关的人员都拉进去了。

慢银行一堆问题就跟机关枪一样发射了,

  • 你们有多少特征,能回溯到什么时候?
  • 需要用什么主键去匹配特征?
  • 你们的数据能不能传给我们,我们直接在行内建模?
  • 我们要建xgb模型,你们xgb模型怎么部署?
  • ……

快大厂不爽了,你们急个毛线,

  • 我们数据多着呢,近两年都可以回溯,身份证和手机号做主键,我们上千个特征不出库,我们准备好电脑和建模环境,你们带着标签过来。
  • 你们准备多少样本建模,最好多带点?
  • 你们自己怎么定义标签的?
  • 你们准备建几个模型,输出几个字段?

一来二回,都觉得对方不给力。

慢银行嫌快大厂特征数据不出库,还要他们派模型同学驻场建模。

快大厂嫌慢银行能带出的样本太少了,建模效果不好的话还要怪数据质量。

但好歹,一些事情还是确定下来了。

慢银行指定了一个模型同学(慢A),快大厂也指定了个同学(快B)。

然后,慢A去准备建模需要的10w样本,走申请流程带出。

快B就去准备了两台电脑,搭建建模环境。

二、数据准备

慢A同学在慢银行苦心经营,找了许多人开了许多会,终于确定了如何选取这10w样本。

又潜心写了几行代码抽取这些样本,还请同事帮忙review一下这几段sql。

然后走起了漫无边际的审批流程,匹配加密的主键,样本出库等。

这个时候的慢A觉得自己是张骞。

此时,快B同学在快大厂申请了两台旧电脑,确保了无网络访问权限,然后安装了下必备的Python包。

然后开始准备怎么做都有问题的特征,从特征库里选择了几张合适的稳定有效的特征表,开始做一些脱敏处理。

变量的值要脱敏,例如分段处理,变量的含义也要做脱敏,巴不得改名为变量1、变量2……。

无所不用其极,这个时候的快B觉得自己是SB。

最后,还要计算变量的分布,确保分段处理后的变量分布逐月稳定且合理。

三、无穷无尽的拉扯

许多天以后,慢A终于准备好了样本,快B被慢银行骂了几次SB后,变量的含义还是没改,不过加了一个维度列。

这些加密的主键被发送到快B,匹配了早已不知道是什么的特征。

终于,慢A带着这10w个好坏样本,不情不愿地来到了快大厂的所在地,快B给安排了工位,电脑桌面放好了10w个样本的匹配结果。

慢A开始了无脑的数据分析,统计了数据的匹配情况,对着f1、f2……的特征强压着内心的怒火。

在旁边拿出了自己带来的电脑,连上热点,开始了百度一下。

找出了早已备好的计算woe、iv的代码块,对着所有的变量跑了一通,筛出了一些区分度高的变量后,又看了他们的风险分布。

问天,这个单增的变量是不是应该单增;问地,这个单减的变量是不是应该单减;问自己,这个U型分布变量是个什么鬼。最后问快B,快说,我有刀。

时间无情的流逝。

模型终于建好了,慢A算了几个KS,不由得想骂人,怎么有点低,怎么波动这么大。

找快B,找慢银行,多方讨论,也没有什么高招,只好就这样。

然后定了个阈值做了一些业务指标的测算,出了一个报告。

慢A把成果发送回了慢银行,进行了远程汇报……

最后,模型就这么定了。

这个阶段慢A很烦躁。

四、模型部署

慢A把模型文件和模型变量交给快B之后,就逃也似的离开了快大厂。

此时的快B觉得气定神闲,上线过很多个模型之后,谁还会把这这当回事呢。

然后不紧不慢地打开了慢A给的文件,差点没吐血。

这些变量咋还被再次处理了,给的变量都被分段好了,还合并分组干什么,不知道xgb是二叉树嘛。

怎么入模了这么多变量。

模型文件一解析,又发现这树怎么长这样,这xgb参数也太扯淡了。

快B大叫一声不好,一个电话打给了慢A,慢A说有些变量分组人数太少就合并了,参数是网格搜索找出来的。

快B很吐血,这意味着,要多一层特征处理作业,这一步很容易出错。另外,模型打分作业耗时久,需监控的变量多。

因为徒增了这些工作,重要但不紧急的模型部署变成了重要又紧急的todo。

但好歹,模型文件给到了快大厂,离线打分总远远好于实时打分。

模型终于被部署好了,并经过了一致性校验。

这个阶段快B很暴躁。

五、我说

有件事情特别重要,而很多建模的同学并没有意识到。

离线打分再把分数推送至线上接口,会比推送特征线上实时计算分数容易地多。

前者,模型复杂度就不太重要,计算作业再耗时也不是什么大问题。

但后者,就注定不能用太多变量,不能让模型过于复杂,因为推送几百个特征至线上是很困难的,保证接口响应速度是很吃资源的,验证分数的一致性也是更不容易的。

这决定了你如何去做特征工程,如何去训练模型。

所以,最为要紧的事情是,在启动建模前就必须想清楚最终将如何上线应用。

负责建模的A和B同学,一定要清楚这个流程,即使他们本人还没有这些经验,也需要有人告知并提醒他们。

并且保持一定频率的交流。

如果你们在联合建模,或者任何建模,确保你有办法知晓更全的信息。如果没办法,我可以尽一点绵力。欢迎交流。

 

本文作者@雷帅

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部