GNN の推奨システムとアプリケーション

1. GNN推奨システムの基礎となる計算能力の進化

過去 20 年間にわたり、コンピューティングは進化してきました。 2010 年以前は、クラウド コンピューティングが非常に普及していましたが、他の形式のコンピューティングは比較的弱かったです。ハードウェアのコンピューティング能力の急速な発展と端末チップの導入により、エッジ コンピューティングが特に重要になっています。現在の 2 つの主要なコンピューティング形式は、AI の発展を 2 つの極端に異なる方向に形作っています。一方では、クラウド コンピューティング アーキテクチャの下で、超大規模クラスター機能を使用して、Foundation Models や一部の生成モデルなどの大規模な AI モデルをトレーニングできます。一方、エッジコンピューティングの発展により、エンド側にAIモデルを展開し、エンド側で各種認識タスクを実行するなど、より軽量なサービスを提供することも可能になります。同時に、メタバースの発展に伴い、多くのモデルの計算がエンド側に配置されます。したがって、これら 2 つのコンピューティング形式が解決したい中心的な問題は、コンピューティングと伝送のバランスであり、これが人工知能の二極化した発展につながります。

2. オンデバイスGNN推奨システムのパーソナライゼーション

これら 2 つのコンピューティング形式は、GNN 推奨システムにどのような機会をもたらすのでしょうか?

エンドクラウドの観点は、グローバルグラフとローカライズされたサブグラフの観点に似ています。GNNの推奨システムでは、グローバルサブグラフは、多数のノードレベルのサブグラフを継続的に収束させることによって構築されます。その利点は、データが完全であり、ノード間の比較的包括的な関係を提供できることです。その帰納的バイアスはより普遍的である可能性があります。さまざまなノードのルールを要約して帰納的バイアスを抽出できるため、強力な一般化能力を備えています。ローカライズされたサブグラフは必ずしも完全ではありませんが、その利点は、このサブグラフ内で進化する人の行動を正確に記述できることと、優先ノードによって確立された関係性を提供できることです。これは高度にパーソナライズされています。したがって、クラウドとエンドの関係は、グローバル サブグラフとローカル サブグラフに少し似ています。クラウド コンピューティングは、サービスを提供するために強力な集中型コンピューティング能力を提供し、最終的にはパーソナライズされたデータ サービスを提供できます。

グローバル グラフとローカライズされたサブグラフの利点を組み合わせることで、モデルのパフォーマンスをさらに向上させることができます。今年の WSDM2022 で発表された研究では、この点が検討されました。これは、グローバル グラフの全体グラフ モデリングを備え、サブグラフを使用していくつかのローカル モデルを構築し、いくつかの適応を実行する Ada-GNN (グラフ ニューラル ネットワークを改善するためのローカル パターンへの適応) モデルを提案します。このような適応の本質は、グローバルモデルとローカルモデルを組み合わせたモデルがローカルグラフのルールをより細かく認識し、パーソナライズされた学習パフォーマンスを向上させることです。

ここで、サブグラフに注意を払う必要がある理由を具体的な例を使って説明しましょう。電子商取引の推奨システムには、携帯電話、タブレット、カメラ、携帯電話周辺機器などのデジタル製品間の関係を特徴付けることができるデジタル愛好家のグループが存在します。彼がカメラの 1 つをクリックすると、誘導バイアスが誘発されます。グループ貢献グラフによって誘導された帰納的バイアス グラフは、このタイプの携帯電話を推奨するように促す可能性がありますが、個人の視点に戻ると、その人が写真愛好家であり、写真製品に特別な注意を払っている場合、下の図に示すようなパラドックスにつながることがあります。グループ貢献グラフによって誘発される誘導バイアスは、特定のグループ、特に末端グループにとって強すぎるのでしょうか? これは、私たちがよくマシュー効果と呼ぶものです。

一般的に、既存の二極化コンピューティング形式により、GNN 推奨システムのモデリングを実際に再構築することができます。従来の推奨システムは、候補プールからいくつかの製品またはアイテムを呼び出し、それらを分類し、ユーザーに推奨することができます。その過程で、GNN モデリングを通じてオブジェクト間の関係を認識できます。しかし同時に、エッジ コンピューティングのサポートにより、端末側に特定のパーソナライズされたモデルを展開してサブグラフ上で学習し、よりきめ細かいパーソナライズを認識できるようになることがわかります。もちろん、このような新しいエンドクラウド協調型レコメンデーションシステムのアーキテクチャには、一定の前提があります。エンドデバイスのコンピューティング能力と消費電力は比較的実現可能ですが、実際には、小型モデルのコンピューティング能力のオーバーヘッドは大きくありません。1〜2メガバイトに圧縮できる場合、そのコンピューティングオーバーヘッドは、既存のスマートフォンに配置されたゲームアプリのコンピューティング能力と消費電力よりも必ずしも大きくはありません。したがって、エッジコンピューティングのさらなる発展と端末デバイスのパフォーマンスの向上により、端末側でのさらなる GNN モデリングの可能性が広がります。

