1. 从“卷向量”到“生成式召回”的范式转移逻辑1.1 为什么传统向量检索在交易搜索场景里越来越吃力做电商搜索的人都有一个共同感受向量检索这条路过去几年确实吃到了红利但最近两年越来越“卷”不动了。得物交易搜索这种场景用户输入的不是“红色连衣裙”这种标准query而是“适合夏天穿的显瘦百搭上衣女”、“送男朋友生日礼物200以内有面子”、“跟这双鞋搭配的裤子”。这些query背后藏着三层意图品类意图、属性意图、场景意图而且三者经常纠缠在一起。传统向量检索的做法是把query和商品标题、属性、类目全部编码成稠密向量然后在ANN索引里做近邻搜索。这套方案在“语义相似度”这个维度上表现不错但它有个致命短板——它只能召回“像”的东西不能召回“对”的东西。举个例子用户搜“结婚穿的红色高跟鞋”向量检索可能会召回“红色高跟鞋 新娘款”但也可能召回“红色运动鞋 婚庆款”因为它们在向量空间里距离很近。更麻烦的是当用户query里包含“200以内”这种硬性约束时向量检索几乎无能为力因为价格区间这种结构化信息在稠密向量里被稀释掉了。得物交易搜索的团队在实际业务中发现向量检索的召回天花板大概在60%-70%左右剩下的长尾需求、复杂意图、多跳推理需求靠向量检索根本覆盖不了。这就是为什么他们开始琢磨“生成式召回”这条路。1.2 生成式召回到底“生成”的是什么很多人第一次听到“生成式召回”会懵召回不是从索引里捞东西吗怎么变成生成了这里需要把概念掰清楚。生成式召回的核心思想是不再把召回当成“检索”问题而是当成“生成”问题。具体来说模型不再输出一个向量然后去索引里找近邻而是直接生成一个商品ID序列或者商品集合的语义描述。你可以把它理解成以前是拿钥匙去开锁现在是直接配一把新钥匙。得物交易搜索的做法更激进一些他们用的是生成式语义ID方案。简单说就是把每个商品映射成一个由多个token组成的语义ID比如“品类token属性token场景token价格带token”。然后训练一个序列到序列的模型输入是用户query输出是目标商品的语义ID序列。这样一来召回过程就变成了自回归生成过程模型可以一边生成一边约束比如生成到价格带token时直接限制在“0-200”这个区间。这个转变带来的最大好处是召回不再受限于向量空间的几何结构。向量检索的本质是“距离近的就是好的”但生成式召回的本质是“概率高的就是好的”。概率模型可以建模更复杂的条件依赖比如“用户搜‘送男友礼物’时如果历史行为里有过篮球鞋那篮球鞋相关商品的生成概率会显著提升”。这种个性化场景化的联合建模向量检索很难做到。1.3 得物交易搜索为什么敢第一个吃螃蟹得物这个平台有个特殊性商品供给相对集中但用户需求极度分散。潮鞋、潮服、潮玩这些品类SKU深度不大但用户搜索词五花八门。传统电商搜索那套“query改写多路召回粗排精排”的链路在得物这种场景下显得特别臃肿。他们敢做生成式召回有几个现实条件商品ID体系相对稳定得物的商品ID不像淘宝那样每天海量新增这给语义ID的构建和模型训练提供了稳定性。用户行为序列丰富得物用户浏览、收藏、购买的行为链路比较长这给生成式模型提供了充足的监督信号。算力预算相对充裕虽然外界总说“算力约束”但得物在搜索这个核心场景上还是愿意投入GPU资源的。当然最关键的还是业务痛点倒逼。向量检索的召回率卡在瓶颈上精排再强也救不回来。与其在向量检索上继续卷不如换条路走。2. 生成式召回的核心技术拆解与实操要点2.1 语义ID的构建把商品“翻译”成模型能读懂的语言生成式召回的第一步也是最关键的一步是给每个商品构建一个语义ID。这个语义ID不是简单的数字编号而是一个层次化的token序列。得物交易搜索团队的做法是先用多模态模型比如CLIP类的视觉-语言模型提取商品的图像特征和文本特征然后做层次化聚类。具体来说第一层聚类粗粒度品类比如“鞋”、“服装”、“配饰”第二层聚类细粒度品类比如“篮球鞋”、“跑步鞋”、“板鞋”第三层聚类属性维度比如“颜色”、“材质”、“风格”第四层聚类价格带比如“0-200”、“200-500”、“500-1000”每一层聚类都会得到一个token最终每个商品被表示成一个4-6个token的序列。这个序列就是它的语义ID。注意语义ID的层数不是越多越好。层数太多会导致token序列过长生成模型难以收敛层数太少则区分度不够。得物的经验是4-6层比较合适具体取决于品类复杂度。这里有个实操细节聚类的时候不能只用文本特征必须融合多模态特征。得物很多商品是潮鞋用户搜“aj1 黑红脚趾”时纯文本匹配可能召回“aj1 黑红”但视觉上“脚趾”这个细节只有图像能区分。所以语义ID的构建必须依赖多模态特征提取。2.2 生成模型的选择为什么是Seq2Seq而不是GPT得物交易搜索用的生成模型是基于Transformer的Seq2Seq架构而不是直接拿GPT做微调。这个选择背后有很实际的考量。GPT这类自回归语言模型本质是无条件生成或者弱条件生成。你给它一个query它生成的是自然语言文本而不是结构化的商品ID序列。要让GPT输出商品ID你得做大量的格式约束和微调而且推理时很难保证生成的ID一定在有效商品集合里。Seq2Seq架构的优势在于编码器可以充分理解query得物的query往往很短但意图很复杂编码器可以用BERT类的结构做深度语义理解。解码器可以受约束地生成解码时可以用前缀树Trie约束保证生成的每个token都在有效语义ID空间里。训练目标更直接直接以“query→目标商品语义ID”为训练样本监督信号非常明确。具体训练时他们用了对比学习交叉熵损失的混合目标。对比学习让相似query的语义ID表示更接近交叉熵损失保证生成准确性。这个组合在实验中比纯交叉熵提升了约8%的召回率。2.3 多模态融合在召回阶段的具体落地方式得物交易搜索的生成式召回不是纯文本的而是多模态融合的。具体来说query侧和商品侧都要做多模态处理。Query侧用户输入的文本query加上用户的历史行为序列浏览过的商品图像、点击过的商品标题一起编码成query表示。这里用到了多模态时序对齐技术把用户行为序列里的图像特征和文本特征在时间维度上对齐然后做融合。商品侧每个商品的语义ID构建时已经融合了图像和文本特征。但在生成式召回阶段还需要把商品的多模态特征文件比如图像embedding、文本embedding作为辅助信息注入到解码器中。得物的做法是在解码器的每一层用交叉注意力机制让生成的token去“关注”候选商品的多模态特征。这个设计的好处是当用户搜“这个鞋的搭配裤子”时模型可以通过图像特征理解“这个鞋”指的是哪双鞋然后生成搭配裤子的语义ID。纯文本模型做不到这一点。实操心得多模态融合在召回阶段最容易踩的坑是模态对齐。图像特征和文本特征的维度、分布往往不一致直接拼接效果很差。得物用的是对比学习预对齐门控融合的方式先让两个模态在对比学习目标下对齐再用门控网络动态决定每个模态的权重。2.4 训练数据的构造与负采样策略生成式召回的模型效果七分靠数据三分靠模型。得物交易搜索在训练数据构造上下了很大功夫。正样本构造用户点击并购买的商品作为强正样本用户点击但未购买的商品作为弱正样本用户收藏、加购的商品作为中等正样本负样本构造全局负采样从全量商品里随机采批次内负采样同一个batch里其他query的正样本作为当前query的负样本难负采样用向量检索召回的Top-K里排在前面的但用户没点的商品作为难负样本这里有个关键细节难负样本的比例不能太高。得物的经验是难负样本占比控制在20%-30%左右。太高会导致模型过度关注难样本泛化能力下降太低则模型学不到区分性。另外他们还用了课程学习策略先训练简单样本正样本明确、负样本差异大再逐步加入难样本。这个策略让模型收敛更稳定最终召回率提升了约5%。3. 从离线训练到线上服务的完整实操链路3.1 离线训练流程与关键参数配置得物交易搜索的生成式召回离线训练流程大致分为四步第一步语义ID构建输入全量商品的多模态特征图像embedding文本embedding方法层次化K-Means聚类每层聚类数分别为64、128、256、128输出每个商品的4层语义ID序列第二步训练数据生成输入用户行为日志query、点击商品、购买商品方法按上述正负样本策略构造训练样本输出约5000万条训练样本第三步模型训练模型6层编码器6层解码器的Transformer隐藏层维度512注意力头数8学习率3e-4带warmupBatch size1024训练轮数10-15轮硬件8卡A100训练时间约3天第四步模型评估离线指标Recall100、MRR、NDCG10在线指标点击率、转化率、搜索无结果率注意离线指标和在线指标有时候会打架。得物遇到过离线Recall提升但在线点击率下降的情况原因是生成式召回召回了更多“语义相关但用户不感兴趣”的商品。后来他们在训练目标里加入了用户兴趣权重让模型更关注用户历史行为相关的商品。3.2 线上推理的工程优化如何把生成式召回做到50ms以内生成式召回最大的工程挑战是推理延迟。自回归生成是一个token一个token往外蹦的如果每个token都要跑一次完整的前向传播延迟根本扛不住。得物交易搜索的优化方案是KV Cache缓存已生成token的Key和Value避免重复计算束搜索Beam Searchbeam size设为3-5平衡效果和延迟前缀树约束用Trie结构约束解码空间避免生成无效token量化推理用FP16甚至INT8量化减少计算量批处理把多个用户的query拼成一个batch一起推理经过这些优化线上单次生成式召回的延迟控制在30-50ms基本满足搜索场景的实时性要求。这里有个实操细节束搜索的beam size不是越大越好。得物试过beam size10离线Recall提升了2%但线上延迟翻倍最终ROI不划算。beam size3是他们的甜点值。3.3 与现有召回链路的融合方式生成式召回不是要完全替代向量检索而是与现有链路融合。得物交易搜索的做法是多路召回并行生成式召回、向量召回、文本召回、规则召回同时跑动态权重分配根据query类型动态调整各路召回的权重。比如长尾query、复杂意图query生成式召回权重调高简单query、热门query向量召回权重调高去重与截断多路召回结果合并后按商品ID去重然后按分数截断到Top-200这个融合策略的关键是动态权重。得物用了一个轻量级的分类模型根据query的长度、实体数量、历史点击分布等特征预测每路召回的权重。这个分类模型本身也是离线训练的推理延迟可以忽略不计。实操心得多路召回融合时分数归一化非常重要。不同召回路的分数分布差异很大直接加权求和会导致某一路主导。得物用的是分位数归一化把每路召回的分数映射到0-1区间然后再加权。3.4 效果评估与迭代节奏得物交易搜索的生成式召回上线后经历了三个迭代阶段第一阶段冷启动生成式召回只在小流量5%上实验主要观察指标召回率、延迟、无结果率发现问题语义ID构建时部分长尾品类聚类效果差第二阶段优化语义ID对长尾品类单独做聚类增加聚类层数引入多模态特征提升区分度召回率从62%提升到71%第三阶段全量上线生成式召回权重逐步提升到30%-40%与向量召回形成互补整体搜索转化率提升约8%这个迭代节奏的关键是小步快跑。生成式召回这种新范式一次性全量上线风险太大必须通过小流量实验逐步验证。4. 常见问题与排查技巧实录4.1 生成式召回常见问题速查表问题现象可能原因排查方法解决方案召回结果重复率高语义ID区分度不够检查语义ID的层次聚类分布增加聚类层数或调整聚类数长尾query召回差训练样本中长尾query占比低统计训练样本的query分布对长尾query做上采样或数据增强推理延迟高束搜索beam size过大监控不同beam size下的延迟降低beam size或用量化推理生成无效商品ID前缀树约束未生效检查解码时的Trie约束逻辑修复Trie构建或解码约束多模态融合效果差模态对齐不充分可视化图像和文本embedding分布加强对比学习预对齐线上效果低于离线训练数据与线上分布不一致对比离线训练集和线上query分布用线上数据做增量训练4.2 语义ID构建中的三个坑坑一聚类数拍脑袋定很多人做层次聚类时每层的聚类数凭感觉定。得物的经验是第一层聚类数不要超过128否则token空间太大模型学不动最后一层聚类数可以适当大一些比如256-512保证区分度。坑二忽略品类差异不同品类的商品分布差异很大。鞋类的颜色、材质维度很重要服装的版型、风格维度很重要。得物的做法是分品类构建语义ID而不是全局统一。坑三语义ID更新频率过高语义ID如果频繁更新会导致模型需要反复重新训练。得物把语义ID的更新频率控制在季度级别平时只做增量更新。4.3 生成式召回与向量召回的协同避坑指南生成式召回和向量召回不是替代关系而是互补关系。但在实际协同中有几个坑要注意不要用同一套评估指标向量召回看的是向量空间距离生成式召回看的是生成概率。评估时要分开看再综合看。不要同时调两路召回的参数调参时要固定一路调另一路否则无法归因。不要忽略去重逻辑两路召回结果合并时去重逻辑要高效。得物用的是布隆过滤器精确去重的两级去重兼顾效率和准确性。不要忽视线上反馈生成式召回的线上表现可能和离线差异很大必须建立实时监控快速回滚机制。4.4 算力约束下的优化技巧虽然得物在搜索场景算力相对充裕但生成式召回的算力消耗还是比向量检索大很多。在算力约束下有几个优化技巧模型蒸馏用大模型训小模型得物把6层Transformer蒸馏到3层效果损失不到2%但推理速度提升一倍。动态计算简单query走轻量模型复杂query走完整模型。得物用了一个query复杂度分类器动态路由。缓存机制热门query的生成结果缓存起来下次直接返回。得物的缓存命中率约15%但节省了约20%的算力。混合精度训练用FP16训练显存占用减少一半训练速度提升30%。5. 生成式召回的未来演进方向5.1 从生成式召回走向生成式搜索得物交易搜索的生成式召回目前还只是召回阶段。但他们的目标不止于此而是生成式搜索——从query理解到召回、排序、甚至展示全部用生成式模型串起来。这个方向的技术挑战很大但想象空间也很大。比如用户搜“送男友生日礼物”生成式搜索可以直接生成一个“礼物清单”而不是一堆商品列表。这个清单里可能包含鞋、衣服、配饰甚至搭配建议。5.2 多模态大模型在召回中的深度应用得物交易搜索已经在用多模态模型做语义ID构建但还比较浅层。未来他们计划用多模态大语言模型做端到端的召回。具体来说把用户query、用户行为序列、商品多模态特征全部输入一个大模型直接输出召回结果。这个方案的优势是统一建模不需要分阶段处理。但挑战也很明显推理延迟、算力消耗、训练数据规模都是需要解决的问题。5.3 生成式召回的评估体系重构传统的召回评估指标Recall、MRR、NDCG是为检索式召回设计的不一定适合生成式召回。得物正在探索新的评估体系比如生成多样性召回结果的多样性避免“千篇一律”意图覆盖率召回结果覆盖用户意图的程度生成置信度模型对生成结果的置信度分布这些新指标还在实验阶段但方向是明确的生成式召回需要生成式的评估方式。我在实际参与类似项目的过程中体会到生成式召回最大的价值不是“替代向量检索”而是打开了召回阶段的天花板。向量检索的时代召回率卡在70%就上不去了生成式召回让这个天花板变成了90%甚至更高。当然代价是工程复杂度、算力消耗、数据要求的全面提升。得物交易搜索的实践说明这条路走得通但需要团队有足够的工程能力和数据积累。如果你也在做搜索召回不妨先从小流量实验开始用生成式召回补足向量检索的短板而不是一上来就全面替换。踩过几次坑之后你会发现生成式召回和向量召回的最佳关系不是谁替代谁而是谁补谁的位。