风控决策引擎的产品设计（二）

文明世界拼图 2018-03-22

展开全文

之前分享了风控决策引擎的产品设计（一），为什么带个（一）呢？主要是为了激励自己能来写第二篇，那么我来了。

本篇主要从数据的合理使用、把控模型及规则的有效性、风控模型自动配置三个方面总结并分享一下自己的心得，还望大家多多指教。

一、数据的合理使用

首先我们要明确风控的核心目标：提高通过率，降低坏账（尽可能的挑出好用户）

风控是数据“喂出来”的结果，数据的质量、数量均会影响到最终的风控结果，因此合理使用我们能获取的数据尤为重要。

1.1、把握有效的数据源

这里提到【有效】二字，数据不是越多越好，而是有效数据越多越好。在建模的过程中，如果出现大量无效变量（对最终结果影响不大）、或相似变量（多个变量效果相似）、或缺失率较高的变量。则会非常影响风控的准确性。我们应该对这些变量进行处理。

无效变量：无效变量是指对风控结果影响不大的变量，也就是建模之后系数特别低的变量。对于无效变量，我们不能完全舍弃，而应该从本次模型中剔除，但数据要存储，用户的质量在发生变化，变量的有效性也会发生变化，因此应该保证数据源的完整性，以便模型迭代时可以继续使用。

相似变量：对于相似变量，应该把其余相似变量剔除，保留一个最有效的变量，剔除的方式可以是逐个校验，看加入哪个变量的ks值会更高一点，则保留哪个变量

缺失变量：缺失变量的处理，直接拿一张图来解释（图片来自知乎）

数据缺失.jpg

数据填充的方式有：

1）以业务知识或经验推测填充缺失值

2）以同一指标的计算结果（均值、中位数、众数等）填充缺失值

3）以不同指标的计算结果填充缺失值

1.2、挖掘有效变量

在业务开展的过程中，除了已有变量的使用，我们需要基于已获取的数据，尽可能的挖掘一些其他衍生变量，以提高我们的风控能力。

数据源一般有以下几种：

内部数据（用户填写的数据，性别姓名等）
三方数据（黑名单、信用分等）
抓取数据（设备、wifi、通讯录等）
爬虫数据（运营商、社保公积金等）

以上数据的种类大家应该都比较熟悉，不再过多介绍。主要讲一下如何挖掘有效变量。

变量的挖掘都是基于已有数据，再进行假设，通过可解释性，清洗一些衍生的交叉数据。

举个例子：

我们想要搜集催收号码，希望用户通讯录或通话记录命中这些号码的数量来作为一个变量。从可解释性来讲，用户跟催收通过话，应该是坏用户。因此这个可以作为一个新的变量。但催收号码并不好搜集，我们的目的是为了搜集一些高危号码。可以换一种思考方式：

我们有很多用户，有用户的通讯录，通话记录，我们可以把所有用户的通话记录清洗一遍（如果有200万用户，大概能清洗1亿个号码左右）。再对清洗出来的号码作出判断，筛选出联系超过50个用户的号码，例如号码A。我们看一下与A联系过的放款用户，最终的坏账是怎么样的，从而根据命中的坏账结果，来定义高危号码。我们不去管这个号码是催收电话，亦或是中介的电话，只要知道这个号码是高危号码，我们的目的就达到了。

二、把控规则的有效性

风控之所以要快速迭代，是因为用户时刻在发生变化，我们之前定的规则是否还是有效的，需要我们经常去关注，去测试。

2.1、敢于冒险

为什么要敢于冒险呢？如果我们在坏账ok的情况下，希望去提高通过率，就应该去冒险。去灰度测试我们之前的拒绝规则，去尝试把通过的模型分调低。

本人真实经历：去年7月份的时候，老用户通过率为63%，通过一个月拒绝规则的灰度测试，把通过率调整至81%，当月坏账比上个月高了30%。但是经过8月份的调整，8月份通过率维持在78%，坏账恢复到正常水平。这个经历也就是拿短期的风险来换取长期的收益，通过对拒绝规则的重新测试，在次月把失效规则去除，以保证风控的通过率提升。

我们要时刻关注用户被拒绝的原因，如果用户因为某个原因一直被拒，我们就不知道这条被拒规则是否真正有效，因为命中的用户是没有结果的，因此我们要经常灰度测试一些被拒的规则，让适量的用户去通过，看命中的用户是否像之前一样坏账那么高，也就是验证被拒规则的有效性。这必然会导致一些损失，但我们如果没有测试，假设规则失效了，我们会误拒很多用户，导致更大的损失。

下图为我们对拒绝规则的监控，方便我们及时作出调整。