实时增量学习在云音乐直播推荐系统中的实践

图片来源：https://unsplash.com/photos/ft0-Xu4nTvA

1. 直播业务背景

1.1业务背景

直播推荐业务是嵌入在云音乐 APP 中各个地方，其中就包括最大的几个场景歌曲播放页的直播模块、混合在评论中的评论页直播以及云音乐首页的首页六卡直播。如下图所示，图 1.1 即为播放页上的直播模块；图 1.2 是云音乐首页中首页六卡直播模块；图 1.3 是歌曲评论页中的直播模块。

不同推荐位的直播承载着不同的内容使命，在首页我们更倾向让新用户了解直播，让老用户快速地进入直播间观看直播；在歌曲播放页的直播更倾向于推荐给用户与听歌行为相关、与歌曲相关的直播内容；在歌曲评论页，直播更像是另外一种形态的内容，是社交内容的补充。

同时，直播业务是云音乐的衍生品，其推荐不同于音乐推荐，主要表现为用户意图不明确、直播用户行为稀疏、实时性要求高以及存在 debias。

本文主要聚焦于直播推荐系统实时化，以场景的算法特色为切入点介绍直播场景的优化目标，从多个角度说明为什么直播需要实时化。同时，本文概述了推荐系统实时性的基本组成和基本解决方案。推荐系统实时性主要由特征实时性、模型实时性和系统实时性组成。具体地，本文也以云音乐直播场景的实时化演进来详细介绍我们是如何去搭建整个直播实时化系统，并解决实时化过程中带来的困难与挑战。最后，本文也给出了在大规模场景下的线上效果和分析。

1.2 场景算法特色

大多数平台的直播场景，同时开播场次有限，对召回诉求不强，本质是一个对实时直播的精排或者粗排+精排的过程。

1.2.1 多目标

在推荐场景中，用户的行为一般都不止一种，而且不同行为的发生有先后顺序和依赖关系。直播推荐场景就是这样一个相关型多目标场景，在哪里建模也都是一个多目标的过程，比如既要点击率又要在观看时间长，又要转化率高，还有些粉丝亲密度的问题。图 3 是直播的推荐的整个多目标学习过程。

用户在首页浏览直播模块时，先会发生点击，然后进入直播间产生观看，当达到 30s 以上的时候，会产生一个目标任务：有效观看。可能这时用户会喜欢该主播，和主播发生互动，并关注这个主播，更甚者送礼物给主播。用户的每一种行为都可以成为多目标模型里的一个目标，像这种目标之间存在依赖关系的多目标模型就属于相关型的多目标模型。这样流程也可以转化为一张多目标关系图，那么每一个任务和目标就是我们模型需要去学习的。

1.2.2 实时化

相比于传统的个性化推荐每天更新用户的推荐结果， 实时推荐基于用户最近几秒的行为实时调整用户的推荐结果 。实时推荐系统让用户当下的兴趣立刻反馈到了推荐结果的变化上，可以给用户所见即所得的视觉体验，它牢牢地抓住了用户的兴趣，让用户沉浸在其中。直播推荐系统更是对实时化需求非常高，大致可以从几个角度来介绍，Item 推荐角度、数据指标、业务环境。

Item推荐角度

直播推荐是对实时在线主播的排序，是存量主播的一小部分。从下面这张平台主播开播分布情况图（图 4）可以看出，我们平台存量主播有百万量级，而当天开播主播只有万量级, 同时每个主播开播的时段不一，有凌晨、早上、下午、晚上，且每个时段开播主播咖位也不同，一般来说晚上开播主播更多，咖位更大。

直播推荐的 item 就是主播，是"活的货物"，这不同与歌曲推荐中的歌曲，信息流推荐中的图文或者视频，主播是一个不断变化的 item，如下面这张图可以看出用户每次进入直播间看到的直播内容和主播状态都不一样，主播可能在 pk、表演、聊天；而歌曲或者视频是一个完全静态的 item，且每次推荐展示都是从头开始播放；所以直播推荐的不仅仅是一个 item ，更是 status。

