写点什么

智能推荐算法在花椒直播中的应用

2020 年 3 月 28 日

智能推荐算法在花椒直播中的应用

推荐系统介绍

首先和大家介绍一些推荐系统的基本知识。


1. 推荐系统是什么


现代移动互联网娱乐充斥着各种各样的信息,如新闻,短视频,直播等等,经常使用户迷失在海量的内容中,而无法找到真正感兴趣的内容。平台搭建推荐系统则是帮助用户发现内容,克服信息过载的重要工具。它通过分析用户行为,对用户兴趣建模。通俗来讲就是通过用户过去的喜好来分析现在的喜好,从而预测用户的兴趣并给用户做推荐。


早期的花椒推荐系统是基于热度推荐的,即根据观看人数、送礼人数、互动人数等因素来进行加权得到相应的分数代表热度,然后根据热度进行推荐。这样做的好处是热度高的直播质量有保证。但是坏处也很明显,流量全部集中在头部主播,小主播难以得到有效曝光,这样对于平台的利益也是一种损害。对于用户来说,也难以做到“千人千面”的个性化推荐效果。


因此现代的推荐系统应运而生,一般分为以下几个阶段:



首先从百万级别的内容中,根据历史行为,运用协同过滤等算法召回千百级别的内容, 再经过 feature-based 精排模型排序,选取百十级别内容推荐给客户。召回阶段会用些成本低、易实现、速度快的模型 ( 如协同过滤 ) 进行初步筛选。排序阶段则用更全面的数据、更精细的特征、更复杂的模型进行精挑细选。


2. 召回算法介绍


① 基于领域的协同过滤


以电影推荐为例,我们知道用户对于历史观看过的电影的评分,将原始数据格式转化为评分矩阵,如下所示:



用户只看过少部分电影,我们想要知道对于未看过的电影,用户可能对其的喜爱程度 ( 打分 ) 是多高。建模的过程就是填充空白项的过程,这样就得到了所有用户对所有电影的评分 ( 喜好程度 ),然后就可据此进行个性化推荐。


这种协同过滤方法基于场景一般采用 user-based 或者 item-based model。花椒直播用的是 item ( 主播 ) based model,即基于主播的协同过滤算法。主要基于以下原因:


  1. 主播数量远小于用户数量,相似度矩阵维度小,计算少、易存储 (𝑂(𝑛2))

  2. 根据用户的历史行为推荐,可以让用户比较信服 ( 可解释性强 )

  3. 新用户只要看过一个主播,就可以很快得到其他相似主播的推荐。计算方法如下所示:



但是这种方法存在一些缺点:


  1. 这是一种基于统计的方法,不是优化学习的方法,没有学习过程和设立指标进行优化得到最优模型的过程

  2. 没有用到全局数据,只用了局部数据计算相似度、进行推荐

  3. 当用户或物品维度很大时,会占用很大的内存


基于这些原因,后面出现了基于隐向量的协同过滤方法进行推荐。


② 基于隐向量的协同过滤


隐向量的生成方式一般分为两类:


  1. 基于矩阵分解生成隐向量。

  2. 基于深度学习生成隐向量。


和基于邻域的方法一样,基于矩阵分解方法建模的目的也是补全缺失值。在介绍矩阵分解之前,我们先来看看推荐系统的两种反馈方式:



显式反馈一般采用评分矩阵来提取隐向量, 方法如下所示:



这种方法就是标准的 MF,通过评分矩阵分解出代表用户的隐向量矩阵和代表物品的隐向量矩阵。但是缺点也很明显,在实际的应用场景中, 不可能用户每使用一次物品就要求用户打分。所以在实际场景中,隐式反馈使用的更多,在直播场景里,用户对于视频的喜好表现为观看时长和点击次数等等。


以观看时长作为用户对于商品的偏好为例,在观看时长大于某个程度作为喜好的标准,设定评分为 1,否则为 0。同时设置偏好的可信度作为损失函数的权重,理解为偏好越大,权重越大。则隐向量计算方法如下所示:



