图片来源：unsplash.com/photos/ooZf…

作者：TrainableLu，左冯翊

0. 引言

直播是一种高即时，强互动的内容展示办法，一般在主播向观众传达内容的一起与观众进行互动。在泛娱乐直播产品中，直播满意了用户寻求陪伴，娱乐消遣、打发时刻的需求，一起也满意了主播完成盈利和取得重视认可的需求。 iiMedia Research（艾媒咨询）数据显现，2020 年我国在线直播用户规划为 5.87 亿人，估计未来继续保持添加态势，2022 年用户规划将达 6.6 亿人。艾媒咨询剖析师以为，电竞、电商、教育等新形状直播内容兴起为职业注入新的发展活力。各大平台活跃推进直播与其他类型相结合，也使更多内容形状呈现，吸引更广泛的用户群体。（数据来源：2020-2021我国在线直播职业年度研究报告）

云音乐播放页直播推荐实战
LOOK 直播是网易云音乐旗下一款主打音频直播的直播软件，依托网易云音乐的音乐人生态，为用户打造最具音乐特色的直播新体验。LOOK 直播不仅有独立的 APP，在云音乐 APP 也有多个进口。 本文以歌曲播放页直播进口为例，介绍云音乐直播特性化引荐的实践，包含以下几个部分：

  • 事务布景。介绍 Look 直播在云音乐 APP 的产品形状，以及算法引荐的方针。
  • 事务应战。介绍直播引荐事务的特色，以及咱们遇到的应战。
  • 实时引荐。介绍实时引荐的计划，包含流式样本、样本归因和增量练习。
  • 多方针交融。介绍多方针交融，包含 ESMM、MMoE 和 Loss 交融。
  • 多模态探究。介绍咱们在直播引荐多模态探究方面的一些发展。

1. 事务布景

LOOK 直播依托于云音乐 APP，有着丰厚的流量进口以及各式各样的展示办法，不同进口的产品功能和用户心智存在较大的差异。如图 1 所示，是云音乐直播在首页、歌曲播放页、谈论页的产品形状。除了这 3 个流量比较大的进口，云音乐直播还有搜索综合页、我的页面和更多页等进口。

云音乐播放页直播推荐实战
在实践引荐的进程中，咱们期望除了满意用户自身在内容消费上的需求以外，咱们更期望能够去推进用户和主播产生更多的互动。在事务方针上，咱们会重视 CTR、观看时长这样的内容项的方针；一起，也会考虑社交联系达到方面的方针，如重视转化；别的，云音乐直播自身也承担了比较重要的营收功能，因而付费转化为代表的营收方针同样是要点。除此之外，咱们还会从整个生态的角度来统筹生产者（主播侧）和顾客（用户侧)的留存问题。

2. 事务应战

