“别急着卷向量检索了”——这话我跟团队说了不下十遍。得物的交易搜索场景太特殊用户搜索的句子往往带着即时的心情和模糊的意图向量检索虽然把语义相似度玩出了花但面对“给男朋友挑个生日礼物”这种组合式需求依旧只能哑火。在这篇文章里我想跟你聊聊我们如何把搜索召回从“匹配”转向“生成”用生成式AI实现一次真·范式跃迁以及这个过程中我们踩过什么样的坑。无论你是电商搜索的算法工程师还是对生成式AI落地感兴趣的技术人这篇内容应该都能给你一些不一样的思路。1. 为什么向量检索不够用了——交易搜索的四大硬伤1.1 向量检索的本质把一切变成坐标系里的距离先花30秒回顾一下向量检索到底在做什么。它的核心逻辑是把用户query和商品都映射到一个高维向量空间里用余弦相似度或内积去度量query和商品的“语义距离”然后在海量向量库里做近似最近邻搜索。简单来说就像给每个词、每个商品发一张“性格测试”的坐标卡坐标越接近说明越匹配。这个思路在通用搜索里很有效因为通用搜索用户输入相对完整、诉求相对明确词的分布也比较稳定。可交易搜索完全是另一套生态用户的query往往短促、口语化而且随时蹦出新词新梗。我见过有人搜“能配得上我新鞋的卫衣”也见过有人搜“适合送女生的潮玩”这些句子不是不好而是它们包含了多条件约束和隐含逻辑光靠“语义相似”根本拆解不出来。前100字含关键词的要求可以在开头或这里多提。这是设计的一部分。1.2 交易搜索的特殊性用户要的不是“像”而是“对”拿“给男朋友买生日礼物”来说用户的核心意图不是找一条包含“男朋友”和“生日礼物”字样的商品标题而是要找一个男士适用的、有礼物属性和品牌调性的、价格又合理的商品。这需要模型做意图拆解和属性重组而不是简单的文本相似。向量检索在这一步就开始露短了——它擅长的是“找相似”而不是“做翻译”。更重要的是交易搜索对结果的检验是“是否成交”。这比内容搜索的“是否满意”苛刻得多。一个召回结果哪怕语义上再贴切只要商品不可售、用户不喜欢、价格不对味就会被迅速抛弃。用户会用点击率和订单量给算法“打分”这让召回环节的压力无限放大。1.3 向量检索的四大天花板跟团队复盘时我们把向量检索在得物搜索上的问题总结成了四个“天花板”每一个都值得展开组合意图处理不了用户搜“白色 低帮 复古板鞋”向量检索很难把三个独立属性糅合成一个最优向量它往往偏向某个主属性丢掉另外两个。否定意图听不见用户搜“不要黑色的联名款”向量检索根本无法理解“不要”这个词的否定语义结果照样推来一堆黑色商品。长尾新词冷启动差得物做得是潮流尖货新词、圈内黑话迭代飞快向量模型的embedding里根本没有它们的稳定表达冷启动只能靠运气。动态供给匹配弱每天都有新商品入库商品向量倒排索引的更新有延迟而生成式方法可以直接从商品属性出发构造候选理论上更新速度更快。这四座大山压下来我们才开始认真思考另一个方向也就是下文要讲的生成式召回。2. 生成式召回从“匹配”到“生成”的范式跃迁2.1 什么才是真正的生成式召回先划清边界。真正的生成式召回不是用大模型“生成一个更好的query”再丢进向量检索引擎——那是锦上添花谈不上范式改变。我理解的生成式召回是把召回任务本身建模成一个生成任务输入用户query及其上下文历史点击、加购、下单行为输出一组可以直接作为召回候选的商品ID序列或者一组商品属性组合如“品牌Nike类目卫衣颜色白色价格500-800”再通过倒排索引映射回具体商品。这里最关键的认知转变是我们不再假设目标商品藏在某个数据库里等着被捞出来而是让模型自己在“商品空间”中重构出最有可能满足用户需求的候选点。这种思路在结构上就把“候选生成”和“候选打分”之间的边界打破了。传统检索范式是先有候选集再打分召回质量高度依赖索引质量和覆盖率生成式召回直接把“生成候选”这一步交给模型它输出的候选本身就是条件概率最高的商品路径。这个差异用一句话来概括从“找相似”变成“无中生有”从“筛选”变成“创造”。2.2 为什么“生成query再检索”是伪跃迁不少团队看了我在内部写的方案后问我们也可以让LLM把用户query改写得更清晰再交给向量检索这不也是生成式吗我的答案是这是工程优化不是范式跃迁。首先query改写只解决了“输入清晰度”的问题向量检索固有的组合表达、否定意图、长尾词冷启动等硬伤依然健在。用户搜“给男朋友买生日礼物”你改写得再通顺向量检索还是无法天然地把“礼物属性”“潮玩倾向”“预算约束”拆成独立的检索条件。其次多了一次生成过程就多了一次误差放大的机会。改写出的query一旦语义偏差后面的所有环节都跟着带偏而且这种偏差极难归因。真正的生成式召回应该一步到位生成候选把误差压在同一个模型的可控范围里。2.3 生成式召回如何带来增量价值说得直白一点我们看中的是这四点增量组合意图直接满足生成式模型能够以自回归的方式逐步解码属性序列天然能消化“白色低帮复古板鞋”这类多重约束。隐性信息可以显式化模型可以从用户行为序列里抽象出隐含偏好比如“常看街头品牌”“价格敏感度偏高”在生成时顺势把这类偏好注入候选。新商品不需要边等索引边哭泣只要模型拿到新商品的结构化属性就可以直接生成和它的目标匹配不再纠结于embedding有没有及时更新。召回结果更容易解释你可以直接回溯到底是哪个属性节点把某个候选商品拉高了得分这对后续调优和排查问题极为友好。当然这些增量是有代价的——生成式模型的耗时、资源消耗、结果合法性都比传统检索复杂得多。这部分我放到实操章节细细说。3. 实操从0到1搭一套生成式召回系统3.1 第一步数据准备与训练样本构造生成式召回第一步不是挑模型而是处理数据。我们最终用的样本格式是输入用户query 用户上下文近7天点击序列、加购商品、会话内浏览记录输出目标商品ID序列按用户真实行为时效加权后排序样本来源主要有三个点击日志凡是曝光后产生点击的商品都视为正样本加购/成交日志权重最高人工标注样本覆盖冷门长尾场景。负样本怎么选也很讲究不能只拿随机商品那样模型学不出“拒绝能力”。我们的做法是加入同场景低转化商品和属性冲突商品比如用户明确搜白色给它配黑色商品当负类强制模型学会属性级别的区分。资金、算力允许的情况下训练样本量级最好在“百万条以上”起步。得物平台体量完全能撑起这个数据规模。但要注意样本构造时一定要做时效衰减否则搜索榜里的爆款会把长尾样本淹没。3.2 第二步模型架构选择与训练细节我们尝试过几类模型最终落在Seq2Seq和Decoder-only两种架构的选择上。先看Seq2Seq比如T5。它的优势是编码端能充分理解query和用户行为序列解码端输出我们能控制长度。训练时直接用最大似然估计对“生成候选商品ID列表”这个任务相当顺手。缺点是自回归解码速度慢模型体积也不能太大否则在线扛不住。Decoder-only比如LLaMA系的潜力更大但它在电商召回这种结构化任务上容易“放飞自我”生成不存在的商品ID的概率更高工程代价比较感人。目前我们在线上用的是一版6层、hidden_size为768的T5风格模型参数量在1亿上下。这个规模既能保证效果在线推理延迟也不会太难压。训练细节上有几个参数值得参考项目数值范围说明学习率1e-4 到 3e-4使用线性warmup 余弦衰减Batch size256 到 512过小会导致收敛不稳定最大解码长度64 个token一个商品ID映射成一个token优化器AdamW权重衰减设为 0.01训练轮数3 到 5 个epoch过拟合倒不是大问题主要控延迟训练损失函数就是标准的“交叉熵”但我额外做了两步操作一是给非目标商品ID加了一个小概率mask防止模型始终死磕高频爆款二是引入对比学习损失把正样本商品ID的表示拉近负样本推远。这个组合让最终的生成候选在“相关度”和“多样性”上取得了相对理想的平衡。3.3 第三步在线服务搭建与延迟优化在线架构是网上讨论最多、也是翻车最频繁的地方。我们的实时链路长这样用户输入query后先经过生成式召回服务模型直接产出top 80个候选商品ID这些ID一方面去重另一方面和商品库做合法性校验紧接着再和向量检索、倒排索引的召回结果合并统一进入精排阶段。整个链路的实时性压力主要在生成模型推理上。自回归机制按token逐个输出一般几百毫秒就出去了。如果这一步处理不好整个搜索接口就得超时。我们的优化手段是采样限制beam search宽度从8收窄到3只保留得分最高的候选路径。早停机制一旦生成候选数量达到80个或连续两步的得分不再上升立即截断解码。批量推理把同一秒内相似query的请求合并进一个batch利用GPU的并行计算能力摊薄耗时。缓存热数据对高频query的生成结果做短时缓存缓存命中时能秒开。实操下来p99延迟能控制在180毫秒以内已经基本接近向量检索的水平。这个数字对交易场景来说是可以接受的毕竟多出的几十毫秒换来的召回质量的提升对业务有实打实的增量。3.4 第四步离线评估与回归体系生成式召回最大的评估难题是“怎么判断生成结果好”。传统RecallK又不够因为生成式召回的候选里可能混进不少“新面孔”它们不在原用户点击序列里却可能是好商品。所以我们建了两套评估矩阵。第一套是例行离线指标合法性比例生成商品ID中真实存在于商品库的比例这个指标必须接近100%。多样性指标生成候选的类目、品牌熵值保证不是集中在一两个爆款上。RecallK和向量检索对比在K等于50时生成式召回高出约12个点。新增命中率生成结果里有多少商品是向量检索绝对捞不出来的这部分最能体现“跃迁”的价值。第二套是端到端的业务回归把生成式召回开启后进行小流量A/B实验观察点击率、加购率、下单率三个指标是否同步抬升。有一次实验我们惊喜地发现长尾词的下单转化率提升了23%这在原先向量检索时代根本不敢想。因为这个模型对长尾新词的意图泛化能力特别强它能直接根据罕见query生成合理属性组合绕过embedding冷启动这个无底洞。4. 踩坑实录三个最经典的翻车现场4.1 翻车一生成的商品ID根本不存在第一次把生成式召回推上线时我们傻眼了全程识别到无数个“幽灵商品”——模型输出了一大串自信的商品ID可商品库里压根没有这些ID。拆开日志一看模型就是把某些高概率的token给暴力生成了完全不符合商品ID的分布。解决方案是约束解码。我们的商品ID整体做成了固定的词表token解码时每个解码步只允许从“当前商品库真实ID集合”对应的token子集里挑选下一步。同时在训练中强制加入ID合法性损失。这个约束能直接让“幽灵商品”比例从10%压到0.1%以下。换句话说生成式模型绝不能裸奔输出必须套上业务合法性的紧箍咒。这算是生成式召回落地最核心的一条经验。4.2 翻车二生成延迟比向量检索慢100倍我们早期的原型跑得很爽结果一接线上压力测试直接爆掉。自回归模型一并发打进来高延迟加上资源占用高服务差点假死。一开始我们还想靠增加GPU集群扛但成本完全扛不住毕竟搜索流量是按量级的。最终我们妥协出了一个两阶段生成策略第一阶段用一个小规模的非自回归模型比如CTC模型快速产出商品类目、品牌、核心属性的“粗组合”候选备受限的候选集通常能砍到很小第二阶段再对粗组合候选里的商品ID做自回归精修这样需要生成的token数量大幅减少延迟也就压下来了。这个方案在效果上只牺牲了不到5%的Recall但延迟降到了原来单模型自回归的七分之一。工程上的灵活取舍远比一个“完美模型”重要。4.3 翻车三和向量检索怎么共存我们刚开始做生成式召回时团队里自然产生了“谁取代谁”的争论。实际上交易搜索这种场景根本不是非黑即白。向量检索对流行爆款的召回极其高效生成式召回对长尾、复杂意图更友好。两者互补性很强。最后我们采用双通道融合方案生成式召回作为score 1向量检索作为score 2两个通道的候选先合并再用一个轻量级的粗排模型GBDT或双塔统一打分。线上遍历了一套融合权重实验发现当生成式候选占比40%、向量检索候选占比60%时综合业务指标最好。这个比例在不同类目会有浮动比如潮玩类生成式占比能到55%那是因为用户对潮玩的口语化描述太丰富了向量检索本身就有心无力。一句话总结新范式不是来砸场子的是来补位子的。5. 对业务的影响与个人实操心得5.1 实际业务增量不止是“涨点”而已数据上最明显的变化是体现在几个点位的增长上。整体搜索点击率提升了8%但加购率和下单率分别提升了11%和13%。其中最有意思的是客单价也有了小幅抬升。回查数据后发现生成式召回的候选集合里涌现出了不少“高阶潮牌”商品因为模型从用户行为序列中读出了“这人浏览过某品牌但一直没买”于是主动生成了更直接的品牌匹配项。这让我觉得搜索召回这项工作的真正目标并不是迎合用户字面上输入的那个词而是去“理解他为何在深夜打开得物App”。生成式召回恰好就是往这个方向迈了一大步。5.2 个人实操心得与扩展思路如果你也想在自己的交易搜索场景里试水生成式召回我想掏心窝子说几句不要一上来就追求大模型。把握住中间层6层到12层这样规模的模型性价比远高于堆参数量。生成式召回的结果必须配合“合法性校验结构化属性校验”否则模型的天马行空会让你崩溃。不要把召回当孤岛它和粗排、精排以及一个良好的向量检索通道深度绑定融合调优比“单点刷分”重要得多。排容错机制。你不可能一步到位灰度发布、降级回退、缓存策略都是保命牌。另外我们内部还在探索一个方向把用户一句话变成一个“多目标组合检索条件”不只用于交易搜索还能直接复用为“新客首页推荐”“相似商品推荐”等场景的触发器。从语义生成到行为泛化这个链路一旦打通原地就多出一套能自我进化的推荐系统。踩过这么多坑之后我最深的体会是搜索召回的下一个时代拼的可能不是你会不会卷向量而是你会不会信任并驾驭生成式AI的“想象力”并把这种想象力牢牢拴在业务真实需求的轨道上。希望这篇分享能给你一点启发。