数据指标

具体的主播实时效率也能体现这一问题，某一主播在同一天内不同时刻效率变化剧烈，存在多个高峰和低谷，这可能与主播当时表现的状态有关、也可能与直播内容相关。但是对于推荐系统来说，系统是利用历史的数据去拟合预估未来的趋势，如果系统不够实时，无法获取主播实时表现情况，那么系统极有可能会对主播未来的趋势拟合出现偏差，甚至可能是完全相反的结果。

业务环境

云音乐直播业务与其他业务息息相关，牵一发而动全身。这是因为直播业务不是固定位置的推荐，例如首页直播收到音乐业务风格推荐的影响，会导致直播模块出现在第3、6、7位。歌曲播放页的直播模块，会收到歌曲的影响，因为一个直播间在不同歌曲的效率是不一样的。所以一旦其他业务有所改动，都极有可能对直播业务的数据分布产生巨大的变化。

所以不管是从推荐的 item 、主播数据指标还是大环境，直播推荐都急需要一个实时化的推荐系统。

2. 推荐系统的实时性

推荐系统实时化性由特征实时性、模型实时性和系统实时化组成，需要利用特征实时化去实时获取数据分布；模型实时化去实时拟合数据分布；最后基于实时系统去获取最新模型和数据。

抛开系统实时来说，算法同学当然更关心的是特征实时性和模型实时性。具体来说;

1. 推荐系统的更新速度越快，越能够反应用户最近的用户习惯，越能够给用户进行越有时效性的推荐。

2. 推荐系统更新的越快，模型更容易发现最新流行的数据 pattern，越能够让模型反应找到最新的流行趋势。

2.1 特征实时性

推荐系统依赖强大的数据处理能力

• 系统“实时”地收集模型所需的输入特征，使推荐系统能够使用最新的特征进行预测和推荐

• 用户 T-1 时刻发生的行为(播放某首歌、观看某个主播、打赏/付费)，需要在T时刻实时反馈到训练数据中，提供模型学习

这是一个比较常见的特征实时化的实现框架图，主要包括日志系统、离线画像、实时画像，通过 storm、flink、kafka 完成实时数据的处理和传输, 并存储在 hbase 和 redis 中，最后落盘到 hdfs 中。实时样本的处理中间环节是通过快照系统来解决样本的穿越问题和一致性问题。

但特征实时性再强，影响的范围也仅限于当前用户，要想快速抓住系统级别的全局的数据变化和新产生的数据 pattern，就必须加强“模型”的实时性。

2.2 模型实时性

与“特征”的实时性相比，推荐系统模型的实时性往往是从更全局的角度考虑问题。特征的实时性力图用更准确的特征描述一个人，从而让推荐系统给出更符合这个人的推荐结果。而模型的实时性则是希望更快的抓住全局层面的新的数据模式，发现新的趋势和相关性。

要加强模型实时性最重要的做法是改变模型的训练方式，按照实时性强度排序，是全部样本更新、增量更新、在线学习。不同的更新方式当然也会带来不同的效果，例如全量更新，模型会利用某时间段内的所有训练样本进行重新训练，再用训练好的新模型替代老版本的模型，这样的训练方式需要的训练样本量、训练时间长、数据延迟长，但是样本的准确性最高。对于在线学习，更新速度是最快的，是增量更新的进阶版，在每次获得一个新样本的时候就实时更新模型，但是这样的方式会导致一个很严重的问题，就是模型的稀疏性很差，打开过多“碎片化”的不重要特征。增量更新相对来说是一种 tradeoff 的方式，既可以减少样本训练时间长、数据延迟严重带来的问题，又可以减少每个样本更新带来的模型训练不稳定的问题，所以我们的做法也主要采用这种方式。

