源码

基于标签的实时短视频推荐系统

作者丨gongyouliu

1.1万字,阅读需70分钟

以下为正文:


作者在《基于内容的推荐算法》这篇文章中对基于内容的推荐算法做了比较详细的讲解,其中一类非常重要的内容推荐算法是基于标签的倒排索引算法,也是工业界用的比较多的算法,特别是新闻资讯类、短视频类产品大量采用该类算法。

 

在本篇文章中作者会结合电视猫的业务场景及工程实践经验来详细讲解基于标签的倒排索引算法的原理及工程落地方案细节。


希望读者读完本文,可以完整地了解基于标签的倒排索引算法的产品形态、算法原理、工程实现方案,并且能够基于本文的思路,具备从零开始搭建一套基于标签的算法体系的能力。

 

本文会从基于标签的推荐算法应用场景、基于标签的推荐算法原理介绍、整体架构及工程实现、召回与排序策略、冷启动策略、未来优化方向等6个方面来介绍基于标签的实时视频推荐系统。

 

如上篇文章《基于Erlang的相似视频推荐系统》所讲,电视猫有长视频和短视频各6大类,长视频对实时性要求相对没有那么高,所以本文主要以短视频的实时个性化推荐为例来讲解。



01

基于标签的推荐算法应用场景


在讲具体的算法原理及工程实践之前,我们先对基于标签的推荐算法可行的产品形态做简单介绍,让读者知道该类算法可以用到哪些业务场景中,从而有一个直观的印象,方便更好地理解后续讲解的内容。这些产品形态电视猫都落地到了真实业务场景中,下面的图例也是拿电视猫的产品形态来举例说明的。

 

《基于内容的推荐算法》这篇文章第三节我们简单描述了基于内容的推荐算法的应用场景,而基于标签的推荐是内容推荐的一种,应用场景也是类似的:完全个性化推荐、标的物关联标的物推荐(相似视频推荐)、主题推荐这3类应用场景都是可行的,我们下面对这3大业务场景简单一一说明。

 

1.1
完全个性化推荐

完全个性化推荐是为每个用户生成不一样的推荐结果,下图是电视猫小视频实时个性化推荐,基于用户的(标签)兴趣画像,为用户推荐跟用户兴趣偏好相似的视频,用户可以无限右滑(由于电视猫是客厅端的视频软件,靠遥控器交互,所以产品交互方式上跟头条等手机端的下拉交互是不一样的)获取自己感兴趣的推荐结果,整个算法会根据用户的兴趣变化实时为用户更新推荐结果。

 

       

图1:电视猫小视频实时个性化推荐

 

1.2
标的物关联标的物推荐(相似视频推荐)

短视频相似推荐基于视频标签构建视频之间的相似度,为每个视频推荐相似的视频。


下图是电视猫短视频的相似推荐,采用的产品形态是连播推荐的形式,当用户播放主视频后,相关联的相似视频会按照相似度列表连续播放,最大程度提升用户体验。

               图2:电视猫短视频信息流连播推荐

 

1.3
主题推荐

主题推荐根据用户播放行为历史,构建用户兴趣画像,这里是基于节目的标签来构建用户画像,基于用户画像标签为用户推荐最感兴趣的标签关联的节目。


下图是电视猫音乐频道的主题推荐,根据作者最近看过的音乐视频,为作者推荐了“国语”和“器乐教学”两个主题相关的音乐短视频。

              图3:电视猫音乐频道主题推荐

 

讲解完了基于标签的推荐产品形态,相信读者对基于标签的推荐有了较直观的认知,那么我们在实际业务中怎么实现这些产品形态呢?怎么构建合适的基于标签的推荐算法呢?在下节我们会详细讲解算法基本原理。



02

基于标签的推荐算法原理介绍



我们在《基于内容的推荐算法》中对基于标签的个性化推荐算法原理已经做过初略介绍,读过该文章的读者应该有印象,不熟悉也没关系,本节我们会对上节提到的三个产品形态:个性化推荐、相似视频推荐、主题推荐的算法实现原理做细致的介绍,方便读者深入理解算法的实现细节。

 

2.1
个性化推荐(完全个性化范式)

基于标签的个性化推荐算法具体推荐过程见下面图4:从用户画像中获取用户的兴趣标签,基于用户的兴趣标签从标签->节目倒排索引表中获取该标签对应的节目,这样就可以从用户关联到节目了。其中用户的每个兴趣标签及标签关联到的节目都是有权重的。

              