歌曲播放页直播进口（也称直播播放页）是 Look 直播在云音乐最大的一个流量进口，它的方位十分特别：坐落歌曲播放页的右上角。因而，歌曲播放页直播引荐不仅有着直播引荐的共性，也有着自己的特性。 咱们先来看看直播引荐的一些共性。

  • 实时改变 直播引荐和产品引荐等场景有一个比较大的差异是，直播引荐的对象（即主播）是动态的、有片面认识的，主播的情感表达等表现是会影响直播间的功率的。直播是长时刻连续性的，内容会实时改变，比方主播或许在这个时刻唱歌，在下一个时刻就谈天，如果某些用户喜欢看跳舞直播，那么当主播不跳的时分，他们或许就退出了。如图所示，同一个主播，在不同的时刻段功率差别比较大。关于这个问题，咱们将在第 3 节「实时引荐」讲述怎么处理这个问题。
    云音乐播放页直播推荐实战
  • 多方针 多方针由事务驱动。在电商场景，咱们期望推出的产品，用户不仅点击而且购买，如果能谈论共享就更好了。在直播场景，咱们期望推出的主播，用户不仅点击而且有用观看，如果能打赏就更好了。在云音乐直播场景，咱们能够优化的方针有点击、观看、送礼和谈论等，考虑到不同方针之间的相互影响，模型的首要优化方针是点击和有用观看（观看超过 30 秒）。在第 4 节「多方针交融」，咱们将讲述怎么经过多使命模型来平衡不同方针的相互影响。
  • 多模态 直播引荐给用户引荐的是主播，但不仅仅是主播。实践上，咱们给用户引荐的是一个直播间，包含直播间的进口案牍、主播头像、主播自身等。直播案牍和主播头像是吸引用户点击直播间的重要因素，用户进入到直播间后，直播内容是促进用户转化的重要因素。因而，咱们需求对多模态的内容进行了解、交融，包含但不限于：
  1. 文本（如直播案牍、直播间弹幕等）
  2. 图片（如主播头像、封面等）
  3. 视频（如辨认主播是否在跳舞、挂机等）
  4. 音频（如辨认主播是否在唱歌，在唱什么类型的歌等） 针对这个问题，咱们将在第 5 节「多模态探究」讲述咱们在多模态方面的一些探究。 上面讲了直播引荐的一些共性，接下来咱们看看歌曲播放页直播引荐的特性。
  • 只要一个展示位，且展示素材面积较小（头像尺寸半径只要 45px） 在产品或许信息流等列表式引荐场景，用户一次恳求就能带来几条曝光，射中用户兴趣点的概率较大，而在歌曲播放页直播场景，用户一次恳求只能曝光一条，射中用户兴趣点的概率比较小了许多。 别的，用户不太简略感知到歌曲播放页右上角有一个引荐位，而且不同的主播只能靠一个小头像和短案牍去辨认，特性化相对较弱。因而，除了优化 Rank 模型，咱们还需求在展示物料的款式和形状上面做一些优化。
  • 新用户在有用观看用户和有用观看次数中占比大 这里新用户的定义是：曩昔 30 天内未有用观看的用户。咱们对直播用户进行了分层：新用户、活跃用户和付费用，经剖析发现，新用户在有用观看用户的占比，以及在有用观看次数的占比，都达到了 XX% 以上。从模型的角度来剖析，也便是，大部分样本覆盖的用户都是新用户，他们的直播行为不丰厚，这样就会导致模型的特性化才干比较弱（简略给新用户推热门主播），也不可避免地会加重该场景的马太效应。
    云音乐播放页直播推荐实战

3. 实时引荐

如果把引荐体系简略地看成是一个排序函数 f(x)，那么能够把实时性拆成两点：

  • 输入 x 实时
  • 模型 f 实时 其间，输入 x 实时，也便是特征实时，能够依据时效性分为三个粒度：
  • 毫秒级特征：依托客户端在恳求中填入时刻、地点、场景等上下文特征
  • 秒/分钟级特征：依托流式核算，做一些简略的核算类特征的核算和聚合用户行为反应数据等，比方核算主播在某个时刻窗口的点击次数等
  • 小时级特征：依托离线核算，能够进行更高阶的特征组合的工作，比方核算用户在某个时刻窗口对主播标签的转化率散布情况等 而模型 f 实时，能够拆解为：
  • 练习数据流式生成：曝光流、点击流等和各类行为数据实时接入，流式相关特征数据，生成练习样本
  • 增量学习/在线学习：练习数据随着时刻的推移源源不断地加入到当时练习流程中，以增强当时模型的拟合才干。增量学习往往在取得一批新样本后再进行练习更新，而在线学习则是在每次取得一个新样本的时分就实时更新模型 这里咱们要点介绍下贱式样本、增量学习的详细做法。

3.1 流式样本

咱们与实时核算组协作，最早将依据 snapshot 的实时样本在直播播放页落地，较好地处理了线上线下特征不一致、实时特征简略导致穿越等问题。经过不断地完善与优化，现在这套结构已应用于直播的各个场景、播客等各事务，取得了不错的作用。 下面咱们以直播播放页为例，对这套结构做一个介绍。（注：或许跟现在最新的结构有所收支，但中心思想根本一致）