3. 直播精排模型的实时化演进

云音乐直播业务的实时化一直都是分成两条腿在走，一个特征实时，一个是模型实时。我们最初主要是通过不断增加各个维度的实时特征来提升系统的实时化能力，来实时反应主播、用户、上下文在当前的变化，使得模型能够跟上当前的实时变化来预估未来的趋势。另外在提升特征实时化的同时，我们也一直在对模型结构做升级迭代，业务最初采用的是特征工作+简单的单模型逻辑回归，这个方式的核心就在于实时数据、实时交叉特征打点⽇志的建设。迭代到现阶段，我们采用的是 ESMM+DFM+DMR 模型，通过 ESMM 联合训练模型来解决 SSB 问题和转化样本的 Data Sparsity，DMR 结构来捕捉用户长期和短期的兴趣。但是，现阶段还存在一些问题，特征够快了，模型够复杂了，可模型更新不够快，无法更快的抓住全局层面的新的数据 pattern 和趋势。

4. 实时增量模型搭建

云音乐直播算法团队通过探索与实践，总结出了一个相对成熟且行之有效的实时增量模型的训练框架。

• 框架左侧部分是实时增量学习，右侧是离线学习： 离线训练仍然保留，它基于历史7天的数据训练，主要用于增量模型的热启动重启。增量学习通过消费 Kafka 的实时数据流，通过 ETL 处理后，用于实时训练模型。
• 实时样本累计归因： 实时样本处理完后存储在 HDFS 中，实时数据流处理时，对于样本需要做一个当天历史样本的累计归因，保证样本 label 的准确性，这里的累计归因取决于使用场景，例如首页场景重复曝光率高需要做；对于重复曝光率低的场景，则无需再做。
• 模型实时训练：  实时增量训练任务的训练数据集都是当天的累计归因过的样本，累计样本随 kafka 流不断增加。模型训练每次都是基于最新的离线模型热启动重启。这里的归因样本也取决于落地场景，部分场景无需累计归因。
• 模型同步：  模型按照 15 分钟例行化导出模型文件同步给引擎，这里的同步效率可以自行调节。

4.1离线模型

增量模型是在离线模型的基础上做进一步迭代，在不改变原有模型的网络结构，增量更新模型参数，来快速抓住系统级别的全局的数据变化和新产生的数据 pattern。

我们现有的离线主模型是一个深度兴趣 ESMM-DFM 模型；该模型是借用 Wide&Deep 的思想，在 ESMM 框架下，增加特征交叉模块、用户兴趣模块，最后通过 RestNet-DNN 来加快模型收敛。

• ESMM 联合训练模型，解决 SSB 问题和转化样本的 Data Sparsity
• 引入 DFM 替换 DNN，增加多特征域交互性
• 显性建模 U2I 和 I2I 网络，增强用户和主播的兴趣连接
• Output 层：ResNet-DNN 替换 Sigmoid 加快模型收敛

4.2 样本归因

大多数和转化相关的正样本 delay 现象都很明显，这样会导致实时数据分布不是真实的分布，因为在实时样本被落下来的时候，正样本还没到来。正样本 delay 是因为用户行为上报存在天然串行，导致 label 滞后，用户曝光日志会最先产生，然后才会是点击再是观看日志，整个行为不可逆转。所以这会产生一个问题，同一个用户在同一页面，曝光和点击数据先后到达时，如何确定归因样本 label。

业内常见的样本归因方式，一般有两种，一个是 facebook 提出的负样本 cache 归因法，第二个就是 twitter 提出的样本矫正法。

负样本 cache 归因法就是如图所示，负样本会先 cache, 等待潜在的正样本到达，若后续正样本到达，则只保留正样本，更新模型一次。cache 的时间窗口一般是有转化时长来确定，保证 95% 以上的转化能完成即可。虽然这样的做法会存在一些样本延迟，但是样本 label 准确性是比较高的。

