kuaishou直播团队在《Ensure Timeliness and Accuracy: A Novel Sliding Window Data Stream Paradigm for Live Streaming Recommendation》提出了它们的直播推荐：

摘要

直播推荐系统旨在为用户实时推荐其感兴趣的直播内容。由于直播内容的动态变化特性，提升推荐系统的时效性成为关键问题。直观而言，数据的时效性决定了模型可学习时效性的上限。然而，现有研究均未从数据流设计的角度解决直播推荐系统的时效性问题。若采用传统的固定窗口数据流范式，则需在标注准确性和时效性之间进行权衡。

本文提出了一种名为Sliver的新型数据流设计范式，通过缩小窗口尺寸并相应实现滑动窗口机制，同时解决标签的时效性与准确性问题。此外，我们提出了一种时间敏感的重复推荐策略：通过周期性请求推荐服务，降低请求与展示之间的延迟，从而提升推荐服务及特征的时效性。

为验证方法的有效性，我们在快手直播平台采集的带时间戳标注的多任务直播数据集上进行了离线实验。结果表明，在四种典型多任务推荐模型中，Sliver在所有目标指标上均优于不同窗口尺寸的固定窗口数据流。进一步地，我们在快手直播平台部署了Sliver，在线A/B测试显示点击率（CTR）和新关注数（NFN）显著提升，再次验证了Sliver的有效性。

1 引言

在移动互联网时代，在线直播已成为最受欢迎的实时互动方式之一，并近年来快速发展[11]。通过直播平台，主播能够与观众实时分享其体验。多样化的直播应用场景随之涌现，包括在线教育[8]、电商直播[35]等。直播推荐系统专为这些平台设计，旨在向用户推荐其感兴趣的直播内容。与传统推荐系统不同，直播推荐的核心特征在于直播内容会实时动态变化[27]。例如，图1展示了直播内容的动态变化如何导致直播间真实点击率（CTR）的实时波动。因此，保障直播推荐的时效性成为直播推荐系统面临的重要挑战。

图1：从该图可以看出，在直播间里，ground truth CTR随着直播内容变化而动态变化。这张图中的游戏图片代表时间轴中对应时刻的实时内容。我们可以观察到：直播内容在 一小时前和一小时后的ground truth CTR发生巨大变化，因为主播切换了游戏

现有研究主要从模型角度解决这一问题，通过向推荐模型中引入内容信息（如时间、多模态信息或用户动态行为）以捕捉直播内容的动态性[11, 13, 27, 36]。然而，这些工作均忽略了从数据层面建模直播时效性的关键问题。直观上，数据的时效性决定了模型可学习时效性的上限。换言之，若模型未使用最新样本训练，其时效性必然受限。在工业级推荐系统中，数据通常以流式形式呈现，推荐模型随新数据到达而增量更新（即流式学习）[3, 5, 31–33]。流式学习通过即时更新模型确保直播推荐系统具备一定时效性，但未解决一个核心问题：如何生成直播训练样本并保障其时效性？例如，理想情况下，用户行为（如点击）应在发生后立即转为训练样本，并通过流式学习更新模型。

针对此问题，一种直观方法是采用主流的固定时间窗口数据流[9, 21, 25]并缩短窗口尺寸。然而，缩短窗口会引发延迟反馈问题[6, 9, 19]。如图2(a)所示，窗口外的长期行为（如关注）会被误标为负样本。这自然引出一个关键问题：如何同时保障直播数据流的时效性与标注准确性？

图2 传统固定窗口数据流与我们的方法对比：传统固定窗口数据流在实时流推荐系统的时效性和准确性之间存在权衡。Sliver通过实现滑动窗口和重新推荐策略，确保了时效性和准确性。ST和LT分别表示服务时效性和标签时效性。