线上的部署很简单,X 中每行为一个用户的隐向量,Y 中每列为一个物品的隐向量。离线训练好将 X,Y 两个矩阵存起来,线上用时直接取对应向量做内积即可得到任一用户对任一物品的得分 ( 即喜好程度 )。


矩阵分解的思想很简单,优点也很明显:


  1. 模型简单易实现。

  2. 线上速度快:可以离线训练,线上只需要做点积。

  3. 存储少 ( 高维评分矩阵映射为两个低维隐向量矩阵 )。同样的,传统的矩阵分解也存在着可解释性较差,未用到其他特征,综合性较差的缺点。


总结一下基于领域的协同过滤和基于矩阵分解的协同过滤的异同点:



有些示例表明,学到用户/物品的隐向量后,直接用内积描述用户-物品交互关系 ( matching function ) 有一定的局限性,即内积函数 ( inner product function ) 限制了 MF 的表现力。


随着深度学习的兴起,有学者提出了新的模型:即借鉴深度学习中的方 法,使用深度神经网络 ( DNN ) 从数据中自动学习用户/物品隐向量的交互函数,在增强表现力的同时也可以引入一定的泛化能力。


以 NCF 为例,通过对 user_id 和 item_id 的 one-hot 编码,经过嵌入形成隐向量,用 DNN 取代内积,输出目标预测值,通过损失函数求梯度进行反向传播训练模型。如下图所示:



NeuMF 则提出了 GMF 层来提取用户、物品潜在特征之间的相互作用 ( MF 的特性 ),同时采用了 MLP 进行非线性的特征融合,具体如下所示:



但是仅仅运用到 id 类特征并没有充分使用用户和物品的属性特征,因此随时技术进步,越来越多平台开始把属性特这个加入到深度学习中来提取隐向量。以下是 youtube 的召回模型结构:



随着业界对于深度学习的不断探索,目前召回模型也越来越复杂和精妙, 如:


双塔模型 ( Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations )


知识图谱模型 ( RippleNet: Propagating User Preferences on the Knowledge Graph for Recommender Systems )


图神经网络等 ( GraphSAGE: Inductive Representation Learning on Large Graphs )。


3. 精排 ( Ranking ) 算法介绍


① 特征工程


特征的选择和建造对于模型的效果起着至关重要的作用,在直播领域,考虑的特征一般包括如下几个方面:



在训练数据的生成上,我们根据当天的用户与主播的交互程度形成征服样本,根据之前的历史数据组成用户画像和行为特征。在生成数据的时候,要注意不能有数据穿透,基本流程如下图所示:



选择 14 日组成整体训练集,这样既可以保证数据量的要求,又可以保证用户和主播覆盖度的要求。


② 排序模型


早期的排序模型采用的是传统的机器学习模型,如 LR/FM/GBDT+LR。


LR 一般代指逻辑回归模型,是广义线性模型,一般用于解决二分类问题,模型如下:



优点就是模型简单,训练速度快,消耗资源少。缺点也很明显,缺少非线性的特征交叉,泛化性较低。


为了将特征交叉考虑进去,FM 模型被广泛使用,模型如下:



FM 模型在 LR 模型的基础上增加了自动二阶特征交叉的部分。不同于 CF 类模型,只有用户、物品 ID 两类特征 ( 即 MF ),FM 可以添加任意多的特征。隐向量的引入也使得模型可以泛化到未曾出现过的特征组合中,兼顾了模型的记忆性和泛化性。但是 FM 只能学习二阶交叉项,遇到高阶交叉项,则会出现纬度爆炸的情况。


因此为了寻找不同特征之间的组合,人们选择了用 GBDT 进行特征组合,自上而下每条路径代表一种高阶特征交叉,然后叶子节点编号作为 LR 的输入,具体结构如下所示:



但是这种方法的缺点是可能导致过拟合高维稀疏数据,GBDT 不能将数据 batch 输入,无法并行,因此速度慢、泛化性差。


随着深度学习的深入,人们将高阶特征交叉的工作中心转移到了 DNN 网络。首先最直观的改进就是通过 DNN 处理特征交叉,LR 处理线性部分。



大名鼎鼎的 W&D 就是由此而来,其结构如下:



