weixin_290533831. 电商推荐系统的演进与挑战
在淘宝这样的电商平台上，"猜你喜欢"模块每天要处理数亿次的商品推荐请求。这个看似简单的功能背后，隐藏着复杂的算法较量。传统的推荐系统通常采用两阶段架构：召回阶段快速筛选出候选商品，排序阶段对候选商品进行精细排序。而召回作为整个推荐流程的第一环，其质量直接影响着最终推荐效果。
近年来，生成式模型在推荐系统中的应用呈现出爆发式增长。与传统的基于向量内积的双塔召回模型相比，生成式模型能够更好地捕捉用户行为序列中的复杂模式。然而，现有的生成式推荐方法大多沿用了语言模型中的"下一个词预测"(Next Token Prediction)范式，这在电商场景中遇到了两个关键问题：
首先，电商推荐中的用户行为具有明显的会话特征。当用户打开淘宝首页或下拉刷新时，系统会一次性展示多个商品，这些商品之间并没有内在的因果关系或顺序依赖。但传统自回归模型强制为这些商品添加了顺序关系，导致模型学习到虚假的依赖模式。
其次，电商场景对推荐的新鲜度和实时性要求极高。用户兴趣可能随着一次点击而迅速变化，这就要求模型能够快速适应最新的用户行为。但生成式模型通常参数量大、训练成本高，难以实现高频更新。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. TBGRecall的核心设计理念
阿里巴巴团队提出的TBGRecall模型，创造性地将生成范式从"下一个词预测"重构为"下一会话预测"(Next Session Prediction)，从根本上解决了上述问题。其核心思想可以概括为三点：
2.1 会话级自回归建模
传统方法将用户行为序列视为连续的token流，而TBGRecall则将其划分为多个会话段。每个会话以一个上下文token开头，后跟该次会话中交互的商品token。这种结构明确区分了会话内和会话间的关系：
- 会话内：商品之间没有顺序依赖，可以并行处理
- 会话间：保留自回归关系，捕捉用户兴趣的演进
这种设计既保留了序列建模的能力，又避免了强加不必要的顺序依赖。
2.2 对比学习目标
不同于传统生成模型使用的回归损失，TBGRecall采用了基于噪声对比估计(NCE)的损失函数。具体来说，模型学习将上下文token的表示与正样本商品拉近，与负样本商品推远。这种对比目标更符合召回任务的性质——我们不需要预测具体的下一个商品，只需要找到相关的候选商品。
2.3 高效训练框架
为了应对电商场景的数据规模和时效性要求，TBGRecall提出了Partial Incremental Training方法。将用户数据分为10个桶，每天只使用一个桶的最新数据进行训练。这样既保证了模型每天都能更新，又将训练时间控制在合理范围内。实验表明，这种方法仅用1/10的计算资源就能达到接近全量训练的效果。
3. 模型架构详解
3.1 输入表示
TBGRecall的输入序列采用特殊结构组织：
code复制Q = {c^(1), i_1^(1), i_2^(1), i_3^(1), c^(2), ..., c^(K), i_1^(K), i_2^(K), c^(K+1)}
其中c^(k)表示第k个会话的上下文token，i_m^(k)表示第k个会话中的第m个商品token。
每个token的隐藏表示由四部分组成：
code复制h = e_id + e_act + e_side + e_ctx
- e_id：商品ID嵌入
- e_act：用户行为类型嵌入(点击/曝光)
- e_side：商品侧信息嵌入(类目、价格、卖家等)
- e_ctx：场景上下文嵌入
3.2 关键组件
3.2.1 会话掩码(Session Mask)
为了阻断同一会话内商品间的注意力，TBGRecall在标准因果掩码基础上引入了会话掩码。具体实现上，同一会话内的所有商品共享相同的位置编码，这样它们可以互相看到，但不建立依赖关系。
3.2.2 令牌特定网络(TSN)
考虑到上下文token和商品token具有不同的语义和分布，模型为两类token分别设计了独立的嵌入变换层和初始Transformer层。这种设计消除了共享参数带来的性能下降，同时不影响推理效率。
3.2.3 多会话预测(MSP)
受语言模型中多token预测的启发，TBGRecall在会话维度上预测多个后续会话。这不仅提供了更丰富的训练信号，还能更好地建模长距离用户行为模式。
3.2.4 混合专家(MoE)
模型在前馈网络中使用MoE架构，包含24个专家网络和一个共享专家。每个token根据其路由权重激活top-2专家。这种设计在不显著增加计算成本的前提下，提升了模型容量。
3.3 损失函数设计
TBGRecall的损失函数由三部分组成：
-
基础对比损失(L_NCE)：
使上下文表示接近正样本商品，远离随机负样本 -
点击增强损失(L_click)：
在正样本中，给予被点击商品更高权重 -
购买增强损失(L_pay)：
在点击商品中，给予产生购买的商品更高权重
这种级联式的损失设计引导模型更关注高价值的用户交互。同时，针对不同场景(如首页推荐、搜索推荐等)分别计算归一化损失，避免了场景分布不均衡带来的偏差。
4. 工程实现与优化
4.1 分布式训练框架
TBGRecall的训练面临两大挑战：
- 万亿级token的语料库和百亿级参数
- 数十亿商品库中的高效负采样
解决方案包括：
- 分布式负采样分片：将商品库分散到多个节点并行采样
- 异步数据加载：CPU工作线程预取数据并执行特征工程
- 分片嵌入：使用TorchRec的DMP在GPU间分区稀疏嵌入
- FSDP：对密集参数进行全分片数据并行
这些优化使得模型能够在合理时间内完成训练，GPU利用率保持在90%以上。
4.2 近线推理架构
为了满足线上服务的低延迟要求，TBGRecall采用了近线推理设计：
- 用户行为实时更新到序列中
- 异步服务生成最新的用户兴趣向量
- 定期执行ANN搜索更新候选商品缓存
- 线上请求直接返回预计算的推荐结果
这种架构将耗时的生成和检索过程与实时请求解耦，平均延迟降低到毫秒级。
5. 实验与效果
5.1 离线实验
在淘宝内部数据集和公开的RecFlow数据集上，TBGRecall相比基线模型有显著提升：
| 模型 | HR@20 | HR@100 | HR@500 | HR@4000 |
|---|---|---|---|---|
| SASRec | 0.124 | 0.256 | 0.412 | 0.589 |
| BERT4Rec | 0.131 | 0.263 | 0.421 | 0.602 |
| Online DT | 0.142 | 0.281 | 0.445 | 0.624 |
| TBGRecall | 0.158 | 0.302 | 0.473 | 0.658 |
特别是在高优先级商品(HR@20-500)上的提升更为明显，说明模型能更好地捕捉用户的核心兴趣。
5.2 在线A/B测试
在淘宝首页"猜你喜欢"场景的5%流量上进行了7天测试，结果：
- 曝光占比：23.94%
- 交易数提升：+0.60%
- 交易金额提升：+2.16%
这一提升带来了显著的业务价值，验证了生成式召回在工业级推荐系统中的实用性。
5.3 消融实验
对各组件的贡献进行分析：
| 配置 | HR@4000 |
|---|---|
| 基础模型 | 0.601 |
| +TSN | 0.623 |
| +MSP | 0.639 |
| +MoE | 0.647 |
| 完整模型 | 0.658 |
结果显示各组件都有独立贡献，其中MSP带来的提升最大。
6. 实践启示与展望
TBGRecall的成功实践为生成式推荐系统提供了几个重要启示：
-
领域适配比模型大小更重要：通过针对推荐场景特点改造生成范式，TBGRecall用相对较小的模型规模(相比LLM)取得了显著效果提升。
-
数据时效性是关键：Partial Incremental Training证明，在推荐系统中，及时使用最新数据比堆砌更多历史数据更重要。
-
工程实现决定上限：没有高效的分布式训练和近线推理架构，再好的算法也难以落地。
未来方向可能包括：
- 结合多模态商品信息增强表示
- 探索更灵活的用户序列分割策略
- 优化增量训练中的数据分布平衡
TBGRecall的创新不仅在于提出了新的生成范式，更在于证明了生成式方法在工业级推荐系统中的可行性。这一工作为推荐算法的发展开辟了新的可能性，也让我们看到了AI技术与电商业务深度融合的巨大潜力。