本文首次从数据流设计的角度研究上述问题，提出了一种面向直播推荐的滑动窗口数据流范式（Sliver）。如图2(b)所示，Sliver通过滑动短时间窗口并在窗口结束时生成样本，其训练样本与真实行为间的延迟仅为窗口长度，从而本质性保障了时效性。同时，滑动窗口机制允许利用用户退出直播间的显式负反馈行为作为负样本，既确保了负样本的准确性，又有效解决了固定窗口数据流的延迟反馈问题。此外，考虑到在线推荐系统仅能使用请求时刻的特征和模型，而请求与展示间的延迟会损害推荐特征与服务的时效性，我们提出了一种时间敏感的重复推荐策略（re-reco），在推荐内容未展示时持续重新请求推荐服务，以保障特征与服务的实时性。

为验证数据流的有效性，我们基于中国头部短视频与直播平台快手APP的实时数据构建了带时间戳标注的真实直播数据集，并展示了该平台上直播推荐系统的三种数据流演进过程（延迟从小时级逐步降至秒级，时效性逐代提升）。前两种为固定窗口数据流，第三种为Sliver数据流。基于多任务学习框架[4, 23, 24, 29]，我们在离线实验中预测了用户多种交互行为（点击、关注、点赞），其中点击与关注目标在曝光空间预测，点赞目标在点击后空间预测[24]。实验结果表明，Sliver在所有目标上均优于两种不同窗口尺寸的固定窗口数据流，证明了从数据流视角兼顾时效性与标注准确性的必要性。最终，Sliver在快手APP上线后，两个页面的点击率（CTR）提升6.765%-8.304%，新增关注数（NFN）提升2.788%-3.697%，进一步验证了方法的有效性。

本文贡献总结如下：

• 首次从数据流视角研究如何同时保障直播推荐系统的时效性与准确性；
• 提出Sliver数据流范式，通过滑动短窗口连续生成样本，在保障时效性的同时，利用直播间退出行为避免延迟反馈，确保标注准确性；
• 提出时间敏感的重推策略（re-reco），保障推荐特征与服务的实时性；
• 开源带时间戳标注的真实直播数据集，并进行离线实验。Sliver在快手平台部署后，在线实验表明其在离线与在线环境中均优于高延迟、低准确性的传统数据流。

2 相关工作

2.1 直播推荐

随着直播作为一种新兴社交媒体形态的发展，直播推荐日益受到关注。与传统静态物品推荐问题不同[17, 26, 30, 37]，直播内容具有动态变化的特性。现有研究提出了多种方法应对直播推荐问题：

• LiveRec[27] 将时间内容融入历史交互的自注意力机制，增强模型的时间敏感性；
• [36] 利用LSTM和基于注意力的模型联合提取主播与观众的偏好；
• DRIVER[13] 通过分析用户在直播间的动态行为学习动态表征；
• ContentCTR[11] 采用多模态Transformer提取直播画面中的多模态信息。

这些工作均从模型角度解决直播推荐的时效性问题，而本文首次从数据层面探究时效性建模。

2.2 流式推荐与延迟反馈

为应对用户偏好持续变化等现实动态性，研究者提出流式推荐[5, 7, 12, 16, 33]，其核心是通过时间轴上的数据与模型同步动态更新。虽然流式推荐可处理直播内容的动态变化，但现有工作均未考虑如何设计数据流以满足直播推荐的时效性需求。若简单缩短固定时间窗口尺寸，会引发延迟反馈问题[6, 9, 19]。当前解决方案主要分为两类：

1. 延迟时间分布建模[6, 34]：仅优化观测到的行为信息，无法充分利用正向反馈；
2. 样本复制机制[9, 15, 21, 22]：复用窗口外的延迟行为，并通过重要性采样校正数据分布偏差。

这些方法始终面临时效性与标注准确性的权衡问题，尤其对时效性要求更高的直播推荐场景。本文提出的滑动窗口范式可同时保障两者。

2.3 推荐系统中的多任务学习

多任务学习（MTL）[2, 28]通过利用多任务间的关联信息提升整体泛化性能。现代工业级推荐模型常采用MTL捕捉用户多样行为偏好：

