推荐系统(一)概述

在互联网领域,推荐系统(Recommendation Systems)的应用非常广泛。在音视频方面,如抖音、快手、哔哩等;在电商平台方面,如京东、淘宝、拼多多等。推荐有助于帮助用户快速发现潜在感兴趣的内容(音视频、商品、新闻等信息流),从而提升用户体验,同时有助于提升商业效率。 

从本文开始,笔者将结合自身在信息流推荐领域的经验,通过系列文章对推荐系统展开介绍。

目录

1.什么是推荐?

1.1 首页推荐

2.为什么推荐?

3.基本术语

3.1 Item

3.2 Query

3.3 Embedding

3.4 推荐场景中哪些数据可以采用 Embedding 来构造特征呢?

 3.4.1 User 数据

 3.4.2 Item 数据

 3.4.3 额外数据

 4.推荐系统概略图

4.1 候选 Item 池

4.2 打分

4.3 重排

5.候选 Item 池

5.1 嵌入空间

5.2 相似性计算

5.2.1 余弦

5.2.2 点积

5.2.3 欧氏距离

5.3 召回

6.工业推荐系统架构

 6.1 用户画像

6.2 召回

6.3 粗排

6.4 精排

6.5 混排

6.6 在离线一致性

7.参考文献


1.什么是推荐?

当你进入淘宝、京东等电商平台APP时,你可能会发现,展示的商品大都是自己感兴趣的。当你进入抖音、快手、哔哩等音视频APP时,你会发现很多音视频也是自己感兴趣的。不必惊讶,这其实就是推荐——更准确地说,是信息流推荐——即通过机器学习的推荐模型,从海量的商品、视频、新闻中寻找出用户潜在感兴趣的内容。 常用的推荐有两种:

  • 首页推荐——home page recommendations
  • 相关Item推荐——related item recommendations

注意:Item 一词直接翻译为“项目”并不合适,在信息流推荐领域,Item 指一条新闻、一则广告、一个商品、一首歌曲、一个权益等等。Item 可以理解为被一条被推荐的内容。

1.1 首页推荐

首页推荐是根据用户的已知兴趣向用户个性化推荐。每个用户都会看到不同的推荐——俗称“千人千面”。你可以尝试访问淘宝、京东等 APP,和身边的朋友对比一下,你会发现,你们看到的内容是不一样的。

顾名思义,相关 Item 推荐是指推荐与特定 Item 相似 Item。在 Google Play 应用程序示例中,查看数学应用程序页面的用户还可能会看到相关应用程序的面板,例如其他数学或科学应用程序。


2.为什么推荐?

推荐系统可以帮助用户在大型语料库中快速找到感性却的内容。例如,Google Play 商店提供数百万个应用程序,而 YouTube 提供数十亿个视频。每天都会新增更多应用程序和视频。用户如何找到新颖且感兴趣的内容呢?

一种朴素的观点,人们可以使用搜索来寻找、访问内容。然而,这并不高效,因为用户可能并不了解自己对哪些内容感兴趣,即便知道,也可能不清楚使用哪些关键词来搜索。相较之下,推荐引擎可以为用户推荐一些用户自身 “未曾想到但感兴趣” 的 Item。

你可知道?

  • Google Play 上 40% 的应用安装来自推荐。
  • YouTube 上 60% 的观看时间来自推荐。


3.基本术语

为了便于理解后面的系列文章,我们先 “统一语言”——即定义一些术语,基于这些术语交流,可以减少歧义:

3.1 Item

直译为:项目,内涵为系统推荐的实体(如视频、商品、新闻、酒店等等),也称为项目,在不同场景下,Item 的内涵也有差异。对于 Google Play 商店,Item 是要安装的应用程序;对于 YouTube,Item 是视频。

3.2 Query

也称为上下文-Context,推荐系统需要根据 Query 来计算并返回建议(推荐)的 Item。Query 可以是以下各项的组合:

  • 用户信息
    • 用户的 ID
    • 用户之前交互过的 Item
    • 用户的地理位置、年龄、学历、收入等
  • 补充信息(也称为额外信息)
    • 一天中的时间
    • 用户的设备类型和 ID

3.3 Embedding

即嵌入,在《机器学习20:嵌入-Embeddings》一文中有详细的介绍。嵌入是指从离散集(在本例中为 Query 集或要推荐的 Item 集)到称为嵌入空间的向量空间的映射。许多推荐系统依赖于学习 Query 和 Item 的适当嵌入表示—— Query 和 Item 的合适嵌入,将有助于推荐。

