《深度学习推荐系统》——第五章1

第 5 章-多角度审视推荐系统

  在构建推荐系统的过程中，推荐模型的作⽤是重要的，但这绝不意味着推荐模型就是推荐系统的全部。事实上，推荐系统需要解决的问题是综合性的，任何⼀个技术细节的缺失都会影响最终的推荐效果。这就要求推荐⼯程师从不同的维度审视推荐系统，不仅抓住问题的核⼼，更要从整体上思考推荐问题。
  本章从 7个不同的⻆度切⼈推荐系统，希望能够较为全⾯地覆盖推荐系统相关知识，具体包括以下内容：
  (1)推荐系统如何选取和处理特征？
  (2)推荐系统召回层的主要策略有哪些？
  (3)推荐系统实时性的重要性体现在哪⼉？有哪些提⾼实时性的⽅法？
  (4)如何根据具体场景构建推荐模型的优化⽬标?
  (5) 如何基于⽤户动机改进模型结构？
  (6)推荐系统冷启动问题的解决⽅法有哪些？
  (7)什么是**“ 探索与利⽤” 问题**？有哪些主流的解决⽅法？
  以上 7 个问题之间没有必然的逻辑关系，但它们都是推荐系统中除推荐模型外不可或缺的组成部分。只有理解它们，才能构建出功能全⾯、整体架构成熟的推荐系统。

