Shopify 详解生成式商品发现模型架构与落地实践
Shopify’s generative discovery model
Shopify 披露了其已部署上线的生成式商品发现模型,通过联合训练统一支撑全平台的搜索与推荐候选召回。该系统采用 RQ-KMeans 将数十亿商品编码为 3-token 语义 ID,选用 Liquid AI 的 LFM2-2.6B 作为底座,并通过 GPU 前缀树约束解码将开销从 50 ms 压缩至约 1 ms。
拆解了数十亿级商品语义编码与低延迟约束解码落地细节,为电商搜索推荐一体化架构提供了工程参考。
两个人都拿出手机搜索“双肩包”。其中一人自从在公交车上经历过咖啡泼溅的意外后,就一直在挑选防水电脑包;另一人则一直在看容量更大的登山包,打算去科罗拉多落基山脉徒步。
搜索词只是个起点。
真正揭示买家真正在意什么的,是他们浏览和购买过的内容。借助这些上下文,我们可以为买家量身定制搜索结果和推荐内容,让他们既能从熟悉的店铺选购,也能发现从未光顾过的新商家推出的心仪好物。
数百万 Shopify 参与商家的交易行为,让我们得以深入洞察消费者如何在不同品类中发现并购买商品。我们的商业生态涵盖了海量独立网店、Shop 应用,以及专为对话式商务和 AI 智能体打造的 Catalog API。
难点在于:如何在实时请求严苛的延迟限制内,利用这些搜索、浏览和购买信号,从数十亿件商品库中为每位买家精准匹配相关商品。
我们的思路立足于搜索与推荐的共通之处:二者都利用商品知识和买家上下文来定位相关商品。搜索词提供了明确的意图信号;推荐则更多依赖行为记录来推测下一步可能需要什么。这种输入与目标的共通性,让它们天然适合联合训练。
为此,我们打造并上线了统一的生成式发现模型。该模型基于 Shopify 的搜索和推荐数据进行联合训练,能同时为这两种场景生成候选商品。目前它已正式投入生产环境,并在离线和线上均取得了显著成效。
本文将详解促成该模型落地的商品表征方法、训练方案以及线上部署决策。
完整的方法论与实验结果详见我们的详细技术报告。
搜索与推荐的大一统基座模型
模型以开源权重的预训练语言模型为起点,利用其通识背景理解商品描述、属性及买家搜索词。随后,我们利用 Shopify 获授权使用的电商数据对模型进行微调,其中包括商品库以及符合条件的搜索与推荐交互数据。
在评估方面,我们在线上衡量买家转化效果,在离线端评估召回检索质量。
模型当前表现
在推荐场景下,接入生成式模型后,Shop 应用首页推荐流的线上指标迎来了如下提升:
| 首页推荐流线上指标 | 相对提升 |
|---|---|
| 订单量 | +7.95% |
| 转化用户数 | +8.60% |
| 转化率(CVR) | +9.85% |
在离线评估中,该生成式模型为推荐生产系统贡献了 2.65 个百分点的增量候选池召回率。同时,它也是我们单体能力最强的候选生成器。
在搜索场景下,该模型不仅单模表现出众,还进一步提升了生产系统的整体效果,带动 OneDCG@10 整体提升 2.1 个点。针对已登录、可进行个性化排序的用户,OneDCG@10 提升了 2.7 个点,且有 25% 的搜索词在前 10 项相关性上实现了净提升。
OneDCG@10 是 NDCG 的一种变体,用于评估前 10 条结果的搜索质量。它以 10 条完全理想的结果为基准进行归一化,而不是针对每个查询各自的理想排序,从而为所有查询提供了统一的参考基准。
| 搜索配置 |
综合 OneDCG@10 |
仅个性化 OneDCG@10 |
|---|---|---|
| 当前线上系统(不含生成式模型) | 30.6 | 33.0 |
| 当前线上系统(加入生成式模型) | 32.7 (+2.1) | 35.7 (+2.7) |
| 仅生成式模型 | 28.5 | 33.6 |
能取得这些效果,离不开我们在商品表示、模型训练和服务部署环节的关键抉择。接下来我们将逐一拆解这些决策,首先从如何让模型高效表示商品讲起。
为模型构建商品词表
Shopify 的商品目录包含数十亿件商品。原始商品 ID 固然能区分数据库中的不同记录,但其数字本身不包含任何商品信息。如果把每件商品都当作独立的输出项,就会产生一个包含数十亿词条的词表,且每个词条都要单独学习表示向量。然而许多商品的训练样本极为稀疏,为每个 ID 独立学习有效表示往往效率低下。
我们在之前关于生成式推荐的文章中曾提出过下一步规划:将商品与文本一样,用语义 ID(Semantic ID)Token 来表示。在此基础上,我们先将商品内容编码为 Embedding(即商品的向量表示),再通过分词器(Tokenizer)将其转换为语义 ID——也就是一串简短的离散编码序列,便于模型进行学习和生成。
我们评估了两种常见的分词器方法:RQ-VAE 和 RQ-KMeans,最终选用了 RQ-KMeans,因为在相同码本(Codebook)规格下,它的下游表现更优。RQ-KMeans 会对商品 Embedding 进行聚类,减去所选的聚类中心,并在剩余的残差上重复这一过程。每一层都会捕捉上一层遗留的信息。我们最终选定的配置包含 3 个码本,每个码本包含 8,192 项,从而为每件商品生成一个由 3 个 Token 组成的语义 ID。
相关商品可以共享编码,使得它们的训练样本能够共同更新共享表示。这样一来,互动较少的商品也能从相似商品的训练中受益。
来看一个真实商品目录中的例子,会更加直观。
共享前缀 [6001] 的商品涵盖了各种款式和面料的马甲。沿其中一个分支看,[6001, 5561] 汇集了不同颜色的充棉马甲,而 [6001, 5561, 0] 则进一步细化为灰色充棉款式。另一个分支 [6001, 4551] 归拢了工装风马甲,[6001, 4551, 879] 则具体对应靛蓝牛仔马甲。
多件商品可能会共享完全相同的编码序列。我们探索了多种在线上服务阶段解决这种冲突的方法,包括在将语义 ID 映射回商品时,引入结合商品热度的轻量级重排步骤。我们的技术报告对此有更详细的介绍。
面向商品语义与买家意图的模型训练
我们的训练方案为预训练语言模型注入了电商知识:将语义 ID 与商品含义关联、学习买家行为轨迹、针对各项任务优化预测,并把特化专家模型重新融合进一个共享模型中。图 4 概述了这些阶段。
在探索这套训练方案的过程中,我们总结出四条核心经验。
经验 1:搜索与推荐能够互相促进
我们借助通用的商品词表对搜索和推荐进行联合训练。图 5 展示了二次预训练阶段的样本示例,每个样本都将上下文与待预测的补全内容配对。
为了弄清两项任务如何相互促进,我们在训练组合中分别移除了搜索或推荐数据:
| 训练数据组合 | 搜索相关性 OneDCG@10 | 搜索购买 Recall@10 | 推荐 Recall@50 |
|---|---|---|---|
| 基线 | 28.8 | 33.4 | 21.0 |
| 无搜索数据 | — | — | 20.9 |
| 无推荐数据 | 28.5 | 32.6 | — |
移除某一数据流时,其训练 token 份额会按比例重新分配给其余数据流。破折号表示未报告被排除任务的相应指标。
结果表明,通过联合训练,搜索与推荐能够相互提升。
经验 2:“发现”能力需要针对性训练
我们现有的基于规则的候选生成器已经能够召回买家历史互动过的商品。推荐领域真正的难点,在于发掘买家从未接触过却对其有用的商品。由于历史记录中包含大量重复浏览,仅在这些数据上训练模型,容易让模型过度偏向买家已知的商品。
为有针对性地培养“发现”能力,我们对围绕“首次购买”构建的训练数据流进行了上采样:包括买家首次购买某件商品、首次在某家商户下单,或首次购买某个品类的行为。这样在微调期间赋予了“发现”事件更高的权重。同时,我们通过丢弃过往点击等陈旧交互、仅保留购买记录来压缩历史,从而在上下文窗口中为近期行为留出更多空间。
发现召回率(Discovery Recall)衡量的是买家购买此前从未交互过商品的情况,能更直接地评估这一目标。
在离线实验中,结合了历史压缩与“发现”配方的方案,在 Top 10 和 Top 50 截断处的发现召回率相对提升了约 10–15%,同时总体召回率相对提升了约 2%。
经验 3:强化学习可提升检索质量
监督微调教会模型复现历史样本,但精准预测下一个 token 并不完全等同于高质量的检索。即便训练样本中只记录了一次购买或点击,多款不同商品其实都能满足相同的用户意图。
在搜索场景中,我们采用大模型相关性裁判来提供奖励信号。模型生成候选集后,由评判器评估其相关性,强化学习算法再根据这一反馈不断优化模型的选择。这让训练更紧密地围绕我们最关注的目标:为买家检索出高质量的商品。在搜索中引入强化学习后,OneDCG@10 提升了 1.5。
经验 4:专业化专家模型可以强化通用共享模型
联合训练让模型对商品和买家形成了通用认知。在此基础上,针对特定任务的微调和后训练进一步构建出专精于搜索与推荐的专家模型。我们的目标是打造一个统一的发现(discovery)模型,既能兼顾二者,又能完整保留各任务单独优化所取得的质量提升。
我们采用多教师蒸馏技术,把两位专家的能力迁移到同一个学生模型中。其核心思路是:先让各专家术业有专攻,再将它们各自学到的能力融于一体。随着每个专家在各自任务上不断迭代进步,共享模型也能通过蒸馏继承这些成果。
以生产级速度提供生成式发现模型服务
在线搜索或推荐请求留给候选生成的时间极短。我们从模型选型入手,并精简生成有效商品编码所需的计算步骤,对推理服务链路的质量和延迟进行了全面优化。
结合延迟预算选择基座模型
我们的模型充当候选生成器,需要与下游重排阶段共享实时请求的延迟预算。为此,我们选择了 Liquid AI 的 LFM2-2.6B,因为它在质量与延迟之间取得了最佳平衡,同时为后续环节预留了充足的时间。在生产环境中,我们采用 RIPL 推理技术栈来部署该 Liquid 模型。
| 模型 |
搜索相关性 OneDCG@10 |
搜索购买 Recall@10 |
推荐 Recall@50 |
p95 延迟 |
|---|---|---|---|---|
| LFM2-2.6B —— 最终入选 | 24.9 | 32.3 | 25.3 | 25.5 ms |
| Qwen3-1.7B | 24.9 | 32.5 | 26.0 | 46.1 ms |
| Qwen3-14B | 25.3 | 35.0 | 26.7 | 108.4 ms |
为公平起见,所有模型均采用相同的训练数据配比,并在相同的搜索与推荐基准上进行评测。p95 延迟是在服务端通过 TensorRT-LLM 采用闭环基准测得:每个客户端均等待当前请求完成后才发送下一个。本表中的延迟仅统计服务端生成器调用的耗时,采用 100 的束搜索宽度(beam width)生成 100 个候选商品。LFM2-2.6B 运行于定制版 TensorRT-LLM 引擎上。延迟基准测试所用请求抽样自真实线上流量。提示词长度在 p50 为 22 个 token,在 p95 为 620 个 token。
实现快速约束解码
此外,模型生成的编码必须能解析为库内的合规商品。由于商品目录中仅有部分 token 组合对应真实商品,我们通过有效语义 ID(semantic-ID)路径索引来约束生成过程。
校验这些路径的计算开销可能极高。我们基于 STATIC 方案,将商品目录的前缀树(trie)表示为 GPU 上的稀疏索引,使引擎能通过向量化操作校验合法的后续分支。随后,我们在 TurboMind 内部通过 CUDA/C++ 插件执行这些解码约束。在我们这一场景下,单次请求的约束校验开销从 50 ms 以上骤降至约 1 ms。
另一个挑战是受约束生成式检索的元数据路由。每次请求都可能带有特定的合规过滤条件(例如买家所在市场),这些过滤条件必须对模型能生成的语义 ID 路径形成约束。我们将在后续文章中详细介绍针对这一问题的解决思路。
单次前向传播预测完整语义 ID 序列
我们的输出结构有一个很有用的特点:虽然需要大量候选商品,但每个商品仅由三个码字表示。传统的自回归(AR)生成方式需要逐个预测这些码字。
多 Token 预测(MTP)可以在单次模型前向传播中,同时预测全部三个位置的概率分布,再将其组合成有效的语义 ID。这大幅减少了生成候选时所需的顺序计算量。后续博文将详细解析多 Token 预测的设计方案、推理优化,以及在效果、延迟和吞吐量之间的权衡取舍。
图 6 对比了当前线上生产环境下 AR 与 MTP 的表现。非个性化搜索仅使用查询词作为输入;个性化搜索则会在提示词中加入买家画像上下文。
我们利用节省下来的时间,通过 MTP 生成规模更大的候选集,再由轻量级重排模型选出最佳结果。MTP 与该重排模型搭配使用,不仅比 AR 表现出显著的效果提升,同时依然保持了更低的 p95 延迟。
下一步规划
如今的商品发现依赖多阶段漏斗体系:召回环节先从庞大的商品库中筛选候选集,随后的层层排序阶段逐步缩小范围,最终为买家排定展示顺序。我们统一的生成式发现模型目前主要充当这一架构中的候选生成器。各阶段环环相扣:一旦在召回阶段遗漏了相关商品,后续的排序环节就再也无法挽回。
展望未来,我们的目标是将这套发现流程更多地整合进单一发现模型。该模型能够分析买家所处的情境、推断购物意图、借助语义 ID 生成候选商品并直接打分排序。这一共享理解能力将在严格尊重买家隐私选择的前提下,同时赋能搜索、推荐和广告业务。下图展示的完全一体化路径,正是我们的长期演进方向。
为实现这一愿景,我们需要对用户的购物历程建立更丰富、更具时序性的全貌观察,将搜索词、商品浏览、下单购买和店铺访问整合为单一的时间序列。保留这些行为的先后顺序和时间跨度,能让搜索和推荐系统在买家兴趣与意图演化上拥有统一的全局认知。
基于这一共享上下文,我们正在押注三大方向。
首先是意图推理。比如有人正在布置一间小公寓,买了一张桌子之后,接下来需要的东西也会随之改变——买家可能接着需要既与桌子相配又适合房间大小的椅子。我们希望模型能够把这些历程线索串联起来,并将这种理解贯穿到候选生成和排序的始终。
第二点是更丰富的多模态表征,重点在于视觉信息。商品图片能呈现文字描述中往往会忽略的细节:形状、质感、图案和风格。将这些视觉信号与文本信息,以及买家浏览过的商品关联起来,有助于模型准确把握用户偏好,并找出与之匹配的其他商品。
第三点是在线持续训练。我们希望将最新的点击、购买等行为数据持续用于更新这一共享模型,使其能够随着买家喜好和商品目录的变化而动态调整。缩短从用户交互到模型更新的链路,可以让搜索或推荐环节学到的新信息同时改善这两种场景的体验。
本文由 Aaron Yuen、Darshan Fofadiya、Kyumin Park、Michael Garner、Joshua Antonio Crisologo、Ryan Synk、Jose Sepulveda 与 Anthony Maltsev(Liquid AI)共同贡献内容。
特别鸣谢 Liquid AI 团队的 Darian Bhathena 和 Edoardo Mosca。
来源:Shopify Engineering · shopify.engineering