摘要

近年来，银行业不断推陈出新及迅猛发展的业务对数据建模提出了两点要求。一是要求模型比传统的业务系统有更强的场景驱动性，业务穿透性更强，即要求数据模型需通过新的数据不断的迭代优化，以适应新的业务需求。二是，数据在广度深度上的激增及应用场景的增加如客户管理、零售精准营销、风险管理、运营管理等，意味着分布式分类、聚类、关联等机器学习算法都有可能会用到。从以上两点来看，机器学习平台是大数据应用的一个重要发力点，其在基本功能方面需要包括两点，一是其能为大数据建模提供海量数据支撑；二是其能为大数据建模提供强大的算力及处理能力。本文主要是从机器学习建模的应用场景及实践出发，引发对机器学习平台构建的思考，旨在帮助读者了解机器学习在银行业的应用现状及应用难点，从而对构建机器学习平台有一定的启发。

1、机器学习在银行业的应用背景、现状及趋势

2006 年到 2015 年是人工智能崛起的黄金十年。 2016 年，谷歌“ AlphaGo ”的成功，人工智能再世界范围内掀起了新一轮技术创新的浪潮。金融领域庞大的交易量、交易历史数据比较完备 ，以及其量化分析的特点，为人工智能技术的应用和发展提供了得天独厚的条件。作为人工智能的基础和核心，机器学习已经成为金融生态中不可或缺的组成部分，从信贷审批到用户资产管理、到用户金融需求预测、到用户金融行为引导，再到金融风险评估等。很显然，在解决银行业转型难题的过程中，机器学习以其丰富的大数据处理技术及强大而精准的计算力，显示出了巨大的推动能力。

机器学习是一门多领域交叉学科，专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能。据了解，机器学习已经成为各大银行转型升级的主要推动力。目前，机器学习平台已经作为业务智能化发展的基础性平台，服务于银行的各类应用场景：精准营销、风险管理、反欺诈分析、客户关系管理、信贷消费中的信用评分甚至到银行内部管理等。

2、机器学习在银行业的应用场景分析

精准营销在银行业的应用广泛、风险成本低、执行过程简单但效果提升可能很大等特点，使得精准营销成为银行业机器学习应用的开山鼻祖，且一直是其主要的应用场景。精准营销可以说是贯穿了客户运营的整个流程，包括：拉新、转化、促活及留存。拉新即利用现有的老客户作为训练样本建模，然后将获取的外部数据灌入到模型中得到评分（概率），评分高的表示客户的潜在性高。类同，精准营销在转化方面的应用主要是通过依据客户的行为类特征进行大数据建模，再通过精准营销触达模型“过滤”出来的潜在客户刺激转化；个性化推荐就是精准营销在客户促活方面的完美案例。流失客户挽回最好的办法当然是优惠吸引，但往往我们无法精准的营销敏感点，机器学习等大数据技术在优惠敏感及流失预警等场景中则大放异彩了。但在银行业，精准营销仍有其局限性，在产品全生命周期中应用终不会像互联网那样流畅。一方面，是因为银行产品种类有限；二是因为，银行有的更多的是客户的资产信息，而行为类信息及具有潜在业务逻辑的数据较为稀有，且业务办理渠道不唯一。但精准营销还是可以大放异彩的，机器学习在零售条线的理财客户拉新、转化及留存方面的实践结果也是非常显著的，遗憾的是很可能难以做到产品粒度的个性化推荐。