5.1 推荐系统的特征工程

  本节从特征⼯程的⻆度审视推荐系统。“Garbage in garbage out( 垃圾进，垃圾出 ）” 是算法⼯程师经常提到的⼀句话。机器学习模型的能⼒边界在于对数据的拟合和泛化，那么数据及表达数据的特征本身就决定了机器学习模型效果的上限。因此，特征⼯程对推荐系统效果提升的作⽤是⽆法替代的。为了构建⼀个“ 好”的特征⼯程，需要依次解决三个问题：
  (1)构建特征⼯程应该遵循的基本原则是什么？
  (2)有哪些常⽤的特征类别？
  (3)如何在原始特征的基础上进⾏特征处理，⽣成可供推荐系统训练和推断⽤的特征向量？

5.1.1 构建推荐系统特征工程的原则

  在推荐系统中，特征的本质其实是对某个⾏为过程相关信息的抽象表达。推荐过程中某个⾏为必须转换成某种数学形式才能被机器学习模型所学习，因此为了完成这种转换，就必须将这些⾏为过程中的信息以特征的形式抽取出来，⽤多个维度上的特征表达这⼀⾏为。
  从具体的⾏为转化成抽象的特征，这⼀过程必然涉及信息的损失。⼀是因为具体的推荐⾏为和场景中包含⼤量原始的场景、图⽚和状态信息，保存所有信息的存储空间过⼤，⽆法在现实中满⾜；⼆是因为具体的推荐场景中包含⼤量冗余的、⽆⽤的信息，都考虑进来甚⾄会损害模型的泛化能⼒。搞清楚这两点后，就可以顺理成章地提出构建推荐系统特征⼯程的原则：
  尽可能地让特征⼯程抽取出的⼀组特征能够保留推荐环境及⽤户⾏为过程中的所有有⽤信息，尽量摒弃冗余信息。
  举例来说，在⼀个电影推荐的场景下，应该如何抽取特征才能代表“ ⽤户点击某个电影” 这⼀⾏为呢？
  为了回答这个问题，读者需要把⾃⼰置身于场景中，想象⾃⼰选择点击某个电影的过程受什么因素影响？笔者从⾃⼰的⻆度出发，按照重要性的⾼低列岀了6个要素：
(1)⾃⼰对电影类型的兴趣偏好。
(2)该影⽚是否是流⾏的⼤⽚。
(3)该影⽚中是否有⾃⼰喜欢的演员和导演。
(4)电影的海报是否有吸引⼒。
(5)⾃⼰是否看过该影⽚。
(6)⾃⼰当时的⼼情。

  值得注意的是，在抽取特征的过程中，必然存在着信息的损失，例如，“ ⾃⼰当时的⼼情” 这个要素被⽆奈地舍弃了。再⽐如，⽤⽤户观看历史推断⽤户的 “兴趣偏好” 也⼀定会存在信息丢失的情况。因此，在已有的、可获得的数据基础上，“ 尽量” 保留有⽤信息是⼀个现实的⼯程上的原则。

5.1.2 推荐系统中的常用特征

  在推荐系统特征⼯程原则的基础上，本节列出在推荐系统中常⽤的特征类别，供读者在构建⾃⼰的特征⼯程时参考。
  1.⽤户⾏为数据
  ⽤户⾏为数据是推荐系统最常⽤，也是最关键的数据。⽤户的潜在兴趣、⽤户对物品的真实评价均包含在⽤户的⾏为历史中。⽤户⾏为在推荐系统中⼀般分为显性反馈⾏为 ( explicit feedback )和隐性反馈⾏为 ( implicit feedback )两种，在不同的业务场景中，则以不同的形式体现。表 5-2所示为不同业务场景下⽤户⾏为数据的例⼦。

  对⽤户⾏为数据的使⽤往往涉及对业务的理解，不同的⾏为在抽取特征时的权重不同，⽽且⼀些跟业务特点强相关的⽤户⾏为需要推荐⼯程师通过⾃⼰的观察才能发现。
  在当前的推荐系统特征⼯程中，隐性反馈⾏为越来越重要，主要原因是显性反馈⾏为的收集难度过⼤，数据量⼩。在深度学习模型对数据量的要求越来越⼤的背景下，仅⽤显性反馈的数据不⾜以⽀持推荐系统训练过程的最终收敛。因此，能够反映⽤户⾏为特点的隐性反馈是⽬前特征挖掘的重点。
  在具体的⽤户⾏为类特征的处理上，往往有两种⽅式：⼀种是将代表⽤户⾏为的物品 id 序列转换成 multi-hot 向量，将其作为特征向量；另⼀种是预先训练好物品的 Embedding (可参考第 4 章介绍的 Embedding ⽅法 ），再通过平均或者类似于 DIN 模型（可参考 3.8节）注意⼒机制的⽅法⽣成历史⾏为 Embedding 向量，将其作为特征向量。
  2.⽤户关系数据
  互联⽹本质上就是⼈与⼈、⼈与信息之间的连接。如果说⽤户⾏为数据是⼈与物之间的“ 连接” ⽇志，那么⽤户关系数据就是⼈与⼈之间连接的记录。在互联⽹时代，⼈们最常说的⼀句话就是“ 物以类聚，⼈以群分”。⽤户关系数据毫⽆疑问是值得推荐系统利⽤的有价值信息。
  ⽤户关系数据也可以分为**“ 显性” 和“ 隐性” 两种**，或者称为“ 强关系” 和“ 弱关系”。如图 5-1 所示，⽤户与⽤户之间可以通过**“ 关注” “ 好友关系” 等连接建⽴ “ 强关系”，也可以通过 “ 互相点赞” “ 同处⼀个社区”，甚⾄ “ 同看⼀部电影” 建⽴ “ 弱关系”。

  在推荐系统中，利⽤⽤户关系数据的⽅式不尽相同，可以将⽤户关系作为召回层的⼀种物品召回⽅式**；也可以通过⽤户关系建⽴关系图 ，使⽤ Graph Embedding 的⽅法⽣成⽤户和物品的 Embedding;还可以直接利⽤关系数据，通过“ 好友” 的特征为⽤户添加新的属性特征；甚⾄可以利⽤⽤户关系数据直接建⽴社会化推荐系统。
  3.属性、标签类数据
  这⾥把属性类和标签类数据归为⼀组进⾏讨论，因为本质上它们都是直接描述⽤户或者物品的特征。属性和标签的主体可以是⽤户，也可以是物品。他们的来源⾮常多样化，⼤体上包含表 5-3 中的⼏类。


  ⽤户属性、物品属性、标签类数据是最重要的描述型特征。成熟的公司往往会建⽴⼀套⽤户和物品的标签体系，由专⻔的团队负责维护，典型的例⼦就是电商公司的商品分类体系；也可以有⼀些社交化的⽅法由⽤户添加。图 5-2所示为⾖瓣的“ 添加收藏” ⻚⾯，在添加收藏的过程中，⽤户需要为收藏对象打上对应的标签，这是⼀种常⻅的社交化标签添加⽅法。
  在推荐系统中使⽤属性、标签类数据，⼀般是通过 multi-hot 编码的⽅式将其转换成特征向量，⼀些重要的属性标签类特征也可以先转换成 Embedding,再输⼈推荐模型。

  4.内容类数据
  内容类数据可以看作属性标签型特征的延伸，它们同样是描述物品或⽤户的数据，但相⽐标签类特征，内容类数据往往是⼤段的描述型⽂字、图⽚，甚⾄视频。
  ⼀般来说，内容类数据⽆法直接转换成推荐系统可以 “ 消化” 的特征，需要通过⾃然语⾔处理、计算机视觉等技术⼿段提取关键内容特征，再输⼈推荐系统。例如，在图⽚类、视频类或是带有图⽚的信息流推荐场景中，往往会利⽤计算机视觉模型进⾏⽬标检测，抽取图⽚特征（ 如图 5-3 所示 ），再把这些特征（ 要素 ）转换成标签类数据，供推荐系统使⽤。

  5.上下义信息
  上下⽂信息（ context )是描述推荐⾏为产⽣的场景的信息。最常⽤的上下⽂信息是 “ 时间” 和通过 GPS 获得的 “ 地点” 信息。根据推荐场景的不同，上下⽂信息的范围极⼴，包含但不限于时间、地点、季节、⽉份、是否节假⽇、天⽓、空⽓质量、社会⼤事件等信息。
  引⼈上下⽂信息的⽬的是尽可能地保存推荐⾏为发⽣场景的信息。典型的例⼦是：在视频推荐场景中，⽤户倾向于在傍晚看轻松浪漫题材的电影，在深夜看悬疑惊悚题材的电影。如果不引⼈上下⽂特征，则推荐系统⽆法捕捉到与这些场景相关的有价值的信息。
  6.统计类特征
  统计类特征是指通过统计⽅法计算出的特征，例如历史 CTR、历史 CVR、物品热⻔程度、物品流⾏程度等。统计类特征⼀般是连续型特征，仅需经过标准化归⼀化等处理就可以直接输⼈推荐系统进⾏训练。
  统计类特征本质上是⼀些粗粒度的预测指标。例如在 CTR 预估问题中，完全可以将某物品的历史平均 CTR 当作最简易的预测模型，但该模型的预测能⼒很弱，因此历史平均 CTR 往往仅被当作复杂 CTR 模型的特征之⼀。统计类特征往往与最后的预测⽬标有较强的相关性，因此是绝不应被忽视的重要特征类别。
  7.组合类特征
  组合类特征是指将不同特征进⾏组合后⽣成的新特征。最常⻅的是 “ 年龄+性别” 组成的⼈⼝属性分段特征（segment )。在早期的推荐系统中，推荐模型（⽐如逻辑回归 ）往往不具备特征组合的能⼒。但是随着更多深度学习推荐系统的提出，组合类特征不⼀定通过⼈⼯组合、⼈⼯筛选的⽅法选出，还可以交给模型进⾏⾃动处理。

