干货 | 平安银行算法实践

作者简介

潘鹏举, 平安银行大数据平台AI算法和分析团队负责人。2012年加入携程，开始撸代码、写文档、出规范、带团队，曾参与设计算法工程化架构，带领算法团队助力酒店服务提升。2017年加入平安，组建AI和算法团队，推动AI在银行业务的应用。

背景

银行是偏传统的行业，目前正在遭受互联网和P2P等公司的竞争压力，所以我们正在进行零售转型，拥抱互联网和金融科技。在最近不到一年的时间里，我们在算法方面做了一些尝试和探索，并对未来的一些算法应用有一些思考。整体来说，今天我想分享的内容主要分三大块：

1. 业务背景介绍

2. 算法实践分享

3. 一些思考

业务背景

首先来看银行的核心KPI。从下图中可以知道，银行核心的KPI有两个：AUM和LUM。

AUM表示的是在管资产，包括了一些存款、大额存单、同业拆借、央妈给银行代管的钱，表示的是银行从其他渠道拿到的钱；LUM表示的是借出资金，信用卡也是其中一种类别，表示的是银行借给其他人、政府或者机构的金额。只要借出资产的利率超过借入资产的利率，那么这笔资金的转换就是有收益的。

在这两个资产汇总，在管资产是重中之重，因为国家有规定，LUM/AUM应该小于某个比例，所以银行资产规模的大小其实是由AUM决定的。LUM相对来说是比较容易达成，需要钱的个人、机构是很多的，但因为风控方面的考虑同时很多人没有人行征信报告，所以正常情况下从银行申请贷款是件非常痛苦的事情，也正因为如此，现如今P2P行业、消费金融行业层出不穷，因为供给和需求的不对等催生了如今的现象。

从上面的业务背景描述，我们可以看到AUM的核心是客群管理，因为我们在LUM方面比较谨慎，换位一下，银行要从其他渠道获取资金也是非常艰难的。LUM的核心是风控，坏账率是需要关注的一个指标，当然坏账率高低和利差高低有直接关系，这也就是为什么现在的消金公司的逾期率和坏账率比银行高很多的原因。以上两点之外，我们也可以了解到银行受到的一些挑战：1. 受监管 2. 合规性 3.获客难 4. 数据稀疏。

受监管是因为平安银行属于全国性商业银行，受到国家政策的限制和监管，所做的一切都是合规性先行，我们不能做非政府允许或者非个人授权的事情。数据稀疏是针对老客户和新客户来说，老客户因为我们的产品的频次较低，所以能够获取的用户数据较少。而新客户因为我们可以获取的数据量较少，所以我们经常会跟外部的供应商进行合作。在这点上，其实是个机会，所以针对银行、保险和证券这部分的金融领域公司来说，外部的数据供应商是有一定的机会的。

面对这些挑战，我们也尝试在用一些算法实践来帮助提升银行的AUM或者降低风控风险。

算法实践

在说算法实践之前，我们整体的数据应用的架构如下。分别是基础设施、数据层、应用层三部分。

数据服务层主要提供的一些通用的产品和服务，而最底层的基础设施层，我们使用的现在常用的大数据技术组件，比如hadoop，hive，spark，ES，Redis等组件。

这里说一下AI基础能力这块，说的是专门针对的算法的一个平台级别的设计，其中核心思想是基于Docker来进行算法方面的封装和部署应用，达到一键部署和训练的目的。目前我们正在自研这个平台，如果未来设计完成了，可以针对这部分内容进行专题分享。基于新型的架构设计，我们大大的加快算法的迭代速度，加快产出。

之前提到了一些架构面的事情，现在重点说一下我们在算法应用的探索，我们这边整体的应用概览如下：

从此图中，我们的AI能力建设大致区分成了深度学习和算法应用这两块。应用层面中机器学习主要说的算法应用，结合业务的场景进行的算法的应用，帮助提升智能化和自助化。知识图谱是针对现有知识的梳理和串联，这部分数据在风控方面用处很多，我们现在在尝试串联一切，通过图谱的方式来去发现数据不一致的地方。

图像、语音和文本是根据现在业务存在的大量人工的事情，可以借助现在新型的技术和方法来提高自动化。文本这块，我们服务于app搜索和智能客服这两块。这里提一下文本这块，因为是场景化的需求居多，所以我们会重点发展自有的技术。

关于算法应用这块，我们的原则是：如果利用一些开源的技术短时间内也和市场主流的产品有一定的差距，那么这部分技术可以采用采购的方法来短时间内达到市场主流竞争中去。举个例子，语音的 ASR方面，科大讯飞的效果最高那么我们就会直接采用讯飞的技术进行ASR转换，但是在语音前处理和后处理方面，我们就会自研，因为在语音方面的去噪和增强方面，很多供应商是要做定制化开发的，对于定制化开发这部分，我们会自研，否则我们就只能一直依赖外部供应商，这个从长远来说，对我们是不利的。

说完了面上的应用。我们来看一些具体的例子，有助于理解我们在某些应用是怎么思考的。

先看第一个例子，关于客群管理的。

案例1：客群管理

从上图可以看到，我们的客群是根据客户的生命周期来进行分析和管理的。横轴是客户的生命周期，从获客、迁移到流失，纵轴是业务的细分维度，这样交叉可以区分出不同的客群出来。根据不同的客群我们会给出不同的offer和权益，不同的权益享受不同的待遇。

在客群管理中，我们会建不同的子模型用来对客户进行精准化运营。这些不同的子模型，我们的落地方案基本是走客户画像这套体系，落地在标签系统里面，这样其他人想调用的时候都可以直接拉出相应的结果出来。关于客群经营这块，其实很多公司都有涉及，但是都没有深入挖掘并细化，没有形成一整套的解决方案，都是各个部门各自为战。

