|
Google: Bootstrapping Recommendations at Chrome Web Store（KDD2021）
1. Introduction
业务场景：
??Google Chrome 中 Chrome Web Store，推荐浏览器第三方插件（以下以item代称）
任务：
??在现实数据中，从零开始搭建大规模推荐系统
困难：
??不同于学术研究中已处理好的数据，现实中通常面临隐私限制、数据分布不均、数据稀疏等问题
contributions：
??1.设计了快速可解释非个性化神经网络排序模型（non-personalized recommendation），有助于从零开始的推荐系统进行数据和特征分析，从而实现快速训练和推断，为后续更先进的模型快速迭代铺路
??2.设计了相关推荐模型（related extension recommendations），利用新的item-item based算法，解决现实数据问题
??3.结合前两种模型，设计了个性化推荐模型（personalized recommen- dations），有效缩短开发周期，并规避了业务面临的困难
2. non-personalized recommendation
目的：快速构建打通pipeline，帮助端到端推荐更快实现，并更易分析解决机器学习模型问题
负责业务：面向未登录用户推荐猜喜
2.1 模型架构
数据：
（input）每个item构建为k-dim向量 x
（input）简单的上下文特征 q，如浏览器设置的地区、语言
（label）对当前item的操作（1-点击，2-安装，0-otherwise）
模型：
??Neural RankGAM：从零开始搭建推荐系统过程中，为了方便迭代，选择训练可解释的generalized additive models (GAMs)。为每个特征单独构建子模型，再将子模型输出的和作为预测结果
y
^
=
f
(
x
)
=
∑
j
f
j
(
x
j
)
\hat{y}=f(\bold{x})=\sum_{j}f_{j}(x_{j})
y^?=f(x)=∑j?fj?(xj?)
??Neural RankGAM+：引入简单的上下文特征
y
^
=
f
(
q
,
x
)
=
∑
j
w
j
(
q
)
f
j
(
x
j
)
\hat{y}=f(\bold{q,x})=\sum_{j}w_{j}(\bold{q})f_{j}(x_{j})
y^?=f(q,x)=∑j?wj?(q)fj?(xj?)
2.2 改进
case：线上落败
原因：线上线下数据分布差异，线上候选集为整个item空间，而训练主要针对最热item
可选方案：对训练数据加权等；增加候选filter，对线上item只推荐训练数据中高频出现的item
3. related extension recommendations
面向业务：推荐当前item的相似扩展item
3.1 尝试1:pointwise mutual information (PMI)
??对于任意两个item，计算其pointwise mutual information (PMI)（类似于item共现分）
??
P
M
I
(
e
1
,
e
2
)
=
N
#
(
e
1
,
e
2
)
#
(
e
1
)
#
(
e
2
)
PMI(e_1,e_2) = \frac{N \#(e_1, e_2)}{\#(e_1)\#(e_2)}
PMI(e1?,e2?)=#(e1?)#(e2?)N#(e1?,e2?)?，给定
e
1
e_1
e1?下，
P
M
I
(
e
1
,
?
)
∝
#
(
e
1
,
e
2
)
#
(
e
2
)
PMI(e_1, \cdot)\propto\frac{ \#(e_1, e_2)}{\#(e_2)}
PMI(e1?,?)∝#(e2?)#(e1?,e2?)?
面临困难：
??1.冷启动问题：当前item没有任何交互数据
??2.PMI一直在尝试推荐相关但罕见的item（极端情况可以考虑
e
2
e_2
e2?仅和
e
1
e_1
e1?共现，其余情况均不安装）
3.2 尝试2: learning to rank formulation
对于共现数据
{
e
1
,
e
2
,
e
3
}
\{e_1,e_2,e_3\}
{e1?,e2?,e3?}，相互作为正样例，从整个空间中采样负样例
case1：所有相似推荐结果同质化（对于不同item推荐列表不变）
原因：安装item的分布是高度不均的，热度集中在少数item上
case2：针对case1优化，如加权，启发式负采样，更通用的特征（如文本类特征），但线上落败
原因：从一个极端（最热）到另一个极端（相关但不流行），单纯使用基于学习的方法在最热和相关之间取舍很难
3.3 A new hybrid item-item recommendation method
3.3.1 Mixture model解决流行度偏差
??假设given
e
1
e_1
e1?下，
e
2
e_2
e2?安装的概率由
P
i
n
s
t
a
l
l
e
d
(
e
2
∣
e
1
)
=
(
1
?
λ
)
P
r
e
l
a
t
e
d
(
e
2
∣
e
1
)
+
λ
P
(
e
2
)
P_{installed} (e_2|e_1)=(1-\lambda)P_{related}(e_2|e_1)+\lambda P(e_2)
Pinstalled?(e2?∣e1?)=(1?λ)Prelated?(e2?∣e1?)+λP(e2?)给出
??用共现计数定义最大似然问题
L
=
∑
e
2
l
o
g
(
P
i
n
s
t
a
l
l
e
d
(
e
2
∣
e
1
)
)
L= \sum_{e_2}log(P_{installed} (e_2|e_1))
L=∑e2??log(Pinstalled?(e2?∣e1?))
??从而求出相似度
P
r
e
l
a
t
e
d
(
e
2
∣
e
1
)
P_{related}(e_2|e_1)
Prelated?(e2?∣e1?)
3.3.2 Hybrid method
mixture model给出更流行的item，与PMI互补，因此采用加权和
P
M
I
(
e
1
,
e
2
)
+
w
P
r
e
l
a
t
e
d
(
e
2
∣
e
1
)
,
w
=
5.0
PMI(e_1,e_2) + wPrelated(e_2|e_1), w=5.0
PMI(e1?,e2?)+wPrelated(e2?∣e1?),w=5.0。
然而mixture model 和hybird method都没能解决冷启动问题，因此引入额外信息，用bert获得item的文本embedding，以此作为base score，进而基于流行度重排。
4. personalized recommendation
负责业务：面向登录用户推荐猜喜
面临困难：涉及隐私限制
4.1 尝试1:采用序列建模用户安装item
将用户的安装历史item按序排列，预测下一个，但最终落败
原因：数据稀疏、分布不均、时序很短
4.2 A bootstrapping approach
- 利用前两种推荐模型，对用户安装历史(len=n)中所有item构建其相似集（共n个）
- 新增一个non-personalized recommendation 结果（有助于多样性）
- 每次取这n + 1个集合中的第 i 个 按流行度排列接在之前列表（前i - 1个生成的结果哦）后
5. future work
- non-personalized recommendation：尝试更复杂的机器学习模型
- related extension recommendations：在保障隐私的同时获得session数据；微调bert更好解决长尾问题；用统一的机器学习方法均衡流行度和相似度
- personalized recommendation：针对数据高度分布不均构建统一模型；提升前两种模型能力；探索其他方法，包括引入其他业务数据
|