• Shared Bottom[28]：硬参数共享，基于共享输出独立预测各任务；
• MMOE[23]：类似MOE[18]共享所有专家网络，但为各任务设计独立门控网络融合专家；
• ESMM[24]：软参数共享结构，通过序列模式联合优化两个相关任务以解决目标稀疏性问题；
• CGC/PLE[29]：为各任务设置共享与专属专家，缓解任务冲突与负迁移现象。

这些多任务学习模型可与本文方法互补——我们提出的数据流范式可作为插件增强直播推荐系统中多任务模型的在线性能。

3 方法论

本节首先形式化流式数据环境下的多任务直播推荐问题并解释关键符号，随后详细阐述提出的Sliver数据流及其在快手直播推荐场景中的演进过程，最后展示基于Sliver数据流的建模方法。

3.1 问题定义

定义流式数据环境下的多任务直播推荐问题：设$\lbrace D_{\mu} \rbrace_{\mu=1}^\infty$表示数据流，其中：$D_\mu$为时间戳$\mu$处的直播训练样本，其形式为：

\[\mathcal{D}_\mu = \left\{ \mathbf{U}_t, \mathbf{I}_t, \mathbf{A}_t, Y^b_\mu = f_\mu(y^b) \right\}\]

这里:

• $t$为推荐服务请求时刻
• $U_t, I_t, A_t, Y^b_\mu$分别表示用户、直播内容、主播及标注的用户行为$b$（如点击、点赞、关注）

如图3所示，推荐的直播内容在$\tau$时间后展示给用户，经过$\eta$时间后在时刻$\mu$生成训练样本并增量更新推荐模型。

图3 在流式推荐系统中生成一个样本的时间线示意图。请求、曝光和样本生成之间的时间间隔分别为 𝜏 和 𝛿 。$Y_b$ 是用户在曝光后在现实世界中发生用户行为时刻的随机变量。

设：$Y^b$为随机变量，其取值$y^b$表示用户行为实际发生的时刻。

• 若$y^b < \mu$，则$f^b_\mu(y^b)=1$作为正反馈；
• 若$y^b > \mu$，则$f^b_\mu(y^b)$为不确定反馈。

我们的目标是：估计下一请求时刻$t’$的用户行为概率$P(Y_{t’}^{b}=1 \mid U_{t’}, I_{t’}, \theta_{\mu})$，其中：

• $\theta_\mu$为通过$D_\mu$增量学习的多任务模型参数

由于直播内容$I_t$随时间动态变化，$t$与$t’$时刻的特征分布会发生偏移。此外，即使初始推荐结果在$t$时刻是及时的，经过$\tau$延迟后也可能过时。因此，延迟$\tau$和$\delta$共同决定了推荐服务和训练样本的时效性。模型参数$\theta_\mu$基于延迟样本学习，样本时效性越高，模型提供的推荐结果越及时——这成为我们从数据流设计角度提升时效性的核心动机。

3.2 快手APP直播数据流演进

图4展示了快手APP直播数据流的演进过程，包括两种固定窗口数据流（1小时/5分钟窗口）和我们提出的30秒间隔Sliver数据流。

图4 快手直播平台数据流演进概览：从一小时数据流到五分钟数据流，再到Sliver数据流，时效性不断提高。一小时数据流以请求时刻作为一小时窗口的起始点。五分钟数据流以曝光时刻作为一小时窗口的起始点。我们提出的Sliver数据流利用30秒滑动窗口来平衡时效性和准确性。

3.2.1 固定窗口数据流范式

工业推荐系统主流数据流范式[9,21,25]为：从特定时刻（如用户请求）开始，在预定义窗口$w$内记录用户行为，窗口结束时生成样本。据此构建的1小时固定窗口数据流可形式化为：

\[\tau + \delta = w_h\]

如图4顶部所示，若用户在$t$时刻请求服务，则$t < y^b < t+w_h$内的行为$b$将被记录，并在$\mu=t+w_h$时刻作为正样本；若直播已展示但窗口内无行为发生，则作为负样本：

