拓海さん、最近部下から「連合学習で通信コストを下げる新しい手法が出ました」と聞きまして、要は通信量が減ればうちの現場でも使えますかね？私は数学は得意じゃないもので、ざっくり教えてください。
素晴らしい着眼点ですね！結論から言うと、大きく変わったのは「送るものの見方を変える」だけで通信量を大きく減らせる点です。難しい言葉はあとで解説しますが、要は同じ情報をより小さくまとめて送れるんですよ。
これって要するに、ファイルサイズを圧縮するようなイメージで、データを小さくして送ればいいということですか？でも圧縮して精度が落ちるのではと心配でして。
いい質問ですよ。今回の技術は二種類の工夫を組み合わせています。一つはBasis Learn（Basis Learn: 基底学習）で、送る対象の表現を変えて“もともと小さくできる形”にする方法。もう一つはbidirectional compression（双方向圧縮）で、サーバーと端末の双方で圧縮をする点です。両方組み合わせることで精度を保ちながら通信を削れますよ。
双方向ってサーバーから端末へも圧縮するんですか。それで本当にモデルの性能が落ちないんでしょうか。うちの場合は製品の品質に響くと困ります。
大丈夫、ちゃんと担保されていますよ。ポイントを三つで整理します。1) 表現を変えるだけで情報の余分な部分を減らせること、2) 双方向で圧縮して通信コストを両側から下げること、3) 局所的に速い収束（Newton-type methods（Newton-type methods: ニュートン型手法）に由来する性能）を保てること。これらを組むことで精度低下を抑えます。
なるほど。現場導入の観点では、端末ごとに参加しない場合（部分参加）が多いのですが、その点はどうなりますか？うちは常に全員が繋がっているわけではありません。
それも想定されています。BL2とBL3という拡張で部分参加（partial participation（partial participation: 部分参加））に対応し、参加端末がランダムでもサーバーの推定が崩れないように設計されています。実務では端末の可用性が低い場合でも安定して動きますよ。
投入するコスト面も気になります。新しい基底を決める手間や計算資源が増えるなら投資対効果が合わないかもしれません。ここはどうでしょうか。
良い観点です。ここも要点を三つで説明します。1) 基底（basis（basis: 基底））の選定は事前に一度行えば良く、学習中は固定で使えること、2) 計算は端末側での処理量が少し増えるが通信の減少で総合コストが下がること、3) 特に通信がボトルネックの現場では投資対効果が高いこと。ですから、まずは小規模でPoC（概念実証）を回すのが現実的です。
よく分かりました。要するに、送る情報の”見せ方”を変えて通信を減らし、それでいて学習速度や精度を保てるなら、まずは現場の限られたラインで試してみればいい、ということですね。
その通りですよ。大丈夫、一緒に設計すれば確実に導入できます。まずは通信状況が悪い現場を1つ選んで、基底選定と双方向圧縮の組合せで比較してみましょう。すぐに見積もりも出せますよ。
分かりました。では私の言葉で整理します。基底学習で行列の見方を変えて情報を小さくまとめ、サーバーと端末の双方で圧縮すれば通信料を減らせる。部分参加にも対応しており、まずは現場で小さく試して効果を確かめる、ですね。