这种深浅双塔结构的提出极大的促进了后续模型的发展。如后续的 DeepFM 就是将 FM 与 DNN 结合起来,更加提高了交叉特征的提取能力。



又如较新的 DIN 模型,引入了 attention 的机制,通过 attention network 来组合 embeddings,而不是类似之前的 concatenate 的方式。



4. 多目标优化


推荐系统的多目标优化,是目前业界的主流之一,也是很多公司的研发现状。以我 们花椒直播为例,可以优化的目标有点击、观看、送礼、评论、关注、转发等等。


多任务模型旨在平衡不同目标的相互影响,尽量能够做到所有指标同步上涨,即使 不能,也要尽量做到在某个优化目标上涨的情况下,不拉低或者将尽量少拉低其它 指标,力求达到全局最优的效果。


传统的 CVR 任务,只考虑从 impression 到 conversion 的过程,即:



阿里的 ESMM 模型还考虑了点击的过程,并引入了浏览转化率 ( pCTCVR ) 的概念,即为在浏览的条件下既点击又转化的概率,即:



不同于 CTR 预估问题,CVR 预估面临两个关键问题:


问题 1. Sample Selection Bias ( SSB ) 转化是在点击之后才“有可能”发生的动作,传统 CVR 模型通常以点击数据为训练集,其中点击未转化为负例,点击并转化为正例。但是训练好的模型实际使用时,则是对整个空间的样本进行预估,而非只对点击样本进行预估。即是说,训练数据与实际要预测的数据来自不同分布,这个偏差对模型的泛化能力构成了很大挑战。


问题 2. Data Sparsity ( DS ) 作为 CVR 训练数据的点击样本远小于 CTR 预估训练使用的曝光样本。


模型结构如下:



仔细观察上图,留意以下几点:


  1. 共享 Embedding CVR-task 和 CTR-task 使用相同的特征和特征 embedding,即两者从 Concatenate 之后才学习各自部分独享的参数;

  2. 隐式学习 pCVR 啥意思呢?这里 pCVR ( 粉色节点 ) 仅是网络中的一个 variable,没有显示的监督信号。


更进一步,MMoE 模型为我们提供了多任务模型更加直接的思路,关于共享隐层方面,MMoE 和一般多任务学习模型的区别:


一般多任务学习模型:接近输入层的隐层作为一个整体被共享


MMoE:将共享的底层表示层分为多个 expert,同时设置了 gate,使得不同的任务可以多样化的使用共享层。如图:


a. 是最原始的多任务学习模型,也就是 base


b. 是加入单门 ( one gate ) 的 MoE layer 的多任务学习模型


c. 是文章提出的模型。可以看出,c 本质上是将 base 的 shared bottom 换成了 MoE layer,并对每个任务都加 gate



智能推荐遇上花椒直播

直播中的推荐和商品推荐等场景有所不同,是“活的”而不是“死的”,因为直播是长时间连续性的,并 且内容是实时在变的,比如用户喜欢看跳舞直播,那么当主播不跳的时候用户可能也不想看了。因此 我们需要把直播最核心、最精彩的部分挖掘出来推荐给用户。


这就需要对多模态内容进行理解、融合,包括但不限于:


  • 文本:如直播间标题、弹幕等

  • 图片:如主播头像、封面等

  • 视频:如可以识别主播是否在跳舞、游戏、挂机等

  • 音频:如可以识别主播是否在唱歌,在唱什么类型的歌等


除了上面所说需要对直播的多模态内容进行理解,一些实时的数据也是非常重要的,它们一定程度 上可以反映当前直播的火热程度和受欢迎程度,放到模型中作为特征可以加强推荐系统的准确性和实时性。包括但不限于:实时看播人数、打赏人数/金额、弹幕数、点赞数、分享数、新增粉丝 数、是否正在唱歌/跳舞/连麦 PK、是否正在挂机、游戏精彩瞬间 ( 如吃鸡剩余人数、王者荣耀 KDA ) 等。


