1. 从“生成式推荐”这个词说起这个竞赛到底在比什么第一次看到“LLM-Rec 2026 生成式推荐竞赛”这个标题很多人脑子里冒出来的第一个问题不是“怎么参赛”而是“生成式推荐到底是个什么东西”。我刚开始接触这个方向的时候也有同样的困惑——推荐系统我熟协同过滤、双塔召回、粗排精排那一套流程闭着眼睛都能画出来但“生成式”三个字加在前面整个事情的逻辑就变了。传统推荐系统的核心思路是“打分”。给定一个用户和一个物品模型输出一个分数代表这个用户对这个物品的偏好程度。整个链路围绕“如何更准确地打分”来设计特征工程、样本构造、模型结构、损失函数所有优化都指向同一个目标。但生成式推荐换了一个思路——它不再问“这个物品该打多少分”而是问“这个用户接下来最可能对什么物品产生行为”然后把这个问题转化成一个序列生成任务。换句话说模型不是在给候选物品排序而是在直接“写出”用户可能感兴趣的物品。这个思路的转变带来的影响是深远的。传统推荐系统需要维护一个庞大的候选物品池召回阶段从百万级物品中筛出几千个排序阶段再从中选出几十个展示给用户。而生成式推荐理论上可以跳过“候选池”这个概念直接根据用户的历史行为序列自回归地生成下一个可能被交互的物品标识。这就像是从“从菜单里选菜”变成了“直接报菜名”——后者对模型的理解能力和生成能力要求更高但上限也更高。这个竞赛之所以值得关注是因为它把生成式推荐这个前沿方向变成了一个可量化、可对比的实战问题。参赛者需要在统一的框架下用LLM的能力去解决推荐场景中的核心问题如何把用户行为序列编码成LLM能理解的输入如何设计生成目标让模型输出合理的推荐结果如何在有限的算力下完成训练和推理。这些问题的答案不仅决定了竞赛的成绩也决定了生成式推荐这条路到底能走多远。我写这个学习笔记的目的很简单把我在准备这个竞赛过程中理解到的核心概念、踩过的坑、以及一些实操层面的思考记录下来。如果你也在关注这个方向或者准备参加类似的竞赛希望这些内容能帮你少走一些弯路。接下来的内容会从任务理解、数据构造、模型设计、训练策略、评估方法这几个维度展开每个部分都会尽量落到“具体怎么做”的层面而不是停留在概念介绍。2. 生成式推荐的任务形式化把推荐问题翻译成语言模型能懂的话2.1 从“预测下一个物品”到“预测下一个Token”要让LLM做推荐第一步就是要把推荐问题“翻译”成语言模型能处理的形式。语言模型的核心任务是预测下一个Token所以我们需要把用户的行为序列和物品信息都转化成Token序列。最直观的做法是给每个物品分配一个唯一的Token ID然后把用户的历史交互序列表示成Token序列。比如用户依次交互了物品A、B、C那输入就是[A, B, C]模型需要预测下一个Token也就是用户接下来最可能交互的物品。这个思路听起来很简单但实际操作中会遇到几个关键问题。第一个问题是物品数量。真实的推荐场景中物品池可能有百万甚至千万级别如果每个物品一个Token那词表就会爆炸。LLM的词表通常只有几万到十几万直接扩展词表会导致Embedding层参数急剧增加训练和推理的成本都难以承受。所以需要设计一种编码方案把大量物品映射到有限的Token空间里。第二个问题是行为序列的长度。用户的历史行为可能很长但LLM的上下文窗口是有限的。如何在有限的窗口内保留最关键的行为信息是一个需要仔细权衡的问题。第三个问题是物品的语义信息。传统的ID类特征比如物品ID、类目ID是离散的、无语义的但LLM擅长处理有语义的文本。如果能把物品的标题、描述、类目等信息利用起来让模型在生成时不仅依赖ID共现关系还能理解物品的语义内容效果可能会更好。2.2 物品Token化的几种主流方案目前生成式推荐中物品Token化的方案主要有三种每种都有自己的适用场景和取舍。方案一层次化编码。这个思路是把物品的ID拆解成多个层级的Token。比如一个物品的ID是12345可以拆成[1, 2, 3, 4, 5]五个Token或者按层级拆成[12, 34, 5]。这样做的好处是不需要扩展词表直接用现有的数字Token就能表示所有物品。但缺点是序列长度会增加而且模型需要学会从这种拆解中恢复出物品的完整信息。实际操作中通常会采用类似“语义ID”的做法先用聚类或者向量量化把物品映射到几个层级的编码上每个层级对应一个Token这样既能控制序列长度又能保留一定的语义信息。方案二文本描述替代ID。这个思路是直接用物品的标题、描述等文本信息作为输入让模型基于文本内容进行生成。比如用户交互了“某款无线耳机”输入就是“某款无线耳机”这几个字的Token序列。这种方案的最大优势是充分利用了LLM的语义理解能力模型可以根据物品的文本描述来判断用户可能喜欢什么。但缺点是推理时需要生成完整的文本描述然后再匹配到具体物品这个匹配过程可能引入误差而且生成文本的计算开销比生成几个Token要大得多。方案三混合方案。结合前两种方案用少量Token表示物品的核心语义同时保留文本描述作为辅助信息。比如用3-5个Token表示物品的语义ID同时在输入中拼接物品的标题文本。这样模型既能通过语义ID快速定位物品又能通过文本理解物品的具体内容。这种方案在实际竞赛中比较常见因为它平衡了效率和效果。提示选择哪种Token化方案取决于你的算力预算和竞赛的评估指标。如果算力有限层次化编码是更稳妥的选择如果追求极致效果且有足够的推理资源混合方案值得尝试。2.3 输入输出的序列构造细节确定了Token化方案之后接下来要设计具体的输入输出格式。一个典型的生成式推荐输入序列可能长这样[用户特征Token] [行为1] [行为2] ... [行为N] [预测目标]其中用户特征Token可以包括年龄、性别、地域等离散化后的信息行为序列就是用户历史交互的物品Token预测目标就是模型需要生成的物品Token。这里有几个细节需要注意。第一行为序列的顺序很重要通常按时间顺序排列最近的行为放在最后因为模型预测的是“下一个”行为。第二是否需要加入时间间隔信息比如两个行为之间隔了1天还是30天这个信息对预测下一个行为是有帮助的。可以把时间间隔离散化成几个档位作为额外的Token插入序列中。第三是否需要加入行为类型比如点击、购买、收藏是不同的行为类型可以在每个行为Token前加一个类型Token来区分。输出端的设计相对简单就是让模型生成目标物品的Token序列。但这里有一个关键问题如何保证生成的Token序列能对应到一个真实存在的物品如果模型生成了一个不存在的Token组合那这个推荐就是无效的。常见的做法是在解码时使用约束解码只允许生成合法的物品Token组合。另一种做法是在训练时就让模型见过所有合法的物品Token组合这样模型生成非法组合的概率会很低。3. 数据构造竞赛数据集里藏着哪些坑3.1 行为序列的截断与填充策略真实场景中的用户行为序列长度差异很大有的用户只有几次交互有的用户有上千次交互。而LLM的上下文窗口是固定的所以需要对序列进行截断或填充。截断策略看似简单其实有很多讲究。最直接的做法是取最近的N个行为但这样会丢失早期的行为信息。对于兴趣比较稳定的用户早期行为可能比近期行为更能反映长期偏好。另一种做法是按时间衰减采样近期行为保留的概率更高但早期行为也有机会被保留。还有一种做法是分段截断比如取最近N个行为同时从更早的行为中均匀采样M个这样既能捕捉近期兴趣又能保留长期偏好。填充策略相对简单通常用特殊的Padding Token补齐到固定长度。但需要注意的是Padding Token不应该参与损失计算否则模型会学会预测Padding浪费容量。我在实际操作中发现一个容易被忽略的细节行为序列的去重。有些用户会在短时间内重复交互同一个物品比如反复查看某个商品如果不去重序列中会出现大量重复Token既浪费上下文窗口又会让模型过度关注这个物品。通常的做法是对连续重复的行为去重只保留第一次或最后一次。3.2 负样本的选择为什么随机负采样不够用生成式推荐的训练目标通常是让模型最大化正样本用户实际交互的物品的生成概率同时最小化负样本的生成概率。负样本的选择直接影响模型的学习效果。最简单的负采样策略是随机采样从物品池中随机选一些物品作为负样本。但随机负样本太容易区分了模型很快就能学会“正样本是用户交互过的负样本是随机选的”导致学到的区分能力很弱。更好的做法是使用难负样本比如选择与正样本相似但不被用户交互的物品。相似度的计算可以基于物品的类目、品牌、价格等属性也可以基于物品的Embedding向量。另一种策略是使用Batch内负采样把同一个Batch中其他用户的正样本作为当前用户的负样本。这种做法在双塔模型中很常见在生成式推荐中也可以借鉴。它的好处是不需要额外维护负样本池而且负样本的难度会随着训练过程动态变化。还有一个容易被忽略的点是负样本的数量。负样本太少模型学不到足够的区分能力负样本太多训练成本会急剧增加。通常的做法是根据算力预算和模型收敛情况来调整从少量负样本开始逐步增加。3.3 数据泄露的隐蔽形式竞赛中最让人头疼的问题之一就是数据泄露。有些泄露是显式的比如测试集的特征出现在了训练集中有些泄露是隐式的比如时间信息的不一致。在生成式推荐中一个常见的隐式泄露是未来信息泄露。比如在构造用户行为序列时如果不小心把预测目标之后的行为也放进了输入序列那模型在训练时就能“看到答案”导致评估指标虚高。避免这个问题的方法很简单严格按照时间顺序切分数据确保输入序列中的所有行为都发生在预测目标之前。另一个隐蔽的泄露是物品流行度泄露。如果训练集和测试集的物品分布差异很大模型可能会学到“训练集中常见的物品就是好推荐”这种捷径而不是真正理解用户的偏好。检查方法是统计训练集和测试集中物品的分布如果差异显著就需要考虑对训练集进行重采样或对物品进行加权。注意在竞赛中任何看起来“好得不像真的”的指标提升都值得花时间检查是否存在数据泄露。我见过太多因为泄露导致线上评估翻车的案例。4. 模型设计LLM做推荐需要改什么4.1 基座模型的选择不是越大越好选择基座模型时很多人第一反应是“越大越好”但在推荐场景中这个直觉不一定对。推荐任务对模型的语义理解能力要求没有通用NLP任务那么高但对推理效率的要求很高因为线上服务需要在毫秒级返回结果。从我的经验来看7B到13B参数的模型是比较合适的起点。这个规模的模型有足够的容量来学习用户行为模式同时推理成本可控。如果算力充足可以尝试更大的模型但需要仔细评估推理延迟是否满足要求。如果算力有限小模型1B到3B也能跑出不错的效果关键是要做好特征工程和训练策略。另一个需要考虑的因素是模型是否支持长上下文。推荐场景中的用户行为序列可能很长如果模型的上下文窗口只有2K或4K就需要频繁截断丢失信息。支持8K以上上下文的模型在这方面更有优势。4.2 微调策略全量微调还是参数高效微调全量微调的效果通常更好但成本也更高。对于7B以上的模型全量微调需要大量的GPU显存而且训练时间很长。参数高效微调方法如LoRA、Prefix Tuning可以在保持大部分预训练知识的同时用较少的参数完成适配。在推荐场景中我倾向于推荐LoRA。原因是推荐任务和通用语言任务之间的差异比较大全量微调可能会让模型“遗忘”预训练阶段学到的语言知识而LoRA通过低秩适配器来注入推荐领域知识对原始参数的改动较小更不容易出现灾难性遗忘。而且LoRA的推理开销很小可以把适配器合并到基座模型中不增加额外的推理延迟。LoRA的秩rank是一个关键超参数。秩太小适配能力不足秩太大参数量增加训练成本上升。通常从8或16开始尝试根据验证集效果调整。学习率一般设置在1e-4到3e-4之间比全量微调的学习率大一些。4.3 位置编码的适配问题LLM的位置编码是为自然语言序列设计的但推荐场景中的行为序列有其特殊性。比如行为之间的时间间隔差异很大两个行为可能相隔几分钟也可能相隔几个月。标准的位置编码无法表达这种时间间隔信息。一种解决方案是在输入序列中显式加入时间间隔Token。比如在每两个行为之间插入一个表示时间间隔的Token这样模型可以通过注意力机制学习到时间间隔对预测的影响。另一种方案是修改位置编码的计算方式让位置编码不仅取决于位置索引还取决于实际的时间戳。这种做法需要对模型结构进行修改实现成本较高。在实际竞赛中显式加入时间间隔Token是更实用的选择。时间间隔可以离散化成几个档位比如“1小时内”“1天内”“1周内”“1月内”“更久”每个档位对应一个Token。这样既保留了时间信息又不增加太多序列长度。4.4 输出层的约束解码前面提到过生成式推荐需要保证生成的Token序列对应真实存在的物品。约束解码是实现这个目标的关键技术。最简单的约束解码是在每一步生成时只保留合法的Token。比如如果物品Token是5位数字那每一步只能生成0-9这10个Token。但这样还不够因为不是所有5位数字组合都对应真实物品。更严格的做法是维护一个前缀树Trie把所有合法物品的Token序列插入树中解码时根据当前前缀在树中查找合法的下一个Token。这样就能保证生成的序列一定是合法物品。前缀树的构建和维护需要一些工程工作但带来的收益是显著的无效推荐的比例可以降到接近零。在竞赛中无效推荐会直接拉低评估指标所以这个工作值得做。5. 训练与推理的工程细节5.1 训练数据的批次构造生成式推荐的训练数据构造和常规LLM训练有所不同。常规LLM训练中每条训练样本是一个独立的序列批次内的序列通过Padding对齐。但在推荐场景中同一个用户可能有多个训练样本每个行为都可以作为预测目标这些样本之间有很强的关联性。一种做法是把同一个用户的多个样本放在同一个批次中这样模型可以在一次前向传播中看到用户的多个行为片段学习效率更高。但这样做需要注意样本之间的顺序避免信息泄露。另一种做法是随机打乱所有样本让批次内的样本来自不同用户这样训练更稳定但可能损失一些用户级别的信息。我个人的经验是在训练初期使用随机打乱的方式让模型先学到通用的行为模式在训练后期切换到用户级别的批次构造让模型学习用户个性化的偏好。这种课程学习Curriculum Learning的策略在实践中效果不错。5.2 学习率调度与 warmupLLM微调的学习率调度对最终效果影响很大。推荐场景中的训练数据通常比预训练数据少得多所以需要更谨慎地设置学习率。Warmup是必须的通常设置总训练步数的5%到10%作为warmup阶段。在warmup期间学习率从0线性增加到设定的最大值避免训练初期梯度太大导致模型发散。Warmup之后可以使用余弦退火或线性衰减让学习率逐渐降低帮助模型收敛到更好的局部最优。有一个容易忽略的细节是不同层的学习率。LLM的底层通常学习通用的语言表示顶层学习任务相关的表示。在推荐微调中底层参数可以设置较小的学习率甚至冻结顶层参数设置较大的学习率。这种分层学习率的策略可以防止底层语言知识被破坏同时让顶层充分适配推荐任务。5.3 推理阶段的加速技巧竞赛中的推理效率直接影响最终排名因为通常会有推理时间限制。生成式推荐的推理瓶颈主要在自回归解码过程每生成一个Token都需要一次前向传播。加速推理的方法有几种。KV Cache是最基本的优化把已经计算过的Key和Value缓存起来避免重复计算。投机解码Speculative Decoding可以用一个小模型快速生成候选Token然后用大模型验证在保证生成质量的同时提升速度。量化可以把模型权重从FP16降到INT8或INT4减少显存占用和计算量但可能会损失一些精度。在实际竞赛中我建议优先做好KV Cache和批次推理。KV Cache是标配批次推理可以把多个用户的请求合并成一个批次充分利用GPU的并行能力。量化需要谨慎使用因为推荐任务对数值精度比较敏感量化后的模型效果可能会明显下降。5.4 线上服务的延迟优化如果竞赛涉及线上服务评估延迟优化就是必须考虑的问题。生成式推荐的延迟主要来自两个方面模型推理时间和物品匹配时间。模型推理时间可以通过前面提到的加速技巧来优化。物品匹配时间是指把模型生成的Token序列映射到具体物品的时间。如果使用前缀树匹配时间通常很短因为树的高度就是Token序列的长度通常只有几位。但如果物品池很大前缀树的规模也会很大需要做好内存管理。另一个优化方向是预生成。对于活跃用户可以在用户没有发起请求时提前生成推荐结果缓存起来。当用户真正发起请求时直接返回缓存结果延迟可以降到很低。这种做法的挑战是如何保证缓存的新鲜度因为用户的兴趣可能会快速变化。6. 评估指标与结果分析6.1 离线指标的选择与解读生成式推荐的离线评估通常使用Top-K召回率、NDCG、MRR等指标。这些指标的计算方式和传统推荐系统类似但有一个关键区别生成式推荐的输出是Token序列需要先解码成物品ID再和真实交互物品进行匹配。Top-K召回率是最直观的指标表示模型生成的Top-K个推荐中有多少个是用户实际交互过的物品。K的选择取决于应用场景竞赛中通常取10或20。NDCG考虑了推荐结果的排序质量位置越靠前的正确推荐贡献越大。MRR只关注第一个正确推荐的位置适合评估“最快找到用户感兴趣物品”的能力。解读这些指标时需要注意生成式推荐的指标通常比传统推荐系统低一些因为生成任务的难度更大。不要因为指标绝对值低就否定方案关键是对比不同方案之间的相对提升。6.2 错误分析模型到底错在哪里指标只能告诉我们模型表现如何但不能告诉我们为什么。错误分析是找到改进方向的关键。常见的错误类型有几种。重复推荐模型反复生成同一个物品即使这个物品已经在用户的历史行为中出现过。这通常是因为训练数据中重复行为太多模型学会了“重复就是安全”的策略。热门偏置模型倾向于推荐热门物品因为热门物品在训练数据中出现频率高模型学会了“推荐热门物品大概率不会错”。长尾失效对于长尾物品模型的推荐效果明显下降因为训练数据中长尾物品的样本太少。针对每种错误类型有不同的改进方向。重复推荐可以通过在训练时对重复行为降权来解决。热门偏置可以通过对热门物品降采样或对长尾物品升采样来缓解。长尾失效可以通过引入物品的语义信息来改善让模型即使没见过某个物品的ID也能通过语义理解来判断是否应该推荐。6.3 消融实验的设计消融实验是验证每个模块贡献的标准方法。在生成式推荐中可以消融的模块包括物品Token化方案、用户特征、时间间隔信息、负采样策略、微调方法等。设计消融实验时要注意控制变量。每次只改变一个因素其他因素保持不变。同时要确保实验的可重复性固定随机种子多次运行取平均值。一个常见的误区是只报告最终指标不报告中间过程。实际上训练过程中的损失曲线、验证集指标变化趋势都能提供有价值的信息。比如如果训练损失持续下降但验证指标不升反降说明模型过拟合了需要增加正则化或减少训练轮数。7. 我在准备这个竞赛时踩过的几个坑7.1 词表扩展的陷阱刚开始的时候我想当然地认为“给每个物品分配一个Token”是最直接的方案于是尝试扩展LLM的词表把物品ID作为新的Token加入。结果发现两个问题一是Embedding层的参数量急剧增加训练显存不够用二是新加入的Token没有预训练知识需要从零开始学习收敛很慢。后来改用层次化编码把物品ID拆成几个层级的Token复用现有的数字Token问题就解决了。这个经历让我明白在LLM时代“复用预训练知识”比“从头学习”重要得多。7.2 忽略时间信息的代价有一版模型我没有加入时间间隔信息结果发现模型对“用户刚交互过的物品”和“用户很久以前交互过的物品”一视同仁导致推荐结果偏向于用户长期兴趣忽略了短期兴趣的变化。加入时间间隔Token后指标有了明显提升尤其是短期兴趣相关的指标。这个坑让我意识到推荐场景中的“时间”是一个非常重要的信号不能忽略。而且时间信息的引入方式也很重要显式Token比隐式位置编码更有效。7.3 约束解码的实现细节约束解码的前缀树实现看起来简单但实际写代码时遇到了几个问题。一是前缀树的构建效率如果物品池很大逐个插入Token序列会很慢。后来改用批量构建先把所有物品的Token序列按前缀排序然后递归构建树速度快了很多。二是解码时的回溯如果当前前缀在树中不存在需要回溯到上一个合法前缀这个逻辑容易写错。建议在实现时多写单元测试确保各种边界情况都能正确处理。7.4 评估指标的计算陷阱计算Top-K召回率时有一个容易忽略的细节如果用户实际交互了多个物品而模型只推荐了其中一个那召回率应该算多少常见的做法是算“命中率”即只要推荐列表中包含任意一个真实交互物品就算命中。但更严格的做法是计算“召回率”即推荐列表中包含的真实交互物品数量除以真实交互物品总数。两种计算方式的结果差异可能很大需要根据竞赛的评估标准来选择。8. 后续可以继续深挖的方向生成式推荐这个方向还有很多值得探索的问题。比如如何把多模态信息物品图片、视频融入到生成过程中让模型不仅能理解文本描述还能理解视觉内容。再比如如何设计更好的解码策略在生成多样性和生成准确性之间取得平衡。还有如何把生成式推荐和传统推荐系统结合起来用生成式模型做召回用传统模型做排序发挥各自的优势。从竞赛的角度来看接下来的重点可能是优化推理效率和多任务学习。推理效率决定了方案能否在实际场景中落地多任务学习则可以让一个模型同时处理多种推荐场景比如首页推荐、搜索推荐、相关推荐提升模型的通用性。我在这个方向上也还在不断学习很多想法还需要通过实验来验证。如果你也在做类似的事情欢迎交流讨论。这个领域变化很快保持学习和实验的节奏比什么都重要。
1. 从“生成式推荐”这个词说起这个竞赛到底在比什么第一次看到“LLM-Rec 2026 生成式推荐竞赛”这个标题很多人脑子里冒出来的第一个问题不是“怎么参赛”而是“生成式推荐到底是个什么东西”。我刚开始接触这个方向的时候也有同样的困惑——推荐系统我熟协同过滤、双塔召回、粗排精排那一套流程闭着眼睛都能画出来但“生成式”三个字加在前面整个事情的逻辑就变了。传统推荐系统的核心思路是“打分”。给定一个用户和一个物品模型输出一个分数代表这个用户对这个物品的偏好程度。整个链路围绕“如何更准确地打分”来设计特征工程、样本构造、模型结构、损失函数所有优化都指向同一个目标。但生成式推荐换了一个思路——它不再问“这个物品该打多少分”而是问“这个用户接下来最可能对什么物品产生行为”然后把这个问题转化成一个序列生成任务。换句话说模型不是在给候选物品排序而是在直接“写出”用户可能感兴趣的物品。这个思路的转变带来的影响是深远的。传统推荐系统需要维护一个庞大的候选物品池召回阶段从百万级物品中筛出几千个排序阶段再从中选出几十个展示给用户。而生成式推荐理论上可以跳过“候选池”这个概念直接根据用户的历史行为序列自回归地生成下一个可能被交互的物品标识。这就像是从“从菜单里选菜”变成了“直接报菜名”——后者对模型的理解能力和生成能力要求更高但上限也更高。这个竞赛之所以值得关注是因为它把生成式推荐这个前沿方向变成了一个可量化、可对比的实战问题。参赛者需要在统一的框架下用LLM的能力去解决推荐场景中的核心问题如何把用户行为序列编码成LLM能理解的输入如何设计生成目标让模型输出合理的推荐结果如何在有限的算力下完成训练和推理。这些问题的答案不仅决定了竞赛的成绩也决定了生成式推荐这条路到底能走多远。我写这个学习笔记的目的很简单把我在准备这个竞赛过程中理解到的核心概念、踩过的坑、以及一些实操层面的思考记录下来。如果你也在关注这个方向或者准备参加类似的竞赛希望这些内容能帮你少走一些弯路。接下来的内容会从任务理解、数据构造、模型设计、训练策略、评估方法这几个维度展开每个部分都会尽量落到“具体怎么做”的层面而不是停留在概念介绍。2. 生成式推荐的任务形式化把推荐问题翻译成语言模型能懂的话2.1 从“预测下一个物品”到“预测下一个Token”要让LLM做推荐第一步就是要把推荐问题“翻译”成语言模型能处理的形式。语言模型的核心任务是预测下一个Token所以我们需要把用户的行为序列和物品信息都转化成Token序列。最直观的做法是给每个物品分配一个唯一的Token ID然后把用户的历史交互序列表示成Token序列。比如用户依次交互了物品A、B、C那输入就是[A, B, C]模型需要预测下一个Token也就是用户接下来最可能交互的物品。这个思路听起来很简单但实际操作中会遇到几个关键问题。第一个问题是物品数量。真实的推荐场景中物品池可能有百万甚至千万级别如果每个物品一个Token那词表就会爆炸。LLM的词表通常只有几万到十几万直接扩展词表会导致Embedding层参数急剧增加训练和推理的成本都难以承受。所以需要设计一种编码方案把大量物品映射到有限的Token空间里。第二个问题是行为序列的长度。用户的历史行为可能很长但LLM的上下文窗口是有限的。如何在有限的窗口内保留最关键的行为信息是一个需要仔细权衡的问题。第三个问题是物品的语义信息。传统的ID类特征比如物品ID、类目ID是离散的、无语义的但LLM擅长处理有语义的文本。如果能把物品的标题、描述、类目等信息利用起来让模型在生成时不仅依赖ID共现关系还能理解物品的语义内容效果可能会更好。2.2 物品Token化的几种主流方案目前生成式推荐中物品Token化的方案主要有三种每种都有自己的适用场景和取舍。方案一层次化编码。这个思路是把物品的ID拆解成多个层级的Token。比如一个物品的ID是12345可以拆成[1, 2, 3, 4, 5]五个Token或者按层级拆成[12, 34, 5]。这样做的好处是不需要扩展词表直接用现有的数字Token就能表示所有物品。但缺点是序列长度会增加而且模型需要学会从这种拆解中恢复出物品的完整信息。实际操作中通常会采用类似“语义ID”的做法先用聚类或者向量量化把物品映射到几个层级的编码上每个层级对应一个Token这样既能控制序列长度又能保留一定的语义信息。方案二文本描述替代ID。这个思路是直接用物品的标题、描述等文本信息作为输入让模型基于文本内容进行生成。比如用户交互了“某款无线耳机”输入就是“某款无线耳机”这几个字的Token序列。这种方案的最大优势是充分利用了LLM的语义理解能力模型可以根据物品的文本描述来判断用户可能喜欢什么。但缺点是推理时需要生成完整的文本描述然后再匹配到具体物品这个匹配过程可能引入误差而且生成文本的计算开销比生成几个Token要大得多。方案三混合方案。结合前两种方案用少量Token表示物品的核心语义同时保留文本描述作为辅助信息。比如用3-5个Token表示物品的语义ID同时在输入中拼接物品的标题文本。这样模型既能通过语义ID快速定位物品又能通过文本理解物品的具体内容。这种方案在实际竞赛中比较常见因为它平衡了效率和效果。提示选择哪种Token化方案取决于你的算力预算和竞赛的评估指标。如果算力有限层次化编码是更稳妥的选择如果追求极致效果且有足够的推理资源混合方案值得尝试。2.3 输入输出的序列构造细节确定了Token化方案之后接下来要设计具体的输入输出格式。一个典型的生成式推荐输入序列可能长这样[用户特征Token] [行为1] [行为2] ... [行为N] [预测目标]其中用户特征Token可以包括年龄、性别、地域等离散化后的信息行为序列就是用户历史交互的物品Token预测目标就是模型需要生成的物品Token。这里有几个细节需要注意。第一行为序列的顺序很重要通常按时间顺序排列最近的行为放在最后因为模型预测的是“下一个”行为。第二是否需要加入时间间隔信息比如两个行为之间隔了1天还是30天这个信息对预测下一个行为是有帮助的。可以把时间间隔离散化成几个档位作为额外的Token插入序列中。第三是否需要加入行为类型比如点击、购买、收藏是不同的行为类型可以在每个行为Token前加一个类型Token来区分。输出端的设计相对简单就是让模型生成目标物品的Token序列。但这里有一个关键问题如何保证生成的Token序列能对应到一个真实存在的物品如果模型生成了一个不存在的Token组合那这个推荐就是无效的。常见的做法是在解码时使用约束解码只允许生成合法的物品Token组合。另一种做法是在训练时就让模型见过所有合法的物品Token组合这样模型生成非法组合的概率会很低。3. 数据构造竞赛数据集里藏着哪些坑3.1 行为序列的截断与填充策略真实场景中的用户行为序列长度差异很大有的用户只有几次交互有的用户有上千次交互。而LLM的上下文窗口是固定的所以需要对序列进行截断或填充。截断策略看似简单其实有很多讲究。最直接的做法是取最近的N个行为但这样会丢失早期的行为信息。对于兴趣比较稳定的用户早期行为可能比近期行为更能反映长期偏好。另一种做法是按时间衰减采样近期行为保留的概率更高但早期行为也有机会被保留。还有一种做法是分段截断比如取最近N个行为同时从更早的行为中均匀采样M个这样既能捕捉近期兴趣又能保留长期偏好。填充策略相对简单通常用特殊的Padding Token补齐到固定长度。但需要注意的是Padding Token不应该参与损失计算否则模型会学会预测Padding浪费容量。我在实际操作中发现一个容易被忽略的细节行为序列的去重。有些用户会在短时间内重复交互同一个物品比如反复查看某个商品如果不去重序列中会出现大量重复Token既浪费上下文窗口又会让模型过度关注这个物品。通常的做法是对连续重复的行为去重只保留第一次或最后一次。3.2 负样本的选择为什么随机负采样不够用生成式推荐的训练目标通常是让模型最大化正样本用户实际交互的物品的生成概率同时最小化负样本的生成概率。负样本的选择直接影响模型的学习效果。最简单的负采样策略是随机采样从物品池中随机选一些物品作为负样本。但随机负样本太容易区分了模型很快就能学会“正样本是用户交互过的负样本是随机选的”导致学到的区分能力很弱。更好的做法是使用难负样本比如选择与正样本相似但不被用户交互的物品。相似度的计算可以基于物品的类目、品牌、价格等属性也可以基于物品的Embedding向量。另一种策略是使用Batch内负采样把同一个Batch中其他用户的正样本作为当前用户的负样本。这种做法在双塔模型中很常见在生成式推荐中也可以借鉴。它的好处是不需要额外维护负样本池而且负样本的难度会随着训练过程动态变化。还有一个容易被忽略的点是负样本的数量。负样本太少模型学不到足够的区分能力负样本太多训练成本会急剧增加。通常的做法是根据算力预算和模型收敛情况来调整从少量负样本开始逐步增加。3.3 数据泄露的隐蔽形式竞赛中最让人头疼的问题之一就是数据泄露。有些泄露是显式的比如测试集的特征出现在了训练集中有些泄露是隐式的比如时间信息的不一致。在生成式推荐中一个常见的隐式泄露是未来信息泄露。比如在构造用户行为序列时如果不小心把预测目标之后的行为也放进了输入序列那模型在训练时就能“看到答案”导致评估指标虚高。避免这个问题的方法很简单严格按照时间顺序切分数据确保输入序列中的所有行为都发生在预测目标之前。另一个隐蔽的泄露是物品流行度泄露。如果训练集和测试集的物品分布差异很大模型可能会学到“训练集中常见的物品就是好推荐”这种捷径而不是真正理解用户的偏好。检查方法是统计训练集和测试集中物品的分布如果差异显著就需要考虑对训练集进行重采样或对物品进行加权。注意在竞赛中任何看起来“好得不像真的”的指标提升都值得花时间检查是否存在数据泄露。我见过太多因为泄露导致线上评估翻车的案例。4. 模型设计LLM做推荐需要改什么4.1 基座模型的选择不是越大越好选择基座模型时很多人第一反应是“越大越好”但在推荐场景中这个直觉不一定对。推荐任务对模型的语义理解能力要求没有通用NLP任务那么高但对推理效率的要求很高因为线上服务需要在毫秒级返回结果。从我的经验来看7B到13B参数的模型是比较合适的起点。这个规模的模型有足够的容量来学习用户行为模式同时推理成本可控。如果算力充足可以尝试更大的模型但需要仔细评估推理延迟是否满足要求。如果算力有限小模型1B到3B也能跑出不错的效果关键是要做好特征工程和训练策略。另一个需要考虑的因素是模型是否支持长上下文。推荐场景中的用户行为序列可能很长如果模型的上下文窗口只有2K或4K就需要频繁截断丢失信息。支持8K以上上下文的模型在这方面更有优势。4.2 微调策略全量微调还是参数高效微调全量微调的效果通常更好但成本也更高。对于7B以上的模型全量微调需要大量的GPU显存而且训练时间很长。参数高效微调方法如LoRA、Prefix Tuning可以在保持大部分预训练知识的同时用较少的参数完成适配。在推荐场景中我倾向于推荐LoRA。原因是推荐任务和通用语言任务之间的差异比较大全量微调可能会让模型“遗忘”预训练阶段学到的语言知识而LoRA通过低秩适配器来注入推荐领域知识对原始参数的改动较小更不容易出现灾难性遗忘。而且LoRA的推理开销很小可以把适配器合并到基座模型中不增加额外的推理延迟。LoRA的秩rank是一个关键超参数。秩太小适配能力不足秩太大参数量增加训练成本上升。通常从8或16开始尝试根据验证集效果调整。学习率一般设置在1e-4到3e-4之间比全量微调的学习率大一些。4.3 位置编码的适配问题LLM的位置编码是为自然语言序列设计的但推荐场景中的行为序列有其特殊性。比如行为之间的时间间隔差异很大两个行为可能相隔几分钟也可能相隔几个月。标准的位置编码无法表达这种时间间隔信息。一种解决方案是在输入序列中显式加入时间间隔Token。比如在每两个行为之间插入一个表示时间间隔的Token这样模型可以通过注意力机制学习到时间间隔对预测的影响。另一种方案是修改位置编码的计算方式让位置编码不仅取决于位置索引还取决于实际的时间戳。这种做法需要对模型结构进行修改实现成本较高。在实际竞赛中显式加入时间间隔Token是更实用的选择。时间间隔可以离散化成几个档位比如“1小时内”“1天内”“1周内”“1月内”“更久”每个档位对应一个Token。这样既保留了时间信息又不增加太多序列长度。4.4 输出层的约束解码前面提到过生成式推荐需要保证生成的Token序列对应真实存在的物品。约束解码是实现这个目标的关键技术。最简单的约束解码是在每一步生成时只保留合法的Token。比如如果物品Token是5位数字那每一步只能生成0-9这10个Token。但这样还不够因为不是所有5位数字组合都对应真实物品。更严格的做法是维护一个前缀树Trie把所有合法物品的Token序列插入树中解码时根据当前前缀在树中查找合法的下一个Token。这样就能保证生成的序列一定是合法物品。前缀树的构建和维护需要一些工程工作但带来的收益是显著的无效推荐的比例可以降到接近零。在竞赛中无效推荐会直接拉低评估指标所以这个工作值得做。5. 训练与推理的工程细节5.1 训练数据的批次构造生成式推荐的训练数据构造和常规LLM训练有所不同。常规LLM训练中每条训练样本是一个独立的序列批次内的序列通过Padding对齐。但在推荐场景中同一个用户可能有多个训练样本每个行为都可以作为预测目标这些样本之间有很强的关联性。一种做法是把同一个用户的多个样本放在同一个批次中这样模型可以在一次前向传播中看到用户的多个行为片段学习效率更高。但这样做需要注意样本之间的顺序避免信息泄露。另一种做法是随机打乱所有样本让批次内的样本来自不同用户这样训练更稳定但可能损失一些用户级别的信息。我个人的经验是在训练初期使用随机打乱的方式让模型先学到通用的行为模式在训练后期切换到用户级别的批次构造让模型学习用户个性化的偏好。这种课程学习Curriculum Learning的策略在实践中效果不错。5.2 学习率调度与 warmupLLM微调的学习率调度对最终效果影响很大。推荐场景中的训练数据通常比预训练数据少得多所以需要更谨慎地设置学习率。Warmup是必须的通常设置总训练步数的5%到10%作为warmup阶段。在warmup期间学习率从0线性增加到设定的最大值避免训练初期梯度太大导致模型发散。Warmup之后可以使用余弦退火或线性衰减让学习率逐渐降低帮助模型收敛到更好的局部最优。有一个容易忽略的细节是不同层的学习率。LLM的底层通常学习通用的语言表示顶层学习任务相关的表示。在推荐微调中底层参数可以设置较小的学习率甚至冻结顶层参数设置较大的学习率。这种分层学习率的策略可以防止底层语言知识被破坏同时让顶层充分适配推荐任务。5.3 推理阶段的加速技巧竞赛中的推理效率直接影响最终排名因为通常会有推理时间限制。生成式推荐的推理瓶颈主要在自回归解码过程每生成一个Token都需要一次前向传播。加速推理的方法有几种。KV Cache是最基本的优化把已经计算过的Key和Value缓存起来避免重复计算。投机解码Speculative Decoding可以用一个小模型快速生成候选Token然后用大模型验证在保证生成质量的同时提升速度。量化可以把模型权重从FP16降到INT8或INT4减少显存占用和计算量但可能会损失一些精度。在实际竞赛中我建议优先做好KV Cache和批次推理。KV Cache是标配批次推理可以把多个用户的请求合并成一个批次充分利用GPU的并行能力。量化需要谨慎使用因为推荐任务对数值精度比较敏感量化后的模型效果可能会明显下降。5.4 线上服务的延迟优化如果竞赛涉及线上服务评估延迟优化就是必须考虑的问题。生成式推荐的延迟主要来自两个方面模型推理时间和物品匹配时间。模型推理时间可以通过前面提到的加速技巧来优化。物品匹配时间是指把模型生成的Token序列映射到具体物品的时间。如果使用前缀树匹配时间通常很短因为树的高度就是Token序列的长度通常只有几位。但如果物品池很大前缀树的规模也会很大需要做好内存管理。另一个优化方向是预生成。对于活跃用户可以在用户没有发起请求时提前生成推荐结果缓存起来。当用户真正发起请求时直接返回缓存结果延迟可以降到很低。这种做法的挑战是如何保证缓存的新鲜度因为用户的兴趣可能会快速变化。6. 评估指标与结果分析6.1 离线指标的选择与解读生成式推荐的离线评估通常使用Top-K召回率、NDCG、MRR等指标。这些指标的计算方式和传统推荐系统类似但有一个关键区别生成式推荐的输出是Token序列需要先解码成物品ID再和真实交互物品进行匹配。Top-K召回率是最直观的指标表示模型生成的Top-K个推荐中有多少个是用户实际交互过的物品。K的选择取决于应用场景竞赛中通常取10或20。NDCG考虑了推荐结果的排序质量位置越靠前的正确推荐贡献越大。MRR只关注第一个正确推荐的位置适合评估“最快找到用户感兴趣物品”的能力。解读这些指标时需要注意生成式推荐的指标通常比传统推荐系统低一些因为生成任务的难度更大。不要因为指标绝对值低就否定方案关键是对比不同方案之间的相对提升。6.2 错误分析模型到底错在哪里指标只能告诉我们模型表现如何但不能告诉我们为什么。错误分析是找到改进方向的关键。常见的错误类型有几种。重复推荐模型反复生成同一个物品即使这个物品已经在用户的历史行为中出现过。这通常是因为训练数据中重复行为太多模型学会了“重复就是安全”的策略。热门偏置模型倾向于推荐热门物品因为热门物品在训练数据中出现频率高模型学会了“推荐热门物品大概率不会错”。长尾失效对于长尾物品模型的推荐效果明显下降因为训练数据中长尾物品的样本太少。针对每种错误类型有不同的改进方向。重复推荐可以通过在训练时对重复行为降权来解决。热门偏置可以通过对热门物品降采样或对长尾物品升采样来缓解。长尾失效可以通过引入物品的语义信息来改善让模型即使没见过某个物品的ID也能通过语义理解来判断是否应该推荐。6.3 消融实验的设计消融实验是验证每个模块贡献的标准方法。在生成式推荐中可以消融的模块包括物品Token化方案、用户特征、时间间隔信息、负采样策略、微调方法等。设计消融实验时要注意控制变量。每次只改变一个因素其他因素保持不变。同时要确保实验的可重复性固定随机种子多次运行取平均值。一个常见的误区是只报告最终指标不报告中间过程。实际上训练过程中的损失曲线、验证集指标变化趋势都能提供有价值的信息。比如如果训练损失持续下降但验证指标不升反降说明模型过拟合了需要增加正则化或减少训练轮数。7. 我在准备这个竞赛时踩过的几个坑7.1 词表扩展的陷阱刚开始的时候我想当然地认为“给每个物品分配一个Token”是最直接的方案于是尝试扩展LLM的词表把物品ID作为新的Token加入。结果发现两个问题一是Embedding层的参数量急剧增加训练显存不够用二是新加入的Token没有预训练知识需要从零开始学习收敛很慢。后来改用层次化编码把物品ID拆成几个层级的Token复用现有的数字Token问题就解决了。这个经历让我明白在LLM时代“复用预训练知识”比“从头学习”重要得多。7.2 忽略时间信息的代价有一版模型我没有加入时间间隔信息结果发现模型对“用户刚交互过的物品”和“用户很久以前交互过的物品”一视同仁导致推荐结果偏向于用户长期兴趣忽略了短期兴趣的变化。加入时间间隔Token后指标有了明显提升尤其是短期兴趣相关的指标。这个坑让我意识到推荐场景中的“时间”是一个非常重要的信号不能忽略。而且时间信息的引入方式也很重要显式Token比隐式位置编码更有效。7.3 约束解码的实现细节约束解码的前缀树实现看起来简单但实际写代码时遇到了几个问题。一是前缀树的构建效率如果物品池很大逐个插入Token序列会很慢。后来改用批量构建先把所有物品的Token序列按前缀排序然后递归构建树速度快了很多。二是解码时的回溯如果当前前缀在树中不存在需要回溯到上一个合法前缀这个逻辑容易写错。建议在实现时多写单元测试确保各种边界情况都能正确处理。7.4 评估指标的计算陷阱计算Top-K召回率时有一个容易忽略的细节如果用户实际交互了多个物品而模型只推荐了其中一个那召回率应该算多少常见的做法是算“命中率”即只要推荐列表中包含任意一个真实交互物品就算命中。但更严格的做法是计算“召回率”即推荐列表中包含的真实交互物品数量除以真实交互物品总数。两种计算方式的结果差异可能很大需要根据竞赛的评估标准来选择。8. 后续可以继续深挖的方向生成式推荐这个方向还有很多值得探索的问题。比如如何把多模态信息物品图片、视频融入到生成过程中让模型不仅能理解文本描述还能理解视觉内容。再比如如何设计更好的解码策略在生成多样性和生成准确性之间取得平衡。还有如何把生成式推荐和传统推荐系统结合起来用生成式模型做召回用传统模型做排序发挥各自的优势。从竞赛的角度来看接下来的重点可能是优化推理效率和多任务学习。推理效率决定了方案能否在实际场景中落地多任务学习则可以让一个模型同时处理多种推荐场景比如首页推荐、搜索推荐、相关推荐提升模型的通用性。我在这个方向上也还在不断学习很多想法还需要通过实验来验证。如果你也在做类似的事情欢迎交流讨论。这个领域变化很快保持学习和实验的节奏比什么都重要。
解法与Go实现)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
