今更聞けない Federated Learning : 個人のプライバシーを守るAI

# はじめに

こんなことを考えたことはないでしょうか？

- 僕の秘蔵写真コレクションがサーバに送られるのはいやだ！
- 個人情報をサーバに置かれるのは気持ちが悪い
- 自社のデータを他社に置きたくない
- 膨大なローカルデータを一箇所に集めて処理するのは効率が悪い

このような時に *Federated Learning* が役に立ちます．

大まかな考え方は以下です

1. ローカルのデータを用いてモバイル端末で学習を回す
2. モデルの勾配をサーバに送信
3. 複数端末の勾配を集計してサーバ側のモデルを更新
4. 学習されたモデルを各モバイル端末に送りモバイル端末側のモデルを更新する
4. 1 へ戻る

![FederatedLearning_FinalFiles_Flow Chart1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298787/28bd1110-753c-aaa6-a8d0-7cbffe1de88d.png)
> ユーザーの利用方法に応じて、スマートフォンがローカルでモデルをパーソナライズ（A）。多くのユーザーのアップデートを集計（B）後、共通する変更データを生成（C）して共有モデルを更新。その後はこの手続きを繰り返す。

今回はそんな Federated Learning について本家 Google の記事，論文を呼んだのでまとめます．

# 基本的な考え方

上記，触れましたが基本的なフローについて噛み砕いて見ていきます．

### 数式定義

> W : モデル(レイヤごとのパラメータの行列)
> t : ラウンド数
> St : デバイス全体におけるラウンド t のサブセット
> n : St 中のデバイス数
> i : デバイス番号
> H : 勾配

### 1. ローカルのデータを用いてモバイル端末で学習を回す

ここについては通常の機械学習の通り，各レイヤーの勾配を計算します．

```math
H_t^i = W_t^i - W_t
```

### 3. 複数端末の勾配を集計してサーバ側のモデルを更新

上記，送られてきた勾配を元にサーバ側のモデルを更新します．

とその前に，勘のいい人はお気づきかもしれませんが，サーバ側は勾配の値を持っていることになります．
そのため，勾配の値を元にローカルのデータ特性が知られてしまうかもしれません．

これを防止するため，本論文では Secure Aggrication を採用しています．
これは勾配を計算する際に，マルチパーティ計算(MPC)で集計処理を行うことでサーバ側も各デバイス側も他人の勾配情報を知ることなく集計値を取り出すとこができます．これにより，一人ひとりの勾配を知らないままモデルの更新が行なえます．

![3-Figure1-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298787/327decec-cf1c-6ca5-db03-00bdcffe0e99.png)

> Left: In the cloud-centric approach to machine intelligence, user devices interact with cloud hosted models, generating logs that can be used as training examples. The logs from many users are combined and used to improve the model, which is then used to serve future user requests. Middle: In Federated Learning, machine intelligence models are shipped to users’ devices where they are both evaluated and trained locally. Summaries of improved models are shared with the server, where they are aggregated into a new model and deployed to user devices. Right: When Secure Aggregation is added to Federated Learning, the aggregation of model updates is logically performed by the virtual, incorruptible third party induced by the secure multiparty communication, so that the cloud provider learns only the aggregated model update.

話を戻しまして，モデルの更新処理ですが，本論文では各デバイスの勾配を平均することでサーバ側のモデル更新を行う勾配を作成します．

```math
H_t := \frac{1}{n_t}\sum_{i\in S_t}H_t^i
\\
W_{t+1} = W_t + \eta_tH_t
```

上記，更新したモデルを端末に返して 1. へ戻ります．

これが Federated Learning のフローになります．

# ボトルネックと解決方法

当たり前ですが，通信が多く行われるため，通信時間がオーバーヘッドとなってしまいます．
そこで，以下の対策がされています．

- モバイル側で学習を進めアップデート行うことで通信回数を削減
- ランダムな循環と量子化による圧縮アップロードによる通信コスト削減

また，ユーザのモバイル端末をお借りして学習を進める必要があるため，ユーザエクスペリエンスを損なわないような学習を設計する必要があります．記事では，学習スケジュールのタイミングを工夫することで上記問題を解決しました．

- 小型化 TensorFlow の利用
- 端末がアイドル状態で電源に接続されており，無償の無線接続がされているときのみ学習

![02_Personalizationsleeping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298787/2f5388a8-477f-038d-0562-87e2f32d0299.png)

> スマートフォンがフェデレーション ラーニングに参加するのは、ユーザー エクスペリエンスに悪い影響を与えない場合のみ。

# 活用事例

現在，Federated Learning の活躍はプライバシーが重視される医療，金融関係での活躍が期待されています．

また，Federated Learning の非中央集権的な学習方法から，ブロックチェーンとの応用が期待されています．(こちら，自分の中でどのようなシナジーがあるのか精査できていないため，今回は詳しくは述べません)

# 感想

今回の学び

- Federated Learning は非中央集権的な学習方法である
- Federated Learning は各デバイスで計算した勾配を集計して学習を進める
- 通信時間がかなりオーバーヘッドになってしまう

こちらの記事が 2017 年とかなり前の技術のため，最新論文ではどこまで技術が進んでいるのか調査して行きたい思います．技術としてもシンプルですが，プライバシー保護や協業研究が進む現代ではかなり重要な技術であると感じました．論文を呼んでいてとても楽しかったです．

# 参考文献
Google の Federated Learning の解説記事
https://developers-jp.googleblog.com/2017/05/federated-learning-collaborative.html