1. 从向量检索到生成式召回一次范式转移的底层逻辑1.1 为什么传统向量检索在交易搜索场景里越来越吃力做电商搜索的人都有一个共同感受向量检索这套东西在内容社区、图文推荐里跑得挺顺一放到交易搜索里就开始各种别扭。得物这种以交易为核心场景的平台用户搜“aj1 低帮 白红”他要的不是“语义相近的一堆鞋”而是“能下单、有货、价格合适、尺码对”的那几双。向量检索擅长的是“意思差不多”但交易搜索要的是“意图精确命中 商业约束满足”这两件事在本质上是有张力的。传统做法一般是“召回靠向量 排序靠模型”的两段式。召回阶段用双塔把 query 和 item 各自编码成向量然后走 ANN 近似最近邻。问题在于双塔结构天然是“query 和 item 分开编码”的两者之间没有细粒度的交互query 里的“低帮”“白红”“男款”“42码”这些关键约束在向量空间里会被平均掉、稀释掉。你搜“白红”它可能给你召回一堆“红白”“米白”“奶白”因为向量距离上它们确实很近。更麻烦的是长尾 query。得物的商品库里有大量球鞋、潮服、潮玩型号、配色、联名、年份这些信息极其细碎。一个“dunk low 熊猫 女款 36”这样的 query向量检索经常召回一堆“熊猫配色但男款”“dunk 但非 low”“low 但非熊猫”的结果。召回阶段就已经偏了后面排序再强也救不回来——这就是所谓的“召回天花板”。还有一个被低估的点交易搜索的 query 分布是高度动态的。新品发售、联名突袭、季节换装都会让 query 分布在一夜之间发生漂移。向量索引的更新是有延迟的双塔模型重训也是有周期的等模型学明白“这个新配色该召回什么”热度可能已经过去了。1.2 生成式召回到底“生成”的是什么很多人一听“生成式召回”就懵召回不是“从库里捞东西”吗怎么变成“生成”了这里得把概念掰清楚。生成式召回的核心思路是把“召回”这个动作从“在向量空间里找最近邻”重新定义为“让模型直接生成候选 item 的标识”。也就是说模型不再输出一个稠密向量然后去 ANN 里比对而是像语言模型预测下一个 token 一样直接“写出”它认为最该召回的 item ID 序列。这个转变的意义在于query 和 item 之间的交互从“事后算距离”变成了“生成时就融合”。模型在生成每一个 item ID 的时候是带着对整个 query 的理解、对商品库结构的记忆、对商业约束的感知去生成的。它不是在“找相似的”而是在“根据意图直接构造答案”。打个比方。向量检索像是你在一座巨大的图书馆里凭“这本书大概在哪个区域”去找书生成式召回像是你脑子里已经有一张图书地图直接报出“第三排左数第七本”的书名。前者依赖空间索引的质量后者依赖模型对“书库结构”的内化程度。得物交易搜索用生成式做召回本质上是在做一件事把“商品库的结构知识”和“query 的意图理解”压缩进同一个生成模型里让召回从“检索问题”变成“生成问题”。这带来的直接好处是细粒度约束配色、尺码、款式、联名可以在生成过程中被显式建模而不是被向量平均掉。1.3 范式跃迁背后的三个关键判断为什么是现在做这件事为什么是得物这个场景我梳理下来有三个判断值得说。第一大语言模型让“生成式召回”从理论可行变成工程可用。早几年也有用 seq2seq 做召回的尝试但那时候模型容量小、训练数据少、推理成本高生成出来的 item ID 经常是“语法正确但语义离谱”。现在 LLM 的底座能力上来了尤其是对结构化 ID 序列的建模能力配合商品库的层级化编码生成质量有了质的提升。第二交易搜索的 query 天然适合“生成式”建模。交易 query 往往短、约束多、意图明确比如“aj1 芝加哥 男 42”。这种 query 的信息密度很高向量检索容易丢信息但生成模型可以逐 token 地把这些约束“翻译”成 item ID 的各个字段。换句话说交易 query 的“结构化程度”反而成了生成式召回的优势场景。第三算力约束下的性价比拐点到了。生成式召回的推理成本确实比 ANN 高但得物的商品库规模、query 量级、以及召回阶段对延迟的容忍度刚好落在一个“用生成式做粗召回、用轻量模型做精排”的甜蜜区间。如果商品库再大十倍或者延迟要求再严一倍这个方案可能就不成立。所以这是一个“场景匹配度”的问题不是“技术越新越好”的问题。2. 生成式召回的核心机制拆解从 item ID 编码到约束解码2.1 商品库的层级化 ID 编码让模型“会写”商品生成式召回要成立第一步是让模型能“写出”商品。但商品不是自然语言 token不能直接扔进词表。得物的做法是给商品库设计一套层级化的 ID 编码把每个商品拆成“品类-品牌-系列-款式-配色-尺码”这样的结构化字段每个字段对应一个子词表。举个例子一个商品可能被编码成类似鞋AJ1低帮芝加哥男42这样的 token 序列。模型在生成的时候不是一次性吐出整个 ID而是逐字段生成先定品类再定品牌再定系列逐层收窄。这样做的好处是即使模型在某一层生成了“错误”的 token后面的层还可以在合法范围内做修正不会出现“整个 ID 完全无效”的情况。这套编码的关键在于“层级间的约束关系”。比如“AJ1”下面不可能出现“女款 46 码”这种组合假设该款没有那么解码时就可以用一棵前缀树Trie来约束生成空间。模型每生成一个 token就沿着 Trie 走一步只允许走合法的分支。这本质上是一种“约束解码”把商品库的结构知识直接注入到生成过程里。注意层级化编码的粒度需要反复调。粒度太粗模型生成空间太大容易生成无效 ID粒度太细序列太长推理延迟上不去。得物这边的经验是把“品类-品牌-系列-款式”作为必选层级“配色-尺码”作为可选层级在召回率和延迟之间取平衡。2.2 约束解码与前缀树怎么保证生成的都是“真商品”约束解码是生成式召回能不能落地的命门。没有约束模型可能生成一堆“语法上像商品、但库里根本没有”的 ID召回率直接崩掉。具体做法是把整个商品库的层级化 ID 构建成一棵前缀树。每个节点对应一个字段值从根到叶的一条路径就是一个合法商品。解码时模型在每个位置输出的是“下一个字段值的概率分布”然后只在这个节点的子节点集合里做 softmax。这样生成的每一个 token 都保证是合法的最终生成的 ID 一定对应库里的真实商品。这里有个工程细节值得说前缀树的规模。得物的商品库是千万级如果每个商品都展开成完整路径Trie 的节点数会非常庞大。实际做法是对高频路径做“共享前缀压缩”对低频路径做“懒加载”只在解码走到那个分支时才展开。这样既保证了约束的完整性又控制了内存占用。另一个细节是“多商品生成”。一次召回往往需要生成 top-K 个候选而不是一个。做法是在解码时用 beam search维护 K 条候选路径每条路径对应一个商品 ID。beam 的宽度需要根据延迟预算来调得物这边实测下来beam8 到 16 是比较稳的区间。2.3 多模态信号的注入让“看图搜鞋”也能生成得物的交易搜索里有相当一部分 query 是带图的或者 query 本身是“以图搜款”。这就涉及多模态信号的注入。生成式召回处理多模态的思路不是把图像编码成一个向量然后拼到 query 向量上而是把图像信息“翻译”成文本侧的约束再参与生成。具体来说用一个视觉编码器比如 CLIP 类的结构把图像编码成一组“视觉 token”然后通过一个投影层把这些视觉 token 映射到和文本 token 同一个空间再一起送进生成模型。这样做的效果是模型在生成 item ID 的时候既能看到 query 文本里的“白红”“低帮”也能“看到”图像里的配色分布、鞋型轮廓。生成出来的 ID 会同时满足文本约束和视觉约束。实测下来这种多模态注入对“以图搜款”场景的召回率提升很明显尤其是那些“用户说不清楚、但一看图就知道要什么”的长尾需求。提示多模态注入的难点在于“模态对齐”。视觉 token 和文本 token 的分布差异很大如果投影层训不好视觉信号会变成噪声反而拉低召回。得物的做法是先做一轮对比学习预训练让视觉 token 和文本 token 在同一个空间里“对得上”再接入生成模型做联合微调。3. 实操落地从数据准备到线上部署的完整链路3.1 训练数据的构造query-item 对的“生成式改写”生成式召回的训练数据不能直接用“query-点击 item”这种原始日志。因为原始日志里一个 query 对应的点击 item 往往有几十上百个而且噪声很大。直接拿来训模型学到的会是“平均意图”而不是“精确意图”。得物的做法是做“生成式改写”把每个 query 对应的正样本 item按照层级化 ID 展开成 token 序列然后把 query 和这个序列拼成“输入-输出”对。比如输入是“aj1 芝加哥 男 42”输出是鞋AJ1低帮芝加哥男42。这样模型学的是“从 query 到 item ID 序列”的映射。负样本的构造也很关键。如果只用随机负样本模型学不到“细粒度区分”。得物的做法是构造“难负样本”在层级化 ID 上和正样本只差一个字段的 item。比如正样本是“AJ1 芝加哥 男 42”难负样本可能是“AJ1 芝加哥 女 42”或者“AJ1 黑红 男 42”。这样模型必须学会区分“男/女”“芝加哥/黑红”这些细粒度字段才能真正提升召回精度。数据量级上得物这边是千万级的 query-item 对配合百万级的难负样本。训练时用课程学习先训简单样本再逐步加入难负样本避免模型一开始就被难负样本带偏。3.2 模型结构与训练策略底座选型与微调技巧底座模型的选择上得物没有直接用通用 LLM而是在一个中等规模的生成模型上做领域微调。原因很实际通用 LLM 的词表里没有商品 ID 的 token直接拿来用需要大量改造而且通用 LLM 的推理成本太高召回阶段扛不住。具体做法是用一个 1B 到 3B 参数量的生成模型作为底座把商品库的层级化 token 加入词表然后做两阶段训练。第一阶段是“领域预训练”用商品标题、描述、属性等文本数据让模型熟悉商品领域的语言分布。第二阶段是“召回微调”用 query-item 对做监督学习让模型学会从 query 生成 item ID。训练策略上有几个细节值得说。一是“字段级 loss 加权”品类、品牌这些高层字段的 loss 权重调高因为高层字段错了整个 ID 就废了配色、尺码这些低层字段的 loss 权重相对低因为低层字段错了至少还能召回一个“差不多”的商品。二是“beam search 训练”训练时就用 beam search 的路径做监督让模型学会在多个候选之间做区分而不是只学“最优路径”。实操心得微调时学习率要调得比常规 NLP 任务小因为商品 ID 的 token 是“新加入”的学习率太大会把底座模型的通用能力冲垮。得物这边用的是底座学习率的 1/5 到 1/10配合 warmup效果比较稳。3.3 线上部署延迟、吞吐与降级的工程权衡生成式召回的线上部署最大的挑战是延迟。ANN 检索是毫秒级的生成式解码是几十毫秒级的这个差距在交易搜索场景里是致命的。得物的做法是“分层召回 动态降级”。分层召回的意思是不是所有 query 都走生成式。高频 query、简单 query 走缓存或轻量模型只有长尾 query、复杂 query 才走生成式。这样整体延迟可控同时把生成式的算力用在“最需要它的地方”。动态降级的意思是线上实时监控生成式召回的延迟和成功率一旦超过阈值自动切回向量检索兜底。这样即使生成式模型出问题也不会影响整体搜索可用性。工程上还有几个优化点。一是“KV Cache 复用”同一个 query 的多次生成请求可以复用一部分 KV Cache减少重复计算。二是“批量解码”把多个 query 的生成请求打包成一个 batch提高 GPU 利用率。三是“量化推理”把模型权重做 INT8 量化推理速度能提升 30% 到 50%精度损失在可接受范围内。优化手段延迟收益精度影响适用场景KV Cache 复用20%-30%无同一 query 多次生成批量解码30%-40%无高并发场景INT8 量化30%-50%轻微下降延迟敏感场景分层召回50%长尾略降整体延迟优化4. 常见问题与排查技巧实录4.1 生成式召回“跑偏”了怎么办最常见的问题是模型生成的 item ID 看起来“语法正确”但和 query 意图对不上。比如搜“aj1 芝加哥”生成了一堆“aj1 黑红”。排查思路是分三步走。第一步看训练数据。是不是“芝加哥”和“黑红”在训练数据里经常一起出现如果是模型可能学到了“这两个配色相关”的错误关联。解决办法是在负样本里增加“同系列不同配色”的难负样本让模型学会区分。第二步看约束解码。是不是前缀树里“芝加哥”和“黑红”的路径太近导致 beam search 容易走错解决办法是调整前缀树的权重给高频正确路径更高的先验。第三步看多模态信号。如果 query 带图是不是视觉 token 的权重太高把文本信号压过去了解决办法是调整模态融合的权重让文本和视觉信号平衡。4.2 长尾 query 召回率上不去怎么破长尾 query 是生成式召回最该发力的地方但实际做下来长尾的召回率提升往往不如预期。原因通常是“长尾 query 的训练数据太少模型没见过”。得物的做法是“数据增强 冷启动策略”。数据增强方面用 query 改写、同义替换、属性组合等方式人工构造一批长尾 query 的训练样本。冷启动方面对新出现的 query 模式先用规则召回兜底同时把这些 query 的点击日志快速回流到训练数据里让模型在下一次更新时学到。还有一个技巧是“query 分解”把长尾 query 拆成“核心意图 修饰约束”核心意图走生成式召回修饰约束走规则过滤。这样即使生成式模型对长尾 query 理解不够规则过滤也能保证约束被满足。4.3 生成式召回和向量检索怎么协同生成式召回不是要“取代”向量检索而是和它协同。得物的做法是“双路召回 融合排序”生成式召回负责“精确意图”向量检索负责“语义泛化”两路结果合并后送排序模型。协同的关键是“去重和配额”。两路召回的结果会有重叠需要去重同时要控制两路结果的配额避免一路压过另一路。得物这边实测下来生成式召回占 60% 到 70%向量检索占 30% 到 40%整体效果最好。问题类型排查方向解决手段预期效果生成 ID 跑偏训练数据关联错误增加难负样本精度提升 5%-10%长尾召回低训练数据不足数据增强 规则兜底长尾召回提升 15%两路冲突配额失衡动态配额调整整体召回提升 3%-5%延迟超标解码开销大分层召回 量化延迟降低 40%4.4 几个容易踩的坑第一个坑是“过度依赖生成式”。有些团队一上来就把所有 query 都走生成式结果延迟爆炸、成本失控。正确做法是分层把生成式用在“向量检索搞不定”的场景。第二个坑是“忽略约束解码”。没有前缀树约束模型生成的 ID 大量无效召回率反而比向量检索还低。约束解码是必选项不是可选项。第三个坑是“训练数据不洗”。原始点击日志里的噪声很大直接拿来训会把模型带偏。必须做数据清洗和改写构造高质量的 query-item 对。第四个坑是“不做线上降级”。生成式模型的稳定性不如 ANN线上必须有降级方案。得物这边是“生成式超时自动切向量”保证搜索永远可用。5. 多模态与生成式召回的进一步结合5.1 视觉信号如何参与 item ID 生成前面提到多模态信号注入这里再展开说一层。得物的商品图质量很高鞋款、配色、材质这些信息在图上非常清晰。生成式召回如果能把视觉信号用好对“以图搜款”和“图文混合 query”场景的提升会非常明显。具体做法是用视觉编码器把商品图编码成一组 patch-level 的视觉 token然后通过一个 cross-attention 层让这些视觉 token 和文本 token 做交互。生成 item ID 的时候模型同时 attend 到文本 token 和视觉 token生成出来的 ID 会同时满足文本约束和视觉约束。实测下来这种做法的难点在于“视觉 token 的粒度”。粒度太粗视觉信号丢失粒度太细序列太长推理延迟上不去。得物这边用的是“区域级”粒度把商品图分成鞋面、鞋底、鞋带等几个区域每个区域编码成一个 token既保留了关键视觉信息又控制了序列长度。5.2 多模态召回的评测与调优多模态召回的评测不能只看整体召回率要分场景看。得物这边把评测集分成“纯文本 query”“纯图 query”“图文混合 query”三类分别看召回率。调优的时候重点是“模态权重”。纯文本 query 场景视觉信号权重调低纯图 query 场景视觉信号权重调高图文混合场景两者平衡。这个权重不是固定的而是根据 query 类型动态调整。还有一个调优点是“视觉 token 的预训练”。视觉编码器如果只在通用图像数据上预训练对商品图的细节比如鞋款的细微差别可能不够敏感。得物的做法是用商品图数据做一轮领域预训练让视觉编码器学会区分“AJ1 芝加哥”和“AJ1 黑红”这种细粒度差异。5.3 生成式召回的未来扩展方向从得物的实践来看生成式召回还有几个值得探索的方向。一是“端到端召回排序”现在召回和排序是分开的未来可能用同一个生成模型同时做召回和排序减少信息损失。二是“实时个性化”把用户历史行为编码成 token注入到生成过程里让召回结果更个性化。三是“跨模态生成”不仅生成 item ID还生成“为什么召回这个 item”的解释提升可解释性。这些方向都还在探索阶段但底层逻辑是一致的把更多的信号、更多的约束、更多的结构知识压缩进生成模型里让召回从“检索”变成“理解后的生成”。我个人在实际操作中的体会是生成式召回不是“银弹”它解决的是向量检索在“细粒度约束”和“长尾意图”上的短板但在“语义泛化”和“低延迟”上向量检索依然有优势。真正有效的方案是让两者协同各司其职。得物的实践也证明了这一点生成式召回占大头向量检索兜底整体效果比单用任何一路都好。如果你也在做交易搜索不妨先从“长尾 query”这个场景切入用生成式做增量而不是一上来就全量替换这样风险可控效果也更容易验证。