推荐检索模型如何由观看时长结果控制？

观看时长为何难以转化为检索查询

典型的推荐系统先从数千万条候选内容中检索出几百条，再按多个目标对它们排序。检索通常采用双塔模型：用户编码器和物品编码器以分类目标训练，物品嵌入提前算好，每次请求只需重新计算用户嵌入并做一次最近邻搜索。为了服务多个目标，系统常常并行运行多条检索通路，每条通路针对不同目标训练，再把候选合并后送入排序。

观看时长这类连续结果打破了这一模式。期望观看时长同时取决于用户和具体视频，但用户塔在任何候选被选出之前就已经算出了表示。论文还指出，不存在一个统一的观看时长阈值能在所有用户和视频上代表好结果。因此，排序阶段的观看时长目标很难直接转化为检索查询。

把观看时长作为用户塔的条件

CRM 把观看时长加入用户塔的输入。在基于 DNN 的版本中，下一个视频的实际观看时长与用户特征一起生成带条件的用户嵌入，训练沿用原来的双塔损失。物品塔和检索流程保持不变。

训练与推理的分工是这一设计的关键。训练时，模型学习在给定实际观看时长的条件下预测下一个物品；推理时则改为给定期望观看时长。因此条件可以在不重新训练的情况下更换，而物品嵌入不依赖该条件，仍可建立索引用于近似最近邻搜索。

用条件标记控制检索目标

第二种实现借用了 Decision Transformer 的序列建模方式。在离线强化学习中，该模型把 return-to-go、状态和动作 token 交替排列，从而能针对指定的回报目标预测动作。CRM 把回报换成观看时长：输入在物品 token 之间交替插入 watch-time-to-go 条件 token，并以下一个物品的条件结尾，因果注意力掩码保证预测只依赖过去。

训练时，watch-time-to-go 的值由实际观看时长算出；推理时，最后一个条件被设为下一个物品的期望观看时长，充当预测下一个物品的数值提示。论文说明，生产环境使用的是 Transformer 版本。

每次请求选平均值还是最大值

推理时，目标观看时长取自用户近期历史，即最近 n 个视频的平均值或最大值。平均值反映用户近期的观看行为，最大值则设定更高目标以鼓励更长的观看。历史长度对两者都有影响：窗口过大，最大值容易受旧异常值影响；窗口过小，又可能不足以代表用户的观看习惯。生产环境使用 n = 32。

两种条件在线上表现不同。平均值条件提升了视频播放量和评论、点赞等互动指标，但对总观看时长几乎没有改善。最大值条件提升了观看时长，却倾向于检索更长的视频，并可能降低播放量和互动。因此 CRM 采用时分复用：每次请求以概率 p 取最大值条件，以概率 1 − p 取平均值条件。

在线 A/B 测试测到了什么

CRM 部署在快手最大的短视频推荐场景中，论文称该场景服务超过 4 亿用户，每天产生 500 亿条日志。在线 A/B 测试报告的视频观看时长提升为：快手主端 0.372%，快手极速版 0.457%。应用总使用时长分别提升 0.175% 和 0.196%，两个应用的人均使用时长均有增长。

两个应用的视频播放量、点赞、关注和评论也都有增长。在快手极速版中，视频播放量提升 0.324%，关注提升 0.828%。这些是线上测试得到的相对变化，不是观看时长的绝对值，描述的是已部署系统，而非受控的离线基准。

增益来自哪里，又止于哪里

论文自己的解释是：把期望观看时长作为检索输入，同时保留预计算的物品嵌入和 ANN 搜索，正是线上增益的来源。这一机制有两种实现：DNN 用户塔中的观看时长特征，以及 Transformer 中的条件 token。报告的证据覆盖两个快手应用中的观看时长、应用总使用时长、视频播放量、点赞、关注和评论。

这些结果并不能证明存在一个适用于所有用户和视频的单一条件值；论文明确指出不存在这样的阈值，这也是条件要按请求从近期历史中选取的原因。平均值与最大值的对比也说明权衡是真实存在的：提升播放量和互动的条件，并不是提升总观看时长的那个条件。论文提出的后续工作是探索其他结果条件，以及如何为每次请求选择条件。

最关键的线上选择

对实践者而言，真正与决策相关的结果不只是条件机制本身，而是每次请求的混合方式。平均值观看时长换来了播放量和互动，但总观看时长几乎没有增益；最大值观看时长换来了观看时长，代价是播放量和互动下降，并倾向于更长的视频。CRM 以概率 p 做时分复用，正是论文对这一取舍的回答；报告的 0.372% 和 0.457% 观看时长增益来自这一组合投放策略，而不是任一条件单独使用的结果。

本文引用的文献