5.1.3 常⽤的特征处理⽅法

  对推荐系统来说，模型的输⼈往往是由数字组成的特征向量。5.1.2 节提到的诸多特征类别中，有“ 年龄” “ 播放时⻓” “ 历史 CTR” 这些可以由数字表达的特征，它们可以⾮常⾃然地成为特征向量中的⼀个维度。对于更多的特征来说，例如⽤户的性别、⽤户的观看历史，它们是如何转变成数值型特征向量的呢？本节将从连续型（ continuous )特征和类别型（ categorical )特征两个⻆度介绍常⽤的特征处理⽅法。
  1. 连续型特征
  连续型特征的典型例⼦是上⽂提到的⽤户年龄、统计类特征、物品的发布时间、影⽚的播放时⻓等数值型的特征。对于这类特征的处理，最常⽤的处理⼿段包括归⼀化、离散化、加⾮线性函数等⽅法。
  归⼀化的主要⽬的是统⼀各特征的量纲，将连续特征归⼀到[0,1]区间。也可以做 0均值归⼀化，即将原始数据集归⼀化为均值为 0、⽅差为 1 的数据集。
  离散化是通过确定分位数的形式将原来的连续值进⾏分桶，最终形成离散值的过程。离散化的主要⽬的是防⽌连续值带来的过拟合现象及特征值分布不均勻的情况。经过离散化处理的连续型特征和经过 one-hot 处理的类别型特征⼀样 ,都是以特征向量的形式输⼈推荐模型中的。

  2.类別型特征
  类别型特征的典型例⼦是⽤户的历史⾏为数据、属性标签类数据等。它的原始表现形式往往是⼀个类别或者⼀个 id。这类特征最常⽤的处理⽅法是使⽤one-hot 编码将其转换成⼀个数值向量，2.5 节的“ 基础知识” 部分已经详细介绍了 one-hot 编码的具体过程，在 one-hot 编码的基础上，⾯对同⼀个特征域⾮唯⼀的类别选择，还可以采⽤ multi-hot 编码。

  对类别特征进⾏ one-hot 或 multi-hot 编码的主要问题是特征向量维度过⼤，特征过于稀疏，容易造成模型⽋拟合，模型的权重参数的数量过多，导致模型收敛过慢。因此，在 Embedding 技术成熟之后，被⼴泛应⽤在类别特征的处理上，先将类别型特征编码成稠密 Embedding 向量，再与其他特征组合，形成最终的输⼊特征向量。