\[f^b_\mu(y^b) = \begin{cases} 1, & t < y^b < t+w_h \\ 0, & y^b > t+w_h \land \tau < w_h \land b \in S_{imp} \\ 0, & y^b > t+w_h \land t < \eta_c < t+w_h \land b \in S_{post} \end{cases}\]

其中：

• $S_{imp}$为曝光空间（点击/关注行为），$S_{post}$为点击后空间（点赞行为）。

然而，直播内容在1小时前后的数据分布差异显著，严重削弱推荐时效性。此外：

• 1.请求与曝光间存在数分钟延迟$\tau$，影响服务时效性；
• 2.用户关注行为若发生在窗口中期，需额外等待半小时才能转为训练样本；
• 3.直播特征的整体延迟$\tau+\eta$达1小时，无法满足特征实时性需求。

3.2.2 滑动窗口数据流范式

为缓解上述问题，如图4中部所示，我们将时间窗口缩短至5分钟（$w_m$），并从直播曝光时刻开始计算窗口：

\[\delta = w_m \tag{3}\]

选择曝光而非请求时刻作为起点，是因为请求到曝光的延迟可能超过5分钟，这会导致大量未曝光样本被误判为负样本。5分钟数据流的标签逻辑可形式化为：

\[f^b_\mu(y^b) = \begin{cases} 1, & t + \tau < y^b < t + \tau + w_m \\ 0, & y^b > \mu \ \land\ b \in S_{imp} \\ 0, & y^b > t + \tau + w_m \ \land\ t + \tau < \eta_c < t + \tau + w_m \ \land\ b \in S_{post} \end{cases} \tag{4}\]

该方法缩短了$\delta$的延迟，一定程度上提升了样本时效性。但减小窗口尺寸会引发延迟反馈问题[6,9,19]。以图4为例：若用户的关注行为发生在5分钟窗口外，该样本会因延迟反馈在训练时被误标为假负样本。如图5所示，曝光后5分钟的标签准确率约为点击86%、关注和点赞80%。该问题在1小时数据流中不显著，因为标签准确率随窗口增大而提升[9]。同时，与1小时窗口相同的延迟$\tau$仍会影响直播特征和推荐服务的时效性。

图5 该图展示了快手直播平台上标注准确率随时间的变化情况。曝光后五分钟时，点击标签的准确率约为86%，点赞和关注标签的准确率约为80%。

综上，固定窗口数据流存在两个时效性问题：

1. 标签时效性与准确性的权衡不可避免；
2. 请求与曝光间的延迟$\tau$限制了特征和推荐服务的时效性。
   我们通过滑动窗口数据流范式解决第一个问题，通过重推策略（re-reco）解决第二个问题。

3.2.3 滑动窗口数据流范式

固定窗口数据流中时效性与准确性权衡的根本原因在于：$y^b$的不确定性导致窗口截断后的样本分布偏离真实分布$Y^b$。受微积分思想启发，若将时间窗口视为微分，通过连续滑动窗口进行积分，则可逼近真实分布$Y^b$——微分保证时效性，积分保证准确性。这一思想催生了滑动窗口数据流范式。

如图4底部所示，Sliver以统一时间$t_{uni}$为起点，在每个滑动窗口结束时生成样本，并为每个窗口分配唯一ID索引。样本生成时刻$\mu_k$表示为：

\[\mu_k = t_{uni} + k * w_s \tag{5}\]

其中：

• $k$为窗口ID，$w_s$为窗口尺寸（实际应用中设为30秒）。

该方法将延迟$\delta$缩短至30秒，同时保障标签时效性与准确性。Sliver的标签逻辑如下：

\[f^b_{\mu_k}(y^b) = \begin{cases} 1, & \mu_{k-1} < y^b < \mu_k \\ 0, & y^b > \mu_k \ \land\ \mu_{k-1} < \eta_{exit} < \mu_k \ \land\ b \in S_{imp} \\ 0, & \eta_{click} < \mu_k \ \land\ y^b > \mu_k \ \land\ \mu_{k-1} < \eta_{exit} < \mu_k \ \land\ b \in S_{post} \end{cases} \tag{6}\]

其中$\eta_{exit}$为用户退出直播间的时刻。

