©作者 | 机器之心编辑部
来源 | 机器之心
10 月 20 日,信息检索和数据挖掘领域的顶级会议之一 CIKM 2022 公布论文奖项,快手社区科学团队获得了应用研究方向「最佳论文奖」。
获奖论文《Real-time Short Video Recommendation on Mobile Devices》针对短视频推荐场景,传统服务端部署的推荐系统在决策时机和实时特征利用方面的不足问题,通过在移动客户端部署推荐系统来实时响应用户反馈,提高推荐结果的精准度,从而提升用户体验。论文提出的方案 100% 流量部署到了快手短视频推荐生产环境,影响了日均超过 3.4 亿用户的体验,是端上智能在大规模推荐场景落地的创新实践。
Real-time Short Video Recommendation on Mobile Devices
论文来源:
论文链接:
https://dl.acm.org/doi/10.1145/3511808.3557065
近年来,越来越多的用户通过短视频应用来学习和娱乐,并通过丰富的隐式和显式反馈来表达对视频内容的满意度,比如点赞、收藏、分享等(如图 1 所示)。
▲ 图1. 快手应用界面:沉浸式观看,丰富的显式 / 隐式反馈
为了给用户推荐其感兴趣的内容,推荐系统必需通过用户的显式或者隐式反馈来感知用户的实时兴趣。由于短视频时长较短,内容主题也多种多样,用户在短时间内会观看很多不同主题的内容,实时兴趣会发生快速变化,这给推荐系统带来了很大的挑战。
传统推荐系统完全部署在服务端,由于整体复杂性高,链路耗时比较长(1 秒左右),同时为了给客户端留出足够的时间来预加载和渲染视频,防止播放时造成卡顿,因此通常采取分页请求的方式,每次返回多个视频给客户端,依次展示给用户,用户看完前,客户端再发起下一次请求。这种架构会带来两个问题:
1. 决策机会角度:服务端只有在接收到客户端的请求时才有机会调整后续推荐内容,而无法对用户的实时反馈马上做出响应。即使用户对某类内容表现出了明显的偏好或厌恶,客户端也没有办法对候选中的类似内容做提前或者打压操作。
2. 特征时效性角度:用户的反馈必需回传到服务端才能被利用,整个链路延迟通常长达几十秒甚至几分钟,对特征的时效性有很大的影响。同时,有一些客户端独有的特征,比如当前时刻下,设备的网速、每个候选视频的预加载时长等,在服务端是无法获取的,但这些因素也会对用户体验造成影响。
随着移动设备算力和存储资源的快速提升,以及移动端深度学习框架的发展,现在已经可以在移动设备上进行深度学习模型推理甚至训练,因此我们通过在移动设备上部署一个重排系统来解决上述问题(图 2)。通过端上重排模型来实现用户反馈信号和客户端独有特征的实时利用,从而得到当前上下文下更准确的预估值。在此基础上,通过自适应确定搜索步数的 beam search 来生成整体效果更好的排序,从而提升用户体验,并带来显著的线上效果提升。
系统框架
1. 服务端的推荐系统。这部分就是传统的推荐系统,通常包括召回、排序、重排等环节,最终输出几十个左右的候选视频。一些服务端能获取到的特征也会被抽取出来,随着候选视频一起发送到客户端。
2. 模型训练系统。这个模块负责训练拼接训练样本,并训练端上重排模型。训练过程中会定期导出 checkpoint,并转换成 TFLite 格式下发到客户端。
3. 客户端推荐系统。这是整个系统的核心模块,负责客户端的特征收集,以及根据用户行为触发候选视频重排。
在现有的公开资料中,端上重排模型一般被设计成端云结合的结构,比如 EdgeRec。即模型在部署时会拆分成两部分,参数量最多的 embedding 部分部署在服务端,上层 DNN 部分部署在客户端。我们设计了一个超轻量级的小模型,可以整体部署在客户端。之所以采取这种设计,有如下三个原因:
1. 服务端的精排模型是一个非常复杂的超大规模千亿参数模型,在精排模型的预估值中已经蕴含了输入特征中的精华信息,客户端的重排模型可以直接将其作为输入,减少重复计算,也省去了搭建一套类似 pipeline 的训练和预测资源开销。同时,拆分部署的架构会增加维护的复杂性,比如客户端的模型更新受到很多限制,可能同时存在非常多的模型版本,需要保证服务端参数和客户端参数的一致性,这些也会带来更多的资源开销。
2. 客户端能获取的实时特征都是比较小规模,并且有明确含义的,比如用户的反馈、网速信号等,这些特征也不需要太复杂的网络结构来学习。
3. 精排模型用到了用户的长期行为序列,能学到用户的长期兴趣,和客户端侧重于用户实时兴趣感知的模型正好互补。
我们离线做过对比实验,相对于我们设计的超轻量级模型,增加更多特征和更复杂结构的模型并没有带来明显的离线指标提升。
1. 精排模型预估分。前面提到过,精排模型用到的特征和模型结构都很复杂,因此其预估分有很丰富的信息量,这也决定了精排的预估分是非常重要的输入特征。同时精排模型用到了视频 id、用户 id 等记忆性特征,以及非常长的用户历史行为序列,因此很擅长捕捉用户的长期兴趣,和客户端侧重用户实时反馈的重排模型正好互补。
2. 视频静态属性。为了减少参数量,我们主要选择视频的类别、时长等维度比较低的属性,整体 id 特征的取值数量不超过 10000。
3. 客户端特征。用户在观看视频的过程中,客户端会收集用户反馈、观看时长等信息,并组织成按观看时间排序的序列格式,同时也会收集当前的网速、视频预加载时长等客户端独有的特征,作为端上重排模型输入。
1. 候选视频精排 pXTR 和观看历史视频 pXTR 的差值。不同用户天然存在的 bias 会导致用户间的 pXTR 并不直接可比,比如有些用户 pXTR 会整体偏高或偏低,由于端上重排模型中没有用到 uid 等特征,直接用 pXTR 的原始分值作为特征会干扰模型学习。通过 pXTR 之差可以消除这种 bias,并且以最近看过的视频 pXTR 为锚点,可以感知用户的实时兴趣偏好。
2. 视频曝光时间之差。通常来说离当前时间越近的视频影响越大。
3. 视频曝光位置之差。用户观看视频的速度通常变化较大,此时曝光位置之差比曝光时间之差会更稳定。两者结合起来可以建模视频在时间和空间上的互相影响。
以上特征会进一步和已观看视频的类别以及对应的用户反馈进一步交叉,来捕捉用户的细粒度偏好。
2.4 模型结构
▲ 图3. 端上重排模型
整体模型结构如图 3 所示,除了直接引入候选视频特征和其他特征(如客户端特征)之外,模型主要通过 target attention 来建模已观看的视频序列和候选视频之间的关系,以及已排序候选序列和候选视频之间的关系。上层通过 MMoE 模块来建模 3 个目标,分别是 has_next(下滑)、effective_view(有效播放)和 like(点赞)。
相对于贪心的单点排序,我们更希望能考虑候选视频之间的互相影响,得到整体效果最好的序列。这里序列整体的效果以 ListReward 来评估,其定义如下:
表示用户会看到第 i 个视频的概率,用来作为折扣因子,引入后续视频的 reward。α,β是不同目标的权重,P 是候选集合的某个排列。
生成式重排的优点在于,每一步都能利用到前序已排序候选的所有信息,基于更完整的 context,来更新待排序候选的各项预估值,使得预估结果更准确,缺点在于计算量比较大,因此采用基于 beam search 的生成式重排来逐步生成推荐结果。在短视频场景中,用户每次只会看到 n 个视频,因此每次排序只需要确定 top-n 的顺序即可(沉浸式上下滑场景 n=1)。
在离线实验中,我们还观察到,beam search 每一步得到的 k 个序列,它们的 ListReward 的差别随着搜索步数增加会单调递减。利用这个特性,我们定义了 beam search 的稳定性,并提出自适应搜索步数的 beam search(图 4),可以将 beam search 的时间复杂度从 O(km^2) 进一步降低到 O(klm),其中 k 是 beam size,m 是候选视频数量,l 是实际的搜索步数,n≤l≪m。
▲
图4
. beam search 稳定性及 adaptive beam search 示例
实验
我们在业务数据集上对比了服务端精排模型预估分、简单的 DNN 模型、EdgeRec,结果如下:
将 SimpleDNN 和论文提出的模型做对比,可以看到直接加入服务端精排模型预估分作为特征效果并不好,甚至比精排分本身的 AUC 更低,说明这种缺少记忆性特征的小模型在不做相应特征处理的情况下,很难利用好精排分这类强个性化的特征。
▲ 表2. 消融实验效果对比
CSF:客户端特有的特征,如网速、视频预加载时长等,这类特征对用户是否会继续观看视频有很大影响。
RTS:用户实时反馈序列。点赞比有效播放和下滑操作更稀疏,用户实时反馈的影响也更小一些。
在线实验在快手 App 的线上环境进行,用到的模型大小在 6MB 以内,完全部署在客户端。
实验结果表明,基于单点贪心排序的端上重排相对于没有端上重排的基线,各个指标都有明显提升。context-aware 的生成式重排在此基础上又带来了进一步的指标提升。
实验期间也监控了基于 adaptive beam search 生成式端上重排带来的资源开销,表 4 是实验组中所有设备的资源开销均值,相对于没有端上重排模型的实验组,CPU 和内存的开销有轻微涨幅。通过对视频播放卡顿率等指标的监控表明,端上重排模型对用户体验不会造成影响。
▲ 图5. 线上效果随曝光位置的周期性变化
在实验过程中,还观察到了线上效果随曝光位置呈现周期性变化(图 5),我们分析主要有两个原因导致了这个现象:
1. 候选集合大小会周期性变化。当服务端的候选集合刚下发到客户端时,候选空间最大,随着视频逐渐曝光,候选数量慢慢变小,潜在的收益空间也逐渐收缩,直到客户端接收到下一次候选集合。
2. 服务端排序效果的周期性变化。服务端每次接收到客户端的请求时,可以利用最近的用户行为,推荐更好的内容,此时排序效果是最好的,随着用户在客户端持续观看视频,变化的上下文使得服务端的排序逐渐变得不够准确,这也存在周期性的变化。
▲ 图6. 反映用户实时反馈重要性的例子
图 6 中展示了一个线上的真实例子。用户在当前页中对两个亲子视频有明显的正反馈(点赞 + 收藏),但服务端无法实时获取到这些信号,此时候选中的另一个亲子视频,服务端预测的点赞率只有 0.049。而端上模型在引入用户实时反馈特征之后,关注到了用户在同类别视频上的反馈(attention 权重最高),对候选视频的点赞率预估值大幅提升到 0.592,并将其排在靠前的位置(受打散规则限制,没有紧接着之前的亲子视频曝光),最终用户也点赞并收藏了这个视频。这个例子证明用户实时反馈对感知其当前的兴趣至关重要。
端上重排系统大大提升推荐系统的实时性,带给用户更极致的推荐体验。论文在短视频场景通过一个超轻量级的端上重排模型实现了用户反馈的实时感知,提升了离线和在线的效果。另外介绍了端上部署推荐模型的很多实现细节和实践经验,希望能够推动端上智能在工业界和学术界的发展。后续会继续探索端上推荐系统的实时特征利用,端云联合优化等相关方向。
如何才能让更多的优质内容以更短路径到达读者群体,缩短读者寻找优质内容的成本呢?答案就是:你不认识的人。
总有一些你不认识的人,知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁,促使不同背景、不同方向的学者和学术灵感相互碰撞,迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人,在我们的平台上分享各类优质内容,可以是最新论文解读,也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个,让知识真正流动起来。
📝 稿件基本要求:
• 文章确系个人原创作品,未曾在公开渠道发表,如为其他平台已发表或待发表的文章,请明确标注
• 稿件建议以 markdown 格式撰写,文中配图以附件形式发送,要求图片清晰,无版权问题
• PaperWeekly 尊重原作者署名权,并将为每篇被采纳的原创首发稿件,提供业内具有竞争力稿酬,具体依据文章阅读量和文章质量阶梯制结算
📬 投稿通道:
• 投稿邮箱:hr@paperweekly.site
• 来稿请备注即时联系方式(微信),以便我们在稿件选用的第一时间联系作者
• 您也可以直接添加小编微信(pwbot02)快速投稿,备注:姓名-投稿
△长按添加PaperWeekly小编