小红书精读：PinGER: Token-Efficient Generative Retrieval with Semantic IDs

生成式召回省6倍token，还更快 🔍

各位算法同学们，生成式召回有个被忽略的尴尬数字：100 条 beam 里，一级码只有 11.9 个不同的，剩下全挤在同一前缀上互相重叠。Pinterest 这篇 PinGER 就是在解决这类问题，还顺手把输入 token 砍了 6 倍。

📄 PinGER: Token-Efficient Generative Retrieval with Semantic IDs

🔧 不对称注意力掩码：训练时每个历史 item 由 L 个 SID token 加 1 个 dense token 组成，SID 能读 dense 历史和自身浅层码，但后续任何位置都不读过去的 SID。于是服务时直接丢掉 SID，一个 item 只喂一个 token，算的还是同一个函数——训练拿到 TIGER 那样的 L 个标签监督，服务只付 embedding 召回的输入成本。

🧩 前缀多样性惩罚：不是按步惩罚，而是按候选与已选 beam 共享前缀的深度收费，逐条选 beam，把 beam 按层级推开，这一步很关键。

⚙️ 服务栈三件事：cascade attention 让共享历史每请求只读一次，而不是每个 beam 读一次；约束解码保证每个 beam 都落在语料里真实存在的 SID 上；SID 到 item 用本地索引解析，不走网络调用。

📊 离线 Recall@100 与 TIGER 持平，但服务 token 少 6 倍。

📈 同等服务 token 下比 TIGER 高 9.5%，是线上 embedding 召回 PinRec 的 3.9 倍。

✅ 加上惩罚后，beam 覆盖的一级前缀数量是贪心解码的 7.9 倍。

✅ 服务侧 W=30 时比 paged attention 快 10.9 倍，W=400 时快 32 倍，KV 内存少 12.6 倍。

📈 线上 Related Pins 替换 PinRec：整体 save +0.62%，新 Pin 的 save +3.60%，端到端延迟降 0.7%，被替掉的 ANN 检索成本直接归零。

我的判断：做召回、尤其内容更新快、长尾重的场景，这篇的实验方式可以直接借鉴——它把“和 embedding 召回比”放进了线上 A/B，而不是只跟自己比。要盯的是新内容 save 这个指标，3.60% 和 0.62% 的差距说明收益主要来自冷启动和长尾，存量热门内容别指望。坑在训练侧：自定义稀疏注意力 kernel 加 SID 分词质量，复现成本不低，分词分得不好，掩码再巧也白搭。

原文：AlphaXiv