《深度学习推荐算法》——第五章2

5.2.3 基于 Embedding 的召回⽅法

  4.5 节曾详细介绍了 YouTube 推荐系统中利⽤深度学习⽹络⽣成的Embedding 作为召回层的⽅法。再加上可以使⽤局部敏感哈希进⾏快速的Embedding 最近邻计算，基于 Embedding 的召回⽅法在效果和速度上均不逊⾊于多路召回。
  事实上，多路召回中使⽤“ 兴趣标签” “ 热⻔度” “ 流⾏趋势” “ 物品属性”等信息都可以作为 Embedding 召回⽅法中的附加信息（ side information )融合进最终的 Embedding 向量中（ 典型的例⼦是 4.4节介绍的 EGES Embedding ⽅法 ）。就相当于在利⽤ Embedding 召回的过程中，考虑到了多路召回的多种策略。
  Embedding 召回的另⼀个优势在于评分的连续性。多路召回中不同召回策略产⽣的相似度、热度等分值不具备可⽐性，⽆法据此决定每个召回策略放回候选集的⼤⼩。Embedding 召回可以把 Embedding 间的相似度作为唯⼀的判断标准，因此可以随意限定召回的候选集⼤⼩。
  ⽣成 Embedding 的⽅法也绝不是唯⼀的，除了第 4章介绍的 Item2vec、Graph Embedding 等⽅法，矩阵分解、因⼦分解机等简单模型也完全可以得出⽤户和物品的 Embedding 向量。在实际应⽤中可以根据效果确定最优的召回层 Embedding的⽣成⽅法。

5.3 推荐系统的实时性

  周星驰的电影《功夫》⾥有⼀句著名的台词“ 天下武功，⽆坚不摧，唯快不破”。如果说推荐模型的架构是那把“ ⽆坚不摧” 的“ ⽞铁重剑”，那么推荐系统的实时性就是“ 唯快不破” 的“ 柳叶⻜⼑”。本节就从推荐系统“ 实时性” 的⻆度谈⼀谈影响推荐系统实时性的重要性体现在哪⾥，以及如何提⾼推荐系统的实时性。

5.3.1 为什么说推荐系统的实时性是重要的

  在解决怎样提⾼推荐系统实时性这个问题之前，我们先思考“ 推荐系统的实时性是不是⼀个重要的影响推荐效果的因素”。为了证明推荐系统实时性和推荐效果之间的关系，Facebook 曾利⽤ “GBDT+LR” 模型进⾏过实时性的实验（ 如图 5 6所示），笔者以此数据为例，说明实时性的重要性。

  图 5-6 中横轴代表从推荐模型训练结束到模型测试的时间间隔（ 天数 ），纵轴是损失函数 Normalized Entropy (归⼀化交叉熵 ）的相对值。从图中可以看出，⽆论是 “GBDT+LR” 模型，还是单纯的树模型，损失函数的值都跟模型更新延迟有正相关的关系，也就意味着模型更新的间隔时间越⻓，推荐系统的效果越差；反过来说，模型更新得越频繁，实时性越好，损失越⼩，效果越好。
  从⽤户体验的⻆度讲，在⽤户使⽤个性化新闻应⽤时，⽤户的期望是更快地找到与⾃⼰兴趣相符的⽂章；在使⽤短视频服务时，期望更快地“ 刷” 到⾃⼰感兴趣的内容；在线购物时，也期望更快地找到⾃⼰喜欢的商品。只要推荐系统能感知⽤户反馈、实时地满⾜⽤户的期望⽬标，就能提⾼推荐的效果，这就是推荐系统 “ 实时性” 作⽤的直观体现。
  从机器学习的⻆度讲，推荐系统实时性的重要之处体现在以下两个⽅⾯：
  ( 1 )推荐系统的更新速度越快，代表⽤户最近习惯和爱好的特征更新越快，越能为⽤户进⾏更有时效性的推荐。
  ( 2 )推荐系统更新得越快，模型越容易发现最新流⾏的数据模式（ data pattern ), 越能让模型快速抓住最新的流⾏趋势。
  这两⽅⾯的原因直接对应着推荐系统实时性的两⼤要素：⼀是推荐系统**“ 特征” 的实时性**；⼆是推荐系统 “ 模型” 的实时性。

