联邦学习应用思考：需求还是方法？

　　徐葳 清华大学交叉信息研究院长聘副教授、华控清交首席科学家

　　前言：

　　目前，“联邦学习”这个术语在市场上存在很多认识上的误解和混淆，主要原因是其既在广义上表达了保护数据前提下联合多方数据训练模型的需求，又在狭义上表示了一类通过暴露部分数据信息来提升训练性能的方法。有趣的是，作为广义上的需求，它强调为了保护数据安全，可以牺牲部分准确性;但作为狭义的方法，它反而强调通过牺牲安全来换取性能提升。

　　一、初心：联邦学习要达到的目标是什么？

　　1.联邦学习的广义定义：解决联合建模的问题或需求

　　人们在进行机器学习任务时发现必须面临的一个关键问题是：需要更多的数据从而才能得到一个好的模型。而更多的数据意味着：(1)更多样本点，以便减少模型偏差(bias)，提升模型质量;(2)一个标签(例如一个用户是否还钱);(3)更多维度，以便更全面刻画一个对象。但是这些额外数据经常由不同人持有，并且可能很敏感，没人愿意拿出来共享、生怕暴露这些数据(例如用户身份和某些行为特征)，但是大家还都希望从训练出来的更好的模型中获益。

　　上述这一类问题，就是“联邦学习”的需求。从广义上讲，能够解决这一需求的机器学习方法，即多个数据方联合训练一个机器学习模型的技术，都叫做“联邦学习”。因此，广义上的联邦学习是一个问题，或者说是需求，而不是一种技术或解决方案。

　　事实上，这一需求在多年前就已有解决方案。在密码理论领域，采用多方数据训练模型是多方安全计算技术的一个具体应用，理论上讲我们可以用一个“多方计算”(也叫多方安全计算，Multi-party Computation, MPC)的方案来描述整个训练过程;在数据挖掘领域，人们很早就提出了如k-匿名、差分隐私等方法;硬件领域，人们试图做出更可信的硬件芯片来保证数据不泄露;近期人们也尝试采取迁移学习等手段，试图隐藏和个人相关的敏感信息。

　　2.联邦学习的狭义定义：一类特定算法

　　然而现在市场上，联邦学习这个术语被局限于一个更狭义的定义。现在人们普遍认为，联邦学习是和多方安全计算、可信执行环境、差分隐私等并列的一种隐私保护计算技术，这实际上采用的是一种狭义的定义。这种定义下的联邦学习特指一类算法，其本质特征是在多个数据控制方运行，能够让各数据方之间只交换了某些模型训练的中间数据。如果我们假设这些被交换的数据不包含敏感信息，那么这个模型的训练过程就能达到我们想要的数据隐私保护目标。然而这个假设是否真实成立，目前尚无理论上的证明。

　　狭义的联邦学习，作为一种独特的方法提出，其主要动机是试图在此前的几种方法中取得一种平衡，即解决如下问题：(1)多方计算等密码学方法计算和通讯开销高;(2)k-匿名暴露信息太多;(3)在原始数据上加入差分隐私需要的噪声，对于多次迭代的机器学习结果的准确度影响太大;(4)硬件可信程度未知。也就是说，狭义联邦学习的主要目标是试图通过有选择地暴露一些信息，从而实现训练精度、训练速度和数据隐私安全的平衡。本文下述“联邦学习”均是基于这一狭义意义上的方法。

　　二、设计：联邦学习理论上的挑战

　　联邦学习相比之前的隐私保护计算技术，其本质特征是暴露某些中间数据，并假设了这些数据不泄露敏感信息。然而越来越多的研究发现，这一假设未必成立。

　　1.联邦学习真的能做到“数据不动”么？

　　联邦学习过程中虽然没有发送任何原始数据，但它暴露的数据主要有两类：一是模型迭代训练中每轮的中间结果，二是在纵向联邦学习中暴露的双方数据交集中的元素。这一节我们着重探讨第一类数据暴露，第二类留到第三节中讨论。

　　一个常见的认知误区是，不发送原始数据，做到“数据不动”就是安全的。这里实际有个非常强的安全假设，即联邦学习每次迭代中暴露的中间结果，不会泄露有价值的信息。很多工作都证明了这个安全假设是不容易达到的。

