近 20 年来，计算形态在不断的演化。2010 年之前，云计算特别火，其他的计算形态比较微弱。随着硬件算力突飞猛进的发展，以及端侧芯片的引进，边缘计算也变得特别重要。当前的两大计算形态塑造了 AI 往两个两极化的方向发展，一方面在云计算的架构下，我们可以利用超大规模集群能力训练大规模的AI模型，比如 Foundation Model 或者一些生成模型。另一方面，随着边缘计算的发展，我们也可以将 AI 模型部署到端侧，做更轻量化的服务，比如在端侧做各种各样的识别任务。同时，随着元宇宙的发展，很多模型的计算都会放到端侧。所以这两种计算形态，其内核想调和的问题就是计算与传输的均衡，随之而来的是人工智能的两极化发展。
这两种计算形态给 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 推荐系统服务的实现形式有三种，第一种是 session recommendation，它是推荐系统中常见的为了节省开销的批量会话推荐，即一次进行批量的推荐，要求用户浏览很多商品才会重新触发推荐。第二种是极端的情况下一次只推荐一个。第三种是我们提到这种端侧的个性化模型。这三种推荐系统方法各有优势，当用户兴趣变化很缓慢的时候，我们只需要云侧感知得很准，所以云侧模型做 session recommendation 就足够了。当用户兴趣变化更加多样时，做端侧的子图的个性化推荐可以相对提升推荐性能。
在用户行为突然变得非常稀疏的情况下，推荐更加依赖于常识推理。为了协调这三种推荐行为，可以建立元协调器- Meta Controller，来协调GNNs推荐系统
构造三路共存的端云协同式的推荐系统一个挑战就是数据集的构建，因为我们也不知道怎么管理这几个模型，怎么做决策。所以这里只是通过一种反事实推理的机制，虽然我们没有这种数据集，但是我们有单路的数据集，通过评估构造一些代理模型去评估它们的因果效应。如果因果效应比较大，那么做这样的一个决策的收益就比较大，可以构建伪标签，即反事实数据集。具体步骤如下：
单路有三个模型 D0、D1、D2，通过学习一个代理的因果模型，估计它们的因果效应去构建一个决策标签，构建一个反事实数据集去训练元协调器。最终我们可以证明这个元协调器相对于单路的各个模型都有一个性能的稳定提升。相对于随机试探的方式具有显著的优势。我们可以通过这种方式来构造端云协同的推荐系统。
最后，我们来讨论一下端侧GNNs推荐系统的安全问题。一旦端云协同的GNNs推荐系统被开放使用，就必然面临着开放环境下的问题。因为要对模型进行个性化学习，就会存在一些攻击的风险，比如逃逸攻击、投毒攻击、后门攻击等，最终可能导致推荐系统面临巨大的安全风险
底层算力驱动了当前端云协同 GNNs 推荐系统的方向，但还处于发展的初期，并存在一些潜在的问题，比如安全问题，同时在个性化的模型建模领域也依然存在很大的提升空间。
A1：子图不是下发的，它其实是汇聚式的。第一点，子图下发是伴随式的。比如我们要做推荐商品的时候，它天然会携带商品的属性信息。在这里伴随式的下发是跟属性同级别的开销，其实开销不是很大。因为它不是把整个大图都下发下来，只是一些邻居子图，至多二阶的邻居子图还是非常小的。第二点，端上一部分子图还是依赖于用户行为的反馈做一些 co-occurrence 共点击自动构建的，所以它是一个双端汇聚的形式，总体开销不是特别大。
以上是应用于推荐系统的GNNs技术及其实际应用的详细内容。更多信息请关注PHP中文网其他相关文章！
