银行和大厂的一次数据交易

之前写过一篇:银行和大厂的一次联合建模慢银行在联合建模之后,借由快大厂的数据和流量,短暂地解决了获客问题。

但好景不长,该模型效果衰减地非常厉害,通过率也掉了一个水平,当初建模未料到行业将如此下行,采用的样本过于优质。现在不得不面对更下沉的客群。

不管是那次联合建模过程中,还是之后,慢银行和快大厂涉事双方都对那次合作不置好词。他们唯一达成了的共识是,联合建模太麻烦了。但合作是上层战略,总是要维持和推进的。

于是,快大厂提议,可以输出我们内部的数据标签作为标准产品给你们,这些数据不仅风险区分效果好还很稳定。慢银行虽然明知其套路,但迫于形势恶劣,还是觉得可以一试。

毕竟,标准产品省去了联合建模的麻烦,同时也避免了建模样本过少导致过早失效的问题。于是,原班人马把上个项目成立的微信群,“快与慢联合建模群”,改成了,“快与慢数据产品合作群”。

只是联合建模时快大厂的负责人,已经离职了。据说是因为当时合作太费劲,受不了了,也据说是在快大厂已经待了两年多了,该走了。(不知道我为什么特意想黑一下)曾经发生的故事,或多或少,或变或没变,地再次发生了。

一、立项会议

有了之前的经验,这次两方都没怎么寒暄,就直奔主题了。慢银行因为对上次合作不满意,这次主动提了很多要求。你们那什么什么交易数据要加工这些字段,提供给我们。

此处可以代入,天猫淘宝京东拼多多等电商交易数据,也可以代入花呗借呗白条金条等支付借贷数据,等等。你们那会员等级数据要提供给我们。

此处可以代入支付宝会员等级、芝麻信用分,京东京享值、小白守约分,微信支付分等。另外,你们的账龄数据要给我们。还有,你们提供什么模型评分给我们?是你们的A卡、B卡还是什么模型的评分?你们怎么建的模型?内部怎么用的?……快大厂,没有话说。

项目是VP层级的,老板发了死命令,要服务好对方。慢银行指定了一个同学,当然还是那个慢A,快大厂也指定了个同学,也还是那个快B。此外,双方增加了策略同学的参与,分别是慢C、快D。慢A和快B仇人见面分外眼红,但工资让他们学会了安分和合作。

二、数据准备

关于标准产品,慢银行体现了其专业性,提出的数据维度非常丰富,把快大厂的数据资产挖的是干干净净,多一个不能多,少一个不能少。

那是因为慢C同学参考了芝麻信用变量的维度,依葫芦画瓢,再排除了快大厂相对比较缺失的信息,提出了这么一个变量清单。芝麻信用的65个变量列表如下,其中标红的是8个核心变量。

覆盖信用历史、行为偏好、履约能力、身份特质、人脉关系五个维度,正所谓“五大护法齐上阵,信用风险忙下场”。关于芝麻信用,我写过揭秘:芝麻信用是怎么做的。

明显可以看到,阿里系在人脉关系上是多么的弱势,该部分信息主要都在腾讯和运营商手上。

产品经理,产品经理网站

不仅如此,慢C还提出了这些变量分段的要求,例如天数类的、金额类的、次数类的分段区间怎么设等等。只是最终分段还是要结合快大厂大盘数据分布情况再做定夺。

快大厂的策略同学快D秉着“最大化达成合作目的,最小化合作效果”的宗旨,剔除了其中一些过于敏感的数据,并进一步限制了变量分段数量。需求最终提给了模型同学快B去加工,这处加工费了快B半条老命。

不仅四处问人这些字段的取数逻辑,好不容易加工好还总有变量分布不符合预期。过程中,快D找出了无数个问题点,以至于快B天天吐槽快D事儿多。百年之后,快B终于改好了这些变量加工的代码,对着大盘跑批了近两年的数据,并校验了分布稳定合理。

同步慢银行时,还被慢C同学质疑了-1和0取值上的不合理。

三、策略制定

慢银行要了快大厂的大盘数据分布情况后,从行内提取了10w样本,让快大厂的模型同学快B回溯。随后,慢银行的模型同学慢A,对这些字段进行了IV和KS的计算,效果差强人意。没有人惊喜,也没有人发怒。

于是,慢A做了非常详细的数据分析,回匹了行内的客群标签,计算了变量每组下的风险水平。然后,交给了慢C制定策略。慢C操起了所谓的经验之锤,写了一堆case when,得到了最终的风险评级,继而测算了各类人群结构上的占比、通过率、风险、额度水平等等。

写了一些结论,做了一个文档,获得了行内认可。快D苦求了半天,以方便更好的监控服务效果为由,要到了这个毫无营养的文档。如获至宝地同步了快B和厂里的老板。

四、数据部署

标准产品的部署显然跟慢银行都没关系,但即便如此,谁说又能小瞧呢?快B和快D首先讨论了,客群要包括哪些。大盘用户数量巨大,全都算人数太多了,很多人也没有有效数据。

于是按活跃度选定了一个客群。然后讨论了接口服务的困难。要输出的字段有大几十个,这些字段都是要推送线上的,跟模型分的一两个字段部署完全不一样。导致这个部署作业既吃资源,又耗时长。

于是一致决定月更。但日后随着大盘活跃用户增加,该作业的执行和推数效率仍可能存在风险点。最后再制定了数据监控的方案。

快B同学每月跑数完成后要校验所有字段的分布,并邮件正式通知相关方。再第一时间推送线上接口,同时确保推送服务的有效性。对待这些需求,快B只是觉得他们吵闹。

四、我说

这次合作,慢A和快B两位模型同学都沦为了工具,非常弱势,“人为刀俎,我为鱼肉”。没办法,他们是“牛逼哄哄”的算法工程师,数据产品又不是模型,跟他们有什么关系。

算法工程师往往不等于风控同学。在数据产品合作这个项目过程中,他们被策略同学教做人了。我相信这对他们来说是一件好事。算法工程师不应该只会算法。

如果你只会对确定的样本、确定的特征、确定的标签,建一个所谓的大数据模型,不管这个模型是LR,还是XGB,还是神经网络,还是图算法,其实都是不够的。但,这在国内往往是吃得香的。

有一类很难的面试考点叫system design,国外大厂很喜欢考,国内也有很多考的了。风控模型本应该也是一样,如何对遇到的问题设计合理的解决方案,比模型本身重要的多得多。

但,还是有很多算法层面的面试仍然是XGB参数、AUC、KS等。考察的永远都是候选人有没有在认真准备面试。“存在即合理”,我理解不了这句话的解析意,我就是想用其表面意。

#作者#

雷帅,微信公众号:雷帅快与慢。风控算法工程师,懂点风控、懂点业务、懂点人生。始终相信经验让工作更简单,继而发现风控让人生更自由。

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部