1. 从“卷向量”到“生成式召回”的范式切换1.1 为什么传统向量检索在交易搜索里越来越吃力做电商搜索的人都有一个共同感受向量检索这几年被卷到了极致。从双塔模型到多负样本训练从ANN索引调参到量化压缩能榨的油水基本榨干了。但真正落到交易搜索场景——尤其是像得物这种以商品为核心、用户意图极其碎片化的平台——纯向量召回的天花板其实很早就摸到了。问题出在哪儿向量检索的本质是“相似度匹配”。它把query和doc分别编码成一个稠密向量然后在向量空间里算距离。这套逻辑在通用语义匹配上没问题但交易搜索的query往往带着强烈的“结构化意图”和“隐性约束”。比如用户搜“夏天穿的透气跑鞋男款42码预算500以内”这里面至少包含品类、季节属性、功能属性、性别、尺码、价格区间六个维度的约束。向量模型能把这些信息压缩进一个几百维的向量里吗能但一定会丢信息。更麻烦的是交易搜索对“精确匹配”的要求远高于通用搜索——尺码错了就是错了价格超了就是超了向量空间里的“相近”在交易场景下可能意味着完全不可接受的推荐结果。还有一个被很多人忽略的点向量检索是“静态”的。索引建好之后商品下架、价格调整、库存变化这些实时信号很难直接反映到召回阶段。你只能靠后端的排序层去补救但召回阶段漏掉的东西排序层再强也变不出来。这就导致一个尴尬局面离线指标看着不错线上成交转化却总是差一口气。1.2 生成式召回到底“生成”了什么“生成式召回”这个词听起来很玄但拆开看其实很朴素。它的核心思路是不再把召回当成一个“匹配问题”而是当成一个“生成问题”。具体来说就是让模型直接根据用户query生成一组可能被点击或购买的商品ID或商品属性组合而不是从预先建好的向量索引里“捞”出Top-K。这两者的区别有多大打个比方。向量检索像是一个巨大的图书馆你拿着一张模糊的描述去找书管理员按相似度给你搬来一堆“看起来差不多”的书。而生成式召回更像是一个熟悉库存的导购你说完需求他直接告诉你“三楼左转第三排那本蓝色封面的”甚至能根据你的语气判断你是想随便看看还是急着买。得物交易搜索团队的做法从公开的技术分享来看核心是把大语言模型LLM的生成能力引入召回阶段。具体路径大概是这样先把商品的多模态信息标题、属性、图片、价格、销量等编码成一种“语义ID”或者“结构化token序列”然后训练一个生成模型输入是用户query输出是这些语义ID的概率分布。推理时通过beam search或者约束解码直接生成一批候选商品。这里的关键在于“语义ID”的设计。它不是简单的商品ID而是一种融合了多模态信息的紧凑表示。比如一个商品可以被表示为“运动鞋_跑步_透气_男_42_500-800”这样的token序列每个token对应一个属性维度。生成模型要学的就是在给定query的情况下预测出最可能的token组合。这样一来召回阶段天然就带上了结构化约束——尺码不对的token组合根本不会被生成出来。1.3 得物为什么敢第一个吃螃蟹得物的交易搜索有几个特殊性决定了它比通用电商更适合走生成式召回这条路。第一商品池相对聚焦。得物以潮流单品、球鞋、服饰为主品类虽然也在扩张但核心品类的商品属性体系非常成熟。这意味着语义ID的维度是可控的不会像全品类平台那样面临“属性爆炸”的问题。一个球鞋的语义ID可能就几十个维度生成模型的输出空间是收敛的。第二用户意图的“潮流属性”强。得物用户搜“AJ1 芝加哥”他要的不只是一双鞋而是一种潮流符号。这种意图很难用传统的向量相似度去刻画但生成模型可以通过学习海量行为序列捕捉到“芝加哥”背后关联的配色、联名、年份、甚至穿搭场景。换句话说生成式召回有机会把“潮流语义”直接编码进召回阶段而不是留给排序层去猜。第三多模态数据积累厚。得物的商品图片质量高、角度规范用户晒单图也丰富。这为多模态语义ID的构建提供了天然优势。CLIP这类多模态模型可以把图片和文本映射到同一空间生成模型就能同时利用视觉和文本信号来做召回决策。2. 生成式召回的核心技术拆解2.1 语义ID的构建从商品到token序列整个生成式召回的地基是语义ID的构建。这一步做不好后面全是空中楼阁。得物的方案大概率是分层级的。第一层是品类token比如“运动鞋”“外套”“背包”第二层是属性token比如“跑步”“透气”“男款”第三层是细粒度token比如“42码”“黑色”“2024春季”。每一层都是一个独立的词表生成模型按层级逐步解码。这里有个关键决策语义ID是离散的还是连续的离散的好处是可解释、易约束坏处是信息损失大。连续的好处是保留更多细节坏处是解码时不好做约束。从工程落地的角度看得物很可能采用了“离散为主、连续为辅”的混合方案——核心属性用离散token图片embedding用连续向量两者拼接后送入生成模型。构建语义ID的过程本质上是一个多模态对齐问题。你需要把商品的标题文本、属性表格、图片特征、价格区间映射到同一套token体系里。这里CLIP或者类似的视觉语言模型会派上用场。具体做法是先用CLIP提取图片embedding然后用一个投影层把它映射到文本token的空间最后通过量化或者聚类把连续向量离散化成token。注意语义ID的粒度需要反复调优。太粗了召回精度不够太细了生成模型的输出空间爆炸训练和推理都吃不消。得物这种体量的平台语义ID的总词表大小大概率控制在几万到几十万之间具体取决于品类覆盖度。2.2 生成模型的选择为什么是LLM而不是传统Seq2Seq理论上任何Seq2Seq模型都能做生成式召回。但得物选择LLM路线背后有很实际的考量。传统Seq2Seq模型比如LSTM或者小Transformer参数量有限对长尾query和复杂意图的建模能力不足。交易搜索里大量query是“短且模糊”的比如“那个联名款”“上次看的那双”。这种query需要模型有很强的世界知识和上下文推理能力而这正是LLM的强项。更重要的是LLM的预训练过程已经吸收了海量文本知识对“潮流”“联名”“限量”这些概念有天然的理解。你不需要从零教模型什么是“AJ”它已经在预训练阶段见过无数次了。这意味着在交易搜索场景下LLM的冷启动成本远低于传统模型。但直接用LLM做召回也有坑。最大的问题是推理延迟。一个70亿参数的模型单次生成几十个token在GPU上跑也要几十毫秒。交易搜索的QPS动辄上万这个延迟是扛不住的。得物的解法大概率是“蒸馏量化缓存”三件套先用大模型蒸馏出一个小模型比如1B到3B参数然后做INT8量化最后对高频query做结果缓存。这样能把推理延迟压到可接受的范围。2.3 多路召回融合生成式不是替代是补充得物的技术分享里有一个很重要的观点生成式召回不是要干掉向量检索而是和向量检索、倒排索引形成互补。实际线上系统里召回层通常是多路并行的。倒排索引负责精确匹配比如品牌名、型号向量检索负责语义泛化比如“透气跑鞋”匹配到“网面运动鞋”生成式召回负责意图理解和结构化约束比如“500以内42码男款跑鞋”直接生成符合条件的商品组合。三路结果合并后再送入粗排和精排。这种多路融合的架构好处是鲁棒性强。生成式召回如果出了问题比如模型输出异常倒排和向量还能兜底。坏处是融合策略复杂需要仔细调权。得物的做法可能是用一个轻量级的融合模型根据query类型动态调整各路召回的权重。比如query里包含明确品牌词时倒排权重调高query是自然语言长句时生成式权重调高。召回方式优势劣势适用场景倒排索引精确、低延迟无法处理语义泛化品牌词、型号词向量检索语义泛化强结构化约束弱模糊描述、风格搜索生成式召回意图理解深、结构化约束强推理延迟高、训练成本大复杂长query、多约束条件2.4 训练数据的构造行为序列比标注数据更值钱生成式召回的训练核心是“query到商品”的映射数据。得物手里最值钱的资产就是海量用户行为序列。具体构造方式大概是把用户的一次搜索会话拿出来query作为输入最终点击或购买的商品作为正样本曝光未点击的作为负样本。但这里有个细节交易搜索的“正样本”定义很关键。点击了不一定买买了不一定满意。得物的做法可能是分层采样——购买行为权重最高加购次之点击再次之曝光未点击作为负样本但权重调低。还有一个容易被忽略的点query的改写和扩展。用户搜“夏天穿的鞋”模型需要学会生成“透气运动鞋”“凉鞋”“帆布鞋”等多个品类的token组合。这要求训练数据里包含足够的query改写对。得物可能用了LLM来做query扩展把短query改写成多个语义等价的变体然后分别构造训练样本。实操心得训练生成式召回模型时负样本的构造比正样本更重要。如果负样本太容易区分模型学不到细粒度约束。得物的经验可能是用“同品类不同属性”的商品作为难负样本比如用户搜“42码跑鞋”把“43码跑鞋”作为负样本强迫模型学会尺码约束。3. 工程落地中的关键环节与实操细节3.1 推理加速怎么把LLM塞进召回链路召回层对延迟极其敏感通常要求单次请求在10毫秒以内完成。LLM的原始推理速度远远达不到这个要求。得物在这块做了大量工程优化值得借鉴。第一层优化是模型蒸馏。用一个大模型比如13B作为teacher蒸馏出一个1B左右的小模型作为student。蒸馏的目标不是简单的输出分布匹配而是让student学会teacher的“排序能力”——即给定query哪些商品token应该排在前面。这需要设计专门的蒸馏损失函数比如listwise ranking loss。第二层优化是量化。INT8量化能把模型体积压缩到原来的四分之一推理速度提升2到3倍。但量化会带来精度损失得物的做法可能是对不同的层采用不同的量化策略——注意力层用INT8FFN层用INT4关键投影层保持FP16。第三层优化是缓存。交易搜索的query分布是长尾的但头部query的重复率极高。得物可能对Top 10%的高频query做了生成结果缓存命中缓存时直接返回不走模型推理。缓存的有效期需要仔细设计——太短了命中率低太长了商品下架后还在召回。第四层优化是异步预生成。对于可预测的query比如大促期间的热门搜索词可以提前离线生成候选集线上直接查表。这需要一套query预测机制根据历史流量和实时趋势判断哪些query需要预生成。3.2 约束解码怎么保证生成结果“合法”生成式召回最大的风险是“生成出不存在或不可买的商品”。比如模型生成了一个“42码的童鞋”token组合但库存里根本没有这个SKU。这就需要约束解码。得物的做法可能是在解码阶段加入“合法性掩码”。具体来说维护一个实时更新的商品属性组合集合解码时只允许生成集合中存在的token组合。这需要在解码每一步都做一次集合查询对性能有影响但可以通过布隆过滤器或者前缀树来加速。另一个约束是“业务规则”。比如某些品类不支持货到付款某些商品不支持七天无理由。这些规则需要在解码阶段就过滤掉而不是等到排序层再处理。得物可能把这些规则编码成了token之间的转移约束——某些token后面只能接特定token。注意约束解码会降低生成多样性。如果约束太严模型可能只会生成“安全”但平庸的结果。得物的经验可能是在召回阶段放宽约束在粗排阶段再收紧。这样既能保证召回覆盖率又能控制最终展示质量。3.3 多模态信号的融入图片不只是辅助得物的商品图片质量高这是天然优势。生成式召回如果只利用文本信号就浪费了这部分资产。多模态融入的方式大概有两种。第一种是“早期融合”在语义ID构建阶段就把图片embedding量化成token和文本token拼在一起。这样生成模型在解码时会同时考虑文本和视觉信号。第二种是“晚期融合”文本生成模型和图片匹配模型分别召回然后在融合层合并结果。得物可能采用了早期融合为主、晚期融合为辅的方案。早期融合的好处是模型能学到“图片风格”和“文本描述”之间的细粒度关联。比如用户搜“复古风球鞋”模型能生成那些图片色调偏暖、鞋型偏老式的商品token而不是仅仅依赖标题里的“复古”二字。具体实现上CLIP模型负责提取图片embedding然后通过一个VQ-VAE或者残差量化器把连续embedding离散化成多个token。这些视觉token和文本token共享同一个解码器但有不同的词表前缀方便模型区分。3.4 线上A/B实验怎么衡量生成式召回的真实价值离线指标再好看线上不涨就是白搭。得物做生成式召回的A/B实验核心看几个指标。第一是召回覆盖率。生成式召回能覆盖多少query特别是长尾query和复杂query的覆盖率。如果覆盖率太低说明模型泛化能力不够。第二是召回准确率。生成的商品里有多少是用户真正感兴趣的这需要看后续的点击率和转化率。但要注意召回层的准确率不能孤立看要和排序层联合评估。有时候召回层放进来一些“看起来不相关”的商品排序层反而能挖掘出潜在需求。第三是延迟和成本。生成式召回的推理成本远高于向量检索。得物需要算一笔账每提升1%的转化率需要增加多少GPU成本这个ROI是否划算第四是多样性。生成式召回容易陷入“安全区”反复生成头部商品。得物可能用“品类熵”或者“品牌熵”来衡量召回结果的多样性确保长尾商品也有曝光机会。指标定义目标召回覆盖率有生成结果的query占比95%召回准确率生成商品中被点击的比例相对向量检索提升10%以上推理延迟单次生成耗时20ms含缓存品类熵召回结果的品类分布熵不低于向量检索基线4. 踩过的坑与实战避坑指南4.1 语义ID设计太细导致模型“学不动”早期做生成式召回时最容易犯的错误是把语义ID设计得太细。比如把“颜色”拆成“红色”“深红色”“酒红色”“樱桃红”十几个token。结果就是每个token的训练样本都不够模型学出来的分布非常稀疏生成时经常出现“四不像”的组合。得物的经验可能是语义ID的粒度要和数据量匹配。如果一个属性维度的取值超过50个就要考虑做聚类或者分桶。比如颜色可以聚成“红系”“蓝系”“黑系”“白系”几个大类每个大类下面再用连续embedding表示细粒度差异。这样既保留了信息又控制了词表大小。另一个坑是“属性耦合”。有些属性是强相关的比如“品类跑鞋”和“功能透气”经常一起出现。如果把它们当成独立token模型可能会生成“跑鞋防水”这种不合理组合。解法是在语义ID构建阶段就做属性依赖分析把强相关属性合并成一个复合token。4.2 生成结果“幻觉”严重召回一堆不可买商品LLM的幻觉问题在生成式召回里会被放大。模型可能会生成一个“看起来合理”但实际不存在的商品组合。比如“AJ1 芝加哥 42码 白色”但实际库存里只有黑色。得物的解法是“实时校验反馈闭环”。生成结果在返回前必须经过一个轻量级的校验层检查商品是否存在、是否有库存、是否可配送。校验不通过的token组合会被丢弃并记录到“幻觉日志”里。这些日志会定期回流到训练数据中作为负样本让模型学会避免生成不存在的组合。还有一个技巧是“温度调低”。生成时的温度参数控制随机性温度太高容易幻觉温度太低又缺乏多样性。得物可能对不同的query类型设置了不同的温度——精确query用低温0.3左右模糊query用高温0.8左右。4.3 多路召回融合时“互相打架”生成式召回和向量召回的结果经常重叠但排序不一致。比如向量召回把“某款跑鞋”排在第一生成式召回把它排在第五。融合时如果简单加权可能会导致最终结果不稳定。得物的做法可能是“分层融合”。先按召回来源分组每组内部先排序然后再做组间融合。组间融合的权重不是固定的而是根据query特征动态调整。比如query里包含“类似”“差不多”这种词时向量召回权重调高query里包含具体尺码、价格时生成式召回权重调高。另一个坑是“召回结果去重”。不同召回路径可能召回同一个商品如果不去重排序层会看到重复项浪费计算资源。得物可能用了基于商品ID的哈希去重同时保留每个商品的“召回来源”标签供排序层参考。4.4 线上延迟抖动长尾query拖垮整体性能生成式召回的延迟和query长度强相关。短query生成快长query生成慢。如果不对长query做特殊处理线上会出现延迟抖动影响用户体验。得物的解法可能是“query分级”。根据query的长度和复杂度把query分成三档短query5个词走快速生成路径中等query走标准路径长query走“先改写再生成”路径。改写是把长query压缩成几个关键token降低生成难度。还有一个工程技巧是“超时降级”。如果生成式召回在指定时间内没返回结果直接降级到向量召回保证整体链路不超时。降级策略需要仔细设计——不能频繁降级否则生成式召回永远拿不到足够的线上流量来迭代。实操心得生成式召回的线上部署建议先从低流量场景切入比如只对10%的query开启生成式召回观察延迟和效果。等模型稳定后再逐步扩量。得物大概率也是这么做的一上来就全量风险太大。4.5 模型更新频率与商品上下架的冲突交易搜索的商品池是实时变化的。今天在售的商品明天可能就下架了。但生成式召回模型是离线训练的更新频率通常是天级或周级。这就导致模型可能生成已经下架的商品token。得物的解法是“模型规则”双保险。模型负责生成候选token组合规则层负责实时过滤。规则层维护一个“在售商品属性组合”的倒排索引生成结果必须命中这个索引才能返回。索引的更新是实时的商品下架后立即从索引中移除。另一个问题是“新品冷启动”。新上架的商品没有历史行为数据生成式召回模型没见过自然不会生成。得物可能对新品做了“强制曝光”策略——在生成结果中预留一定比例的槽位给新品确保新品有机会进入召回池。5. 生成式召回的未来延展与个人思考5.1 从“召回”到“生成式搜索”的完整链路生成式召回只是第一步。得物的技术演进方向很可能是把生成能力贯穿到整个搜索链路——召回阶段生成候选商品排序阶段生成排序理由展示阶段生成个性化文案。想象一下这个场景用户搜“约会穿的鞋”系统不仅召回几双合适的鞋还能生成一句“这双白色板鞋搭配牛仔裤很清爽适合轻松约会场合”。这种“生成式搜索”体验是传统向量检索完全做不到的。但这条路还很长。生成式排序需要模型理解“为什么这个商品排第一”这比生成商品ID难得多。生成式展示需要模型有很强的文案能力同时不能违反广告法。得物如果在这块有布局大概率也是从辅助功能开始比如生成“相似商品推荐理由”而不是直接生成主文案。5.2 算力约束下的取舍不是所有query都值得生成生成式召回很贵。得物这种体量的平台如果对所有query都走生成式召回GPU成本会是个天文数字。所以必然要做取舍。我的判断是得物会对query做“价值分级”。高价值query比如高转化品类、高客单价品类优先走生成式召回低价值query比如长尾品类、低客单价品类继续走向量检索。这个分级不是静态的而是根据实时流量和转化数据动态调整。另一个取舍是“生成深度”。对于简单query生成一层token就够了对于复杂query可能需要生成多层token。得物可能用了“自适应生成”策略——根据query复杂度动态决定生成层数简单query少生成复杂query多生成。5.3 多模态统一处理的下一步视频和直播信号得物除了图文商品还有大量视频和直播内容。这些内容的多模态信号更丰富但也更难处理。生成式召回如果能把视频帧、直播语音、弹幕文本都纳入语义ID体系召回能力会再上一个台阶。技术上这需要更强大的多模态编码器。CLIP只能处理静态图片视频需要时序建模直播需要流式处理。得物可能还在探索阶段但方向是明确的——把“商品”从一个静态的图文实体扩展成一个包含视频、直播、用户互动的动态内容集合。5.4 个人实操建议中小团队怎么低成本试水如果你不在得物这种体量的平台但想试试生成式召回我的建议是从“小场景”切入。选一个品类聚焦、商品属性规范的场景比如“手机壳”或者“T恤”。先用LLM把商品标题和属性转成结构化token序列构建一个几百维的语义ID体系。然后拿用户行为数据训练一个小的生成模型1B参数以内用LoRA做微调。推理时用vLLM或者TensorRT-LLM做加速配合缓存和降级策略。不要一上来就追求全品类覆盖也不要追求超越向量检索的效果。先跑通链路验证生成式召回在你的场景下能不能带来增量。如果能带来5%以上的转化提升再考虑扩量。如果连5%都不到可能你的场景根本不适合生成式召回——不是所有交易搜索都需要“范式跃迁”。最后分享一个我踩过的坑生成式召回的离线评估指标和线上效果经常不一致。离线看召回率很高线上转化却没涨。后来发现是离线评估用的负样本太简单模型在线上遇到了大量“难负样本”就露馅了。所以做生成式召回一定要尽早做线上A/B不要沉迷于离线指标。