风险管理是机器学习在银行业应的另一大应用。银行来说，在为顾客提供产品和服务之前，基于其国籍、职业、薪资区间、个人经历、工作行业和信用历史等来对顾客进行风险评分是至关重要的。风险评分是银行最终决定提供给客户多少额度以及其它相关产品行为的重要业绩指标（ KPI ）。基于机器学习大数据建模技术建立的评分卡模型，极大的提高的银行顾客风险评分预测效率低等问题。当然，真正要 “ 即时地 ” 引入一个处于中心地位的、综合性的金融和风险机制成为了主要的难题，主要是目前机器学习在风险管控方面的应用主要集中在信用卡领域，包括贷前审批、贷中风险快速响应以及贷后催收等。贷前审批也是我们常说的评分卡模型，它是基于历史客户的征信报告以及行内真是的消费还款等信息构建的机器学习模型。说白了，做风险管控的终极目的还是为了增加收益。但目前一般构建的评分卡模型并没有结合收益综合考虑，致使它只能做风险管控而无法做到拉新增加营收，及只能作为整个审批流程的一部分，无法做到全流程的自动化。欺诈行为是银行面临的又一大难题。或许，银行业最大的机遇之一就在于在线欺诈实时监测，通过分析手段和机器学习的方法，最终获得对顾客的完整认识。识别数据形态，模拟业务行为，将信息整合到一起，然后从普通的行为活动中分辨出欺诈行为。然而，欺诈数据量少、 app 埋点不规范无法拿到连续性的行为特征是整个应用的两大难题。

运营方面，银行 ATM 现金运营工作任务繁重，且每年要投入大量的人力成本和现金库存。机器学习建模在寻求银行 ATM 现金运营风险防控、客户服务和成本管理的最佳平衡点方面发挥了很好的作用，为银行深化集约运营后台体系改革带来机遇。目前，工商银行在这方面已经取得了大规模推广使用的经验，且业务效果提升明显。金库有多种多样的产品选择，比如固定收益（ FX ）、期权、互换、远期，更重要地，还有现货。通过整合这些复杂的产品、客户风险因素、市场和经济行为和信用历史，来实现线上交易，对银行来说几乎是一个遥远的梦想。在即时风险评测的支持下，用机器学习来整合一个强大的汇率定价方式，最终把交易搬到线，这将会是一件非常惊艳的事情！

然而，在机器学习在银行业大放异彩的时候，应用流程上的弊端即不稳定等风险及工作效率等逐渐暴露放大，人们自然会反过来思考如何去优化流程以及控制整个应用“生态”的风险等问题，如何构建一个好的机器学习平等问题。

3、机器学习平台介绍

目前，各大银行都在尝试构建机器学习模型辅助业务开展相关工作，并逐渐线上部署实现模型的自学习过程。一个机器学习模型的构建不仅需要数据科学家研发模型，开发工程师对原生模型进行开发上线，还需要开发工程师和运维工程师来建设和维护机器学习平台。在机器学习应用团队中，构建机器学习平台是非常重要的一个环节。

从功能上说，机器学习平台最重要的三个功能为：数据处理、建模、部署。这其中每一个都可独立成为一个平台，当然也可以组合成一个超级机器学习平台。我们以营销服务为例，先从机器学习平台构建的农耕时代讲起，来思考现在及将来我们到底要如何构建我们的机器学习平台，或者说在构建的时候需要关注那些点，目前我们只对批量情况做分享，实时是趋势，有机会再话。

3.1. 机器学习平台建设的必要性

上图展示的是一个典型的营销子业务的架构图。从图中可以看出，离线特征和模型的 json 文件都是直接导入到 Mysql 数据库。算法逻辑和工程逻辑耦合在一起，工程说白了就是在做算法的翻译工作，将算法同学的想法以及模型预测逻辑都写在工程代码里。这种架构的缺点是显而易见的。我行在机器学习应用的实践过程中，缺陷就逐渐暴露出来了。首先，对于精准营销来说，可应用的业务条线众多，如果每个业务条线都采用这种架构，每个场景要独立进行模型训练、特征工程和线上预测。这必然存在特征工程重复开发，造成特种口径混乱的局面。因此，我们有必要将算法研发过程中的一些公共环节进行抽象和规范，将各个业务线在运用机器学习过程中的公共模块统一起来，提供一个平台来支撑离散特征管理、算法迭代，模型管理，提升迭代效率，这就是为什么我们的机器学习需要平台化。

3.2. 机器学习平台架构及功能介绍

目前，我行引进并投入使用的是基于第四范式“先知”机器学习平台，是分布式人工智能应用开发平台。在此平台中，业务及科技人员可通过平台进行人工智能模型调研探索、模型应用及模型的自学习工作，助力企业提升数据价值，完成数字化转型工作。

