應用於推薦系統的GNNs技術及其實際應用

一、GNNs 推薦系統的底層算力演化

近 20 年來，計算形態在不斷的演化。 2010 年之前，雲端運算特別火，其他的運算形態比較微弱。隨著硬體算力突飛猛進的發展，以及端側晶片的引進，邊緣運算也變得特別重要。目前的兩大運算形態塑造了 AI 往兩個兩極化的方向發展，一方面在雲端運算的架構下，我們可以利用超大規模叢集能力訓練大規模的AI模型，例如 Foundation Model 或一些生成模型。另一方面，隨著邊緣運算的發展，我們也可以將 AI 模型部署到端側，做更輕量化的服務，例如在端側做各種各樣的辨識任務。同時，隨著元宇宙的發展，許多模型的計算都會放到端側。所以這兩種計算形態，其核心想調和的問題就是計算與傳輸的均衡，隨之而來的是人工智慧的兩極化發展。

二、端側GNNs 推薦系統的個人化

##這兩種計算形態為GNNs 推薦系統帶來了哪些機會？

端雲的視角可以類比為全域圖與本地化子圖的一個視角。在GNNs的推薦系統中，全域化子圖是由許多節點層級的子圖不斷匯聚而成的一個全域化子圖。它的優點在於資料完備，能夠提供比較全面的節點之間的關係。這種歸納偏置可能更加普適，總結了各種節點的規律並提取了歸納偏置，因此具有強大的泛化能力。而本地化子圖則不一定特別完備，但其優勢在於能夠精確地描述個人在該子圖上的行為演化，並提供個人化的節點關係建立。因此，端和雲端的關係就有點像是全域化子圖和在地化子圖。雲端運算可以提供強大的中心化算力來提供服務，而端則可以提供一些資料個人化的服務

我們可以結合全域圖和本地化子圖的優勢來更好地提升模型的效能，今年發表在WSDM2022 的一篇研究對此做了探索。它提出了一個 Ada-GNN（Adapting to Local Patterns for improving Graph Neural Networks）模型，對於全局圖有一個整圖的建模，同時也會以 subgraph 構建一些 local model 來做一些 adaptation。這樣的 adaptation 本質是讓全域模型和 local model 組合起來的模型更精細地去感知局部圖的規律，提升個人化學習表現。

現在我們透過一個具體的例子來闡述為什麼要關注子圖。在電商推薦系統中，有一個數位愛好者群體，能夠刻畫出這種數位產品，例如手機、Pad、相機和手機週邊產品的關聯關係。他一旦點擊了其中的一台相機，就會誘導出歸納偏置。群體貢獻圖誘導出來的一個歸納偏移圖可能促進我們去推薦這種手機，但是如果我們回歸到個體視角，如果他是一個攝影愛好者，特別關注聚焦於攝影類產品，這樣有時候就會產生下圖所示的悖論。群體貢獻圖誘導的歸納偏壓是不是對這樣的某些群體過強，尤其是這種尾部群體，這就是我們常說的馬太效應。

#

總的來說，現有的兩極化計算形態可以重新塑造我們對GNNs推薦系統的建模。傳統的推薦系統從候選池中召回商品或物品，並透過GNNs建模來感知它們之間的關係，然後對使用者進行排序推薦。然而，由於邊緣運算的支持，我們可以在端側部署個人化模型，透過對子圖進行學習，以感知更細粒度的個人化。當然，這種新的端雲協同的推薦系統架構有一個假設，即端設備的算力和功耗是可行的。但實際情況是，小型模型的算力開銷並不大，如果將其壓縮到一兩兆，並將計算開銷放在現有的智慧型手機上，實際上並不一定比一個遊戲APP消耗的算力和電能大。因此，隨著邊緣運算的進一步發展和端設備效能的提升，為在端側進行更多的GNNs建模提供了更大的可能性

##如果我們想把GNNs 模型放到端上，那麼必然要考慮端側算力和儲存能力。前面我們也提到了模型壓縮，要想 GNNs 模型在端側做得更有效，把一個相對比較大的  GNNs 模型放上去，一定要做模型壓縮。模型壓縮的傳統方法剪枝、量化都可以用到現有的 GNNs 模型上，但它們在推薦系統裡面都會導致效能損失。在這種場景下，我們不可能為了搭建一個端側模型而去犧牲效能，所以剪枝和量化雖然有用，但是作用有限。

另一個有用的模型壓縮方法是蒸餾。雖然可能只能降低數倍，但成本也差不多。最近在KDD上發表的一項研究是關於GNNs的蒸餾。在GNNs中，圖形化資料建模的蒸餾面臨一個挑戰，即在logit空間中很容易定義距離度量，但在潛在特徵空間中，尤其是teacher GNNs和student GNNs之間的逐層距離度量。對此，這項在KDD上的研究提供了一個解決方案，透過對抗生成的方式學習一個測量來實現可學習的設計

在GNNs推薦系統中，除了之前提到的模型壓縮技術，拆分部署是一項特定且​​非常有用的技術。它與GNNs推薦系統的模型架構密切相關，因為GNNs底層是商品的Item Embedding，並且經過幾層MLP的非線性變換後，才會使用GNNs的聚合策略

