先说个结论在搜索召回这条赛道上向量检索确实还是主流但它已经卷成“红海”了。大家比模型结构、比负样本挖掘、比量化压缩、比ANN索引参数说实话边际收益已经越来越低。而最近我们在交易搜索场景里尝试了一条新路径——把召回从“匹配问题”重新定义成“生成问题”让模型直接产出候选目标而不是在候选池里挑相似项。这套思路落地后效果超出预期也让我确认了一件事别再只卷向量检索了生成式召回才是值得投入的方向。这篇文章我会从问题背景、范式对比、得物交易场景的独特约束、落地实操、避坑实录五个部分展开。面向的是搜索/推荐/NLP方向的技术同学尤其是正在做召回链路、觉得向量召回已经触到天花板的人。看完你大概率会得到一个可以上手的“生成式召回”改造思路以及一套避开血泪坑的评测方法。1. 先聊聊为什么向量检索这么卷却还是不够用1.1 向量检索的黄金时代与隐痛向量检索能在过去几年成为召回标配逻辑很清楚把Query和商品映射到同一个语义空间用余弦相似度或内积去衡量匹配程度然后用FAISS、HNSW这类ANN索引做近邻检索。这套组合解决了传统字面匹配无法处理同义词、语义改写、跨模态的问题比如用户搜“千元机”能召回“2000元以下智能手机”。但这套范式有一个天然的结构性限制召回是“先在候选池里挑再算相似度”。它本身并不创造候选候选池的上限决定了召回的天花板。一旦用户请求超出了候选池中embedding能覆盖的语义范围向量检索就无能为力。举一个我们在得物交易搜索里真实遇到的例子用户搜“冬天约会穿的大衣”。这个Query包含季节性信息“冬天”、场景信息“约会”、品类信息“大衣”。双塔向量模型可能把“冬天”和“大衣”编码进表征里但“约会”这种场景属性在商品侧未必有对应的显式字段或标签——商品标题可能只写“羊毛大衣 黑色 中长款”并不含“约会”这个词。于是即使这个商品客观上很适合约会穿向量召回也会因为表征空间里“场景维度缺失”而漏掉它。换句话说向量检索的问题不是“相似度学得不够好”而是“候选池本身是静态的Query中动态展开的意图无法被完整表达”。我们一直在优化embedding模型、挖掘难负样本、调ANN参数但这些都是在一个给定候选集内的局部寻优。1.2 从“查相似”到“解意图”的诉求变化再往下深挖一层交易搜索和传统搜索有一个本质差异传统搜索求“准确找到某个东西”交易搜索求“找到用户愿意下单的东西”。用户表达的不只是一个“实体”而是一个“意图组合”。以得物的场景为例用户搜索“AJ鞋”时真实意图可能是“想买一双耐克的Air Jordan篮球鞋”“想看看最近哪些AJ配色在潮流圈火”“预算一千以内适合日常穿搭的AJ”三种意图对应三种完全不同的商品集合。向量检索只能把Query和商品编码进向量空间然后用一个点积结果去硬匹配所有可能意图。这在语义空间里天然处于劣势——一个向量点积无法同时表达“实体属性场景预算”的组合需求。所以行业里逐渐发现真正能拉开体验差距的不是把向量搞得更准而是把Query拆解成结构化的、可延展的意图表示再基于意图去“生成”候选集合。这就是生成式召回登场的逻辑基础也是“范式跃迁”这四个字背后的含义。2. 生成式召回的本质不挑候选直接“造”候选2.1 什么是生成式召回所谓生成式召回核心思想是将召回任务从“从集合中检索”转换为“从条件分布中采样”。模型不再是“给Query找一个最相似的向量”而是“根据Query直接生成一个目标集合的表示”——可以是商品ID、可以是描述性文本、也可以是一组商品属性的组合。这个思路最早在学术界有相关探索比如用Transformer模型直接生成文档ID来完成检索把“检索”变成了“序列到序列生成”。到了大模型时代这个范式变得特别可行LLM天然具备对Query进行意图扩写、属性拆解、语义联想的能力。通俗一点说向量检索是“拿着照片在相册里翻”生成式召回是“听完描述直接画一张要找的人像再去核对”。前者受限于相册里已经有什么后者至少理论上不受已有内容限制它先构建一个关于目标的完整描述再映射回具体对象。2.2 范式跃迁而不是技术叠加“跃迁”这个词不是玄学它在工程意义上改变了一个根本假设。向量检索的假设是存在一个编码空间Query和Doc可以映射到其中相似度等于相关性。为了维护这个假设我们需要对齐双塔表征、构造难负样本、做跨域对齐每一步都是在“同一个数学框架内打补丁”。生成式召回的假设是相关性是一种可以在生成过程中被条件化地构造出来的性质。模型先理解Query的深层需求再“生成”一个满足该需求的候选列表对应的表示。这个过程中检索边界是由生成条件动态决定的而不是由预先嵌入的候选向量决定的。在工程上两者也有本质区别维度向量检索生成式召回核心操作计算向量距离近似近邻检索条件生成候选表示上限瓶颈候选embedding覆盖范围生成模型的表达能力Query理解方式一次编码成定长向量逐步解码可拆分可组合候选来源已有索引中的固定项生成得到的动态集合扩展性ANN参数调优、模型蒸馏修改Prompt、训练生成目标所以它不是一个“可以叠加到向量检索之上”的增强模块而是一种需要重新设计召回链路的思路。得物交易搜索之所以选择这个方向不是因为它时髦而是因为交易场景的用户表达天然是“多意图组合”向量检索处理这种组合需求确实显得吃力。2.3 生成式召回不是不要向量这里要特别澄清一个误区生成式召回不是要消灭向量检索起码在现阶段不建议这么做。更务实的做法是将生成式召回作为向量召回之外的“第二路召回”甚至是第三路召回专门去接那些向量检索容易漏掉的“长尾意图”和“组合语义”。因为生成式模型擅长把握全局语义关系但受限于解码速度和成本不适合承担全量召回向量检索擅长在大规模候选集上做快速粗筛但表达组合语义的能力弱。两者的关系更像是“互补双引擎”向量召回到位基础相关性生成式召回负责突破语义边界把单一Query“裂变”成多个可能意图再逐一召回。我自己在工程上常用一个比喻向量召回是“大纲”生成式召回是“脑洞”。大纲保证不跑题脑洞保证有惊喜。交易搜索里“不跑题”带来的稳定性和“有惊喜”带来的转化提升缺一不可。3. 得物交易搜索为什么适合生成式召回3.1 交易场景的“人本查询”占比极高得物交易搜索有一个特点用户搜索词里的品牌词、品类词占比虽然高但场景化、体验化、人本化的查询占到了相当大的比例。什么叫“人本查询”就是用户不是直接说我要什么商品而是说“我想要什么状态”。例如“出门被人夸的香水”“适合送男朋友的礼物”“健身房穿显身材的运动套装”这些Query本身没有一个准确的商品实体对应向量检索基本只能把它们编码成一个模糊的语义向量然后到商品库里去碰运气。而生成式召回可以在理解这句话之后生成一个更明确的商品候选描述“木质调 男香 小众 高级感”“运动紧身衣 速干 显线条 黑色 健身 男”再映射到商品库中。这种“从主观描述到客观属性”的解码过程恰好是LLM的强项。3.2 商品侧的多模态信息没有被充分利用交易搜索中另一个被忽视的困境是商品库里的结构化信息往往很稀疏。标题、品类、属性、价格这些字段是有的但“场合”“风格”“人群感受”这类主观标签在传统数据管道里几乎不可能被完整维护。我们不可能派人工去给每个商品标注“适合约会”“适合送人”“显得腿长”。生成式召回为这个问题提供了一条可自动化的路径用LLM对商品描述进行二次生成为每个商品生成一份“语义扩展文档”。该文档包含从原始标题、属性、评论中提炼出的场景标签、人群标签、风格标签。这份扩展文档既可以语义化地映射成向量也可以作为生成式索引的一部分参与检索甚至可以直接送入倒排索引做关键词匹配。简单说生成式召回把原本“人肉维护”的语义标签环节变成了“模型自动生成”的环节让商品在更多意图下变得“可被找到”。3.3 交易转化目标要求召回链路“懂业务”在得物搜索场景里召回做得好不好不能只看“相关不相关”还要看“能不能转化”。用户搜“AJ鞋”如果召回出来的都是最新款限量AJ但价格破万而用户实际上是想找一双五百块的入门AJ那即使语义相关也不会产生点击和购买。这就意味着召回阶段的候选需要带上一层“用户适配度”的信息。向量检索的相似度是比较难表达“预算匹配”“消费分层”这类信息的。生成式召回可以做得更自然模型可以直接在生成过程中注入用户维度信息——比如把用户的历史价格偏好、品牌偏好写进Prompt让生成的候选一开始就是“适合这个人”的商品集。我们在实践中发现这其实是生成式召回相对向量检索最有业务价值的一点它可以把很多原本需要靠重排阶段解决的“个性化初步过滤”提前到召回阶段直接减少后续环节的压力。4. 实操落地从0到1搭一套生成式召回链路4.1 第零步定义“生成”的输入与输出动手之前先明确一个问题生成式召回要“生成什么”目前主流的生成式召回输出形式有三种按落地难度递增生成查询扩展词/伪文档用LLM将用户Query扩展为多个子查询或自然语言描述再交由向量检索或倒排召回补充候选。生成商品语义标签离线为每个商品生成扩展属性文档在线用Query去匹配这些“增强后的文档”。生成商品ID序列训练生成模型直接输出商品ID列表类似Sequence-to-Sequence召回。前两种更偏向“生成式增强召回”第三种才是真正的“生成式检索”。在得物交易搜索这个场景里我们采用了一种混合方案上线初期用方案1和方案2同时离线训练方案3作为长期演进方向。这么做的好处是我们不需要一上来就推翻原有架构就能很快看到生成式召回带来的增量。先“站在向量检索的肩膀上”把生成模型的能力传导进召回链路这是最稳妥的第一步。4.2 核心模块一Query意图拆解与扩展在线链路上我们最先落地的是“Query理解模块”。具体做法是将用户Query拼接历史行为特征和品类上下文送入LLM/轻量生成模型输出三样东西意图标签集合如“篮球鞋”“限量”“日常穿搭”“送礼”属性约束集合如“价格低于800”“黑色”“中帮”扩展查询集合如“AJ低帮运动鞋”“耐克篮球鞋 时尚”“千元内 潮鞋 男”这套Prompt我们沉淀了很久一个基础版本长这样你是电商搜索查询理解专家。给定用户搜索词、用户最近点击的商品标题列表分析用户的真实购买意图。 输出JSON格式包含 - intents: 用户可能的意图标签可多个 - attributes: 用户对商品属性的显式或隐式约束 - expansions: 3个适合向量检索和关键词检索的扩展查询词 只输出JSON不输出其他内容。 用户搜索词: {query} 用户最近点击: {click_titles}关键不在Prompt写得多花哨而在于如何利用生成结果构造召回信号。我们做了三件事将intents和attributes映射为结构化过滤条件直接灌入召回后端缩小候选集范围将expansions交给向量召回做多路查询大幅扩展语义覆盖将生成的意图序列与商品侧的语义标签做交叉匹配形成一个额外的“生成式相关性打分”。这样做下来覆盖的召回Query类型从“实体型”扩展到了“意图型”而且几乎没有增加太多线上延迟——因为LLM推理本身走异步不阻塞主链路。4.3 核心模块二商品侧“语义文档生成”在线Query理解之外离线商品语义文档生成是更花时间、也更出效果的一环。我们的做法是对每个商品SKU把标题、卖点、详情页OCR文本、用户评价片段、价格、品类属性拼接起来输入LLM生成“商品语义扩展文档”包括核心场景如“健身房”“日常通勤”“情侣礼物”目标人群如“学生党”“潮流爱好者”“职场新人”风格标签如“街头风”“简约”“复古”可组合的属性表述如“适合秋冬叠穿”“轻便不压脚”这步耗时但很值得能解决一个搜索链路里最麻烦的“底层数据结构”问题不是所有商品都有场景标签但生成式模型可以给它们补上。技术上我强烈建议把生成的语义文档与原始内容混合后重新构建一个“语义倒排索引”或“语义向量索引”。我们实测下来这比只更新商品embedding效果好很多因为“语义文档”这种高密度的文本描述能让向量模型学到更丰富的语义边界而不是只靠一个短标题去猜商品。4.4 核心模块三生成结果与候选集的映射与融合生成式召回在线上的执行流大概是这样的接收用户Query同步传给Query理解模块拿到LLM生成的意图标签、属性约束、扩展查询将这些结果并行交给多个召回源向量召回查询扩展词、倒排召回属性约束、生成式召回意图标签匹配语义文档各路结果进入融合层按照LR/GBDT排序模型与原有重排链路对接。这一步最大的坑是**“生成的扩展词过于发散”**导致召回出来一堆看似相关其实不相关的商品。控制方法是给扩展查询设置“相似度下界”或者对意图标签做置信度截断只有LLM自身置信度高、且与用户实时行为相关性强的意图才进入扩展召回。否则宁可少召回也不能召回一堆噪音数据给下游重排增加负担还拉低体验。融合排序阶段我们用了轻量级GBDT模型输入特征包括各路召回结果的原始得分生成式标签与用户Query意图的匹配度商品侧场景标签与用户人群的匹配度商品价格与用户历史消费水平的差距商品近7天转化率、点击率等行为特征这个融合模型更重要的是“纠偏”作用防止生成式召回“太有想法”而带偏基础相关性。4.5 评测别只盯着召回率从热搜词里看到“召回率91.3%”我要提醒一句召回率只是离线指标它高的本质可能是“候选集变大”带来的福利不代表线上转化就好。我们在项目初期就吃过这个亏生成式召回加入后Recall100涨了十多个点但线上CVR几乎没有提升。后来复盘发现问题出在评测口径上——我们只评估了“语义相关”的召回没评估“交易意图匹配”的召回。用户想买“五百元内AJ”结果召回了“三千元限量AJ”语义“相关”交易意图完全不匹配。所以我们在离线评测里引入了一组“交易转化导向的召回指标”比如IntentRecallK召回结果中至少有一个满足用户核心交易意图的比例PrecisionK for Conversion召回结果中进入过转化漏斗点击/加购/下单的商品占比PriceMismatchRate召回商品价格与用户历史成交价格区间不匹配的比例。这些指标比单纯看Recall更有业务意义也更适合用来指导生成式召回的效果调优。如果你正在做类似的召回改造建议从第一天就把这些指标纳入看板别等上线之后被业务方质疑。5. 避坑指南生成式召回最容易踩的五个坑5.1 生成幻觉模型“编造”了不存在的商品LLM生成查询扩展时可能造出“根本不存在的商品”或“想买但商品库里没有的属性组合”。例如用户说“一百块的AJ鞋”LLM扩展成“Air Jordan 1 限定款 PU皮质 百元”但商品库中根本没有满足该组合的商品。我们采用的解法是双重校验生成式的候选描述先生成一个“描述向量”拿到向量索引里去做近似检索如果没有达到相似度阈值的候选就弃用该路结果而不是把低置信度结果硬塞给用户。另一条路是给LLM提供商品库的候选属性集合让它“只能从集合中选择属性组合”从而约束生成的边界。5.2 延迟控制生成式不能拖垮在线链路LLM推理的延迟比向量计算高一个到两个数量级。线上方案目前采用“分级调度”大部分流量走轻量级小模型几亿参数蒸馏模型只对复杂Query和高价值流量调用大模型所有生成式结果一律异步回流不阻塞主检索路径。实测下来p99延迟从原来的80ms增加到110ms还在可接受范围。如果你没做异步化直接把大模型推理塞进主路径延迟很可能会直接翻倍得不偿失。5.3 离线指标涨、线上效果不动这是做生成式召回最打击人的坑。我们的经历是离线Recall都涨到90%以上了线上点击率却原地踏步。原因还是一个老问题——召回只是漏斗的开始重排和精排可能已经弥补了召回差异或者召回集合里多了很多“边缘相关”的商品反而稀释了核心商品的曝光。对策有两个与重排团队约定生成式召回结果主要在“重排尾部”补充用于测试增量价值使用分桶实验只把生成式召回结果发给部分流量观察与基础链路并存的增量转化。这个阶段拼的不是模型能力而是工程耐心和团队协同。5.4 数据飞轮没转起来生成式召回有一个隐藏前提它依赖较多“意图-商品”关系数据来做监督训练或评估。如果商品侧没有足够的评价、点击反馈、收藏数据生成式模型就很难学习“哪些意图对应哪些商品”。我们的实践是先在点击率、加购率高的商品子集上做生成式召回积累高质量的训练样本再逐步扩展到全量商品。这个过程需要至少两个完整的回流周期才能看到明显的效果提升别指望一上线就有完美表现。5.5 生成式召回与多模态的延伸方向最后说一个我们已经开始验证的方向多模态生成式召回。交易搜索里很多商品的信息价值不在于文字而在于图片。鞋子的版型、大衣的质感、配饰的细节文字描述经常无法完整表达但图片可以。我们的思路是在商品侧调用视觉模型生成图像描述和原有的文字语义文档融合再参与生成式召回。实测对“风格感”强、视觉信息主导的品类潮鞋、外套、配饰提升尤其明显。这个方向成本更高但天花板也更高适合有一定基建后去尝试。说白了生成式召回不是某个模型的事而是一套“如何用生成能力重构检索流程”的思路。你在决定卷向量之前值得先看看这条路——尤其当你负责的交易搜索场景里用户表达越来越像“人话”的时候生成式召回可能会成为你打破天花板的那把钥匙。