搜索圈这两年最深的感受就是所有团队都在卷向量检索。双塔卷完卷 ANN 参数ANN 卷完卷图召回最后大家交出来的线上指标几乎都长一个样——你的 RecallK 涨了 0.3%我的 A/B 提升 0.2%谁都没法真正拉开差距。说到底这些努力没跳出同一个范式把 query 和商品放到一个空间里求“相似”。直到我看到得物交易搜索团队在讲“生成式召回”这条路子才觉得这事终于有点不一样了。它不是给现有漏斗打补丁而是把召回这件事从“匹配”迁到了“生成”。今天想把这条技术路线的原理、落地方式和踩坑经验一次说清楚给正在做电商搜索、以及想跳出向量检索惯性思维的人一个参考。1. 别急着卷向量检索先看清这波“内卷”卷到哪了1.1 向量检索解决过什么问题先把时间轴拉回去。最早做电商召回就是倒排索引query 分词、匹配商品标题里的关键词逻辑简单、响应快但天花板也很明显用户说“白色休闲鞋”商品标题写的是“小白鞋 百搭 板鞋”词面完全不一样倒排索引就断了。向量检索解决的就是这个问题把 query 和商品都编码成固定维度的向量然后用余弦相似度或者内积去衡量语义距离本质上等于把“拿病历逐字比对”换成了“拿两张照片比长相”对同义改写、口语表达宽容得多。这波技术红利确实存在所以过去五年几乎所有搜索团队都在做同一件事把词表改成 embedding 表把倒排拉链换成 HNSW 图把词频统计换成双塔模型。到 2023 年之后业内中等规模的电商团队基本都能做到“只要用户说得像人话向量召回就能找到八成像的商品”。基础设施也成熟了Milvus、FAISS、Qdrant 这些向量数据库或算法库都能扛住亿级规模部署门槛低到不像一个算法问题更像一个运维问题。1.2 但向量检索有三个说不出口的瓶颈问题在于向量检索的“语义相似”是一种软匹配它擅长处理模糊却处理不好精确。很多搜索词其实是带强约束的比如“黑色 42码 高帮 帆布鞋”用户要的是四个属性同时满足。双塔模型把整句话压成一个向量后四个约束会被折叠成一个浮点向量颜色、尺码、鞋型的信息互相稀释。最后结果常常是“颜色对了但码数不对”或者“款式对了但颜色偏差”召回器其实并不知道用户是在指定一个精确条件它只知道你这个 query 和某些商品向量距离近。第二个问题是锚点漂移。query 里经常有歧义词“苹果”可能是手机也可能是水果“AJ”可能是球鞋也可能是 Air Jordan 的含糊简称。双塔模型为了兼容所有正样本会把这类 query 的向量往几个簇的公共区域推结果就是“苹果手机和苹果水果都召得一般”谁都捞不准。这种失效不是调参能解决的是表示学习本身的折中。第三个问题藏在长尾里。双塔训练依赖大量的点击和曝光日志头部的爆款商品样本多、向量学得稳长尾商品曝光少、正样本稀疏向量空间里被挤到边缘即使用户明确搜了一个小众单品名召回也可能把它漏掉。而交易搜索里恰恰是这部分长尾需求最有利润空间。1.3 问题的本质是“近似匹配”不等于“条件生成”如果把搜索召回抽象成一句话给定一个用户意图从候选商品库里选出一批最该被展示的对象。传统向量检索的思路是在一个巨大的向量空间里找“离 query 最近的点”这隐含了一个假设——query 和商品一定存在一个几何上可比的表达空间。但真实交易搜索里的 query 往往比商品表达更口语、更残缺、更具联想性用户不是在做“相似匹配”而是在做“意图描述”需要系统去推导出他最可能想买的那几个商品。这也是为什么得物交易搜索会转向生成式召回。生成式召回不再把问题当作“在向量空间里做 KNN”而是把问题重写为“给定 query逐词生成它对应的商品 ID 序列”。这个过程更像翻译输入中文意图输出商品库里的离散标识符。你不需要先找到一个好的向量空间再在里面做近邻搜索你是直接学习从 query 到商品 ID 的条件概率。这个范式的转换才是真正意义上的跃迁。2. 生成式召回到底是啥把商品库变成一张“会说话的词表”2.1 从“检索”到“生成”的核心转变简单理解生成式召回可以把它想成一本超级厚的“商品字典”。传统召回是在字典里做匹配倒排索引是查词条向量召回是查近义词。而生成式召回把字典本身变成了词表模型像一个“翻译机”你给它一句 query它直接吐出一串商品 ID就像你问一个人“我要买那个黑色的耐克高帮帆布鞋”他不需要翻目录而是直接说出商品编号。这个方向的学术脉络是清晰可见的。Google 的 DSIDifferentiable Search Index最早提出把文档集合直接参数化到模型里输入 query 输出 docid后来的 TIGERTransformer-based Index for GEnerative Retrieval把这个思路引到了商品推荐场景核心做法是用 RQ-VAE 给每个商品生成一个多层离散编码作为商品 ID再用 encoder-decoder 模型做序列生成。得物交易搜索的落地路径明显沿用了这条思路再叠加了电商场景特有的约束。这套设计的关键不是模型本身有多深而是“商品 ID 怎么设计”和“生成空间怎么约束”。2.2 商品 ID 的灵魂语义 ID 与 RQ-VAE生成式召回的第一道关卡是给商品库里的每一件商品一个 ID但这个 ID 不能是随机短链。如果商品 ID 只是一串随机编码模型学起来就是硬背字典既没有泛化能力也不能处理新商品。所以得物这类实践里用的是“语义 ID”先对商品侧信息标题、类目、品牌、价格档位、属性标签做 embedding然后用残差量化向量RQ-VAE把高维向量压缩成多层离散token。RQ-VAE 特别适合干这件事。它把商品表示从高维连续空间像“剥洋葱”一样逐层拆开第一层残留一个粗粒度语义比如“鞋”第二层细一点点比如“高帮帆布鞋”第三层再细比如“黑色 42码”每一层都在拟合上一层的残差。每一层有一个码本比如 4 层×8192 个码字组合起来就是一棵巨大的前缀树。这种 ID 结构的好处是语义相近的商品在 ID 前缀上天然相近模型生成的时候不需要精确背出整串 ID它只要一步步把语义逐层说清楚就能锁定到具体的商品。2.3 训练和推理的完整闭环整个系统的训练目标非常简单——和机器翻译一模一样的交叉熵。把用户 query 作为 encoder 输入把商品语义 ID 序列作为 decoder 输出用点击、成交数据作为正样本在 batch 内随机采样负样本标准 teacher forcing 训练。学完之后推理时输入一条 query解码器用 beam search 一个个吐出 token每一步都查一遍前缀树确保当前生成的前缀能对应到至少一个真实商品否则直接剪掉这一路。这个设计里最容易被低估的是前缀树约束。商品库可能有几百万甚至上千万商品但离散 ID 的组合空间是 8192 的 4 次方模型如果自由生成大概率会吐出一个不存在的 ID。加了前缀树剪枝之后beam 里每一步只有落在合法前缀上的候选才能存活模型永远不可能输出库里没有的商品。这也引出一个重要结论生成式召回里的“生成”不是无限制的 AI 自由发挥它是一个输出空间被彻底焊死的受限生成。它不会像通用大模型那样胡编乱造这种可控性恰恰是它能落到严肃交易场景的前提。2.4 为什么它能补上向量检索的洞对照着看就很清楚。向量检索的三个老大难精确属性折叠、query 歧义漂移、长尾稀疏——生成式召回都有结构性的缓解。精确属性这块RQ-VAE 分层码本天然把“颜色、尺码、类目”拆成不同层级的预测目标模型生成的时候是逐步收敛的先定大方向再定细节比向量空间里一个点扛所有属性要清楚得多。长尾方面更明显生成式模型不依赖候选商品必须出现在训练 batch 的负样本堆里它学习的是“从意图到 ID 的条件概率”一个长尾商品哪怕曝光少只要它的语义 ID 存在于码本中模型就有机会在解码路径上经过它而不是像双塔那样在向量空间里被挤到无人区。当然这不是说生成式召回没有任何代价。它最大的代价是把原来“一次 ANN 查询”变成了“多步自回归解码”延迟和计算量都上来了这就是我们落地时要啃的硬骨头。3. 得物交易搜索的落地拆解“生成式”不是替代是叠加3.1 交易搜索和内容搜索的约束完全不同先强调一个前提得物做的是交易搜索不是内容搜索这两者的召回诉求差异非常大。内容搜索里用户刷到什么都能凑合看曝光了就算召回成功但交易搜索每一条用户行为后面都是真金白银的加购和支付用户搜“黑色高帮帆布鞋”如果召回来的是一双白色低帮跑鞋他大概率会直接退出根本轮不到排序阶段去纠错。所以交易搜索的召回器必须对商品的价格、类目、库存、在售状态这些硬约束有感知。在生成式召回里这类约束一部分被编码进了语义 ID 的码本比如价格档位、类目层级会占掉一层码字另一部分需要在解码之后做规则过滤。业界常见的做法是不要在解码过程中尝试处理所有规则因为规则一旦变了就得重新生成模型输出。正确姿势是让生成模型负责“语义上最可能对”的候选再用一个轻量级元数据 KV 表做在线硬剪枝商品是否在售、库存是否可售、是否合规、发货区域是否匹配。这种“生成加剪枝”的组合既保留了生成模型的语义能力又把不可控的业务规则隔离在模型之外。3.2 整体链路长这样从公开信息和行业同态实践来看得物交易搜索这套生成式召回大概跑在下面的链路上query 进到系统后先走一层 query 理解完成分词、改写、纠错拿到结构化意图标签然后生成式召回模型接管 query 编码用 beam search 生成几百个候选商品 ID这些 ID 立刻去反查商品元数据把标题、图片、价格、库存拉出来做一轮规则硬剪枝剪完之后和传统倒排召回、向量召回的结果一起进入融合层合并去重后送粗排。这条链路里最关键的设计是“并行不替代”。生成式召回不是要推翻倒排和向量它只是一个新的召回通道。真实线上系统的做法是让三条通道同时跑最后在融合层按预估分数做加权或者 rank 合并。为什么要这么设计因为生成式召回虽然语义推导能力强但它的行为模式和传统通道差异太大——它更适合处理“用户描述了一个具体款式需要推导出对应商品 ID”的场景而倒排索引在品牌词、型号词、精确词上依然更快更稳向量召回在处理泛意图大词时依然有不可替代的优势。多通道并行是工程上最稳妥的上线策略。3.3 “找同款”和“参数查询”是生成式主战场得物搜索里有一类 query 非常典型用户看到一张图或者一个短视频想买视频里那个同款球鞋但他叫不出款式的确切编号。他只能描述“那个白色的耐克空军一号低帮”。传统倒排遇到这种 query 基本无能为力向量召回会把这个描述折叠成一个模糊向量可能召到空军一号也可能召到一堆白色 nike 运动鞋根本分辨不出具体 SKU。但生成式召回在处理这类 query 时有天然优势。它训练时见过大量“口语描述到商品 ID”的映射RQ-VAE 码本又把类目、型号、材质这些维度拆开了。解码过程中模型可以先生成“白色 耐克 球鞋”的粗粒度码字再逐步收敛到“空军一号低帮”的细粒度码字。如果用户后续补充了“42码”这些属性还能在后续 token 中继续指定。这就是从“近似检索”到“条件生成”的差别它不只是找一个语义近似的点而是按逻辑先锁定类目、再锁定属性、最后锁定商品能处理更多层级的约束。我在自己的业务里观察到一个共通的规律这种 query 的成交率本来就比普通泛意图 query 高但传统召回经常漏相当于白白流失毛利。生成式召回上线后最先看到显著收益的几乎都是这一类“多属性叠加、口语化描述”的搜索。如果你们的业务里也有大量同款、代购、参数查询类流量生成式召回值得重点关注。3.4 别指望零成本延迟和算力的代价要提前算清楚任何范式跃迁都不免费。生成式召回最直接的代价在延迟上向量召回基本是一次矩阵计算加 HNSW 图搜索响应时间能压在十毫秒以内生成式召回是自回归解码即使有前缀树剪枝和 KV cachebeam 宽度只要开到 16 以上解码时间就会肉眼可见地涨。从行业同类系统的公开数据来看这类系统在 GPU 上的端到端耗时通常会比向量召回高一到两倍CPU 上会更夸张。所以实际落地时一般会做三件事生成式召回通道启用独立线程池和独立模型实例不让它拖累主链路beam 宽度按流量高峰期自动降级比如平时 32 路大促压测时降到 8 路最后再加一层总超时控制比如 25 毫秒没出结果就直接降级让这条通道空跑不阻塞整个搜索请求。把这些准备好生成式召回才敢放进用户流量里。4. 工程实现与调参备忘从训练到上线要过的五道关4.1 训练数据别上来就追求“大而全”生成式召回是监督学习样本质量决定天花板。最自然的正样本是点击和成交日志点过的商品 ID 作为目标序列。但这里有一个大坑用户点了某个商品不代表这个商品是“最正确”的答案他可能只是随便看看。所以在构造训练样本时要对行为加权成交权重大于点击权重长点击大于短点击。负样本方面抽样一批随机商品作为 batch 内负例是必要的同时也可以从负反馈日志里捞一批“被展示但没有被点击的商品”这能大幅降低模型把热门爆款无条件排在所有 query 前面的倾向。样本里还需要刻意加入“对话式描述”的数据。电商搜索日志里能挖到很多用户表达比如“有没有 200 块以下的黑色高帮鞋”“想买李宁那款白色运动鞋”。这类带属性约束的 query 是生成式召回的精华样本越多越好。如果业务里这类流量本来就少可以先拿搜索日志里的 query 做改写用小模型把短查询扩写成自然语言描述再用伪标签的方式加入训练集。# 训练样本构造的简化示意 def build_training_instances(search_log, behavior_weight): instances [] for query, item, action in search_log: if action purchase: weight 3.0 elif action long_click: weight 1.5 else: weight 0.5 semantic_id item_id_encode(item) # RQ-VAE 得到 4-token 语义ID instances.append({ src: query, tgt: semantic_id, weight: weight, }) return instances4.2 模型结构与训练细节模型主体不用做得多大一个两三百兆的 encoder-decoder 就够用。encoder 侧可以复用团队现有的语义编码器学习率初始设在 1e-4 左右线性衰减加上一个 brief warmup。训练 loss 就是标准的 CE loss如果希望模型在收敛后更多关注成交意图可以加一点 rank loss 做辅助让它在主码本预测正确的基础上对商品的热度偏差做校准。训练中最容易犯的错是商品 ID 和 token ID 的映射表不稳定。因为 RQ-VAE 每次重训都会产出新的码本ID 序列会整体变化如果边训练边换码本模型就一直在追一个移动的靶子。稳妥做法是像建立“发布基线”一样管理码本确定一版 RQ-VAE 后冻结再用它生成全部训练样本的语义 ID整个训练周期内不再变更。商品库的增量更新通过“冻结旧码字、只扩展新码字”的方式处理保证老 ID 的语义不漂移。4.3 推理加速与候选收割推理阶段要压性能第一件事是把 beam search 的实现换成前缀树动态剪枝版。每解码一个 token就查一遍当前前缀在商品 ID 集合里是否还有后继没有就砍掉。第二件事是 KV cache这是标配没有它自回归根本没法上线。第三件事是候选收割策略解码完成后不是取 beam 里排名最高的单一路径而是在所有 beam 的路径上前缀去重然后把命中的所有合法商品 ID 都收进来。这样能让同一个 beam 宽度下收割到的候选数多不少实测对召回率的帮助非常明显。这里有一个工程取舍值得记下来生成式模型对“头部泛意图 query”的效果通常不如倒排但对“长尾描述型 query”的效果远超其他通道。所以线上调度时可以做 query 难易分流简单词直接走倒排和向量复杂描述类 query 才进生成式通道。这种调度策略能让整体算力成本下降非常多而不是让每条 query 都来一次自回归解码。4.4 底层存储的新需求你还需要向量库吗很多团队会问做生成式召回还需要 Milvus 或者 FAISS 吗这要看你走的是纯生成式路线还是混合路线。纯生成式在线推理阶段模型对商品库的访问完全走码表和前缀树商品元数据放一张 KV 表就能满足反查需求向量索引实际上退出了在线主链路。但如果你的线上仍然是混合召回向量通道还在跑那就还需要一个 ANN 向量库只不过它的角色从“召回的绝对主力”变成“多路召回里的协同者”。从底层组件角度看生成式召回对基础设施的要求不是“向量数据库”而是三样东西第一一个高性能前缀树或倒排 ID 索引支撑解码过程中的合法性检查第二一个低延迟的 KV 存储支撑候选 ID 到商品元数据的在线反查第三一套码本管理工具支撑 RQ-VAE 的离线训练、版本冻结和增量更新。这套组件虽然和向量检索的基建不完全重合但很多团队其实早就有了倒排索引本身就是一棵天然前缀树把 docid 换成语义 ID 即可复用。5. 踩坑实录与常见问题速查5.1 商品 ID 漂移同一个商品上午还在、下午就“消失”了这个坑几乎每个团队都会踩。商品信息一变比如改了标题、换了类目或者 RQ-VAE 增量更新后码本变了同一件商品对应的语义 ID 就可能变成另一串序列。对模型来说它辛辛苦苦记住了“这个 query 应该输出 A 商品”结果 A 商品的 ID 被改了线上解码时模型照着老路径生成前缀树里已经没有对应节点了这个商品就直接从候选里蒸发。解决办法是给语义 ID 加一层版本管理码本和 ID 映射表做成版本化发布线上推理统一使用当前 active 版本增量更新时老商品尽量保留旧码字只有新商品或语义变化大的商品才分配新 ID每次码本更新后必须做一次离线回归重点盯“同一 query 的召回结果漂移率”。我见过最夸张的一次漂移是 30% 的结果变化从那次之后我们就再也不敢用裸 RQ-VAE 直接上线了。5.2 双子重复同一个 query 生成出一堆“双胞胎”候选beam search 有个典型毛病多条 beam 走到最后收敛到相似甚至相同的路径上。生成召回结果看起来数量不少去重之后发现只有三四个独特的商品其他全是近义词重复。这会把召回多样性压得很低对后续排序也不友好。解决思路有两个一个是在解码时加长度惩罚和 n-gram 重复惩罚让模型不要总盯着一个模式输出另一个更有效是在收割候选时直接用商品 ID 做前缀去重并且允许从不同 beam 路径上摘取不同的前缀子树。比如 beam 1 收敛到了 A 商品路径beam 5 可能同样经过了 A 的前两个前缀 token 但第三个 token 分岔出去了那就把分岔分支上的商品也收进来这样能在不太损失精度的前提下把候选量推上去。5.3 冷启动难题一个新上架的商品怎么让模型“认识”它新商品上架当天它没有点击日志没有成交数据模型训练时压根没见过它更不可能在 beam 搜索路径上走出来。这是所有生成式索引类方法都绕不开的痛点。我们的做法分两步走第一步是 RQ-VAE 增量编码新商品进库后立刻生成语义 ID 并挂进前缀树保证它至少有资格被解码路径经过第二步是用“相似商品迁移”找同品牌同叶子类目的老商品用它们的 query-商品训练样本做近邻迁移让模型在解码经过相关前缀时有机会落到新商品上。这一步能解决“有资格被召回”的问题但解决不了“排序有信心”的问题新商品最终的转化仍然要交给粗排精排去判断。所以在召回层面目标是别让新商品因为“模型没见过”就天然隐形而不是强行让它在所有场景下都排到前面。5.4 常见问题速查表问题现象可能原因排查思路解决建议线上候选大量非法 ID 被过滤前缀树索引更新延迟解码范围和实际商品库不一致检查索引版本和生效时间索引更新与模型发布走同一发布流水线先更新索引再切流量同一 query 召回结果频繁变化码本增量更新导致 ID 漂移对比两个版本的 ID 映射覆盖率老商品冻结码字新商品走增量分配重大语义变更走全量重训GPU 延迟抖动严重beam 宽路太多、部分 query 意图复杂导致解码步数增加按 query 意图维度拆分延迟监控增加 query 并行度、超时降级、复杂 query 走独立实例召回多样性差翻来覆去几个爆款训练样本热度分布失衡检查正样本成交权重是否过高降低成交权重、加入随机负样本、解码端加重词惩罚新商品全站不可召新商品语义 ID 未挂上解码前缀树检查增量编码产物入库耗时增量编码流程设分钟级延迟目标上线前做“新商品可召回”巡检5.5 一个小技巧先做离线回放再上 A/B生成式召回上线前很多人直接拿 nDCG 或 RecallK 评估一下就去开实验了这是不够的。我建议务必做一个离线回放取一段时间真实线上日志把 query 重新用新模型跑一遍召回再和当时实际展示、点击、成交的商品做对齐看新增召回里有多少是真实成交过的有多少是用户当时想买但没有被旧系统捞上来的。这个“旧系统漏掉但用户真实购买”的比例比离线指标更能说明新召回通道的价值。我们当时上线前测出来这个比例在长尾 query 上接近三成才下定决心推进度后来线上 A/B 的表现也印证了这个判断。最后说点实际体会我自己研究这条路线半年多的感受是生成式召回带来的不是某一个模型或者某一套参数的升级而是从“把商品库变成向量的集合”到“把商品库变成模型词汇表的延伸”这一整套思维转变。前期最耗时间的不是模型训练而是商品 ID 体系设计、码本稳定性和训练样本的质量这三件事做不好再强的模型也发挥不出来做好之后线上收益往往是稳的、持续的而且是向量检索很难再挤出来的增量。我个人的建议是如果你的搜索团队已经有成熟的向量召回链路别急着推翻重来也别把生成式召回当成一个万金油方案。先拿一个月时间搭一套最小闭环只用历史点击日志训练一个小规模的 encoder-decoder用离线回放验证“旧系统漏掉但实际成交”的比例再考虑要不要进线上 A/B。至于那些热门的知识库、向量库选型问题在这个方案里反而变得没那么关键——真正的注意力应该放在码本、前缀树和样本工程上。搜索下一波红利大概率不在更长的向量里而在更聪明的索引结构里。