写点什么

智能重排序在推荐场景中的应用 (三十四)

发布于: 3 小时前
智能重排序在推荐场景中的应用(三十四)

写在前面:

大家好,我是强哥,一个热爱分享的技术狂。目前已有 12 年大数据与 AI 相关项目经验, 10 年推荐系统研究及实践经验。平时喜欢读书、暴走和写作。

业余时间专注于输出大数据、AI 等相关文章,目前已经输出了 40 万字的推荐系统系列精品文章,今年 6 月底会出版「构建企业级推荐系统:算法、工程实现与案例分析」一书。如果这些文章能够帮助你快速入门,实现职场升职加薪,我将不胜欢喜。

想要获得更多免费学习资料或内推信息,一定要看到文章最后喔。

内推信息

如果你正在看相关的招聘信息,请加我微信:liuq4360,我这里有很多内推资源等着你,欢迎投递简历。

免费学习资料

如果你想获得更多免费的学习资料,请关注同名公众号【数据与智能】,输入“资料”即可!

学习交流群

如果你想找到组织,和大家一起学习成长,交流经验,也可以加入我们的学习成长群。群里有老司机带你飞,另有小哥哥、小姐姐等你来勾搭!加小姐姐微信:epsila,她会带你入群。


随着移动互联网的深入发展,硬件成本的降低,智能手机成为每个人的标配。手机最初主要用于沟通交流,但随着科技的进步和应用场景的拓展,手机的通信功能弱化了,人们利用手机更多地用于获取信息。不管是看视频、刷某音、看新闻,还是社交、购物、投资,都可以看成是信息获取的过程(至少信息获取是其中最重要的一个环节之一)。在当前信息爆炸的时代,获取有价值的信息不是一件容易的事情,但我们可以借助机器学习算法来更好地帮助用户获取有价值的信息。

 

用户在互联网产品上获取信息主要有 3 种方式:一种是用户需求比较明确,用户知道自己需要什么,这时一般会通过搜索来获取信息;第二种方式是用户需求不是特别明确,这时可以借助个性化推荐技术来帮助用户更便捷地获取信息,个性化推荐基于用户历史行为,构建数学模型,猜测用户兴趣偏好,为用户提供个性化的信息推荐;第三种方式是用户通过产品提供的筛选、列表等模块自己逐个找寻、检索自己需要的信息。第一、第二种方式都是通过算法(搜索算法、推荐算法)来帮助用户更简洁、方便、快速地获得更加精准的信息。其实第三种方式也是可以借助算法来帮助用户更快、更精准地找到自己喜欢的信息的,这就是本文要讲的列表页智能重排序算法。

 

具体来说,本文会从什么是列表页智能重排序、智能重排序的应用场景、智能重排序的价值、智能重排序的实现方案与算法原理、智能重排序的难点与挑战、智能重排序在电视猫上的应用等 6 个维度来讲解智能重排序相关的知识点。期望读者可以掌握智能重排序的基本概念、核心思想、实现原理与业务价值,并思考在自己的产品中是否可以采用本文的思路去优化、提升用户体验与商业价值。

 

一、什么是列表页智能重排序?

在很多互联网产品中,存在很多以某个主题组织的内容池,该主题下的标的物一般以某种方式排列(典型的比如按照标的物入库的先后顺序降序排列,新入库的标的物放在最前面),用户想要在该主题下找到某个自己喜欢的标的物,需要逐个浏览。某猫电视剧频道里面各个主题(比如战争风云)的 UI 呈现方式,当焦点聚焦在某个主题上时,右边会展示出所有与该主题相关的视频。

 

根据上面的介绍,这类内容展现形式是将某个主题下的所有标的物按照某种规则进行更新和排序。有可能前面的标的物用户已经操作过(看过、浏览过、购买过、甚至忽略过等),当用户第二次再浏览该页面时,如果用户操作过的或者不喜欢的标的物还展示给用户时,对用户体验不是很好。那么是否有办法解决这个问题呢?答案是肯定的,这就是利用智能重排序技术对展示的标的物列表进行智能排序。

 

