AkaliKong
SID的discussion
1、作者您好，感谢您对开源社区作出的贡献。有个问题想请教您一下：当一个SID对应很多个item（当然是由于SID可能效果不太好），那有啥好办法能避免或者缓解这个冲突吗？Tiger中是加入了最后一个位置索引，但我认为当重复数量较高时是不实用的，谢谢～
当欲分配的SID已经被占用时，可以找最近邻的SID代替，我看有个文章是这么做的Purely Semantic Indexing for LLM-based Generative Recommendation and Retrieval
1、作者您好，感谢您对开源社区作出的贡献。有个问题想请教您一下：当一个SID对应很多个item（当然是由于SID可能效果不太好），那有啥好办法能避免或者缓解这个冲突吗？Tiger中是加入了最后一个位置索引，但我认为当重复数量较高时是不实用的，谢谢～
In our current RQ-VAE, we use a Sinkhorn-based uniform semantic mapping. We will soon release more advanced SID generation methods, including RQ-Kmeans and RQ-OPQ.
个人认为，单个SID的聚合最大簇不高的时候，并不太需要关注这个问题，交给后续的步骤就好（例如精排，混排，或其他的打分策略），直接用递增ID也是一个可用的策略。
1、作者您好，感谢您对开源社区作出的贡献。有个问题想请教您一下：当一个SID对应很多个item（当然是由于SID可能效果不太好），那有啥好办法能避免或者缓解这个冲突吗？Tiger中是加入了最后一个位置索引，但我认为当重复数量较高时是不实用的，谢谢～
SID冲突这块可以关注我们的新工作FORGE，使用KNN 以及 Random based的方式来缓解了语义ID的冲突，伴随着其他的SID优化已经通过大量离线实验（基于从淘宝采样的十天数据集 -> 140亿交互，15%Hit Rate提升）和在线AB验证（增加0.35%总交易数量），相关方案已经在淘宝召回场景推全。同时我们也公开了相关实验代码和淘宝的真实工业界数据（140亿真实交互，比现有最大数据集大近一百倍）
当欲分配的SID已经被占用时，可以找最近邻的SID代替，我看有个文章是这么做的Purely Semantic Indexing for LLM-based Generative Recommendation and Retrieval
其实这样的情况下，随机分配的方法比最近邻的方式好（大规模数据验证过之后），并且时间复杂度会小很多
当欲分配的SID已经被占用时，可以找最近邻的SID代替，我看有个文章是这么做的Purely Semantic Indexing for LLM-based Generative Recommendation and Retrieval
其实这样的情况下，随机分配的方法比最近邻的方式好（大规模数据验证过之后），并且时间复杂度会小很多
想请教一下，随机分配的方法，分配到的新SID，还具有semantic吗？体感上像是随便给他分配到一个类目下
当欲分配的SID已经被占用时，可以找最近邻的SID代替，我看有个文章是这么做的Purely Semantic Indexing for LLM-based Generative Recommendation and Retrieval
其实这样的情况下，随机分配的方法比最近邻的方式好（大规模数据验证过之后），并且时间复杂度会小很多
想请教一下，随机分配的方法，分配到的新SID，还具有semantic吗？体感上像是随便给他分配到一个类目下
最后一层随机就可以，最简单的例子是淘宝这边（码本大小是三层，每一层是8192）很多店铺会卖苹果手机，导致这些苹果手机对应的SID很可能都是一样的(比如$<C_1 1248>C_2 6475><C_3 1>$可能挂载了一千个苹果手机)，然后一部分SID就没有被利用（比如$<C_1 1248>C_2 6475><C_3 2>$）。我们的方法只会在第三层随机打散，例如第二个$<C_1 1248>C_2 6475>$的商品进来第三层编码就会被分到$<C_3 2>$（假设$<C_3 1>$是第三层的第一个编码且已经被使用）。可以看到论文当中Random的方式比KNN的效果更好（我们给出的解释是这样的话SID的精度会更高，均匀性更好，在RQ这样残差的方式下第三层还剩下的语义信息不如精度更重要），并且方案复杂度小很多。
@fukairui 打散的代码在哪里可以找到
https://github.com/selous123/al_sid/blob/main/SID_generation/ID_collision.sql
用sql写的，因为上亿的商品pandas处理起来很慢，所以内部用的是数据库集群来处理（如果想转换为pandas，可以参考来修改，逻辑比较简单的）
@fukairui 感谢分享！
请教一个问题，这种随机打散的方式会不会对于生成式推荐的 quality 有一些影响？我理解这种方法能够帮助降低 ID collpase, 但是不可避免的破坏了最后一层的 sematnic 结构，在训练的时候会不会导致模型学习到 conflict 的信息，影响最后生成的 quality?
或者另外一个思路是，如果数据量够大，那么这个最后一层的 codebook id 其实就是起到了一个和传统推荐系统里面用到的 hased sparse id 的作用，通过大数据训练让模型 memory 一部分物品信息