#一旦一個模型訓練好，就有一個天然的優勢。基礎層的部分都是共享的，只有GNNs層可以做一些個人化。這裡的個人化，我們可以將模型拆分為兩個部分，將模型的公共部分放到雲端，因為算力充足，個人化的部分則可以在終端機進行部署。這樣，我們在終端只需要儲存中間核心的GNN。在實際的推薦系統中，這種做法能夠大幅節省整個模型的儲存開銷。我們在阿里的場景下進行了實踐，拆分部署之後的模型可能達到KB級別，然後透過進一步簡單的位元量化模型，可以使模型變得特別小，放到終端幾乎沒有特別大的開銷。當然，這是基於經驗的拆分方法。華為最近在KDD上發表的一項工作是自動分割模型，它能夠感知終端設備的效能，並自動對這種模型進行拆分。當然，如果應用到GNNs上，可能還需要進行一些重塑

#在一些嚴重的分散轉移場景中部署模型時，我們的預訓練模型在部署到端側之前已經相對陳舊了。這是因為實際中的圖資料回流到雲端進行訓練的頻率相對較慢，有時可能需要一週的時間間隔

這裡的主要瓶頸是資源限制，雖然在研究上面不一定會遇到這種瓶頸，但在實際中會遇到端側模型老舊的問題。隨著領域的改變，資料的改變，模型不再適用，效能就會下降。這時候就需要 GNNs 模型的線上個人化，但在端上做個人化，會面對端側算力和儲存開銷的挑戰。

還有一個挑戰就是資料稀疏，因為端資料只有個體節點，所以其資料稀疏性也是一個很大的挑戰。最近的研究有一個比較有效率的做法，就是 Parameter-Efficient Transfer，在層之間打一些模型的補丁，可以類比殘差網絡，只是學習的時候學習一下補丁。透過一個 flag 機制，使用時開啟，不用即關掉，關掉就可以退化到原始的基礎模型，既安全又有效率。

這是一個比較實際且高效的做法，發表在 KDD2021 上面，能夠實現 GNNs 模型的線上個人化。最重要的是我們從這樣的一個實踐中去發現，透過感知這種本地模型的子圖訊息，確實能夠使整體性能有一個穩定的提升。同時也緩解了馬太效應。

在推薦系統中，尾部使用者在圖資料上仍面臨馬太效應的問題。然而，如果我們採用分而治之的建模方法，將子圖進行個人化處理，就能夠改善稀疏行為使用者的推薦體驗。尤其是對於尾部人群來說，效能的提升將更加顯著

#三、端雲協同GNNs 推薦系統的實作

在GNNs 推薦系統裡，一種是雲端服務的GNNs 模型，還有一種端側的GNNs 的小模型。 GNNs 推薦系統服務的實現形式有三種，第一種是 session recommendation，它是推薦系統中常見的為了節省開銷的批量會話推薦，即一次進行批量的推薦，要求用戶瀏覽很多商品才會重新觸發推薦。第二種是極端的情況下一次只推薦一個。第三種是我們提到這種端側的個人化模型。這三種推薦系統方法各有優勢，當使用者興趣變化很緩慢的時候，我們只需要雲側感知得很準，所以雲側模型做 session recommendation 就足夠了。當使用者興趣變化更加多元時，做端側的子圖的個人化推薦可以相對提升推薦效能。

在使用者行為突然變得非常稀疏的情況下，推薦更加依賴常識推理。為了協調這三種推薦行為，可以建立元協調器- Meta Controller，來協調GNNs推薦系統

建構三路共存的端雲協同的推薦系統一個挑戰就是資料集的構建，因為我們也不知道怎麼管理這幾個模型，怎麼做決策。所以這裡只是透過一種反事實推理的機制，雖然我們沒有這種資料集，但是我們有單路的資料集，透過評估建構一些代理模型去評估它們的因果效應。如果因果效應比較大，那麼做這樣的一個決策的收益就比較大，可以建構偽標籤，也就是反事實資料集。具體步驟如下：

單路有三個模型D0、D1、D2，透過學習一個代理人的因果模型，估計它們的因果效應去建立一個決策標籤，建構一個反事實資料集去訓練元協調器。最終我們可以證明這個元協調器相對於單路的各個模型都有一個性能的穩定提升。相對於隨機試探的方式具有顯著的優勢。我們可以透過這種方式來建構端雲協同的推薦系統。

四、端側 GNNs 推薦系統安全性問題

最後，我們來討論一下端側GNNs推薦系統的安全性問題。一旦端雲協同的GNNs推薦系統開放使用，就必然面臨開放環境下的問題。因為要對模型進行個人化學習，就會存在一些攻擊的風險，例如逃逸攻擊、投毒攻擊、後門攻擊等，最終可能導致推薦系統面臨巨大的安全風險

底層算力驅動了當前端雲協同GNNs 推薦系統的方向，但還處於發展的初期，並存在一些潛在的問題，例如安全問題，同時在個性化的模型構建模領域也依然存在很大的提升空間。

五、問答環節

Q1：在端上做圖模型，子圖的下發流量會不會太大？

A1：子圖不是下發的，它其實是匯聚式的。第一點，子圖下發是伴隨式的。例如我們要做推薦商品的時候，它天然會攜帶商品的屬性資訊。這裡伴隨式的下發是跟屬性同等級的開銷，其實開銷不是很大。因為它不是把整個大圖都下發下來，只是一些鄰居子圖，至多二階的鄰居子圖還是非常小的。第二點，端上一部分子圖還是依賴於用戶行為的回饋做一些 co-occurrence 共點擊自動構建的，所以它是一個雙端匯聚的形式，總體開銷不是特別大。

以上是應用於推薦系統的GNNs技術及其實際應用的詳細內容。更多資訊請關注PHP中文網其他相關文章！