生成式召回：交易搜索新范式，从多路匹配到约束生成

1. 当交易搜索遇到复杂query多路召回为什么越卷越累做了几年交易搜索我对“召回”这个词的感情很复杂。传统做法走到今天基本就是两条路并行倒排索引负责字面匹配向量检索负责语义相似然后再叠加上swing、热度、品类关系之类的一堆策略路最后搞一个融合层把各路结果按分数并在一起。这套多路召回架构本身没有错经典且有效但它有一个本质问题——召回的入口是“匹配”而交易搜索里大量query根本不是靠匹配就能解决的。举个例子用户搜“送男友的机械键盘预算800左右”。倒排能把“机械键盘”找出来但“送男友”和“预算800左右”这两个约束基本被丢弃了。向量检索能泛化一点把“送男友”映射成某种语义向量但向量空间里“送男友”和“预算800”是两种完全不同的语义维度拼在一个向量里互相稀释最后召回来的结果依然是“机械键盘池子里排名靠前的那批”而不是“满足这组约束的那批”。我见过很多团队在这种query上反复调权重、调阈值效果始终不稳定。更麻烦的是长尾query。交易搜索里真正难啃的不是高频词而是那些用户随口一说的口语化描述。“适合新家的除甲醛绿植”“婚礼伴手礼要能定制的”“油皮夏天用的清爽防晒”这类query没有固定类目、没有标准词倒排基本空召回向量检索召回来的是散装结果行为数据又稀疏个性化模型也帮不上忙。整个召回链路看起来在“卷”各个路的效果实际上是在卷一个上限很低的框架。还有一个被很多人忽视的问题——多路召回的字面路和语义路之间处理目标不一致。倒排在优化精确命中向量在优化语义相似融合层却默认各路分数可以线性加权。但“字面命中”和“语义相似”根本不是同一把尺子强行融合的结果就是各路打平头部流量被几个高热商品霸占长尾资源反而更沉底。那怎么办行业里这两年出现了一个新思路叫生成式召回。它把整个召回框架推倒了一层——不是继续加路而是换一种方式去理解“召回”这件事。我一开始听完是有点怀疑的但认真拆解之后发现它确实在解决多路召回的根因问题。先说结论生成式召回不是一个gimmick它重新定义了“匹配”和“约束”的关系。传统召回是从索引里找候选生成式召回是在理解query的同时直接把满足约束的候选“算”出来。这个差别听着抽象实际落地之后你会发现它把很多原本要堆策略才能解决的问题简化成了模型训练问题。得物交易搜索在这个方向上做了一个非常有意思的尝试项目的核心不是用生成式去替代向量检索而是用它完成一次召回范式跃迁。咱们接下来就围绕这个项目把原理、设计和落地经验拆开讲透。1.1 交易场景的query到底特殊在哪先厘清一个前提交易搜索和通用网页搜索的query分布差异很大。通用搜索里“苹果”可能是水果、可能是手机、可能是唱片公司歧义多但意图相对单一交易搜索里一个词往往自带多重约束用户不是在问“这是什么”而是在说“我要什么”。“送男友”“预算800”“机械键盘”这三个信息在一条query里本质上是三个约束维度对象约束、价格约束、品类约束。传统召回的做法是拆词把能命中的词拆出来走倒排剩下的词进向量。问题在于拆词本身就是一种损失——把“送男友”和“预算800”当成语义向量的一部分等于把这两个强约束信息稀释成了一个模糊的向量方向。交易搜索这个场景还有一层特殊之处类目体系的存在。用户不关心你后端怎么组织商品类目他说“适合新家”的时候他心里想的是“绿植、空气净化、装饰品”这些场景而不是某个类目ID。生成式召回天然适合处理这种“自然语言描述 → 结构化约束”的映射因为模型可以学习到词和约束之间的隐含关系。1.2 “多路融合”模式的天花板在哪里多路召回的核心问题是每路召回都有盲区融合层再强也补不了盲区。倒排的盲区是语义漂移向量检索的盲区是约束稀释swing这类行为路则完全依赖行为数据新商品和冷门品类直接躺平。有人会说“那多上几路不就完了”可路子越多融合越难。业内做多路融合最常见的做法是LTR但LTR的前提是各路召回结果的分布相对稳定一旦新增一路特征分布会变模型要重新训练而且线上效果波动很大。整个过程像在叠乐高叠到一定高度就开始摇晃。我自己测过一条“需要代写新年贺词的礼盒”的query传统多路召回来来回回就是那几个品牌礼盒所有路都在竞争热度池子里的同一批商品。用户要的不是“礼盒”这个类目而是“能代写贺词”这个属性但没有任何一路的索引能感知到这个属性。这才是多路召回真正的天花板——它不是努力不够的问题是信息维度不够的问题。2. 生成式召回的本质从“索引里找”到“理解后生成”我第一次看到生成式召回这个名词的时候脑子里冒出来的是那个经典笑话“让语言模型做加法它把答案算出来了不算检索”。后来我认真跟进了几篇相关工作发现这个方向其实非常严肃用一个序列到序列模型把query映射成一组商品ID直接从模型输出里得到候选结果整个过程绕开了传统索引。DSIDifferentiable Search Index那类工作是最早给我启发的。它把整个文档集合直接压进Transformer的参数里输入query模型直接吐docid。这个想法在当时很多人觉得疯癫但实际做下来确实能work。应用到交易搜索场景逻辑其实顺理成章把“商品ID序列”作为生成目标让模型学会在给定query和约束条件的情况下直接生成对应的商品ID集合。但完全照搬DSI到交易搜索是行不通的。交易搜索的候选是亿级别的商品池模型参数里塞不下那么多商品而且新商品每天都在上架模型不可能实时记住每个新入库的商品。这就逼着我们把“生成式”和“检索式”结合起来不能把宝全部押在模型的记忆能力上。得物这个项目的聪明之处也在这里——它把生成式和向量检索设计成了上下游关系而不是替代关系。2.1 一次生成完成“理解→约束→候选构造”的全过程生成式召回的实际工作流程可以拆成三步。第一步是query结构化理解。模型把用户输入的query解析成一组显式的约束项比如“品类键盘”“价格≤800”“目标礼品”。这一步本质上是在做语义解析但它不是硬规则解析而是模型从海量行为数据里学出来的隐含解析能力所以口语化、省略式的query也能被正确拆解。第二步是目标函数下的候选构造。模型在约束项下生成候选商品ID序列。这里有个关键设计不是让模型直接生成商品ID而是生成“符合约束的商品特征组合”再通过一个轻量索引把特征组合转化为具体商品ID。这一步兼顾了生成模型的灵活性和索引的实时性。第三步是校验和回灌。生成的候选集合不是直接就上了还要经过一轮过滤校验确认商品在售、库存充足、类目合规然后作为召回结果进入后续排序流程。这个过程快吗实测下来单次生成可以控制在几十毫秒级别跟向量检索的耗时量级是接近的。原因很简单模型解析query并生成候选的过程本质上是几次前向计算而传统多路召回是“多路并行查索引融合计算”后者在工程上并不便宜。2.2 为什么“生成”比“匹配”更适合处理约束型query传统召回框架里有一个隐含假设query和商品之间存在某种可度量的相似度。但交易场景里query和商品之间不是相似关系是满足关系。“送男友的机械键盘预算800左右”和某款键盘之间相似度可能不高但满足度很高。相似度是连续的、模糊的满足度则是带明确边界的。生成式召回把匹配问题转化成了条件生成问题给定约束条件生成满足条件的候选。这一步转化在数学上是质的改变。匹配问题是度量学习生成问题是条件概率建模。条件概率建模天然支持多约束组合模型可以学到“价格约束品类约束场景约束”之间的交互关系而不是像向量检索那样把不同约束维度生硬地拼在同一个向量里。这也是为什么我在前面说多路召回是在卷一个上限很低的框架。生成式的核心优势不是“比倒排更准”而是“能表达比匹配更丰富的语义关系”这是维度上的差异不是精度上的差异。3. 生成式与向量检索不是替代关系而是上下游分工很多团队看到“生成式召回”这个名词第一反应是要不要再引进一个更大的模型来替代向量检索。我在测试过程中最大的体会是这两者根本不是竞争关系而是上下游关系甚至可以共存在同一条链路里。得物这个项目里向量检索不是被抛弃了而是被重新定位了。生成式模型负责“理解复杂query并生成约束候选”向量检索负责“在语义空间里做泛化兜底”防止生成式模型因为训练数据覆盖不全而漏召。两者之间有明显的分工边界生成式解决的是“约束满足型”query向量检索解决的是“语义相似型”query。3.1 向量检索在生成式链路中的新角色兜底与补全生成式召回模型有个先天短板它对长尾覆盖的能力上限取决于训练数据。如果某些商品长期没有行为数据模型学习不到它和query之间的关联生成结果里就永远不会有这个商品。这时候向量检索就是最可靠的兜底——它不依赖商品的行为数据只依赖商品的文本和图像表征能保证那些冷启动商品至少还有一条进入候选的通道。我在实际调试中经常遇到一个情况生成式召回的结果整体质量很高但覆盖面偏窄头部品牌集中度高。这时候把向量检索的结果按一定比例融进去覆盖率和指标都会明显回升。说白了生成式负责“准”向量检索负责“全”。这两者还存在一层有趣的互补关系向量检索擅长处理“没见过的表述”生成式擅长处理“没见过的组合”。用户把“送男友”“预算800”“机械键盘”这三个概念组合在一起向量检索可能见不到这种组合形式但生成式模型能根据训练数据里学到的知识进行组合推理。3.2 从多路并列到分层递进融合策略的简化传统多路召回的融合层为什么难调因为各路的结果是并列关系分数域不一致设计一个合理加权本身就是玄学。生成式主导的链路则把这套融合逻辑简化了生成式主轴提供约束满足的候选向量检索提供语义泛化的候选然后合并、去重、过滤进入排序层。这个设计最直接的好处是特征分布变干净了。排序模型不用再学习“每路结果该给多少权重”只需要聚焦在“如何从混合候选里挑出最合适的”排序模型的特征空间一下子简化了很多。我观察到一个有意思的现象引入生成式作为主轴之后排序模型面临的候选质量层次普遍提高了。也就是说排序模型不再是“矮子里拔将军”而是“优中选优”。这种情况下排序模型自身的特征表达能发挥更大的作用整体的排序质量也跟着上去了。4. 工程落地的关键细节与踩坑记录原理聊得再多落地才是真正见真章的地方。生成式召回从demo到线上中间有非常多坑我把踩过的几个关键问题按工程顺序从头梳理一遍。4.1 候选生成的目标函数选择生成式召回首要问题是训练目标怎么定。我试过两种主流方案一种是直接生成商品ID序列另一种是先生成结构化属性再映射到商品。两种都跑过一轮之后我更倾向于后者。直接生成商品ID的问题在于模型对商品ID的感知能力非常不稳定。商品ID是离散的、无意义的符号模型学ID之间关系的难度远大于学属性之间关系而且一旦商品池更新ID分布变化模型性能会有明显波动。属性序列生成则天然更稳定商品属性是语义化的属性的组合空间远小于商品ID空间而且属性级别的负样本构造起来也更可控。但属性生成方案也有一个隐患属性覆盖不全时生成结果会有“属性正确但商品不对”的情况。比如生成了“机械键盘、背光、茶轴”这三个属性但符合这三个属性的商品里没有真正适合送礼的款式。这个问题需要在后处理环节加一轮商品级的筛选不能完全信任生成结果。4.2 训练数据的构造与负样本策略生成式模型的训练数据构造是个大工程。正样本可以来自历史点击、下单和收藏行为但负样本的构造要特别小心。我用的方案是“混采对抗式污染”从全量商品池里随机采样一批作为基础负样本再专门加入一批“高相似但不对应”的商品。这个“高相似但不对应”的负样本特别关键。比如query是“送男友的机械键盘”模型如果生成了办公键盘虽然品类不完全匹配但特征相似容易混过去。只有加入这类难负样本模型才能真正学会区分“相关”和“满足”的微妙差异。另外一个容易被忽视的坑训练数据的时效性。交易搜索的query分布天然跟季节、热点、商品生命周期绑定。大促期间“送女友礼物”的query占比会骤升如果训练数据里没有这类样本模型在高峰期表现就会崩。所以生成式模型的训练数据不能做一次性快照得定期增量更新。4.3 延迟、重复与时效性工程侧的三座大山第一个痛点是延迟。生成式模型做一次beam search解码如果候选序列长度大耗时会上来。我实测把beam size从4降到2延迟能降40%左右品质损失却很小。交易搜索场景里召回阶段的整体预算一般不能超过几十毫秒留太多时间给解码是不现实的所以beam search的参数务必备得保守一些。第二个痛点是重复。生成式模型在beam search解码时经常beam之间产出非常相似的结果导致合并后候选多样性不足。这个问题我拿“MMR多样化”策略在外面套了一层才解决核心思路是在候选合并时把高相似的结果降权强制保留差异化的候选。第三个痛点是时效性。商品的下架、库存变动没办法实时影响生成模型所以生成结果名单里经常出现过期商品。这块我的经验是不要试图让模型感知实时状态而是后处理环节跟商品中心对接一套实时校验在校验通过之后才进入排序。另外一个值得分享的工程经验是召回候选池的设计。生成式模型输出的是“商品ID序列”但线上要对结果做实时过滤和扩展。我们在生成结果和排序层之间加了一层轻量索引扩展——把生成的属性序列转成倒排query从实时索引里取一批最新商品再去重融合。这样就能在不重训模型的前提下保证新上架的商品有进入候选的通道。4.4 离线评估指标怎么定才不会自欺欺人召回阶段离线评估最常见的是RecallK但这里有一个隐藏陷阱交易搜索里的“相关商品”定义本身不清晰。你用点击定义正样本那位置靠前的商品天然容易有点击指标虚高你用人肉标注定义正样本那成本高到无法持续。我最后用的组合方案是“点击召回率下单召回率人工抽评”三块并行。点击召回率反映模型对当下用户行为的拟合度下单召回率反映对高价值行为的拟合度人工抽评则用来兜住那些模型自己会骗自己的情况。三者加权才是一个相对可信的评估口径。单纯看任意一个指标都容易在AB实验阶段翻车。人工抽评的设计也有讲究。我建议不做“相关/不相关”的二分类标注而是做“满足用户完整约束/部分满足/不满足”的三级标注。这样能更早识别出模型生成的候选是否“只见树木不见森林”——也就是说单看每个商品跟query的某个面相关但用户的多重约束并没有同时被满足。5. 我的个人体会这个方向适合什么团队建议怎么起步放在最后聊几句实在话。生成式召回是一个有意思的方向但不是所有团队都适合立刻上。如果你的业务query分布里长尾复杂query占比很低主流搜索词都是品牌词、类目词那传统多路召回可能根本还没摸到天花板先优化现有链路性价比更高。如果确实想尝试我的建议是从一个小流量boundary条件切入不要一开始就全量重构召回框架。可以先选一个约束项明确的场景比如礼赠场景单独搭一条生成式召回通道做AB实验。这样既能验证模型能力又不会因为链路改动太大导致线上事故。技术上还有几个值得继续深挖的点。LangChain4j这类框架在Java生态里做LLM集成很方便如果团队技术栈偏Java可以考虑用它来做生成式召回链路的编排基础减少重复造轮子的成本。另外结合Swing这类行为召回策略把生成式结果里的商品再拿到行为关系图上去扩展能进一步提升召回结果的联动覆盖。我个人的一个判断是生成式召回和向量检索之争在短期内不会是谁替代谁而是会走向协同。向量检索用低成本解决语义泛化问题生成式召回用更强的约束理解能力解决复杂意图问题两者的结合点才是交易搜索召回未来的稳态。踩过这一轮坑之后我自己的倾向也已经很明确了——多路召回还是要做但主轴会逐渐迁移到生成式这边。