小红书精读：Separating Thinking from Spelling for Efficient Generative Recommendation

生成式推荐提速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，否则加速数字会显得太乐观。

原文：AlphaXiv