　　联邦学习每次迭代均会暴露中间结果，这一中间结果可能是每方提供的梯度，或者是多方聚合的梯度，或者是一个本轮结束之后的模型中间结果。这里的核心问题在于，中间结果是一个高维的向量或矩阵，在很多模型里，这个中间结果都缺少可解释性。一个参与方可以根据这些暴露的结果以及结果之间的差异性去推算一些不应该暴露的信息[1][2][3][4]。中间结果具体会泄露什么信息很难确定，因此其安全性无法得到证明。有一些针对这一问题“打补丁”的方法，例如利用密码学方法来计算梯度聚合，但无论如何加密，都不可避免地会向各方暴露一个本轮迭代训练的中间结果，否则就失去了这一方法的核心价值，即通过暴露这个结果，减少加密，从而平衡计算代价与安全。

　　也有一些方法利用差分隐私来给中间结果加一些噪声，但是这对于最终训练结果的准确性影响也是未知的。当然，一个观察是，参与方数量的增多会缓解噪音对准确性的影响。Google最初提出联邦学习应用在2C场景中，含有大量客户端，参与方数量庞大，每个参与方加上一些专门设计的噪声(噪声会互相抵消)，从而同时保证了数据隐私安全及计算准确性。但是这一方法对于只有少量参与方的情况是否有效，以及究竟可满足多少参与方的模型训练的准确性，往往与具体数据和模型相关，通用的方法仍有待探索。

　　更为深层次的问题是，联邦学习所专注的数据隐私保护一般定义在“原始数据不暴露”的层面上。然而实践中需要保护的数据特定使用价值，很多情况下在于统计信息，例如某企业的平均薪资水平、订单数，某金融机构的投资总额等。联邦学习过程中交换的高维向量，显然泄露了大量的统计信息，至于具体泄露了哪些统计信息，以及泄露这些信息的危害，一般与具体场景有关，因此非常难以判断，极易形成“虚假的安全感”。无数信息安全领域的实践证明，虚假的安全比没有安全造成的后果更加严重。

　　缓解该问题(当然不是根本性的彻底解决)的一种思路是，定义一种通用的明、密文混合计算方式，并根据不同的场景需求(安全需求、性能需求等)灵活地选择可以暴露什么，以及必须隐藏什么。也就是说，即使对于同一种机器学习算法，由于应用场景不同，也需要对算法的明文计算部分和密文计算部分进行适配性的规划和调整。

　　2.上述联邦学习中各参与方真的能诚实地参与计算么？

　　联邦学习和很多隐私保护计算技术都基于一种“半诚实”的假设。从直观上看，半诚实假设意味着参与方虽然有可能偷看或者泄露别人的数据，但是他们会遵守协议，即不会对数据造假。理论上，半诚实是一个安全假设，但在实践中，我们应该有切实有效的机制来引导和制约使各参与方遵守协议。其中重要的一类方法是通过监管，让不诚实的行为被发现和被举证，因此大家就不敢作假;另一类方法是让不诚实的行为造成的不良后果尽量少(例如只是让计算不能进行下去了，或者大家都知道结果是错的等等)。

　　但遗憾的是，联邦学习的分布式特点以及安全聚合机制往往让数据造假变得更容易，更难被发现和举证[5][6][7][8][9]。传统数据挖掘算法无论是检测数据造假还是容忍错误数据，均依赖于数据中内生的冗余信息，以及人们的先验知识。由于联邦学习交换的中间信息是高度凝练的统计信息，数据中缺乏冗余，又缺乏可解释性，这些被传递的中间结果是否是捏造的假数据，难以确认。另外，攻击者亦可通过加工假数据以逃避异常值检测[10]，从而对全局模型进行投毒攻击。由于当前市面上许多方法使用了一种仅支持加法操作的半同态加密算法来保护各方提供的梯度，造假的检测能力进一步丧失。退一步说，即使我们发现了造假行为，造假方完全可以抵赖说这些假数据就是自己的数据随机采样算出来的，理论上很难区分是其恶意造假，还是随机抽样造成的噪声。

　　更为严重的是，每方的中间结果对于模型的训练影响都很大，因此每一方都可以通过构造“有毒数据”来控制整个模型的训练结果。例如在模型中留一个后门(即某些特定样本的推理完全受恶意一方的控制)。相比于传统的模型训练，在联邦学习过程中人们更难举证这一后门是哪一方下毒造成的。许多研究已经证明，这样的攻击在横向联邦学习中广泛存在[10][11][12][13][14]，此类攻击方法在纵向联邦学习中也已经被发现。

