一次联合建模分析
共 2666字，需浏览 6分钟
·
2021-09-27 20:43
最近雷帅慢银行着实愁坏了，行内消费信贷业务新增客户越来越少，活跃度也越来越低了。
疫情长期结束不了，消费下滑经济下行，监管持续趋严，资产规模和质量都开始面临很大的增长压力。
雷帅慢银行寻思，这么下去不是办法，形势再差，也要人为，得主动出击去找优质资产。
怎么找，流量和质量都掌控在互联网大厂手上。
于是，找到了雷帅快大厂，你把优质用户给我，我们来做款产品，一起分润。
互联网公司都是在做流量变现，雷帅快大厂就爽快同意了。
win-win。
那快大厂怎么把优质用户给慢银行呢？
快大厂虽然自己也做消费信贷业务，也有内部风险评分。但风险是由用户和产品决定的，慢银行想要的是适合他们产品的优质用户，快大厂的优质用户虽然不错，但不是最优。
这就是合作中最重要的一环，联合建模。
慢银行提供一批有风险表现的用户给快大厂去匹配特征，风险是慢银行的，特征是快大厂的。
由慢银行同学去建模，有了模型之后就可以对快大厂的流量做精准风险评估了。
一般来说，谁用模型谁建模。
于是慢银行和快大厂分别成立了一个小组，两方各自指定了个负责人，专项对接该模型开发工作。
01
立项会议
小组成立之后，马上开了一次语音会议，聊这个模型怎么建。
两方负责人先拉了个微信群，把慢银行和快大厂这次联合建模相关的人员都拉进去了。
慢银行一堆问题就跟机关枪一样发射了，
你们有多少特征，能回溯到什么时候？
需要用什么主键去匹配特征？
你们的数据能不能传给我们，我们直接在行内建模？
我们要建xgb模型，你们xgb模型怎么部署？
……
快大厂不爽了，你们急个毛线，
我们数据多着呢，近两年都可以回溯，身份证和手机号做主键，我们上千个特征不出库，我们准备好电脑和建模环境，你们带着标签过来。
你们准备多少样本建模，最好多带点？
你们自己怎么定义标签的？
你们准备建几个模型，输出几个字段？
一来二回，都觉得对方不给力。
慢银行嫌快大厂特征数据不出库，还要他们派模型同学驻场建模。
快大厂嫌慢银行能带出的样本太少了，建模效果不好的话还要怪数据质量。
但好歹，一些事情还是确定下来了。
慢银行指定了一个模型同学（慢A），快大厂也指定了个同学（快B）。
然后，慢A去准备建模需要的10w样本，走申请流程带出。
快B就去准备了两台电脑，搭建建模环境。
02
数据准备
慢A同学在慢银行苦心经营，找了许多人开了许多会，终于确定了如何选取这10w样本。
又潜心写了几行代码抽取这些样本，还请同事帮忙review一下这几段sql。
然后走起了漫无边际的审批流程，匹配加密的主键，样本出库等。
这个时候的慢A觉得自己是张骞。
此时，快B同学在快大厂申请了两台旧电脑，确保了无网络访问权限，然后安装了下必备的Python包。
然后开始准备怎么做都有问题的特征，从特征库里选择了几张合适的稳定有效的特征表，开始做一些脱敏处理。
变量的值要脱敏，例如分段处理，变量的含义也要做脱敏，巴不得改名为变量1、变量2……。
无所不用其极，这个时候的快B觉得自己是SB。
最后，还要计算变量的分布，确保分段处理后的变量分布逐月稳定且合理。
03
无穷无尽的拉扯
许多天以后，慢A终于准备好了样本，快B被慢银行骂了几次SB后，变量的含义还是没改，不过加了一个维度列。
这些加密的主键被发送到快B，匹配了早已不知道是什么的特征。
终于，慢A带着这10w个好坏样本，不情不愿地来到了快大厂的所在地，快B给安排了工位，电脑桌面放好了10w个样本的匹配结果。
慢A开始了无脑的数据分析，统计了数据的匹配情况，对着f1、f2……的特征强压着内心的怒火。
在旁边拿出了自己带来的电脑，连上热点，开始了百度一下。
找出了早已备好的计算woe、iv的代码块，对着所有的变量跑了一通，筛出了一些区分度高的变量后，又看了他们的风险分布。
问天，这个单增的变量是不是应该单增；问地，这个单减的变量是不是应该单减；问自己，这个U型分布变量是个什么鬼。最后问快B，快说，我有刀。
时间无情的流逝。
模型终于建好了，慢A算了几个KS，不由得想骂人，怎么有点低，怎么波动这么大。
找快B，找慢银行，多方讨论，也没有什么高招，只好就这样。
然后定了个阈值做了一些业务指标的测算，出了一个报告。
慢A把成果发送回了慢银行，进行了远程汇报……
最后，模型就这么定了。
这个阶段慢A很烦躁。
04
模型部署
慢A把模型文件和模型变量交给快B之后，就逃也似的离开了快大厂。
此时的快B觉得气定神闲，上线过很多个模型之后，谁还会把这这当回事呢。
然后不紧不慢地打开了慢A给的文件，差点没吐血。
这些变量咋还被再次处理了，给的变量都被分段好了，还合并分组干什么，不知道xgb是二叉树嘛。
怎么入模了这么多变量。
模型文件一解析，又发现这树怎么长这样，这xgb参数也太扯淡了。
快B大叫一声不好，一个电话打给了慢A，慢A说有些变量分组人数太少就合并了，参数是网格搜索找出来的。
快B很吐血，这意味着，要多一层特征处理作业，这一步很容易出错。另外，模型打分作业耗时久，需监控的变量多。
因为徒增了这些工作，重要但不紧急的模型部署变成了重要又紧急的todo。
但好歹，模型文件给到了快大厂，离线打分总远远好于实时打分。
模型终于被部署好了，并经过了一致性校验。
这个阶段快B很暴躁。
05
我说
有件事情特别重要，而很多建模的同学并没有意识到。
离线打分再把分数推送至线上接口，会比推送特征线上实时计算分数容易地多。
前者，模型复杂度就不太重要，计算作业再耗时也不是什么大问题。
但后者，就注定不能用太多变量，不能让模型过于复杂，因为推送几百个特征至线上是很困难的，保证接口响应速度是很吃资源的，验证分数的一致性也是更不容易的。
这决定了你如何去做特征工程，如何去训练模型。
所以，最为要紧的事情是，在启动建模前就必须想清楚最终将如何上线应用。
负责建模的A和B同学，一定要清楚这个流程，即使他们本人还没有这些经验，也需要有人告知并提醒他们。
并且保持一定频率的交流。
如果你们在联合建模，或者任何建模，确保你有办法知晓更全的信息。如果没办法，我可以尽一点绵力。
推荐阅读
欢迎长按扫码关注「数据管道」