如果两个商品共享前三个 code，模型会把它们视为近邻。但这个“近”究竟应该表示：
- 标题相似？
- 被相似用户点击？
- 还是仅仅因为码本塌缩，太多商品挤进了同一个 code？
LC-Rec 用多任务把既定商品 index 接到语言与行为上，却没有直接规定 tokenizer 应该为推荐优化什么。LETTER: Learnable Item Tokenization for Generative Recommendation 把问题反过来：
不先问生成器够不够大，先定义什么是一个好的推荐 token。
它提出三个准则：Hierarchical Semantics、Collaborative Signals、Code Assignment Diversity。
30 秒看懂本文
- LC-Rec 留下的问题：内容重构得到的 Semantic ID 不一定保存协同近邻，码本还可能只使用少量 code。
- LETTER 的答案：保留 RQ-VAE 的语义重构，加入与 SASRec/LightGCN 商品 embedding 的对比对齐，再用受约束聚类正则分散 code；总体目标是 (\mathcal L_{\rm Sem}+\alpha\mathcal L_{\rm CF}+\beta\mathcal L_{\rm Div})。
- 最重要的证据：Beauty 上 LETTER-TIGER 的 NDCG@10 为 0.0364，TIGER 为 0.0331；加入协同正则把 0.0331 提到 0.0351，协同与多样性一起到 0.0357，ranking loss 后到 0.0364。
图 1：LETTER 认为 ID 设计是一个多目标问题；仅仅能重构商品内容，不代表适合预测与排序。
用八件商品理解三个目标
沿用八件商品。一个理想 code 空间至少要同时表达三件事。
目标一：层次语义
I06 泳镜 与 I07 泳帽 可以共享前缀：
I06 = 〈运动, 水上, 游泳, 眼部〉
I07 = 〈运动, 水上, 游泳, 头部〉
这由 RQ-VAE 对内容 embedding 的逐级残差重构提供。
目标二：协同一致
I03 攀岩鞋 与 I04 镁粉袋 文本不相似，但用户序列中常共现。若预训练 SASRec 或 LightGCN 的 item embeddings 很近，LETTER 希望量化后的表示也靠近。
目标三：分配多样
若八件商品中六件的第一级都被分到 code 0，剩余 code 从未训练，生成器面对一个极不均衡的分支。LETTER 希望 assignments 更均匀，并让不同簇的 code embeddings 分开。
图 2：语义、协同与均衡可能互相冲突。LETTER 的工作是把冲突显式暴露给目标函数，而不是假设一次量化自动解决。
核心公式：三个损失定义一种商品语言
LETTER 的总目标：
[ \mathcal L_{\text{LETTER}} =\mathcal L_{\text{Sem}} +\alpha\mathcal L_{\text{CF}} +\beta\mathcal L_{\text{Div}}. ]
(\mathcal L_{\text{Sem}})：内容语义
这是 RQ-VAE 的重构、codebook 与 commitment 损失。它让量化后的 (\hat z_i) 保留原内容向量 (z_i)，并形成粗到细的 residual codes。
(\mathcal L_{\text{CF}})：协同对齐
先用传统协同模型得到商品 embedding (h_i)。在 batch 中，把同一商品的 ((\hat z_i,h_i)) 当正例，其他商品当负例，用双向对比学习拉近两个空间：
[ \ell_i^{z\to h} =-\log \frac{\exp(\operatorname{sim}(\hat z_i,h_i)/\tau)} {\sum_j\exp(\operatorname{sim}(\hat z_i,h_j)/\tau)}. ]
这不是要求两个空间完全相同，而是让协同近邻在量化语义中更可辨认。
(\mathcal L_{\text{Div}})：code 多样性
LETTER 对 code embeddings 做受约束 k-means 风格的聚类：同簇样本靠近其中心，异簇被推开，并限制簇大小，使 code 分布不被少数簇垄断。它解决的不是“每件商品唯一”，而是词表有没有被有效使用。
三个权重隐含真正的建模选择：(\alpha) 太大，ID 可能过拟合旧交互、损失冷启动语义；(\beta) 太大，模型会为均匀而牺牲自然簇；太小则退回内容 RQ-VAE。
从 tokenizer 到推荐器
LETTER 不是一个固定生成器，而是一套可插入后端的 item tokenizer。论文分别替换 TIGER 与 LC-Rec 的原 tokenizer：
商品内容 ─┐
├→ LETTER tokenizer → Semantic IDs
CF embedding┘ ↓
TIGER / LC-Rec
tokenizer 离线训练完成后冻结，再把生成器训练在新 IDs 上。
图 3：LETTER 改进的是“词表”，因此可与不同 generative backbone 组合；代价是仍存在前后两阶段失配。
Ranking-guided generation 在修什么
逐 token 交叉熵把正确 code 当唯一正例，所有错误 code 都是负例，但推荐更关心候选之间的相对顺序。LETTER 在解码分布中调节温度 (\tau)：温度较低时，概率质量更集中在高分 hard negatives，训练更强调正例与最容易混淆候选的间隔。
论文把这种目标与 one-way partial AUC 建立联系。直觉是：
不是平均推开所有负例，
而是优先把真正会挤进 Top-K 的负例压下去。
推理仍使用目录 trie 约束，只允许合法 Semantic ID。
训练和推理的完整流程
1. 训练 SASRec 或 LightGCN，保存每件商品的 h_i
2. 编码商品内容，得到 z_i
3. 用 Sem + αCF + βDiv 训练 LETTER tokenizer
4. 冻结 tokenizer，把所有历史转换成 ID 序列
5. 训练 TIGER 或 LC-Rec 生成器，并加入 ranking guidance
6. 用 trie-constrained beam search 返回合法商品
这条流水线比 TIGER 更强，也更复杂：传统推荐器变成 tokenizer 的教师；内容编码器、RQ-VAE、生成器分别有版本；三个损失与温度都需调参。
实验究竟证明了什么
LETTER 同时在 TIGER 与 LC-Rec 后端上验证：
图 4：两个生成后端、三个数据集都获得提升，说明收益不只来自某个特定 backbone。
| 后端 | 数据集 | 原始 | + LETTER |
|---|---|---|---|
| TIGER | Instruments | 0.0797 | 0.0831 |
| TIGER | Beauty | 0.0331 | 0.0364 |
| TIGER | Yelp | 0.0213 | 0.0231 |
| LC-Rec | Instruments | 0.0772 | 0.0854 |
| LC-Rec | Beauty | 0.0374 | 0.0418 |
| LC-Rec | Yelp | 0.0199 | 0.0211 |
Beauty/TIGER 的消融能拆出贡献：
| 组件 | NDCG@10 |
|---|---|
| TIGER tokenizer | 0.0331 |
| + collaborative regularization | 0.0351 |
| + diversity regularization | 0.0335 |
| + 两者 | 0.0357 |
| + ranking-guided loss | 0.0364 |
多样性单独提升有限，但与协同正则互补。论文还测量 code 层面的协同邻居相似度：TIGER 为 0.0849/0.1135，LETTER 为 0.2760/0.3312，说明地址确实更接近协同结构，而不仅是生成器碰巧更好。
Identifier 长度从 2 增到 4 时效果改善，从 4 墠到 8 反而下降。更多层提高表达容量，也拉长自回归路径；任何一位出错都会使完整 ID 失效。
它失败在哪里
1. tokenizer 与推荐器仍然分开
LETTER 的协同教师来自预训练 CF 模型，但最终生成器的 loss 仍不能直接反向进入 tokenizer。它缩小了目标差距，没有消除两阶段训练。
2. 它依赖一个传统推荐教师
若 SASRec/LightGCN embedding 有流行度偏差、曝光偏差或旧分布，LETTER 会把这些结构固化到 ID。生成模型不再是摆脱传统推荐器，而是在继承它。
3. 三个目标可能互相拉扯
语义自然簇往往不均匀；强制均衡会切开真实类别。协同近邻也会随季节与平台策略变化。固定 (\alpha,\beta) 难覆盖所有目录区间。
4. 地址漂移仍在
重新训练 CF 教师或 tokenizer 会改变 ID。协同信号比内容变化更快，因此版本更新甚至可能更频繁。
5. 证据仍是中小目录
提升在多个数据集一致，但没有证明码本均衡、trie 解码和多阶段训练在千万商品、实时反馈下的成本。
下一篇为什么会出现
LETTER 已经把协同信号写入 tokenizer，却仍是：
先把 ID 学好并冻结 → 再训练生成器适应它
如果推荐器发现某个 code 很难由历史预测，它无法告诉 tokenizer 改地址；tokenizer 也不知道生成器当前把用户表示成什么。下一篇 ETEGRec 会在两者之间增加两个对齐目标，并交替更新 tokenizer 与生成器，让商品语言和用户模型共同演化。
本篇批判性结论：LETTER 把“商品 ID”从工程预处理提升为一个可检验的建模对象。它最有价值的不是又加两个 loss，而是提出了评审任何 Semantic ID 的三问：保留了什么语义、保留了什么行为、码本是否真正被使用。