Fork me on GitHub

本助手集算力、智能于一身，为您提供最精彩全面的人工智能技术资讯
      •  0 回帖  •  1.1K 浏览  •  2 年前
   

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

image.png

网易云音乐技术团队 作者：鲁沛瑶，郑楷涛

0. 引言

直播是一种高即时，强互动的内容展现形式，一般在主播向观众传达内容的同时与观众进行互动。在泛娱乐直播产品中，直播满足了用户寻求陪伴，娱乐消遣、打发时间的需求，同时也满足了主播实现盈利和获得关注认可的需求。 iiMedia Research（艾媒咨询）数据显示，2020 年中国在线直播用户规模为 5.87 亿人，预计未来继续保持增长态势，2022 年用户规模将达 6.6 亿人。艾媒咨询分析师认为，电竞、电商、教育等新形态直播内容兴起为行业注入新的发展活力。各大平台积极推进直播与其他类型相结合，也使更多内容形态出现，吸引更广泛的用户群体。（数据来源：2020-2021中国在线直播行业年度研究报告） img LOOK 直播是网易云音乐旗下一款主打音频直播的直播软件，依托网易云音乐的音乐人生态，为用户打造最具音乐属性的直播新体验。LOOK 直播不仅有独立的 APP，在云音乐 APP 也有多个入口。 本文以歌曲播放页直播入口为例，介绍云音乐直播个性化推荐的实践，包括以下几个部分：

  • 业务背景。介绍 Look 直播在云音乐 APP 的产品形态，以及算法推荐的目标。
  • 业务挑战。介绍直播推荐业务的特点，以及我们遇到的挑战。
  • 实时推荐。介绍实时推荐的方案，包含流式样本、样本归因和增量训练。
  • 多目标融合。介绍多目标融合，包含 ESMM、MMoE 和 Loss 融合。
  • 多模态探索。介绍我们在直播推荐多模态探索方面的一些进展。

1. 业务背景

LOOK 直播依托于云音乐 APP，有着丰富的流量入口以及各种各样的展现形式，不同入口的产品职能和用户心智存在较大的差异。如图 1 所示，是云音乐直播在首页、歌曲播放页、评论页的产品形态。除了这 3 个流量比较大的入口，云音乐直播还有搜索综合页、我的页面和更多页等入口。 img 在实际推荐的过程中，我们希望除了满足用户本身在内容消费上的需求以外，我们更希望能够去推动用户和主播发生更多的互动。在业务目标上，我们会关注 CTR、观看时长这样的内容项的指标；同时，也会考虑社交关系达成方面的指标，如关注转化；另外，云音乐直播本身也承担了比较重要的营收职能，因此付费转化为代表的营收指标同样是重点。除此之外，我们还会从整个生态的角度来兼顾生产者（主播侧）和消费者（用户侧)的留存问题。

2. 业务挑战

歌曲播放页直播入口（也称直播播放页）是 Look 直播在云音乐最大的一个流量入口，它的位置非常特殊：位于歌曲播放页的右上角。因此，歌曲播放页直播推荐不仅有着直播推荐的共性，也有着自己的个性。 我们先来看看直播推荐的一些共性。

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

3. 实时推荐

如果把推荐系统简单地看成是一个排序函数 f(x)，那么可以把实时性拆成两点：

  • 输入 x 实时
  • 模型 f 实时 其中，输入 x 实时，也就是特征实时，可以根据时效性分为三个粒度：
  • 毫秒级特征：依靠客户端在请求中填入时间、地点、场景等上下文特征
  • 秒/分钟级特征：依靠流式计算，做一些简单的统计类特征的计算和聚合用户行为反馈数据等，比如统计主播在某个时间窗口的点击次数等
  • 小时级特征：依靠离线计算，可以进行更高阶的特征组合的工作，比如统计用户在某个时间窗口对主播标签的转化率分布情况等 而模型 f 实时，可以拆解为：
  • 训练数据流式生成：曝光流、点击流等和各类行为数据实时接入，流式关联特征数据，生成训练样本
  • 增量学习/在线学习：训练数据随着时间的推移源源不断地加入到当前训练流程中，以增强当前模型的拟合能力。增量学习往往在获得一批新样本后再进行训练更新，而在线学习则是在每次获得一个新样本的时候就实时更新模型 这里我们重点介绍下流式样本、增量学习的具体做法。

3.1 流式样本