　　《周易》上说，“慢藏诲盗”，意思是不把东西藏好了，就是教唆别人偷盗。我们认为一个技术不应该让造假变得更容易、更难被发现，因此联邦学习在这一方面仍需要很多改进。

　　从监管角度看，目前缓解上述问题的一种思路是，采取一些方法来强化联邦学习的中心管控功能，具体包括：(1)除了参数聚合，将更多的计算逻辑纳入中心化可监管的范畴;(2)使用支持密文复杂计算逻辑的密码学技术，如秘密分享(secret sharing)，这样可以最大程度上通过密文来分析数据的“造假”特征;(3)引入第三方独立行使计算或监管职责，鼓励针对高价值、敏感数据的场内流通方式，而不仅仅在联邦学习参与方之间进行计算;(4)使用存证机制，增强事后回溯和举证能力。

　　3.联邦学习真的促进了数据的公平共享么？

　　在一个公平的场景中，参与联邦学习的各方，希望共同获得一个模型，双方要么获得了相同的价值，或者获得价值少的一方能够获得额外的补偿。然而，联邦学习其实并不能达到这个效果，反而会导致数据多的一方获益更大。

　　当前国内联邦学习主要应用场景是纵向联邦学习，纵向联邦学习的第一步是隐私求交（PSI），会将交集结果暴露出来。事实上，理论上的PSI方法，本身可以保护交集结果，但是如果不暴露交集，后续计算无法实现联邦学习减少加密数据量的目的，因此我国业界常见做法就是把交集暴露出来。试想，一个大型互联网公司拥有10亿用户上网数据，一个银行拥有1000万用户金融数据。互联网公司根本不在乎暴露交集，因为几乎所有客户信息反正他已经有了，它可以通过联邦学习获得1000万银行用户标签，至少知道了这1000万人是这个银行的客户，以后不依赖于银行数据，互联网平台也可对他们进行精准营销等等。银行当然也知道了自己的哪些客户是这一互联网产品的客户，但是这个信息显然没有太大价值，因为绝大多数用户都是这个互联网产品的用户，这个不用训练也知道。银行泄露了自己客户的信息，换来的是一个模型，而且这个模型其实也不能单独使用，还需要输入只有互联网公司拥有的数据维度才能有用，所以银行在数据上仍然存在被互联网企业卡脖子的风险。因此这个交易显然是不公平的。更为有趣的是，当前的市场环境下，经常是数据少的金融机构向数据多的互联网企业付费，更加加剧了这一不公平性。因此，纵向联邦学习技术有利于拥有大量数据的公司获取数据量相对较小的公司的数据信息。这样的“联邦”，实际上成为了大公司数据垄断的延伸，难以实现公平合作的共赢生态。

　　理想的方式是，交集不暴露给双方，在不暴露的交集上继续完成后续机器学习过程，乃至后续推理的过程;但这样做会完全损失联邦学习暴露中间结果而带来的性能优化，丧失了其特性。

　　一个可行的解决方式也许是允许多种类型的参与方角色加入，促进数据生态和业务形态全面发展。比如，可以由小公司作为数据使用方提出联合建模需求;也可以让专门从事算法研究的参与方加入，通过贡献算法模型获取收益等。这样每一方都可以贡献自己的专长，同时也能够使用他方的资源信息为自己服务。通过这样不断创新的技术应用方式，丰富业务发展模式，逐步构建良性循环的数据生态环境。

　　三、实现：联邦学习在系统工程与运维上的挑战

　　目前联邦学习在工程上的架构是一种多个数据源直接互联进行计算的模式。这一模式给现有的私有云和企业网络的部署带来了额外挑战。这些挑战具体体现在网络安全、算力可扩展性、易用性和可监管性等方面。

　　1.算力与原始数据的耦合，带来部署时网络安全与算力扩展的挑战

　　联邦学习的主要算力都与原始数据源部署在一起。这里存在两个问题，即企业防火墙配置的问题和算力可扩展性的问题。

　　一般来说，大数据平台位于企业内部的后台，应该部署在企业防火墙内，不应从外网直接访问。联邦学习的软件模块需要直接访问原始明文大数据(端上的迭代需要在明文上进行)，因此也需要进行企业内网的部署。然而，在训练过程中，不同数据源方的软件模块需要频繁互相通讯，因此需要在防火墙上对外暴露网络端口。这一部署模式给企业的网络和信息安全带来了额外挑战。另一种部署方式是将联邦学习软件模块部署在企业防火墙外的DMZ区域(demilitarized zone，隔离区)中，让联邦学习软件跨过防火墙与内网中的大数据系统交换任务。这一部署模式安全性略好，但仍然需要给一个处于较低安全区(DMZ)中，且暴露网络端口的联邦学习模块授权许多内网大数据平台的访问权限，一旦这个模块被黑客攻破，后果会非常严重。