图4:基于倒排索引的视频推荐

假设用户的兴趣标签及对应的标签权重如下,其中  是标签, 是用户对标签的偏好权重。


   


假设标签  关联的视频分别为:


        

......


       

其中 分别是标的物及对应的权重,那么

              

上式中U是用户对视频的偏好集合,我们这里将视频   看成向量空间的基,所以有上面的公式。不同的标签可以关联到相同的视频(因为不同的视频可以有相同的标签),上式中最后一个等号右边需要合并同类项,将相同基前面的系数相加。合并同类项后,视频(基)前面的数值就是用户对该视频的偏好程度了,我们对这些偏好程度降序排列,就可以为用户做topN推荐了。

 

上面只是基于用户兴趣画像来为用户做推荐的算法原理,实际业务中,用户的兴趣有长期兴趣、短期兴趣,同时还需要考虑给用户提供多样性的推荐及根据用户播放过程中的实时反馈调整推荐结果,所以实际工程上会非常复杂,这一块我们会在第三节的架构及工程实现、第四节的召回和排序中详细说明。

 

2.2
视频相似推荐(标的物关联标的物范式)

在本节我们先来讲解怎么利用视频的标签来计算两个视频之间的相似度,有了视频之间的相似度就很容易做视频的相似推荐了。

 

假设视频集合是 ,其中 是对应的视频。假设所有视频标签集合是  ,其中是对应的标签。一般n和m都是非常大的数,从几十万到上百万,甚至更大。每个视频只有很少的标签,所以将视频表示成标签的向量的话,一定是稀疏向量,我们可以采用视频的标签向量表示的余弦相似度来计算两个视频之间的相似度,具体计算过程如下:


假设两个视频  的向量表示如下(我们按照中标签的顺序来编码向量),  是对应的权重,如果采用one-hot编码, =0 或者  =1,如果标签是有权重的, 就是对应标签的权重。

     

     

我们可以采用如下cosine余弦相似度公式来计算 之间的相似度:

       

我们可以计算出 与所有其他视频(除去 自身)的相似度:

  

那么  的相似推荐就可以利用上述列表降序排列后取topN作为最终推荐列表。

 

2.3
主题推荐

有了1中介绍个性化推荐的算法原理,就很容易说明怎么做主题推荐了。


首先我们根据用户画像获取用户的几个最感兴趣的标签,每个兴趣标签就是一个主题,将每个兴趣标签关联的节目推荐给用户就可以了,下面简要说明一下。

 

假设用户的兴趣标签及对应的标签权重如下,其中 是标签,是用户对标签的偏好权重。

             


我们可以将上述集合按照权重降序排序,选择k个权重最大(用户最喜欢)的标签         作为待推荐的主题。再从每个标签关联的节目(在实际工程实现上,我们会事先构建标签->节目的倒排索引表,方便从标签关联到节目)中选择对应的节目推荐给用户。

 

上面我们简要讲解了三类基于标签的推荐算法的算法原理,下面我们会结合电视猫的实践经验来讲解这三类推荐产品在工程上是怎么实现的。



03

整体架构及工程实现



本节我们来详细讲解上述三类算法的整体架构、核心功能模块及工程实现。


这里我们重点只讲解个性化推荐和相似视频推荐两种推荐产品的架构和实现,主题推荐跟个性化推荐非常相似,我们会简单说明一下。

 

电视猫基于标签的个性化短视频推荐是基于Spark平台来实现的,其中流式处理采用Spark Streaming组件,离线处理采用Spark,整个代码工程整合到了Doraemon框架(不了解的读者可以参考《推荐系统的工程实现》这篇文章)中。下面架构图的每一个处理逻辑都抽象为一个算子,封装在Doraemon框架中,便于业务的复用、拓展和工程维护。

 

为了让各个模块之间解耦,我们大量采用消息队列(RabbitMQ和Kafka)来传输消息(数据),让整个推荐系统更加模块化、结构化。只要定义好两个模块(算子)之间的(数据)协交互议,就可以独立对各个子模块进行优化升级而不会互相影响。

 

节目倒排索引及用户画像是存储在HBase集群中,方便算法分布式读取,HBase的数据结构如下图,不熟悉的读者可以网上搜索了解一下。最终的推荐结果存储在CouchBase及Redis中,个性化推荐、主题推荐这类为每个用户都生成一个推荐结果的产品形态,数据量会更大,推荐结果存储在CouchBase(一个分布式文档数据库,可以方便横向扩容)中,而相似视频数据量相对较小存储在Redis这类key-value内存数据库中。

 

              图5:HBase数据结构

 

