OceaBase开发者大会落地上海!4月20日共同探索数据库前沿趋势!报名戳 了解详情
写点什么

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

  • 2020-03-28
  • 本文字数:5001 字

    阅读完需:约 16 分钟

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

推荐系统介绍

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


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


公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2020-03-28 10:003342

评论

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

揭秘在召唤师峡谷中移动路径选择逻辑?

华为云开发者联盟

算法 地图 最短路径

《Python:Python编程简介:计算机编程和机器学习入门指南》

计算机与AI

Python

爆料!前华为微服务专家纯手打500页落地架构实战笔记,已开源

996小迁

架构 面试 分布式 微服务 程序人生

CDN是什么?

德胜网络-阳

数字货币OTC交易所开发,交易所搭建方案

13530558032

一款区块链钱包开发需要多少钱?数字资产钱包开发搭建

13530558032

如何实现后台管理系统的权限路由和权限菜单

徐小夕

Java 大前端 编辑器 H5 数据可视化

【涂鸦物联网足迹】涂鸦云平台接口说明

IoT云工坊

人工智能 物联网 API sdk 云平台

又一道比较运算符相关的面试题让我明白基础很重要

Gopher指北

Go 语言

终于啃完了Java核心原理+框架“面试圣经”成功五面上岸美团

小Q

Java 学习 编程 架构 面试

医疗界“最强大脑”落户杭州!阿里巴巴联合浙大一院共同打造

互联网

如何稳扎稳打推进数字货币进程

CECBC

数字货币

USDT承兑支付平台技术开发,承兑商币支付交易平台搭建

13530558032

架构训练营 - 第7周课后作业 - 学习总结

Pudding

架构师训练营第一期 - week8

习习

做个别人家的网页

MySQL从删库到跑路

html/css 网页设计

从智慧计算的点、线、面,读懂浪潮AI的进化轨迹

脑极体

Apache DolphinScheduler 是如何走进Apache的

代立冬

大数据 数据湖调度 DolphinScheduler Apache DolphinScheduler

帮助企业摆脱困境,名企归乡工程师:能成功全靠有它!

Philips

敏捷开发

【运维思考】如何做好云上运维服务?

嘉为蓝鲸

云计算 运维 数字化转型 数据中心 云服务

浅谈API网关(API Gateway)如何承载API经济生态链

华为云开发者联盟

API 网关

百亿级数据分表后怎么分页查询?

艾小仙

Java MySQL 数据库 编程语言 分库分表

价值超10亿美元的直播系统架构图是什么样子的?

冰河

系统架构 高并发 高性能 亿级流量 直播架构

魏际刚:精准谋划我国供应链发展新方位

CECBC

供应链 物流

金融科技的未来

CECBC

金融

从一场“众盟科技云滇之播”,我们发现了美食直播的商业与公益价值

脑极体

害怕重构?都怪我太晚和你介绍该如何重构,现在我来了

小Q

Java 学习 程序员 面试 重构

谈谈敏捷开发概念和迭代开发方案

Learun

敏捷开发

LeetCode题解:77. 组合,递归回溯,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

架构师训练营 - 第 7 周课后作业(1 期)

Pudding

架构师训练营第 1 期第 7 周总结

owl

极客大学架构师训练营

智能推荐算法在花椒直播中的应用_移动_DataFunTalk_InfoQ精选文章