5.3.2 推荐系统“ 特征” 的实时性

  推荐系统特征的实时性指的是**“ 实时” 地收集和更新推荐模型的输⼊特征**,使推荐系统总能使⽤最新的特征进⾏预测和推荐。
  举例来说，在⼀个短视频应⽤中，某⽤户完整地看完了⼀个⻓度为 10 分钟的 “ ⽻⽑球教学” 视频。毫⽆疑问，该⽤户对 “ ⽻⽑球” 这个主题是感兴趣的。系统希望⽴刻为⽤户继续推荐“ ⽻⽑球” 相关的视频。但是由于系统特征的实时性不强，⽤户的观看历史⽆法实时反馈给推荐系统，导致推荐系统得知该⽤户看过 “ ⽻⽑球教学” 这个视频已经是半个⼩时之后了，此时⽤户已经离开该应⽤，⽆法继续推荐。这就是⼀个因推荐系统实时性差导致推荐失败的例⼦。
  诚然，在⽤户下次打开该应⽤时，推荐系统可以利⽤上次的⽤户历史继续推荐“ ⽻⽑球” 相关的视频，但毫⽆疑问，该推荐系统丧失了最可能增加⽤户黏性和留存度的时机。
  为了说明增强“ 特征” 实时性的具体⽅法，笔者在推荐系统的数据流架构图之上（ 如图 5-7所示 ），来说明影响 “ 特征” 实时性的三个主要阶段。

  1. 客户端实时特征
  客户端是最接近⽤户的环节，也是能够实时收集⽤户会话内⾏为及所有上下⽂特征的地⽅。在经典的推荐系统中，利⽤客户端收集时间、地点、推荐场景等上下⽂特征，然后让这些特征随 http 请求⼀起到达服务器端是常⽤的请求推荐结果的⽅式。但容易被忽视的⼀点是客户端还是能够实时收集 session( 会话 ）内⽤户⾏为的地⽅。
  拿新闻类应⽤来说，⽤户在⼀次会话中（假设会话时⻓ 3分钟）分别点击并阅读了三篇⽂章。这三篇⽂章对推荐系统来说是⾄关重要的，因为它们代表了该⽤户的即时兴趣。如果能根据⽤户的即时兴趣实时地改变推荐结果，那对新闻应⽤来说将是很好的⽤户体验 。
  如果采⽤传统的流计算平台（图 5-7中的 Flink ), 甚⾄批处理计算平台（ 图5-7中的 Spark ),则由于延迟问题，系统可能⽆法在 3分钟之内就把 session 内部的⾏为历史存储到特征数据库（如 Redis )中，这就导致⽤户的推荐结果不会⻢上受到 session 内部⾏为的影响，⽆法做到推荐结果的实时更新。
  如果客户端能够缓存 session 内部的⾏为，将其作为与上下⽂特征同样的实时特征传给推荐服务器，那么推荐模型就能够实时地得到 session 内部的⾏为特征，进⾏实时的推荐。这就是利⽤客户端实时特征进⾏实时推荐的优势所在。

  2.流计算平台的准实时特征处理
  随着 Storm Spark Streaming、Flink 等⼀批⾮常优秀的流计算平台的⽇益成熟，利⽤流计算平台进⾏准实时的特征处理⼏乎成了当前推荐系统的标配。所谓流计算平台，是将⽇志以流的形式进⾏微批处理 mini batch ) 由于每次需要等待并处理⼀⼩批⽇志，流计算平台并⾮完全实时的平台，但它的优势是能够进⾏⼀些简单的统计类特征的计算，⽐如⼀个物品在该时间窗⼝内的曝光次数，点击次数、⼀个⽤户在该时间窗⼝内的点击话题分布，等等。
  流计算平台计算出的特征可以⽴刻存⼈特征数据库供推荐模型使⽤。虽然⽆法实时地根据⽤户⾏为改变⽤户结果，但分钟级别的延迟基本可以保证推荐系统能够准实时地引⼈⽤户的近期⾏为。
  3.分布式批处埋平台的全量特征处理
  随着数据最终到达以 HDFS 为主的分布式存储系统，Spark 等分布式批处理计算平台终于能够进⾏全量特征的计算和抽取了。在这个阶段着重进⾏的还有多个数据源的数据联结( join )及延迟信号的合并等操作。
  ⽤户的曝光、点击、转化数据往往是在不同时间到达 HDFS 的，有些游戏类应⽤的转化数据延迟甚⾄⾼达⼏个⼩时，因此只有在全量数据批处理这⼀阶段才能进⾏全部特征及相应标签的抽取和合并。也只有在全量特征准备好之后，才能够进⾏更⾼阶的特征组合的⼯作。这往往是⽆法在客户端和流计算平台上进⾏的。
  分布式批处理平台的计算结果的主要⽤途是:
  (1)模型训练和离线评估。
  (2)特征保存⼊特征数据库，供之后的线上推荐模型使⽤。
  数据从产⽣到完全进⼈ HDFS, 再加上 Spark 的计算延迟，这⼀过程的总延迟往往达到⼩时级别，已经⽆法进⾏所谓的“ 实时” 推荐，因此更多的是保证推荐系统特征的全⾯性，以便在⽤户下次登录时进⾏更准确的推荐。