所谓智能重排序,就是在产品(即 APP)的任何一个包含大量标的物的列表页或者类目结构中,通过机器学习算法来学习用户对标的物的偏好程度,对列表页/类目结构中的标的物进行智能重排,保证用户喜欢的标的物排在前面,提升列表页的用户体验和点击转化。该解决方案可以做到千人前面的智能重排,每个用户的排序都是不一样的,都是适配用户兴趣的,真正做到个性化、智能化。这里要说明两点,一是智能重排序后这个列表或者类目结构中包含的标的物数量是不变的,只不过排序方式是根据算法来计算出来的,用户喜欢的会排在前面。二是,这个排序是个性化的,可以做到每个人的排序方式不一样。举个例子,在某猫 APP 电视剧频道首页的战争风云这个主题中(见上面图 1),如果利用算法给每个用户生成个性化的排序,那么这就是列表页智能重排序。

 

智能重排序与推荐系统是有非常紧密的内在联系的。首先,我们可以将智能重排序看成是对已经召回的内容(即需要智能重排的标的物列表)的排序,从这个角度看,智能重排序就等价于推荐系统的排序模块。其次,我们可以将智能重排序看成限定范围的推荐,我们将推荐内容限定在需要排序的列表中的标的物上,需要通过排序将列表中的标的物推荐给用户,并且是全部推荐给用户。不管是上面哪一个角度看智能重排序,它都可以看成是推荐系统的一种特例。

 

通过上面的介绍,相信读者已经理解了什么是智能重排序,下面我们来说说智能重排序的应用场景。

 

二、智能重排序的应用场景

根据上面一节中的讲解,只要是在产品中存在按照某个主题或者某个类目结构来对标的物进行组织的产品架构,都可以借助智能重排序技术来对标的物列表进行智能排序。一般来说,智能重排序主要的应用场景包含如下这 3 大类场景:

 

1. 视频网站按照某种主题展示的视频列表

像某奇艺等视频网站,存在很多根据某个标签(一个标签也算一个主题)组织的内容结构,这里当然可以利用智能重排技术对展示出的视频进行个性化排序。下图就是节目的筛选界面,筛选是满足多个标签的内容的过滤操作,将所有的包含这几个筛选标签的内容展示出来,这本身也是一种内容的列表。电视猫也属于视频类 APP,只不过只在智能电视上播放,也属于这一类。

 

2. 电商网站按照类目组织的内容列表

像电商网站,一般按照多级类目结构来组织商品,每个类目下有大量的商品,这些商品构成一个商品的列表,因此可以用智能排序技术来对物品进行个性化重排并展示出来。某东男装类目下的子类目,每个子类目点击进去就是各种衣服或裤子列表,这些列表可以用智能重排技术来优化排序逻辑,提升用户体验与点击转化率。

 

3. 生活服务类 APP 按照服务类型组织的服务列表

生活服务类 APP 中包含多个品类的服务类型,其中很多服务类型是包含子服务类别的,进入这些子服务类别就展示该类别下的所有服务,这些服务也构成一个服务列表。因此,是可以用个性化排序策略进行优化的。某团 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 万字关于推荐系统相关的系列原创文章)

 

一般来说,某个产品中需要做智能重排序的列表是非常多的(比如产品如果存在筛选功能的话,可供用户筛选的标签是非常多的。有很多筛选维度,每个维度下也有很多标签,因此可行的筛选组合是一个非常大的数字,可以达到几百,甚至成千上万),那么需要事先存储的数据量是


(这里


是用户数,


是需要做智能重排序的列表数),这个量是非常大的(除了数据条数多,每个列表的排序结果占用的空间也很大,因为这些列表中可能会包含非常多的标的物,前面也提到,只有标的物很多的列表才有做智能重排的必要),如果将排序结果全部存下来,会占用了太多的存储资源,是不可取甚至是不可行的。

 

那么可行的解决方案是什么呢?一种方法是降低给用户排序的个性化程度,这种思路是根据笔者将个性化推荐分为完全个性化、群组个性化、非个性化 3 种范式的自然延伸。怎么理解前面这句话呢?就是先将用户聚类,对于每一类用户,可以将他们看成”一个“用户(有一定数学基础的读者可以将每一类的用户看成是一个等价类,一般来说,聚类算法会保证同一类的用户具有相似的兴趣偏好),这”一个“用户在某个列表的智能重排序就是唯一的,那么需要存储的数据量就是


(这里


是聚类数,


是需要做智能重排序的列表数),聚类数一般选取成千上万就足够了,这远远小于用户数(互联网产品的用户数一般是百万级、千万级、甚至是亿万级),一般来说存储可以减少至少 3 个数量级。所以,当给用户聚类时,事先计算出排序结果并存起来是可行的。

 

