对百度来说，联邦学习+金融会产生怎样的火花？
雷锋网AI金融评论推出的《BATJ高管公开课》第四期，就邀请到了百度智能云智慧金融事业部算法负责人谢国斌做客线上讲堂，揭秘百度智能云在金融领域的安全计算布局和技术思考。
此次课程，他将分享基于联邦学习技术的百度金融安全计算平台（度信）建设与实际应用，讲述如何借力安全技术架构、脱敏方法和合规制度设计，在“用户充分授权、数据来源合法合规”前提下，打破数据孤岛，实现多方数据加密融合建模，助力金融企业业务的开展。
以下为谢国斌演讲全文内容，AI金融评论做了不改变原意的编辑：
百度智能云的数据孤岛破解之道
我们在跟很多的金融客户进行沟通的时候，他们普遍面临的痛点，就是数据孤岛和隐私保护的问题。
目前的现状是，一方面要保护客户的隐私，另外一方面，数据孤岛在不同的程度上存在着，去年央行发布的金融科技三年发展规划里，也强调了要“消除信息的壁垒；数据融合。”
今年4月，国务院也在《关于构建更加完善的要素市场化配置体制机制的意见》里，强调了数据的共享、数据资源的整合和安全保护。
所以，“数据孤岛”和“隐私保护”两者的困境，在业内一直是个难题。
行业里做这块技术的公司，一般有如下路径在积极探索：
其中一种就是联邦学习；还有与之接近的，就是在做参数交换、梯度交换的时候，会用到的多方安全计算。另一种以硬件加密为主，可信计算（TEE），在内存里做安全加密。以及基于云安全，做安全隔离域的方法。
基于刚才说到的痛点，百度推出了度信金融安全计算平台，做数据融合，前提是强调用户要充分授权，数据来源要合法、合规。也提出了联合建模产品，拒绝数据孤岛的存在，产品对上面几种路径都是支持的。
今天的要点，主要是分享在联邦学习和多方安全计算技术路径上，我们所做的尝试和产品的研发。
我们的金融安全计算平台有以下特点：
平台主要服务于金融行业to B客户，会考虑行业里特别关注的一些场景，比如营销、风控、投研、反欺诈。我们基于金融的建模，有一些专用的功能点增强。从安全特性上，无论硬件软件，有多种的方式进行技术加固。
金融云专区上，我们通过了国家的四级等级保护；数据流通方面，我们今年通过了信通院的相关技术测评。
从计算建模层面看，我们是自主操作，甲方乙方各自操作，全程免编码，流程很简单，性能比同类的算法也要快。
私有云、公有云和私有化方面，我们有多种方式部署，产品目前也能提供工业级的使用体验，包括严格的工程封装、项目的验证实测，还有百度沉淀的金融行业案例、提供金融行业的场景的解决方案。
度信金融安全计算平台的技术方案
我们这个平台建设，刚才提到用三大类技术方案，统一前端入口和统一后台架构。
后台的架构，从下往上看，分为执行层、应用层、操作层、场景层。
从执行层看，中间是基于多方计算的联邦学习引擎，引擎最下面是基于加密的密码学算法和一些常用的不经意传输、同态加密、密钥分享等。
往上是基于密码学算法的多方安全计算，双方或多方的加密数据的协调和交换，隐私的PSI对齐、ID化、联邦分析和联邦学习。
再往上是应用层一些基于模型的算法的应用，这个是标准的机器学习建模流程。
操作层有可视化的操作平台和4A安全赋能金融行业，打造营销风控端对端的场景化建模功能。
我们的平台架构，需要满足三个不同的客户需求：
定制化方案要满足客户不同的安全等级要求；有客户对建模要求较高，那对算子、算法、模型多样性、交互和应用性方面要求就高一些，我们也会提供类似的解决方案。还有对不同的资源配置，构建私有云、公有云和专有云支撑，支持不同的部署方案。
这个平台的操作很简单，就是三个步骤。
先是合作的AB双方，完成本地数据的上传。原则上都是上传到自己的IDC机房里，数据不出域。
第二步细分为几个小步骤：
1.数据的融合，会通过隐私保护的求交技术PSI，达到双方的数据的可用不可见。
强调一下，融合不会泄露双方的数据隐私，比如说甲方有一亿的客户，B方有5000万的客户，双方去求交集，求出来只有500万客户，那么我们只知道这500万的交集，剩下的客户群双方都是不知道的。
即使求交了这500万的客户，我们也只有某一个主要的使用方，比如甲方银行在使用的时候，才知道这500万相互求交的客户号码是什么。
2.求交的这批客户，我们会进行简单的特征工程，一些算法模型训练，包括像机器学习的逻辑回归、GBDT等，也按照这个数据拆分，做完模型训练、输出模型报告以后，进行模式部署、模型推理和预测发布。
第一步上传样本比较简单，把数据上传以后，摁一个按键，就会看到这一横行里数据的上传成功，然后AB双方在这个地方点鼠标发布，数据才传到本地的服务器上面。
第二步模型训练，会自动包含刚才说的样本对齐，包括可选的特征工程，还有算法参数、算法选择等。
在模型训练过程中，等它出来一个结果，就会有一些像我这里截屏的模型，配置基本信息，比如双方对齐了多少样本，有哪一些特征？这里只能看到特征名称。我们算法所涉及的每一个主要参数是什么样的。这里以逻辑式回归为例，生成模型评估报告，像ROC、KS值等等，就完成整个模型训练。
第三步就是模型预测，需要在页面新建预测任务名称，包括描述，还有我们选择哪个预测的模型。生成的模型在这里做选择，再选择要预测的数据集，点蓝色按钮完成整个模型预测过程。一定时间后，就会看到右下角预测成功的显示，整个模型的离线预测就完成了，也可以用新建预测服务以API的方式供外调用。
我们平台的设计理念，是全程免编码，通过鼠标的拖拽来完成的。
度信平台在银行业、保险业的应用
银行信贷产品的互联网营销
这家银行开展信贷业务时，需要通过互联网去线上获客，但它并没有这种线上资源或流量去投放，也没有相关风险管理经验，于是它就跟某家互联网公司进行渠道上的联合建模，实现精准获客和控制风险。
首先是银行把他的数据和互联网合作方，把数据在自己的机房里边准备好，然后各自联邦学习时，上传梯度参数。
在互联网渠道这一端，主要是上传数据，建模发生在银行这端自行操作，就完成了整个建模过程，达到了数据模型建设，完成后确定合适人群。
第三步，精准广告投放，包括精准获客，这部分我们项目的客户日均调用量是50万笔。整体贷后表现非常好，降低了风险，也节约了这家银行的成本。
线上风控+联邦学习
因为银行没有过往的一些互联网行为信息，也需要为此通过互联网渠道来合作、来进行联合建模。联邦学习最后的效果就是，让申请率提升了，通过率又稳定在一定的范围内，不良率低于银行业同业平均水平。
这个案例，我们推送的贷款客户金额是超过千万；通过率控制在稳定范围；该案例的不良贷款率是0.38 ，比去年银行业1.81的不良率低了不少。
不同险种交叉营销
这个案例是一家车险公司的业务，在客户里筛选健康险的意向用户，进行精准点对点促销。建模流程与上个案例类似，由保险公司提供的高响应人群样本和互联网公司的数据进行融合训练，最后结果运用于全量的车险客户群。
效果上，这个模型的AUC值达到了0.76，减少了对客户的打扰，也降低了营销的成本。
联邦学习落地金融的关键技术点
联邦学习本质上是软件加密技术，数据不出域、不出本企业，主要是通过梯度参数出域。从本质上来说是去中心化的方案。横向联邦由谷歌在2016年的时候研发出来，即数据的水平切分，主要用于金融同业间的数据融合。
横向联邦学习的计算步骤主要有四：双方发送加密的梯度，安全的聚合，发送聚合的加密梯度参数，再解密梯度更新模型。
纵向联邦学习基于数据的垂直细分，主要用于金融业和非金融行业，特别是像一家银行和一家互联网公司的数据融合。两家公司的客户群很多时候是重叠的，特征互补。
首先有分发公钥，加密交换中间的结果，再进行加密梯度和损失的计算，然后更新模型。
在和金融企业沟通的时候，我们发现他们关注的点有这些：
整个联邦学习里，金融企业运用最多的是纵向联邦学习，金融机构更想看到的是和他非同业之间的数据融合。
银行在和第三方机构合作时，非常强调这些数据进来以后，对指标的一些增量贡献，在意的是在现有基础上的提升。如果在现有基础上，引入的数据源没有很大幅度的提升、效果不明显，对金融机构的吸引力就会降低。
同时金融机构也强调数据源的差异化，如果数据来源都很类似，那对指标的贡献、对模型效果，提升度不是很大。
联邦学习是整个框架里的主要技术。
另外，多方安全计算所涉及的加密技术，其主要原理如图左所示，四个参与方在针对任何一方都没有可信的情况下，安全地进行多方协同计算。
在一个分布式的网络中，多个的参与实体各自持有秘密的输入，完成对某函数的计算；但是要求每一个参与实体，除了计算的最终结果以外，其他的中间过程，包括自己其他客户的原始数据，任何的输入数据都是不可以看到、都是不可以获得的，这保证了参与各方的数据的安全性。
在安全计算过程中，所用到的一些密码学或加密技术，概括起来有这么七种。
混淆电路，来自于物理学电路原理：一堆人各自拥有隐私数据，想把数据合起来进行计算，但又不想把数据交换给别人，典型的案例就是百万富翁问题。
不经意传输，服务的某一个接收方，以不经意的方式得到服务的发送方输入的一些信息、信号，这样就可以保护接受者的隐私不被发送者所知道。
秘密的比较协议，计算的双方各输入一个数值，但是他们又希望在不向对方泄露自己的数据的前提下，比较出这两个数的大小。
同态加密，用这种方法先计算，后解密，也等价于先解密后计算。同态加密里也有加法同态、乘法同态，包括全同态、偏同态、半同态等，它在联邦学习中应用也较多。
秘密分享，将秘密分割存储，多个参与者要相互协作才能恢复秘密的消息，如果有一方没有参与，是没有办法把这个秘密完全恢复出来的。
零知识证明，证明者能够在不向验证者提供任何有用的信息情况下，使验证者相信某个论断是正确的。
差分隐私，这在业界应用也比较多。
百度在多方安全计算方面，有自己的MPC平台架构。我们的平台架构分为这么六层，从基础到应用，有运行环境基于DOCKER的，还有基于云和SERVER的。
在基础的运行环境往上，有刚才说到的六七种加密算法。再往上是整个系统包括TLS、4A这一块的安全。再往上是系统平台层，有用户角色管理，包括数据和分布式调度、监控等。再往上看是数据的接入，再到数据的应用。
下面我会重点介绍三类算法，都是百度自研的。
第一种是逻辑回归，逻辑回归是常用的二分类的分类器，在这种分类器上面我们加了一个基于PrivC的加密算法的逻辑回归，这种算法是基于MPC的安全学习。
我们在19年的安全顶会上面发表了关于这个算法的文章，特点是训练速度和在公开的服务器上的明文相比，速度大概会是在明文算法的40倍以内，也就是明文算法假如要用时1分钟，那么我们要用时40分钟。
这里有一个案例，就是我们基于深度MNIST公开数据集，6万行784位的运算，我们用时25秒，时间还是比较快的。
在下面的截图，我们看到一些Table2，在一些加减还有一些常规的比较上面，基于我们自研的PrivC的算法和公开的其他的一些加密算法，像ABY、EMP、SPDZ等等，我们的运算速度都比他们快，标出的黑色数值是越小越好。
我们的准确率和明文算法比，会达到99%左右，比明文算法低一点点，一般的梯度，有时候建模如果控制得不太好，都会有一些模型的损耗，而我们的损耗是比较少的。
第二种算法，就是基于梯度提升的算法，有GBDT、XGBoost,再快一点的有LightGBM,我们这种算法叫SecureGBM,它是在LightGBM级别的基础上改造而成的。
基于 LightGBM基础上改造而成的这种算法，我们也是发表在19年的IEEE国际大数据会议上，大家看到左下角有一个截图，红色的框是百度自研的叫SecureGBM,蓝色的框，LightGBM-（A,B）就是明文算法，我们算法最后的结果和同类的最好的明文算法去比，在没有用任何加密的和普通的建模相同的条件下，AUC值的差距大概是在3%以内。
我们也比较了其他的一些明文算法，在这个图里边是-A或者-B，它是用了一些加密的联邦的一些算法去比AUC值，我们的算法都是比其它的算法会高一些，但我们会比明文的算法大概低三个AUC值，在3%以内。
第二个是它的运算速度，从这个截图看到，对比了16,000个样本，我们的算法和明文算法去比的话，我们的速度大概是明文算法的6倍，也就是明文算法如果用一分钟的话，我们会用六分钟，这个已经是非常好的效果了。
这个地方我们也提到，我们现在用的这个Paper里边是16,000个样本，如果样本增加到10万个，或者再往上增加，我们这个算法的运算效率会更高。
那么我们SecureGBM和明文算法的LightGBM，双方数据在一起，比较了在训练集上的AUC值和F1值，大家会看到有一条红线和一条蓝线，在截图里面红线和蓝线绝大多数时候是靠在一起的，走势是相同的，非常的接近。
说明我们的这个算法和明文的LightGBM的算法，在AUC值、在F1、在训练集上和测试集上，达到了非常类似的一个效果。
第三种算法基于深度学习，PaddleFL，是在我们百度自研的一个开源的深度学习框架飞桨的基础上，研发出来的开源的联邦学习框架。
下面是开源框架的github的网址，通过PaddleFL，使用人员可以很轻松的去复制和比较不同的联邦学习算法，也可以在分布式的大规模集群里面去使用。
这种PaddleFL主要用在深度学习算法里边，用在计算机视觉、自然语言处理和推荐算法的一些领域，也提供一些传统的机器学习的训练策略。
比如说像多任务学习，还有一些迁移学习、主动学习等等，我们底层也提供基于分布式的训练和Kubernetes的训练任务的弹性的调度能力，可以进行全站开源软件的侵入和部署，下面是基于我们的飞桨的一个的架构图。
接下来是编程模型、参数服务器、到端侧训练和弹性调度，再往上是我们联邦学习的训练策略及应用。
联邦学习策略这块我们也有纵向的联邦学习，刚才提到的PrivC的逻辑回归，横向的联邦学习，还包括DPSGD基于差分隐私的随机梯度等等。
我们也有常态的一些机器学习，像迁移学习，多任务学习，主动学习等基于联邦学习的任务，还有基于深度学习的自然语言处理、视觉、推荐这一块的学习任务，都是在PaddleFL的基础上来做深度联邦学习的建模。
PaddleFL的架构设计，图的左边叫编译Compile Time，是首先通过联邦策略，去设计一些算法策略，然后在中间设计训练策略，再用分布式的配置，合成以后，传到中间任务的调度上面。任务调度再传到参数的任务和训练的任务上面生成了job以后，再传到这边运行。
运行这一块有参数的服务器和worker，再下面是调度器，整个就会把服务提起来，然后进行分布式的训练，这是PaddleFL的架构设计。
同理，我们也有基于MPC的联邦学习，分成三部分，一是图右部分，基于数据的准备，首先有私有数据的对齐和数据加密及分发。
二是训练和推理过程，和Paddle的运行模式一样。首先要定义协议，在策略训练和推理完成后，就会到这个图的最右边进行结果的重构。
这一块就会把模型的结果或者预测结果，由加密方以加密的形式输出，结果方可以收集加密的结果，在PFM工具中进行解密，再将明文的结果传递给用户，就完成了整个MPC的联邦学习过程。
安全保证是金融企业最高优关注点
我们先看看现有的模式，现有的模式只有几个，在没有用到联邦学习的时候，状态是自己的IDC机房的网络和外界是隔离的，没有联通互联网，数据不进不出，因为只用到自己的核心系统的数据，数据是物理隔离的。
但是这个模式最大的问题，就是在它的建模过程中，会存在着一些天花板，比如刚才提到的KS值，如果做到0.35了，就再也不能再往上做了。
模型效果更多的取决于特征工程，而他又没有用过外面的无论是互联网，还有政府，一些运营商的一些领域的数据，那么一些风控也好，营销的行为它是拿不到的，模型的上限是由多维度、多样性来决定的，所以达不到很好的建模效果。
于是就衍生出来第二种模式，叫标准分的调用模式，标准分的第二个模式，它也是有自有机房，但是它的网络变成不是隔离的了，而是单通道的，就是它的数据只进不出。
在网络这块，因为开了一个单向的通道，有可能存在一些被黑客攻击的风险，这个标准分的调用也有一些弊端。
大家知道，进来的只是一些标准分，也就是说，外面的数据过来的可能就是一个变量或者两个变量，它是一个高维特征压缩以后的、降维以后的一些特征的输入，每次输入只有那么两三个特征。
这种高维特征压缩降到两三个维度以后，有非常多的特征信息是损失了的，所以它提升的建模效果在信贷场景可能只提升那么一两个点，比如像KS值是0.35，提升到0.37、0.38就到了天花板了。
我们今天谈到联邦学习的模式，它的数据通道是双通道的，双方要进行梯度或模型参数的交换。
首先，双方数据对上面的一个中间节点要进行上传，但是它的原始数据没有出域，它的参数数据或者模型的参数或者梯度参数，是通过加密的方式来出域的。
从这个角度来看，因为它的网络通道打开了，存在潜在的被黑客去攻击的风险。梯度参数的话，从现在的业内的研究来看，也存在一些被反解，或者一些隐私被攻击的方法。
还有一个，它有一个强烈假设，就是需要参与的双方或者各方，需要满足诚实、半诚实模型的原则，如果有一方有严重的欺诈，去改变了模型的一些参数，或者是一些游戏规则，模型的安全也会受到一些挑战。
这是联邦学习目前和上面的现有模式、标准的模式相比，所面临的一些优点和缺点。
那么这里会就提到模型提效，模型提效是一把双刃剑。现有模式下，在右边的这样一个方程式，目标标签Y是来自于金融企业本身，它的X特征也是来自于这家企业，企业只用自有的数据建模，没有外部数据带来模型效果提升，就会面临天花板。
我们再看联邦学习这种方式，刚才提到，通过梯度参数的交换来建立模型，那么基本上双方数据没有降维，外部提升的最大好处就是，带来的模型效果提升非常大，与明文相比的话，它的精度损失基本上还是比较小的。
但是，在和很多金融企业沟通后，知道它有非常大的短板，企业有各种各样的顾虑。
1.建模的过程中，即使想用联邦学习来进行建模，金融企业很多时候并不愿意把自己的特征放进来，但是可能只会将自己客户的ID和目标变量Y放进来，因为金融企业会觉得用联邦学习来建模，有可能存在一些数据安全的问题。
2.他们也希望拿到一些数据以后，再做二次建模，以满足金融监管的要求，因为在金融监管这一块，特别是在信贷风控的场景，希望金融机构要自控这个模型本身，而不能把这个模型交给外部的机构去控制。
安全保证和数据提效前提下的得与舍
在数据的安全保证和数据提效的前提下，联邦学习还要面对什么样的得和舍呢？
第一个，从运算速度来看，现有的银行在自己的机房里面进行明文计算的数据建模，它的特点是运算速度很快，可以用像spark、Tensorflow、PaddlePaddle等分布式技术去做这种很成熟的运算。
但是到联邦学习就不一样了，刚才提到，它的训练速度至少会比明文计算，少则慢一个数量级，慢10倍几十倍，也有慢两个数量级几百倍的这种可能性。
第二块就是它现有的分布式技术还不太成熟，这是他在速度这一块可能需要去考量的。
第二个，从算法种类来说，明文算法它是基于Python的开源社区，算法生态非常多，上千种上万种，顶级论文的开源代码，基本上就是按天、按周来迭代，更新的频次非常快。
但是在联邦学习的算法过程中，要考虑到数据参数的加密，所以它的研发非常困难，我们的算法种类相对而言都是比较少的。业界现在能看到的也就是那么几种或者几十种，并且也不可能把最新的算法研发出来用在联邦学习这个领域。
第三块，就是产品的应用性，因为现在基于明文数据的这种算法，AI开发平台有非常多，支持多种框架，还有它和数据的中台的融合，非常好对接。
那么对纯代码方式来讲，金融行业去使用时，因为金融行业很多用户也不是经常做coding，所以他的学习曲线比较难、比较高。
刚才也提到如果用代码这种方式，它跟这个操作系统有些时候需要linux shell脚本方式进行交互，那么它的安全性可能会存在一些缺陷。百度的度信平台在这一块用纯界面的方式，也面临着一些开发的周期和实施的难度。这个是联邦学习与建模要考虑的问题。
所以我们在考虑安全，在考虑数据对建模效果业务绩效的前提下，我们在运算速度上，在算法的种类的选择上，在产品的应用上，都做了一些权衡和一些损失，但有些时候这种损失和这种权衡是值得的。
下面一点，就是百度金融专有云，如果是联邦学习在我们的金融云、专有云上面进行部署的话，我们还额外提供七重的数据安全保障。
这七重的数据安全保障在这个图里边用1234567都标注出来了。一块是我们提供异地的灾备，我们在武汉、北京和上海有异地的百度金融云专区。
在数据的交换过程中，我们会提供一些芯片级的算法级的加密，包括在网络的通路上，也提供一些加密的传输，让加密的数据被截取以后都是不可用、不可解的。我们参与方的数据在云上的链路也好，在云上的一些硬件的里面，双方都是互不可见的。
安全的数据脱敏方法和合规制度保障
在完成了整个建模的过程以后，比如说金融企业的数据要有用户要查处，最后模型在使用的时候，有一个数据的健全，如果没有授权的话，是不可以去使用产出模型的。
除了联邦学习以外，我们在整个云上、在物理链路上、存储量上、硬件上做了各种各样的加密去保证安全，而不只是运用了联邦学习技术本身，或者只是开发一个平台。
在和金融企业的沟通中，我们发现，即便双方要进行联邦数据的融合建模，也可以采取刚才说到的，双方先有两个数据宽表，然后再进行融合的联邦学习。
在生成这两个双方的数据宽表的同时，还可以采取一些更加安全的数据脱敏方法，用的比较多的就是K-匿名化，这个是保护客户数据隐私的一种重要方法。
我们希望双方在生成数据宽表的时候，甲方和乙方都能够采用类似于匿名化的技术，让双方的原始特征数据脱敏得比较彻底，不能够被反推。虽然联邦学习本身也非常安全，在这个基础上，我们能够用更多的数据脱敏的方法。
右边这一种也是类似的，我们会用差分隐私的一个方法，在数据集中里面产生一定的噪声，这种随机造成它可以通过一些概率分布前置来产生，这样就在设计过程中很难去推断出客户的一些隐私。
和金融机构合作时，在数据的安全管控上，我们也会提供一整套的安全的合规的保障制度。
首先是从公司的治理层面，数据和流程层面及安全的能力层面，我们从不同的角度去看这家金融企业和它合作的另外一个互联网企业，只要用到度信平台，我们会提供一整套的关于安全保障机制的建议。
还有一块就是数据的生命周期安全，我们考虑到六个环节，数据的收集和产生要合规，我们有数据的分类分级和安全日志。那么在传输和传递过程中，有加密和传输的安全的监控。
第三块就是存储，在存储的安全和数据的加密备份这一块，也要考虑安全。
第四就是它整个数据的加工的环境，使用方和用户授权等等，也要保证安全。
第五个环节涉及整个的流通与共享，包括对内流通和对外流通，我们要考虑相关的安全性。
当我们使用完联邦学习以后，也要有相应的动作，不要让数据留存在双方的服务器里边。整个的安全制度合规保障和数据的生命周期，都是我们在实践中慢慢总结出来的。
对于整个联邦学习，额外增加了一些针对金融行业更加安全的一些举措和方法论。
我们也通过度信在这样一个平台的实施过程中，慢慢把这种方法论传递给金融机构，传递给合作方，让我们整个在运用联邦学习的过程中，更加保证整个数据的安全，让数据可用不可见。