功能上，主要包括两个平台模块，分别是模型调研平台和模型自学习平台。模型调研平台，覆盖从业务数据处理到机器学习模型建模的全过程。平台支持大规模数据的分布式计算和处理，特征的构建，特征重要性分析，主流的机器学习算法，模型的效果评估以及模型的版本管理及发布工作。模型自学习平台主要是基于生产最新的数据，进行模型的迭代，实现模型的自学习。模型的时效性主要依赖于数据的时效性，目前我们所有的场景都是 T+1 批量预估。功能模块及逻辑架构如下：

数据仓库的数据根据业务需要，引入到模型调研平台，经过数据处理及特征工程，算法训练等过程得到模型方案存储到模型仓库中，可供调用；模型自学习平台接收来自数据仓库的增量数据，进行模型的迭代工作，即模型的自学习。当然，数据来源除了数据仓库之外也可以是各业务系统，但一般我们为了系统的运营稳定性，不从业务系统直接接入数据。同时，各平台有各自的优势，多平台之间的协同就对整个系统的调度引擎提出了高要求，需要支持不同计算平台，不同计算任务的调度，以期实现整体机器学习全流程运行效率。同时，系统针对不同的计算任务，如数据处理、模型训练等开发了不同的计算算子，以提升计算的速度。通过 Pyspark 处理数据引入及执行特征工程等任务时，利用 spark 基于内存架构计算速度快特点，提升数据处理能力。

模型调研完成后，在后续的使用中，需要利用新的增量数据持续更新、稳定、完善模型效果。可以通过自学习平台实现自动化过程。新的增量数据按设计放到指定地点， SDK 提交模型自学习请求，模型开始进行增量拼表、特征构造、全量数据的模型训练。架构方面，调研平台并不要求与自学习平台网络可达。当网络可达时，模型和自学习方案可以自动发布到自学习平台；当网络不可达时，用户可以手动导出模型和自学习方案将它们导入到自学习平台完成模型的生产发布。

目前，我们平台支持的算法有： LR （逻辑回归）算法、 GBDT （梯度提升决策树）算法、 SVM （支持向量机）算法、 DNN （深度神经网络）算法及 K-Means 算法等。模型评估方面，评价指标有 AUC 、 ROC 图、 KS 图、各阈值下的混淆矩阵及对应的准确度、精确率、召回率等指标。评估对比功能可同时对比多分模型评估报告，加入训练多个超参数配置的不同算法模型，并对多个模型进行评估得到多分评估报告，可以在同一坐标体系下进行多个模型效果的指标比较，评估模型的优劣。

3.3. 机器学习建模实践分享

目前，基于此第四范式“先知”平台我们的数据应用主要围绕精准营销和风控两大主题展开，包括但不局限于各类理财产品的精准营销、辅助贷前审批的评分卡模型及贷中风险预警模型等。下面将以精准营销模型为例，介绍如何建立一个机器学习模型。

机器学习建模是如何助力精准营销的呢？首先，我们要清楚机器学习的定义及原理。机器学习是指从海量数据中自动分析提炼出有价值的知识、规则与模式，以进行预测、识别与分类的技术，是使计算机具有人工智能的根本途径。

在离线模型的具体构建中，一般按下述几个步骤进行（此处以某理财产品的营销为例）：

1. 样本收集：

l 明确需求：弄清楚业务问题，转化成可解决的机器学习问题；

l 获取数据：确认为了解决问题，需要哪些数据，哪些数据是可获取的，如何获取；

l 样本构造：基于获取的数据，如何构造样本，可以构造哪些特征来描述样本。

在样本的构造中，往往存在正样本“不完美”情况：一种是对于某一款理财产品，过往并没有营销的记录，这时我们需要根据购买时间去构造虚假的营销时间，进而再进行特征工程的工作；另一种情况是，专家规则使得样本构成和整体有差异，这一定程度上会造成线下和线上评估验证结果不一致问题。解决办法是评估集合随机发一批名单，保证线下建模和线上验证的外界因素基本一致。

2. 特征工程：

   特征工程主要包括特征处理和构造两部分，为整个建模过程中最重要且耗时最长的部分。特征分类一般包括基本属性特征、资产类特征、行为类特征、趋势类特征及时序特征。