5.3.3 推荐系统“ 模型” 的实时性

  与“ 特征” 的实时性相⽐，推荐系统 “ 模型” 的实时性往往是从更全局的⻆度考虑问题。特征的实时性⼒图⽤更准确的特征描述⽤户、物品和相关场景，从⽽让推荐系统给岀更符合当时场景的推荐结果。⽽模型的实时性则是希望更快地抓住全局层⾯的新数据模式，发现新的趋势和相关性。
  以某电商⽹站“ 双 1 1 ” 的⼤量促销活动为例，特征的实时性会根据⽤户最近的⾏为更快地发现⽤户可能感兴趣的商品，但绝对不会发现⼀个刚刚流⾏起来的爆款商品、⼀个刚刚开始的促销活动，以及与该⽤户相似的⼈群最新的偏好。要发现这类全局性的数据变化，需要实时地更新推荐模型。
  模型的实时性是与模型的训练⽅式紧密相关的，如图 5-8 所示，模型的实时性由弱到强的训练⽅式分别是全量更新、增量更新和在线学习（Online Learning )。

  1. 全量更新
  “全量更新” 是指模型利⽤某时间段内的所有训练样本进⾏训练。全量更新是最常⽤的模型训练⽅式，但它需要等待所有训练数据都“ 落盘” （记录在 HDFS等⼤数据存储系统中）才可进⾏，并且训练全量样本的时间往往较⻓，因此全量更新也是实时性最差的模型更新⽅式。与之相⽐，“ 增量更新” 的训练⽅式可以有效提⾼训练效率。
  2. 增量更新
  增量更新仅将新加⼈的样本“ 喂” 给模型进⾏增量训练。从技术上讲，深度学习模型往往采⽤随机梯度下降 ( SGD )法及其变种进⾏学习，模型对增量样本的学习相当于在原有样本的基础上继续输⼈增量样本进⾏梯度下降。增量更新的缺点是：增量更新的模型往往⽆法找到全局最优点，因此在实际的推荐系统中，经常采⽤增量更新与全局更新相结合的⽅式，在进⾏了⼏轮增量更新后，在业务量较⼩的时间窗⼝进⾏全局更新，纠正模型在增量更新过程中积累的误差。
  3.在线学习
  在线学习是进⾏模型实时更新的主要⽅法，也就是在获得⼀个新的样本的同时更新模型。与增量更新⼀样，在线学习在技术上也通过 SGD 的训练⽅式实现，但由于需要在线上环境进⾏模型的训练和⼤量模型相关参数的更新和存储，⼯程上的要求相对⽐较⾼。
  在线学习的另⼀个附带问题是模型的稀疏性不强，例如，在⼀个输⼈特征向量达到⼏百万维的模型中，如果模型的稀疏性好，就可以在模型效果不受影响的前提下，仅让极⼩⼀部分特征对应的权重⾮零，从⽽让上线的模型体积很⼩（ 因为可以摒弃所有权重为 0 的特征 ），这有利于加快整个模型服务的过程。但如果使⽤ SGD 的⽅式进⾏模型更新，相⽐ batch 的⽅式,容易产⽣⼤量⼩权重的特征,这就增⼤了模型体积，从⽽增⼤模型部署和更新的难度。为了在在线学习过程中兼顾训练效果和模型稀疏性，有⼤量相关的研究，最著名的包括微软的 FOBOS[1]⾕歌的 FTRL[2]等。
  在线学习的另⼀个⽅向是将强化学习与推荐系统结合，在 3.10节介绍的强化学习推荐模型 DRN 中，应⽤了⼀种竞争梯度下降算法，它通过 “ 随机探索新的深度学习模型参数，并根据实时效果反馈进⾏参数调整” 的⽅法进⾏在线学习，这是在强化学习框架下提⾼模型实时性的有效尝试。

  4.局部更新
  提⾼模型实时性的另⼀个改进⽅向是进⾏模型的局部更新，⼤致的思路是降低训练效率低的部分的更新频率，提⾼训练效率⾼的部分的更新频率。这种⽅式的代表是 Facebook 的“GBDT+LR” 模型。
  2.6 节已经介绍过 “GBDT+LR” 的模型结构，模型利⽤ GBDT 进⾏⾃动化的特征⼯程，利⽤ LR 拟合优化⽬标。GBDT 是串⾏的，需要依次训练每⼀棵树，因此训练效率低，更新的周期⻓，如果每次都同时训练 “GBDT+LR” 整个模型，那么 GBDT 的低效问题将拖慢 LR 的更新速度。为了兼顾 GBDT 的特征处理能⼒和 LR 快速拟合优化⽬标的能⼒，Facebook 采取的部署⽅法是每天训练⼀次GBDT 模型，固定 GBDT 模型后，实时训练 LR 模型以快速捕捉数据整体的变化。通过模型的局部更新，做到 GBDT 和 LR 能⼒的权衡。
  “ 模型局部更新” 的做法较多应⽤在 “Embedding 层+神经⽹络” 的深度学习模型中，Embedding 层参数由于占据了深度学习模型参数的⼤部分，其训练过程会拖慢模型整体的收敛速度，因此业界往往采⽤Embedding 层单独预训练，Embedding 层以上的模型部分⾼频更新的混合策略，这也是 “ 模型局部更新” 思想的⼜⼀次应⽤。
  5.客户端模型实时更新
  在本节介绍“ 特征” 实时性的部分，提到了客户端“ 实时特征” 的⽅法。既然客户端是最接近⽤户的部分，实时性最强，那么能否在客户端就根据当前⽤户的⾏为历史更新模型呢？
  客户端模型实时更新在推荐系统业界仍处于探索阶段。对于⼀些计算机视觉类的模型，可以通过模型压缩的⽅式⽣成轻量级模型，部署于客户端，但对于推荐模型这类“ 重量级” 的模型，往往需要依赖服务器端较强⼤的计算资源和丰富的特征数据进⾏模型服务。但客户端往往可以保存和更新模型⼀部分的参数和特征，⽐如当前⽤户的 Embedding 向量。
  这⾥的逻辑和动机是，在深度学习推荐系统中，模型往往要接受⽤户Embedding 和物品 Embedding 两个关键的特征向量。对于物品 Embedding 的更新，⼀般需要全局的数据，因此只能在服务器端进⾏更新；⽽对⽤户 Embedding 来说,则更多依赖⽤户⾃身的数据。那么把⽤户 Embedding 的更新过程移植到客户端来做，能实时地把⽤户最近的⾏为数据反映到⽤户的 Embedding 中来，从⽽可以在客户端通过实时改变⽤户 Embedding 的⽅式完成推荐结果的实时更新。
  这⾥⽤⼀个最简单的例⼦来说明该过程。如果⽤户 Embedding 是由⽤户点击过的物品 Embedding 进⾏平均得到的，那么最先得到⽤户最新点击物品信息的客户端，就可以根据⽤户点击物品的 Embedding 实时更新⽤户 Embedding , 并保存该 Embedding 在下次推荐时，将更新后的⽤户 Embedding 传给服务器，服务器端可根据最新的⽤户 Embedding 返回实时推荐内容。
  5.3.4 用 “ 木桶原理” 看待推荐系统的迭代升级
  本节介绍了提⾼推荐系统的 “ 特征” 实时性和“ 模型” 实时性的主要⽅法。由于影响推荐系统实时性的原因是多⽅⾯的，在实际的改进过程中，“ 抓住⼀点，重点提升” 是⼯程师应该采取的策略。⽽准确地找到这个关键点的过程就要求我们以 “ ⽊桶理论” 看待这个问题，找到拖慢推荐系统实时性的最短的那块⽊板，替换或者改进它，让 “ 推荐系统” 这个⽊桶能够盛下更多的 “ ⽔”。
  从更⾼的⻆度看待整个推荐系统的迭代升级问题，“ ⽊桶理论” 也同样适⽤。推荐系统的模型部分和⼯程部分总是迭代进⾏、交替优化的。当通过改进模型增加推荐效果的尝试受阻或者成本较高时，可以将优化的⽅向聚焦在⼯程部分，从⽽达到花较少的精⼒，达成更显著效果的⽬的。