　　另外，联邦学习主要计算都发生在数据源端，数据源需要的算力与其数据量和计算复杂度成正比。因此每个参与方都需要部署相应的计算能力，具备计算资源的可扩展性。联邦学习的稳定运行，也依赖于每一参与方的计算执行可靠性。这种跨多个参与方的计算资源调度和容错机制，与通常的云计算等有显著差别。目前尚缺乏这方面的可靠的系统设计方案。

　　一种解决思路是，将一部分计算功能独立出来(比如参数聚合功能)，在额外的代理计算方上运行。这样一来，各数据源方只需主动向代理计算方推送中间参数并适时获取聚合结果，而无需暴露自身的网络接口。另外，将算力独立出来，有利于充分利用云计算的扩展性和容错性，而不用再依赖于各数据源方的算力水平。

　　2.算法、系统和业务逻辑的耦合，带来开发门槛高，难学难懂的挑战

　　当前使用联邦学习系统开发一个AI算法，开发者需要在提升模型准确度的同时，时刻牢记“多方”的概念，时刻关注什么信息、可以暴露什么、不可以暴露什么，时刻注意加密了什么数据，加密后的数据可以做什么处理，时刻计算传输数据需要多少代价。这就要求开发者同时了解密码学、分布式计算、AI等领域知识。这样的开发者是非常难于培养的，写出来的程序非联邦学习专业工程师也很难看懂，更不用说验证其安全性。当前的联邦学习开源代码都只提供了核心功能，一些对于系统和数据安全缺乏理解的开发者在进行二次开发的过程中，极易忽略一些基本的安全策略配置，例如此前提到的防火墙的配置，以及联邦学习中关于密钥管理和分发的配置方法，从而造成虚假的安全感。

　　造成这一问题的根源在于，目前联邦学习软件的开发接口，抽象层级不够高，把太多的实现细节暴露给开发者。这当然有工程成熟度的原因，但更深层次的原因是，为了应对我们在第二节中提到的联邦学习的安全问题，导致现在联邦学习的实现上都打上了多种安全补丁。一个常见的补丁方式是结合一些密码学方法来掩盖一些梯度，例如半同态加密，但这些密码学方法都有比较复杂的密钥管理机制的要求，并且只能进行一些特定操作(例如加法)。因此许多算法都需要围绕这些密码学方法在进行特定的改进，因此导致了更为复杂的软件接口设计。如何利用更通用的密码计算方法，定义一套抽象的开发接口，使得AI算法设计人员和业务人员不用再去关心系统底层的技术，是一个联邦学习亟待解决的工程挑战。

　　一个可推荐的实现思路是，逐层级构建算法体系，对外开放友好的编程接口。具体地讲，在底层将基础的密码学协议进行封装，构建基本的密码操作指令集，支持密文计算引擎以及它与明文计算间的转换。这样，联邦学习算法的开发人员，可同时面向明文和密文开发并提供算法函数库，而业务逻辑开发人员不仅可以直接引用这些算法库解决问题，而且可以像修改明文算法库一样查验、分析和修改这些联邦学习算法，而不需要任何的密码或者联邦学习的专门知识，就像直接在明文数据上开发大数据算法一样。在运行时，可定义开发者自主编程接口和IDE，通过配置数据源，IDE可自动适配程序中的数据指向，使得开发者就像在一个数据源(可称为“虚拟的数据中心”)上开发一样。

　　3.P2P架构、半同态加密与参数聚合算法的耦合，带来数据监管的挑战

　　监管在数据流通中非常重要。监管不仅仅是为了防止数据滥用对社会造成危害，同时也是避免数据造假和数据投毒的重要手段。

