阿里-FORGE-生成式推荐SID构建
这里阅读一下阿里 FORGE ：《Forming Semantic Identifiers for Generative Retrieval in Industrial Datasets》，应该正在投稿 ICLR2026，公开了一个比以往最大的数据集还要大 100 倍的用于生成式推荐 SID 评估的数据集，专门提出一整套用来评估 SID 质量如何，并针对工业界 SID 的构建给出阿里的一些策略吧，这里就主要写一下自己的一些见解吧，可能需要一定的了解才能看懂。
论文链接：https://arxiv.org/abs/2509.20904
代码链接：https://github.com/selous123/al_sid
1. 背景
生成式推荐在工业界 SID 如果重整的话，流程其实非常复杂，需要很长时间，比如要训一个量化的模型，然后要给流式的数据打好 SID ，之后才能开始训练生成式的部分，这部分训练又需要几天才能收敛，收敛后要想评估效果，还需要上线 Infer，看下 Hitrate 这些，或者上线 ab 看看指标。
2. 方法与实验
与 OneRec 不同的是，在 文本、图像 fusion 之前，他们自己就先进行对比学习了一下，并且这里采用 RQ-VAE 为主，对齐进行一些优化防止冲突，并且作者认为冲突对效果影响很大【我觉得这个跟具体的场景相关，有的场景可能数据量没那么大，并不一定会有那么多冲突，这个影响也就变小了】，认为 OneRec 采用 RQ-Kmeans 因为他冲突率低【我觉得有部分原因还是因为 RQ-Kmeans 比较简单，不需要怎么训练吧，只需要离线拿一小部分数据训好之后就固定这部分了】，而本文主要是对 3 层 codebook 的最后一层做了一些防冲突的策略。下面是相关的实验：
具体而言作者采用的方法是对最后一层加了随机策略，让其均匀，不冲突 ：
infer 的时候采用动态 beam-search，300 --> 600 --> 1200 去减少一些开销，理论上，比 1200 --> 1200 -->1200 应该会节省个 40% 左右的 Infer 资源吧，主要是前两层节省了，不过这不是文章重点，作者没有放实验。
用于召回的模型是 Qwen2-0.5B 采用中文 prompt：
这个跟 OneRec 就不太一样了，不知道这个是否靠谱，如果用户历史行为非常长呢？上万？OneRec 会对用户历史行为进行压缩，然后通过 kv 给到 decoder，而这里是不是要对历史进行一些筛选了，这样的 Infer 消耗的资源线上不知道是否扛得住也存疑。
有个实验还比较有趣：
这种递增的 codebook：1024–>4096–>32768 对效果有一定提升。
3. 总结
其实整体认知还是比较接近的，有一定收获：动态 beam-search 可以节省计算资源，变长 codebook 对效果可能有帮助，较少 codebook 冲突率可能对效果有帮助。不过整体采用的 decoder-only 的生成，怀疑线上不一定扛得住。一定要加这些 prompt 么，效果会比直接通过 Encoder 取提取用户侧信息好么，这个存疑。