云音乐播放页直播推荐实战
全体事务流程如下： （1）线上预估恳求所用到的原始特征在旁路环境 dump 到 kafka，经过 flink 解析，依照一个格局写入 kv （2）Flink 使命 1：将埋点与 snapshot 进行拼接

  • 将 traceid，userid，itemid 和曝光转化(曝光为 0，转化为 1）拼成一个 key 写入 redis，供后面的正负样本符号运用

  • 用曝光、转化去相关 kv 中的 snapshot，将能相关上的成果写入拼接成功的 kafka，相关不上的成果写入拼接失利的 kafka （3）Flink 使命 2：进行兜底样本拼接。消费拼接 snapshot 失利的 kafka，去特征 tair 集群拿相应特征生成 snapshot，并将成果写入拼接成功的 kafka （4）Flink 使命 3：进行正负样本拼接

  • 消费拼接成功的 kafka，数据推迟 M 分钟处理（这里的 M 怎么设置，在下一节 样本归因 介绍）

  • 当来了一条曝光样本，咱们去 Redis 查找是否有对应的转化行为，如果能查到，就丢弃当时曝光样本，否则符号当时曝光样本为负样本(label=0)

  • 当来了一条转化样本，则直接符号为正样本(label=1)

  • 别的，为了处理埋点重复上报的问题，咱们能够这样做，当来了一条曝光样本，咱们用 traceid_userid_itemid_0 去 Redis 查找该 key，判别对应的 value 是否为 1，如果是则过滤掉该样本，否则修正其 value 为 1；转化样本同理

  • 将上面拼接后的数据写入 kafka（5）Flink 使命 4：消费 kafka 的样本数据，进行特征抽取、格局处理，并写到 HDFS

该计划具有以下长处：

  • 正负样本实时拼接，能够支撑实时性要求高的事务需求
  • 有兜底模块，在旁路环境或 snapshot 等反常情况下，能够最大补全 snapshot 特征
  • 整个样本拼接流程都在流里完结，只要最终运用环节才落地 hdfs，避免了 flink 频繁写 hdfs

3.2 样本归因

样本归因即对样本赋予 ground truth，咱们知道，转化是有推迟的，即在点击产生往后一段时刻用户或许才会产生转化，且往往转化漏斗越深，推迟的时刻越长。 那么，在对流式样本进行归因的时分，就会遇到实时性和准确性 trade-off 的问题。一方面，咱们需求样本尽或许实时，可是有些事情的 label 或许还没回流，如果此时把样本喂给模型练习，就会导致模型预估不准；另一方面，如果要等候事情的 label 完全回流再练习，比方说事情的真实 label 能在一天内完全回流，也便是咱们常见的天级练习，但此时样本就不实时了。

上述问题也被概括为一个推迟反应（delayed feedback）的问题。下面咱们介绍几种处理计划。 (1）运用 Flink 进行推迟处理。首要咱们要确定两个数据流相关的时刻窗口，咱们会经过离线的办法对两份数据在不同的时刻范围内做 join，以此判别在线需求的时刻窗口。比方事务接受的最低相关比例是 95%，而且经过离线测验确认 20 分钟内两个数据流能够相关 95% 的数据，那么就能够用 20 分钟作为时刻窗口。这里的相关比例和窗口时刻便是在准确性和实时性之间做一个 trade-off。现在直播播放页便是选用这种办法。 (2）不运用推迟处理的办法，而让负样本和正样本都去更新模型，这种实时性最高。这样做的话，流式样本就会呈现 False Negative 样本，但咱们能够经过 Importance Sampling 对样本加权、False negative calibration 和 Positive-Unlabeled Learning 的办法来近似学习一个无偏的数据散布。详细细节能够参考 Twitter 发的一篇 paper《Addressing Delayed Feedback for Continuous Training with Neural Networks in CTR prediction》。 (3）不运用推迟处理的办法，而对推迟时刻（点击行为和转化行为的时刻间隔）进行建模。著名广告公司 criteo 发表了一篇论文《Modeling Delayed Feedback in Display Advertising》就介绍了这种办法，它的首要思想是关于还未观察到转化的样本，不直接将其当做负样本，而是考虑 click 产生的时刻距离当时时刻的长短，给予模型不同大小的梯度。它选用两个模型进行建模，第一个模型用于猜测用户产生转化的概率，即转化率模型；第二个模型用于猜测用户产生转化的情况下，推迟时刻（点击行为和转化行为的时刻间隔）的概率。

3.3 增量练习

增量练习并非一向增量，而是合作全量练习，因为如果一向运用增量模型，时刻长了会产生必定的误差，误差累积效应会影响线上作用，因而，经过定期的全量更新进行矫正是必须的。 如图所示，左面是分钟级的流式样本，经过练习，增量地对模型进行更新；右边是经过全量样本对模型进行全量的 full-batch 更新。

云音乐播放页直播推荐实战
别的，在增量练习进程中，咱们还会遇到如下问题：

  • 低频的特征进入模型练习，会导致模型预估成果不相信。这种情况需求咱们对特征设置准入规则，比方设置特征频次过滤掉低频特征，或许对低频特征施加比较大的正则项等进行处理
  • 特征规划一向在添加，会给线上预估性能和机器内存带来压力。这种情况需求咱们对特征进行筛选，比方筛选长时刻未更新的特征、筛选 L1 正则项很小的特征等

3.4 事务作用

  • 在直播播放页场景下，依据 snapshot 模型，5min 更新模型，相关于对照组，均匀点击率进步 3.15%，均匀有用观看率进步 2.52%
  • 在首页直播场景下，依据 snapshot 模型，T8 组 15min 更新模型，相关于对照组，均匀点击率进步 6.57%，有用观看率进步 5.06%

4. 多方针交融

直播引荐是一个典型的多方针场景，在一个用户的行为途径中，会经过点击、观看、重视和打赏等进程，而且不同行为的产生有先后顺序和依靠联系。比方，当用户在歌曲播放页的时分，如果点击右上角的直播进口，这时产生点击行为，点击之后会进入到直播间，这时会产生观看行为，观看一段时刻后会有必定概率产生各种互动行为。用户的每一种行为都能够成为多方针模型里的一个方针，那么怎么建模呢？现在业界首要有以下几种办法：

  • 分隔建模。这种办法关于每一个事务方针，单独练习一个模型，线上经过组合多个模型输出决定终究排序。这种办法的长处是分隔迭代，各司其职，关于单一模型，迭代速度会更快。而缺陷也很明显，因为各个方针独立拟合，方针之间的依靠联系信息就会丢掉，各使命之间无法共享信息，资源运用也较多，方针一旦变多保护也比较困难。
  • 联合建模。这种办法经过一个模型一起练习多个方针，线上进行多方针交融。这种办法的长处是各个使命之间能够共享信息，一致迭代方便，节省资源；缺陷是模型较为杂乱，各使命之间或许相互影响，模型精度或许会有所损失，影响迭代速度。
  • 样本加权。这种办法经过修正样本权重来体现方针的重要性，比方在点击模型里边运用时长加权、完播率加权等。这种办法的长处是简略，易于快速上线，缺陷是迭代灵活性不行。
  • LTR（Learning To Rank）。经过 LTR 的办法来对多方针建模，比方 Lambda MART 算法。这种办法的长处是直接优化排序方针，排序作用较好，缺陷是需求结构期望排序的样本对，样本数量大，而且有些偏序联系不简略结构，多方针之间的联系也不易调整。 现在，直播播放页的模型方针首要有点击和有用观看（观看超过 30 秒），为此，咱们尝试过分隔建模和联合建模两种办法，考虑到资源运用和保护成本等因素，咱们当时的多方针模型都是联合建模。关于多方针联合建模，咱们首要尝试了 ESMM 和 MMoE 两种模型，下面咱们别离介绍这两种模型。

4.1 ESMM + FM

ESMM 模型是 阿里妈妈团队 2018 年发表在 SIGIR 上的一篇论文《Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate》，文章依据 Multi-Task Learning 的思路，首要为了处理 CVR 预估碰到的两个关键问题：

  • 数据稀少（Data Sparsity）。CVR 模型的练习样本量远小于 CTR 模型的练习样本量。
  • 样本挑选误差（Sample Selection Bias）。传统 CVR 模型通常以点击数据为练习集，其间点击未转化为负例，点击且转化为正例。可是练习好的模型在线上运用时，则是对整个空间的样本进行预估，而非只对点击样本进行预估。也便是说，练习数据与实践猜测的数据来自不同散布，这个误差对模型的泛化才干构成了很大应战。 下面，咱们看 ESMM 模型怎么处理这两个问题。 ESMM 的网络结构如图所示：
    云音乐播放页直播推荐实战
    1）为了处理数据稀少的问题，ESMM 运用了共享 Embedding，CVR 使命和 CTR 使命运用相同的特征和特征 Embedding。 2）为了处理样本挑选误差的问题，ESMM 并没有直接运用 点击->转化 样本学习 CVR，而是经过 曝光->点击 和 曝光 -> 转化 样原本隐式地学习 CVR。在咱们的场景，咱们需求建模的方针是点击和有用观看，这两个方针涉及到的联系能够被描绘为：
    云音乐播放页直播推荐实战
    能够看到，pCTR 和 pCTCVR 这两个使命运用的是整个空间的样本，它们有显式的监督信号，而 pCVR 节点只是网络结构中的变量，它没有显式的监督信号。 3）ESMM 的方针函数如下
    云音乐播放页直播推荐实战
    总结起来，便是 ESMM 经过 CTCVR 和 CTR 的监督信息来练习网络，隐式地学习 CVR。 在实践运用进程中，为了提取高阶组合特征，咱们做了两个如下改动：
  1. 添加了一些手动结构的交叉特征，以此进步模型的回忆才干
  2. 在原有 ESMM 网络结构基础上添加了 FM 模块 全体网络结构如下：
    云音乐播放页直播推荐实战
    在方针交融阶段，咱们对多个方针选用带权乘积交融(取 log)：final_score = m * log(ctr + 0.00001) + n * log(cvr + 0.00001) 的办法进行交融打分，经过 m 和 n 的权重操控，来调整模型偏向于ctr 还是 cvr，以符合不同阶段的事务需求。 选用经过改造的 ESMM 模型后，相关于基线(CTR、CVR 分隔建模)，CTR 进步 7.1%，CTCVR 进步 6.4%。

4.2 MMoE

ESMM 模型实践是一种 shared-bottom 的结构，不同使命间共享底部的隐层，然后再依据使命的个数区分出多个 tower network 来别离学习不同的方针。这种结构能够减少过拟合的危险，可是如果使命之间相关性较低，模型的作用相对会较差。 为了处理使命之间相关度下降导致模型作用下降的问题，google 在 MoE（Mixture-of-Experts）的基础上进行了改善，提出了 MMoE：《Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts》，引入了多个 Gate 来操控不同使命不同 Expert 的权重。MMoE 的全体结构如图所示：

云音乐播放页直播推荐实战
如图所示，Gate 通常是一个线性模型 + softmax，而 Expert 通常是 DNN 等。 MMoE 与 ESMM 模型的不同点首要有：

  1. 使命底层不是 shared-bottom 结构，而是经过多个 Expert 来学习不同的特征
  2. 引入与使命个数相同的门控网络（gating network），每个使命的 gating network 经过输出不同的权重完成对 experts 的挑选性使用（加权求和）。不同使命的 gating network 能够学习到不同的 experts 的组合模式，即吸收 expert 信息的侧要点不同，因而模型捕捉到了不同使命的相关性和差异 将上面的网络结构转换成公式，表明如下：
    云音乐播放页直播推荐实战
    经过试验，MMoE 比较 ESMM+FM 模型，CTR 根本持平，CTCVR 进步 1.5% 。

4.3 Loss 交融

关于多使命学习，存在一个问题：不同使命的数据散布、重要性往往不一样，那么多个使命的 loss 怎么交融？最简略的办法，便是将各个使命的 loss 直接相加： loss = loss(task1) + loss(task2) 这种直接相加的办法存在以下几个问题：

  • 不同使命 loss 梯度的量级不同，或许会导致练习进程被某个使命主导或学偏
  • 不同使命收敛速度不一致，或许导致有些使命还处于欠拟合，而有些使命已经过拟合 咱们对上述交融办法进行简略地调整，对每个使命的 loss 设置一个超参数，如下： loss = w_1 * loss(task1) + w_2 * loss(task2) 这种加权交融的办法允许咱们人为调整每个使命的重要性程度，可是也存在一些问题：
  • 各使命在练习进程中自己的梯度量级和收敛速度也是动态改变的，咱们这里设置的超参数会一向伴随整个练习周期
  • 固定的权重设置或许会限制使命的学习，比方使命 A 接近收敛，而使命 B 还处于欠拟合
  • 超参数依靠人为屡次调参，才干找到一个相比照较好的参数

那么多使命学习中，怎么更好地对不同使命 Loss 进行交融呢？

咱们把多使命模型的损失函数记为：

云音乐播放页直播推荐实战
那么关于共享参数 W_sh 在梯度下降优化时：
云音乐播放页直播推荐实战
从上面的表达式能够看出：

  • loss 大则梯度更新量也大
  • 不同使命的 loss 差异大导致模型更新速度不平衡的本质原因在于梯度大小
  • 经过调整不同使命的 loss 权重能够改善这个问题
  • 经过对不同使命的梯度进行处理也能够改善这个问题 因而，交融办法大体分为两类：
  • 在权重 w_i 上做文章
  • 在梯度上做文章 在咱们的场景，咱们尝试了人工设置 loss 超参和梯度归一化（GradNorm）两种办法。GradNorm 的中心思路首要有两点：
  • 期望不同使命对应的 Loss 量级接近
  • 期望不同使命以附近的速度进行学习 GradNorm 自身不聚焦于不同使命之间的权重，而是将一切使命等同视之，它期望不同使命的更新速度能够相对接近，然后避免了某个使命收敛了，某个使命还在收敛的路上的问题。 经过试验，在咱们的场景，依据 GradNorm 的 Loss 交融办法比较人工设置超参的办法，CTR 进步 0.6%，CTCVR 进步 0.4%。

5. 多模态探究

直播引荐实践上是一个多模态的引荐，首要呈现在用户面前的是案牍和主播头像，除了向用户引荐特性化的主播，关于进口款式，咱们也应该做到千人千面。直播产品形状呈现多款式、多物料（案牍、头像）组合形状，对 CTR 预估提出了巨大的应战。 别的，因为主播每次替换头像和案牍，都会导致主播的数据散布呈现剧烈的变动（CTR或许会相差好几倍）。针对这个问题，现在咱们有两个处理计划：

  1. 经过实时的特征和模型来捕捉这种数据散布的快速改变（即前文的实时引荐）
  2. 使用模型操控主播的头像与案牍来下降这种数据散布的改变，如果主播的新头像、案牍不优于前史的内容，模型能够主动的将内容替换为旧的内容，一起经过扩展主播的头像、案牍候选集，进步主播的点击率上限。 依据第 2 点，咱们将仅关于Item（主播）进行排序的引荐计划，逐渐改造为针对<主播、案牍、头像>三元组进行排序，在播放页直播的实践进程中取得了十分好的作用。

5.1 案牍、头像优选

在改造初期，咱们别离针对头像和案牍进行了试验来验证计划的可行性，首要计划如下：

  • 经过添加通案牍、主播前史头像来扩展主播的案牍、头像候选集
  • 区分必定的流量来对新案牍、头像进行Explore
  • 然后经过离线核算的办法，核算不同案牍、头像的CTR、CTCVR数据
  • 最终依据核算数据对主播的案牍、头像进行轮询 如下图所示，赤色为优选流程。
    云音乐播放页直播推荐实战
  • 针对主播头像，因为头像与主播相关性较强，许多用户是经过头像对主播树立的感知，一切咱们没有运用主播自身头像以外的数据，只选取了主播的前史头像作为候选集。
  • 针对主播案牍，可选的扩展内容则更为丰厚，除了一些通用的案牍之外，主播有较为丰厚的标签，针对主播的性别、年纪，是否在唱歌、跳舞、ACG主播等等特征，都能够添加相应的扩展案牍，除了添加案牍的丰厚度外，能够细粒度的将案牍和直播间内容进行匹配，出了直接进步CTR之外，关于CVR的进步也是有利的。
  • 经过该流程的实践，案牍优选在播放页、首页均取得了十分好的作用.

5.2 案牍模型+案牍投进体系

在案牍优选的实践进程中咱们也发现了许多问题：

  • 案牍量少、无法继续产出高效案牍，继续追踪热门，构成持久的高收益，扩展案牍实践只要20多个

  • 主动化程度不行（一切的案牍均是经过硬编码在体系中，十分不灵活），每次更新都要线上发布

  • 案牍需求经过优先级来操控（通用案牍和一些活动案牍有冲突） 针对以上问题，咱们将整个流程进行优化，如下图所示。

    云音乐播放页直播推荐实战

  • 在案牍的产出阶段，咱们引入了产品/策划作为案牍的生产者，产出优秀的案牍加入引荐的案牍池

  • 使用案牍模型来完成案牍的特性化引荐

  • 经过离线作用核算，以图形化界面的办法给产品/策划产出每天的数据反应

  • 产品/策划经过数据总结规律，来继续产出优秀的案牍，构成整个优化的闭环 1）依据此，咱们构建了案牍体系2.0，让产品、策划能够经过Web页面装备的办法，方便的上传、修正案牍，一起支持20多种不同的装备特色来完成案牍的定向投进，一切特色如下所示。

    • 用户：性别、年纪、城市等级
    • 主播：性别、年纪、特定主播、开播标签、算法标签、直播类型、是否发红包、直播间类型
    • 上下文：场景、小时、是否周末、是否节假日、是否活动、开始时刻、结束时刻。比方能够针对聊愈主播，在晚间22：00-02:00点之间投进某种案牍，针对五一、十一等特别节假日期间投进各种案牍。

    2）具有丰厚的案牍池后，继续经过简略核算的办法来投进明显不是最优的挑选。案牍模型能够主动的的进行案牍特性化投进，一起能够将一切类型的案牍进行一致处理，依照案牍的优化方针（而不是人为规则）进行投进。 3）案牍的作用核算如下图，经过不同的案牍作用比照，产品/策划能够了解用户关于不同案牍的喜欢程度，然后产出新的案牍

    云音乐播放页直播推荐实战

经过案牍模型+丰厚案牍池+数据反应，咱们拿到了十分好的作用。

5.3 主播案牍交融模型

在当时引荐链路中，案牍和主播的排序是分隔。咱们知道两个局部最长处的功率总是小于等于大局最长处的，由此咱们展开了下一阶段的优化，将Item（主播）和案牍进行交融排序，流程图如下。

云音乐播放页直播推荐实战

  1. 在主播召回的成果后，针对每个主播进行案牍召回
  2. 针对〈主播、案牍〉的pair对进行交融排序
  3. 最终获取Top1主播的优选头像进行引荐

在试验进程中，咱们将主播和对应的案牍候选池进行笛卡尔积操作后再使用精排模型进行排序，因为排序数量的上升，精排集群的资源使用率急剧上升，现有的机器无法进行全量布置。咱们剖析后发现以下问题：

  • 排序的粒度为<主播、案牍>，导致数据传输、解析和回包的数量量也急剧上升
  • 每个主播有多个案牍，会导致主播特征屡次查询和特征抽取（原始特征转换为模型输入内容，如bucket等）
  • 精排部分的rt满意需求，但cpu负载过高
  • 针对以上问题，咱们进行了一些优化：
  • 经过每次predict添加batch_size来下降cpu耗费（增大了RT）
  • 与精排体系之间的交互改为Item纬度，每个Item顺便一个案牍ID列表的特征，一起回包成果也改为Item纬度，每个Item顺便排序成果Top1的案牍ID，下降网络传输（下降RT）
  • 模型猜测进程中，先对用户、主播、案牍维度进行特征查询、抽取等操作，在模型predict前将案牍相关特征拼接入sample中，下降屡次相同的特征查询和抽取耗费（下降RT） 如下图所示，该集群包含播放页20%的流量，在优化其间部分流量（10%）后，在RT添加3-5ms的情况下，cpu占用率下降了60%，使得模型能够顺畅全量。
    云音乐播放页直播推荐实战
    终究，在播放页取得点击率（ctr）：+10.21%，有用播放率（ctcvr）：+8.48%的作用。

5.4 主播、案牍、头像交融模型

以上咱们经历了从案牍、头像优选->案牍模型+案牍投进体系->主播、案牍交融模型。 不难发现，咱们下一步的优化方针是将主播、案牍交融模型改造为主播、案牍、头像交融模型。 咱们在主播前史头像的基础上，让主播上传了动态头像，现在还在继续优化中，我相信咱们能够取得十分不错的作用。

6. 总结展望

本文以歌曲播放页直播进口为例，介绍了咱们在云音乐直播的特性化引荐实践。 针对事务中遇到的问题和应战，咱们调研和规划了相应的计划去处理这些问题：

  • 关于直播内容会实时改变的问题，咱们选用了实时引荐的计划
  • 关于事务多方针的诉求，咱们选用了多方针交融模型
  • 关于直播引荐存在的多种模态，咱们进行了多模态的探究实践 要注意的是，没有「最好的模型」，只要「最适合的模型」，并不是说模型越 fancy 越杂乱，线上作用就会越好。比方阿里提出了 DIN 模型，是因为工程师们首要发现了数据中的「多峰散布」、「部分激活」的现象，而在直播场景中这个特色就不是很明显，但直播场景也有其自身的特色，如多模态、实时性和热门效应等。

只要深化了解事务场景，并依据用户行为和数据提取出能表现这个场景的特征，再对应地开发适用于这个场景的模型，才干取得最佳的作用。

参考文献

  • 我对互联网直播产品的了解
  • 2020-2021我国在线直播职业年度研究报告
  • 引荐体系之多方针优化小结 – 知乎
  • 多使命学习优化（Optimization in Multi-task learning） – 知乎
  • 深化了解引荐体系：多模态广告CTR预估
  • Ktena S I, Tejani A, Theis L, et al. Addressing delayed feedback for continuous training with neural networks in CTR prediction[C]//Proceedings of the 13th ACM Conference on Recommender Systems. 2019: 187-195.
  • Xiao Ma, Liqin Zhao, Guan Huang, Zhi Wang, Zelin Hu, Xiaoqiang Zhu, and Kun Gai. 2018. Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate. SIGIR (2018).
  • Jiaqi Ma, Zhe Zhao, Xinyang Yi, Jilin Chen, Lichan Hong and Ed H. Chi. “Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts” Knowledge Discovery and Data Mining (2018).
  • Zhao Chen, Vijay Badrinarayanan, Chen-Yu Lee and Andrew Rabinovich. “GradNorm: Gradient Normalization for Adaptive Loss Balancing in Deep Multitask Networks” International Conference on Machine Learning (2018).