導讀 近年來，随着圖神經網絡的興起，大量關于在推薦系統中使用 GNNs 的研究被發表。本文并非介紹一種新的 GNNs 推薦系統模型，而是從端雲的視角來介紹 GNNs 推薦系統的應用，通過 4 個方面來闡述 GNNs 推薦系統在端側實作的可行性。
主要内容如下：
1. GNNs 推薦系統的底層算力演化
2. 端側 GNNs 推薦系統的個性化
3. 端雲協同 GNNs 推薦系統的實作
4. 端雲 GNNs 推薦系統安全問題
分享嘉賓｜姚江超博士 上海交通大學 助理教授
出品社群｜DataFun
01
GNNs 推薦系統的底層算力演化
近 20 年來，計算形态在不斷的演化。2010 年之前，雲計算特别火，其他的計算形态比較微弱。随着硬體算力突飛猛進的發展，以及端側晶片的引進，邊緣計算也變得特别重要。目前的兩大計算形态塑造了 AI 往兩個兩極化的方向發展，一方面在雲計算的架構下，我們可以利用超大規模叢集能力訓練大規模的AI模型，比如 Foundation Model 或者一些生成模型。另一方面，随着邊緣計算的發展，我們也可以将 AI 模型部署到端側，做更輕量化的服務，比如在端側做各種各樣的識别任務。同時，随着元宇宙的發展，很多模型的計算都會放到端側。是以這兩種計算形态，其核心想調和的問題就是計算與傳輸的均衡，随之而來的是人工智能的兩極化發展。
02
端側 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 space 距離度量很容易定義，但是在 latent feature space 的距離度量，尤其是 teacher GNNs 和 student GNNs 逐層之間的距離度量。對此，KDD 上的這篇工作提供了一個解決方案，通過對抗生成的方式來學習一個 metric 來實作 learnable 設計。
除了上面提到的模型壓縮技術，拆分部署是一個在 GNNs 推薦系統上特定且特别有用的技術。它跟 GNNs 推薦系統的模型架構非常有關系，因為 GNNs 底層是一個商品的 Item Embedding，還要經過幾層的 MLP 的非線性變換完之後，才會有這種 GNNs 的 aggregation 的政策進來。
一旦一個模型訓練好，就有一個天然的優勢，基礎層的部分都是共享的，隻有 GNNs 層可以做一些個性化。在這裡的個性化我們就可以把模型一拆為二，把模型公共的部分放到雲側，因為算力充足，個性化的部分就可以放到端側進行部署。這樣我們在端側隻需要存儲中間核心的 GNN。在實際的推薦系統中，能夠極大地節省整個模型的存儲開銷。我們在阿裡的場景下實踐過，拆分部署之後的模型可能達到 KB 級别，然後做進一步簡單的比特量化模型能夠做到特别小，放到端側基本沒有特别大的開銷。當然這是一個經驗上的拆分，華為最近發表在 KDD 上的一個工作是做了模型的自動拆分，它會感覺端裝置的性能自動化對這種模型拆分。當然如果應用到 GNNs 上面，可能還是需要一些重塑。
在端側一些 distribution shift 嚴重的場景部署模型時，我們的預訓練好的模型在放到端上之前其實已經比較老舊了，這是由于在實際中的圖資料回流到雲端去訓練的頻次比較緩慢，有時候會隔一周。
這裡的主要瓶頸是資源限制，雖然在研究上面不一定會遇到這種瓶頸，但在實際中會遇到端側模型老舊的問題。随着領域的改變，資料的改變，模型已經不再适用，性能就會下降。這時候就需要 GNNs 模型的線上個性化，但是在端上做個性化，會面對端側算力和存儲開銷的挑戰。
還有一個挑戰就是資料稀疏，因為端資料隻有個體節點，是以其資料稀疏性也是一個很大的挑戰。最近的研究有一個比較高效的做法，就是 Parameter-Efficient Transfer，在層之間打一些模型的更新檔，可以類比殘差網絡，隻是學習的時候學習一下更新檔。通過一個 flag 機制，使用時開啟，不用即關掉，關掉就可以退化到原始的基礎模型，既安全又高效。
這是一個比較實際且高效的做法，發表在 KDD2021 上面，能夠實作 GNNs 模型的線上個性化。最重要的是我們從這樣的一個實踐中去發現，通過感覺這種本地模型的子圖資訊，确實能夠使整體性能有一個穩定的提升。同時也緩解了馬太效應。
圖資料上的尾部使用者，在推薦系統的馬太效應還是一個比較大的問題。但是如果我們通過分而治之的模組化，對子圖進一步個性化，能夠提升稀疏行為使用者的推薦體驗。尤其是在尾部人群上面，性能的提升會更加明顯。
03
端雲協同 GNNs 推薦系統的實作
在 GNNs 推薦系統裡，一種是雲側服務的 GNNs 模型，還有一種端側的 GNNs 的小模型。GNNs 推薦系統服務的實作形式有三種，第一種是 session recommendation，它是推薦系統中常見的為了節省開銷的批量會話推薦，即一次進行批量的推薦，要求使用者浏覽很多商品才會重新觸發推薦。第二種是極端的情況下一次隻推薦一個。第三種是我們提到這種端側的個性化模型。這三種推薦系統方法各有優勢，當使用者興趣變化很緩慢的時候，我們隻需要雲側感覺得很準，是以雲側模型做 session recommendation 就足夠了。當使用者興趣變化更加多樣時，做端側的子圖的個性化推薦可以相對提升推薦性能。
當使用者行為特别稀疏驟變的情況下，推薦更依賴于常識推理。要協調這三種推薦行為，可以建構 Meta Controller - 元協調器，來協調 GNNs 推薦系統。
構造三路共存的端雲協同式的推薦系統一個挑戰就是資料集的建構，因為我們也不知道怎麼管理這幾個模型，怎麼做決策。是以這裡隻是通過一種反事實推理的機制，雖然我們沒有這種資料集，但是我們有單路的資料集，通過評估構造一些代理模型去評估它們的因果效應。如果因果效應比較大，那麼做這樣的一個決策的收益就比較大，可以建構僞标簽，即反事實資料集。具體步驟如下：
單路有三個模型 D0、D1、D2，通過學習一個代理的因果模型，估計它們的因果效應去建構一個決策标簽，建構一個反事實資料集去訓練元協調器。最終我們可以證明這個元協調器相對于單路的各個模型都有一個性能的穩定提升。相對于随機試探的方式具有顯著的優勢。我們可以通過這種方式來構造端雲協同的推薦系統。
04
端側 GNNs 推薦系統安全問題
最後，探讨一下端側 GNNs 推薦系統的安全問題。一旦端雲協同 GNNs 推薦系統放開之後，勢必面臨開放環境的問題。因為要把模型上端做個性化就要去學習，就會有一些攻擊的風險，比如逃逸攻擊、投毒攻擊、後門攻擊等，最終可能導緻推薦系統存在巨大風險。
底層算力驅動了目前端雲協同 GNNs 推薦系統的方向，但還處于發展的初期，并存在一些潛在的問題，比如安全問題，同時在個性化的模型模組化領域也依然存在很大的提升空間。
05
問答環節
Q1：在端上做圖模型，子圖的下發流量會不會太大？
A1：子圖不是下發的，它其實是彙聚式的。第一點，子圖下發是伴随式的。比如我們要做推薦商品的時候，它天然會攜帶商品的屬性資訊。在這裡伴随式的下發是跟屬性同級别的開銷，其實開銷不是很大。因為它不是把整個大圖都下發下來，隻是一些鄰居子圖，至多二階的鄰居子圖還是非常小的。第二點，端上一部分子圖還是依賴于使用者行為的回報做一些 co-occurrence 共點選自動建構的，是以它是一個雙端彙聚的形式，總體開銷不是特别大。
今天的分享就到這裡，謝謝大家。