Twitter 的做法：两条样本都会保留，都会去更新模型，这样实时性最高，但是非常依赖样本矫正策略。

在现有的工程框架下，我们更倾向于构造类似于 facebook 的负样本 cache 策略，但是直接迁移使用会存在问题，我们尝试在首页直播模块落地，但是整体样本 label join 率只有70%。

这就涉及到云音乐首页场景都会存在的一个问题，息屏现象。因为用户进入首页到退出，再到重新回到云音乐首页，是不会重新拉流的，这就导致了用户的点击和观看可能远远大于曝光，cache 是无法等待这么长时间的。如果直接落下实时样本，就会导致样本内出现同一条特征对应着多个正负样本 label，给模型训练带来太多的噪声。

所以我们设计了样本累计归因的方式，cache 落样本的方式不变，增加一个离线处理过程，对实时样本和当天历史样本在做一次归因，保证截止当前时刻内的样本准确；这样牺牲少量时间，换取高样本准确性，最后使得样本准确性从 70% 提高到 97%。

4.3 模型热启动重启

如我们上文给出的实时增量学习的技术架构图，右侧的离线训练过程是不会丢弃的，因为增量学习需要依赖离线模型做模型热启动重启。离线模型热启动重启的主要原因有两点：

（1）防止模型会因为一些局部的 pattern 而被带偏，基于离线模型热启动可以对其进行矫正。

（2）如果模型训练是 long running 的，会导致模型词表OOV 的概率会越来越大，无法将新的ID快速加入到模型的词典并且快速淘汰老的 ID。通过离线模型热启动重启，可以同步更新模型词表，防止 OOV。

（3）场景使然，如 4.2 所述，首页直播场景存在严重的息屏现象，导致实时样本需要做进一步的累计归因，这样获得的样本均为当前时刻的累计样本，所以模型更新均需要在离线日更模型上做梯度下降。

因此，我们设计了天级别的离线模型热启动重启和 15min 样本级别的重启，以解决上述三个问题。这样既可以解决模型 long runing 带来的 oov 问题和局部 pattern 有偏的问题，更重要是保证进入模型训练的样本 label 都是准确的。

4.4 特征准入方案

样本和特征作为机器学习的基石，其质量的好坏直接决定了模型效果的上限，所以做好样本和特征的质量保障，对实时增量学习的效果提升至关重要。上文 4.2 样本归因一节中，我们着力于保证进入模型训练的样本准确性。本节主要以具体 case 为切入点，分别从样本偏差特征和低频特征两个角度，介绍我们的解决方案。

Case1: 时间偏差特征，例如 week 和 hour 这类型的特征，增量样本中集中于某一两个特征值，和离线训练样本分布完全不一致。

Case2: 低频不置信特征，例如某主播 id 样本只出现 2 次曝光，1 次点击，1 次转化。 该 id 做维特征喂入模型，从统计意义上说，该 id 点击率50%，转化率100%。

所以我们设计了一套特征准入方案来缓解这种现象，主要包括 feature freezing、特征硬准入、动态 L1 正则的软准入方式。具体方案，如图所示。

4.4.1 Feature Freezing

机器学习算法有一个独立同分布的基本假设，即模型训练的数据分布要与预测时的数据分布独立同分布。一些时间特征比如 week 和 hour，在离线批样本中由于被充分 shuffle 过，使用这些特征训练出来的模型依然能保障训练和预测独立同分布，但是在实时流式训练中，样本实时顺序到达的，这类特征无法被充分 shuffle，使得模型训练一直在训练同一个时刻的特征值，而预测时可能切换到下一个时刻的特征值，导致模型泛化能力差。所以，这类时间偏差特征不参与模型的参数更新，作为冻结节点，防止这部分特征陷入局部最优。

4.4.2 “硬准入”

