得物交易搜索生成式召回：从向量检索到条件生成的范式跃迁

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 常见问题速查表

实操心得：生成式召回的调参优先级是：条件分解质量 > 多模态对齐 > 融合策略 > 多样性控制。前两个是基础，后两个是锦上添花。如果条件分解都做不对，后面调再多参数也没用。

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实验体系应该很成熟，但小团队做这个方向，建议先用小流量做在线验证，再逐步扩量。