整个事先计算型智能重排序方案的架构图见下面图 5,重排序引擎通过处理用户行为日志,并基于用户兴趣将用户聚类后再构建排序模型,为每一个聚类生成唯一的排序结果并存放到数据库中,当用户在产品(即 APP)上访问该列表时,智能重排序 web 服务模块将该列表的排序结果取出来并在前端展现给用户。

 


图 5:事先计算型智能重排序架构

 

整个方案的工程实现主要包含 3 步,首先基于用户行为挖掘出用户的兴趣偏好表示,再基于用户兴趣偏好表示将用户聚类,最后为每类用户智能重排序(见下面图 6)。下面我们对每个步骤及其方法进行介绍。

 


图 6:事先计算型智能重排序步骤

 

1)挖掘用户兴趣

用户的兴趣是用户真实行为的反馈,我们可以基于用户在 APP 上的各类行为(点击、收藏、浏览、播放、加购物车、下单等等)挖掘出用户的兴趣偏好。用户的兴趣一般可以用标签来显式表示,也可以用抽象的数学对象来隐式刻画,不管哪种方式,最终都可以用一个向量来表示用户的兴趣偏好。

 

如果标的物是包含标签的,那么用户对标的物的操作行为就可以为用户打上相应的标签(比如,如果你看了一部恐怖电影,可以给你打上爱好恐怖电影的标签),用户对该标的物的投入度代表了用户对该标签的偏好度,即标签的权重(你看该恐怖电影如果看完了肯定比只看了 10 分钟更喜欢,那么看完了的时候恐怖标签可以给权重 1,看了十分钟可以给权重 0.3,具体怎么分配权重,需要根据策略和经验,这里不详细介绍;对于电商类产品也类似,购买了的权重大于加购物车,加购物车的权重又大于浏览商品详情页)。当我们对某个用户所有操作过的标的物标签进行上面处理后,我们可以按照字典序将所有(标的物的)标签排序,那么每个用户基于标签表示的兴趣偏好就可以表示为一个向量,向量的维数是所有标签的数量,向量中某个非零分量代表用户对这个标签有兴趣,而分量的大小代表的是用户的兴趣偏好大小。用户在具有相同标签的不同标的物上的兴趣偏好权重可以是各个具备该标签的标的物上的操作的权重的加权平均。

 

我们还可以用机器学习算法对用户的兴趣偏好进行建模。这里举个例子,推荐系统中常用的矩阵分解算法(比如 Spark Mllib 中的 ALS 算法)就可以用来刻画用户的兴趣偏好,通过矩阵分解可以获得用户的特征矩阵,每个用户可以用一个隐向量来表示(用户特征矩阵的行向量),这个向量就可以用于刻画用户的兴趣偏好,只不过每个分量是在某个隐因子上的表现,隐因子很难用现实中的某个具体概念来表述,可解释性没有标签那么强。最终通过矩阵分解也获得了用户的兴趣向量表示了。矩阵分解只是其中的一种方法,item-based 协同过滤、各类嵌入方法、深度神经网络方法(参考文献 3 中 YouTube 曾经用到的深度学习方法就可以获得用户兴趣偏好的特征向量表示)都可以获得用户兴趣偏好的向量表示。

 

2)用户聚类

有了用户的兴趣偏好的向量表示,就可以对用户聚类了,常用的 KMeans 聚类算法就是最简单的一种聚类实现方案。利用 KMeans 聚类可以将每个用户分配到某一个类中,那么给这个类做智能重排序就可以了,在同一个类中的用户具备一样的智能重排序结果。

 

3)为每个类做智能重排序

有了上面的步骤 2,我们就可以获得该类的聚类中心向量(该类中每个用户向量求加权平均就可以获得聚类中心向量了),该向量可以代表该类的兴趣偏好。对于需要做智能重排序的标的物,不管是步骤 1 中提到的基于标签表示还是矩阵分解表示,我们都可以获得该标的物的向量表示。聚类中心向量跟该标的物的向量的 cosine 余弦就代表该类对该标的物的偏好得分。当我们计算出了聚类中心跟需要排序的列表中所有标的物的偏好得分后,按照偏好得分降序排列,就获得了该类的智能重排序结果。

 

上面讲完了基于用户聚类的事先计算型智能重排序的工程实现方案和算法原理。这里提一下,在提供推荐 web 服务时,我们可以事先获得该用户所在的类,再将该类的排序结果取出来,并在前端展示给该用户,因此,每个用户属于哪个类,我们也是需要事前存下来的(用户属于哪个类,我们在聚类时是知道的),同时我们计算出的智能重排序结果是基于类来存储的,一般采用 key-value 型的 NoSQL(如 Redis、CouchBase 等)存储,每个类有一个唯一的标识(即 key),该类对应的智能重排序结果作为值(即 value)存储起来。

 

