前段时间看到了一篇文章，讲苹果新版的iOS系统做了一个升级，用户有权利选择是否将IDFA标记公开给服务提供商。IDFA标记是用来追踪用户身份的，有了IDFA标记，服务提供商就可以把一个用户产生的各种数据关联起来，从而实现基于大数据的个性化推荐，比如用来做更加精准的广告推送。
假如大部分用户都选择了不公开IDFA标记，代表着以前的广告推荐、内容推荐就都无法正常工作了，这当然让我们的隐私数据得到了更好的保证，但是也让我们丧失了很多个性化推荐提供的便利。
于是我们就在想，能不能用隐私计算来做个性化推荐的系统，保证用户的隐私数据不被任何外界的人看到，同时又能让用户享受到个性化推荐的好处呢？
在上一篇文章中，我们假设了一个企业信息中心的场景。这次就想接着在这个场景下，实现一个针对企业内部内容的个性化推荐系统，帮助企业里面的每个人看到他更感兴趣的内部文档、别人分享的文章等等。
在苹果的场景下，只要用户授权开放了IDFA，我们就可以实现聚合全部数据的内容推荐，而在企业场景下进行内容推荐，由于企业数据是需要严格对外保密的，我们根本不可能把多个企业内部的数据聚合到一起来训练推荐模型，这比个人用户的隐私要求更为严格。
单个企业的内部数据一般是比较少的，只使用一家企业的数据训练出的内容推荐模型，推荐的精准度会非常差。假如有一家企业刚刚开始使用这个系统，在冷启动的时候甚至没有内部的数据来开始训练。这时候，我们如果用隐私计算的技术，实现每家企业的数据都不对外暴露的前提下，联合多个企业的内部数据进行推荐模型的训练，再把得到的模型拿给每一家企业进行使用。可以让每一家企业的推荐质量都得到极大的提升。新加入的企业甚至可以在没有内部数据的情况下， 直接开始享受推荐模型的精准结果。
在这一次的尝试中，我们首先选定了一个传统的推荐系统模型，然后使用横向联邦学习技术来完成保护隐私的分布式模型训练。最后，最重要的部分，因为在联邦学习技术中，需要一个可信第三方来进行多方计算过程的协调，假如这个可信第三方作弊，或者不配合，都会导致整个系统无法正常运作。因此我们使用区块链替代掉了联邦学习中的可信第三方，使得整个系统可以在多个企业组成的P2P对等网络中运行，不受任何单一企业状态的影响。
关于区块链和隐私计算的结合，最近一些新的思考是，在涉及多方计算的场景中，一定会涉及到参与者作弊或者是不配合的情况。在以前的每一个具体的算法设计时，都需要将这种情况考虑进去。而针对每一个具体的场景设计不同的算法来解决作弊问题，无疑增大了算法设计的复杂度。区块链其实可以看做是对这一问题的抽象：假如有一个统一的解法，可以让多方算法不用再考虑作弊的问题，而专注在本身要解决的具体问题上，应该可以简化算法设计和系统设计，提高系统运行的效率。
内容推荐模型
内容推荐模型来自KDD 2017年日本雅虎的一篇文章：《Embedding-based News Recommendation for Millions of Users》。推荐系统包含两个子模型，分别为文章编码器和用户编码器，负责对文章和用户的特征进行编码。推荐的过程是计算文章编码和用户编码的内积，内积越大，表明用户越可能点击这篇文章。
文章编码器的结构是一个降噪自编码（Denoising Autoencoder, DAE），DAE中编码器层输出的向量就是文章的编码。文章编码器输入是加入了噪声的文章TF-IDF向量，目标是尝试恢复出原始的TF-IDF向量。文章编码器是以一种自监督的方式来进行训练的，输入和目标都是文章本身，不需要额外的标注，也不需要用户的点击数据。
用户编码器的结构是一个循环神经网络（RNN），RNN中的隐藏状态H就是用户的编码。用户编码器的输入是用户点击过的新闻的编码（来自于文章编码器），目标是使输出的用户编码与用户点击的下一篇文章的编码内积更大。用户编码器的训练数据来自于用户点击文章的历史。
在训练时，用户编码器和文章编码器会分开训练。先使用文章数据训练文章编码器直至收敛，然后使用文章编码器对用户点击过的文章进行编码，再使用用户点击文章的历史训练用户编码器。
文章编码器的训练并不需要使用用户的数据，为了简化问题，对于每个企业内部的文章编码器的训练，我们采用企业内部的文章库直接在本地完成训练。
用户编码器需要用到用户的点击历史，单个企业内部的用户量一般较少，我们就希望能使用其他企业的数据来扩充我们的训练数据。这里我们就引入了横向联邦学习，联合多个企业的数据来训练我们的用户编码器。
横向联邦学习
横向联邦学习中包含两种角色，服务器与客户端。服务器端即是上文所说的可信第三方，负责保存、更新全局的机器学习模型，协调、配置各个客户端对模型进行训练，而客户端就是一家家独立的企业，保存自己产生的隐私数据，使用自己的数据对服务器提供的模型进行训练。
横向联邦学习与传统的机器学习类似，使用类似SGD的方法对模型进行训练，大致流程上是相同的。训练分为很多轮，每一轮都需要:
· 选取数据
· 训练模型
· 更新模型
不断重复这一过程，直至模型达到收敛。
与传统的机器学习相比，不同之处主要有：
· 选取数据：数据不储存在服务器上，而是在客户端上，选取数据就是选取一些客户端提供数据
· 训练模型：模型不在服务器上训练，而是在客户端上进行训练
· 更新模型：模型的梯度会由多个参与训练的客户端提供，需要对梯度进行聚合
因此，在一个轮次中，横向联邦学习的整体流程如下：
每个轮次共分为三个阶段：选择、配置、上报
选择阶段
选择阶段是一个轮次的开始。每隔一段时间，客户端会检查其是否满足了开始训练的条件时，如果是，客户端就会与服务器建立一个双向的连接，这个连接会用于后续阶段服务器与客户端之间的通信。
服务器与客户端建立连接之后，会根据联邦学习的配置，选择接受或是拒绝这一连接。联邦学习中一个轮次中所需要的用户数量有限，并不是越多越好，只要达到了最低的限度即可。服务器会从所有连接的客户端中，随机地挑选出足够的客户端。对于没有被选中的客户端，服务器会向他们发送指令，让其过一段时间再进行连接，然后断开连接。
配置阶段
在选择阶段完成后，服务器会将本轮训练需要的配置，发送给客户端。这些配置包括了执行计划、当前模型的参数、聚合的方法、聚合方法的参数等等。在这里，模型的执行计划包括模型结构的定义、如何读取数据、如何计算模型的梯度等，服务器会把这些方法打包成为一个可执行的格式，供客户端使用。
上报阶段
客户端将收到的执行计划、模型参数加载进运行时，从客户端本地的数据库中读取数据，进行训练，得到模型的梯度。得到梯度之后，根据配置的聚合方法，将梯度上传给服务器。
服务器收到客户端上传的梯度之后，会根据配置的聚合方法，对梯度进行聚合，求得所有上传梯度的平均值，使用SGD之类的方法，对当前的模型参数进行更新，将新的模型参数持久化到数据库中，供下一轮使用。
安全聚合
多个客户端进行梯度上报、服务器进行梯度聚合的阶段，是整个联邦学习过程中需要重点关注数据隐私的部分，因为这一部分会从客户端发送数据到服务器上。
联邦学习对于这一部分数据上传的隐私保护分为两个部分，首先，从客户端上传的是计算出的梯度增量而不是原始的数据，原始数据无论如何也不会被上报到服务器端，这就对原始数据做出了第一层的保护。
在某些场景下，即使是仅仅上传了梯度增量，对于原始数据的保护也还是不够的。在拥有模型的情况下，外部攻击者有可能通过梯度反推出用于训练的隐私数据，从而造成企业的隐私数据泄露。因此联邦学习中增加了第二层的保护——安全聚合。
安全聚合的设计思路是给原始的梯度加上一个随机的掩膜，生成混淆的梯度。各个客户端通过交换公钥的方式，使得随机生成的掩膜之和为0，这就能保证混淆的梯度之和与原始梯度之和相等。为了应对执行过程中客户端的掉线，各个客户端通过秘密共享的方式，将他们的私钥共享给其他客户端，保证即使掉线，也能去除掉线客户端的掩膜。
为了防止服务器意外获得掉线用户的原始梯度，客户端会再加入第二个随机的掩膜，并将这个掩膜以秘密共享的方式分享出去。服务器在聚合时，会通过共享的秘密，去除掉线客户端的第一个掩膜，以及存活客户端的第二个掩膜，得到原始梯度之和。
安全聚合包含四轮通信过程：
1. 客户端将其生成的公钥发送给服务器；服务器将收到的公钥广播给每个客户端
2. 客户端将私钥和第二个掩膜进行秘密共享，为每一个客户端都生成一份加密的秘密，发送给服务器；服务器将收到的秘密转发给对应的客户端
3. 客户端对原始梯度进行混淆，并将混淆过的梯度发送给服务器；服务器根据这一轮上传的情况，确定最终存活的客户端，和掉线的客户端
4. 服务器向存活的用户询问掉线用户的私钥，以及存活用户的第二个掩膜，最终得到存活用户的原始梯度之和
安全的聚合，带来了额外的通信与计算开销，其中计算开销是与用户数量呈二次方关系的。因此，在流程的选择阶段，需要控制连接的用户数量，降低安全聚合的开销；同时在架构上，使用多个子聚合器对客户端进行聚合，降低开销。
安全聚合能够保证在服务器和客户端都按照协议准确地执行时，服务端无法获得用户上传的原始梯度。安全聚合发送给服务器的是经过混淆的梯度，服务器无法得知原始梯度，但是能够从混淆的梯度之和得到原始的梯度之和。同时，安全的聚合能够容忍在运行过程中客户端掉线，只要最后有超过最低限度的客户端存活，就能计算出存活客户端的梯度之和。
移除可信第三方——服务器端
整个分布式模型训练过程的正确完成，非常依赖于服务器端的正确执行。在Google的案例，输入法词组联想功能中，Google是整个功能的设计者，客户端和服务端都由谷歌设计，而输入法的用户只是选择信任了Google。假如Google实际上没有使用联邦学习，用户也无法知道。
在我们的企业场景下，我们更希望能移除对于第三方公司可信的依赖，通过区块链的技术手段实现服务器端的可信，通过智能合约来实现整个服务器端的功能。
横向联邦学习中，服务器主要有以下三个功能点：
1. 储存：储存执行计划、模型的参数、配置等数据
2. 计算：对客户端上传的结果进行聚合
3. 通信：与客户端进行通信，将数据分发给客户端，并从客户端接受数据
对于储存功能，因为执行计划、模型的参数都会很大，区块数据是储存在每一个节点上的，直接将模型储存在区块数据中，会很占用空间。在原本链的研发中，我们实现了可信的链外分布式存储层，通过P2P多备份的方式存储数据，通过链上数据对链外数据进行索引，并且对存储数据的正确性进行校验。通过这样一个链外存储层，我们相当于可以实现在区块链上完成联邦学习需要的存储功能。
对于计算功能，需要计算的是客户端上传的结果的平均值，计算相对简单，只包含加减乘除等四则运算，因此可以直接在智能合约中实现。但是客户端输出的结果一般是模型的参数的梯度，是矩阵的形式且维度很高，如果智能合约不支持矩阵运算，在智能合约中简单地实现，效率会很低。这里我们还是采用了Layer 2的方法，将实际计算过程转移到链下，在链上提交计算结果，由其他节点进行校验，如果校验失败会触发节点的惩罚机制。
对于通信功能，需要分开讨论。对于客户端上传服务器的数据，智能合约当然是可以实现的。客户端上传数据，就相当于调用智能合约的方法，并向区块链发送一笔交易。对于服务器发送到客户端的数据，智能合约无法像服务器一样发送给各个客户端，需要改为由客户端从区块链拉取数据。当区块链有数据需要发送给客户端时，可以先广播一个特定的事件，通知各个客户端。客户端需要监听服务器的事件，根据收到的事件，执行对应的智能合约的方法，从区块链拉取数据。
除了以上三个功能之外，智能合约还需要实现注册、发布任务、参与任务的功能。
在我们的场景中，无论是提供数据的机构，还是使用数据的机构，都需要先在智能合约中注册，才能参与进来。
注册过的机构，可以通过调用智能合约的方法，发布任务。发布的任务要包含以下几个部分：任务的执行计划、任务的模型参数、使用的聚合方法、所需数据的格式。智能合约会保存这些内容（链上或链下），以供参与方获取。
注册过的机构，可以获取到智能合约上所有发布的训练任务。如果其满足了任务所需要的数据要求，它就可以选择参与这个任务。参与特定的任务，就是调用智能合约的方法，将该机构与参与的任务绑定起来。参与任务之后，该机构就可以参与到任务的训练轮次中，获取任务的执行计划、模型的参数等内容。一个机构可以参与多个任务。
对于发起任务的发起方来说，还需要能够获取参与任务与参与执行轮次的机构列表，以保证当前参与方的数量满足了最低限度。
完整的联邦学习训练过程
1. 任务发起方
假设我们的文章编码器已经训练收敛，且区块链上已经部署了合约，我们现在需要做以下三步：
* 发布任务
我们需要在智能合约上发布我们的训练任务，才能让其他的数据提供方加入我们的训练。在这里，我们需要发布两个任务，分别是训练任务和测试任务。训练任务用来在训练模型，更新参数；测试任务用来测试模型的效果，观察模型的收敛程度。
* 训练模型
在部署完训练任务之后，我们就可以开始训练模型了。
作为发起方，我们首先要检查现在参与这个任务的参与方的数量，只有当参与方数量达到最低的限度之后，才开始发起训练。
我们首先调用智能合约的开始轮次方法，开始一轮训练。我们会等待一个固定的区块时间后，然后调用合约的方法，获取参与这一轮训练的节点。
如果参与的节点数量达到了最低限度，那么就调用配置下发的方法，开始配置阶段。
等待一个固定的区块时间后，调用结束轮次的方法，结束当前轮次，让智能合约聚合训练的结果。监听到轮次结束的事件后，调用合约的方法，获取当前的轮次的计算结果，也就是模型参数的梯度。在本地完成模型参数的更新后，调用合约的更新参数方法，更新智能合约储存的模型参数。在这之后，调用智能合约的开始轮次方法，开始一轮新的训练。
* 测试模型
在传统的机器学习中，我们在训练的同时，需要在验证集上测试当前模型的效果，确定模型的收敛程度。由于我们的用户量较少，单纯使用本地的用户浏览数据作为验证集并不足够，所以可以使用横向联邦学习的方法，在其他参与方的数据上对模型进行测试。
测试任务的执行过程与训练任务大致相同，只是在轮次开始前，调用合约的更新参数方法，更新智能合约储存的模型参数，之后的执行过程与训练模型时一致。任务的轮次结束后，聚合得到的结果就是模型在验证集上的损失。
在测试模型时，我们需要保证用来测试的数据不是训练数据。由于数据读取的方式，是由参与方自己实现的，所以这一点比较难以控制。一种方法是在测试时，选取与测试时不同的参与方；另一种方法在设计读取数据的接口时，预留参数来控制读取数据的范围，例如使用时间范围来作为参数，训练与测试时使用不同的时间范围，不过这一点需要参与方的支持。
2. 任务参与方
对于参与方，需要实现的功能有三个：
* 能运行执行计划的运行时（Runtime）
运行时需要与执行计划的格式相匹配。执行计划有多种格式可选，包括脚本文件、可执行文件、pytorch中的TorchScript、Tensorflow中的Graph等。在这里，我们将执行计划打包为一个Python中的第三方包，参与方只需要有对应版本的Python环境，在使用时安装执行计划的第三方包即可。使用Python第三方包的形式，对于参与方来说，运行时的安装与执行都相对简单，且代码开源，可以审查，没有安全性方面的顾虑。
* 数据读入的接口
参与方需要根据任务的数据格式，以及接口的定义，实现数据读入的接口。
在这里，数据的格式为用户阅读的文章序列{文章1，文章2，文章3，……}。数据读入的接口为：
read_data(timestamp: int, limit: int, offset: int, seq_length: int) -> List[List[str]]
其中，timestamp表示数据的起始时间戳，limit表示一次读取的数量，offset表示偏移量，seq_length表示每个文章序列的长度。接口的输出格式为序列的列表。
* 与智能合约交互的逻辑
参与方首先需要先调用智能合约的方法，加入任务。之后参与方监听智能合约的事件，根据事件，执行对应的方法。
当监听到轮次开始事件时，调用智能合约的参与轮次方法，参与这轮训练。当监听到配置下发事件时，调用智能合约的获取配置方法，获取配置、执行计划、模型参数等，调用运行时，运行执行计划。执行计划运行完毕后，根据聚合算法，对运行结果进行处理，之后调用智能的上传结果方法，上传结果。如果监听到了轮次结束的事件，则无论是否上传了结果，直接结束当前轮次的执行。
（本文从 缪弘 提供的素材洗稿而来）