我们与实时计算组合作，最早将基于 snapshot 的实时样本在直播播放页落地，较好地解决了线上线下特征不一致、实时特征容易导致穿越等问题。经过不断地完善与优化，目前这套框架已应用于直播的各个场景、播客等各业务，取得了不错的效果。 下面我们以直播播放页为例，对这套框架做一个介绍。（注：可能跟目前最新的框架有所出入，但核心思想基本一致） img 整体业务流程如下： （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 更新。 img 另外，在增量训练过程中，我们还会遇到如下问题：

  • 低频的特征进入模型训练，会导致模型预估结果不置信。这种情况需要我们对特征设置准入规则，比如设置特征频次过滤掉低频特征，或者对低频特征施加比较大的正则项等进行解决
  • 特征规模一直在增长，会给线上预估性能和机器内存带来压力。这种情况需要我们对特征进行淘汰，比如淘汰长时间未更新的特征、淘汰 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 的网络结构如图所示： img 1）为了解决数据稀疏的问题，ESMM 使用了共享 Embedding，CVR 任务和 CTR 任务使用相同的特征和特征 Embedding。 2）为了解决样本选择偏差的问题，ESMM 并没有直接使用 点击->转化 样本学习 CVR，而是通过 曝光->点击 和 曝光 -> 转化 样本来隐式地学习 CVR。在我们的场景，我们需要建模的目标是点击和有效观看，这两个目标涉及到的关系可以被描述为： img 可以看到，pCTR 和 pCTCVR 这两个任务使用的是整个空间的样本，它们有显式的监督信号，而 pCVR 节点只是网络结构中的变量，它没有显式的监督信号。 3）ESMM 的目标函数如下 img 总结起来，就是 ESMM 通过 CTCVR 和 CTR 的监督信息来训练网络，隐式地学习 CVR。 在实际使用过程中，为了提取高阶组合特征，我们做了两个如下改动：
  1. 增加了一些手动构造的交叉特征，以此提高模型的记忆能力
  2. 在原有 ESMM 网络结构基础上添加了 FM 模块 整体网络结构如下： img 在目标融合阶段，我们对多个目标采用带权乘积融合(取 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 的整体框架如图所示： img 如图所示，Gate 通常是一个线性模型 + softmax，而 Expert 通常是 DNN 等。 MMoE 与 ESMM 模型的不同点主要有：

  1. 任务底层不是 shared-bottom 结构，而是通过多个 Expert 来学习不同的特征
  2. 引入与任务个数相同的门控网络（gating network），每个任务的 gating network 通过输出不同的权重实现对 experts 的选择性利用（加权求和）。不同任务的 gating network 可以学习到不同的 experts 的组合模式，即吸收 expert 信息的侧重点不同，因此模型捕捉到了不同任务的相关性和区别 将上面的网络结构转换成公式，表示如下： img 经过实验，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 进行融合呢？

我们把多任务模型的损失函数记为： img
那么对于共享参数 W_sh 在梯度下降优化时： img
从上面的表达式可以看出：

  • 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数据
  • 最后根据统计数据对主播的文案、头像进行轮询 如下图所示，红色为优选流程。 img
  • 针对主播头像，由于头像与主播关联性较强，很多用户是通过头像对主播建立的感知，所有我们没有使用主播自身头像以外的数据，只选取了主播的历史头像作为候选集。
  • 针对主播文案，可选的扩展内容则更为丰富，除了一些通用的文案之外，主播有较为丰富的标签，针对主播的性别、年龄，是否在唱歌、跳舞、ACG主播等等特征，都可以添加相应的扩展文案，除了增加文案的丰富度外，可以细粒度的将文案和直播间内容进行匹配，出了直接提高CTR之外，对于CVR的提升也是有益的。
  • 通过该流程的实践，文案优选在播放页、首页均取得了非常好的效果.

5.2 文案模型+文案投放系统

在文案优选的实践过程中我们也发现了很多问题：

  • 文案量少、无法持续产出高效文案，持续追踪热点，形成长久的高收益，扩展文案实际只有20多个

  • 自动化程度不够（所有的文案均是通过硬编码在系统中，非常不灵活），每次更新都要线上发布

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

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

  • 利用文案模型来实现文案的个性化推荐

  • 通过离线效果统计，以图形化界面的方式给产品/策划产出每天的数据反馈

  • 产品/策划通过数据总结规律，来持续产出优秀的文案，形成整个优化的闭环 1）基于此，我们构建了文案系统2.0，让产品、策划可以通过Web页面配置的形式，方便的上传、修改文案，同时支持20多种不同的配置属性来实现文案的定向投放，所有属性如下所示。

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

    2）拥有丰富的文案池后，继续通过简单统计的方式来投放显然不是最优的选择。文案模型可以自动的的进行文案个性化投放，同时可以将所有类型的文案进行统一处理，按照文案的优化目标（而不是人为规定）进行投放。 3）文案的效果统计如下图，通过不同的文案效果对比，产品/策划可以了解用户对于不同文案的喜爱程度，从而产出新的文案 img

通过文案模型+丰富文案池+数据反馈，我们拿到了非常好的效果。

5.3 主播文案融合模型

在当前推荐链路中，文案和主播的排序是分开。我们知道两个局部最优点的效率总是小于等于全局最优点的，由此我们开展了下一阶段的优化，将Item（主播）和文案进行融合排序，流程图如下。 img

  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%，使得模型可以顺利全量。 img 最终，在播放页获得点击率（ctr）：+10.21%，有效播放率（ctcvr）：+8.48%的效果。

5.4 主播、文案、头像融合模型

以上我们经历了从文案、头像优选->文案模型+文案投放系统->主播、文案融合模型。 不难发现，我们下一步的优化目标是将主播、文案融合模型改造为主播、文案、头像融合模型。 我们在主播历史头像的基础上，让主播上传了动态头像，目前还在持续优化中，我相信我们可以取得非常不错的效果。

6. 总结展望

本文以歌曲播放页直播入口为例，介绍了我们在云音乐直播的个性化推荐实践。 针对业务中遇到的问题和挑战，我们调研和设计了相应的方案去解决这些问题：

  • 对于直播内容会实时变化的问题，我们采用了实时推荐的方案
  • 对于业务多目标的诉求，我们采用了多目标融合模型
  • 对于直播推荐存在的多种模态，我们进行了多模态的探索实践 要注意的是， 没有「最好的模型」，只有「最适合的模型」，并不是说模型越 fancy 越复杂，线上效果就会越好 。比如阿里提出了 DIN 模型，是因为工程师们首先发现了数据中的「多峰分布」、「部分激活」的现象，而在直播场景中这个特点就不是很明显，但直播场景也有其自身的特点，如多模态、实时性和热点效应等。

只有深入理解业务场景，并基于用户行为和数据提取出能表现这个场景的特征，再对应地开发适用于这个场景的模型，才能取得最佳的效果 。

参考文献


本文地址：https://www.6aiq.com/article/1660745718777
本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出