在提到 Embedding 时,首先想到的是“向量化”,主要作用是将 高维稀疏向量 转化为 低维稠密向量,从而方便下游模型处理。换一种说法,Embedding 是用一个 低维稠密向量 来表示一个对象,使得这个向量能够表达相应对象的某些特征,同时向量之间的距离能反映对象之间的相似性。

还有一种定义:Embedding 是将一个实例(instance)从复杂的空间嵌入(投射)到相对简单的空间,以便对原始实例进行理解,或者在相对简单的空间中进行后续操作。

3.4 推荐场景中哪些数据可以采用 Embedding 来构造特征呢?

下面简单列了笔者在 游戏和信息流推荐 时主要采用 Embedding 技术来处理的数据。

 3.4.1 User 数据

典型如:用户的基础属性数据,如性别、年龄、关系链、兴趣偏好等。

  • 对于用户兴趣偏好,一般简单地采用文本 Embedding 方法来得到各标签的 Embedding 向量,然后根据用户对这个标签的偏好程度做向量加权;
  • 对于关系链数据(如同玩好友、游戏中心相互关注等),构造用户关系图,然后采用基于图的 embedding 方法来得到用户的 Embedding 向量;

 3.4.2 Item 数据

Item 基本信息数据,如标题、作者、游戏简介、标签等。

  •  对于文本、简介和标签等可以采用基于文本的 Embedding 方法来在已有语料上预训练模型,然后得到对应的 Embedding 向量(如 word2vec 或者 BERT);
  • 此外对于有明确关系的(如 item->文本->标签 or 关键词)可以采用对关键词/标签的向量均值来表示 item 的文本向量;

  • 针对用户对 Item 的操作(如点击、互动、下载)构造:用户->item+Item 标签体系,构造用户-item-tag 的异构网络,然后可以采用 Metapath2vec 来得到各节点的 Embedding 向量;

  • 通过记录用户在整个场景访问 item,构造 Item-Item 关系图,然后采用 DeepWalk 算法得到 item 的向量,用来挖掘 Item 间的关系特征;

 3.4.3 额外数据

外部扩充数据,如用户游戏行为、用户微信其他场景活跃等。

  • 标签型,主要是用户在各场景的兴趣偏好;
  •  关系链型(如游戏中心好友、游戏内好友、开黑好友)可以采用用户关系构造用户关系图,采用 Graph Embedding 方法(如 GraphSAGE)来表示用户抽象特征。 


 4.推荐系统概略图

推荐系统的概略架构如下图所示,包括四个基本节点(复杂的推荐系统包括召回、粗排、精排、重排,会更加复杂,在第6节再展开介绍)。

  • 物料库:包括所有 Item 和 User 的特征数据
  • 召回:即采用简单模型从海量物料库中选择部分用户可能感兴趣的 Item
  • 精排:即通过复杂模型对 Item 进行打分,进而排序
  • 重排:给用户推荐的 Item 也不能完全是用户潜在感兴趣的,需要考虑多样性、时效性等

4.1 候选 Item 池

在第一阶段,系统从一个潜在的巨大物料库开始,通过【召回】生成一个小得多的候选子集​​。例如,YouTube 中的候选生成器将数十亿个视频减少到数百或数千个。鉴于语料库规模巨大,该模型需要快速评估查询。给定的模型可以提供多个候选生成器,每个生成器指定不同的候选子集​​。

4.2 打分

在复杂的推荐系统中,打分通常包括两个部分:【粗排打分】+【精排打分】。本质上都是通过模型对候选 Item 进行评分和排序,以便选择要向用户展示的 Item 集(信息流推荐大多数是分页的,每页大约 10 个,因此每次打分后,取 TOP N 即可)。由于该模型评估相对较小的 Item 子集,因此系统可以使用依赖于附加查询的更精确的模型。

4.3 重排

最后,系统必须考虑最终排名的附加约束。例如,系统删除用户明确不喜欢的项目或提高较新鲜内容的分数。重新排名还有助于确保多样性、新鲜度和公平性。


5.候选 Item 池

如何获取候选 Item 池呢?作为推荐的第一阶段,本质是一个【召回】过程。给定一个 Query,系统会生成一组相关的候选 Item。如下表所示,为两种常见的候选池生成方法。