GNN モデルを端末に配置する場合は、端末の計算能力とストレージ容量を考慮する必要があります。先ほどモデル圧縮について説明しました。クライアント側で GNN モデルをより効果的にするために、比較的大きな GNN モデルを配置する場合は、モデル圧縮を実行する必要があります。プルーニングや量子化などの従来のモデル圧縮方法は既存の GNN モデルで使用できますが、推奨システムではパフォーマンスの低下を引き起こします。このシナリオでは、エンドサイド モデルを構築するためにパフォーマンスを犠牲にすることはできないため、プルーニングと量子化は有用ですが、効果は限られています。

もう 1 つの便利なモデル圧縮方法は蒸留です。蒸留ではモデルを数倍しか削減できませんが、コストは同様です。最近、KDD で GNN の蒸留を実行する研究が発表されました。GNN のこの種のグラフィカル データ モデリングにおける蒸留の課題の 1 つは、ロジット空間距離メトリックは定義しやすいものの、潜在的特徴空間での距離メトリック、特に教師 GNN と生徒 GNN 間のレイヤーごとの距離メトリックは定義が難しいことです。この点に関して、KDD に関するこの研究は、敵対的生成を通じてメトリックを学習し、学習可能な設計を実現するソリューションを提供します。

上記のモデル圧縮技術に加えて、分割展開は GNN 推奨システムに特有の、特に有用な技術です。これは、GNN 推奨システムのモデル アーキテクチャと密接に関連しています。GNN の最下層は製品のアイテム埋め込みであり、GNN 集約戦略が導入される前に、MLP 非線形変換の複数の層を通過する必要があるためです。

モデルがトレーニングされると、ベース レイヤーが共有され、GNN レイヤーのみをパーソナライズできるという自然な利点が得られます。ここで、パーソナライズのために、モデルを 2 つの部分に分割し、モデルの公開部分をクラウド側に配置することができます。十分な計算能力があるため、パーソナライズされた部分は端末側に展開できます。この方法では、中間カーネルの GNN をクライアント側に保存するだけで済みます。実際のレコメンデーションシステムでは、モデル全体のストレージオーバーヘッドを大幅に節約できます。これをAlibabaのシナリオで実践しました。分割して展開すると、モデルはKBレベルに達する可能性があります。すると、単純なビット量子化モデルを非常に小さくすることができ、端末側に配置しても基本的に特に大きなオーバーヘッドはありません。もちろん、これは経験的な分割です。Huaweiは最近、モデルを自動的に分割するKDDに関する研究を発表しました。エンドデバイスのパフォーマンスを認識し、モデルを自動的に分割します。もちろん、GNN に適用する場合は、何らかの再形成が必要になる可能性があります。

クライアント側で分布が大きく変化するシナリオでモデルを展開する場合、事前トレーニング済みのモデルはクライアント側に配置される前にかなり古いものになります。これは、実際にはグラフ データがトレーニングのためにクラウドに戻ってくる頻度が比較的低く、週に 1 回程度である場合があるからです。

ここでの主なボトルネックとなるのは、リソースの制約です。このボトルネックは研究では発生しないかもしれませんが、実際には、エンドサイドのモデルが時代遅れであるという問題に遭遇することになります。ドメインとデータが変更されると、モデルは適用できなくなり、パフォーマンスが低下します。現時点では、GNN モデルのオンライン パーソナライゼーションが必要ですが、端末でのパーソナライゼーションでは、端末の計算能力とストレージのオーバーヘッドの面で課題が生じます。

もう 1 つの課題は、データのスパース性です。最終データには個々のノードしかないため、データのスパース性も大きな課題です。最近の研究では、より効率的なアプローチであるパラメータ効率転送が採用されています。これは、レイヤー間でいくつかのモデルをパッチするものです。残差ネットワークと比較できますが、学習中はパッチのみが学習されます。フラグ機構により、使用時にオンにし、使用しない時にオフにすることができます。オフにすると、元の基本モデルに退化することができ、安全で効率的です。

これは、KDD2021 で公開された、より実用的で効率的なアプローチであり、GNN モデルのオンライン パーソナライゼーションを実現できます。最も重要なことは、このような実践から、このローカル モデルのサブグラフ情報を認識することで、全体的なパフォーマンスを確かに着実に向上できることがわかったことです。同時に、マシュー効果も緩和されます。