由于增量的样本远远少于离线训练样本，所以全量特征的频次过滤条件不一定适用于增量特征的频次过滤条件。比如，全量时，某些特征的频次过滤数量设置为 1000，但在增量时，应该设置得小一些。全量时，使用天级别积累的样本进行训练，但在增量时，则使用 15 分钟或者 1 小时内的样本进行训练，若仍然使用与之前全量相同的频次过滤条件，会过滤掉近 1 小时内频次不足 1000 的特征，即使在后一小时内，这些特征的频次增加到 1000，也无法再追回已训练样本中的这些缺失特征值。

对于这类低频特征，我们采用了两种方式来解决，第一种方式就是硬准入策略，我们设置了两种特征频次过滤条件，全量更新时采用阈值较大的全量阈值；实时增量时，采用阈值相对较小的增量阈值。并且在构建增量样本时，之前在全量样本构建过程中被全量阈值过滤的特征，其频次会被保留，等到下一次增量到来时，若全量中被过滤的这些特征再次出现，则会将全量+当前增量的频次作为当前特征的频次。这样的话，某个特征的频次达到准入门槛后，才会进入模型训练。这样方式带来线上点击率相对提升 0.94%，有效观看率相对提升 0.23%。

优点： 可以解决本次样本中的特征由于频次过低导致学出来的权重不够置信的问题。

缺点： 仍然会过滤掉某些低频特征，损失一部分有效信息。特征在达到准入阈值之前，出现的前 n 次都被忽略了。

4.4.2 “软准入”

如上述“硬准入”的方案的缺点所述，硬准入会过滤掉某些低频特征，损失一部分有效信息。特征在达到准入阈值之前，出现的前 n 次都被忽略了，只有达到一定阈值后再进入训练的设计方案会破坏样本完整性，如全量频次 99，增量频次 1，阈值过滤 100，则该特征出现的前 99 次都被忽略，仅会训练该特征出现的一次，导致模型训练的稳定性差。所以我们需要更加平滑的方式。

对于“软准入”方案，业界有两种比较常见的做法，基于泊松分布的特征频次估计和动态 L1 正则方案。

基于泊松分布的特征频次估计

在离线 shuffle 后的特征满足均匀分布，但对在线数据流，特征进入训练系统可看做泊松过程，符合泊松分布：

其中 n 为当前出现的次数，t 为当前的步数，λ 为单位时间发生率，是泊松分布的主要参数，T 为训练总步数。 为特征最低门限（即最少在 T 时间内出现的次数）。

因此我们能通过前 t 步的特征出现的次数 n，将 t 时刻当做单位时间，则 。根据泊松分布，我们可以算出剩余 时间内事件发生大于等于 次的概率

每次该特征出现时，都可按该概率 做伯努利采样，特征在 t 步进入系统的概率用下式计算：

通过真实线上数据仿真，它能接近离线频次过滤的效果，其 λ 是随每次特征进入时动态计算的。它的缺陷是：当 t 越小时，事件发生在 t 内的次数的 variance 越大，所以会以一定概率误加或丢弃特征。未来总的训练步数 T 在在线学习中是未知的。频次过滤与优化器相分离，导致不能获得优化器的统计信息。

动态L1正则方案

正则化是结构风险最小化策略的实现，是在经验风险上加一个正则化项或罚项，正则化项一般是模型复杂度的单调递增函数，模型越复杂，正则化值就越大。L1 范数是指向量中各个元素绝对值之和，也叫“稀疏规则算子”（Lasso regularization）。范数作为正则项，会让模型参数 θ 稀疏化， 既让模型参数向量里为 0 的元素尽量多。在经典的 FTRL 实现中，L1 正则对每个特征都是一致的。但是过大的 L1 虽然可以过滤掉极低频的特征，但由于约束太强，导致部分有效特征也被 lasso，影响模型性能。