5.1.4 特征工程与业务理解

  本节介绍了推荐系统特征⼯程的特征类别和主要处理⽅法。在深度学习时代，推荐模型本身承担了很多特征筛选和组合的⼯作，算法⼯程师不需要像之前那样花费⼤量精⼒在特征⼯程上。但是，深度学习模型强⼤的特征处理能⼒并不意味着我们可以摒弃对业务数据的理解，甚⾄可以说，在推荐模型和特征⼯程趋于⼀体化的今天，特征⼯程本身就是深度学习模型的⼀部分。
  举例来说，在 Wide&Deep 模型中，到底把哪些特征“ 喂” 给 Wide 部分来加强记忆能⼒，需要算法⼯程师对业务场景有深刻的理解；在 DIEN 模型中，对⽤户⾏为序列的特征抽取更是与模型结构进⾏了深度的耦合，利⽤复杂的序列模型结构对⽤户⾏为序列进⾏ Embedding 化。
  从这个意义上讲，传统的⼈⼯特征组合、过滤的⼯作已经不存在了，取⽽代之的是将特征⼯程与模型结构统⼀思考、整体建模的深度学习模式。不变的是，只有深⼊了解业务的运⾏模式，了解⽤户在业务场景下的思考⽅式和⾏为动机，才能精确地抽取出最有价值的特征，构建成功的深度学习模型。

5.2 推荐系统召回层的主要策略

  在 1.2节的推荐系统技术架构图中，清晰地描述了推荐模型部分的两个主要阶段——召回阶段和排序阶段。其中召回阶段负责将海量的候选集快速缩⼩为⼏百到⼏千的规模；⽽排序阶段则负责对缩⼩后的候选集进⾏精准排序。第 2章和第 3章的推荐模型主要应⽤于推荐系统的排序阶段，本节将着重介绍召回层的主要策略。

5.2.1 召回层和排序层的功能特点

  推荐系统的模型部分将推荐过程分成召回层和排序层的主要原因是基于⼯程上的考虑。在排序阶段，⼀般会使⽤复杂模型，利⽤多特征进⾏精准排序，⽽在这⼀过程中，如果直接对百万量级的候选集进⾏逐⼀推断，则计算资源和延迟都是在线服务过程⽆法忍受的。因此加⼈召回过程，利⽤少量的特征和简单的模型或规则进⾏候选集的快速筛选（ 如图 5-4 所示 ），减少精准排序阶段的时间开销。

  结合召回层、排序层的设计初衷和图 5-4所示的系统结构，可以总结出召回层和排序层的如下特点：
  召回层：待计算的候选集合⼤、速度快、模型简单、特征较少，尽量让⽤户感兴趣的物品在这个阶段能够被快速召回，即保证相关物品的召回率。
  排序层：⾸要⽬标是得到精准的排序结果。需处理的物品数量少，可利⽤较多特征，使⽤比较复杂的模型。
  在设计召回层时，“ 计算速度” 和 “ 召回率” 其实是⽭盾的两个指标，为提⾼“ 计算速度”，需要使召回策略尽量简单；⽽为了提⾼“ 召回率”，要求召回策略能够尽量选出排序模型需要的候选集，这⼜要求召回策略不能过于简单，导致召回物品⽆法满⾜排序模型的要求。
  在权衡计算速度和召回率后，⽬前⼯业界主流的召回⽅法是采⽤多个简单策略叠加的“ 多路召回策略”。

5.2.2 多路策略

  所谓 “ 多路召回策略”，就是指采⽤不同的策略、特征或简单模型，分别召回⼀部分候选集，然后把候选集混合在⼀起供后续排序模型使⽤的策略。
  可以明显地看出，“ 多路召回策略” 是在 “ 计算速度” 和 “ 召回率” 之间进⾏权衡的结果。其中，各简单策略保证候选集的快速召回，从不同⻆度设计的策略保证召回率接近理想的状态，不⾄于损害排序效果。
   图5-5以某信息流应⽤为例，展示了其常⽤的多路召回策略，包括“ 热⻔新闻” “ 兴趣标签” “ 协同过滤” “ 最近流⾏” “ 朋友喜欢” 等多种召回⽅法。其中，既包括⼀些计算效率⾼的简单模型（ 如协同过滤 ）；也包括⼀些基于单⼀特征的召回⽅法（如兴趣标签），还包括⼀些预处理好的召回策略（如热⻔新闻、最近流⾏等 )。

  事实上，召回策略的选择与业务强相关。对视频推荐来说，召回策略可以是**“ 热⻔视频” “ 导演召回” “ 演员召回” “ 最近上映” “ 流⾏趋势” “ 类型召回”** 等。
  每⼀路召回策略会拉回K个候选物品，对于不同的召回策略，K值可以选择不同的⼤⼩。这⾥的K值是超参数，⼀般需要通过离线评估加线上 A/B 测试的⽅式确定合理的取值范围。
  虽然多路召回是实⽤的⼯程⽅法，但从策略选择到候选集⼤⼩参数的调整都需要⼈⼯参与，策略之间的信息也是割裂的，⽆法综合考虑不同策略对⼀个物品的影响。那么，是否存在⼀个综合性强且计算速度也能满⾜需求的召回⽅法呢？基于 Embedding 的召回⽅法给出了可⾏的⽅案。