Path: blob/master/site/ja/federated/collaborations/notes/2022-02-16.md
25118 views
2022/2/16 の TFF コラボレーターミーティング議事録
参加者:
Krzysztof Ostrowski（Google）
Alex Ingerman（Google）
DeWitt Clinton（Google）
Boyi Chen（LinkedIn）
Souvik Ghosh（LinkedIn）
Zheng Li（LinkedIn）
[chen] 自分たちの現在の使用方法、貢献の関心分野、貢献方法に関するプロセス、今後の開発プランについて
[boyi] 現在の FL の使用方法
2 つの部分がある - 1 つはクロスサイロ
ユーザーのデータ
法的要件によるデータへのアクセス制限
FL は 3P データに役立っている
規制を遵守しながらデータを利用できる
オンデバイス FL - 興味深いが、ほぼクロスサイロに取り組んでいる
追及可能ないくつかのプロジェクト
プロトタイプを構築している
TFF が便利
FL とパーソナル化された転移学習のベンチマーク
クライアントのデータを使用して、クライアントと転移学習 f のパーソナル化されたモデルのトレーニングを比較
FL の仕組みに関わる課題
クライアントのサイズが異なる -> バイアス
一番貢献しているクライアントはフリーライダーを危惧している。データ量の最も少ないクライアントはモデルに十分な影響を与えていないことを危惧している。
スケーラビリティに関する課題
現在は推論（数百 M）
トレーニングデータは現在それほど大きくない（数10～数100 K/サイロ）
O(数百 M) クライアントに対してバッチで推論を実行
主な課題は総データボリューム
全クライアントのレコード
現在、クラスタサイズが制限されているため、推論の速度に限界あり
他のサイロと混合すべきでないデータのクライアント = サイロ。カーディナリティは？
現在実験中。将来的には、数十万サイロにスケーリングしたい
これまで見たことのある TFF クライアント数は？
オンデバイス: 大量の小さなデータサイロ。クロスサイロは少量の大規模なデータセット
サイロはどの程度似ているか？
スキーマは同じだが、データの分布はサイロ間で大きく異なる。参加に平等性がない
[K] 推論だけでなくトレーニングの TFF を検討しているのか？
[B] 現時点ではトレーニングに TFF を使用している。同じフレームワークでトレーニングと推論を行いたい
[K] 同じインフラか、同じモデルか？
[b} 現時点では、同じインフラと同じクラスタ
[B] モデルをトレーニングしてデバイスにデプロイする方法を理解したい。
[S] 1 つの環境でモデルをトレーニングし、取り出して別の環境で使用する必要性が重要。ただ最初のアプリケーションではそうしていない。
[B] 自分たちが構築しようとしているもの:
貢献アイデアの 1 つ。公平性のベンチマークを行ったら、ツールとベンチマークを TFF に追加できる
サイロ間（不平等なパフォーマンスとバイアス）でモデルがどのように動作するか
[K] 実践では問題になると考えているか？[B] 実践で問題になると思う。
[B] 敵対的の観点でこれを考えてみれば、皆はボックスにデータを入れることに関心を持つだろう。これは一般的な懸念事項であるが、特定の指標がない。
[K] どれを解決しようとしているのか？サイロとその処理方法に関する規制がある状況について言っているのか？でも、それは敵対的ではなく、単に、複数の機関が存在し、相互に不信感を抱く別の状況に対してバイアスを作りたくないだけ。ここではいずれかを検討しているのか、それとも両方を検討しているのか？
[B] 両方を検討したいが、現時点では後者のみを考えている。
[D] たとえば、ここでのサイロは企業であり、データセットはそれぞれがアップロードしたデータ
[K] フリーロードについての懸念を強調しているようだが、相互に不信感を抱いている企業も存在する。そういった企業は他者がデータにアクセスするのを阻止したがっているのか？これらの懸念には緊迫感がある。攻撃を防ぐために貢献度を確認したい一方で、プライバシーのためにコンテンツを見たくないという懸念だ
[B] 2 つの視点で考えてみると、1 つは DP などによるプライバシー保護。もう 1 つは、モデルパフォーマンスの観点から、多くのサイロのデータからトレーニングした場合、異なるサイロが異なるメリットをもたらすという懸念。前者には標準的なアプローチがあると考えているが、後者はもっと手間のかかる問題
[K] モデルがうまく機能するという意味での公平性。もう 1 つはフリーロードが可能。プライバシーとの緊張が強いのは後者。あなたはそれについて心配しているのか？
[B] 両方とも同じくらい重要。データプライバシーを保護しながら、メリットを公平に分散したい
[S] まだ良い回答はない。[K] こちらもない。
[D] これらの企業はどれくらい LinkedIn がこれを運用することに信頼をおいているか？
[S] 少なくとも自分が感知している例においては今のところ信頼に問題はない。いくつかの制約リクエストがあったが、完全に拒否されたことはない。自分たちが共通のバリューを構築するために、みんな喜んでデータを共有している。
[A] プライバシーの懸念はサイロ自体のことなのか、サイロ内の個人のことなのか？
[S] 後者
[D] これは Azure 上に構築されているか？他に自分たちが考えるべきデプロイ関連の事項はあるか？
[S] 最終的には GPU が出てくるだろう。初期のモデルは小さくなり、ニーズも少なくなる。最終的に、これには多数のメンバーと企業が関与する → モデルがかなり大きくなる。
[D] これは、一般に公開されている Azure と同じものか？または、外部からは見えない、ターゲットへの内部インフラ。
[S] 非常に一般的なもの。
[D] 誰もがパブリック Azure で実行できるため、共同作業が容易になり、OSS コードがもっと貴重になる。
[K] 作ってみよう！どのようにすべきだろうか？ベンチマークスイートとクロスサイロプラットフォームについて言及した。一般公開で PRD を具体化することを考えて、機能や使用例について話してみてはどうか？
[Z] 製品仕様はどのようなものか？小型の TFF コンポーネント？
[k] コンポーネントについて話し合うことは可能。または、TFF 上に構築して他に公開できる製品でもあり。
[Z] きちんと理解しておきたいのだが、これは貢献プロセスなのか？製品を始めようとしているのか？
[k] ここではプロセスを作ろうとしている。合意できるものに応じる。
[Z] TFF 外だが TF に含まれるような、そのような製品の例はあるか？
[K] TF には設計ドキュメントのプロセスがある。この内容をそのようなプロセスに変換し始められる。サイロ、相互不信、DPのようなテクニックを使用したい、Azure に取り組む必要があるなど。
[D] ユースケースのディレクトリがあると便利。ただし情報は開示しない
[K] いずれにしても TFF に存在するユースケースのロードマップ、ドキュメント、例を作成していきたいと考えている。一緒に始めるのはどうだろうか。小規模で始められるとより簡単だろう。とにかく、始めよう。
[B] FL の課題にかんするリサーチは多数ある。こういった課題を解決するツールをいくつかピックアップして、そこから始めるとよいかもしれない。フリーライド、データの不均一性などは、連合の設定に共通した課題のようだ。ツールは汎用的に便利になるだろう。
[K] 課題を評価するツールは？システムコンポーネントはどうか？
[B] TFF が提供できる機能
[K] 賛成。PRD から取り掛かれば機能についての話し合いに文脈を持たせることができるが、機能については別で話し合うことも可能。フリーロードの課題を説明したドキュメントから始めて、それに対処するツールに取り組んでいくことも可能ではないか？
[D] 研究者と連携することもできる。LinkedIn は製品の他に研究結果の生成も狙いとしているか？
[Z] 短期的には、研究には行きついていない
[K] 共有ドキュメントから始められそうだ。機能かコンポーネントをいくつか記述し始めてはどうか。着手するのはどちら側でもよい。Google ドキュメントとメールを使用できる。公開に持ち込もう。
[ostrowski] 構築するものとそのための具体的な最初のステップについて
今後の会議に向けて - 自分たちのアクションアイテムは？
特定の製品/プロジェクトについていくつか記述し始めている
ベンチマークスイート
DP、公平性、フリーロード保護を備えたクロスサイロプラットフォーム
次の可能なステップ
製品要件ドキュメントに着手し、上記の各項目をまとめて公開？
設計レベルのアイデア交換を開始？
実際の開発貢献に関する潜在的な計画？
開発したい具体的なコンポーネント/機能？
作成する具体的なアーティファクト:
フリーロードの問題とそれを解決できる可能性のあるツールまたは TFF 機能の要件を説明する共有ドキュメント
データ量が不平等なサイロ間のバイアスに関するベンチマーク、ベンチマークで測定するものを説明する共有ドキュメント。
Azure ベースの環境で TFF を機能させられる新しいコンポーネントを定義する共有ドキュメント（どのレイヤーと統合する必要があるかは未定）
[ostrowski] 公開コミュニケーション
何を公開するか（GitHub ランディングページでの公開）
ディスカッションとその決定事項、およびフォローアップ会議の要約を、各会議から数日以内に GitHub ページで公開
アーティファクトへのリンク（計画、ロードマップ、設計ドキュメントなど）も同様に GitHub で公開
会話（チャット？）
Slack
共通目標:
範囲内の具体的な製品 / コンポーネント？
これらの開発をサポートするためのより具体的な / 範囲を狭めたワーキンググループ？
[B] 小さな運用関連の課題についてどうするか？
[K] Slack か GitHub 課題でいいだろう。効率が良いのはどちらか？
[ostrowski] 両者がコミットできる定期会議のスケジュールは？
月例