1. 从“关键词匹配”到“意图生成”交易搜索的召回困境到底卡在哪做电商搜索的人都有一个共同的体感召回环节决定了搜索体验的天花板。排序再精妙、重排再花哨如果召回阶段就没把用户真正想要的商品捞出来后面全是白搭。得物交易搜索面临的场景更特殊——这是一个以潮流商品、限量球鞋、设计师品牌为核心的交易场域用户的搜索行为跟传统货架电商有本质区别。传统电商搜索的召回主力是倒排索引向量检索的双路架构。倒排索引负责精确匹配和类目过滤向量检索负责语义泛化。这套架构在过去五六年里被反复打磨已经非常成熟。但得物的交易搜索场景里我观察到几个很明显的痛点第一长尾query的语义鸿沟。得物上大量用户搜索的是“适合夏天穿的浅色系板鞋”“跟某某联名那款差不多的外套”“上次刷到的那双绿色跑鞋”。这些query没有明确的关键词锚点倒排索引基本抓瞎向量检索虽然能泛化但embedding模型对“潮流语义”的理解往往不够精准——它分不清“复古”和“复刻”在球鞋语境下的微妙差异。第二多模态信息的割裂。得物的商品天然是多模态的主图、细节图、上脚图、视频、尺码表、材质说明、用户评价里的实拍图。传统召回链路里文本走文本的通道图片走图片的通道最后在粗排阶段才做融合。这种“先分后合”的模式导致大量跨模态的关联信号在召回阶段就丢失了。第三用户意图的动态性。潮流消费的意图变化极快。今天流行“美拉德风”明天可能就变成“薄荷曼波”。向量检索依赖的embedding索引更新周期长根本追不上这种变化速度。而生成式召回的核心优势恰恰在于它不依赖预先构建的索引而是实时理解query意图动态生成召回策略。这就是为什么得物交易搜索团队会提出“召回范式跃迁”这个命题。不是向量检索不好而是单一范式已经触到了天花板。生成式召回不是要替代向量检索而是在它之上叠加一层“意图理解与策略生成”的能力让召回从“检索已有索引”变成“生成最优召回路径”。2. 生成式召回到底“生成”了什么拆解得物方案的核心机制很多人第一次听到“生成式召回”会懵召回不就是从海量商品里捞出一小撮吗生成式模型不是用来生成文本、图片的吗它怎么“生成”召回结果这里需要把概念掰开。生成式召回里的“生成”生成的不是商品本身而是召回策略、召回路径、以及query的语义表示。具体来说得物的方案里生成式模型承担了三个核心职责2.1 意图解析与query改写把“人话”翻译成“机器能懂的检索指令”用户输入“有没有那种看起来旧旧的但是很贵的鞋”传统向量检索会把这个query编码成一个稠密向量然后去ANN索引里找最近邻。但“旧旧的但是很贵”这个语义太模糊了embedding模型很难把它精准映射到“复古做旧”“限量联名”“高客单价”这些商品属性上。生成式模型的做法是先理解意图再生成结构化的检索指令。比如它可能输出{ intent: 复古潮流鞋款, attributes: { style: [做旧, 复古, vintage], price_range: high, category: sneaker }, recall_strategy: [倒排索引精确匹配style标签, 向量检索语义泛化, 多模态检索匹配做旧质感图片] }这个结构化指令才是真正驱动召回的依据。生成式模型在这里扮演的是“翻译官策略师”的角色它把自然语言的模糊意图翻译成多条可执行的召回路径。2.2 多模态统一表示让图片和文本在同一个语义空间里对话得物商品的多模态特性决定了召回必须能跨模态。用户搜“像这张图里的外套”上传一张图片系统需要同时理解图片的视觉特征和文本query的语义然后在统一的表示空间里做检索。生成式多模态模型比如基于CLIP架构改进的视觉语言模型在这里的作用是把商品的主图、细节图、文本描述、用户评价里的实拍图全部编码到同一个语义空间。这样当用户上传一张图片时系统可以直接在统一空间里做跨模态检索而不需要先分别检索再融合。实操中有一个关键细节多模态统一表示的质量高度依赖训练数据的质量和多样性。得物的方案里商品图片的标注体系非常细不仅有类目、品牌、颜色这些基础标签还有“鞋型”“材质纹理”“穿搭风格”等潮流专属标签。这些标签的构建成本很高但它们是生成式召回能精准理解潮流语义的基础。2.3 动态召回策略生成根据query复杂度自适应调整召回路径不是所有query都需要走多路召回。简单query比如“Nike Air Force 1 白色 42码”倒排索引直接搞定没必要动用生成式模型。复杂query比如“想要一双适合通勤又能搭配裙子的复古跑鞋”才需要生成式模型介入生成多路召回策略。得物的方案里有一个query复杂度评估模块它会根据query的长度、语义模糊度、历史点击行为等特征决定是否触发生成式召回。这个模块的存在非常关键因为生成式模型的推理成本远高于传统检索如果所有query都走生成式系统吞吐根本扛不住。query类型示例召回策略是否触发生成式精确型“AJ1 芝加哥 42码”倒排索引类目过滤否语义型“适合夏天穿的透气跑鞋”向量检索属性过滤否模糊型“上次刷到的那双绿色鞋”生成式意图解析多路召回是多模态型上传图片“找类似款”多模态统一检索生成式策略是这个分流机制是整套方案能落地的工程前提。没有它生成式召回就是一个实验室玩具根本没法上生产。3. 工程落地中最难啃的三块骨头延迟、索引、冷启动理论讲完了真正动手做的时候你会发现生成式召回的工程复杂度远超预期。我梳理了得物方案里最棘手的三个工程问题以及对应的解决思路。3.1 推理延迟生成式模型怎么塞进召回链路召回环节对延迟极其敏感。传统向量检索的P99延迟通常在10ms以内而一个7B参数的大语言模型单次推理延迟轻松超过100ms。如果直接把生成式模型塞进召回链路整个搜索的响应时间会直接崩掉。得物的解法是异步预生成缓存命中。具体来说对于高频query系统会离线预生成召回策略缓存到Redis里线上直接命中缓存延迟控制在5ms以内。对于中频query系统会做近线预生成提前5-10分钟预测可能出现的query变体生成策略后缓存。对于低频长尾query才走线上实时生成但会做模型蒸馏和量化把推理延迟压到50ms以内。这里有一个经验性的取舍缓存命中率每提升10%整体P99延迟能下降约15ms。所以得物在query归一化和意图聚类上投入了大量精力目的就是提高缓存命中率。3.2 索引更新生成式召回需不需要重建索引传统向量检索依赖ANN索引索引更新是一个重操作。生成式召回理论上不依赖索引但它依赖商品语义表示库——也就是所有商品的统一语义向量。这个库的更新频率直接决定了召回的新鲜度。得物的做法是双缓冲索引增量更新。主索引每天全量重建一次增量索引每15分钟更新一次新上架和修改过的商品。生成式模型在生成召回策略时会同时查询主索引和增量索引确保新商品能及时被召回。这个机制的工程复杂度在于双缓冲索引的一致性维护。如果主索引和增量索引的数据版本不一致可能会出现“策略生成了但商品查不到”的情况。得物的方案里有一个版本协调器它会确保生成式模型看到的商品语义表示和实际检索时用的索引版本是一致的。3.3 冷启动新商品和新用户怎么被生成式召回覆盖冷启动是召回系统的经典难题。新上架的商品没有历史点击数据新用户没有历史行为生成式模型怎么为他们生成有效的召回策略得物的解法是内容特征兜底探索机制新商品上架时系统会强制提取其多模态特征图片、标题、属性、类目生成一个“内容语义指纹”。生成式模型在生成召回策略时会优先考虑内容语义匹配而不是依赖行为数据。新用户的首次搜索系统会走“探索式召回”生成式模型会生成一组多样化的召回策略覆盖不同风格、价格带、类目的商品然后根据用户的实时点击反馈快速调整。这个探索机制的关键在于反馈闭环的速度。得物的方案里用户的每一次点击、加购、收藏都会在秒级内反馈到生成式模型的策略调整中。这种实时反馈能力是传统召回架构不具备的。4. 多模态融合在召回阶段的实际效果数据与案例说了这么多机制最终还是要看效果。得物交易搜索团队在内部做过AB实验对比了传统向量检索和生成式召回的多个核心指标。我整理了一些关键数据数据经过脱敏处理仅反映趋势指标传统向量检索生成式召回变化幅度召回率Recall10062.3%78.6%16.3pp长尾query召回率41.2%67.8%26.6pp多模态query召回率38.5%72.1%33.6pp平均响应延迟P9912ms48ms36ms缓存命中率N/A73.5%N/A从数据可以看出生成式召回在召回率上的提升非常显著尤其是长尾query和多模态query提升幅度超过25个百分点。代价是延迟增加了36ms但通过缓存机制大部分请求的实际延迟增加控制在15ms以内。4.1 一个真实案例用户搜“像上次买的那双鞋但颜色换成绿色”这是一个典型的模糊多模态query。传统向量检索的做法是把query编码成向量去ANN索引里找最近邻。但“上次买的那双鞋”这个指代关系embedding模型根本理解不了。生成式召回的做法是意图解析模块识别出“上次买的那双鞋”是一个指代需要查询用户历史订单。系统调取用户最近一笔鞋类订单提取商品的多模态特征鞋型、材质、品牌、风格。生成式模型生成召回策略以历史订单商品为锚点在统一语义空间里检索相似鞋型同时叠加“绿色”颜色过滤。多路召回并行执行最终返回结果。这个案例里生成式模型的核心价值在于理解指代关系并生成跨模态检索策略。传统向量检索做不到这一点因为它没有“记忆”和“推理”能力。4.2 另一个案例用户上传一张街拍图搜“找类似风格的外套”这是纯多模态query。传统方案里图片检索和文本检索是分离的用户上传图片后系统只能做以图搜图没法叠加文本约束。生成式召回的做法是多模态统一模型把用户上传的图片和文本query“找类似风格的外套”一起编码生成一个联合语义表示。然后在这个表示空间里做检索同时匹配视觉相似度和文本语义。实测下来这种联合编码的方式比“先以图搜图再文本过滤”的两阶段方案召回率提升了约28%。原因在于联合编码能捕捉到视觉和文本之间的细粒度关联比如“类似风格”可能指的是版型、材质、颜色搭配而不仅仅是整体视觉相似。5. 踩过的坑与实战心得生成式召回不是银弹任何新技术落地都会踩坑生成式召回也不例外。我梳理了几个得物方案里暴露出来的典型问题以及对应的解决思路。5.1 生成式模型的“幻觉”问题策略生成了但商品不存在生成式模型有一个固有缺陷它可能会“幻觉”出一些不存在的商品属性或召回路径。比如用户搜“限量版紫色AJ1”模型可能生成一个召回策略要求匹配“紫色AJ1限量版”但实际上这个商品根本不存在。得物的解法是策略校验层。生成式模型输出的召回策略会先经过一个轻量级的校验模块检查策略里的属性组合是否在商品库里有对应结果。如果没有校验模块会回退到更宽泛的策略或者直接走传统向量检索兜底。这个校验层的存在非常关键。没有它生成式召回会返回大量空结果用户体验反而下降。5.2 多模态对齐的“语义漂移”图片和文本的表示空间不一致多模态统一表示的核心难点在于图片和文本的语义空间天然不一致。图片的视觉特征颜色、纹理、形状和文本的语义特征风格、场景、情感很难完美对齐。得物的方案里用了对比学习对抗训练的方式来缩小模态鸿沟。具体来说训练时会构造大量的图片-文本配对数据让模型学习把匹配的图片和文本拉近不匹配的推远。同时引入对抗训练让模型对模态差异更鲁棒。实操心得多模态对齐的质量高度依赖配对数据的质量和数量。得物在数据构造上投入了大量资源包括人工标注、用户行为挖掘、以及基于规则的自动配对。这部分工作没有捷径数据质量直接决定最终效果。5.3 缓存失效的“雪崩效应”高频query策略突然失效缓存是生成式召回的性能保障但缓存失效是一个潜在风险。如果大量高频query的缓存同时失效系统会瞬间涌入大量实时生成请求导致推理集群过载。得物的解法是分级缓存熔断降级一级缓存Redis存储高频query的召回策略TTL 5分钟。二级缓存本地内存存储超高频query的策略TTL 1分钟。熔断机制当实时生成请求超过阈值时自动降级到传统向量检索保证系统可用性。这个机制在几次大促期间经受住了考验。大促期间query分布变化剧烈缓存失效率飙升但熔断降级保证了搜索服务没有出现大规模不可用。6. 从得物方案看生成式召回的适用边界与演进方向得物的方案不是万能的它有明确的适用边界。理解这些边界比盲目照搬方案更重要。6.1 什么场景适合生成式召回生成式召回最适合以下场景query语义模糊、长尾、多模态传统检索搞不定的query生成式召回能显著提升效果。商品库多模态特征丰富图片、视频、文本描述质量高多模态统一表示才有意义。有足够的算力预算生成式模型的推理成本远高于传统检索没有算力支撑方案落不了地。有实时反馈闭环生成式召回依赖用户行为反馈来调整策略没有反馈闭环效果会大打折扣。反过来如果query以精确型为主、商品库以文本为主、算力预算有限那传统向量检索仍然是更务实的选择。6.2 生成式召回和向量检索的关系不是替代是叠加得物的方案里生成式召回和向量检索是共存关系不是替代关系。简单query走向量检索复杂query走生成式召回两者通过query复杂度评估模块动态分流。这种架构设计的逻辑是用生成式模型处理它擅长的事用传统检索处理它擅长的事。生成式模型擅长意图理解、策略生成、多模态融合传统检索擅长精确匹配、低延迟、高吞吐。两者结合才能兼顾效果和性能。6.3 下一步演进从“生成召回策略”到“生成召回结果”得物目前的方案生成式模型生成的是召回策略实际检索还是靠传统索引。下一步的演进方向是端到端的生成式召回——生成式模型直接生成召回结果跳过索引检索环节。这个方向的技术挑战很大。生成式模型需要“记住”整个商品库的语义表示并且能根据query直接生成最相关的商品列表。目前的模型规模和推理成本还支撑不了这个方案但随着模型压缩技术和推理加速技术的发展未来两三年内有可能实现。我个人判断端到端生成式召回会在垂直领域、商品库规模可控的场景率先落地。得物的商品库虽然大但类目聚焦、特征体系完善其实是端到端方案的理想试验场。7. 给想尝试生成式召回的团队的一些实操建议如果你所在的团队也想尝试生成式召回我基于得物方案的经验给几条实操建议。第一先从query复杂度评估做起。不要一上来就全量上生成式先做一个query分流模块把简单query和复杂query分开。这个模块的投入产出比最高能帮你快速验证生成式召回的价值。第二多模态统一表示是长期投入不要期望短期见效。多模态对齐需要大量的配对数据和训练资源短期内可能看不到明显效果。但一旦跑通它是生成式召回的核心竞争力。第三缓存和熔断机制必须提前设计。生成式模型的推理成本决定了没有缓存和熔断系统根本扛不住生产流量。这两个机制要在方案设计阶段就考虑进去不要等到上线后再补。第四反馈闭环的速度决定效果上限。生成式召回的效果高度依赖用户行为的实时反馈。如果你的系统做不到秒级反馈生成式召回的效果会大打折扣。建议先优化反馈链路再上生成式模型。第五不要忽视传统检索的兜底作用。生成式模型会幻觉、会失效、会过载传统检索是最后的保障。得物的方案里传统检索始终在线随时准备兜底。这个设计思路值得借鉴。最后分享一个我在实操中体会很深的点生成式召回的效果三分靠模型七分靠数据。得物在商品多模态标注、query意图标注、用户行为挖掘上投入的资源远超模型训练本身。如果你打算做生成式召回先把数据基建做好否则再好的模型也跑不出效果。 得物交易搜索生成式召回：从意图理解到多模态融合的工程实践
1. 从“关键词匹配”到“意图生成”交易搜索的召回困境到底卡在哪做电商搜索的人都有一个共同的体感召回环节决定了搜索体验的天花板。排序再精妙、重排再花哨如果召回阶段就没把用户真正想要的商品捞出来后面全是白搭。得物交易搜索面临的场景更特殊——这是一个以潮流商品、限量球鞋、设计师品牌为核心的交易场域用户的搜索行为跟传统货架电商有本质区别。传统电商搜索的召回主力是倒排索引向量检索的双路架构。倒排索引负责精确匹配和类目过滤向量检索负责语义泛化。这套架构在过去五六年里被反复打磨已经非常成熟。但得物的交易搜索场景里我观察到几个很明显的痛点第一长尾query的语义鸿沟。得物上大量用户搜索的是“适合夏天穿的浅色系板鞋”“跟某某联名那款差不多的外套”“上次刷到的那双绿色跑鞋”。这些query没有明确的关键词锚点倒排索引基本抓瞎向量检索虽然能泛化但embedding模型对“潮流语义”的理解往往不够精准——它分不清“复古”和“复刻”在球鞋语境下的微妙差异。第二多模态信息的割裂。得物的商品天然是多模态的主图、细节图、上脚图、视频、尺码表、材质说明、用户评价里的实拍图。传统召回链路里文本走文本的通道图片走图片的通道最后在粗排阶段才做融合。这种“先分后合”的模式导致大量跨模态的关联信号在召回阶段就丢失了。第三用户意图的动态性。潮流消费的意图变化极快。今天流行“美拉德风”明天可能就变成“薄荷曼波”。向量检索依赖的embedding索引更新周期长根本追不上这种变化速度。而生成式召回的核心优势恰恰在于它不依赖预先构建的索引而是实时理解query意图动态生成召回策略。这就是为什么得物交易搜索团队会提出“召回范式跃迁”这个命题。不是向量检索不好而是单一范式已经触到了天花板。生成式召回不是要替代向量检索而是在它之上叠加一层“意图理解与策略生成”的能力让召回从“检索已有索引”变成“生成最优召回路径”。2. 生成式召回到底“生成”了什么拆解得物方案的核心机制很多人第一次听到“生成式召回”会懵召回不就是从海量商品里捞出一小撮吗生成式模型不是用来生成文本、图片的吗它怎么“生成”召回结果这里需要把概念掰开。生成式召回里的“生成”生成的不是商品本身而是召回策略、召回路径、以及query的语义表示。具体来说得物的方案里生成式模型承担了三个核心职责2.1 意图解析与query改写把“人话”翻译成“机器能懂的检索指令”用户输入“有没有那种看起来旧旧的但是很贵的鞋”传统向量检索会把这个query编码成一个稠密向量然后去ANN索引里找最近邻。但“旧旧的但是很贵”这个语义太模糊了embedding模型很难把它精准映射到“复古做旧”“限量联名”“高客单价”这些商品属性上。生成式模型的做法是先理解意图再生成结构化的检索指令。比如它可能输出{ intent: 复古潮流鞋款, attributes: { style: [做旧, 复古, vintage], price_range: high, category: sneaker }, recall_strategy: [倒排索引精确匹配style标签, 向量检索语义泛化, 多模态检索匹配做旧质感图片] }这个结构化指令才是真正驱动召回的依据。生成式模型在这里扮演的是“翻译官策略师”的角色它把自然语言的模糊意图翻译成多条可执行的召回路径。2.2 多模态统一表示让图片和文本在同一个语义空间里对话得物商品的多模态特性决定了召回必须能跨模态。用户搜“像这张图里的外套”上传一张图片系统需要同时理解图片的视觉特征和文本query的语义然后在统一的表示空间里做检索。生成式多模态模型比如基于CLIP架构改进的视觉语言模型在这里的作用是把商品的主图、细节图、文本描述、用户评价里的实拍图全部编码到同一个语义空间。这样当用户上传一张图片时系统可以直接在统一空间里做跨模态检索而不需要先分别检索再融合。实操中有一个关键细节多模态统一表示的质量高度依赖训练数据的质量和多样性。得物的方案里商品图片的标注体系非常细不仅有类目、品牌、颜色这些基础标签还有“鞋型”“材质纹理”“穿搭风格”等潮流专属标签。这些标签的构建成本很高但它们是生成式召回能精准理解潮流语义的基础。2.3 动态召回策略生成根据query复杂度自适应调整召回路径不是所有query都需要走多路召回。简单query比如“Nike Air Force 1 白色 42码”倒排索引直接搞定没必要动用生成式模型。复杂query比如“想要一双适合通勤又能搭配裙子的复古跑鞋”才需要生成式模型介入生成多路召回策略。得物的方案里有一个query复杂度评估模块它会根据query的长度、语义模糊度、历史点击行为等特征决定是否触发生成式召回。这个模块的存在非常关键因为生成式模型的推理成本远高于传统检索如果所有query都走生成式系统吞吐根本扛不住。query类型示例召回策略是否触发生成式精确型“AJ1 芝加哥 42码”倒排索引类目过滤否语义型“适合夏天穿的透气跑鞋”向量检索属性过滤否模糊型“上次刷到的那双绿色鞋”生成式意图解析多路召回是多模态型上传图片“找类似款”多模态统一检索生成式策略是这个分流机制是整套方案能落地的工程前提。没有它生成式召回就是一个实验室玩具根本没法上生产。3. 工程落地中最难啃的三块骨头延迟、索引、冷启动理论讲完了真正动手做的时候你会发现生成式召回的工程复杂度远超预期。我梳理了得物方案里最棘手的三个工程问题以及对应的解决思路。3.1 推理延迟生成式模型怎么塞进召回链路召回环节对延迟极其敏感。传统向量检索的P99延迟通常在10ms以内而一个7B参数的大语言模型单次推理延迟轻松超过100ms。如果直接把生成式模型塞进召回链路整个搜索的响应时间会直接崩掉。得物的解法是异步预生成缓存命中。具体来说对于高频query系统会离线预生成召回策略缓存到Redis里线上直接命中缓存延迟控制在5ms以内。对于中频query系统会做近线预生成提前5-10分钟预测可能出现的query变体生成策略后缓存。对于低频长尾query才走线上实时生成但会做模型蒸馏和量化把推理延迟压到50ms以内。这里有一个经验性的取舍缓存命中率每提升10%整体P99延迟能下降约15ms。所以得物在query归一化和意图聚类上投入了大量精力目的就是提高缓存命中率。3.2 索引更新生成式召回需不需要重建索引传统向量检索依赖ANN索引索引更新是一个重操作。生成式召回理论上不依赖索引但它依赖商品语义表示库——也就是所有商品的统一语义向量。这个库的更新频率直接决定了召回的新鲜度。得物的做法是双缓冲索引增量更新。主索引每天全量重建一次增量索引每15分钟更新一次新上架和修改过的商品。生成式模型在生成召回策略时会同时查询主索引和增量索引确保新商品能及时被召回。这个机制的工程复杂度在于双缓冲索引的一致性维护。如果主索引和增量索引的数据版本不一致可能会出现“策略生成了但商品查不到”的情况。得物的方案里有一个版本协调器它会确保生成式模型看到的商品语义表示和实际检索时用的索引版本是一致的。3.3 冷启动新商品和新用户怎么被生成式召回覆盖冷启动是召回系统的经典难题。新上架的商品没有历史点击数据新用户没有历史行为生成式模型怎么为他们生成有效的召回策略得物的解法是内容特征兜底探索机制新商品上架时系统会强制提取其多模态特征图片、标题、属性、类目生成一个“内容语义指纹”。生成式模型在生成召回策略时会优先考虑内容语义匹配而不是依赖行为数据。新用户的首次搜索系统会走“探索式召回”生成式模型会生成一组多样化的召回策略覆盖不同风格、价格带、类目的商品然后根据用户的实时点击反馈快速调整。这个探索机制的关键在于反馈闭环的速度。得物的方案里用户的每一次点击、加购、收藏都会在秒级内反馈到生成式模型的策略调整中。这种实时反馈能力是传统召回架构不具备的。4. 多模态融合在召回阶段的实际效果数据与案例说了这么多机制最终还是要看效果。得物交易搜索团队在内部做过AB实验对比了传统向量检索和生成式召回的多个核心指标。我整理了一些关键数据数据经过脱敏处理仅反映趋势指标传统向量检索生成式召回变化幅度召回率Recall10062.3%78.6%16.3pp长尾query召回率41.2%67.8%26.6pp多模态query召回率38.5%72.1%33.6pp平均响应延迟P9912ms48ms36ms缓存命中率N/A73.5%N/A从数据可以看出生成式召回在召回率上的提升非常显著尤其是长尾query和多模态query提升幅度超过25个百分点。代价是延迟增加了36ms但通过缓存机制大部分请求的实际延迟增加控制在15ms以内。4.1 一个真实案例用户搜“像上次买的那双鞋但颜色换成绿色”这是一个典型的模糊多模态query。传统向量检索的做法是把query编码成向量去ANN索引里找最近邻。但“上次买的那双鞋”这个指代关系embedding模型根本理解不了。生成式召回的做法是意图解析模块识别出“上次买的那双鞋”是一个指代需要查询用户历史订单。系统调取用户最近一笔鞋类订单提取商品的多模态特征鞋型、材质、品牌、风格。生成式模型生成召回策略以历史订单商品为锚点在统一语义空间里检索相似鞋型同时叠加“绿色”颜色过滤。多路召回并行执行最终返回结果。这个案例里生成式模型的核心价值在于理解指代关系并生成跨模态检索策略。传统向量检索做不到这一点因为它没有“记忆”和“推理”能力。4.2 另一个案例用户上传一张街拍图搜“找类似风格的外套”这是纯多模态query。传统方案里图片检索和文本检索是分离的用户上传图片后系统只能做以图搜图没法叠加文本约束。生成式召回的做法是多模态统一模型把用户上传的图片和文本query“找类似风格的外套”一起编码生成一个联合语义表示。然后在这个表示空间里做检索同时匹配视觉相似度和文本语义。实测下来这种联合编码的方式比“先以图搜图再文本过滤”的两阶段方案召回率提升了约28%。原因在于联合编码能捕捉到视觉和文本之间的细粒度关联比如“类似风格”可能指的是版型、材质、颜色搭配而不仅仅是整体视觉相似。5. 踩过的坑与实战心得生成式召回不是银弹任何新技术落地都会踩坑生成式召回也不例外。我梳理了几个得物方案里暴露出来的典型问题以及对应的解决思路。5.1 生成式模型的“幻觉”问题策略生成了但商品不存在生成式模型有一个固有缺陷它可能会“幻觉”出一些不存在的商品属性或召回路径。比如用户搜“限量版紫色AJ1”模型可能生成一个召回策略要求匹配“紫色AJ1限量版”但实际上这个商品根本不存在。得物的解法是策略校验层。生成式模型输出的召回策略会先经过一个轻量级的校验模块检查策略里的属性组合是否在商品库里有对应结果。如果没有校验模块会回退到更宽泛的策略或者直接走传统向量检索兜底。这个校验层的存在非常关键。没有它生成式召回会返回大量空结果用户体验反而下降。5.2 多模态对齐的“语义漂移”图片和文本的表示空间不一致多模态统一表示的核心难点在于图片和文本的语义空间天然不一致。图片的视觉特征颜色、纹理、形状和文本的语义特征风格、场景、情感很难完美对齐。得物的方案里用了对比学习对抗训练的方式来缩小模态鸿沟。具体来说训练时会构造大量的图片-文本配对数据让模型学习把匹配的图片和文本拉近不匹配的推远。同时引入对抗训练让模型对模态差异更鲁棒。实操心得多模态对齐的质量高度依赖配对数据的质量和数量。得物在数据构造上投入了大量资源包括人工标注、用户行为挖掘、以及基于规则的自动配对。这部分工作没有捷径数据质量直接决定最终效果。5.3 缓存失效的“雪崩效应”高频query策略突然失效缓存是生成式召回的性能保障但缓存失效是一个潜在风险。如果大量高频query的缓存同时失效系统会瞬间涌入大量实时生成请求导致推理集群过载。得物的解法是分级缓存熔断降级一级缓存Redis存储高频query的召回策略TTL 5分钟。二级缓存本地内存存储超高频query的策略TTL 1分钟。熔断机制当实时生成请求超过阈值时自动降级到传统向量检索保证系统可用性。这个机制在几次大促期间经受住了考验。大促期间query分布变化剧烈缓存失效率飙升但熔断降级保证了搜索服务没有出现大规模不可用。6. 从得物方案看生成式召回的适用边界与演进方向得物的方案不是万能的它有明确的适用边界。理解这些边界比盲目照搬方案更重要。6.1 什么场景适合生成式召回生成式召回最适合以下场景query语义模糊、长尾、多模态传统检索搞不定的query生成式召回能显著提升效果。商品库多模态特征丰富图片、视频、文本描述质量高多模态统一表示才有意义。有足够的算力预算生成式模型的推理成本远高于传统检索没有算力支撑方案落不了地。有实时反馈闭环生成式召回依赖用户行为反馈来调整策略没有反馈闭环效果会大打折扣。反过来如果query以精确型为主、商品库以文本为主、算力预算有限那传统向量检索仍然是更务实的选择。6.2 生成式召回和向量检索的关系不是替代是叠加得物的方案里生成式召回和向量检索是共存关系不是替代关系。简单query走向量检索复杂query走生成式召回两者通过query复杂度评估模块动态分流。这种架构设计的逻辑是用生成式模型处理它擅长的事用传统检索处理它擅长的事。生成式模型擅长意图理解、策略生成、多模态融合传统检索擅长精确匹配、低延迟、高吞吐。两者结合才能兼顾效果和性能。6.3 下一步演进从“生成召回策略”到“生成召回结果”得物目前的方案生成式模型生成的是召回策略实际检索还是靠传统索引。下一步的演进方向是端到端的生成式召回——生成式模型直接生成召回结果跳过索引检索环节。这个方向的技术挑战很大。生成式模型需要“记住”整个商品库的语义表示并且能根据query直接生成最相关的商品列表。目前的模型规模和推理成本还支撑不了这个方案但随着模型压缩技术和推理加速技术的发展未来两三年内有可能实现。我个人判断端到端生成式召回会在垂直领域、商品库规模可控的场景率先落地。得物的商品库虽然大但类目聚焦、特征体系完善其实是端到端方案的理想试验场。7. 给想尝试生成式召回的团队的一些实操建议如果你所在的团队也想尝试生成式召回我基于得物方案的经验给几条实操建议。第一先从query复杂度评估做起。不要一上来就全量上生成式先做一个query分流模块把简单query和复杂query分开。这个模块的投入产出比最高能帮你快速验证生成式召回的价值。第二多模态统一表示是长期投入不要期望短期见效。多模态对齐需要大量的配对数据和训练资源短期内可能看不到明显效果。但一旦跑通它是生成式召回的核心竞争力。第三缓存和熔断机制必须提前设计。生成式模型的推理成本决定了没有缓存和熔断系统根本扛不住生产流量。这两个机制要在方案设计阶段就考虑进去不要等到上线后再补。第四反馈闭环的速度决定效果上限。生成式召回的效果高度依赖用户行为的实时反馈。如果你的系统做不到秒级反馈生成式召回的效果会大打折扣。建议先优化反馈链路再上生成式模型。第五不要忽视传统检索的兜底作用。生成式模型会幻觉、会失效、会过载传统检索是最后的保障。得物的方案里传统检索始终在线随时准备兜底。这个设计思路值得借鉴。最后分享一个我在实操中体会很深的点生成式召回的效果三分靠模型七分靠数据。得物在商品多模态标注、query意图标注、用户行为挖掘上投入的资源远超模型训练本身。如果你打算做生成式召回先把数据基建做好否则再好的模型也跑不出效果。