花椒直播模型的结构十分明确,原始数据包括用户特征,上下文特征,过去历史特征,当前需要预测的物品特征等。对于特征进行嵌入操作,在特征交互层可以使用上文提到的很多结构,如 W&D,FM,attention。随后加入 DNN 结构进行特征融合,最后输出多目标预测结果。等结构如下:



模型训练和更新的逻辑如下,将模型数据整理好,全量样本存入 HDFS 中,以周或者天为单位进行模型更新,增量样本 flink 流处理,进行离线训练和更新,以满足实时性的要求。模型验证通过线下指标对模型进行监控,训练好之后采用 tensorflow serving 这种框架提供服务。推荐引擎使用 golang 来处理用户请求,以及将请求转化为特征传入 tensorflow serving 中。



总结

本次分享总结了花椒直播沿着业内的发展路线从 0 到 1 搭建个性化推荐系统的过程,先后尝试了许多模 型,每个模型除了其典型的结构外,还有许多非常珍贵的细节,比如公式推导,参数的选择,工程上的 trick 等等,这些大家可以查阅相关模型论文。


要注意的是,没有“最好的模型”,只有“最适合的模型”,并不是说模型越 fancy 越复杂,线上效果就会越好。比如阿里提出了 DIN 模型,是因为工程师们首先发现了数据中“多峰分布”、“部分激活”的现象,而在直播场景中这个特点就不是很明显,因此上线了 DIN 模型后的提升也不是很大。


但直播场景也有其自身的特点,如多模态、实时性和热点效应等。只有深入理解了场景,并基于用户行为和数据提取出能表现这个场景的特征,再对应地开发适用于这个场景的模型,才能取得最佳的效果。


本次分享就到这里,谢谢大家。


本文来自 DataFunTalk


原文链接


https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247498637&idx=1&sn=a91d76109129fa42e5910c2e2b5f68ef&chksm=fbd749e1cca0c0f75c8a9dc06c16b8d9a53cdf57eb370c07424d88eefd1ddb66928dd1bf2f7f&scene=27#wechat_redirect


2020 年 3 月 28 日 10:001864

评论

发布
暂无评论
发现更多内容

写作的几点建议:面对卡文,写别人的题目,栩栩如生的写作

七镜花园-董一凡

写作

架构师训练营-作业-1】食堂就餐卡系统设计

superman

学习 极客大学架构师训练营

4天如何完爆Kafka源码核心流程!

奈学教育

kafka

架构师训练营第01周——总结

李伟

极客大学架构师训练营

被迫重构代码,这次我干掉了 if-else

程序员内点事

如何成为一个架构师?

逍遥乐天

极客大学架构师训练营

架构师训练营第 1 周 _ 食堂就餐卡系统设计

方舟勇士

课程练习

4天如何完爆Kafka源码核心流程!

古月木易

kafka

UML 体验(就餐卡系统设计)

陈皮

第一周作业

东哥

极客大学架构师训练营

一味的坚持,或许只是徒劳

这小胖猫

逻辑思维 职业成长 工作体会

架构设计文档

talen

While语句

拾贝

作业1

annie

极客大学架构师训练营

架构师入门之架构方法

知识乞丐

极客大学架构师训练营

架构师训练营第一周总结

皓首不倦

第一周学习总结

小海豚

学习

第一周命题作业

AspYc

食堂就餐卡系统设计

架构设计 极客大学架构师训练营

极客时间架构课Week01-作业二:学习总结

yulyulcl

你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了

小林coding

TCP 计算机网络 网络协议

【总结】第一周架构师如何做架构

chengjing

第一周作业

Geek_2b3614

架构师训练营 - 第一周学习总结

牛牛

学习 极客大学架构师训练营

架构师训练营第一周作业 - 食堂就餐卡系统设计

阿德

第一周作业:食堂就餐卡系统设计

晓雷

第一周学习总结

AspYc

食堂就餐卡系统架构设计文档

小叶

架构设计

一周信创舆情观察(6.1~6.7)

统小信uos

大数据 网络安全 新基建

食堂就餐卡系统设计

小海豚

学习 食堂就餐卡系统设计

架构师是什么?

芥末

极客大学架构师训练营

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

智能推荐算法在花椒直播中的应用-InfoQ