小红书精读：CRM: Retrieval Model with Controllable Condition

快手把观看时长塞进召回塔了🎯

各位算法同学们，快手在召回阶段加了一个”期望观看时长”当输入，主站视频观看时长涨了0.372%，服务4亿用户——召回模型也能被”点菜”了。

📄 CRM: Retrieval Model with Controllable Condition

🔧 观看时长进用户塔：训练喂目标视频的真实时长，推理喂一个期望时长，不用重训就能调目标。物品塔完全不依赖条件，item embedding照旧预计算加ANN检索，这是它能上线的前提。

🧩 Transformer版借了Decision Transformer的结构，把watch-time-to-go条件token和item token交错成序列，目标时长相当于一个数值prompt，直接预测下一个item；DNN版就是用户塔多一列特征，线上跑的是Transformer版。

⚙️ 线上serving用时分复用：从最近32条历史里按概率p取最大值当条件，其余取平均值。因为平均条件涨播放和互动但总时长几乎不动，最大条件涨时长却容易推长视频、掉播放和互动。

📊 主站视频观看时长+0.372%，极速版+0.457%；总使用时长分别+0.175%和+0.196%。

📈 极速版播放量+0.324%、关注+0.828%、评论+0.697%，主站关注+0.447%。

✅ 和Swing、ComiRec、DimeRec、LTR、TDM、KuaiFormer六个召回方法在同场景比，CRM平均单次观看时长42秒，是这批里最高的。规模是4亿用户、每天50亿条日志。

想做多目标召回、把时长这类连续目标直接塞进召回的，这篇”条件进用户塔、物品塔不动”的结构可以直接抄，工程上不用重建索引。坑有两个：时长和互动在max条件下互相拉扯，p和窗口n都是线上调出来的超参，换场景要重调；条件只做了max/avg二选一，按请求个性化选条件还留在future work，这是目前最粗的一环。跟的话就盯总时长和播放量会不会一起掉。

原文：AlphaXiv