小红书精读：MuSeR: Scalable Long-sequence Recommendation with Multi-interest Modeling

推荐系统终于敢看10万条历史了

各位算法同学们 💡 先抛个反差：工业推荐系统嘴上说要长序列，手上却只敢截最近几百条行为，因为线上 SLA 常卡在 300ms 以内。MuSeR 这次把 10^4 到 10^5 条用户行为真正塞进了百度 APP 的线上检索，而且它的价值不在新模型结构，在于「怎么让长序列跑得起来」这套系统级拼装。

📄 MuSeR: Scalable Long-sequence Recommendation with Multi-interest Modeling

🔧 分层时间压缩：最近行为全分辨率保留，中段 Pool16、早期 Pool64 逐级池化，把超长历史压到一个固定服务预算内，总有效长度变成可算的常数级别，Transformer 代价不再随长度膨胀。

🧩 多查询兴趣解耦：用 M 个可学习 query 从序列编码里解码出多个兴趣向量，配正交正则防止它们塌缩成同一个；训练时各兴趣向量负责预测不同未来行为，服务时按候选动态挑最相关的那个。

⚙️ 多模态对齐加工程化：ERNIE-4.0-Turbo 蒸馏文本摘要、BGE 语义向量补稀疏 ID；离线异步刷新用户表示、按 QPS 和负载自适应缓存，检索在 HNSW 上做分层 beam search，适配 CPU/GPU 混布集群。

📊 三个公开 benchmark 加一个大规模工业数据集上，Recall@K 一致优于强长序列和多兴趣 baseline。

📈 百度 APP 首页信息流、发现页、短视频三场景 A/B：DAU +0.26%，总时长 +0.89%，均 p<0.05。

✅ 线上同时把服务延迟和成本压低了，2025 年 8 月起全量部署。

🧠 我的判断：如果你在做长序列召回、已经被延迟和显存卡住，这篇的工程套路（异步刷新、分层池化、多查询解耦、beam 检索）比它的模型结构更有复用价值。坑在于论文没公开 Recall@K 的具体提升幅度和压缩策略的消融，复现前自己盯紧 Recall@K 与 P99 延迟的帕累托曲线；另外 +0.26% DAU 是超大流量大盘下的收益，中小流量场景别直接对标这个数。

原文：AlphaXiv