本文根据平安人寿AI资深专家吴建军老师在平安人寿&DataFunTalk算法主题技术沙龙 —“机器学习/深度学习在金融领域最新研究和应用实践”中分享的《机器学习/深度学习工程实战》编辑整理而成，在未改变原意的基础上稍做整理。
今天主要从以下几个方面进行分享：平安人寿AI应用技术概览，数据处理和编码，模型应用与实时服务，算法与模型训练。
首先讲一下平安人寿AI应用技术概览，首先分一个大数据平台开发，分为平台级的开发和应用级的开发。平台级开发主要有离线计算平台，实时计算平台，以及多维分析引擎等；应用级开发有数据采集清洗，统计报表开发，画像挖掘等。算法研究方面分为三个方向，第一个统计分析，金融数据比较复杂，需要投入大量的人力财力做统计分析，用的比较多。还有就是机器学习、深度学习两类方法，主要解决的问题有：机器学习主要解决分类与推荐、知识图谱、自然语言处理，深度学习解决量化精算、视觉模型，强化学习正在研发当中。后台系统分为两块，一个是组件类开发，一个是服务类开发。组件主要是服务框架、训练平台、容器平台，还有一些分布式存储组件。模型服务主要是针对这个应用来开发一些专用的系统，用专用的应用服务对接。
上图是我们的平台架构，首先是数据搜集，主要依靠Kafka，对于老系统自有一套收集机制，数据搜集完成进入Hadoop和关系DB。数据清洗主要依靠hive和spark，hive实现hql，spark进行复杂的数据处理。除此之外还要做一些洞察分析，分为两块一个是单表快速实时分析，第二个是多表关联实时分析。单表主要用Druid & ES做多维，多表关联主要靠Presto & Impala。还有一些用matlab, SAS做精算量化模型，还用Tensorflow做深度学习，用Hbase，Redis主要做画像存储，提供实时查询，还有一些容器平台对外提供容器调用。
接下来讲下我们用AI技术干嘛，AI在金融领域用的还是很广，很多业务都是靠数据推动，金融对数据依赖性很强。具体应用有代理人管理，平安有百万级的代理人，利用AI算法管理代理人的招聘、销售、升级，还有智慧客服、智慧续收、智慧理赔、坐席等应用于很多场景。
数据是核心，接下来讲一下我们的数据以及数据处理情况。保险行业做数据挖掘遇到的挑战很多，第一个挑战就是决策周期长，低频交互，比如保险非日常消费品/非必需，消费决策过程比较理性。因此模型有没有效都要经过很长的周期检验，在这个周期内都将面临很大的风险。再一个数据比较复杂，稳定性差。数据复杂体现在首先业务线很多，每个业务线存储介质也有很多，每个数据产生的场景也不同，数据种类差异也很大，有文本、LBS，还有一些图像的、自然语言的。还有一个成本比较高，互联网所做的模型都要经过A/B text，但是保险行业不能这样执行。
那么如何解决这些问题呢，大致从以下三个方面解决画像产生、质量检验、数据embedding。首先就是画像如何产生，接着对数据进行检验，因为获取的数据并不一定可靠，然后对数据进行embedding，做embedding的原因就是数据比较复杂，需要对数据提供一种规范化的表示。
建立画像生产首先建立数据分层（ODS、DW、DM、MM），这种数据分层主要是偏业务，虽然没有技术难点但是将其建好不容易。然后做数据模式抽象统一，针对行为数据、事实数据和图像三类数据进行抽象统一。每天产生的行为数据很多，如保险打电话、理赔、网上点击按钮等，归类行为五要素，即什么人在什么时间对什么对象做了什么动作以及这个动作的强度。事实三元组即主语、谓语、宾语，对图像就做embedding。将数据抽象统一后做画像，画像有很多种做法，第一种就是作坊式生产，依据领导要求生存画像，这样比较累。目前标准是画像需求格式要标准化，从而实现自动化的生产机制，这样做的好处就是首先节省人力，需求可以重复利用。
接下来讲一下数据质量如何检验，质量检验一直是个难点，其指标很复杂，时间很差，很难判断计算是否准确。主要从三个方面入手，首先稳定性，给出的模型虽然很难判断其稳定性但是需要知道其不稳定性多大。第二个观察其重要性，有些指标现实中很重要但是模型中表现不重要，这种建模出问题，因此需要判断变量在模型中的重要性，评价指标有IV值、卡方、变量重要性（线性模型中的权重、算法中出现的频率）。接着需要剔除相关变量，检验相关性的指标有相关性系数、PCA/RUFS、方差膨胀因子，除此之外还会降维（PCA不够稳定，因此用了RUFS算法）。为检验稳定性开发工具spark+python，实现数配置灵活，一键式输出结果。
数据embedding方法有很多，如图像embedding、单词embedding、图节点embedding。首先将结构化数据人工组合，然后用GBDT做特征组合，以及FM编码，利用低置分解的向量来做特征表示，现在可以利用KB编码。对文本数据主要利用TF/IDF模型，word2vec，图像数据进行SITF以及CNN。主要的工作是对数据做embedding，与后面的数据结合起来，使其更加统一。
接下讲一下如何进行算法和模型的训练，目前主要的还是基于分布式或者并行机器学习。在面对数据量大，模型复杂、参数大，并行运行平台能解决这个问题，平台要求通信高效、容错可靠、描述能力强，一个机器不能运行所有算法的原因就是其无法描述这个算法，因此需要一个描述能力强的平台。目前并行的种类有模型并行、数据并行，还有混合并行。目前用的比较多的是数据并行，将数据先切分，分配到每个worker计算，得出一个梯度传入模型，模型将其汇聚，返回一个worker，然后利用worker进行本地模型的更新。
分布式机器学习需要描述能力强，简化下就是编程范式问题。如面向过程、面向对象不同，这里的范式是这种范式是否能完整描述算法。范式最早的是MP，主要实现是MPI，但是它只是提供基本的通信原语，编程几乎无限制，编程门槛高，没有错误恢复机制。后来又MR，主要是研究Hadoop，编程简单，能容错，但是限定严格，不灵活，通过磁盘交换数据，效率低。接下来就DAG（有向无环图），典型实现就是spark，内存计算，限定放宽，可以灵活实现复杂的算法，不能有环，不能支持大量迭代，目的是容错。再者就是计算图，tensorflow是典型代表，好处就是自动求微分，支持任意迭代，可以实现绝大部分NN算法；缺点就是容错能力弱。后来出现了动态计算图，主要代表有Torch，还有tensorflow也支持，支持计算中更改图，而且很实用RNN。
参数更新模型解决的是在一个集群中如何将worker同步起来，首先的方法是BSP，主要有Pregel(未开源)、Spark，如果有10个worker完成一轮将参数传给中心节点，更新完再传回来，这种方式比较慢，但是能够保证收敛。然后就是ASP，全异步，因此主要用来单机多核，利用共享类型存储模型；这种方式是随机更新无收敛保证，如果模型是高度稀疏，冲突较少，有一定的正则化效果。SSP的典型实现是petuum，最快的worker和最慢的worker的bound超过阈值时同步参数，好处是速度快，保证收敛。说道参数更新，就不得不说一下ps-lite，它是基于PS，特点是模型依靠分布式存储，支持海量参数，再者支持以上三种更新模式。这是机器学习需要了解的两个方面。
接下来分享一下我们是如何实现的。首先分布式机器学习集群依靠spark，spark特点有：以DAG描述计算任务,以RDD抽象数据操作，基于内存的数据交换，同步参数更新(BSP),与生产环境无缝对接,主要采用数据并行。基于spark分布式集群开发了很多包，MLlib包实现决策树、SVN、LR；splash实现了MCMC,Gibbs Sampling,LDA, 比mllib快20倍；还有一个是Deep Learning4j，主要是在spark上做深度学习，支持GPU，但没有TensorFlow灵活不能自动写网络结构；接下来就是我们实现的PAMLkit，支持NB,Ada Grad+FM,FTRL+LR算法。
基于spark分布式集群实战经验首要的一点是要理解算法，不能有偏差。接下来就是代码结构良好: 梯度类(Gradient),正则项类(Updater)，优化器类(Optimizer)相互独立。还有就是相关调优经验，上面的都是我们实战从坑里面总结出来的。尽量使用稀疏向量，且以稀疏方式遍历或计算，如果不注意会引起性能恶化。
接下来讲一下在TensorFlow下如何做深度学习。TensorFlow应用主要是面向结构化数据，辅以视觉文本，DNN算法应用广泛，其他相关算法（CNN、AE）已开始成功应用，强化学习正在研发中。TensorFlow分布式特点：编码组建训练集群并分配任务； 需要手动在各个机器启动进程；需要提前切分数据，并手拷贝到各个机器；基本没有容错机制。训练方式经过了以下三个阶段：单机单卡，整体一次性读入数据，迭代时逐batch送入显存；后来进入单机双卡，采用输入队列，出队后在GPU之间轮发数据。同步模式，每GPU的梯度做平均后更新参数；后来进入多机多卡，采用Between graph,准同步模式。提前切分数据，不用手动启动进程，主要是基于pdsh分发数据，启动服务。
很多时候是基于spark和TensorFlow联合建模，spark主要依靠其并行能力，TensorFlow建立复杂模型。怎样将两者结合起来，例如GBDT+FM+DNN模型，GBDT+FM在spark上训练，DNN在TensorFlow上。第一个阶段是将spark的输出直接拷贝到TensorFlow上，TensorFlow上切分数据然后拷贝到各个机器上去。目前是将spark训练输出的数据放到HDFS，然后利用PDSH启动TensorFlow上各个worker进程，直接读取hdfs上部分数据，继续训练。目前正在研发Spark与tensorflow集群共存，每个RDD分区内启动一个计算图，一栈式编程。
模型训练完需要提供服务，提供服务面临的挑战有：模型众多，建模历史悠久，业务需求宽广，投入生产的模型多达数百个，分散运行，监控困难。另一个就是建模平台很多，现有MATLAB，java，python，SAS，R，Spark，tensorflow等建模平台；因为有很多量化和精算模型很重要。然后算法策略复杂，包括决策树类算法，各种线性模型，深度学习模型，传统时序算法等，且常组合各类算法。还有数据加工各异，数据加工很乱、个性化，模型同时包括历史数据和实时数据，且需要在线join，不同模型对数据需要进行不同的加工。系统需要达到目标：集中管理、统一监控；第二个上线快速，节约资源,可伸缩高可靠；不能限制建模工程师，支持跨平台；需要支持典型的模型格式转换；需要定义典型的数据加工算子。
为了实现目标借助了很多开源组件开发。框架采用thrift，特点是：跨语言通信，支持python，java，c++等；u成熟稳定，开源十年，使用广泛；轻便简单，有编译器(不足3M)即可。服务协调用zookeeper，在线存储用redis，对外通信库用Netty，运行容器用docker，负载均衡用Nginx等。
模型应用架构分为三层：模型处理层、数据计算层、接口层。模型处理层其核心是模型解析器实现跨平台、跨语言，输出格式三种PMML（线性模型）、protobuf（TensorFlow）、自定义格式。将模型训练好形成模型文件，线上算法服务会加载这些文件提供服务。业务应用器调用模型，支持http协议，利用负载均衡器定义到各个应用服务，应用服务就是对应数据计算层，定义的相关算子是为数据处理开发，实现特征组合，将其传入模型路由器，模型路由器调用相关服务。还有一个管理监控平台。
——END
