文章目录
简介
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面对几个困难:
- 如何建立一个联合推荐模型适用于拥有大量用户的多个分享场景
- 如何处理long-tail或者训练数据有限的冷启动场景
- 如何结合这叫影响来更准确的进行推荐
MTL传统框架
首先介绍mixture of expert networks
图中灰色的部分是共享权重的bottom layer
假设x表示输入到expert network中的向量,如上图所示有两个expert,每个expert的输出向量用 f k ( x ) f^k(x) fk(x)表示。
每个scenario(task) 有选择的结合expert networks的输出,然后在分别通过一个全连接的prediction layer(用 p s ( ) p^s() ps()表示)
y
^
s
\hat{y}^s
y^s表示第s个scenario的预测结果。
g
k
s
(
x
)
g_k^s(x)
gks(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 ) f_i^k(x) fik(x)表示k-th expert 的第i层的输出,同时论文中还强调了Tree的深度需要和expert layer层数相同。
在上图右边的Tree中,每一个完整的path都是从根节点开始,到叶子节点结束。对于每个node,用
o
i
s
o_i^s
ois表示scenario s 的第i层的表示。
然后将这一条路径的表示输入到一个LSTM中,主要是为了保留这个路径的顺序性。
h
i
s
h_i^s
his表示的是lstm输出的hidden state.
然后使用上式中输出的h来有选择的integrate i-th layer的输出:
整体的结构和MMoE还是大致相同的,但是输出换成了h。
最后我们结合整个模型的结构图,得到最后的预测 y ^ u v s \hat{y}_{uv}^s y^uvs:
Multi-view Heterogeneous Graph Augmentation
论文中以获取user u的表示为例:
如上图所示,对于每个u,包含多个view(friend,share,pay),对于每个view分别处理。
对于
u
i
u_i
ui第
l
l
l层的embedding 在关系r(friend/share/pay)中表示为:
u
i
,
r
l
u_{i,r}^l
ui,rl
是通过聚合邻居的embedding获得的:
上图中的第二个式子的
u
p
d
a
t
e
update
update函数实现如下:
但是由于不同的scenario不同的邻居对于u的贡献是不同的,所以使用attention机制:
其中c表示的是context information
通过上述步骤我们可以获得friend,share,pay三个view的三个user u的embedding表示,但是还需要进行
c
o
m
b
i
n
e
combine
combine,通过如下公式:
combine 表示 concatenation操作。
Optimization
但是文中作者提到不希望某一个单一的expert占据主导,所以还设计了一个auxiliary loss来进行平衡。
最终的LOSS,有上面两个部分组成:
Dataset
Performance
大家共勉~~