一、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 共点击自动构建的，所以它是一个双端汇聚的形式，总体开销不是特别大。
