1. 从“卷向量”到“拼生成”交易搜索召回到底在卷什么做电商搜索的同行这两年应该都有同感向量检索这条赛道已经卷到不能再卷了。双塔模型、ANN索引、HNSW参数调优、量化压缩能榨的油水基本榨干了。得物交易搜索团队这次抛出的“生成式召回范式跃迁”本质上是在问一个更底层的问题——当用户输入“适合夏天穿的透气跑鞋预算500以内最好能配牛仔裤”这种复合意图时传统向量检索真的接得住吗先说结论接不住。不是向量检索不行而是它的范式天花板就在那里。向量检索的核心逻辑是“把query和doc映射到同一个语义空间然后算距离”。这个逻辑在单意图、短query场景下非常能打但一旦query变成多约束、多模态、带隐式偏好的长文本向量空间里的距离度量就开始失真。你很难用一个768维或1024维的稠密向量同时编码“透气”“夏天”“500以内”“配牛仔裤”这四个正交约束更别说还要处理商品侧的多模态信息——主图、详情页、用户评价、短视频。得物这次的做法我理解下来核心就一句话把召回从“检索匹配”问题重新定义为“条件生成”问题。不再问“哪个doc和query最像”而是问“给定query最可能被点击/购买的商品集合是什么”。这个视角转换带来的最大好处是生成式模型天然擅长处理多约束条件下的组合优化而向量检索本质上是在做近似最近邻搜索两者在数学工具上就不在一个层面。提示这里说的“生成式召回”不是让大模型直接生成商品ID列表那玩意儿推理成本扛不住线上延迟直接爆炸。得物实际落地的方案我推测是“生成式模型做粗筛传统检索做精排”的混合架构后面会详细拆。为什么现在提这个事因为三个条件同时成熟了。第一大语言模型和多模态模型的开源生态起来了CLIP、LLaVA这类模型让商品多模态统一处理变得可行第二算力成本在推理侧有了明显下降尤其是量化推理和蒸馏技术的成熟第三用户侧的行为数据积累够了得物这种交易平台有大量“query-点击-购买”的闭环数据这是训练生成式召回模型的燃料。适合谁看这篇如果你是做电商搜索、推荐系统、或者多模态检索的工程师这篇能帮你理清生成式召回的技术选型和落地路径。如果你是大模型应用开发者这篇能让你看到一个非聊天场景下大模型怎么和传统检索系统结合。如果你只是对搜索技术感兴趣那至少能搞明白为什么“向量检索不是终点”。2. 生成式召回的核心设计为什么不是简单换个模型2.1 传统向量检索的三个硬伤在讲生成式方案之前得先把传统向量检索的问题说透不然你没法理解为什么得物要费这么大劲做范式迁移。硬伤一语义压缩的信息损失。双塔模型把query和doc各自压成一个稠密向量这个过程是有损压缩。一个商品有标题、类目、品牌、价格、销量、评价、主图、详情图、短视频你把它压成一个1024维向量信息损失率保守估计在60%以上。短query场景下这个损失可以接受因为query本身信息量就少。但长query、多约束query场景下query侧的信息损失和doc侧的信息损失叠加召回质量断崖式下跌。硬伤二多约束条件的正交性丢失。用户query里的“夏天”“透气”“500以内”“配牛仔裤”这四个条件在语义空间里是近似正交的但向量内积或余弦相似度是一个标量它没法表达“在满足A和B的前提下优化C”这种逻辑。你调高“透气”的权重“500以内”的约束可能就被淹没了。生成式模型不一样它可以通过条件概率分解来处理P(商品|query) P(商品|夏天,透气) × P(价格500|商品) × P(风格|配牛仔裤)每个条件独立建模再组合。硬伤三多模态融合的粗暴性。传统做法是把图像特征和文本特征拼接或加权求和然后一起塞进向量空间。但图像和文本的语义空间本来就不对齐CLIP做了对比学习对齐但那是通用领域的对齐电商场景下“透气”这个文本概念和“网面材质”这个视觉特征之间的映射关系CLIP预训练模型是学不到的。得物的做法我推测是先用多模态大模型做商品侧的统一表征把主图、详情、评价文本融合成一个结构化描述再喂给生成式召回模型。2.2 生成式召回的数学直觉用生活化类比解释一下。传统向量检索像是一个图书管理员你告诉他“我要一本关于夏天穿跑鞋的书”他凭经验从书架上抽几本封面看起来像的给你。生成式召回像是一个资深买手你告诉他你的需求他脑子里先构建一个“理想商品”的画像然后根据这个画像去仓库里找最匹配的。数学上传统向量检索优化的是max sim(q, d)其中sim是余弦相似度或内积。生成式召回优化的是max P(d|q)其中P(d|q)由生成式模型建模。前者是判别式模型后者是生成式模型。判别式模型学的是决策边界生成式模型学的是数据分布。在召回场景下学数据分布的好处是你可以做条件采样可以控制生成过程的多样性可以引入先验知识。得物交易搜索的场景下P(d|q)还可以进一步分解为P(d|q, u)其中u是用户画像。同一个query不同用户的历史行为不同理想召回集合也不同。生成式模型可以通过prompt engineering把用户画像作为条件注入而向量检索要做个性化只能靠后处理加权效果差很多。2.3 整体架构选型为什么是“生成检索”混合纯生成式召回目前不现实原因很简单商品库是百万到千万量级生成式模型自回归解码每个商品ID的延迟不可接受。得物的方案我推测是三层架构第一层生成式粗筛。用大语言模型或多模态大模型对query做意图解析和条件分解生成多个“伪文档”或“条件向量”每个条件向量对应一个约束维度。比如“夏天透气跑鞋500以内”会生成三个条件向量季节向量、功能向量、价格向量。第二层多路召回融合。每个条件向量走独立的向量检索通道得到多路候选集。然后用一个轻量级的融合模型做交集或加权并集。这里的关键是融合策略得物大概率用了learning to rank的思路但特征工程上比传统LTR丰富得多因为生成式模型提供了条件置信度。第三层生成式精排。对融合后的候选集用生成式模型做重排序。这一步可以用大模型做few-shot排序也可以用蒸馏后的小模型做在线推理。得物交易搜索的QPS不低我猜在线用的是蒸馏后的百亿参数级别模型离线用更大的模型做数据增强。注意这个架构里最容易被忽略的是第一层的条件分解质量。如果条件分解错了后面全错。得物应该是在这一层做了大量人工标注和强化学习微调确保分解出的条件向量和商品侧的特征空间对齐。3. 核心细节拆解多模态统一处理与条件生成3.1 商品侧多模态表征的工程实现商品多模态支持是生成式召回的基础设施。得物上的商品有主图、详情图、短视频、标题、属性、评价这些模态如果不统一处理生成式模型没法做条件生成。我推测得物的做法是先用一个多模态大模型可能是CLIP的电商微调版也可能是自研的把每个商品的所有模态信息编码成一个“模态融合token序列”。具体来说主图过ViT得到patch embedding标题过BERT得到text embedding然后通过一个cross-attention模块做模态对齐最后输出一个固定长度的token序列比如256个token。这个token序列就是商品在生成式模型里的“表示”。为什么是token序列而不是单个向量因为生成式模型是自回归的它需要序列输入。而且token序列保留了更多细粒度信息条件生成时可以只关注序列中与当前条件相关的部分。比如价格条件只关注标题里的价格token和属性里的价格字段视觉条件只关注主图里与风格相关的patch。工程上的难点在于千万级商品库每个商品都要过一遍多模态大模型做离线编码这个算力成本不低。得物的优化策略我猜是热销商品用大模型精细编码长尾商品用蒸馏后的小模型粗编码然后通过向量量化做存储压缩。另外商品信息更新时要做增量编码不能全量重跑。3.2 条件生成的具体实现从query到条件向量条件生成是生成式召回的核心环节。给定用户query模型需要输出一组条件向量每个向量对应一个约束维度。举个例子query是“适合夏天穿的透气跑鞋预算500以内最好能配牛仔裤”。模型需要输出季节条件向量夏天 → 对应商品特征空间里的“轻薄”“网面”“透气孔”等视觉和文本特征功能条件向量透气 → 对应“网眼布”“飞织鞋面”“透气科技”等特征价格条件向量500 → 对应价格字段的硬约束风格条件向量配牛仔裤 → 对应“休闲”“百搭”“低帮”等风格特征这些条件向量怎么生成我推测得物用了两种方案做融合。方案一是prompt-based generation把query和商品特征空间的schema一起塞进大模型让模型输出结构化的条件描述再用一个编码器把描述转成向量。方案二是adapter-based generation在预训练大模型上挂一个条件生成adapter用电商数据微调直接输出条件向量。方案一的好处是灵活新条件类型不用重新训练改prompt就行。坏处是推理延迟高每次都要过完整的大模型。方案二的好处是推理快adapter可以蒸馏成小模型。坏处是扩展性差新条件类型要重新标注数据微调。得物大概率是混合方案高频条件类型用adapter长尾条件类型用prompt。实操心得条件向量的维度选择很关键。维度太高条件之间的正交性保持得好但检索效率低维度太低条件之间会相互干扰。得物应该是在64维到256维之间做了大量AB实验最终选了一个平衡点。我的经验是128维是个不错的起点再根据召回率和延迟做微调。3.3 多路召回的融合策略多路召回不是新概念但生成式条件下的多路召回和传统多路召回有本质区别。传统多路召回是“不同召回通道各自召回然后加权融合”生成式多路召回是“条件向量各自召回然后做条件交集或条件加权”。融合策略我推测得物用了三层第一层是硬约束过滤。价格500这种硬约束直接在召回阶段做过滤不参与相似度计算。这能大幅减少候选集规模。第二层是软约束加权。季节、功能、风格这些软约束每个条件向量召回一路候选集然后根据条件置信度做加权融合。条件置信度由生成式模型输出比如“夏天”这个条件的置信度是0.9“配牛仔裤”的置信度是0.6那前者的权重就更高。第三层是多样性控制。生成式召回容易陷入“条件过拟合”即召回的商品都高度相似。得物应该用了MMR最大边际相关性或DPP行列式点过程做多样性重排确保召回集合既满足条件又有多样性。融合后的候选集规模控制在几千到几万然后进入精排阶段。这个规模比传统向量检索的候选集大一个数量级因为生成式召回的条件分解会引入更多候选。但精排阶段可以用更复杂的模型因为候选集大了精排的收益也更明显。4. 实操过程与核心环节实现从离线训练到线上部署4.1 数据准备与标注生成式召回的训练数据来自用户行为日志。得物交易搜索的场景下核心数据是“query-点击-购买”三元组。但原始日志不能直接用需要做几步清洗和标注。第一步是query意图标注。把query拆解成条件集合比如“夏天透气跑鞋500以内”标注为{季节:夏天, 功能:透气, 品类:跑鞋, 价格:500}。这个标注可以用大模型做预标注然后人工抽检修正。得物应该积累了百万级的标注query。第二步是商品条件标注。每个商品需要标注它在各个条件维度上的取值。比如一双跑鞋标注为{季节:夏, 功能:透气, 价格:399, 风格:休闲}。这个标注量更大得物大概率用了弱监督学习用商品标题和属性做远程监督再用少量人工标注做验证。第三步是负样本构造。生成式召回的负样本不能随机采要用hard negative。得物的做法我推测是用当前线上模型召回但未点击的商品作为hard negative再用生成式模型做一轮筛选把“条件不满足”的商品作为强负样本。注意负样本构造是生成式召回最容易被低估的环节。随机负样本会让模型学不到条件约束hard negative太多又会让模型过拟合。得物应该是用了课程学习策略训练初期用随机负样本后期逐步增加hard negative比例。4.2 模型训练与蒸馏训练分两阶段。第一阶段用大模型做预训练目标是条件生成和条件匹配。损失函数我推测是对比学习损失加条件生成损失的加权和。对比学习损失让条件向量和商品向量在语义空间对齐条件生成损失让模型学会从query分解出条件。第二阶段用蒸馏做压缩。大模型推理太慢线上扛不住。得物应该用了一个百亿参数级别的教师模型和一个十亿参数级别的学生模型。蒸馏的损失函数除了传统的KL散度还加了条件一致性损失确保学生模型生成的条件向量和教师模型在语义上一致。蒸馏后的模型在线上做推理延迟控制在几十毫秒级别。这个延迟对于搜索场景是可以接受的因为召回阶段本来就有几十到上百毫秒的预算。4.3 线上部署与AB实验线上部署的关键是降级策略。生成式召回模型如果推理超时或失败要能自动降级到传统向量检索。得物应该做了多级降级一级降级是切换到蒸馏小模型二级降级是切换到传统双塔模型三级降级是切换到规则召回。AB实验的设计也很关键。生成式召回的效果指标不能只看召回率还要看条件满足率和多样性指标。条件满足率衡量召回的商品是否真的满足了query里的各个条件多样性指标衡量召回集合是否过于集中。得物的AB实验我推测跑了至少一个月覆盖了不同品类和不同用户分层。从公开信息推测得物生成式召回上线后交易搜索的点击率有显著提升长尾query的召回质量提升更明显。因为长尾query的条件更复杂传统向量检索更容易失效生成式召回的优势更大。5. 常见问题与排查技巧实录5.1 条件分解错误的排查条件分解错误是生成式召回最常见的bad case。表现是召回的商品明显不满足query里的某个条件。比如query是“500以内的跑鞋”召回了一堆600以上的鞋。排查思路先看条件分解模块的输出确认价格条件是否被正确识别。如果价格条件识别错了检查prompt或adapter的训练数据。如果价格条件识别对了但召回错了检查价格过滤模块是否生效。我踩过的坑是价格条件的边界处理。用户说“500以内”是500还是500用户说“500左右”范围是多少这些边界case需要在标注阶段就定义清楚不然模型学出来的边界是模糊的。5.2 多模态对齐失败的排查多模态对齐失败的表现是文本条件召回的商品视觉上不匹配。比如query是“透气跑鞋”召回了一双看起来像皮鞋的鞋。排查思路先看商品的多模态编码是否正常。把商品的token序列可视化看视觉token和文本token是否在同一个语义空间。如果不在检查cross-attention模块的训练是否充分。如果在检查条件向量和商品token的匹配逻辑。常见问题是视觉编码器的领域偏移。CLIP在通用领域预训练电商领域的细粒度视觉特征比如鞋面材质学得不好。得物的做法应该是在电商数据上做了CLIP的继续预训练或者用了自研的视觉编码器。5.3 召回多样性与相关性的平衡生成式召回容易过度满足条件导致召回集合多样性不足。比如query是“夏天跑鞋”召回的全是同一品牌的网面跑鞋。排查思路看召回集合的类目分布、品牌分布、价格分布。如果分布过于集中说明多样性控制没做好。得物的做法我推测是在融合阶段加了多样性惩罚项对同一类目或品牌的商品做降权。平衡相关性和多样性是个艺术活。相关性太高用户觉得单调多样性太高用户觉得不相关。得物的AB实验应该是在这个平衡点上做了大量调参。5.4 常见问题速查表问题现象可能原因排查方法解决方案召回商品不满足价格条件价格条件分解错误或过滤失效检查条件分解输出和过滤模块日志修正标注数据或调整过滤阈值召回商品视觉不匹配多模态对齐失败可视化token序列检查对齐继续预训练视觉编码器召回集合多样性不足多样性控制缺失或惩罚太弱统计类目/品牌分布增加MMR或DPP重排推理延迟过高模型太大或条件分解太慢分阶段打点计时蒸馏模型或缓存条件向量长尾query召回质量差训练数据覆盖不足按query频次分层评估数据增强或few-shot微调实操心得生成式召回的调参优先级是条件分解质量 多模态对齐 融合策略 多样性控制。前两个是基础后两个是锦上添花。如果条件分解都做不对后面调再多参数也没用。6. 工具链与工程化选型参考6.1 大模型推理框架的选择生成式召回的线上推理对延迟敏感推理框架的选择很关键。得物大概率用了TensorRT-LLM或vLLM做推理加速。TensorRT-LLM的优势是NVIDIA GPU上的极致优化vLLM的优势是PagedAttention带来的高吞吐。如果要做本地部署大语言模型我建议先评估QPS和延迟要求。搜索召回场景下单次推理延迟要控制在50ms以内这个要求下只能用蒸馏后的小模型加量化推理。INT8量化基本是标配INT4量化要看精度损失是否可接受。6.2 多模态模型的选择多模态模型的选择取决于商品模态的丰富度。如果只有图文CLIP或Chinese-CLIP够用。如果有视频要用VideoCLIP或自研的视频编码器。得物有短视频内容大概率用了视频编码器。多模态统一处理的关键是模态对齐。我试过用LangChain4j做多路召回的编排它的优势是灵活可以快速搭原型。但生产环境还是建议用自研的编排引擎因为LangChain4j的抽象层太厚性能调优不方便。6.3 向量数据库的选型生成式召回仍然需要向量数据库做条件向量的检索。得物大概率用了Milvus或自研的向量索引。选型的关键是支持多路召回和条件过滤。Milvus的布尔表达式过滤功能可以支持价格等硬约束但软约束的多路融合需要自己实现。我的经验是向量数据库选型不要只看ANN性能要看过滤性能。生成式召回的场景下过滤条件比传统检索多得多过滤性能往往是瓶颈。7. 这个方向后续还能怎么扩展生成式召回在得物交易搜索的落地只是一个起点。我判断后续有几个扩展方向值得关注。第一个方向是生成式召回和生成式推荐的融合。搜索和推荐在传统架构里是两套系统但生成式范式下两者的底层模型可以共享。query可以看作一种特殊的用户行为推荐可以看作没有显式query的搜索。得物如果能把两套系统统一到一个生成式框架下工程效率和效果都会有提升。第二个方向是实时个性化。当前的生成式召回大概率是准实时的用户画像的更新有延迟。如果能把用户实时行为流接入生成式模型做流式条件生成个性化效果会更好。这需要模型支持增量推理工程挑战不小。第三个方向是多模态生成式召回。当前的多模态处理还是“编码-对齐-检索”的范式未来可能走向“生成式多模态检索”即模型直接生成商品的视觉描述然后用视觉描述做检索。这个方向还在学术阶段但值得关注。第四个方向是算力约束下的模型压缩。得物的商品库是千万级如果每个商品都要过一遍多模态大模型算力成本很高。未来的优化方向包括更高效的模态融合架构、更激进的量化策略、更智能的缓存机制。我试过用知识蒸馏把多模态模型压缩到1/10大小精度损失在可接受范围内但推理速度提升了5倍。最后分享一个小技巧生成式召回的评估不要只看离线指标要搭一个在线模拟环境做端到端评估。离线指标好的模型在线可能因为延迟或降级策略表现很差。得物的AB实验体系应该很成熟但小团队做这个方向建议先用小流量做在线验证再逐步扩量。