推荐算法日报 · 2026-10-27

总览

今天的 arXiv 有点冷清，真正值得展开讲的其实就一篇，但主线很清楚：生成式召回的瓶颈不在预填充、而在解码。这个判断很关键——beam=100 时 beam search 吃掉九成生成时间，说明过去压缩输入 token 的努力方向偏了一半。这篇的做法我很欣赏：backbone 只跑一遍，把历史压成一个极小的 concept 向量，后面带 trie 约束的 beam search 全交给一个两层轻量 decoder 承担，SID、trie、自回归分解一个都没改，属于对线上系统改动最小、最容易落地的优化；它把“蒸馏在这个逐层级目标上等价于 teacher 引导的 label smoothing”讲清楚了，平滑质量落在 trie 合法后缀上，这个视角值得记一笔。离线结果也站得住：七个数据集基本追平甚至略超自己的 teacher，50ms p95 下吞吐高 3.2–8.6 倍，而且加宽 beam 几乎不增加成本——k=1000 比原来 k=100 还快、召回约三倍，这种扩展性才是真价值。不足也明说：全程没有线上 A/B，所谓 production-style 只是自己搭的计时环境，concept 只有 1KiB，音乐这类重复消费场景还得外挂 history copy pointer，说明“一个向量概括用户”在长历史、高重复领域信息量确实不够。今天优先看这一篇，重点看解码侧拆分的动机和加宽 beam 的成本曲线，别被离线那几个点的涨幅带跑。

论文列表

1. Separating Thinking from Spelling for Efficient Generative Recommendation

• 论文链接：AlphaXiv
• 更新时间：2026-10-23 17:59 UTC
• 机构：未披露机构
• 工业优先级：强

生成式推荐提速8.6倍：重活别让大模型干

各位算法同学们，生成式推荐里最贵的其实不是读历史；真正占时间的，是拼出 SID。beam width 100 时，trie 约束的 beam search 能吃掉最多 91% 的生成时间；预填充早跑完了，大部分时间都花在逐 code 解码上。这篇把生成 SID 的负担从大骨干模型上分走，而且改动很小。

📄 Separating Thinking from Spelling for Efficient Generative Recommendation

🔧 把思考和拼写拆开：backbone 只读一次融合后的历史，每个 item 一个 token，输出定长的 next-item concept z；整个 SID 拼写交给轻量的 KV-cached decoder，条件只有 z 和已生成前缀。

🧩 ID 体系一点没动：SID、trie、自回归分解照旧，逐层左到右的 beam search 全部留在轻 decoder 里，所以每个保留前缀仍然能落到真实 item 上；这点和并行生成、扩散那类先出码再筛合法的路线不一样。

⚙️ 训练上单靠 cross-entropy 就能逼近全 backbone 精度，再加蒸馏还能涨；重复消费重的场景（音乐流媒体）额外加一个 history pointer，把用户反复回到的 item 直接抄回来。

📊 七个数据集（电商、电影、音乐流媒体）上，精度与标准生成式推荐、以及融合输入的全 backbone teacher 持平或更好。

📈 生产风格 serving 下，batch 128 时吞吐是 FusedGR 的 2.8–5.1 倍；50ms p95 延迟预算内是 3.2–8.6 倍。加速比随候选预算、SID 深度、backbone 规模一起涨。

✅ 生成 1000 个候选比 teacher 生成 100 个还快；换成 1.5B LLM backbone，吞吐追平 69M teacher 且精度更高；3B 模型上对 FusedGR 有 16 倍加速。

总结感想：这套思路对骨干大、候选池大、延迟卡在 50ms 的召回场景最直接有用。评估时别只盯 Recall@K，要看同一 p95 预算下的吞吐，以及候选池放大后收益曲线的走向。风险在于 concept 是定长的，长尾兴趣和强序列依赖会被压掉；低重复数据集上让 decoder 直接看历史并没有稳定收益，音乐这类重复消费还得靠 pointer 兜底。对比对象建议选 FusedGR 而不是 FlatGR，否则加速数字会显得太乐观。