グラフデータにおけるテールユーザーのマシュー効果は、推奨システムにおいて依然として大きな問題です。ただし、分割統治モデリングを通じてサブグラフをさらにパーソナライズすると、スパースな動作をするユーザーに対する推奨エクスペリエンスを向上させることができます。特に末端のグループの人々にとっては、パフォーマンスの向上がより明白になります。

3. エンドクラウド協調型GNN推奨システムの実装

GNN 推奨システムには、クラウド側サービス用の GNN モデルとクライアント側用の小規模な GNN モデルがあります。 GNN の推奨システム サービスには、3 つの実装形式があります。1 つ目はセッション推奨です。これは、コストを節約するために推奨システムでよく使用されるバッチ セッション推奨です。つまり、バッチ推奨は一度に行われるため、ユーザーは推奨を再度トリガーする前に多くの製品を閲覧する必要があります。 2 つ目は、極端な場合には一度に 1 つだけ推奨することです。 3 番目のタイプは、前述したエンドサイドのパーソナライズ モデルです。これら 3 つの推奨システム方法にはそれぞれ利点があります。ユーザーの興味の変化が非常に遅い場合は、クラウド側で正確に認識するだけでよいため、セッション推奨にはクラウド側のモデルで十分です。ユーザーの興味がより多様化すると、クライアント側でのサブグラフのパーソナライズされた推奨によって、推奨パフォーマンスが相対的に向上する可能性があります。

ユーザーの行動が特にまばらで突然変化する場合は、推奨事項は常識的な推論に大きく依存します。これら 3 つの推奨動作を調整するために、GNN 推奨システムを調整するメタ コントローラーを構築できます。

3 方向共存エンドクラウド共同推奨システムを構築する際の課題の 1 つは、データセットの構築です。これは、これらのモデルの管理方法や意思決定方法がわからないためです。ここでは、反事実的推論のメカニズムを使用します。そのようなデータセットはありませんが、一方向データセットはあります。いくつかのプロキシモデルを評価および構築することで、それらの因果効果を評価できます。因果効果が大きい場合、そのような決定を行うことの利点は比較的大きく、疑似ラベル、つまり反事実データセットを構築できます。具体的な手順は次のとおりです。

1 つのチャネルに 3 つのモデル D0、D1、D2 があります。エージェントの因果モデルを学習することで、それらの因果効果が推定され、決定ラベルが構築され、メタコーディネーターをトレーニングするための反事実データセットが構築されます。最終的に、このメタコーディネーターはさまざまなシングルチャネルモデルよりも安定したパフォーマンスの向上を実現できることを証明できます。ランダム試験に比べて大きな利点があります。この方法を使用すると、エンドとクラウドが連携したレコメンデーション システムを構築できます。

4. オンデバイスGNN推奨システムのセキュリティ問題

最後に、エンドサイド GNN 推奨システムのセキュリティの問題について説明します。エンドクラウド協調型 GNN 推奨システムがリリースされると、必然的にオープン環境の問題に直面することになります。モデルの上位をパーソナライズするには学習が必要であるため、エスケープ攻撃、ポイズニング攻撃、バックドア攻撃などの攻撃のリスクがあり、最終的には推奨システムに大きなリスクをもたらす可能性があります。

現在のエンドクラウド協調型 GNN 推奨システムの方向性は、基盤となるコンピューティング能力によって推進されていますが、まだ開発の初期段階にあり、セキュリティ問題などの潜在的な問題がいくつかあります。同時に、パーソナライズされたモデルモデリングの分野では、まだ改善の余地が多く残っています。

5. 質疑応答

Q1: クライアント上でグラフ モデルを構築する場合、サブグラフを送信するために必要なトラフィックが大きくなりすぎませんか?

A1: サブグラフは分散されているのではなく、集約されています。まず、サブグラフが同時に送信されます。例えば、商品をおすすめしたい場合、当然その商品の属性情報も伴います。ここで、付随する配布には属性と同じレベルのオーバーヘッドがあり、実際のところオーバーヘッドはそれほど大きくありません。なぜなら、大きなグラフ全体が送信されるのではなく、一部の隣接サブグラフのみが送信され、最大でも 2 次隣接サブグラフは非常に小さいからです。第二に、エンドのサブグラフの一部は、ユーザーの行動からのフィードバックに依存して共起クリックを自動的に構築するため、デュアルエンド集約の一形態であり、全体的なオーバーヘッドはそれほど大きくありません。