PailitaoMMSearch2.0 Technical Report: Scaling Generative Retrieval to Unified End-to-End Multimodal Search

在淘宝拍立淘里，用户拍一件衬衫，再打一句「找条配它的运动短裤」，要的不是同款，而是另一个品类的搭配；拍一双凉鞋说「这个牌子的女款」，要的是改掉一个属性、其余不变。传统做法先用意图分类器判断这是哪类请求，再分发给不同的召回通道，任何一步分错，后面全错。阿里这篇技术报告把这些都交给一个 2B 的视觉语言模型：输入原图和原话，直接生成商品的 Semantic ID（SID），不需要任何意图标签。离线上，「找搭配」这类请求的优秀率（ER）从内部多路召回链路的 44.2% 提到 74.3%，平均响应时间从 780 毫秒降到 278 毫秒；线上 A/B 中成交笔数提升 27.04%，GMV 提升 8.94%，已全量上线。

做多模态搜索或生成式召回的团队值得读，因为它回答的是一个很实际的问题：一个模型能不能同时接住「找同款」「改属性」「找搭配」三种关系，并且在不同资源预算的入口复用。最值得借走的是 Sample–Beam：强化学习采样时，推理部分照常随机采样，商品编号部分改用和线上一样的 beam search，让训练优化的东西和线上真正返回的候选列表对齐，这一步在标准强化学习之上又把宏平均优秀率提了 2.30 个点。需要留意的是，它在「找同款」和「改属性」上仍不如原有的多路链路，线上也是和老链路的结果混排后一起评估的。

它到底在解决什么问题？

先看三条请求（示意）：

三条请求的输入形式完全一样，都是「一张图加一句话」，但要求的检索关系不同。论文把它们归成三类：相似（基本保留图中商品）、编辑（保留商品身份、改掉或筛选某些属性）、搭配（找互补的另一件商品）。

老系统的问题出在三处绑定。一是监督数据绑定在已上线的入口：新意图还没上线，就没有点击日志可学。二是一个模型只学一种关系，想支持新关系就要加分类器、加路由、加专家模型，分类器一旦判错，错误会一路传到最终结果。三是模型大小和解码方式按某个入口的延迟要求定死，换个入口就得重来。

论文的内部基线正是这种结构：显式意图分类器决定打开哪些召回通道，有图文组合检索、多模态改写后走文本搜索、query 文本和商品标题的语义匹配，合并后再过多级排序。它在搭配类请求上的优秀率只有 44.2%，比另外两类低一截，原因就在于「找搭配」很难靠相似度召回。

整体流程：数据、意图、场景三个方向

整条链路可以按产出物理解：

每个商品用三层 SID 表示，每层词表 8,192 个码。模型解码出的每个合法 SID 都唯一对应一件商品，所以解码本身就是召回，不是先改写 query 再交给别的检索器。三种推理长度由系统提示控制：No-think 直接输出 SID；Low-think 先写一小段，只点出决定结果的视觉和文字约束；High-think 允许更长的推理，用来比较候选、解决冲突约束。

这样设计的关键分工是：意图由模型自己从图和话里推断，资源预算由部署方通过模型大小和推理长度来选，两件事互不干扰，所以不需要任何路由模型。

没有日志的新意图，训练数据从哪来？

新意图上线前没有流量，只能从已有的商品关系里造数据，比如商品相似、共现、穿搭兼容。这些代理关系结构各异、可靠性也参差，所以作者做了五个工具：粗筛、细筛、生成指令、生成推理过程、质检。粗筛用类目、属性、行为这些便宜信号先去掉明显不合理的配对；细筛判断配对是否真的符合目标关系；生成指令把商品关系写成用户会说的一句话；质检是最后一道关。

拿论文的例子走一遍。代理关系是「红色短袖衬衫 → 红色长袖衬衫」。粗筛看类目和主色一致，保留。细筛给出结构化判断：类目和颜色不变，袖长是要改的属性，其他差异必须足够小。生成指令只写有依据的变化，即「找同颜色的长袖」，而不是把目标商品的所有属性都描述一遍。质检把原图、指令、目标放在一起打 0 到 3 分：红色长袖衬衫得 3 分；袖子被遮住、看不太清的得 2 分；蓝色长袖衬衫违反了「同颜色」，得 1 分；长袖夹克不在目标品类，得 0 分。2 分及以上才进训练集。

为什么要按「便宜的先、贵的后」排？因为细筛和生成指令都要调用大的多模态模型，先用结构化信号把候选池砍小，大模型只处理留下来的样本，成本就降下来了。真实流量走另一条路径：保留用户原话，只在质检发现拼写错误或约束冲突时才修，避免把真实说法改写得面目全非。

数据规模上，代理数据是相似 24M、编辑 24M、搭配 12M，真实流量清洗后是 1M、8M、1M。作者做了两个对照：训练数据从 30% 加到 100%，宏平均优秀率从 46.32% 升到 49.03%；在全量数据上去掉真实流量，优秀率降 0.78 个点，再去掉质检又降 0.28 个点。这说明数据量仍是最大的杠杆，真实流量的贡献比质检大，而质检主要帮的是搭配类。

Sample–Beam：让强化学习优化线上真正返回的那组候选

这是全文最核心、也最容易看不懂的一步。先说为什么需要它。标准 GRPO 对每个 query 采样若干条完整输出，每条都是逐 token 随机采样出来的。线上却不是这样：模型写完推理之后，SID 部分用宽度为 B 的 beam search 一次产出 B 个候选。随机采样出的一条 SID 和 beam 出来的前 B 名，分布并不一样，训练时奖励的东西就和线上返回的东西对不上。