有了上面的背景知识,现在我们正式来介绍各类算法的工程实现。

 

3.1
个性化推荐

个性化推荐分为离线模块和实时模块两部分,离线部分每天更新一次,为全量用户生成推荐结果,而实时部分基于用户实时的行为实时更新推荐列表。离线推荐和实时推荐相互配合,”交替进行“(严格不是交替进行,在离线任务运行过程中,只要有用户在用产品,实时推荐也是在运行的,只不过离线一般在凌晨跑,跑的时间也不会很长,这时用户比较少,其他时间都是实时推荐在起作用,所以简述为交替进行),为用户提供全天候的推荐服务(见下面图6)。

              图6:离线推荐&实时推荐”交替“,离线每天更新一次,两次离线推荐之间采用实时推荐

 

下图是基于标签的个性化推荐的整体架构,分两条线,一条线从媒资系统生成节目标签的倒排索引,另一条线从用户行为日志生成基于标签的用户兴趣画像,最终倒排索引和用户画像供推荐程序(算子5)使用,为用户生成推荐。这里为了简单起见,我们只考虑基于用户画像来为用户做推荐,不考虑其他的各种召回策略,更多的召回策略放到第四节来讲解。

 

              图7:基于标签的个性化推荐整体架构

 

整个算法实现主要包括大5核心模块(对应上图中标注1、2、3、4、5的5个算子),每个算子是作为一个独立程序运行的,互不影响,其中算子5是最核心的推荐模块。我们来分别描述一下各个模块的核心功能及工程实现。


(1) 新增节目及标签注入


媒资系统是视频行业的内容管理系统,负责所有内容的管理、运营、输出。推荐系统依赖媒资系统的内容来源。基于标签的视频推荐系统从消息队列中获取新增/修改的节目及标签信息,利用这些消息来构建标签<->节目倒排索引表。该模块将推荐需要依赖的信息通过消息的方式发送到消息队列的固定topic中,后续模块通过监听该topic来获取新的消息做进一步处理。

 

下面图7给出了信息的一个简化版本,消息通过json的方式来组织,包括type(是新入库的节目还是对老节目标签的更新)、sid(节目唯一标识)、title(节目标题)、tags(标签)。

 

              

图8:信息队列中消息的结构

 

标签也是有唯一识别的,即是上图中的tid,类似视频的sid,在构建倒排索引及用户画像过程中通过使用标签的tid可以简化比较及处理逻辑,减少存储空间。

 

标签也是有权重或者层级结构的,电视猫的标签就有分类标签->栏目标签->内容标签三级体系,从粗到细,这个层级结构跟行业有很大关系,不同行业有不同的分级策略和方法。标签也是有权重的,权重衡量标签对节目的重要程度。在实际做算法时可以整合这些信息,让算法更加精准。本文为了简化起见,不考虑分级的标签,只考虑平展化的一级标签。

 

通过消息队列来获取消息的好处有两点:首先,可以将媒资系统跟推荐系统解耦(一般是两个不同的团队来负责),方便两边系统独立扩展和升级,只要保持消息格式不变,不影响两边业务。其次,通过消息队列来传输信息,可以让系统做到更加实时。

 

在我们的项目中(1)对接的消息队列采用RabbitMQ,这一模块可以由媒资团队来提供基础服务,由媒资团队来维护,算法团队可以给媒资团队提需求,按照推荐算法需要的字段及规范提供数据即可。


(2) 生成标签节目倒排索引


该步骤(近)实时从消息队列中获取节目的标签信息,为每个节目构建标签<->节目的倒排索引,方便从节目关联到标签及从标签关联到节目。我们采用Spark Streaming流式处理组件来构建倒排

(0)

本文由 投稿者 创作,文章地址:https://blog.isoyu.com/archives/jiyubiaoqiandeshishiduanshipintuijianxitong.html
采用知识共享署名4.0 国际许可协议进行许可。除注明转载/出处外,均为本站原创或翻译,转载前请务必署名。最后编辑时间为:7月 24, 2019 at 08:42 下午

热评文章

发表评论

[必填]

看不清?

提交后请等待三秒以免造成未提交成功和重复