这是作者的第36篇原创文章,约1.1w字,阅读约60min
随着移动互联网的深入发展,硬件成本的降低,智能手机成为每个人的标配。手机最初主要用于沟通交流,但随着科技的进步和应用场景的拓展,手机的通信功能弱化了,人们利用手机更多地用于获取信息。不管是看视频、刷抖音、看新闻,还是社交、购物、投资,都可以看成是信息获取的过程(至少信息获取是其中最重要的一个环节之一)。在当前信息爆炸的时代,获取有价值的信息不是一件容易的事情,但我们可以借助机器学习算法来更好地帮助用户获取有价值的信息。
用户在互联网产品上获取信息主要有3种方式:一种是用户需求比较明确,用户知道自己需要什么,这时一般会通过搜索来获取信息;第二种方式是用户需求不是特别明确,这时可以借助个性化推荐技术来帮助用户更便捷地获取信息,个性化推荐基于用户历史行为,构建数学模型,猜测用户兴趣偏好,为用户提供个性化的信息推荐;第三种方式是用户通过产品提供的筛选、列表等模块自己逐个找寻、检索自己需要的信息。第一、第二种方式都是通过算法(搜索算法、推荐算法)来帮助用户更简洁、方便、快速地获得更加精准的信息。其实第三种方式也是可以借助算法来帮助用户更快、更精准地找到自己喜欢的信息的,这就是本文要讲的列表页智能重排序算法。
具体来说,本文会从什么是列表页智能重排序、智能重排序的应用场景、智能重排序的价值、智能重排序的实现方案与算法原理、智能重排序的难点与挑战、智能重排序在电视猫上的应用等6个维度来讲解智能重排序相关的知识点。期望读者可以掌握智能重排序的基本概念、核心思想、实现原理与业务价值,并思考在自己的产品中是否可以采用本文的思路去优化、提升用户体验与商业价值。
在很多互联网产品中,存在很多以某个主题组织的内容池,该主题下的标的物一般以某种方式排列(典型的比如按照标的物入库的先后顺序降序排列,新入库的标的物放在最前面),用户想要在该主题下找到某个自己喜欢的标的物,需要逐个浏览。下图就是电视猫电视剧频道里面各个主题(比如战争风云)的UI呈现方式,当焦点聚焦在某个主题上时,右边会展示出所有与该主题相关的视频。
图1:电视猫APP电视剧频道中的各种电视剧主题
根据上面的介绍,这类内容展现形式是将某个主题下的所有标的物按照某种规则进行更新和排序。有可能前面的标的物用户已经操作过(看过、浏览过、购买过、甚至忽略过等),当用户第二次再浏览该页面时,如果用户操作过的或者不喜欢的标的物还展示给用户时,对用户体验不是很好。那么是否有办法解决这个问题呢?答案是肯定的,这就是利用智能重排序技术对展示的标的物列表进行智能排序。
所谓智能重排序,就是在产品(即APP)的任何一个包含大量标的物的列表页或者类目结构中,通过机器学习算法来学习用户对标的物的偏好程度,对列表页/类目结构中的标的物进行智能重排,保证用户喜欢的标的物排在前面,提升列表页的用户体验和点击转化。该解决方案可以做到千人前面的智能重排,每个用户的排序都是不一样的,都是适配用户兴趣的,真正做到个性化、智能化。这里要说明两点,一是智能重排序后这个列表或者类目结构中包含的标的物数量是不变的,只不过排序方式是根据算法来计算出来的,用户喜欢的会排在前面。二是,这个排序是个性化的,可以做到每个人的排序方式不一样。举个例子,在电视猫APP电视剧频道首页的战争风云这个主题中(见上面图1),如果利用算法给每个用户生成个性化的排序,那么这就是列表页智能重排序。
智能重排序与推荐系统是有非常紧密的内在联系的。首先,我们可以将智能重排序看成是对已经召回的内容(即需要智能重排的标的物列表)的排序,从这个角度看,智能重排序就等价于推荐系统的排序模块。其次,我们可以将智能重排序看成限定范围的推荐,我们将推荐内容限定在需要排序的列表中的标的物上,需要通过排序将列表中的标的物推荐给用户,并且是全部推荐给用户。不管是上面哪一个角度看智能重排序,它都可以看成是推荐系统的一种特例。
通过上面的介绍,相信读者已经理解了什么是智能重排序,下面我们来说说智能重排序的应用场景。
根据上面一节中的讲解,只要是在产品中存在按照某个主题或者某个类目结构来对标的物进行组织的产品架构,都可以借助智能重排序技术来对标的物列表进行智能排序。一般来说,智能重排序主要的应用场景包含如下这3大类场景:
1. 视频网站按照某种主题展示的视频列表
像爱奇艺等视频网站,存在很多根据某个标签(一个标签也算一个主题)组织的内容结构,这里当然可以利用智能重排技术对展示出的视频进行个性化排序。下图就是节目的筛选界面,筛选是满足多个标签的内容的过滤操作,将所有的包含这几个筛选标签的内容展示出来,这本身也是一种内容的列表。电视猫也属于视频类APP,只不过只在智能电视上播放,也属于这一类。
图2:爱奇艺APP中当用户进行筛选时,视频就展现为列表的形式,可以利用重排序技术重排
2. 电商网站按照类目组织的内容列表
像电商网站,一般按照多级类目结构来组织商品,每个类目下有大量的商品,这些商品构成一个商品的列表,因此可以用智能排序技术来对物品进行个性化重排并展示出来。下面图3就是京东男装类目下的子类目,每个子类目点击进去就是各种衣服或裤子列表,这些列表可以用智能重排技术来优化排序逻辑,提升用户体验与点击转化率。
图3:京东APP男装主题下,有很多子类目,每个子类目点进去就是这个子类目相关的商品列表
3. 生活服务类APP按照服务类型组织的服务列表
生活服务类APP中包含多个品类的服务类型,其中很多服务类型是包含子服务类别的,进入这些子服务类别就展示该类别下的所有服务,这些服务也构成一个服务列表。因此,是可以用个性化排序策略进行优化的。下面图4是美团APP休闲/玩乐服务门类下的众多子服务类型,进入某个子服务(如按摩/足疗)就展示出由该子服务类目下的所有服务构成的列表。
图4:美团APP中休闲/玩乐品类下的各种子类目下的各种服务组成服务列表
当然,可以做智能重排序的APP类别远不止上面这3大类。只要满足按照某个类别、某个主题、每个类目等来对标的物进行组织的产品形态和产品架构,都可以利用个性化重排序来优化排序逻辑,提升用户体验和标的物CTR点击概率。可以说,基本所有的toC类APP都存在可以进行智能重排序的场景,因而,智能重排序的应用场景是普适而广泛的。
这里需要提一下,不是只要有标的物列表出现的场景就一定有必要做智能重排序,做智能排序是有一定条件的。必须当该列表包含的标的物数量非常多、有很多页时做智能重排才有价值。否则,如果某个列表只包含很少量的标的物,那么用户只要花很少的时间就可以浏览完整个列表,进而就知道该列表中的哪些标的物是自己感兴趣的了,这时智能重排序就失去了意义、得不偿失。
通过前面两节的讲解,我们知道了什么是智能重排序以及它的应用场景。智能重排序不光有这么多的应用场景,它也是非常有价值的,它的价值主要体现在如下3个方面:
1. 提升用户体验
在不进行智能重排序时,标的物列表是按照某种规则(比如时间倒序)进行自然排序的,在该规则下,排序逻辑是固定的,用户什么时候进入该列表排序基本都是一样的(除了新上线或者下线的标的物外,其它标的物都是不变的),可能列表前面的标的物用户已经浏览过了,用户第二次进入时如果排序不变,是非常影响用户体验的。而当采用智能重排序策略时,每天(甚至可以每小时或者更短的时间间隔,当然需要根据具体的产品形态和场景确定是否有必要做到那么频繁更新,一般的原则是如果这个场景用户频繁进入,可以更新更频繁一些,否则做到T+1更新就足够了)可以重新排列标的物的顺序,将用户感兴趣的但用户没有浏览过的排在前面,这样用户每天看到的标的物就不一样,明显可以提升用户体验。
2. 提升长尾标的物的分发效率
智能重排序可以做到千人千面,每个用户的排序都不一样,相比没有智能排序前的千篇一律,智能重排序后显然可以让更多的标的物得到曝光的机会。由于智能重排序是根据用户的兴趣进行重排,而用户的兴趣是多样的,这样可以让更多的长尾标的物分发给对它感兴趣的用户,提升了标的物的分发效率。
3. 提升标的物的点击转化
由于智能重排是根据每个用户对标的物的兴趣大小,将用户没有操作过的、用户感兴趣的标的物排在前面,显然可以提升标的物的点击率与转化率。
上面3节讲完了智能重排序的基础知识,我们在本节来讲解智能重排序的工程实现方案及算法原理,本节是智能重排序最重要的知识点,读者需要深刻理解相关的方案与原理。智能重排序的工程实现方案有很多种,其中下面的方案1、2、3都是可行的,我们下面分别讲解,除了讲解这3种方案外,我们在4中会比较前2个方案的优劣,并且在5中简单介绍一下智能重排序的冷启动方案。
1. 事先计算型智能重排序
所谓事先计算型,就是事先将每个用户在某个列表中的智能排序结果计算出来存到数据库中,当用户在前端浏览该列表时,推荐系统web服务直接将排序结果取出来并在前端展示给用户。(这里提一下,如果读者不熟悉本节和下一节讲的事先计算型和实时装配型,可以先看看笔者之前写的另外一篇文章《
推荐系统提供web服务的2种方式
》,这篇文章在公众号”大数据与人工智能“中,读者可以关注阅读,公众号里面有笔者写的近40万字关于推荐系统相关的系列原创文章)
一般来说,某个产品中需要做智能重排序的列表是非常多的(比如产品如果存在筛选功能的话,可供用户筛选的标签是非常多的。有很多筛选维度,每个维度下也有很多标签,因此可行的筛选组合是一个非常大的数字,可以达到几百,甚至成千上万,参见上面的图2),那么需要事先存储的数据量是 (这里 是用户数,是需要做智能重排序的列表数),这个量是非常大的(除了数据条数多,每个列表的排序结果占用的空间也很大,因为这些列表中可能会包含非常多的标的物,前面也提到,只有标的物很多的列表才有做智能重排的必要),如果将排序结果全部存下来,会占用了太多的存储资源,是不可取甚至是不可行的。
那么可行的解决方案是什么呢?一种方法是降低给用户排序的个性化程度,这种思路是根据笔者将个性化推荐分为完全个性化、群组个性化、非个性化3种范式的自然延伸。怎么理解前面这句话呢?就是先将用户聚类,对于每一类用户,可以将他们看成”一个“用户(有一定数学基础的读者可以将每一类的用户看成是一个等价类,一般来说,聚类算法会保证同一类的用户具有相似的兴趣偏好),这”一个“用户在某个列表的智能重排序就是唯一的,那么需要存储的数据量就是 (这里 是聚类数, 是需要做智能重排序的列表数),聚类数一般选取成千上万就足够了,这远远小于用户数(互联网产品的用户数一般是百万级、千万级、甚至是亿万级),一般来说存储可以减少至少3个数量级。所以,当给用户聚类时,事先计算出排序结果并存起来是可行的。
整个事先计算型智能重排序方案的架构图见下面图5,重排序引擎通过处理用户行为日志,并基于用户兴趣将用户聚类后再构建排序模型,为每一个聚类生成唯一的排序结果并存放到数据库中,当用户在产品(即APP)上访问该列表时,智能重排序web服务模块将该列表的排序结果取出来并在前端展现给用户。
图5:事先计算型智能重排序架构
整个方案的工程实现主要包含3步,首先基于用户行为挖掘出用户的兴趣偏好表示,再基于用户兴趣偏好表示将用户聚类,最后为每类用户智能重排序(见下面图6)。下面我们对每个步骤及其方法进行介绍。
图6:事先计算型智能重排序步骤
用户的兴趣是用户真实行为的反馈,我们可以基于用户在APP上的各类行为(点击、收藏、浏览、播放、加购物车、下单等等)挖掘出用户的兴趣偏好。用户的兴趣一般可以用标签来显式表示,也可以用抽象的数学对象来隐式刻画,不管哪种方式,最终都可以用一个向量来表示用户的兴趣偏好。
如果标的物是包含标签的,那么用户对标的物的操作行为就可以为用户打上相应的标签(比如,如果你看了一部恐怖电影,可以给你打上爱好恐怖电影的标签),用户对该标的物的投入度代表了用户对该标签的偏好度,即标签的权重(你看该恐怖电影如果看完了肯定比只看了10分钟更喜欢,那么看完了的时候恐怖标签可以给权重1,看了十分钟可以给权重0.3,具体怎么分配权重,需要根据策略和经验,这里不详细介绍;对于电商类产品也类似,购买了的权重大于加购物车,加购物车的权重又大于浏览商品详情页)。当我们对某个用户所有操作过的标的物标签进行上面处理后,我们可以按照字典序将所有(标的物的)标签排序,那么每个用户基于标签表示的兴趣偏好就可以表示为一个向量,向量的维数是所有标签的数量,向量中某个非零分量代表用户对这个标签有兴趣,而分量的大小代表的是用户的兴趣偏好大小。用户在具有相同标签的不同标的物上的兴趣偏好权重可以是各个具备该标签的标的物上的操作的权重的加权平均。
我们还可以用机器学习算法对用户的兴趣偏好进行建模。这里举个例子,推荐系统中常用的矩阵分解算法(比如Spark Mllib中的ALS算法)就可以用来刻画用户的兴趣偏好,通过矩阵分解可以获得用户的特征矩阵,每个用户可以用一个隐向量来表示(用户特征矩阵的行向量),这个向量就可以用于刻画用户的兴趣偏好,只不过每个分量是在某个隐因子上的表现,隐因子很难用现实中的某个具体概念来表述,可解释性没有标签那么强。最终通过矩阵分解也获得了用户的兴趣向量表示了。矩阵分解只是其中的一种方法,item-based协同过滤、各类嵌入方法、深度神经网络方法(参考文献3中YouTube曾经用到的深度学习方法就可以获得用户兴趣偏好的特征向量表示)都可以获得用户兴趣偏好的向量表示。
有了用户的兴趣偏好的向量表示,就可以对用户聚类了,常用的KMeans聚类算法就是最简单的一种聚类实现方案。利用KMeans聚类可以将每个用户分配到某一个类中,那么给这个类做智能重排序就可以了,在同一个类中的用户具备一样的智能重排序结果。
有了上面的步骤2,我们就可以获得该类的聚类中心向量(该类中每个用户向量求加权平均就可以获得聚类中心向量了),该向量可以代表该类的兴趣偏好。对于需要做智能重排序的标的物,不管是步骤1中提到的基于标签表示还是矩阵分解表示,我们都可以获得该标的物的向量表示。聚类中心向量跟该标的物的向量的cosine余弦就代表该类对该标的物的偏好得分。当我们计算出了聚类中心跟需要排序的列表中所有标的物的偏好得分后,按照偏好得分降序排列,就获得了该类的智能重排序结果。
上面讲完了基于用户聚类的事先计算型智能重排序的工程实现方案和算法原理。这里提一下,在提供推荐web服务时,我们可以事先获得该用户所在的类,再将该类的排序结果取出来,并在前端展示给该用户,因此,每个用户属于哪个类,我们也是需要事前存下来的(用户属于哪个类,我们在聚类时是知道的),同时我们计算出的智能重排序结果是基于类来存储的,一般采用key-value型的NoSQL(如Redis、CouchBase等)存储,每个类有一个唯一的标识(即key),该类对应的智能重排序结果作为值(即value)存储起来。
2. 实时装配型智能重排序
所谓实时装配型智能重排序就是在用户访问某个需要做重排序的标的物列表时,推荐系统实时计算出列表页的标的物排序结果并返回给前端展示给用户,这个计算过程是瞬间完成的,不会影响用户体验。跟事先计算型类似,我们有很多方法可以获得用户和标的物的特征向量,并且这两个向量的内积(或者cosine余弦)代表了用户与该标的物的相似度。实时装配型需要实时获得用户对列表中某个标的物的兴趣偏好,所以需要一个算法框架可以近实时地地计算出用户特征向量与每个标的物特征向量的内积(该内积即用户对该标的物的偏好得分),并对列表中所有标的物的偏好得分降序排列。只有这样才可以做到不影响用户体验并且确保用户最喜欢的一定是排在重排序列表最前面的。
下面图7是一种实时装配型智能重排序的技术实现方案,这里与事先计算型不一样的地方是有一套FAISS即席查询服务,它的作用就是提供实时计算的能力,利用用户偏好向量从所有标的物向量中搜索出与用户偏好向量最相似(用户偏好度最强的)的标的物。下面对FAISS框架进行简单的介绍,让读者理解它的工作原理。
FAISS是FaceBook开源的(见参考资料2)框架,是业界用的比较多的一款用于实时即席查询服务的框架。FAISS包含几种相似性搜索方法,它假设用户或者标的物被表示为向量并由整数标识(用户和标的物用整数来唯一标识,即用户id和标的物id),可以在海量向量库中搜索出按照某种相似性计算的最相似的向量列表(对于智能重排序,就是利用用户偏好向量,计算出标的物列表中所有标的物向量与它相似度的降序排列)。FAISS提供了向量之间计算L2(欧几里德)距离或内积距离的方法,与查询向量最相似的向量是那些与查询向量具有最小L2距离或最大内积的向量。FAISS具备在极短的时间(毫秒级)内计算某个向量最相似的一组向量的能力。它还支持cosine余弦相似性查询,因为cosine余弦只不过是向量内积的归一化。
图7:实时装配型智能重排序架构
上面提到的FAISS框架只是一种可行的解决方案。FAISS框架是一种向量近似搜索方案,要用到该方案必须将用户和标的物表示为向量,并且向量的内积或者cosine余弦等度量可以用于衡量两个向量之间的相似度。虽然很多推荐算法(前面提到的标签算法、矩阵分解算法等)可以采用这种方式实现,但这不是唯一的方式。当不能用向量化的方式表示用户和标的物时,可以采用其他的解决方案,业界常用的TensorFlow Serving(见参考资料1,其实PyTorch也有类似的Serving解决方案)也具备这样的能力,只不过需要事先训练出一个排序模型,将用户特征和标的物特征按照某种方式灌入该模型就可以获得该用户对该标的物的偏好得分,当对待排序列表中的所有标的物这样做时就获得了个性化的重排序列表。由于TensorFlow Serving也是实时计算的,它所起的作用跟上面图7中的FAISS差不多,将FAISS替换为TensorFlow Serving即可,只不过这时重排序算法的实现方案是不一样的。常用的Logistic回归、分解机、集成学习算法、深度学习算法都是可以用于排序的,这里不再赘述。
上面提到的FAISS和TensorFlow Serving的方案都是将排序过程解耦为一个独立的模块,推荐web服务通过调用排序模块获得重排序结果,其实还可以将排序模型整合到推荐web服务中,这在《推荐系统提供web服务的2种方式》这篇文章中有讲到,这里不细说。
3. 先对所有标的物排序再筛选
第3种方案是事先对所有标的物排序,当要对某个列表页(它是所有标的物构成的列表的子列表)智能重排序时,可以从已经排序好的所有标的物列表中过滤出该待排序的子列表包含的标的物。这种方案对标的物也只需要计算一次排序,并且排序结果也可以事先存储起来。在提供服务时只需要进行过滤就够了,但是要确保过滤方法是高效的,能够在毫秒级完成(不然会影响用户体验)。这种方式也可以很好地避免极大的事先计算和存储成本。这种方案也是事先计算型的,它可以看成是1的一种特例的拓展。
上面提到了需要做过滤,当然可行的过滤方式有很多,这里介绍一个简单过滤的方法,供读者参考。当我们对所有标的物排序好后,那么每个标的物可以赋予一个排序得分(比如 ,这里 是标的物排在第 位, 是所有标的物的个数,这个排序得分可以保证排在前面的标的物比排在后面的得分高,其他形式的得分赋值也是可以的,比如 也是可行的),这样每一个待排序的标的物列表中的标的物是包含具体的得分的,那么我们就可以采用快速排序等这类时间复杂度低的排序策略来对待排序的标的物列表进行重排序了,时间复杂度可以控制在 O(k*logk) 之内(这里k是待排序列表的长度),这种过滤方法可以控制过滤的速度,基本在毫秒级就可以完成,做到不影响用户体验。
4. 事先计算型与实时装配型的优劣对比
事先计算型智能重排序,是对一类(在同一聚类中的用户组成的类)用户进行重排序,精细化的颗粒度没有实时装配型那么细(事先计算型重排序做到了群组个性化,而实时装配型做到了完全个性化),最终效果肯定会比实时装配型更差一些。
还有,实时装配型可以将用户操作过的标的物放置在列表末端,但是事先计算型不能这样做,因为,事先计算型是对一类用户重排序,某个用户操作过的标的物可能其他用户没有操作过,所以不能直接将某个用户操作过的放置到最末尾。
另外,事先计算型先将结果计算出来了,在推荐时直接获取结果就可以展示给用户而不需要像实时装配型那样需要实时计算出排序结果,因此接口响应时间会更短,用户体验可能会更好。同时,由于少了一个实时计算排序的逻辑,在稳定性方面也会更好一些(对于实时装配型,如果实时排序服务挂了,推荐web服务接口就不可用了)。
5. 智能重排的冷启动方案
如果某个用户是新用户,我们无法获得该用户的兴趣偏好向量表示,这时可以利用原先的基于时间降序的默认排序策略作为默认方案。还可以采用对列表随机打散的策略,这样每天用户进入该列表时看到的排序是不一样的。
还可以对待排序的列表中的标的物进行聚类,在前端展示时,依次从每个类别中随机取一个标的物展示出来,这样就为用户提供了多样性的标的物供用户选择,这种方案可以更容易在重排序列表前面几行击中用户的偏好点,提升新用户的点击概率。
如果可以获得该用户的画像信息(比如年龄、性别、地域等),也可以利用具备该标签的用户的平均向量作为该新用户的偏好向量表示(比如知道该用户是男性,那么就可以将所有可以计算出偏好向量的男性的偏好向量的平均向量赋予给该用户),从而也可以为该用户计算出重排序列表。
智能重排序属于笛卡尔积推荐范式(一般产品是存在非常多的列表页的,比如基于各种组合的筛选,有多少组合就有多少种待排序列表,为每个用户在每一种列表页进行智能重排序,就是用户数与待排序列表数的笛卡尔积),一般用户数和列表页数都是非常大的,要全部将所有的智能排序结果事先计算并存储下来是不现实的(主要是计算、存储成本太高),这是智能重排序面临的最大挑战。
针对上述难点,我们在第4节提供了3种方案。第一种方案对用户聚类,减少了用户维度引起的计算和存储复杂度。第二种方案对计算过程进行优化,不事先计算,而是在需要排序时进行近实时计算,这就不需要太多的存储资源(当然需要存储实时计算需要的特征,这里其实就是用户及标的物的特征向量,但是这个占用的存储空间相对较小,是用户数加上标的物数这么多项需要存储,而不是它们数量的乘积),这种方案的难点是需要近实时(毫秒级)从标的物向量中筛选出跟用户向量最相似的向量(重排序是全部筛选出),这个难点是借助了FAISS(如果采用排序模型的方案,那可以用TensorFlow Serving、PyTorch Serving等框架,排序模型也需要在毫秒级对待排序列表进行排序)这个强大的框架来实现的。第三种技术方案是事先计算出所有标的物的排序,在为某个列表页提供智能重排序时,只需要从所有排好序的标的物中过滤出这个列表页中包含的标的物即可,这里面的难点就是怎么从排序好的所有标的物中筛选出该列表中包含的标的物,上一节3中也提供了一种可行的解决方案。
另外需要提一下,由于待排序的列表一般是包含非常多的标的物的(前面也讲过,只有包含非常多标的物的列表才有做智能重排序的必要),如果一次性将所有标的物取出来返回给用户,在网络中传输的数据量会比较大,影响推荐web服务的性能,从而可能影响用户体验,还可能会产生更多的成本(传输更多的数据有带宽成本)。针对上面这个问题,可行的解决方案是:可以采用分页的技术。具体做法是,在接口中可以提供分页的参数,用户访问列表时,根据用户当前的页数及用户的操作情况(向上翻页或者向下翻页),前端从推荐web服务中获取上一页或者下一页的排序结果并展示给用户。
前面讲解完了智能重排序相关的所有知识点,我们在最后一节简单介绍一下电视猫在智能重排序上的实践。
首先,在智能电视(电视猫是智能电视上的一个视频聚合APP)上进行智能重排序是非常有必要的,为什么在智能电视上非常必要呢?因为智能电视目前主要靠遥控器操作,而遥控器操作是非常不方便的,如果不进行智能重排序,这个列表更新不频繁(一般是按照标的物入库的时间降序排列,对于长视频等视频类标的物,每天新生产的标的物是很少的),用户每次进入这个列表会发现内容基本是一样的,用户要找到新的内容,必须往下翻页,但是用遥控器翻页是非常不方便的,所以用户体验会很差。通过前面的介绍,智能重排序完全可以解决这个问题。
其次,介绍一下电视猫智能重排序的技术实现方案。电视猫最早在2017年是采用的事先计算型方案进行智能重排序,基于Spark Mllib库中的ALS算法对用户行为矩阵进行矩阵分解,获得用户的特征向量表示,再进行聚类,最后对每个类的每个待排序列表进行重排序。后面在今年切换到了实时计算型智能重排序方案,采用的是基于FAISS框架的实现方案,用户特征向量采用的还是是ALS矩阵分解获得的用户向量和标的物向量。
最后,说一下智能重排序的效果。电视猫基本在所有六大类长视频(电影、电视剧、动漫、少儿、纪录片、综艺)频道页的所有列表及所有的频道筛选页中都使用了重排序方案。平均来说,重排序方案上线后的点击率比没有上线之前至少提升了20%以上。
本篇文章首先介绍了列表页智能重排序的基本概念、应用场景、业务价值等知识点。接着讲解了智能重排序的实现方案和算法原理,主要包含事先计算型和实时装配型等两类主要的技术方案,每类方案都有自己的优缺点,如果可能的话,笔者还是建议采用实时计算型,它可以做到更加精准,更细粒度的个性化,用户体验和效果转化也会更好。最后,我们介绍了智能重排序的困难和挑战以及它在电视猫上的应用案例。
-
https://www.tensorflow.org/serving
-
https://github.com/facebookresearch/faiss
-
[YouTube 2016] Deep Neural Networks for YouTube Recommendations
由于微信平台算法改版,公号内容将不再以时间排序展示,如果大家想第一时间看到我们的推送,强烈建议星标我们和给我们多点点【在看】。星标具体步骤为:
(1)点击页面最上方"AINLP",进入公众号主页。
(2)点击右上角的小点点,在弹出页面点击“设为星标”,就可以啦。
感谢支持,比心。
进群请添加AINLP小助手微信 AINLPer(id: ainlper),备注推荐系统
推荐阅读
这个NLP工具,玩得根本停不下来
征稿启示| 200元稿费+5000DBC(价值20个小时GPU算力)
完结撒花!李宏毅老师深度学习与人类语言处理课程视频及课件(附下载)
从数据到模型,你可能需要1篇详实的pytorch踩坑指南
如何让Bert在finetune小数据集时更“稳”一点
模型压缩实践系列之——bert-of-theseus,一个非常亲民的bert压缩方法
文本自动摘要任务的“不完全”心得总结番外篇——submodular函数优化
Node2Vec 论文+代码笔记
模型压缩实践收尾篇——模型蒸馏以及其他一些技巧实践小结
中文命名实体识别工具(NER)哪家强?
学自然语言处理,其实更应该学好英语
斯坦福大学NLP组Python深度学习自然语言处理工具Stanza试用
关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区,专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享,主题包括文本摘要、智能问答、聊天机器人、机器翻译、自动生成、知识图谱、预训练模型、推荐系统、计算广告、招聘信息、求职经验分享等,欢迎关注!加技术交流群请添加AINLPer(id:ainlper),备注工作/研究方向+加群目的。
阅读至此了,分享、点赞、在看三选一吧🙏