参考蚂蚁的实时流技术文章提到的动态调 L1 正则方案，通过特征频次影响 L1 正则系数，使得不同频次的特征有不同的 lasso 效果。

特征频次和基于 MLE 的参数估计的置信度相关，出现次数越低置信度越低。如果在纯频率统计基础上加入一个先验分布（正则项），当频率统计置信度越低的时候，越倾向于先验分布，相应的正则系数要更大。以下是经验公式：

L_1(w_i) = L_1(w_i) * ( 1 + ( C * max( N-freq(feaid), 0 ) ) / N )

其中 C 是惩罚倍数，N 为特征最低门限，这两者皆为超参，freq(feaid) 是当前特征出现的频次（包含当前增量中出现的频次以及历史总频次）。

我们也在线上环境，尝试使用了动态调节 L1 正则的方案，最后实现在原有硬准入方案的基础上，线上 ABTest 效果点击率相对提升 1.2%；有效观看率相对提升 1.1%。

5. 线上效果

当然除了模块带来的效果提升，我们整个实时增量模型方案上线，也取得比较喜人的结果。结合上述样本归因的处理、离线模型热启动重启以及特征准入方案，我们最终在首页直播模块推荐场景取得转化率：平均 24 天相对提升 +5.219% ；点击率：平均 24 天相对提升 +6.575% 的效果。

并且我们针对不同的模型更新频率进行了多种方案的测试，如下图，ABTest t1 组为离线日更模型，每天更新替换模型文件；t2 组为 2 小时更新模型，模型每两个小时增量训练；t8 组为 15 分钟更新模型，模型每 15 分钟增量训练模型。经过我们多次测试，发现模型更新越快效果更佳也更佳稳定。

线上排序结果实验前后对比展示如下图，部分在 base 模型中无法排到 top 3 的主播能够在实时增量模型中被发现且排到前面来。也印证我们上文 2.2 节所说，模型的实时性能够更快的抓住全局层面的新的数据模式，发现新的趋势和相关性。

6. 总结与展望

直播推荐业务有着其不同于其他业务的场景特色，推荐的不仅是一个 Item 更是 Status，进而直播推荐需要更快、更高、更强的推荐算法来支持业务的发展。本文是第一篇落地云音乐直播业务的实时增量学习的文章，分享我们在直播业务中如何落地实时增量学习，解决模型实时化过程中带来的问题的一些经验。接下来，我们会继续朝着更快、更高、更强的推荐算法前进，在用户成长、用户付费、主播成长等多个方面持续探索，致力于提供更优的用户体验，更优的线上效果，更好地服务业务。

参考文献

• Cheng Li, Yue Lu, Qiaozhu Mei, Dong Wang, and Sandeep Pandey. 2015. Click-through Prediction for Advertising in Twitter Timeline. In Proceedings of the 21th ACM SIGKDD International Conferen
• Xinran He, Junfeng Pan, Ou Jin, Tianbing Xu, Bo Liu, Tao Xu, Yanxin Shi, Antoine Atallah, Ralf Herbrich, Stuart Bowers, and Joaquin Quiñonero Candela. 2014. Practical Lessons from Predicting Clicks on Ads at Facebook. In Proceedings of the Eighth International Workshop on Data Mining for Online Advertising (ADKDD’14). ACM, New York, NY, USA, , Article 5 , 9 pages.
• 淘宝搜索模型如何全面实时化？首次应用于双11^[1]
• 蚂蚁金服核心技术：百亿特征实时推荐算法揭秘.^[2]
• 在线学习在爱奇艺信息流推荐业务中的探索与实践.^[3]
• 蘑菇街首页推荐视频流——增量学习与wide&deepFM实践（工程+算法）^[4]

本文发布自网易云音乐技术团队，文章未经授权禁止任何形式的转载。我们常年招收各类技术岗位，如果你准备换工作，又恰好喜欢云音乐，那就加入我们staff.musicrecruit@service.netease.com

参考资料