　　然而，联邦学习的系统和算法都部署在各个数据源方，之间交换的数据全部通过加密传输，即使有一些中心化聚合中间结果的架构设计，这个中心化聚合节点也仅仅是在中间结果上做了很简单的汇聚计算(例如求和)，并不可能知晓各方在进行什么样的数据处理，也更无法实现计算过程的存证。因此，一个联邦学习的算法是否做了它声称的计算，只有参与方自己才知道(而且只知道自己是否做了正确的事情，不知道对方是怎么做的)。这样的系统会导致在它上面进行的明文数据的直接交易(即打着隐私计算的幌子做明文数据交易)更难被发现和监管。如果采用可验证计算等手段对P2P系统进行监管，会造成非常大的额外开销。因此，如何做到对数据使用可监管的联邦学习，在技术和工程上都是很大的挑战。其根源是，参数聚合阶段只能做加法（目前由于全同态计算性能限制，只能选择半同态加密算法），因此参数聚合服务器这个最适合履行监管责任的一方，没有能力分析它所处理的数据。

　　解决上述问题的一个途径是采用支持通用密文计算的代理计算架构，在密文上进行数据特征分析。代理计算的通用计算功能越强大，对数据分析面就越大，所能实现的监管力度就越强。另外，为了防止参与方超范围使用其他参与方的数据，应建立多方计算合约机制，由参与计算的各方在计算开始前就数据的具体使用目的和方式签订合约进行授权，各方严格按照计算合约执行，并对计算合约和执行过程进行存证，保证事后可回溯、可审计、可举证，从而防止数据滥用。

　　四、总结：需求还是方法？

　　综上所述，目前，“联邦学习”这个术语在市场上存在很多认识上的误解和混淆，主要原因是其既在广义上表达了保护数据前提下联合多方数据训练模型的需求，又在狭义上表示了一类通过暴露部分数据信息来提升训练性能的方法。有趣的是，作为广义上的需求，它强调为了保护数据安全，可以牺牲部分准确性;但作为狭义的方法，它反而强调通过牺牲安全来换取性能提升。

　　因此，作为行业用户，选择是不是存在“联邦学习”的需求(也叫做数据融合计算、数据价值流通的需求)，是一个纯粹的业务问题，其判断标准是数据价值流通能否带来业务价值;在这一需求基础上，是不是要选用狭义的“联邦学习”方法和系统来满足这个需求，是个纯粹的IT技术和安全合规问题，需要考虑和平衡的是数据的敏感性、泄露的代价，和进行数据保护所需的技术成本。

　　也许，这样才能回归到我们探索联邦学习的初心。

　　参考文献：

　　[1] Zhu, Ligeng, and Song Han. "Deep leakage from gradients." Federated learning. Springer, Cham, 2020. 17-31.

　　[2] Geiping, Jonas, et al. "Inverting Gradients--How easy is it to break privacy in federated learning?." arXiv preprint arXiv:2003.14053 (2020).

　　[3] Lyu, Lingjuan, Han Yu, and Qiang Yang. "Threats to federated learning: A survey." arXiv preprint arXiv:2003.02133 (2020).

　　[4] Zhao, Bo, Konda Reddy Mopuri, and Hakan Bilen. "idlg: Improved deep leakage from gradients." arXiv preprint arXiv:2001.02610 (2020).

　　[5] Bonawitz, Keith, et al. "Practical secure aggregation for privacy-preserving machine learning." proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. 2017.

　　[6] Kairouz, Peter, et al. "Advances and open problems in federated learning." arXiv preprint arXiv:1912.04977 (2019).

　　[7] Melis, Luca, et al. "Exploiting unintended feature leakage in collaborative learning." 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019.

　　[8] Nasr, Milad, Reza Shokri, and Amir Houmansadr. "Comprehensive privacy analysis of deep learning: Stand-alone and federated learning under passive and active white-box inference attacks." (2018).

　　[9] Bagdasaryan, Eugene, et al. "How to backdoor federated learning." International Conference on Artificial Intelligence and Statistics. PMLR, 2020.

　　[10] Bhagoji, Arjun Nitin, et al. "Analyzing federated learning through an adversarial lens." International Conference on Machine Learning. PMLR, 2019.

　　[11] Sun, Ziteng, et al. "Can you really backdoor federated learning?." arXiv preprint arXiv:1911.07963 (2019).

　　[12] Xie, Chulin, et al. "Dba: Distributed backdoor attacks against federated learning." International Conference on Learning Representations. 2019.

　　[13] Wang, Hongyi, et al. "Attack of the tails: Yes, you really can backdoor federated learning." arXiv preprint arXiv:2007.05084 (2020).

　　[14] Wang, Zhibo, et al. "Beyond inferring class representatives: User-level privacy leakage from federated learning." IEEE INFOCOM 2019-IEEE Conference on Computer Communications. IEEE, 2019.