推荐系统论文 HeterogeneousGraph Augmented Multi-Scenario Sharing Recommendation with Tree-Guided

简介

Heterogeneous Graph Augmented Multi-Scenario Sharing Recommendation with Tree-Guided Expert Networks
是发表在2021WSDM上的一篇多任务学习模型。

我认为本文可以说一篇工业界的创新文章，论文依托于阿里巴巴的多个推荐scenario，基于MTL模型使用Tree-Guided Expert Network和Multi-view Heterogeneous Graph做到了离线线上A/B test比较明显的提升。

Sharing Recommendation

什么是sharing recommendation？
这个场景其实出现的频率并不高，可能读者比较陌生，这里我们借用论文中的图来进行简介：

分享给好友是现在的APP或者电商场景经常能够见到的功能。
sharing recommendation就是来解决如何给一个用户推荐他分享的可选的用户list

Problems

目前sharing recommendation面对几个困难：

1. 如何建立一个联合推荐模型适用于拥有大量用户的多个分享场景
2. 如何处理long-tail或者训练数据有限的冷启动场景
3. 如何结合这叫影响来更准确的进行推荐

MTL传统框架

首先介绍mixture of expert networks

图中灰色的部分是共享权重的bottom layer

假设x表示输入到expert network中的向量，如上图所示有两个expert，每个expert的输出向量用$f^k(x)$表示。

每个scenario（task） 有选择的结合expert networks的输出，然后在分别通过一个全连接的prediction layer（用$p^s()$表示）

${\hat{y}}^s$表示第s个scenario的预测结果。

$g_k^s(x)$表示第k个expert对第s个scenario的scalar value，通过如下式子得到：

Model

作者认为在真实的推荐系统中需要处理超过数以百计的推荐scenarios，并且其中大部分是long-tail或者是冷启动的场景。
在原论文中是这样说的：

我们必须明确地允许更多的参数共享，并充分利用上下文信息来解决严重的长尾问题。

我的理解是这样的，对于MMoE或者是MoE模型来说，子任务之间的相似度其实仍然是影响模型效果的重要影响因素。但是对于子任务数量众多并且存在大量long-tail问题和冷启动问题的scenarios的情况，传统MTL模型可能表现就会收到影响。

为了解决上述问题，作者提出Tree-guided Expert Networks

Tree-guided Expert Networks

这里借用论文中的例子：

当我们考虑“Makeups”场景，相关的Tree path是
C2C -> Sharing -> Entity -> Product -> Makeups（根节点开始）
C2C是比较宽泛的概念，对于Markups是一个具体的场景。
场景树中包含的丰富信息提供了有价值的知识，特别是在长尾场景中sharing推荐。此外，作者还利用这种层次结构选择性地结合专家网络的输出。

这里x表示expert networks的输入，由四个部分组成：

u，v分别表示用户和目标用户的表示。
t表示用户u和用户v的交互历史。
c表示当前scenario的上下文信息。

上图左边可以看出，模型保留了expert network每一层的输出，这是和传统expert network的区别之处。

$f_i^k(x)$表示k-th expert 的第i层的输出，同时论文中还强调了Tree的深度需要和expert layer层数相同。

在上图右边的Tree中，每一个完整的path都是从根节点开始，到叶子节点结束。对于每个node，用$o_i^s$表示scenario s 的第i层的表示。
然后将这一条路径的表示输入到一个LSTM中，主要是为了保留这个路径的顺序性。

$h_i^s$表示的是lstm输出的hidden state.

然后使用上式中输出的h来有选择的integrate i-th layer的输出：

整体的结构和MMoE还是大致相同的，但是输出换成了h。

最后我们结合整个模型的结构图，得到最后的预测${\hat{y}}_{uv}^s$:

Multi-view Heterogeneous Graph Augmentation

论文中以获取user u的表示为例：

如上图所示，对于每个u，包含多个view（friend，share，pay），对于每个view分别处理。

对于$u_i$第$l$层的embedding 在关系r(friend/share/pay)中表示为：$u_{i,r}^l$
是通过聚合邻居的embedding获得的：

上图中的第二个式子的$update$函数实现如下：

但是由于不同的scenario不同的邻居对于u的贡献是不同的，所以使用attention机制：
其中c表示的是context information


通过上述步骤我们可以获得friend，share，pay三个view的三个user u的embedding表示，但是还需要进行$combine$，通过如下公式：

combine 表示 concatenation操作。

Optimization

但是文中作者提到不希望某一个单一的expert占据主导，所以还设计了一个auxiliary loss来进行平衡。

最终的LOSS，有上面两个部分组成：

Dataset

Performance

大家共勉~~