我最近在系统地扫生成式推荐方向的论文坦白讲大多数工作还停在把LLM套到推荐上的层面要么把物品ID塞进词表让语言模型去预测要么用文本描述作为物品的软标识。这类做法都有个共同的问题——物品对语言模型来说仍然是生词模型对物品的理解完全取决于人工设计的标识而不是推荐任务本身。直到我读到ETEGRec这篇论文才看到一条不一样的思路把物品分词这件事本身也交给系统来学。标题里的端到端和可学习不是噱头它确实是在重新定义生成式推荐里最底层的那一环——物品如何被表示成token。如果你也在做生成式推荐、序列推荐或者对LLM与推荐系统的结合点感兴趣这篇论文值得仔细读。1. 生成式推荐先把物品语言化这一关过了1.1 传统推荐系统的ID范式与它的天花板在聊ETEGRec之前得先说清楚我们到底在解决什么问题。过去十几年的推荐系统基本是ID的天下。每个用户、每个物品分配一个全局唯一的编号然后把这个编号映射成稠密向量embedding靠协同过滤信号学交互模式。这个范式非常成熟工业界至今仍是主流但有几个结构性问题越来越明显。一是冷启动。新物品没有交互记录它的ID embedding就是随机的模型很难给出合理的推荐。二是跨域迁移。换一个平台、换一个品类ID空间就全变了之前学到的embedding基本作废。三是可解释性。ID本身不携带任何语义信息推荐结果的解释只能靠事后牵强附会。这些问题的根源在于ID是一种人为指定的标识它跟物品本身的内容属性完全没有关联。语言模型火了之后很多人想的是能不能用文本描述来替代ID比如把物品的标题、类别、属性拼接起来当作一种语义ID让语言模型去处理。这个思路确实缓解了冷启动和跨域问题但代价是——文本描述的质量决定了推荐的上限。物品标题可能是冗长甚至误导的广告语商品属性可能残缺不全。而且更关键的是文本语义和用户行为偏好并不总是对齐的。用户购买一个物品很大程度上看的是行为层面的协同信号而不是文本层面读起来像不像。1.2 语言模型视角下的物品分词到底是什么生成式推荐的基本范式是把推荐任务重写成序列生成任务。给定用户的历史交互序列每个交互对应物品的某种token序列模型自回归地生成下一个物品的token序列然后拿生成的token序列去解码出具体的物品。这里就出现了一个此前很少被认真对待的问题**物品应该被表示成什么样的token序列**如果你用过中文分词工具很容易理解这个问题的微妙之处。同一个句子按字切分、按词切分、按子词切分后续语义分析的难度完全不一样。武汉市长江大桥这种经典歧义就是分词粒度不当造成的。物品也一样——一个物品该被拆成几个token每个token代表什么语义粒度这些token之间的组合规则是什么早期工作最常见的做法是直接复用把物品直接映射成一个special token类似[ITEM_123]或者把文本描述截断成固定长度的token序列。前者本质上是把ID搬进了语言模型后者则是让NLP模型去做一件它设计初衷之外的事——理解推荐语料。两者都没有把分词当作一个可以优化的环节来对待。1.3 可学习分词和智驾端到端的思路同源这里我想提一个热词智驾端到端。最近关于端到端的讨论很多其实核心思想是一致的——把原来分阶段处理、各自优化的模块打通成一个整体来联合优化。智驾里传统方案是感知、预测、规划分模块pipeline每个模块单独调优最后串起来却会出现误差累积和梯度割裂端到端方案干脆把整条链路塞进一个大模型让系统自己学习如何从传感器信号直接输出驾驶决策。推荐里的端到端可学习物品分词也是同样的逻辑。传统做法是先按NLP规则或启发式方法把物品转成token分词这一步是外部固定的然后再训练推荐模型分词质量差推荐模型再努力也很难补回来。ETEGRec的方案是让分词器tokenizer和推荐器共享梯度、联合训练分词的表征方式本身被推荐任务引导着去演化。推荐器学得不好分词器要背锅分词器的参数也得跟着调整——这正是端到端三个字的关键含义。2. ETEGRec的框架里哪些组件在可学习2.1 整体架构从连续表示到离散token再回到连续空间ETEGRec的框架可以拆成三块来看物品编码器、可学习分词器、生成式推荐器。我按数据流的顺序捋一遍。物品编码器的作用是把一个物品映射成连续的语义表示。这里的输入可以是任何模态的特征——文本描述、图片向量、类别属性等甚至可以是ID embedding。它本质上是给物品一个初始语义坐标好让分词器有料可用。这个编码器不需要特别复杂能承载物品的内容信息就行因为在训练过程中它的表示会被推荐信号持续修正。可学习分词器是整个论文最核心的模块。它把物品的连续表示转换成离散token序列。这里要注意的是它不是简单地做最近邻量化或固定聚类。具体实现上论文设计的是**多码本multiple codebooks**机制每个物品的连续表示被映射到若干个码本上每个码本选出最匹配的一个codeword码字最终得到的token序列就是这些码字索引的组合。可以把它想象成做菜一道菜物品需要从肉类、蔬菜、调料几个维度的码本里各选一种组合起来就是一个完整的菜单描述token序列。为什么要用多码本而不是直接映射成单个token因为单个token只能表达这是哪个物品表达不了物品之间的内在结构。多码本则让token序列携带了这个物品属于什么类别有什么属性在语义空间中处于什么位置等多层次信息这对于后续推荐器的推理是决定性的。生成式推荐器负责消费用户历史交互的token序列自回归地预测下一个物品的token序列。它的结构可以是Transformer decoder也可以是任何一种序列模型。它的输入输出都是token级别的预测完一组token之后我们再用分词表把token解码回物品ID完成推荐。2.2 可学习到底体现在哪个环节一句话概括整个分词器含码本和映射函数的参数全部参与反向传播由推荐任务的损失函数来驱动更新。这和传统做法的本质区别在于目标函数。传统的分词是独立于推荐目标完成的比如用深度聚类算法把物品embedding聚成几百类每类给一个token。聚类目标追求的是同一类的物品表示相近但没有人保证同一类的物品用户行为也相近。ETEGRec的做法是让推荐器的交叉熵损失直接指导分词器更新。推荐器预测下一个物品的token序列预测错了梯度回传到分词器分词器就会调整自己的码本、调整映射函数让物品的token表达方式更有利于推荐器的预测。**分词器不是为了表示得好而学而是为了推荐得准而学。**这是整个架构的灵魂。2.3 双向训练推荐引导分词分词也影响推荐论文里还强调了双向的概念这在很多解读里容易被忽略。双向指的是不仅推荐器要适应分词器给出的token序列分词器也要反过来适应推荐器的预测需求。这不是一句空话它体现在训练策略上。具体而言训练是交替进行的先固定分词器训练推荐器让推荐器学会消费当前的token序列再固定推荐器训练分词器让分词器生成更有利于推荐器预测的token序列。这就像一个翻译官和助手之间的磨合翻译官先按自己的方式翻译助手学着猜过一阵子助手告诉翻译官你这种翻译让我的猜测准确率上不去了换种表达方式于是翻译官调整措辞助手重新适应循环往复直到两者配合达到最佳。这个交替训练的过程让分词器和推荐器互相迁就、共同进化而不是单方面让推荐器迁就一个固定的分词方案。方向对了后面所有实验结果才有解释力。3. ETEGRec和ID类、语义ID类方法相比改的是底层逻辑3.1 三种物品表示方案的直观对比很多解读把ETEGRec归为语义ID方法的升级版这个说法不够准确。它和之前的方法相比改的不是某个组件而是整条设计逻辑。我列了一个对比表方便大家看差异。方案物品标识如何产生分词是否参与训练对推荐目标是否自适应跨域/冷启动能力传统ID embedding人工分配ID查表映射否否ID不承载特征弱文本语义ID如FD基于NLP规则/特征工程否分词固定否取决于文本质量中生成式推荐的ID映射如TIGER逐级聚类生成索引否聚类固定方向对齐但无法端到端调优中ETEGRec可学习分词由推荐信号驱动自动生成是端到端是直接对齐推荐目标较强传统ID的问题是标识没有含义文本语义ID的问题是含义不由推荐决定早期生成式推荐用的聚类式编码比如逐级VQ-VAE则卡在分词环节没法通过推荐损失来直接优化。ETEGRec试图把这些坑一次性填掉。3.2 为什么说端到端比两段式在误差传导上更优两段式方案先分词再训练推荐器有一个工程师都懂的问题误差传导被截断。分词阶段产生的错误在推荐阶段会被当作既成事实接受下来推荐器只能在不完美的输入之上做有限修正。典型的例子分词把两个本来行为模式完全不同的物品硬分到同一个token类别里推荐器看到的历史记录就会包含大量噪声无论怎么调注意力权重这个噪声都消不掉的。ETEGRec的端到端联合优化让分词器能感知到这种错误的物品划分方式正在拉低推荐准确率于是下一轮迭代里它就会把这两个物品切分到不同的token上。误差不是单向传导而是双向反馈。这个设计在数学上等价于把一个分阶段的优化问题改成了联合优化问题解空间大了很多整套系统也更容易逼近全局最优。我个人的理解是这其实也回应了智驾端到端领域的核心争论分模块pipeline的每个模块各自最优并不等于系统整体最优只有让所有模块共享同一个优化目标系统才有可能跳出局部最优拼凑这个陷阱。推荐系统虽然规模远小于智驾但逻辑是一致的。3.3 语义ID常踩的坑ETEGRec怎么避开我做序列推荐方向的时间不算短对文本语义ID方案一直保留态度。问题在于文本语义和用户行为偏好的错位。举个例子一个电商平台上有两款耳机一款主打降噪、办公、长时间佩戴舒适另一款主打低音、电竞、线控麦克风。从文本语义看这两款耳机在NLP向量空间里可能相距很远但在用户行为数据里它们经常被同一批用户先后购买。当分词器完全基于文本生成时模型就倾向于认为这两款耳机完全不同于是推荐时给出的是语义近似但行为未必相关的商品。这恰恰是推荐系统最忌讳的。ETEGRec的可学习分词器因为码本参数是在推荐损失驱动下更新的它可以学到行为上相近的物品即使文本差异大也应该在token空间中靠得近。换句话说语义信息只是初始化的线索最终的分词规则由行为数据来定。这种先有语义冷启动、再通过推荐反馈纠偏的方式比纯文本语义ID要稳得多。4. 训练与实现细节里那些容易被跳过、却决定成败的环节4.1 离散token无法反向传播怎么处理文章读到这很多人会问一个很实在的问题从连续表示到离散token中间存在一个不可导的取样或argmax操作梯度怎么传这是所有做离散化工作的通用难题。论文里采用的路数是比较常见的编码器输出连续向量通过码本距离计算得到最匹配的码字索引这一段的梯度用直通估计器straight-through estimator来近似。也就是说前向传播时我们走离散的码字索引反向传播时直接把梯度穿透到编码器的连续输出上假装没经过离散这一步。这个技巧在VQ-VAE系列工作里被验证过多次属于这个领域的标准操作。但要注意直通估计只是个工程妥协它不是免费的。它会让梯度信号带上噪声码本和编码器之间的更新经常出现不同步。实践里常见的补救措施是加一个commitment loss强制编码器输出和码本保持匹配同时用小学习率更新码本避免码本漂移。4.2 码本坍缩多码本分词最难缠的问题做量化类模型的人对码本坍缩codebook collapse一定不陌生。具体的现象是训练一段时间后某些码本里大部分codeword都闲置了只有少数几个codeword频繁被选中token序列的多样性急剧下降。为什么这对ETEGRec尤其致命因为如果码本坍缩了所有物品的token序列在部分维度上完全一致分词就退回了少数几个token加一个特殊ID的原始状态多码本设计的价值直接归零。针对这个问题我个人能想到的合理手段有几种一是在训练早期对codeword做随机初始化增强二是引入码本正交性约束强制多个码本各司其职、语义不重叠三是使用对抗式的commitment loss变体让码本的利用率尽量均匀。论文是否用了其中某一种或全部手段得看原版实现但作为复现者这几手我都建议加上否则实验很容易出现前期效果猛如虎跑了几天后漂移归零的情况。4.3 交替训练的节奏与初始化策略前面说过论文的核心训练方式是先固定分词器训推荐器再固定推荐器训分词器的交替循环。这里有个工程问题交替的粒度怎么定是一个batch交替一次还是一个epoch交替一次交替太频繁两个模块都在移动目标训练不稳定交替太稀疏收敛速度又太慢。基于我自己的复现经验稳妥的做法是以epoch为单位交替且分词器的学习率要比推荐器小一个量级左右。原因很好理解分词器改的是整个表示体系的底层编码规则动得太猛会让推荐器努力积攒的上下文知识瞬间失效而推荐器只是在这个规则之上做拟合对变化的容忍度更低。谁动得快、谁动得慢这个节奏很微妙。另外初始化也很关键。可学习分词器起步时完全是一张白纸如果直接拿随机化的码本上手训练早期token序列基本是乱序的推荐器根本无从学起。合理的初始化方案是先用物品的内容特征比如文本embedding跑几轮预训练让物品的token序列初步具备语义区分度然后再进入端到端联合训练阶段。预训练解决的是起步阶段别乱跑联合训练解决的是跑起来之后往对的方向调。4.4 推理阶段生成物品token的序列长度问题生成式推荐在推理时推荐器逐token生成预测结果。物品被分词成多个token意味着一个交互项被摊成多个生成步序列长度会成倍放大。这对工业落地的挑战是实实在在的生成延迟直接和经济收益挂钩。为了限制成本论文的做法是在推理阶段施加一个约束——生成的结果必须能在分词表中完整解码出一个合法物品。更实用的做法是结合束搜索beam search在解码前几步只保留那些能映射到真实物品的候选路径。我的一些朋友在复现时也采取了提前截断候选重排的策略先宽束搜索生成若干候选token序列再用一个轻量级的打分公式对候选物品做重排。这样既保住了生成式推荐端到端生成的特色又避免了逐token解码在工业场景下不可用的问题。5. 从论文的评估与消融能读出哪些信号5.1 评测结果里真正值得关注的是相对提升的一致性论文的离线评测我重点看了它和几个代表性的baseline的对比标准序列推荐模型、基于聚类的生成式推荐基线、基于文本语义ID的基线。整体结论是ETEGRec在公开数据集上的推荐准确率指标有明显的提升而且在较长交互历史的用户分组上优势更大。这里我感觉信息量很大。长序列用户意味着用户交互中包含了丰富的物品组合信息对分词器来说这种复杂的共现模式更考验它捕捉物品关系的能力。传统ID方法在长序列场景下往往受限于ID embedding的表达瓶颈而ETEGRec的token序列因为带有语义结构推荐器可以更容易地从长历史中提到用户喜欢的模式。另一个我注意到的点是并不是所有数据集上都赢了。在一些品牌效应很强、用户忠诚度极高的场景里比如美妆品类用户反复买同一品牌可学习分词的优势会被削弱——因为这种场景下ID就够用了复杂的语义结构带来的增益不大。这提醒了我们端到端可学习分词也不是万能的它更适合物品语义丰富、用户行为多样化的场景。5.2 消融实验告诉我们的三个结论消融实验是对设计决策最直接的验证。我记得比较清楚几个关键的消融方向。第一个是去掉端到端联合训练改为固定分词器只训推荐器。效果掉得不少这说明分词器被推荐目标持续修正这件事确实在起作用而不是单纯多了一组参数在给模型提容量。第二个是去掉多码本设计退化成单码本。效果同样下降。这验证了多码本能让token序列携带多维度语义信息而不是简单地增加token长度来换取表达能力。第三个是替换初始化特征。用纯随机初始化代替内容特征预训练效果显著变差。这说明内容特征是起点行为反馈是终点这一设计逻辑是对的。如果一上来就让分词器盲学搜索空间大到不现实只有先给一个有语义含义的起点推荐信号才能高效地把表示往行为对齐的方向拉。5.3 如果要复现我建议盯住哪几个指标复现这类工作我个人的建议是不要只看推荐准确率。至少要盯住三组指标分词质量指标比如码本利用率、token序列的平均重复率、不同物品token序列之间的距离分布。这些指标能帮你判断分词器是否正常工作。推荐性能指标常规的Recall、NDCG系列。训练稳定性指标每个epoch的推荐器loss波动幅度、码本更新频率。如果波动太大大概率是交替训练节奏没调好得回头改学习率。很多时候模型效果崩了不是架构问题而是码本已经坍缩了但你还在傻傻地跑T1个epoch。训练过程中周期性地看码本利用率和token分布的多样性能省下大量无效调参时间。6. 这篇论文没解决、但我认为必须正视的问题6.1 生成式推荐的效率瓶颈依然存在端到端可学习分词让物品表达变得更丰富代价是序列变长、解码变慢。论文本身主要在离线评测上论证效果但在线推荐的延迟约束下逐token生成的方式和传统双塔检索的差距仍然巨大。一种缓释思路是先端到端训练、后蒸馏把训练好的生成式推荐器作为teacher蒸馏出一个轻量的检索模型用于线上把可学习分词的表达优势迁移过去同时保证响应速度。这个思路虽然不是论文内容但我认为和论文的主旨走向完全一致。6.2 新物品上线时的再分词机制冷启动问题在可学习分词框架下有个变体训练完的码本如何为一个新物品生成token序列它能直接用训练好的编码器分词器走一遍前向但前提是——这个新物品的内容特征在编码器看来不是完全陌生的。如果新物品包含了从未见过的属性组合映射出的token序列可能落入码本中稀疏甚至空白的区域推荐器会变得无所适从。更务实的做法是常驻一个兜底策略比如给新物品临时生成一组基于语义近邻的伪交互先把它映射到码本的热区再逐步靠用户反馈修正。6.3 可解释性分词本身是不是一个天然的推荐理由最后说一点我自己比较兴奋的方向。物品分词将物品拆成了几个token每个token对应码本中的一个语义类别。如果我把推荐器预测出的下一个物品token序列打开看一眼实际上就能做到一种粒度很细的解释模型不是因为用户之前买了A所以推荐B而是因为用户的历史物品中都包含了某个语义码字而推荐物品的这个码字和它一致。这种解释不需要额外的归因工具而是内生在表示里的。论文里没有专门讨论这条线但我觉得这是可学习分词在可解释推荐上最大的潜在价值。剩下的问题就是怎么把码本中每个码字的含义用自然语言描述出来让用户真正能看懂。如果你打算入这个方向的坑我建议不要只停留在复现论文结果上。试着把码本可视化出来看看同一码字下聚集了哪些物品再把用户的历史token序列和推荐结果的token序列拼在一起看你可能会发现一些论文里没有写、但对业务非常有洞察力的规律。