5.4 如何合理设定推荐系统中的优化目标

  某知名互联⽹⼈物说过：“ 不要⽤战术上的勤奋掩盖战略上的懒惰”。这句话同样适⽤于技术的创新和应⽤。如果⼀项技术本身是新颖的、先进的，但应⽤的⽅向与实际需求的⽅向有偏差，那这项技术的成果不可能是显著的。在推荐系统中，如果你的推荐模型的优化⽬标是不准确的，即使模型的评估指标做得再好，也肯定与实际所希望达到的⽬标南辕北辙。所以，不要犯战略性的失误、合理设定推荐系统的优化⽬标是每位推荐⼯程师在构建推荐系统之前应该着重思考的问题。
  设定⼀个“ 合理” 的推荐系统优化⽬标，⾸先需要确⽴⼀个“ 合理” 的原则。对⼀家商业公司⽽⾔，在绝⼤多数情况下，推荐系统的⽬标都是完成某个商业⽬标，所以根据公司的商业⽬标来制定推荐系统的优化⽬标理应作为“ 合理” 的战略性⽬标。下⾯通过 YouTube 和阿⾥巴巴推荐系统的例⼦进⼀步说明这⼀点。

5.4.1 YouTube 以观看时长为优化目标的合理性

  1.1 节中，笔者就以 YouTube 推荐系统[3]为例，强调了推荐系统在实现公司商业⽬标增⻓过程中扮演的关键⻆⾊。
  YouTube 的主要商业模式是免费视频带来的⼴告收⼈，它的视频⼴告会阶段性地出现在视频播放之前和视频播放的过程中，因此 YouTube 的⼴告收⼈是与⽤户观看时⻓成正⽐的。为了完成公司的商业⽬标，YouTube 推荐系统的优化⽬标并不是点击率、播放率等通常意义上的 CTR 预估类的优化⽬标，⽽是⽤户的播放时⻓。
  不可否认的是，点击率等指标与⽤户播放时⻓有相关性，但⼆者之间仍存在⼀些“ 优化动机” 上的差异。如果以点击率为优化⽬标，那么推荐系统会倾向于推荐“ 标题党” “ 预览图劲爆” 的短视频，⽽如果以播放时⻓为优化⽬标，那么推荐系统应将视频的⻓短、视频的质量等特征考虑进来，此时推荐⼀个⾼质量的“ 电影” 或 “ 连续剧” 就是更好的选择。推荐⽬标的差异会导致推荐系统倾向性的不同，进⽽影响到能否完成 “ 增加⽤户播放时⻓” 这⼀商业⽬标。
  在 YouTube 的推荐系统排序模型 如图 5 9所示 ）中，引⼈播放时⻓作为优化⽬标的⽅式⾮常巧妙。YouTube 排序模型原本是把推荐问题当作分类问题对待的，即预测⽤户是否点击某个视频。
  既然是分类问题，理论上应很难预测播放时⻓ （预测播放时⻓应该是回归模型做的事情）。但 YouTube 巧妙地把播放时⻓转换成正样本的权重，输出层利⽤加权逻辑回归 （Weighted Logistic )进⾏训练，预测过程中利⽤算式e^Wx+b计算样本的概率 （Odds ) 这⼀概率就是模型对播放时⻓的预测（这⾥的论证并不严谨，在 8.3 节中还会进⼀步讨论 YouTube 排序模型的推断过程 ）。
  YouTube对于播放时⻓的预测符合其⼴告赢利模式和商业利益，从中也可以看出制定⼀个合理的优化⽬标对于实现推荐系统的商业⽬标是必要且关键的。

  相⽐视频类公司，对阿⾥巴巴等电商类公司来说，⾃然不存在播放时⻓这样的指标，那么阿⾥巴巴在设计其推荐系统优化⽬标时，考虑的关键因素有哪些呢？

