Shopify 工程团队：搜索与推荐为何能共用一个生成式模型

搜索和推荐在工业系统中通常各走各的管线：搜索处理显式查询，推荐依赖隐式行为信号。Shopify 工程团队提出了一个更根本的观察——两者共享同一组输入和目标。搜索查询提供显式意图信号，推荐则从浏览和购买行为推断意图；但两者都需要产品知识和买家上下文来识别相关商品。这个共同基础使联合训练成为自然选择，而非工程妥协。

要让一个语言模型同时服务搜索和推荐，首先需要一个共享的商品词汇表。Shopify 目录包含数十亿商品，原始商品 ID 的数字本身不携带任何产品信息，把每个商品当作独立输出会创造数十亿条词汇，训练样本极度稀疏。他们的解决方案是语义 ID：先用嵌入模型将商品内容编码为向量表示，再用 RQ-KMeans 将嵌入转换为三词元离散编码序列，每层码本包含 8192 个条目。关键效果是相关商品共享编码前缀——例如以 [6001] 开头的商品涵盖各种马甲和背心，[6001, 5561] 进一步聚焦到不同颜色的填充背心。这意味着一个商品的训练样本能更新其邻居的共享表示，为交互稀疏的商品提供了学习途径。

联合训练是否真的让两个任务互相受益？Shopify 给出了消融实验。移除搜索数据后，推荐 Recall@50 从基线 21.0 降至 20.9；移除推荐数据后，搜索 OneDCG@10 从 28.8 降至 28.5，搜索购买 Recall@10 从 33.4 降至 32.6。两个方向都有下降，说明共享训练确实产生了交叉增益。团队还发现，监督微调虽然能教会模型复现历史样本，但准确预测下一个词元并不完全等同于检索质量——多个商品可以满足同一意图，而训练样本中只记录了一个观察到的购买或点击。为此，他们引入强化学习，用 LLM 相关性判断器提供奖励信号，在搜索任务上额外带来 1.5 点 OneDCG@10 提升。

生产部署的约束决定了模型规模和推理方式。Shopify 将生成式模型定位为候选生成器，与下游排序共享一次实时请求的延迟预算。他们选择了 Liquid AI 的 LFM2-2.6B，p95 延迟 25.5 毫秒（beam width 100），而更大的 Qwen3-14B 虽然质量更高，108.4 毫秒的延迟已无法为后续排序留出足够时间。约束解码方面，他们基于 STATIC 方法将目录前缀树表示为 GPU 上的稀疏索引，通过 CUDA/C++ 插件在 TurboMind 中强制执行，将约束开销从超过 50 毫秒降至约 1 毫秒。多词元预测进一步将三个码字的自回归生成压缩为单次前向传播，省下的时间用于生成更大候选集再由轻量排序器精选。

需要明确的是，上述所有性能数字均为 Shopify 自报的生产指标，没有独立验证。在线增益（订单 +7.95%、转化率 +9.85%）来自 Shop 首页推荐实验，搜索质量提升来自内部 OneDCG@10 评测。这套架构的适用条件与 Shopify 的商品目录结构、请求延迟预算和参与商家规模紧密耦合；不同商品分布、不同延迟约束或不同交互密度的系统未必能直接复用相同决策。团队自己也指出，下一步目标是将意图理解、候选生成和排序整合进同一个模型，并引入在线持续训练——这意味着当前的架构定位（候选生成器）本身是一个阶段性的工程选择，而非最终形态。