引言当“卷向量”不再是最优解交易搜索的下一站在哪里做搜索召回的同学这两年多少都有点“向量焦虑”。周围人张口闭口就是embedding、Faiss、HNSW好像不把向量检索玩出花来就不配谈“召回先进性”。但天天跟交易搜索打交道的人心里都清楚向量化只是把文本/图片映射到高维空间的一种表示手段它解决的是“语义相似”问题但解决不了“意图理解”和“结果生成”的问题。搜索的终点从来不是“召回归档”而是“用户找到并且愿意买”。尤其在高转化诉求极强的交易场景里用户输入“黑色连衣裙显瘦”这种多意图混杂query你光靠召回一堆向量近邻哪怕相关性再高用户还是得自己做二次筛选体验和成交效率都上不去。我最近在看得物交易搜索的做法时发现他们提出了一个很值得聊的思路——别再只卷向量检索了用“生成式”直接实现召回范式跃迁。说白了就是把搜索从“匹配”逻辑推到“生成”逻辑让系统不只是从百万商品库里挑出最像的而是直接“生成”一个满足用户需求的结果集。这篇我就想把它拆开聊透为什么交易搜索不适合纯向量范式生成式召回到底在解决什么结构性问题落地的时候要避哪些坑以及这套思路对做搜索、做推荐、做AI应用的人有哪些可迁移的启发。这篇内容适合正在做搜索召回、做电商/交易类推荐系统、或者研究大模型应用落地的工程师和架构师。特别是那种已经卷完向量检索、但发现线上指标瓶颈愈发明显的团队值得花十几分钟把这套范式转变的底层逻辑理一遍。1. 交易搜索的召回困局为什么“向量检索”不是终点1.1 向量检索解决的是“语义相关”而不是“交易意图”向量检索确实带来了很大进步。早年间靠BM25、TF-IDF做关键词匹配最大的问题是“词汇鸿沟”用户说“耐克Air Force 1”商品标题写“空军一号”字面不匹配召回直接挂掉。引入embedding之后文本被映射到语义空间至少能通过向量距离捕捉“同义改写”、“口语化表达”和“语境相似”这个能力在开放域搜索里非常管用。但交易搜索有个特殊点用户不只是要“相关”而是要“能买、想买、愿意下单”。同样是“运动鞋”有人要通勤缓震有人要实战篮球有人要配色好看有人预算只有300块。向量空间里的相似度本质上反映的是“语义分布接近”它不建模“用户此刻要什么类型的结果组合”更不建模“怎样的排序混合策略能促进成交”。我举个实际例子用户搜“夏季跑步短袖男”如果我们只做向量召回系统很可能召回到大量“材质凉感”、“速干排汗”的相近商品。这没什么问题但如果用户其实是刚跑完半马、想买一件“适合夜跑反光条设计”的上衣呢向量模型如果没有“反光条”这个属性的强监督信号它很难在语义空间里把这个需求精准压出来。这就是纯向量范式的第一个死角——相关不等于意图匹配。1.2 向量召回的结果是“集合”用户仍要自己消化信息再往深一层说。向量召回本质上做的是“TopK检索”系统给用户的是一个无序或粗排之后的有序列表。用户需要自己翻、自己比、自己决定买哪个。这在标品、低价、决策成本低的品类里问题不大但遇到高客单、强个性化、决策链路长的商品比如潮鞋、配饰、美妆礼盒纯列表式召回就是在偷懒。用户真正需要的很多时候不是“一页商品”而是“一个答案”比如“最近通勤适合穿哪双复古跑鞋”、“毕业照穿什么风格的衣服显气质”、“送男朋友千元预算有什么推荐”——这些问题里包含了多重约束场景约束、预算约束、风格约束、甚至社交约束。把这种query打平成向量去“检索”信息损耗不是一般的大。我自己的体会是交易搜索做到后期瓶颈往往不在召回率上而在“信息整合能力”上单点召回再准不会聚合用户照样觉得搜得“散”。这也是为什么大家开始尝试“搜索直达结果页”、“聚合卡片”、“攻略型内容”这些新形态——本质都是在补“整合”这一课。1.3 “范式跃迁”的本质从“match”走向“generate”所以得物交易搜索提的“生成式召回”不是突然冒出来的新词而是把检索任务重新定义了一遍不再把召回看作“从候选库里选”而是把它看作“从用户意图出发构造一个结果集合”。这个“构造”的过程就带上了生成式模型的底子模型不是对比商品的向量距离而是学习“当用户表达某种意图时怎样的商品组合、怎样的属性分布、怎样的价格带结构是最可能带来正向反馈的”。它输出的不是单个商品的排序而是一个“结果方案的生成”。这里我多说一句。很多同学一看到“生成式”第一反应是大模型LLM。但在这个场景里“生成”的含义可以更宽——它指的是“目标函数从相关性到用户满足度的跃迁”。你可以用LLM来做也可以用传统序列模型、甚至规则模型混合来做。关键是思路转变搜索系统从一个“检索器”变成一个“答案生成器”。这一下子就打开了操作空间不仅能召回商品还能召回理由、召回搭配、召回攻略、召回品牌故事然后统一编排成一个“可行动的答案”。这才是交易搜索卷完向量之后真正该卷的方向。2. 生成式召回的架构思路与核心设计2.1 整体框架意图解析、条件生成、结果校验三层想落地生成式召回第一件事不是选模型而是搭框架。我梳理了一套相对通用的三层架构适合大多数交易搜索场景复用第一层意图解析层。用LLM或轻量模型把用户query拆成结构化约束。比如“夏季跑步短袖男”可以拆成性别男季节夏季场景跑步品类短袖上衣隐含需求透气/速干。这一步的核心是“从自然语言里榨出可计算的约束条件”而不是直接做向量化。第二层条件生成层。基于解析出的约束模型“生成”一个候选结果方案。这里生成的动作可以有很多种形态可以是生成一个检索式相当于自动构造多个查询去召回可以是直接生成一组商品ID序列也可以是先生成一个“商品描述模板”再拿模板去匹配商品库。这个层是“范式跃迁”发生的地方——它不再依赖单一的向量近邻而是组合多个约束来“推演出结果”。第三层结果校验与融合层。生成的东西不一定靠谱所以要校验生成的商品是否存在是否有库存是否满足价格带约束再和传统向量召回的结果做融合最后交给排序层。这一步非常关键它保证“生成式”不是“放飞式”。这三层看起来简单但每一层都有不少需要较真的细节。我逐个拆开讲。2.2 意图解析不是简单套一个“分类器”如果你觉得意图解析就是给query打个标签比如“品类男装”、“场景运动”那大概率做出来效果不行。交易场景的query往往是复合意图表达还高度口语化单纯分类会丢失大量信息。我们实际落地时更推荐的方案是“槽位填充兜底自由文本”双通道槽位填充通道对常见结构化属性品类、性别、价格带、风格、材质做抽取转成可检索的过滤条件。自由文本通道对槽位抽取不干净的部分保留完整语义文本用于后面做语义匹配或者生成细粒度描述。举个例子用户搜“复古越野跑鞋小众品牌”槽位抽取能拿到“品类跑鞋”、“风格复古”但“小众品牌”这种偏好就很难落成具体槽位。这时候就需要把“小众品牌”作为一个软约束传到生成层去影响结果——比如在生成检索式的时候加入“非大众热销品牌”的过滤逻辑或者调整品牌分布权重。这里面有个非常容易踩的坑不要把意图解析做成一个巨大的多分类任务。交易搜索的意图空间太稀疏、太长尾了你枚举不完。更务实的做法是“解析出能落地的那部分剩下的交给语义兜底”把“理解不透”的部分留给后面的校验融合层去修正。2.3 条件生成从检索式生成到商品序列生成条件生成层是整个范式跃迁的技术核心。我见过几种落地路径各有取舍第一种生成检索式Query Generation。模型根据意图约束生成多个检索式比如“夏季跑步短袖男”生成“男 速干 短袖 T恤”、“跑步 训练 上衣 夏季”、“透气 运动T恤 男款”。然后拿这些生成的检索式分别做召回再合并结果。这个方案的好处是改动小能复用已有的检索基建缺点是生成检索式不一定会比用户原query更好容易“绕了一圈回到原点”。第二种生成商品描述/属性分布再匹配商品库Profile Generation。这个思路更接近“生成式”的本意模型不是直接生成商品ID而是先生成一个“理想商品的画像”——维度包括品牌偏好、价格中位数、设计风格、材质倾向、功能卖点。画像生成好后用画像向量或者画像约束去商品库里圈选商品。这个方案的好处是生成结果可解释性强而且能比较好地处理长尾query缺点是对画像维度的设计能力要求很高。第三种直接生成商品序列Item Generation。利用序列模型或者大模型直接从商品库中“推理”出最合适的一串商品ID。这个最激进也最像“生成式”但落地风险也最大商品库有百万级规模直接生成很容易产生幻觉生成一些不存在的商品或者明显不符合约束的结果校验成本很高。我的建议是初版落地优先考虑“检索式生成 画像生成”的混合方案先用检索式生成保证基本盘覆盖再用画像生成处理长尾意图。直接生成商品序列可以作为后期迭代方向对校验层的要求会非常高。2.4 为什么要留着传统向量召回做“底座”这里特别想强调一下生成式召回不是来取代向量召回的而是来“叠buff”的。一定要把它当作新增的一路召回而不是唯一的召回。原因很好理解。生成式模型再强它也有“幻觉”问题。特别是面对高热度的突发话题商品比如某明星同款突然火了生成式模型的知识是滞后的它不知道这个商品现在应该被召回。但向量召回基于实时索引只要有新款上架、有新的用户行为反馈它就能迅速反应过来。所以“生成式”管长尾意图和复杂约束向量召回管热点和新品两条腿走路才稳。融合策略上我们团队的经验是“保底不抢量”生成式召回的结果先过一层规则校验是否包含禁售品、库存是否充足再和向量召回结果做比例混排。初期建议生成式召回的占比控制在10%到20%等线上指标验证OK了再逐步放量。一口吃不成胖子召回层的调整尤其要稳。3. 实操过程与关键环节实现3.1 基础数据准备与样本构造任何召回模型的训练都离不开样本生成式召回对样本的要求比普通向量模型更高。首先我们需要“用户行为反馈样本”用户点了什么、买了什么、在搜索结果页停留了多久、最终成交了什么。这些数据是训练“用户满足度”信号的基础。其次是“意图-商品配对样本”一条query对应哪些商品是“好结果”。这个不能只看点击因为点击有偏置——排在前面的容易被点。建议用“成交加购收藏”这类强正反馈再结合“点击后长时间停留”做辅助判断。还有一个容易被忽视的样本来源客服对话记录。用户咨询“有没有适合跑步穿的黑色短袖不要太紧身的”客服的回答往往包含了精准的约束拆解和商品推荐。这一类“会话级”数据对于训练意图解析和画像生成非常有价值。样本量方面我的经验是意图解析层至少需要几十万量级的query标注数据而画像生成层需要百万量级的“user-item”交互对才能训练出稳定的生成质量。如果冷启动来不及积累这么多数据可以先用规则生成一批伪样本再用线上真实反馈逐步迭代。3.2 意图解析模块的离线训练与线上调用意图解析模块我们用的是“轻量LLM 小模型兜底”的组合。线上不可能每个query都调大模型延迟受不了。所以实际落地时是这么做的离线环节用大模型对历史query做批处理产出高质量的槽位标注然后把这些标注作为训练数据蒸馏到一个轻量分类/序列标注模型上。在线环节query进来先走轻量模型如果置信度低再决定是否升级到大模型兜底。这里分享一个调优细节槽位解析的“阈值”不要一刀切。比如“品类”字段的置信度要求可以放到0.7“材质”这种长尾属性放到0.5就行——因为材质识别错了后面还有校验层能兜住但品类错了影响面就大了。不同槽位的风险等级不一样阈值设计要有差异化思维。3.3 生成式召回模型的离线训练与推理服务再来说生成模型这部分。如果我们选“检索式生成 画像生成”的混合路径那模型结构上可以这样做检索式生成可以建模成Seq2Seq任务输入是query和意图槽位输出是多个检索式。训练的时候用历史的高转化query及其对应的“有效检索式”做监督。所谓有效检索式可以反推那条query最终成交的商品是通过哪个检索词/哪个类目路径成交的这个路径就可以当作标签。画像生成则可以建模成“属性预测”任务输入是query和意图槽位输出是一组商品属性分布价格带、风格权重、功能关键词权重。训练目标是让预测出的画像分布能够覆盖该query下高转化商品的属性分布。注意这里用的是“分布”而不是“具体值”目的是为了生成结果的多样性——用户搜“运动鞋”你不能只给他推单一品类得覆盖跑鞋、篮球鞋、板鞋等潜在子类。推理部署这块有个现实约束如果整个链路都串行调用大模型延迟很难压到100ms以内。我们用的解法是“分层缓存 异步化”意图解析和画像生成的结果按键值缓存同一个query或相似query直接命中缓存真正需要实时生成的只有那些长尾新query。这能省掉大部分在线开销。另外要特别提一下“生成结果的去重与多样性控制”。生成式模型天生容易坍缩到少数几种高分模式结果就是召回来的商品长得都差不多。我们的做法是在解码阶段引入“MMR最大边际相关性”做多样性惩罚如果一条新召回商品和前几条已选商品在向量空间里太近就适当降权。这个细节对交易搜索尤其重要——用户不喜欢一页全是同款不同色的商品。3.4 结果校验层把“幻觉”挡在门外生成结果的校验我强烈建议做成独立的一层服务而不是散落在各环节里。校验服务统一提供以下几个能力库存校验生成结果的商品必须当前可售、有库存。合规校验过滤违禁品、侵权品、风险商品。约束校验检查结果商品是否满足意图解析出的硬约束比如性别、价格带上限。真实性校验确认商品ID真实存在于索引中防止模型“编造”不存在的商品。校验层看起来枯燥但它决定了生成式召回能不能上线。我见过团队在模型阶段投入了大量精力结果因为校验没做好上线第一天生成了一堆“好看但不存在”的商品卡用户点进去全是404体验直接崩盘。生成式召回落地校验比生成更重要。这句话我写在这等你们踩过坑之后会回来点赞的。3.5 实验设计与效果评估办法生成式召回上线前实验设计要特别的细致。常规的“召回率点击率”两个指标不够建议额外关注这四类指标意图覆盖率生成式召回结果覆盖了多少种不同意图。可以按query聚类后看每个意图簇是否有结果命中。约束满足率人工抽样生成结果看价格带、性别、品类约束的满足比例。多样性指标计算召回归一化熵或者类目覆盖数防止结果过度集中。业务转化指标最终还是要看加购率、成交转化率这些硬指标因为召回方式变了用户满足度最终会体现在转化上。实验建议用分层实验先小流量比如5%观测生成召回占比和基础体验指标确认无负面后再逐步扩大到20%、50%。每一步都要监控延迟、超时率、无结果率这三个底线指标。生成式召回如果拖慢了整体检索速度那是捡了芝麻丢西瓜。4. 落地过程中的坑与排查心法4.1 Query改写后“离题”了怎么办我们在做检索式生成的时候遇到过最典型的坑生成出来的检索式比原query还抽象。比如用户搜“复古跑鞋”模型生成了“旧款 运动鞋 经典”结果召回了大量老头鞋跟用户想要的复古潮流跑鞋完全不是一个东西。排查思路很直接给生成的检索式打分时加入“与原query语义相似度”这个约束。生成式检索不是自由创作它必须跟原query保持语义在同一个主题域内。实操上可以在生成模型的loss里加一项“生成结果与query的余弦相似度”作为正则偏离太远就降低奖励能有效压制这个问题。4.2 新品类冷启动阶段生成式召回“无米下锅”用户搜了一个刚刚入驻平台的新品类意图解析做得很完美画像也生成得很漂亮但商品库里就是没几个对应商品。这种情况不是模型问题是供给问题。应对办法有两个方向一是“放宽约束”当校验层发现某个硬约束下候选商品数量太少时自动降级为软约束放宽价格带或风格范围二是“转向相关类目”做个简单的类目迁移映射比如新品类“露营灯”没货可以召回“氛围灯”、“户外灯”等相邻类目保证用户体验不落空。4.3 延迟上涨明显如何给生成链路“瘦身”生成式链路天然比传统向量召回多几步意图解析、检索式生成、画像生成、校验融合每一步都有可能变成性能瓶颈。我们实战中做过的几个有效的瘦身动作把意图解析和检索式生成合并成一个模型减少一次网络调用。因为两者的输入都是query输出结构虽然有差异但可以设计成多任务共享。对画像生成做精度换速度线上推理时画像里的连续值如价格带分布可以做离散化处理从浮点数预测改成分类预测模型轻量很多。把校验层做成异步化高置信度的生成结果先返回给用户低置信度的标记待校验后台校验通过后再补发。这个策略可以显著降低首包延迟。4.4 你以为的“生成式”其实还是“检索式”最后一类坑是认知层面的。有些团队宣称上了生成式召回结果实际做的是“用LLM给query做了个向量化”。这个严格来说不叫生成式召回还是向量检索。真正的范式跃迁必须是输出结果发生了结构性变化从“一个列表”变成“一个方案”从“匹配商品”到“按约束构造结果集”。判断标准很简单你把生成式召回关掉看召回结果是否显著变差。如果只是从向量A换成向量B那说明还是在同一范式里打转并没有实现跃迁。真正跃迁的标志是——用户搜“通勤一周穿搭”你返回的不再是七件相似白衬衫而是一套周一至周五搭配方案的集合。这就是生成式召回的护城河也是它跟传统向量检索之间最本质的区别。5. 几个值得持续深挖的延展方向5.1 生成式排序协同召回只是上半场召回变了排序不可能还守着原来的套路。当前生成式召回的输出天然带有“方案性”。下一步值得尝试的是生成式排序不只为每个商品打个分而是综合考虑整页商品组合的互补性与替代性生成一个“最优结果页”。这跟召回阶段的生成范式是一脉相承的。5.2 生成式召回在多模态场景的延伸得物这类平台商品数据天然是多模态的——图文、短视频、用户评测内容都是很好的信号源。现在我们的画像生成主要基于文本属性后续完全可以扩展成多模态画像用商品主图embedding来代替一部分文本属性描述让画像生成更贴近“视觉决策”的真实购物逻辑。5.3 用户长期兴趣建模与生成式召回的联动目前聊的生成式召回更多是基于当前query做即时推导。如果能把用户历史行为序列也输进去让生成结果带有明显的个性化颜色那交易搜索的“答案感”会更强——“最近关注篮球鞋、预算1000到1500、偏好白色系”的用户搜“篮球鞋”得到的结果方案跟另一个首购用户一定不同。这层联动做好了才是真正的搜索体验代差。一些个人体会做搜索这些年我最大的感受是技术范式的升级往往不是“旧技术不行了”而是“旧技术能解决的上限到了”。向量检索把语义召回的墙推倒了一大半这功劳得认。但交易搜索要的不止是“语义命中”还要“意图满足”和“消费决策提效”这就不是单纯的相似度搜索能覆盖的了。得物交易搜索这次把“生成式召回”摆上台面与其说他们找到了标准答案不如说是给行业提了个醒召回的目标函数该从“相关性”切换到“用户满足度”了。用生成式模型去构造结果方案本质上是在用模型的理解力代替用户自己做信息整合。这条路方向是成立的但落地难度也不小尤其考验团队在数据、校验、实验设计上的基本功。如果你正在做搜索或者推荐不妨试一把不要急着换更大的向量模型先盘一盘你的搜索链路里有多少环节可以用“生成”替代“匹配”。哪怕只是把意图解析做得更结构化一点或者给检索式生成加上一个语义正则线上的体验变化可能会超出你的预期。搜索这条路值得卷的方向还多着呢。