类型 定义 例子
基于内容的过滤 利用 Item 之间的相似性,来推荐与用户喜欢的 Item 相似的 Item 如果用户 A 观看了两个可爱的猫咪视频,那么系统可以向该用户推荐可爱的动物视频。
协同过滤 同时使用 Query 和 Item 之间的相似性来提供建议。 如果用户A与用户B相似,并且用户B喜欢视频1,则系统可以向用户A推荐视频1(即使用户A没有看过任何与视频1类似的视频)。

5.1 嵌入空间

基于内容的过滤和协作过滤都将每个 Item 和每个 Query(或上下文)映射到公共嵌入空间中的嵌入向量 E = \mathbb R^d。通常,嵌入空间是低维的(即 d 比物料库的大小小得多),并捕获 Item 或 Query 集的一些潜在结构。类似的 Item(例如由同一用户观看的 YouTube 视频)最终会在嵌入空间中紧密结合在一起。“接近度” 的概念是通过相似性度量来定义的。

额外资源: projector.tensorflow.org是一个用于可视化嵌入的交互式工具。

5.2 相似性计算

相似性度量是一个函数 s : E \times E \to \mathbb R 它接受一对嵌入并返回一个测量它们相似度的标量。嵌入可用于候选池生成(即召回,也称为【向量召回】)。如下所示:给定查询嵌入:q \in E,系统寻找那些接近于 q 的 Item 的嵌入 x \in E ,即相似度高的嵌入 s(q, x)

为了计算相似度,大多数推荐系统依赖于以下一项或多项:

  • 余弦
  • 点积
  • 欧氏距离

5.2.1 余弦

即计算两个向量之间角度的余弦,s(q, x) = \cos(q, x),两个向量越接近,余弦值越大,夹角为 90 度(垂直),则结果为 0,即可认为相似度最低。

5.2.2 点积

两个向量的点积为 s(q, x) = \langle q, x \rangle = \sum_{i = 1}^d q_i x_i。也可用 s(q, x) = \|x\| \|q\| \cos(q, x)(角度的余弦乘以范数的乘积)。因此,如果嵌入被规范化(归一化),则点积和余弦重合。

5.2.3 欧氏距离

欧几里得空间中的距离。距离越小意味着相似度越高。请注意,当嵌入规范化(归一化)时,平方欧几里德距离与点积(和余弦)一致,直到达到一个常数,因为在这种情况下。s(q, x) = \|q - x\| = \left[ \sum_{i = 1}^d (q_i - x_i)^2\right]^{\frac{1}{2}}

5.3 召回

基于 Embedding 和相似度计算,我们就可以从海量的物料库中寻找到那些用户可能感兴趣的 Item,即基于相似度计算结果取出 TOP N。这一过程,在很多推荐场景中被称为【召回】。


6.工业推荐系统架构

在实际应用中,推荐系统的整体架构可以简单的用下图来描述。简单的描述一下推荐过程:当用户端发送一条请求到推荐系统 server 端后,整个推荐检索过程也就开始了,首先各路召回会根据请求中携带的用户画像信息候选物料库中筛选出千级别的候选集;送到粗排服务中进行打分排序,通过截断后选取百级别的候选集,然后送到精排服务进行打分排序,精排排序后,最终根据混排服务的要求,选择 topN 的物料发送到混排服务,参与混排;混排服务则采用一些策略决定最终的展现列表。

推荐系统架构
下面分开每个环节说一下,推荐系统中几个重要的模块。

 6.1 用户画像

用户画像是整个推荐系统最基础且最关键的模块,服务于整个推荐系统各个环节。因此,用户画像数据的质量直接决定了推荐系统效果的好坏。用户画像主要基于用户的行为日志信息挖掘出用户的长期兴趣、短期兴趣、用户行为统计信息、用户 DMP 信息、用户负反馈 等等信息。

6.2 召回

一个推荐系统中的召回模块,通常由几十个召回通道构成,每一个召回通道侧重点各不相同,常见的召回算法有:CF 类召回(ICF、UCF)、规则类召回(最新、最热等)、以及各种基于语义向量也就是 embedding 的召回,比如 DSSM 双塔召回,图召回(其实就是各种 x2vec)。主要是为了降低后面排序环节的候选集大小,通常会把百万级的候选集缩小到千级别的候选集。

6.3 粗排

