不紧不慢的意思(不紧不慢的意思相反)

编辑导读:如今,银行和互联网大厂的和合作越来越频繁。其中,一项重要的合作是联合建模。本文作者根据自己的一次风险联合建模的经历,从中总结出一些问题,希望对你有帮助。最近雷帅慢银行着实愁坏了,行内消费信贷业务新增客户越来越少,活跃度也越来越低了。疫...

不紧不慢的意思(不紧不慢的意思相反)

  编辑导读:如今,银行和互联网大厂的和合作越来越频繁。其中,一项重要的合作是联合建模。本文作者根据自己的一次风险联合建模的经历,从中总结出一些问题,希望对你有帮助。最近雷帅慢银行着实愁坏了,行内消费信贷业务新增客户越来越少,活跃度也越来越低了。疫情长期结束不了,消费下滑经济下行,监管持续趋严,资产规模和质量都开始面临很大的增长压力。雷帅慢银行寻思,这么下去不是办法,形势再差,也要人为,得主动出击去找优质资产。怎么找,流量和质量都掌控在互联网大厂手上。于是,找到了雷帅快大厂,你把优质用户给我,我们来做款产品,一起分润。互联网公司都是在做流量变现,雷帅快大厂就爽快同意了。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同学,一定要清楚这个流程,即使他们本人还没有这些经验,也需要有人告知并提醒他们。并且保持一定频率的交流。如果你们在联合建模,或者任何建模,确保你有办法知晓更全的信息。如果没办法,我可以尽一点绵力。欢迎交流。[email?protected]原创发布于人人都是产品经理。未经许可,禁止转载题图来自Unsplash,基于CC0协议

相关推荐

推荐内容

推荐阅读