相比固定窗口，滑动窗口数据流的优势在于：

1. 低延迟：用户行为到样本生成的延迟$\delta$小于30秒，对内容动态变化的直播推荐任务更敏感；
2. 高准确性：利用用户退出直播间且未发生行为的事实作为负反馈，确保负标签准确。

3.3 滑动窗口数据流下的建模

3.3.1 排序阶段的多任务模型

直播中并发的多样化用户行为共同影响推荐效果。我们采用统一的多任务模型捕捉这些行为的共享特征，其输入定义为：

\[\mathbf{x}_\mu = [\mathbf{x}^i_t, \mathbf{x}^u_t, \mathbf{x}^a_t] \tag{7}\]

其中$\mathbf{x}^u$、$\mathbf{x}^i$、$\mathbf{x}^a$分别表示用户特征、直播特征和主播特征。时刻$\mu$对任务$b$的预测表示为：

\[\widehat{y}^b_\mu = f(\mathbf{x}_\mu, \theta_s, \theta_b) \tag{8}\]

$\theta_s$和$\theta_b$分别为多任务模型$f$的共享参数和任务专属参数。采用多目标损失优化模型：

\[L = \sum_{b \in B} w_b * L_b \tag{9}\]

$w_b$和$L_b$为各任务的权重和损失，使用标准对数似然函数[38]优化不同目标：

\[L^b_\mu = -\frac{1}{N_b} \sum \left( y^b_\mu \log \widehat{y}^b_\mu + (1-y^b_\mu) \log(1-\widehat{y}^b_\mu) \right) \tag{10}\]

$N_b$为时刻$\mu$行为$b$的样本数。最终通过多目标预测结果计算融合分数$s_{t+1}$，用于$t+1$时刻的在线排序：

\[s_{t+1} = \sum_{b \in B} \alpha_b * \widehat{y}^b_{t+1} \tag{11}\]

$\alpha_b$为各目标的融合权重。

3.3.2 时间敏感的Re-reco策略

尽管Sliver数据流训练的模型具有时效性，但推荐结果仍可能因客户端请求到实际曝光的延迟而失效。如图6所示，造成延迟的主因是直播推荐与短视频推荐在一次请求中混合，导致直播曝光时间不确定。

图6 一种对时效性敏感的重新推荐策略示意图。我们在直播曝光之前递归调用直播推荐模型。

为此，我们提出时间敏感的重推策略：当直播间未被曝光时，每30秒重新请求时效敏感的直播推荐模型（re-reco），并用新结果替换原始推荐。该策略通过缩短延迟$\tau$保障了特征时效性，同时提升了整个在线推荐服务的实时性。

4 实验

本节通过大量实验验证所提出数据流方法的有效性。首先在离线环境下评估提出方法，随后报告在快手APP上的在线实验结果，最后展示提出的Sliver数据流在快手直播平台的实际部署方案。

4.1 离线评估

表1：数据集信息

4.1.1 数据集
针对直播推荐系统时序动态性研究的数据稀缺问题，我们收集并开源了来自快手平台的工业级直播数据集，包含详细时间戳信息。该平台日活跃直播用户超过300万。我们从2023年12月27日至29日的日志中抽取1%用户的三天数据子集（根据请求时间戳）。如表1所示，出于商业隐私考虑，数据集仅包含在线推荐系统的部分代表性特征和行为。每个行为均提供精确的发生时间戳，并根据时间戳信息按3.2节方法划分三种数据流。

4.1.2 评估指标
采用12月29日晚7点前的数据作为训练数据。为模拟在线场景：

• 一小时数据流的训练样本最终请求时间为晚6点
• 五分钟数据流的训练样本最终曝光时间为晚6:55

参照[32]，使用晚7点后五小时数据作为测试集，在流式学习设置下增量评估训练模型。例如评估晚7-8点数据后，增加一小时训练数据再评估晚8-9点数据。为符合真实场景，我们将未发生正向行为且退出直播间的情况作为负样本。采用平均AUC（五次重复）[10]评估不同数据流训练的模型，并分别报告各任务的平均AUC得分。此外，使用RelaImpr指标衡量相对改进：

