编辑导读：如今，银行和互联网大厂的和合作越来越频繁。其中，一项重要的合作是联合建模。本文作者根据自己的一次风险联合建模的经历，从中总结出一些问题，希望对你有帮助。

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

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

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

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

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

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同学，一定要清楚这个流程，即使他们本人还没有这些经验，也需要有人告知并提醒他们。

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

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

本文由@雷帅 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议