先ごろの QCon Plus オンラインカンファレンスで、Katharine Jarmul 氏は、「Machine Learning at the Edge」というタイトルで連合機械学習 (federated machine learning) について講演した。彼女は、連合 ML アーキテクチャとユースケースを取り上げ、連合 ML の長所と短所について説明し、連合 ML が特定の問題の優れたソリューションであるかどうかを判断するためのヒントを示した。
データサイエンスコンサルティング会社である Kjamistan を運営する Jarmul 氏は、エッジまたはモノのインターネット (IoT) デバイスでの ML のユースケースと、これらのデバイスの制約が ML プロセスについてどのような新しい考え方が必要かについて説明することから始めた。それから、連合 ML の概要を説明した。次に、Google が開発した連合 ML アプリケーションである Federated Learning of Cohorts (FLoC) について説明した。最後に、彼女は連合 ML のいくつかの利点と弱点を紹介し、開発者が連合 ML が問題に適しているかどうかを判断するために使用できるフローチャートについて説明した。プレゼンテーション後の Q&A セッションで、Jarmul 氏は、連合 MLの1つの副作用は、データチームの考え方に変化を起こす可能性があると指摘した。
データチームは、解決しようとしている問題についていくらか考える責任があります。残念ながら、データチームの一般的な経験では、データはすべて揃っていますが、尋ねたい質問に答えることはできません。おそらく、[連合 ML]は、最初に質問をしてから適切なデータを収集することを考えるという点で役立つでしょう。
Jarmul 氏は、組み込みデバイスの分散システムを使用した機械学習の問題領域について説明することから始めた。たとえば、電動スクータのフリート上のマイクロコントローラだ。これらのデバイスは大量のデータを収集できるが、データを使用して ML モデルをトレーニングすると、多くの課題が発生する。安定したインターネット接続やローカルメモリとストレージが不足している可能性があり、これらのデバイスからデータを収集して、集中管理された場所でトレーニングや推論を行うことは実用的でないかもしれない。別のアプローチは、連合機械学習だ。
連合 ML (Federated ML) は、2016年に Google の研究者によって最初に提案された。一般的な考え方は、モデルを更新するためにすべてのデバイスからトレーニングデータを収集する代わりに、それぞれのデバイスが独自のデータを保持し、モデルのローカルコピーの更新を計算することだ。次に、それぞれのデバイスは更新を中央の場所に送信する。中央の場所で更新が集約され、中央サーバのモデルに適用される。このモデルは更新され、すべてのリモートデバイスにデプロイされる。生のトレーニングデータではなく、モデルの更新のみがエッジデバイスから通信されるため、連合 ML は、ネットワークトラフィックを削減して、プライバシーを向上させる。
次に、Jarmul 氏は、Federated Learning of Cohorts (FLoC) と呼ばれる連合 ML のアプリケーションについて説明した。また、Privacy Sandbox イニシアチブの一部として Google によって開発された FLoC は、ユーザを同様の関心を持つ cohorts にグループ化することで「web 上の関心に基づく広告を可能にする」方法だ。このスキームでは、ユーザに初期 cohort が割り当てられる。時間の経過とともに、ブラウザは「機械学習アルゴリズムを使用して、個人がアクセスするサイトに基づいて cohort を開発する」ようになる。ただし、ブラウザはサイトに関する生データを中央の場所に送信しない。代わりに、ブラウザはそのユーザの cohort で中央サーバを更新するだけだ。Jarmul 氏は、連合 ML がプライバシーを改善する方法と見なされることが多いが、それが保証されるわけではなく、特に FLoC は、そのプライバシーの欠陥について Electronic Frontier Foundation から批判されていると述べた。
次に、連合 ML のいくつかの利点と弱点について説明した。主な利点の1つは、生データがエッジデバイスを離れることがないため、一元化されたデータ収集がないことだ。ただし、これには、モデルの更新に使用できるように、デバイス上のデータを標準化する、つまりベクトルまたはマトリックス形式に変換する必要がある。もう1つの利点は、データがより多様になる可能性があることだ。ただし、その欠点の1つには、データが不均衡になる可能性があることだ。モデルをエッジデバイスに直接デプロイすると、ネットワーク接続がなくても、リアルタイムのローカル推論の利点がある。ただし、これは、エンドユーザがモデルから専有情報や機密情報を抽出できないように開発者がする必要があることを意味する。最後に、連合 ML はプライバシーを強化する可能性を提供するが、保証されているわけではない。連合 ML は、開発者が注意を払い、差分プライバシーやグラデーションクリッピングなどの手法を使用しない限り、情報漏洩の可能性がある。
Jarmul 氏は、開発者が連合 ML がアプリケーションに適しているかどうかを判断するのに役立つフローチャートでプレゼンテーションを締めくくった。最初に、彼女は、開発者が「実証済みの真実を探している」場合、連合 ML は適切な選択ではない可能性が高いと警告した。次の考慮すべき質問は、トレーニングに使用されるデータが「標準化」されているかどうか、およびエッジデバイスが学習アルゴリズムを実行するのに十分強力であるかどうかだ。そうでない場合、Jarmul 氏は分散データ分析を推奨した。デバイス上のデータをクエリし、データサイエンスチームが質問に答えるために使用する中央の場所に集計を送り返す手法だ。連合 ML が実行可能なオプションである場合、Jarmul 氏は、集中型フェデレーションとクラスター化フェデレーションのどちらを使用するかを検討することを推奨した。集中型ソリューションは「複雑さが軽減され、セットアップが容易になる」。ただし、既存の分散システムがすでに何らかの方法でクラスター化されている場合は、それを使用する方が容易かもしれない。最後に、Jarmul 氏は、プライバシーとセキュリティの専門家を設計の議論に参加させ、ネットワーク接続の喪失に対する緊急時対応計画を検討することを推奨した。
プレゼンテーションの後、Jarmul 氏は聴衆からのいくつかの質問に答えた。カンファレンストラックのホストである Sergey Fedorov 氏は、連合 ML を実行するためのエッジデバイスのハードウェア要件について質問した。彼女は、重要な機能はベクトル演算を実行する機能であると回答し、特に Apple は「非常に高性能な」チップを搭載したデバイスを出荷していると述べた。彼女はまた、それほど強力ではないハードウェアの場合、開発者は深層学習モデルの代わりに、より「古典的な」ML アルゴリズムの使用の検討を提案した。聴衆は、連合 ML の iOS と Android デバイスの違いについて質問した。Jarmul 氏は、ハードウェアに対する Apple の制御されたアプローチにより iOS はおそらく Android よりも機能が進んでおり、iOS には差分プライバシーのサポートが組み込まれていると回答した。ただし、Android デバイスは Google の TensorFlow 深層学習フレームワークの連合 ML ライブラリをサポートすることを注意し、これは開発者に役立つ。
Jarmul 氏は、TensorFlow Federated を含む連合 ML リソースへのいくつかのリンクも共有した。TensorFlow と PyTorch の両方をサポートする PySyft。さまざまなモデルタイプの連合学習用のPythonライブラリである IBM 連合学習。そして、WeBank によってリリースされた分散型学習エコシステムである Federated AI だ。