\[\text{RelaImpr} = \left( \frac{\text{AUC}(\text{被测模型})-0.5}{\text{AUC}(\text{基线模型})-0.5} -1 \right) \times 100\%\]

4.1.3 基线模型
为说明提出数据流范式的有效性，我们在典型多任务推荐模型上与两种固定窗口基线进行比较：

• Shared Bottom[28]：共享底层DNN参数（隐藏层64,32），使用任务特定塔生成对应分数
• MMoE[23]：共享多个专家网络和任务特定门控网络（实现中设3个专家，隐藏层64,32）
• CGC[29]：为每个任务设置独立专家并保留共享专家（设1个任务特定专家和1个共享专家，隐藏层64,32）
• PLE[29]：多层CGC版本（实现中使用两层CGC，第一层隐藏层64,32，第二层32,32）

所有模型的任务塔均采用三层DNN（隐藏层32,32,16）。

4.1.4 实现细节
基于TensorFlow[1]实现所有模型，使用Adam[20]优化器（学习率0.001）。离线训练批次大小设为4096，ID特征和辅助特征的嵌入维度分别固定为32和8，训练时忽略用户ID以保证结果稳定性。参数初始化采用Xavier方法[14]。

4.1.5 结果分析
表2展示了四种典型多任务模型在三种任务、不同数据流设置下的结果。可以看出：

表2

• Sliver数据流在所有模型和任务上均优于两种固定窗口数据流
• 具体改进：
  • 点击行为：平均AUC提升4.55%-5.57%（RelaImpr）
  • 关注行为：提升3.81%-6.26%
  • 点赞行为：提升4.62%-7.82%

这表明Sliver能有效保证直播推荐任务的时效性和准确性。同时观察到：

1. 点击性能提升主要来自时效性改进
   • 窗口从1小时缩短到5分钟可获得2.33%-3.29%提升
   • 进一步采用Sliver可获得额外提升
2. 关注/点赞任务中，单纯缩小窗口可能不会带来改进（说明标签准确性的重要性）
3. CGC模型性能最优（与[29]结论一致），PLE因多层结构适配性问题表现稍逊

4.2 在线A/B测试

我们在中国最大直播平台之一的快手APP上部署Sliver数据流，在精选页和单列页进行在线A/B测试，评估指标为CTR和新增关注数（NFN）。由于在线数据流经历两次升级（1小时→5分钟→Sliver），结果分两部分呈现：

表3显示五分钟数据流相比一小时数据流在四天测试中的提升：

• 精选页：CTR平均提升13.653%，NFN提升6.091%
• 单列页：CTR提升9.470%，NFN提升5.666%

表4显示升级到Sliver数据流并采用重推策略后的进一步改进：

• 精选页：CTR再提升8.304%，NFN提升3.697%
• 单列页：CTR再提升6.765%，NFN提升2.783%

每次升级都带来显著性能提升，印证了从数据角度提升时效性的重要性。

4.3 系统部署

图7展示了快手直播推荐系统架构，分为在线服务和数据流循环两部分：

图7 该图展示了快手直播平台推荐系统的架构。左侧部分展示了在线服务的工作流程，包括首次请求服务和重新推荐服务。右侧部分展示了我们提出的Sliver数据流的工作流程。

在线服务流程：

1. 用户启动APP时，客户端请求直播推荐服务，依次调用召回、粗排和精排服务
2. 为解决推荐结果时效性问题，采用3.2.2节提出的重推策略：
   • 根据推荐结果是否实际曝光决定是否重新请求精排模型
   • 直接从Redis获取候选列表（存储于首次请求阶段），节省召回/粗排资源

数据流循环（Sliver实现）：

1. 获取推荐结果后，基于用户信息和实时直播索引从KV存储获取特征
2. 行为日志收集曝光后用户行为，30秒触发样本拼接
3. 以流式学习方式增量更新精排模型

#

https://arxiv.org/pdf/2402.14399