一、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 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 模型的在線個性化。最重要的是我們從這樣的一個實踐中去發現，通過感知這種本地模型的子圖信息，確實能夠使整體性能有一個穩定的提升。同時也緩解了馬太效應。

圖數據上的尾部用戶，在推薦系統的馬太效應還是一個比較大的問題。但是如果我們通過分而治之的建模，對子圖進一步個性化，能夠提升稀疏行為用戶的推薦體驗。尤其是在尾部人群上面，性能的提升會更加明顯。

三、端云協同 GNNs 推薦系統的實現

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

當用戶行為特別稀疏驟變的情況下，推薦更依賴于常識推理。要協調這三種推薦行為，可以構建 Meta Controller - 元協調器，來協調 GNNs 推薦系統。

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

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

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

最后，探討一下端側 GNNs 推薦系統的安全問題。一旦端云協同 GNNs 推薦系統放開之后，勢必面臨開放環境的問題。因為要把模型上端做個性化就要去學習，就會有一些攻擊的風險，比如逃逸攻擊、投毒攻擊、后門攻擊等，最終可能導致推薦系統存在巨大風險。

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

五、問答環節

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

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