尽管风险模型的开发与部署基本实现标准作业化，但在核心环节仍存在很大变数，其中包括需求不全、目标不准、大而不全、信息错配、时空穿越、算法为王、虎头蛇尾等“七宗罪”。
来源 | 金科应用研院
作者 | Jackie Liang
曾与朋友交流时聊到：如果说风险策略是一门艺术，风险模型则可以认为是一门科学技术。
风险建模是一项侧重技术应用的标准流程工作，大致分为“需求立项”、“模型设计”、“样本准备”、“特征工程”、“变量筛选”、“模型开发”、“模型确定与文档撰写”、“部署上线”、‘’模型管理”这9个主要环节。整个Workflow从模型设计到代码开发，最后模型上线，都需要模型开发人员全力以赴，以免部分环节出现细节模型风险。
在上述的9个主要环节中，都有与之对应着相对固定的代码模块，基本可以实现一次开发重复利用。
尽管风险模型的开发与部署基本实现标准作业化，但在核心环节仍存在很大变数，做的好效果提升，做不好就会擦枪走火，这些环节我在本文统称模型“七宗罪”。
第一罪：需求不清
模型确定立项之前，需要启动立项背景调查阶段，背调主要目的有两个：一方面确定模型开发意义，另一方面帮助模型开发小组充分了解数据业务背景。
通常背调内容框架包括：
工作目标
模型适用范围
基本面分析
数据的可获取性分析
仅以工作目标和基本面分析为例说明。
工作目标可以借鉴以下三点，但不同评分模型开发目的不一致，仅做参考：
通过开发评分模型研究XX银行客户特征，预测和评判申请人风险。
协助XX银行在申请处理环节对风险进行分类，决定哪些申请可以批准，哪些需要拒绝以及哪些需要人工审批。
根据申请人的评分分布，判定其不同的风险等级，从而决策对于可以批准的账户应给予何种贷款条件。
基本面分析大致分为“业务基本面分析“、”监控报表分析“、”业务逾期分析“。其中，业务基本面分析可以分析各风险表现指标随时间的分布变化、业务下各产品随时间变化的申请量、通过率以及各逾期指标分布；业务逾期分析可以从以下4点入手：
各逾期指标随时间的分布
各逾期指标流转（fpd30-60；fpd60-90）
vintage：ever 30+／M1+；ever 60+ / M2+；ever 90+/ M3+
All产品、各产品30天逾期指标分布
第二罪：目标不准
模型设计环节最重要的一环是目标变量（好坏）的定义。如果评分模型预测对象定位不准，整个工程相当于提前宣判失败。
好/坏定义用于将客户行为特征同随后的客户表现联系起来。好/坏定义会根据产品稍有不同。常用于推导好/坏定义的主要信息项如下：
逾期状态（如逾期期数）
核销标志等
推导好/坏定义也有一套“非标推导方法”，主要结合Roll Rate和Vintage进行好坏定义推导，流程说明如下：
对于评分卡目标变量Y的界定，我们主要从Roll Rate和Vintage来观察分析，重点需要考虑三个方面：
逾期流转比例
观察期和表现期
样本容量
先分析Roll rate
Roll Rate的定义为在当前催收水平下不同逾期天数转化为坏账的概率。从Roll Rate我们看到2017年开始放款，M0 to M1的流转率约为7.8%，M3 to M4的流转率为100%，也就是说，处于M3逾期阶段内的客户基本很难催收，逾期天数大于60天的客户基本为坏客户了。
再分析Vintage
Vintage可以关注下面3个方面：
观察每月审批通过客户后第N个月的逾期比率，对比每月波动，通常波动与审批策略调整有关，此波动在数据准备阶段的样本抽样过程需要关注；
逾期分布，集中在通过后的前三个月说明审批的策略有待改进，超过三个月之后才慢慢增加，说明贷中的管理有待提高；
确定逾期率在经历第N期趋于稳定。
从上图Vintage分析，每月放款逾期M2+以上的剩余本金逾期率基本在MOB=8期时趋于稳定，如果我们的放款时间累积比较长，样本表现期可以覆盖到8期，那么就可以界定样本目标变量为在8期内（对于银行往往表现期>8;消费金融
第三罪：大而不全
数据准备阶段，没有经验的建模工程师常会犯的一个错误是数据样本“不足够多”。不论是用于筛选的变量特征，还是建模样本，在我们开始进行特征工程前，一定希望建模宽表大而全，在之后环节再做减法。
举个例子，某银行的征信数据的逾期记录时间点与实际逾期时间点发生严重滞后现象，此时建模人员考虑排除征信特征变量，以免当评分模型的组成变量中包含征信变量后出现模型不准现象。
这种分析逻辑本身没错，但对于数据准备环节，大而全是我们的出发点，无征信模型与有征信模型本身效果未定情况下，为何不在一开始保留可用的征信特征呢？
大而不全，一旦因开发模型指标效果不佳时，极易造成重新进入建模工程前期再准备阶段，费时费力。
第四罪：信息错配
错配数据信息常常发生在数据处理阶段，一旦发生错配数据信息情况，一个变量的数据就没办法代表真实业务中应该存在的意义，由此特征变量构建的模型就会出现与业务逻辑不一致的问题。
在现实中，建模人员常常会遇到特征集存在不同程度的缺失，缺失原因多种多样。处理特征值缺失的方式，对数据分析与模型训练有直接影响，因此需要格外重视这一过程。
特征值缺失常见原因有如下4种：
原始数据缺失导致无法计算相关特征
无意义计算
特征值内涵超出定义
数据可采集但存在异常，导致无法计算相关特征
对于以上常见四种情况，特征值缺失本身包含了不同的信息。如果我们忽视了特征值缺失或作出不当处理（如简单填补0），建模工作将会受到极大负面影响，主要体现在：
用于建模的特征值丢失大量有用信息
包含空值的特征对模型拟合过程产生影响，导致不可靠输出
最终模型表现的不确定性与不稳定性更加明显，更难分析模型结果
为了保证特征值保留足够的信息，区分不同缺失情况，我在工作中主要采用以下两种方法：
1.基于数据逻辑的固定值填充
根据不同的用户行为，详细区分空值的不同含义，并为每一个含义补全一个固定的特殊值，此特殊值不能与正常特征值相同。
空值填补完毕后，需要再次分析，根据特征的风险趋势进行合并，或根据具体场景替换均值/中位数。
这样细致的处理有利有弊。
优点是保留了原始数据的信息，便于建模工程师理解和分析相关数据。
缺点是需要特征工程师完全了解数据采集的场景，理解数据的业务含义。具体特征具体分析，工作量大；同时对特征工程师能力要求较高，多人工作难以保证质量标准统一。
2.基于特征构造的虚拟变量引入
使用虚拟变量（dummy variable），增加一列表示特征是否缺失。
引入的虚拟变量不会经过特征选择的过程，而是强制直接进入模型参加训练。
相较于第一种方法，这种做法更加简单高效，完整保留原始信息、不用考虑数值缺失问题，为模型的准确性提供了基本保证；缺点是大大增加了数据维度，只有样本量较大时才有较好效果。
不论是哪种特征缺失处理方法，核心目的都是为了保证我们构建的数据模型在缺失项上仍能有充分的表现，模型上线后当业务中出现预设的数据缺失情况时，上线风控模型仍能保持预设的稳定和区分能力。
第五罪：时空穿越
特征工程里有很多坑，其中最不能饶恕的就是特征变量时间穿越。
何为特征变量穿越？
举一个建模特征工程中经验缺乏的建模工程师最容易忽略的案例：某模型开发小组在一次开发申请评分卡时，错误地应用了诸如“近30天最大逾期天数”、“分期期数“、”当前一个月正常扣款次数“这类变量作为模型入选变量。
模型开发出来表面模型的各项指标效果不错，实则发生了特征穿越问题。因为申请评分卡本身应用于贷前环节，一个客户还未获得贷款审批通过结果前，怎么会有贷中及贷后的表现呢。
发生特征变量穿越的根本原因是我们日常中的数据是时间序列数据，其内含因果关系。
时间序列数据的因果关系可以用这个例子来理解：当我们要预测一个人购买苹果手机的概率时，合理的因果关系是这个人买到苹果手机后会在网络上搜索浏览苹果手机壳。即先有“买苹果手机”后有“搜索浏览手机壳”。
假如做特征时发生数据时间穿越，我们会得到“用户搜索浏览苹果手机壳后”大概率“会购买苹果手机”的错误结论。结果导致模型效果在训练阶段被高估很多，实际上线后效果一落千丈。
第六罪：算法为王
可能每一位数学出身的建模人/DS曾经都有一个坚定无比的信念：自己进入金融量化风控行业的天赋使命是利用先进科学的算法来打破如今逻辑回归百年王者的僵局，用更加先进的机器学习模型把逻辑回归评分卡扫进历史的垃圾堆，趟平那些抱残守缺的公司。
但如果经历一年以上的模型开发历练，这个信念我相信一定会发生一些转变。曾经的算法为王，也许会换成另一种的业务导向。
在CV和NLP上掀起革命浪潮的深度学习，在Kaggle上无往不利的集成树算法，在现实中都未见得比逻辑回归在排序性上有显著的优势。
如果你既经历过金融信贷公司（放贷甲方机构）也从事过金融科技公司（助贷乙方公司）的风控建模工作，你会明显地发现金融信贷公司90%以上的线上信用风险模型主要以逻辑回归评分卡为主，金融科技公司的信用风险模型方案里90%以上都会包含机器学习甚至深度学习模型的影子。
就以大家耳熟能详的招联金融和微众银行为例，招联金融在信用风险的主流算法仍是以逻辑回归为主，核心关键是建模人员在不断细分客群后做出无数精准子模型，达到“最大”差异化评分；微众银行的微信分海纳百川，所有一切所需都可以用一个分数给予授信判断，其背后也是依靠着3000+评分子模型的支持和融合。
数据和特征的质量是决定模型最终效果的核心因子，算法只是帮助我们将模型效力无限逼近于最大值，前者是雪中送炭，后者是景上添花。
我想，并不需要改变对前沿技术的向往本心，但回归商业本身，业务导向才是建模人应该踏地而行的第一步。
第七罪：虎头蛇尾
模型开发之后，交付及验收环节是常被人忽视的一环，很多建模人认为模型开发出来后，没必要花大量时间与精力写几十页的模型交付验收报告。其实，模型交付标准化报告与交付验收流程，对于模型管理尤为重要。
模型管理主要包括”监控“、”微调“、”更新“、”重新培训“、”更换和启动“。当同时管理成百上千个风控模型时，不可能每一个模型出现短期震荡时就进行重新开发工程。如何最优化发挥每一个模型的效能，甚至避免一些周期性因素导致的短期模型效能失效，则成为模型管理的核心。
做好模型管理的第一步，就是要有模型交付标准化报告和严谨的交付验收流程。
模型交付标准化报告可以包括如下7个模块，仅供参考：
报告框架
概述
评分模型设计内容与关键定义
评分模型的开发
评分模型的验证
评分模型使用介绍和具体规则
附录
其中每一个目录下又分为很多子模块，详细记录一个评分模型开发的全部核心细节与注意事项。一般一份相对标准的模型交付标准化报告字数上最少超过1.5万字，50页以上。
在模型验收流程中，代码审阅是一项极容易被忽视的工作内容。模型风险中最不容易发现的一种风险就是因为代码错误造成的。同时，由于每个建模工程师都有自己一套代码编写逻辑和习惯，这也是造成代码审阅工作量加倍且困难的另一方面原因。
如何高效地开展代码审阅工作呢？
一方面，代码审阅小组的成员一定具备多年模型开发经验，具备快速纠错能力。比如一眼看出一个评分卡的变量系数出现正负号问题；另一方面，模型协同开发管理的工作能力要一开始就培养。比如，模型开发核心模块的代码注释要求和标准，是当一位新建模员工入职时，模型team leader就要及时培训到位的。
模型代码标准结构化，不仅是代码审阅小组对建模工程师的要求，也是一名优秀的建模工程师对自身的高标准规范。
我相信，风控模型只有做到标准作业与谨慎细微，才能真正体现出数据科学的魅力，才能在冷冰冰的金融数据里实现数据风控科学的独有温度。