5.4.2 模型优化和应⽤场景的统一性

  优化⽬标的制定还应该考虑的要素是模型优化场景和应⽤场景的统⼀性，在这⼀点上，阿⾥巴巴的多⽬标优化模型给出了⼀个很好的例⼦。
  在天猫、淘宝等电商类⽹站上做推荐，⽤户从登录到购买的过程可以抽象成两步：
  (1)产品曝光，⽤户浏览商品详情⻚。
  (2)⽤户产⽣购买⾏为。
  与 YouTube 等视频⽹站不同，对电商类⽹站⽽⾔，公司的商业⽬标是通过推荐使⽤户产⽣更多的购买⾏为。按照“ 优化⽬标应与公司商业⽬标⼀致” 的原则，电商类推荐模型应该是⼀个 CVR 预估模型。
  由于购买转化⾏为是在第⼆步产⽣的，因此在训练 CVR 模型时，直观的做法是采⽤点击数据+转化数据（图 5-10 中灰⾊和深灰⾊区域数据 ）训练 CVR 模型。在使⽤ CVR 模型时，因为⽤户登录后直接看到的并不是具体的商品详情⻚，⽽是⾸⻚或者列表⻚，因此 CVR 模型需要在产品曝光的场景（ 图 5-10中最外层圈内的数据 ）下进⾏预估。这就导致了训练场景与预估场景不⼀致的问题。模型在不同的场景下肯定会产⽣有偏的预估结果，进⽽导致应⽤效果的损失。

  这⾥当然可以换个思路解决问题，即针对第⼀步的场景，构建 CTR 预估模型；再针对第⼆步的场景，构建 CVR 预估模型，针对不同的应⽤场景应⽤不同的预估模型，这也是电商或⼴告类公司经常采⽤的做法。但这个⽅案的尴尬之处在于 CTR 模型与最终优化⽬标的脱节，因为整个问题最终的优化⽬标是 “ 购买转化”，并不是“ 点击”，在第⼀步过程中仅考虑点击数据，显然并不是全局最优化转化率的⽅案。
  为了达到同时优化 CTR 和 CVR 模型的⽬的，阿⾥巴巴提出了多⽬标优化模型 ESMM ( Entire Space Multi-task Model )[4]。ESMM 可以被当作⼀个同时模拟 “ 曝光到点击” 和 “ 点击到转化” 两个阶段的模型。
  从模型结构（ 如图 5-11)上看，底层的 Embedding 层是 CVR 部分和 CTR 部分共享的，共享 Embedding 层的⽬的主要是解决 CVR 任务正样本稀疏的问题，利⽤ CTR 的数据⽣成更准确的⽤户和物品的特征表达。
  中间层是 CVR 部分和 CTR 部分各⾃利⽤完全隔离的神经⽹络拟合⾃⼰的优化⽬标 pCVR (post-click CVR,点击后转化率 ）和 pCTR (post-view Click- through Rate, 曝光后点击率 ）。最终，将 pCVR 和 pCTR 相乘得到 pCTCVR。

  pCTCVR 指曝光后点击转化序列的概率。
  ESMM 同时将 pCVR、pCTR 和 pCTCVR 融合进⼀个统⼀的模型，因此模型可以⼀次性得出所有三个优化⽬标的值，在模型应⽤的过程中，也可以根据合适的应⽤场景选择与之相对应的⽬标进⾏预测。正因如此，阿⾥巴巴通过构建ESMM 这⼀多⽬标优化模型同时解决了“ 训练空间和预测空间不⼀致” 及“ 同时利⽤点击和转化数据进⾏全局优化” 两个关键的问题。
   ⽆论是 YouTube , 还是阿⾥巴巴，虽然他们的推荐系统的模型结构截然不同，但在设计推荐系统优化⽬标时，他们都充分考虑了真正的商业⽬标和应⽤场景，⼒图在训练模型的阶段“ 仿真” 预测阶段的场景和⽬标，这是读者在设计⾃⼰的推荐系统时⾸先要遵循的原则。

5.4.3 优化目标是和其他团队的接口性工作

  针对“ 优化⽬标” 这个话题，笔者想强调的第三点不是技术型问题，⽽是团队合作的问题。构建成功的推荐系统是⼀个复杂的系统性问题，不是技术团队能够独⽴完成的，⽽是需要产品团队、运营团队、内容编辑团队等协调⼀致，才能够共同达成推荐系统的商业⽬标。
  在协调的过程中，技术团队抱怨产品团队频繁修改需求，产品团队抱怨技术团队没有充分理解他们的设计意图，⼆者之间往往有结构性的⽭盾。如果找⼀个最可能的切⼊点，最⼤限度地解耦产品团队和技术团队的作，那么最合适的点就是推荐系统优化⽬标的设计。
  只有设定好合适的优化⽬标，技术团队才能够专⼼于模型的改进和结构的调整，避免把过于复杂晦涩的推荐系统技术细节暴露给外界。⽽产品团队也只有设定好合理的优化⽬标，才能让推荐系统服务于公司的整体商业利益和产品整体的设计⽬标。诚然，这个过程少不了各团队之间的⽭盾、妥协与权衡，但只有在动⼿解决问题之前协商好优化⽬标，才能在今后的⼯作中最⼤限度地避免战略性的错误和推诿返⼯，尽可能最⼤化公司的商业利益和各团队的⼯作效率。

5.5 推荐系统中⽐模型结构更重要的是什么

  本书之前的章节更多从技术的⻆度介绍了推荐系统的主要模型结构，以及Embedding 等深度学习推荐系统的主要技术点。本节希望与读者讨论的内容是：除了推荐模型结构等技术要点，有没有其他更重要的影响推荐系统效果的要素？

5.5.1 有解决推荐问题的“ 银弹’’ 吗

  笔者在与业界同⾏交流的过程中，经常会被问及“ 哪种推荐模型的效果更好”的问题。诚然，推荐系统的模型结构对于最终的效果来说是重要的，但真的存在⼀种模型结构是解决推荐问题的 “ 银弹” 吗？
  要回答这个问题，可以先分析⼀个模型——阿⾥巴巴 2019 年提出的推荐模型 DIEN。3.9 节曾详细介绍过 DIEN 模型，本节做简要回顾。DIEN 模型的整体结构是⼀个加⼈了 GRU 序列模型，并通过序列模型模拟⽤户兴趣进化过程。其中兴趣进化部分⾸先基于⾏为层的⽤户⾏为序列完成从物品 id 到物品Embedding 的转化，兴趣抽取层利⽤ GRU 序列模型模拟⽤户兴趣进化过程并抽取出兴趣 Embedding 向量，兴趣进化层利⽤结合了注意⼒机制的 AUGRU 序列模型模拟与⽬标⼴告相关的兴趣进化过程。
  笔者想强调的是，所有提出类似问题的同⾏都默认了⼀个前提假设，就是在阿⾥巴巴的推荐场景下能够提⾼效果的 DIEN 模型，在其他应⽤场景下应该同样有效。然⽽，这个假设真的合理吗？DIEN 模型是推荐系统领域的 “ 银弹” 吗？
  答案是否定的。
  做⼀个简单的分析，既然 DIEN 的要点是模拟并表达⽤户兴趣进化的过程，那么模型应⽤的前提必然是应⽤场景中存在着“ 兴趣进化” 的过程。阿⾥巴巴的场景⾮常好理解，⽤户的购买兴趣在不同时间点有变化。⽐如⽤户在购买了笔记本电脑后会有⼀定概率购买其周边产品；⽤户在购买了某些类型的服装后会有⼀定概率选择与其搭配的其他服装，这些都是兴趣进化的直观例⼦。
  DIEN 能够在阿⾥巴巴的应⽤场景有效的另⼀个原因是⽤户的兴趣进化路径能够被整个数据流近乎完整的保留。作为中国最⼤的电商集团，阿⾥巴巴各产品线组成的产品矩阵⼏乎能够完整地抓住⽤户购买兴趣迁移的过程。当然，⽤户有可能去京东、拼多多等电商平台购物，从⽽打断在阿⾥巴巴购物的兴趣进化过程，但从统计意义上讲，⼤量⽤户的兴趣进化过程还是可以被阿⾥巴巴的数据体系捕获的。
  所以，DIEN 模型有效的前提是应⽤场景满⾜两个条件:
  (1)应⽤场景存在 “兴趣的进化”。
  (2)⽤户兴趣的进化过程能够被数据完整捕获。
  如果⼆者中有⼀个条件不成⽴，那么 DIEN 模型就很可能不会带来较⼤的收益。
  以笔者比较熟悉的视频流媒体推荐系统为例，在⼀个综合的流媒体平台（ ⽐如智能电视 ）上，⽤户既可以选择⾃⼰的频道和内容，也可以选择观看 Netflix、YouTube,或者其他流媒体频道的内容（ 图 5-12所示为流媒体平台不同的频道列表 ）。⼀旦⽤户进⼈ Netflix 或者其他第三⽅应⽤，我们就⽆法得到应⽤中的具体数据。在这样的场景下，系统仅能获取⽤户⼀部分的观看、点击数据，抽取出⽤户的兴趣点都是不容易的，谈何构建⽤户的整个兴趣进化路径呢？即使勉强构建出兴趣进化路径，也是不完整、甚⾄错误的路径。

  基于这样的数据特点，DIEN 还适合成为推荐模型的主要架构吗？答案是否定的。DIEN 模型并不能反映业务数据的特点和⽤户动机，如果在此场景下仍把模型效果不佳的主要原因归咎于参数没调好、数据量不够⼤，⽆疑有舍本逐末的嫌疑。相⽐这些技术原因，理解⾃⼰的⽤户场景，熟悉⾃⼰的数据特点才是最重要的。
  到这⾥也基本可以给出题⽬中问题的答案了⼀在构建推荐模型的过程中，从应⽤场景出发，基于⽤户⾏为和数据的特点，提出合理的改进模型的动机才是最重要的。
  换句话说，推荐模型的结构不是构建⼀个好的推荐系统的 “ 银弹”，真正的“ 银弹” 是你对⽤户⾏为和应⽤场景的观察，基于这些观察，改进出最能表达这些观察的模型结构。下⾯⽤三个例⼦对这句话做进⼀步的解释。

5.5.2 Netflix 对⽤户⾏为的观察

  Netflix 是美国最⼤的流媒体公司，其推荐系统会根据⽤户的喜好⽣成影⽚的推荐列表。除了影⽚的排序，最能影响点击率的要素其实是影⽚的海报预览图。举例来说，⼀位喜欢⻢特 达蒙（美国著名男影星 ）的⽤户，当看到影⽚的海报上有⻢特达蒙的头像时，点击该影⽚的概率会⼤幅增加。Netflix 的数据科学家在通过 A/B 测试验证这⼀点后，着⼿开始对影⽚预览图的⽣成进⾏优化（如图5-13所示 ）[5]，以提⾼推荐结果整体的点击率。

  在具体的优化过程中，模型会根据不同⽤户的喜好，使⽤不同的影⽚预览图模板，填充以不同的前景、背景、⽂字等。通过使⽤简单的线性“探索与利⽤”( Exploration&Exploitation )模型验证哪种组合才是最适合某类⽤户的个性化海报。
  在这个问题中，Netflix 并没有使⽤复杂的模型，但 CTR 提升的效果是 10%量级的，远远超过改进推荐模型结构带来的收益。这才是从⽤户和场景出发解决问题。这也符合 5.3 节提出的 “ ⽊桶理论” 的思想，对推荐系统效果的改进，最有效的⽅法不是执着地改进那块已经很⻓的⽊板，⽽是发现那块最短的⽊板，提⾼整体的效果。

5.5.3 观察⽤户⾏为，在模型中加⼊有价值的⽤户信息

  再举⼀个例⼦，图 5-14是美国最⼤的 Smart TV(智能电视 ）平台 Roku 的主⻚，每⼀⾏是⼀个类型的影⽚。但对⼀个新⽤户来说，系统⾮常缺少关于他的点击和播放样本。那么对 Roku 的⼯程师来说，能否找到其他有价值的信息来解决数据稀疏问题呢？

  这就要求我们回到产品中，从⽤户的⻆度理解这个问题，发现有价值的信号。针对该⽤户界⾯来说，如果⽤户对某个类型的影⽚感兴趣，则必然会向右滑动⿏标或者遥控器（ 如图 5-14中红⾊箭头所指 ），浏览这个类型下其他影⽚，这个滑动的动作很好地反映了⽤户对某类型影⽚的兴趣。
  引⼊这个动作，⽆疑对构建⽤户兴趣向量，解决数据稀疏问题，进⽽提⾼推荐系统的效果有正向的作⽤。⼴义上讲，引⼊新的有价值信息相当于为推荐系统增加新的 “ ⽔源”，⽽改进模型结构则是对已有 “ ⽔源” 的进⼀步挖掘。通常，新⽔源带来的收益更⾼，开拓难度却⼩于对已有⽔源的持续挖掘。

5.5. 4 DIN 模型的改进动机

  回到阿⾥巴巴的推荐模型。3.8 节曾详细介绍过 DIEN 模型的前身是 DIN,其基本思想是将注意⼒机制跟深度神经⽹络结合起来（如图 3-24所示）。
  简单回顾 DIN 的原理，DIN 在经典的深度 CTR 模型的基础上，在构建特征向量的过程中，对每⼀类特征加⼈⼀个激活单元，这个激活单元的作⽤类似⼀个开关，控制了这类特征是否放⼈特征向量及放⼊时权重的⼤⼩。那这个开关由谁控制呢？它是由被预测⼴告物品跟这类特征的关系决定的。也就是说，在预测⽤户 u 是否喜欢物品 i 这件事上，DIN 只把跟物品 i 有关的特征考虑进来，其他特征的⻔会被关上，完全不考虑或者权重很⼩。
  那么，阿⾥巴巴的⼯程师能够提出将注意⼒机制应⽤于深度神经⽹络的想法是单纯的技术考虑吗？
  笔者曾与 DIN 论⽂的作者进⾏过交流,发现他们的出发点同样是⽤户的⾏为特点。天猫、淘宝作为综合性的电商⽹站，只有收集与候选物品相关的⽤户历史⾏为记录才是有价值的。基于这个出发点，引⼈相关物品的开关和权重结构，最终发现注意⼒机制恰巧是能够解释这个动机的最合适的技术结构。反过来，如果单纯从技术⻆度出发，为了验证注意⼒机制是否有效⽽应⽤注意⼒机制，则有“ 本末倒置” 的嫌疑，因为这不是业界解决问题的常规思路，⽽是试探性的技术验证过程，这种纯“ 猜测” 型的验证⽆疑会⼤幅增加⼯作量。

5.5.5 算法⼯程师不能只是⼀个“ 炼⾦术⼠”

  很多算法⼯程师把⾃⼰的⼯作戏称为“ 调参师” “ 炼⾦术⼠”，在深度学习的场景下，超参数的选择当然是不可或缺的⼯作。但如果算法⼯程师仅专注于是否在⽹络中加 dropout, 要不要更改激活函数（activation function ), 需不需要增加正则化项，以及修改⽹络深度和宽度，是不可能做出真正符合应⽤场景的针对性改进的。
  很多业内同仁都说做推荐系统就是“ 揣摩⼈⼼”，这句话笔者并不完全赞同,但这在⼀定程度上反映了本节的主题⼀从⽤户的⻆度思考问题，构建模型。
  如果阅读本书的你已经有了⼏年⼯作经验，对机器学习的相关技术已经驾轻就熟，反⽽应该从技术中跳出来，站在⽤户的⻆度，深度体验他们的想法，发现他们想法中的偏好和习惯，再⽤机器学习⼯具去验证它、模拟它，会得到意想不到的效果。