Sample–Beam 把一次采样拆成两段。对同一个 query，先随机采样 N 段推理；每段推理后面接一次 beam search，得到 B 个 SID。这样一组共有 N×B 条完整轨迹，每条都是「推理 + 一个 SID」。每个合法 SID 唯一对应一件商品。奖励模型按对应意图的标准，分别评估每个分支的候选与查询有多相关，并给出分数。所有 N×B 个分数一起做组内归一化，得到每条轨迹的优势值，再用 GRPO 的截断目标更新推理 token 和 SID token。

用一个能手算的小例子看推理部分怎么被训练（示意，N=2，B=3）：

6 个分数的均值约为 1.33（示意，这里只减均值、省略除标准差）。推理 1 后面的 3 个候选整体更好，它的优势之和为正，这段推理的 token 被推高；推理 2 整体偏差，被压低。也就是说，一段推理的好坏由它引出的整组候选来评判，而不是由某一个随机采出的 SID 来评判，这和线上用户看到一整列商品的情况一致。

作者也说明了它的代价：beam search 是确定性地挑前 B 名，不是从策略里随机采样，所以这个目标不是无偏的 on-policy 估计。它换来的是训练和服务的对齐，而不是更准的梯度。

另一个设计是按意图加权采样。三类意图的数据量差别很大，如果按原始比例采，数据多的意图会主导更新，所以每类给一个采样权重。三类共享同一个模型，意图标签只用来决定采样比例和奖励评分标准，不进入线上推理。

标准强化学习的收益主要在搭配类，提了 7.84 个点；Sample–Beam 在此基础上又给相似和编辑各加了约 3 个点，搭配只多 0.95 个点。作者认为，统一强化学习带来了提升。Sample–Beam 让训练时也用线上那样的 beam 解码生成候选，两者的提升相互补充。Sample–Beam 的额外收益主要集中在相似和编辑类。

推理长度和模型大小怎么选？

这张表有三个信息。本实验的 0.8B 模型增加推理后，宏平均优秀率下降，延迟上升。2B 的 Low-think 平均只写 8.6 个 token，却比 No-think 高 0.51 个点，说明这里有用的「推理」其实是一句约束提取，比如「保留颜色、改袖长」，而不是长思维链。4B 配 High-think 拿到表里最高的 55.41%，但响应时间是 2B Low-think 的 4 倍多，只多 0.28 个点。所以作者最终把 2B Low-think 当作主力配置。

和现有系统比，以及线上结果

这里的优秀率指前 10 个结果里拿到满分 3 分的比例，由一个用人工标注校准过的多模态评审模型打分，它判 3 分时与人工一致的精度约 93.6% 到 93.9%。宏平均是三类意图的简单平均。

结果并不是全面领先。2B 模型的宏平均比内部链路高 5.6 个点，几乎全部来自搭配类的 30.1 个点；在编辑类上反而低了 9.5 个点，相似类低 3.6 个点。这说明生成式检索的优势在于理解关系，精确保留属性仍是短板，而内部链路用了多级排序，在细粒度属性上更稳。

线上实验各约 10% 流量、跑约 14 天。在拍立淘「多模态搜索」入口，商品浏览量提升 17.90%，成交笔数提升 27.04%，GMV 提升 8.94%，点击率提升 0.58 个百分点，全部显著。不过已有成熟链路的入口里，新模型的结果是和老链路的结果在最终展示时混排的，所以线上数字衡量的是「新模型加老链路」的整体，不是新模型单独替换。

我认为它的局限

第一，评审、质检和奖励都是同一家族的大模型。质检用 Qwen3.5-397B，奖励模型用 Qwen3.8-27B，离线评审也是模型。作者自己承认它们的错误可能相关，评审精度约 93%，而 Sample–Beam 相对标准强化学习的收益是 2.30 个点，两者量级接近，很难完全排除「学会讨好评审」的成分。

第二，测试集很小。三类意图的自动测试集各只有几百条 query，最小的搭配类只有 371 条。因为样本这么少，推理长度表里零点几个点的差别很可能只是噪声，比如 2B 的 Low-think 和 High-think 只差 0.13 个点，不足以说明哪个更好。

第三，它没有证明能单独替换老链路。编辑类优秀率比内部链路低 9.5 个点，线上又是混排，所以更准确的结论是：它很适合补上老链路最弱的「找搭配」，能否独立承担全部流量还没有证据。

一个推荐或搜索团队可以怎么试

1. 先找出现有多路召回里最弱的那类关系（通常是搭配或跨品类），只针对它训练一个小的生成式召回模型，和老链路混排做 A/B。这样风险最小，也最容易看到收益。
2. 训练数据先用已有的商品关系造，按「便宜信号粗筛、大模型细筛、大模型质检」的顺序排，质检规则先用几千条人工标注校准，看它和人工的一致率能否到 90% 以上。
3. 强化学习阶段直接用 Sample–Beam：只要线上用 beam search 生成多个候选，训练时也用 beam search 生成 SID。先给每个候选打分，再把所有分支的奖励放在一起归一化，最后更新推理 token 和 SID token。判断是否有效，看前几名候选的人工满意率是否提升，而不只看评审分。
4. 推理长度先试最短的约束提取式推理，在小模型上如果加推理变差就关掉，把延迟预算留给更大的模型。

一句话结论

把意图交给模型推断、把预算交给部署方选择，再用 Sample–Beam 让强化学习优化线上真正返回的那组候选，这是一个能在多入口复用的多模态生成式检索方案。