根据我们的测试上来说，通过精细化运营的方式比传统的粗放式运营方式，成本和效益最少会提高5倍。我们银行也在积极的进行探索，希望能够用更加智能化的方式来提高运营，提升业务产出。

案例2：客户画像

接下来我们看一下客户画像如何赋能到一线人员。下图是我们在给一线人员开发的客群分析的界面。

可以从上图看到，我们提供了不同的数据职能模块，前面是一些事实性的标签数据，用来表示当前客户的一些基本信息，后面是一些算法给出的推荐和预测结果。

其中需要留意的是，在预测类标签中，我们额外提供了很多的辅助决策类的数据，比如流失预测概率中，我们会提供计算流失概率的重要因素，把这些重要因素展示给一线人员，告诉他们什么因素导致此客户的流失概率较高。同时，我们也会提供模型预估的流失准确率和实际准确率的比较结果，用来发现当前模型是否有比较显著的下降，以方便我们及时的进行模型的更新。

从这个案例中，告诉我们赋能一线的时候，不仅仅需要提供精准预测的结果，还需要提供更多的决策依据，否则无法指导执行的人进行有针对性的改善。当然，提供辅助决策的前提是预测结果是不是直接可以用来决策。接下来我们来看一下直接利用模型结果决策的例子。

案例3：业务预测

我们接着看比较常规的业务预测

这个是某业务量预测需求，项目背景是去预测未来3天的业务量，根据这个业务量我们会进行排班的设计，所以这个需求是直接用预测结果进行决策的例子。

针对这个项目背景和需求，我们先拉取了数据来进行分析，发现历史数据不全，能拉取到的数据就不到半年，所以周期性的规律我们都没有办法捕捉。所以我们尝试了右边的模型融合的方法，尝试了不同的预测方法进行预测，然后再结合规则进行了最终模型结果的输出。

其中历史同天平均值表示的是最近三个月的同一天的业务量预测平均值。

其中规则的方法针对的是月初的情况，我们发现月初的结果和其他的走势很不一样，所以我们针对月初使用了一些固定的规则来进行预测。

通过以上方法，我们可以把预测的绝对偏差控制在9%以下，在数据量如此小的情况下能达到如此精度，我们觉得还是做的不错的。也在此把方法分享给大家，看一下对大家有没有一些启发。

说完了一些预测类的事情，我们接下来说一下我们在图谱方面的尝试，这是个体力活。

案例4：图谱

上图是我们在图谱方面做的两个尝试，左边的这张图是卡号、进件号码和激活号码之间的聚类结果，我们根据这个聚类结果发现了一些疑似薅羊毛的团伙，并针对这些团伙进行定点的分析，比如地域，发现的结果还是蛮有意思的。

右边这个图是我们根据左图的测试案例进行外衍生出来的知识图谱结果，这个是我们的一个数据产品。我们可以利用这个产品查询到不同电话之间有关系的人、不同卡号之间有关系的人出来，这个产品在对某些风险案件的反查和一些新的规则的发现是有帮助的。

在对图谱的存储上，我们尝试部署了一些图数据库，比如neo4j、OrientDB和JanusGraph。对比结果如下：

OrientDB和JanusGraph，我们都在一定的尝试，目前在使用OrientDB做了一些地址方面的POI存储，用来进行多个三元组的存储。

关于图数据库上，它是一个存储介质。在图挖掘上，我们认为重要的是根据场景来进行分析和挖掘，所以多做一些数据分析和探索是重中之重，存储只是解决了快速部署应用的问题。

我们希望在未来有更多的图谱方面的挖掘和应用，万物串联是我们在做各种应用的基础能力。

一些思考

在我们做一些应用实践的时候，我们也有一些感悟，这些感悟对我们加快数据赋能公司也有一些帮助。

第一个感悟是：

在很多算法落地的场景中，我们都比较需要数据产品经理的角色，比如客户画像、客群管理、业务预测等，数据产品经理会梳理好业务和数据对接的场景，让算法工程师的工作职能变得相对专一一点，他只要了解业务，数据梳理并把模型开发上线就可以，而在最终的页面展示和业务系统对接和沟通、协调上面会由数据产品经理去完成，他们同时会兼任一些项目管理的工作。

通过这个分工，可以让整个算法项目进度完成的更加顺畅。我以前带团队的时候，这个角色一般是由我来承担的，即分组经理承担，但是分组经理因为顾及的面较多，涉及到多个项目的跟进和资源协调，所以在单个项目完成度上打了一定的折扣。

现在，通过新增的数据产品经理角色，可以加快数据落地和闭环过程。算法应用人员、数据产品经理、分组经理。外部系统开发各司其职，很好的完成了数据赋能的任务。

第二个感悟是：

我们需要一个统一的AI算法平台，集模型训练、部署、可视化于一体。通过这个平台可以减少很多不同算法工程师的重复工作。

上图是我们目前使用的一个算法平台，挺好看的，但是功能上需要完善很多，所以我们也在设计一个新的算法平台，用来减轻一些重复工作量。现在外界也有很多公司也在开发相应的产品，其实目的就是想通过减少使用算法的门槛来提高算法在公司的使用情况。从目前来看，很多算法的壁垒和门槛已经慢慢的变低了，所以未来对算法工程师的要求就更加严格了。

最后，说一下理想中的算法平台可以参考一下UBER设计的平台模式，从数据源头到部署运维一体化，覆盖了online和offline渠道。