粗排的存在完全就是因为精排排序受限于时间复杂度,因为目前的精排模型往往是层数很深的 DNN 网络,由于线上时间的限制,所能预估排序的规模终究有限,所以才有了粗排这么一个环节。常见的粗排模型有 DSSM 等。由于粗排是给精排服务的,因此这里还涉及到粗精排目标一致性的问题,常用的做法就是粗精排特征对齐。 近年来,工业界在粗排环节也有很多尝试,比如引入知识蒸馏的思想,把精排-粗排构建一个 teacher-student 网络(详情见《推荐系统(七)知识蒸馏优化粗排模型》),即用精排模型指导粗排模型的训练。

6.4 精排

目前无论是学术界还是工业界,大部分的精力都集中于精排这个环节。主要有几个方面的因素:

  • 精排环节是模型层出的环节,学术界以论文为导向,自然把精力都放在了模型上面,不然着实没法水论文啊。
  • 这一波深度学习浪潮席卷了 CV、NLP、推荐,虽然是由于数据、算力和算法三个因素共同助推了深度学习的浪潮,首先数据量自不用说,每年都在以指数的速度在增长,硬件算力优化历来都是小众,很多人没兴趣甚至也没能力去搞。加之工业界的成果如果想共享或者有影响力,最好的方式依然是发论文,而发论文嘛又回到了第一条里。本次推荐系统系列博客也主要集中在精排阶段的常用模型上。

精排阶段的目标就是排出用户可能最喜欢的 item 列表,用的比较多的排序方式还是 point-wise,因此本质上就是个 CTR 预估模型,因此精排模型的演进实际上就是 CTR 模型的演进历程。下面用一张图来简单的总结下工业界常用的 CTR 模型的演进历史,能够看出基本都围绕着如何更好的从样本中学出有用的信息,因此特征工程的重要性无与伦比,从统计机器学习时代的 LR,进化到embedding+MLP 的范式,也都是在围绕着如何学到更加有用的高阶交叉特征信息。

在统计机器学习时代,LR 在工业界占据统治地位,LR 有着诸多的优点:简单可解释性强,易于分布式并行训练。但 LR 只是个线性模型,没办法学到学到一些高阶交叉信息,因此如果想学到更加细粒度的信息,需要大量的特征工程,既人工做二阶交叉特征,但这样的话,时间复杂度又会飙升,比如 N 个特征,两两交叉复杂度就到了 O(N^{^{2}}),所以 rendle 大佬提出了 FM 模型用于学习二阶交叉特征,Facebook 则利用 GDBT 进行特征组合然后输入到 LR 里,提出了 GBDT+LR 的模型。待到深度学习来临后,embedding+MLP 的范式成为主流,详细的后面在单独介绍每个模型时再一一详述,这里不再赘述,大家看看下面的图就好。

在这里插入图片描述


6.5 混排

混排,顾名思义,就是多种不同类型的内容混合排序,在信息流推荐中,比如手百的信息流内容类型可能会包括:资讯,视频,小视频,图文,动态等等内容。在用户请求时,为了多样性的考虑,这些内容以列表页的形式展现给用户,那么必然涉及到排序,所以有了混排,最终的目的还是为了提高用户的点击率。此外混排还会涉及到一些策略,比如冷启用户的曝光处理,以及一些强制曝光策略等。

6.6 在离线一致性

推荐系统中,大多人只关注模型部分,但实际上整个推荐系统是一个庞大的工程,离线的模型训练只是推荐系统的一个环节,对于有过工业界经验的人来说,最头疼的莫过于如何保证离线一致性了,因此通常负责离线模型的同学和负责在线工程的同学不是同一个,往往还是不同的语言,比如离线 python,在线 C++,就会导致很多不一致的问题。在离线不一致主要有两部分:

  • 特征的在离线不一致;
  • 模型的在离线不一致。

先来说说产生在离线不一致的根源,以特征为例:在离线没有采用统一的框架,比如在线用一套C++ 抽取框架,离线用一套 Java 抽取框架,还是不同的人实现的,那么必然产生在离线不一致的情况。因此,最好的解决办法,就是在离线采用相同的特征抽取框架。模型也是,离线在线采用相同的代码框架,在百度内部,模型部分在离线采用相同的 C++ 代码编译出来的 bin 文件,只要参数不配置错误,就能从根源上避免在离线不一致的情况。此外在离线特征一致性的监控也非常重要,能够检测出不一致的特征,及时修复。


7.参考文献

1-https://developers.google.cn/machine-learning/recommendation/overview

2-https://www.163.com/dy/article/FROC0ILQ0518R7MO.html

3-https://blog.csdn.net/u012328159/article/details/119854083?spm=1001.2014.3001.5501

猜你喜欢

转载自blog.csdn.net/Jin_Kwok/article/details/131593071