3. 模型训练：

   结合不同的样本分布数据选择合适的算法训练模型，一般营销类模型选择 LR 及 GBDT 模型，二者各有自己的优势。在模型训练之前，我们一般会将样本拆分为：训练集、验证集及测试集，一般按 8:1:1 进行拆分。当然，验证集在这里不是必须的，它主要是为了评估过拟合情况，若实际样本数据不足的情况下，可考虑不拆分验证集。

4. 线下评估：

线下评估是指在模型真正使用之前，利用历史样本数据评估模型效果，一般通过模型技术指标 AUC 、 KS 值及模糊矩阵衍生的指标等和模型在测试集上的效果指标统计进行评估。

5. 线上评估：

线上验证一般是设计合理的 ABTest 实验，直接统计业务指标。对于营销模型来说，可直接统计观察期内的营销成功率。

3.4. 机器学习平台建设展望

一个好的机器学习平台的构建一定不是一蹴而就的，并不需要在起步阶段囊括所有的功能，需要避免过度设计问题。但一定是科技驱动并结合业务特点，对平台做好定位，做好全局性规划。整体规划应如超市一样，先搭建好框架，再逐步填充数据服务。这一点和大数据平台架构有很多异曲同工之妙。理想的机器学习平台应包括：

一个完整的大数据建模平台应该有模型的管理及沉淀、模型技术指标和样本分布情况监测及模型管理等功能。要求大数据建模平台定为要实现两大块问题，一是对内 BDMP （大数据管理平台，如算法模型平台、 ABTest 平台及分析服务平台等）板块，完成数据调研、数据处理、概念及逻辑模型设计，以实现提升模型建设效率和沉淀模型设计的作用；二是对外 DACP （数据资产管理平台，如特征管理平台及模管理平台等）板块，完成模型便捷式开发管理、数据监控、运行监控等运维工作；能够便捷开发，如模型技术指标监控及样本分布监测等功能模块，以实现强化模型设计能力及提升模型管控效率的作用。未来大数据建模，一定不是以模型多、模型新（不同业务条线相同主题模型换名即为新）取胜，一定不能说业务或科技人员还需要花大量的时间去建立一个模型和管理模型。一定是实现快捷建模及便捷管理的，这样业务人员才会花更多的时间，在模型的辅助下做更多业务人员应该做的事，避免出现物极必反、本末倒置的情况。业务人员的诉求是快速建模，这里模型的沉淀就尤其的重要；我们一是通过沉淀模型衍生特征，后期建立特征集市，做好特征管理解决；二是沉淀逻辑模型及按类别、功能沉淀特征衍生逻辑模型来降低建模门槛，同时提高建模效率。科技人员的诉求是实现模型的便捷管理，通过监控模型技术指标及样本分布指标情况来完成模型的迭代过程，这就是分析服务平台存在的意义所在。最终希望实现的是，对于业务老师来说，模型就是一个计算器，需要用的时候拿出来帮助工作，提升效率，为我行带来更高的收益；科技人员只需做好计算器的保养及维修工作的工作模式。

实际建设过程中，每个平台都有各自的建设重点及难点。以特征管理平台的建设为例，我们需要将特征发布统一收口，各个业务条线通过特征门户统一获取特征，维护特征。平台的另一个作用就是特征的聚合，如何支持高并发情况获取特征将是我们面临的一大挑战。数据缺乏闭环是我们发现的另一大问题，数据在很多模块之间的流转是无法追踪的，致使在建模应用中造成很大的数据冗余，且带来了极大的不稳定性。数据治理及数据血缘关系管理在这里就显得尤为重要了。同时， “ 数据孤岛 ” 等阻碍大数据技术发展的关键难题仍未得到有效解决。但“数据中台”概念的提出正是为了打破数据割裂的局面。那么，数据中台到底是什么呢？业界也没有一个固定的定义，一点可以确认数据中台即是数据架构的一部分，也是数据架构的一种实现，并不是数据架构规划的本身；且在数据中台的构建中数据目录、数据资产展示、接口该怎么做也没有定论，但一定是业务驱动去构建的；同时，以 AI 为导向的数据应用更多关注的是负样本，因此，数据在接入时是否需要进行数据处理，处理到什么程度同样值得商榷。