智能风控模型的自动化迭代
编辑整理：许瑞
出品平台：DataFunTalk
导读：本文主要分享在智能风控体系下模型如何做到全流程自动化的迭代。将介绍融360如何搭建落地整套系统的方法和经验，以及有哪些环节是需要考虑的，会面临哪些困难。最后，希望大家有所收获，能够了解自动化模型迭代是如何工作的，内容里面会有我们的一些思考和参考方案。
1. 前言
先讲一下我对智能风控的认识，智能风控是多种技术的结合使用最终通过模型在业务的各个环节中进行决策，主要是会提高风控的精度和效率。既然是智能风控，需要有一个智能化的工程实现，智能化工程不仅仅体现在智能决策上，也需要在更新迭代上实现自动化来达到更为智能的程度。
目前的现状是有很多人工干预的地方，在效率上会有很高的提升空间。下面我们来看下在智能风控中有哪些内容可以做到自动化的。
2. 智能风控体系包含多个层次
其实智能风控在整个链条上会包含很多东西，“多”体现在具体在体系中会有很多层次。以最下面的数据层为基础的话，从数据到特征会基于原始数据进行开发，然后再到模型层面会对特征进行使用，去进行模型训练。到最上面的决策层去具体使用模型进行业务决策；其实每一层再细分会有不同的维度，例如数据层中数据获取有不同的方式或者有不同的渠道进行数据接入。特征层有不同的特征挖掘方法，使用一些算法进行特征挖掘。今天我们主要会讲模型层面如何去完成自动化迭代，其他层不会过多赘述。
3. 智能风控中模型多种多样
我们来看下模型层中具体有哪些内容？
智能风控中模型的种类是多种多样的，我们可以先按照业务阶段来划分，划分为贷前、贷中、贷后三个阶段，每个阶段都会有风险控制的需求。贷前是控制风险最重要的一个阶段，会直接将高风险的客户拒之门外，所以贷前阶段通常会部署多个模型来识别风险，这里除了用于营销的模型以外还有一些反欺诈，像申请评分和额度预测等模型；贷中阶段的话，通常会有行为评分模型来预测客户的还款情况制定账户管理等策略来降低风险；贷后也有催收预测模型来预测客户的 逾期迁移情况 , 结合催收策略来提升还款率。模型的种类很多，需要开发的模型也很多。
除了简单粗暴的增加人手，是否可以考虑开发一套通用框架来实现模型自动化迭代来提升效率呢？
1. 自动化模型迭代工作流
审视这个问题，需要先了解全流程的模型迭代会包含哪些任务或者他的工作流程是怎样的？我们对这个工作流程有了一个梳理，端到端模型迭代其实是从样本的选取开始的，然后到最后的模型部署上线以及完成模型监控，中间过程会有特征的加工、数据处理、特征筛选以及模型的训练、评估等流程。
在当前市面中有很多成熟的建模工具，像比较知名的scorecard \ Toad, 也有一些商业化的建模平台，这些工具或者平台普遍可以完成的功能是在已经整合好数据宽表的基础之上，去完成特征筛选及模型训练的功能，它们可以完成上图工作流中标红颜色的模块。
2. 自动化模型迭代架构设计
如果我们需要做到全流程模型自动化迭代的化，其实需要实现以上所有流程自动化的，那中间这些环节，像样本的选取或者模型的自动部署上线就需要和系统之间定制化的一些交互，基于刚才流程的考虑，需要设计一套完整的架构来实现这个功能。这里我们提供了一套可以参考的方案。
在这个系统架构中，大致可以分为三个部分，第一部分是功能模块用方块表示，具体到每个功能的执行；第二部分橙红色部分是数据库来进行交互，第三部分则是外部需要和系统服务之间进行交互，所以大的框架流程会有这三个部分。功能性的模块和模型的迭代的流程是基本保持一致的，所以每一个任务都会由一个功能模块来执行，在执行的时候我们在设计上是一个串联的关系，这么设计的原因是每个模块之间会有一些相互依赖的关系，下一个功能的计算会依赖上一个功能模块的结果作为输入。
具体到执行其实又分为三个阶段来执行：
第一个阶段是样本和特征的获取，在这个阶段中，样本和特征会和业务数据库以及特征的数据库进行交互来获取到数据；
第二个阶段是完成了数据的初筛、处理及模型的训练，这个通常是一些内部的任务，所以我在这里设计构建了一个数据库平台来存放一些临时性的数据，做一些数据的存储交换；同时在模型的功能模块上又有两种设计，第一是可以用python 来完成单机的模型训练，第二种功能是在数据量过大的情况下，也可以支持提交训练任务到spark的集群服务来返回模型的结果，这样来更进一步的优化建模的效率。
第三个阶段是模型的部署、评估、监控，模型的评估会和模型的数据库进行交互去获取线上的模型数据和新训练的模型进行横向的对比，在选出最优的模型之后部署在模型引擎上，并且给模型的数据库返回新的结果；最后一步是完成模型的监控。
这个是我们整套的系统架构设计，有了这个设计，我们来看看每个模块是如何工作的。
3. 灵活多样的样本选取方式
首先是样本的获取，我们是通过配置参数的方式去灵活的进行筛选来获取迭代的样本，它的原理是通过python或者SQL代码去提取数据，然后我们将其中的关键筛选条件进行参数化，每次执行的时候可以达到配置的目的。在这个配置的维度上，我们设计基本分为三个大类：
第一个是在客群上样本的筛选包括业务线的筛选，产品的筛选以及新老客之间的客群区别；
第二个是Y标签，提供多种不同Y标签定义的计算方式；
第三个是样本时间的选取，在这块做了两种设计方案：
第一种按照当前触发迭代任务的时间往前推算来获取最近N个月的样本，比如最近三个月，我们知道在建模的时候需要划分一个OOT的验证数据集，我们会从时间上从近到远划一个固定的比例比如20%，这个比例的样本会作为OOT的样本进行评估。在这个方案下，模型每次迭代的窗口是固定的长度，会随着每次迭代的时间变化向前滚动，这样每次迭代都是使用最新的样本；
第二种方案是设计一种固定的起始样本时间，而终止样本时间会跟随着每次迭代任务不断的向前变化，OOT的划分也可以有一定的不同，OOT在这里可以采取最近N个月的方式来进行划分，这种方案中，模型迭代的样本量是不断增加，时间窗口会不断拉长。随着模型迭代次数的增加，模型的效果和泛化能力就会得到一定的增强。这种方案会适用初期样本量不是特别多需要逐步增加样本量来迭代模型的一个业务场景。
4. 分模块构建特征库
有了样本之后我们需要获取可用的特征，这里设计了一套方案来构建一个特征库并且保证特征可以T+1进行自动更新的。按照特征的来源分布，是可以分为内部和外部数据，不管是内部的还是外部的，每一个数据源或者数据模块都会按照单独的一个库进行存放。比如征信数据，所有的征信数据都会单独的存为一个库。数据存储方式是以用户和数据产生的时间作为主键进行存储。
在有了储方式之后，同时又有两种不同的更新机制，一种是线上如果调用过这个特征的话就会把特征的值直接存储到对应的特征库中。另一种是需要进行T+1离线计算特征值再去更新，这样做的原因是在线上调用数据通常只会调用当时模型中使用到的那部分特征，还有些没使用到的特征，在建模的时候可以进行补充完善。这部分特征就需要进行离线计算来进行补充，这样的话可以获得一个比较全面的候选特征值，最后通过不同的特征库互相关联来合成一个特征宽表。
在设计特征存储方案时考虑了两种方案，一种是像现在这样分模块单独存放，每个数据模块建一个库，另一种是所有的特征统一的作为一个库。如果统一存为一个库，在后续合成宽表或整合的时候会比较方便效率也比较高，但是没有办法做到灵活的配置选取。现在这种分模块存储方式，在更新及模型迭代的选取上会更为灵活，比如在构建贷中模型的时候，可以选取还款行为数据，那贷前模型不会用到这些数据，分模块存储会更灵活的选取模型迭代任务所需的特征维度，避免计算资源的浪费。同样的特征模块选取也是采用参数配置的方式来实现，在需要选取的特征模块中进行添加配置。
在这里会衍生出一个新的问题，新开发的特征如何来添加进来呢？比如，新开发的IP地址关联类的特征。这个时候就需要单独构建一个新的特征库来存放相应的特征，但是只构建一个库的话，还不能完全的使用因为缺乏完整的数据，如果在模型中使用的话会出现大量的缺失，还需要进行一个全量的数据补全操作，并且加入到一个T+1的任务中。这样的话，在下次的模型迭代任务中，我们再把参数配置到特征列表中去进行添加就可以正常的引用调用了。
5. 特征筛选后能更为高效的训练模型
在行成了数据宽表之后，还需要对数据进行预处理和筛选以达到让模型训练获得更好的效果。我们设计了三种特征处理方式来进行自动化。
第一种是缺失值的填充；
第二种是特征根据一定的规则进行初步筛选；
第三种是特征会根据指标效果进行提前的选择。
首先是缺失值的填充，我们的设计中会根据不同的缺失类型来保留更多的信息，比如单个特征缺失的情况我们会填充为-8887，如果整个数据模块缺失会填充为-8888，因为这两种缺失在建模的时候提供的信息是不同的。
然后是特征的初筛，会根据人为的经验来制定一些比较硬性的规则。如果触发的话会就会直接去掉，这些规则的设计需要人为的经验。
最后一类是根据指标效果来进行特征的筛选，这里会有一些单特征的指标，比如IV、KS、缺失率等等，如果没有达到阈值的话则排除此类特征；第二种方式是引入一些树模型，树模型会有一个特征重要性，如果特征重要性为零的话，也可以直接排除。
我们通过这种方式也会初步筛选出一部分特征来进行模型训练，同样的这些筛选规则的阈值的配置参数来进行配置的。特征筛选完之后，剩余的特征都是可以用于模型训练的。
6. 不同算法及调参方式组合训练多版模型
在模型训练的方式上，我们设计了不同的算法和调参方式相组合，来训练出多版的模型。
算法上会支持比较常用的，如树模型、XGB、LGB、LR等等。调参方式使用一些通用性比较强的如贝叶斯优化、随机搜索，可以适用于多种算法，模型算法和调参方式两两组合可以产生多种不同的训练结果，在操作层面也是通过参数配置来完成。其实，调参方式和算法还有很多是可以补充的，比如网格搜索、遗传算法等等。我们在设计上的考虑上，选用了这两种，因为它们的执行效率会比较高，占用的计算资源是比较小的，然后在整个自动化迭代体系中，是比较合适的。
7. 设计一个多维度的模型自动评估体系
有了多版模型之后再结合线上已经部署的模型，我们把它放在一起来评估，这样的话模型个数是非常多，我们也设计了一套模型的自动评估体系，去从多个维度来挑选最好的模型。
首先我们需要评估的模型分为两个部分，第一个是新训练的模型，第二是线上已经部署的模型。在这个评估上有个大前提，就是所有的模型评估OOT验证数据集样本是需要对齐的，这样我们才可以横向的进行评估。
我们设计了三个评估维度：
第一个是模型的效果指标会用KS、AUC来衡量；
第二种方式是模型的单调性，和业务比较相关的指标；
第三是从模型的稳定性进行考虑的。
如果说到模型的单调下，它在风控场景下是需要重点考虑的。这个概念是比较抽象，我们目前没有一个比较明确的或者显性的指标来直接评价模型的单调性。我们在维度层面也进行了拆解，设计了集中不同的指标计算方式来评估倒箱个数和严重程度，还有不同通过率下的逾期率去近似的评估模型单调性。
8. 模型打分
我们借鉴了评分卡的思路，来将所有的指标得分加权，总分最高的就是最好的那个模型，首先每个指标都会有一个单独的得分，在三个维度上有不同的权重，每个维度的指标也会有一个权重，一个指标权重的得分其实是一个指标单独的得分乘以指标权重和维度权重，把所有的指标得分加总会得到一个总分。
在这个例子中，线上模型和离线模型它们进行对比评估，线上模型的KS、AUC都是高于离线模型的，在得分上会相应更高，稳定性和单调性表现会比较差。那么从总分来看，离线模型是优于线上模型的，这个结果和人工判断是基本一致的，因为在风控领域更关心模型的单调性和稳定性，说明这个评估体系是比较符合实际情况的。当前维度权重和指标权重都是以均分的方式赋予权重，具体权重还有没有其他的设计方法也是可以进行深入的思考的。
下面分析一下具体指标的分数是怎么产生的，以KS为例，首先将评估的模型根据KS得分的来排序，然后对应的会有一个排名，用一个公式将排名转换为评分，这样做的好处是避免使用绝对值进行评分。因为KS的绝对值在不同的模型或者业务场景下的变化会比较大，如果用排名来评分，适用的范围会更广。同时公式所转换到的分数区间一定是1-100分，这样也就进行了量纲的统一。
除了模型指标KS\AUC以外，之前还提到了单调性的指标，这里可以分析一下具体是如何进行计算的，首先是倒箱的个数，一个排序单调的模型它的逾期率一定是随着模型分数的增高而递减的。比如，下一个分箱的逾期率如果高于上一个分箱我们就会认为是倒箱了，我们会统计下一箱逾期率高于上一箱的个数，在这个例子中计算得出有三个倒箱的个数，第二个指标是倒箱的严重程度，这个我们是看倒箱的时候，上下两箱他们之间的差值，差值最大的就是模型最严重的倒箱，再和其他模型进行横向的对比。
除此之外，还会看不同通过率情况下所对应的逾期率，这个会综合考虑模型在不同通过率条件下对业务的影响。所以这一整套是我们模型自动评估的体系。
9. 自动化部署上线
在能够选出最优的模型以后，我们需要能够保证模型可以准确且自动化的部署上线。在这里既要要求准确又要要求自动化的话，有如上图三点是需要注意的：
第一是模型引擎的交互，这里模型引擎需要提供一个热加载功能。会实时的将新模型直接部署在系统上，同时模型引擎会提供接口或其他的交互方式来传输模型文件或者是一些特征处理的脚本代码来完成系统上的部署。
第二种是为了保证部署的正确性，通常系统之间会有很多交互，比如从原始数据的获取到特征引擎的实时计算再到模型引擎的调用，是有比较强的关联关系，所以如果要保证部署的正确性，需要对各个环节进行测试来确保系统中的数据流转是正确无误的。这里需要引用一些自动化的测试框架来做一些定制开发。
第三是保证模型线上线下的打分是一致的。在这里设计了一个测试方案，我们会从线下的训练数据集中随机的抽取一百条数据，将这些数据模拟到线上，来实现一个线上的打分流程。如果说模型的打分，线上线下都是一致的，那说明测试是通过的，这样才会进行模型的部署。模型上线之后还设计了一个后续的检验环节，在上线当天会取到所有模型所用到的特征值，去结合和当时建模时的OOT，计算它的特征分布和PSI,如果PSI超过了设定的阈值，则会发送一个监控报警信息，在这种情况下，可能会存在线上线下缺失值不一致或特征的其他处理不一致的问题，此时会发送监控邮件提醒进行人工排查。有了这套流程可以比较好的保证模型的上线部署是准确且自动化的。模型上线之后是先进行“陪跑”不能进行决策，如果要适用模型进行决策还需要进行人为操作。
10. 自动化模型迭代效率提升
自动化模型迭代会在效率上带来很大的优势，这个演进过程是，最初是人工的进行模型的迭代，后面有一些建模的工具，到现在已经实现了全流程的自动化模型迭代。在最开始的模型迭代中，整个流程都是需要人工来进行操作的，且每个建模同学都会有自己的建模方法，不同的人做这个模型项目通常会得到完全不一样的结果，这在管理上会造成一些不可控的因素，工作周期较长。有了自动化建模工具后，在数据宽表的准备和部署上还是需要人工进行操作，中间的建模过程相对标准，不同的人建模的结果差异不大，工作周期会进一步缩短但是还需要3-5天/人。在实现了自动模型迭代之后，整个迭代流程不需要人工进行参与，各个环节可以通过参数配置的方式来灵活实现，最快的可以达到每天的迭代，针对成熟的业务线，我们搭建这样一套自动模型迭代框架来代替人工的迭代工作，可以释放出更多人力去进行其他工作的开展，这个就是模型效率上带来的优势。
除此之外，自动模型的迭代在效果上也会带来价值，假如我们上线了一版模型进行决策，如果不迭代的话，模型效果会随着时间不断衰减，当我们通过定期的人工迭代，比如一个月或者两个月一次，可以再次提升模型的效果，但是中间会有一段时间模型还是会逐步的衰减。在我们上线了自动模型迭之后，迭代的周期会变的更短，可以在几天迭代一次。这样可以维持线上模型的表现在一个比较好的水平上。
回顾今天的主题，我们介绍了模型迭代的框架是如何设计的，然后介绍了每个功能模块的分工且它会带来的效果，在项目落地过程中，最大的问题是系统之间的交互，因为每家的系统架构设计都是不一样的，需要进行一些定制化的框架设计。比如，之前的系统是可以进行界面化的操作，为了适配自动化流程，需要对系统进行一些改造，提供相关的接口来完成自动化执行。除了实施问题，我们实现的这套自动化系统还有很多可以进行优化的地方，比如可以提供更多的模型算法，以及完善模型评估中的权重设计等等。
在实现了模型自动化迭代之后，也给我们带来了一些新的启发，既然模型上可以做到全自动的迭代，像其他的方式比如规则是否有可能进行自动化的挖掘？阈值有没有可能进行自动化的划分来实施自动化的决策？等等。这些都是后续可以思考的一些方向。
今天的分享就到这里，谢谢大家。