实时装配型智能重排序

所谓实时装配型智能重排序就是在用户访问某个需要做重排序的标的物列表时,推荐系统实时计算出列表页的标的物排序结果并返回给前端展示给用户,这个计算过程是瞬间完成的,不会影响用户体验。跟事先计算型类似,我们有很多方法可以获得用户和标的物的特征向量,并且这两个向量的内积(或者 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 种方案是事先对所有标的物排序,当要对某个列表页(它是所有标的物构成的列表的子列表)智能重排序时,可以从已经排序好的所有标的物列表中过滤出该待排序的子列表包含的标的物。这种方案对标的物也只需要计算一次排序,并且排序结果也可以事先存储起来。在提供服务时只需要进行过滤就够了,但是要确保过滤方法是高效的,能够在毫秒级完成(不然会影响用户体验)。这种方式也可以很好地避免极大的事先计算和存储成本。这种方案也是事先计算型的,它可以看成是 1 的一种特例的拓展。

 

上面提到了需要做过滤,当然可行的过滤方式有很多,这里介绍一个简单过滤的方法,供读者参考。当我们对所有标的物排序好后,那么每个标的物可以赋予一个排序得分(比如


,这里


 是标的物排在第


 位,


 是所有标的物的个数,这个排序得分可以保证排在前面的标的物比排在后面的得分高,其他形式的得分赋值也是可以的,比如


 也是可行的),这样每一个待排序的标的物列表中的标的物是包含具体的得分的,那么我们就可以采用快速排序等这类时间复杂度低的排序策略来对待排序的标的物列表进行重排序了,时间复杂度可以控制在


之内(这里 k 是待排序列表的长度),这种过滤方法可以控制过滤的速度,基本在毫秒级就可以完成,做到不影响用户体验。

 

事先计算型与实时装配型的优劣对比

事先计算型智能重排序,是对一类(在同一聚类中的用户组成的类)用户进行重排序,精细化的颗粒度没有实时装配型那么细(事先计算型重排序做到了群组个性化,而实时装配型做到了完全个性化),最终效果肯定会比实时装配型更差一些。

 

还有,实时装配型可以将用户操作过的标的物放置在列表末端,但是事先计算型不能这样做,因为,事先计算型是对一类用户重排序,某个用户操作过的标的物可能其他用户没有操作过,所以不能直接将某个用户操作过的放置到最末尾。

 

另外,事先计算型先将结果计算出来了,在推荐时直接获取结果就可以展示给用户而不需要像实时装配型那样需要实时计算出排序结果,因此接口响应时间会更短,用户体验可能会更好。同时,由于少了一个实时计算排序的逻辑,在稳定性方面也会更好一些(对于实时装配型,如果实时排序服务挂了,推荐 web 服务接口就不可用了)。

 

智能重排的冷启动方案

如果某个用户是新用户,我们无法获得该用户的兴趣偏好向量表示,这时可以利用原先的基于时间降序的默认排序策略作为默认方案。还可以采用对列表随机打散的策略,这样每天用户进入该列表时看到的排序是不一样的。

 

还可以对待排序的列表中的标的物进行聚类,在前端展示时,依次从每个类别中随机取一个标的物展示出来,这样就为用户提供了多样性的标的物供用户选择,这种方案可以更容易在重排序列表前面几行击中用户的偏好点,提升新用户的点击概率。

 

如果可以获得该用户的画像信息(比如年龄、性别、地域等),也可以利用具备该标签的用户的平均向量作为该新用户的偏好向量表示(比如知道该用户是男性,那么就可以将所有可以计算出偏好向量的男性的偏好向量的平均向量赋予给该用户),从而也可以为该用户计算出重排序列表。

 

五、智能重排序的难点与挑战

智能重排序属于笛卡尔积推荐范式(一般产品是存在非常多的列表页的,比如基于各种组合的筛选,有多少组合就有多少种待排序列表,为每个用户在每一种列表页进行智能重排序,就是用户数与待排序列表数的笛卡尔积),一般用户数和列表页数都是非常大的,要全部将所有的智能排序结果事先计算并存储下来是不现实的(主要是计算、存储成本太高),这是智能重排序面临的最大挑战。

 

针对上述难点,我们在第 4 节提供了 3 种方案。第一种方案对用户聚类,减少了用户维度引起的计算和存储复杂度。第二种方案对计算过程进行优化,不事先计算,而是在需要排序时进行近实时计算,这就不需要太多的存储资源(当然需要存储实时计算需要的特征,这里其实就是用户及标的物的特征向量,但是这个占用的存储空间相对较小,是用户数加上标的物数这么多项需要存储,而不是它们数量的乘积),这种方案的难点是需要近实时(毫秒级)从标的物向量中筛选出跟用户向量最相似的向量(重排序是全部筛选出),这个难点是借助了 FAISS(如果采用排序模型的方案,那可以用 TensorFlow Serving、PyTorch Serving 等框架,排序模型也需要在毫秒级对待排序列表进行排序)这个强大的框架来实现的。第三种技术方案是事先计算出所有标的物的排序,在为某个列表页提供智能重排序时,只需要从所有排好序的标的物中过滤出这个列表页中包含的标的物即可,这里面的难点就是怎么从排序好的所有标的物中筛选出该列表中包含的标的物,上一节 3 中也提供了一种可行的解决方案。

 

另外需要提一下,由于待排序的列表一般是包含非常多的标的物的(前面也讲过,只有包含非常多标的物的列表才有做智能重排序的必要),如果一次性将所有标的物取出来返回给用户,在网络中传输的数据量会比较大,影响推荐 web 服务的性能,从而可能影响用户体验,还可能会产生更多的成本(传输更多的数据有带宽成本)。针对上面这个问题,可行的解决方案是:可以采用分页的技术。具体做法是,在接口中可以提供分页的参数,用户访问列表时,根据用户当前的页数及用户的操作情况(向上翻页或者向下翻页),前端从推荐 web 服务中获取上一页或者下一页的排序结果并展示给用户。

 

六、智能重排序在电视猫上的应用

前面讲解完了智能重排序相关的所有知识点,我们在最后一节简单介绍一下电视猫在智能重排序上的实践。

 

首先,在智能电视(某猫是智能电视上的一个视频聚合 APP)上进行智能重排序是非常有必要的,为什么在智能电视上非常必要呢?因为智能电视目前主要靠遥控器操作,而遥控器操作是非常不方便的,如果不进行智能重排序,这个列表更新不频繁(一般是按照标的物入库的时间降序排列,对于长视频等视频类标的物,每天新生产的标的物是很少的),用户每次进入这个列表会发现内容基本是一样的,用户要找到新的内容,必须往下翻页,但是用遥控器翻页是非常不方便的,所以用户体验会很差。通过前面的介绍,智能重排序完全可以解决这个问题。

 

其次,介绍一下某猫智能重排序的技术实现方案。电视猫最早在 2017 年是采用的事先计算型方案进行智能重排序,基于 Spark Mllib 库中的 ALS 算法对用户行为矩阵进行矩阵分解,获得用户的特征向量表示,再进行聚类,最后对每个类的每个待排序列表进行重排序。后面在今年切换到了实时计算型智能重排序方案,采用的是基于 FAISS 框架的实现方案,用户特征向量采用的还是是 ALS 矩阵分解获得的用户向量和标的物向量。

 

最后,说一下智能重排序的效果。电视猫基本在所有六大类长视频(电影、电视剧、动漫、少儿、纪录片、综艺)频道页的所有列表及所有的频道筛选页中都使用了重排序方案。平均来说,重排序方案上线后的点击率比没有上线之前至少提升了 20%以上。

 

总结

本篇文章首先介绍了列表页智能重排序的基本概念、应用场景、业务价值等知识点。接着讲解了智能重排序的实现方案和算法原理,主要包含事先计算型和实时装配型等两类主要的技术方案,每类方案都有自己的优缺点,如果可能的话,笔者还是建议采用实时计算型,它可以做到更加精准,更细粒度的个性化,用户体验和效果转化也会更好。最后,我们介绍了智能重排序的困难和挑战以及它在电视猫上的应用案例。

 

参考资料

1. https://www.tensorflow.org/serving

2. https://github.com/facebookresearch/faiss

3. [YouTube 2016] Deep Neural Networks for YouTube Recommendations

 

发布于: 3 小时前阅读数: 9
用户头像

还未添加个人签名 2018.05.14 加入

公众号【数据与智能】主理人,个人微信:liuq4360 12 年大数据与 AI相关项目经验, 10 年推荐系统研究及实践经验,目前已经输出了40万字的推荐系统系列精品文章,并有新书即将出版。

评论

发布
暂无评论
智能重排序在推荐场景中的应用(三十四)