1. 方向判断交易搜索召回卷不动了吗1.1 向量检索的天花板不在速度在“语义边际”这两年聊搜索召回十个人里九个在说向量检索。图片、文本、用户行为序列全都能拉成一个embedding然后扔进ANN里做近似最近邻。这一套在新闻推荐、商品详情页推荐里确实香但在交易搜索场景里我越做越觉得不对劲向量检索本质上解决的是“语义相似”的问题而交易搜索要解决的是“成交意图”的问题。这两者之间有很长的鸿沟。我在做交易搜索召回时最直观的感受是向量检索的收益在快速衰减。前两年刚上线向量召回端到端效果确实涨了一截因为原来倒排召回抓不到的“语义等价”长尾词被捞回来了。但跑了一段时间问题开始暴露向量召回的候选集边界非常模糊同一个query出来的向量邻居里有大量“看起来像但用户根本不买”的商品。相关性要重新过一遍粗排才能拉回来精排段还要花大量算力去校正召回阶段埋下的噪声。说白了向量检索把麻烦从“召回”转移到了“排序”并没有真正理解用户这句话到底想买什么。另一个藏在现象背后的事实是交易搜索的query普遍短、杂、有错别字、带有明显的类目意图和品牌意图。比如“AJ1 低帮 白灰”、“iPhone 15 Pro 原色钛金属256G”、“始祖鸟 beta lt 男款”这种query用向量去召回往往会把“同风格但不同型号”的东西混进来。因为向量空间是连续稠密的它擅长计算“距离近”但它很难精准回答“用户要的到底是哪个叶子类目、哪一代产品、哪个规格”。所以当团队里还在争论要不要再加一路向量召回、要不要把向量维数再调大时我反而觉得方向应该换一下。交易搜索真正的瓶颈不是“找相似的”而是“猜准用户心里的那棵商品树”。这已经不是召回层能靠特征堆出来的能力而是需要模型直接“理解并输出”检索目标。这个念头就是后来我们转去做生成式召回的最初动机。1.2 生成式召回到底是什么一句话先说明白生成式召回英文叫Generative Retrieval业界也叫“直接生成文档标识符”或“Seq2Seq Retrieval”。传统召回流程是query进来先跟一个大的候选池做匹配倒排也好、向量也罢都是“从池子里捞一堆候选”。生成式召回完全反过来模型不捞候选而是直接根据query生成“目标商品的标识序列”。你可以理解成以前是“在字典里查词”现在是“直接把句子写出来”。举个例子用户搜“索尼ps5港版双手柄”传统倒排是分词匹配向量召回是算语义相似而生成式模型会直接输出一个结构化的序列——[类目游戏主机] [品牌索尼] [系列PS5] [版本港版] [配件双手柄套装]。这个输出不是一个商品ID而是一条意图路径。拿到这条路径之后再通过索引映射到实际商品集合也就是先锁类目、再锁属性、最终圈定一小撮真正可买的东西。这个思路最早的学术来源是Differentiable Search IndexDSI把文档ID当作生成目标用T5之类的模型端到端训练。后来Google、Meta陆续在网页搜索、电商搜索场景放出了Generative Retrieval的论文。原理不复杂就是让模型在海量的“query到doc ID”训练样本里学会把query直接映射成目标ID序列。但在交易搜索里直接照搬这个套路会踩坑踩到怀疑人生因为商品ID的分布极不均衡、Top爆品占据绝大多数query而且商品ID是离散无结构的。我后面会专门讲我们怎么绕开这些坑。我当时决定在交易搜索场景押注生成式召回还有一个很现实的原因搜索算法的核心矛盾是“要精准还是要召回”。倒排太精准长尾语料就漏向量够宽但精度不保证精排再强也只能在召回给定集合内排。如果召回阶段本身就能“理解”query里的类目、品牌、型号、版本那整个漏斗的入口质量就不一样了。这也符合一个更朴素的判断交易搜索的本质不是“语义相似”而是“意图解析 商品匹配”。2. 生成式召回到底改了什么2.1 从“先抄名单再打分”到“直接把答案写出来”传统模式像学生考试做论述题先翻资料召回凑齐一批论点候选商品再组织语言论证哪个论点得分高排序最后选出最像正确答案的那段。生成式召回更像是做填空题看到题目直接在脑海里组织出答案的主体结构然后再补全细节。搜索链路从“召回粗排精排”变成“生成目标结构 映射商品池 精排打分”最大的变化是召回阶段从“匹配”变成了“推理”。这一步改动的意义在交易场景里尤其明显。用户搜“冬季 男士 羽绒服 中长款 鹅绒 防风”传统的向量检索会把它当成一个整体语义去查召回结果里既有“男士夹克”又有“棉服”也有“羽绒服”反正向量空间里它们距离都挺近。但生成式模型会先学到一个概率分布这一类query里“鹅绒”和“中长款”是极强的修饰约束模型会更倾向于输出[男装] [羽绒服] [中长] [鹅绒]这条路径生成的结果天然符合交易搜索对召回的要求——多条件约束下的精确匹配。这里有一个很重要的隐藏收益生成式召回把query理解任务和检索任务合并了。以前的链路里query理解是一个独立的模块实体识别、意图分类、类目预测一层套一层任何一个环节出错都会传导到召回。生成式模型端到端训练所有信号都融合在生成过程中少了很多pipeline的级联误差。我在实践里的体会是线上指标提升有一部分就来自这种“端到端去模块化”带来的对齐效应而不仅仅是生成式模型本身的能力。2.2 为什么商品ID不能直接生成——可生成单元设计很多人一听生成式召回第一反应是“让模型直接吐商品ID不就行了”。我劝你先冷静。商品ID是完全没有语义结构的随机序列模型学起来极为吃力。更重要的是商品ID的候选空间动辄上亿而训练样本里只有极少商品被高频query覆盖绝大部分长尾商品在训练中几乎见不到你让模型生成一个从来没见过的商品ID等于让一个只学过几千汉字的人写出一篇十万字的小说字都对不上。直接生成商品ID还会碰上一个供给侧问题商品是有生命周期的。今天在售的爆款三个月后可能下架了而新上架的商品没有任何历史query日志按生成式训练的老套路新商品永远出不来。电商搜索对时效性是极其敏感的一个连“新品冷启”都解决不了的召回方案上线当天就会被业务方打死。所以落地生成式召回关键一步是设计“可生成单元”。我们最后采用的是语义单元序列方案不再生成一个扁平的ID而是生成一串结构化的离散Token每个Token表示一个语义原子——类目、品牌、系列、性别、关键属性、规格版本等。模型的任务变成了“预测这串语义原子序列”。序列生成完之后再利用一个“语义原子到商品池”的倒排映射把命中的商品作为召回集输出。这个设计的好处很实在第一语义原子的数量级是几千到几万远比商品ID空间小模型学得动第二语义原子是稳定的不随商品上下架而剧烈变化第三新商品只要被打上正确的结构化标签就能被已有的语义路径召回冷启动问题天然缓解第四序列本身是可解释的出了问题能回溯是哪个语义原子预测错了。这个决定我怎么强调都不为过生成式召回落地先定义你的“词表”再谈模型结构。2.3 受控解码生成不是自由发挥是带“交通规则”的路径搜索模型训练好之后线上推理阶段如果直接beam search输出序列会碰上一个问题模型大概率会生成出一些“语义正确但交易不通”的序列。比如生成了[品牌耐克] [品类篮球鞋] [版本空军一号]看似没问题但“空军一号”并不是篮球鞋系列这种组合在商品池里根本不存在映射之后是空结果用户就啥也搜不到。我们在线推理解码时引入了一个“合法路径约束”机制。简单说维护一棵语义原子前缀树每个序列必须沿着这棵树的合法路径一步步展开。比如起点是“所有类目”第一步只能在“男装/女装/鞋靴/箱包/数码……”这些合法类目里选选了“鞋靴”之后下一步只能在该类目下的子类目或属性里选不能跳到“数码”去。这就像开车必须沿着路网走可以选路线但不能开进湖里从根本上杜绝了不存在的组合。这个受控解码逻辑写起来不复杂本质上就是在beam search的每一步用一个合法后继Token集合去mask掉模型的非法输出。改造量不大但对线上效果的提升是决定性的。我见过一些团队申请了论文复现效果不好就放弃了多半是没做约束解码生成了一堆“漂亮的废话”。另一个工程细节是合法路径树不能只按类目层级建要把品牌和类目的组合关系也编码进去比如“Nike”在“潮流服饰”下合法在“数码产品”下不合法这棵树通常直接生成在内存里几万节点的Trie树检索一次也就是微秒级别线上开销完全可以接受。3. 落地的数据库与知识库底座3.1 交易搜索知识库到底存什么做生成式召回绕不开一个词——知识库。很多团队一听到知识库就以为要上一个复杂的图数据库或者什么“知识图谱平台”我觉得先别急着上基建先想清楚交易搜索的知识库里到底需要什么。以我实践下来的经验交易搜索知识库最核心的内容是三类。第一类是实体规范库品牌的标准名、别名、简称、历史叫法。比如“AJ1”其实是“Air Jordan 1”的昵称“Dunk”和“Dunk Low”之间的关系“Yeezy 350 V2”的多种写法。这些信息通常是散落在各个业务团队的Excel和配置后台里的需要专门抽出来统一清洗成结构化表。第二类是类目属性体系每个类目下有哪些合法属性、属性之间有没有互斥关系比如“鞋靴”下的“鞋帮高度”有“低帮/中帮/高帮”“版本”有“中国区/其他区”这些信息决定了约束解码的路径树。第三类是商品映射表每个语义原子组合对应到哪些商品ID这个映射往往需要接实时商品池商品上下架、库存状态变化都要能反映到召回集合里。我们当时搭这块的时候吃过亏一开始知识库散落在多个团队自建的MySQL表和配置文件里品牌词、类目树、商品标签各自维护线上线下不一致生成式模型训练出来的语义原子跟线上知识库的原子对不上。后来不得不专门建了一个“知识库同步链路”每天从商品中心、品牌库、运营配置后台抽取数据统一落到一套结构里再分发给训练、解码、评估三条线使用。所以我的建议是生成式召回工程启动之前先花两周把知识库的数据字典和负责人理清楚这个时间省不得。3.2 向量库检索需要什么数据库生成式落地的“索引复合体”这个话题正好跟很多人关心的“向量库检索需要什么数据库”连在一起。先说结论生成式召回的线上服务不是单一数据库能搞定的它通常是一个“索引复合体”不同阶段用不同的存储。第一个是倒排索引。对就是最传统那种ES或者自研的倒排用来做“语义原子到商品ID”的映射。模型生成出[男装][羽绒服][中长][鹅绒]之后我们要最快找出同时满足这四个标签的商品集合这本质上是一个多标签求交的倒排检索过程ES挺合适但要注意控制分片和查询超时。第二个是内存级前缀树Trie。受控解码每一步都要查合法Token集合这个数据量不大但延迟要求极高通常在10微秒这个量级ES根本扛不住所以我们会放在服务进程内的内存里用Trie或者Hash DAG直接承载。第三个才是向量检索数据库。这里要明确一点生成式召回上线之后并不是把向量检索删掉而是把它降级为“兜底召回”和“泛化召回”。比如模型生成的语义路径命中的商品太少或者query里有模型没见过的词向量召回作为补充通道仍然有价值。这时你的向量库选型Milvus、Faiss、ES向量插件都行主要看三点单机QPS够不够、索引构建增量更新快不快、是否能跟现有粗排服务打通。我个人的倾向是选支持标量过滤和向量检索混合查询的引擎方便后面做“语义路径命中 相似向量召回”的融合逻辑。把这三个存储拼成一个整体说生成式召回服务就像一个“人”模型是大脑负责生成意图路径Trie是骨架负责保证路径合法倒排索引是手臂负责把路径变成商品集合向量库是备用的安全绳负责给泛化兜底。这四个部件缺一不可只盯着“用什么向量库”问反而容易忽略真正决定成败的前两者。3.3 约束解码所需的“前缀树KV”组合受控解码的另一块工程底座是“KV 前缀树”的组合。为什么要KV因为线上并发场景下多个请求会同时带着自己的beam状态来做解码KV存储要缓存两类数据一是“某条语义路径下的实时可用商品数”二是“特定query对应的热门意图路径”。这两个信息能帮我们在beam search的时候做裁剪比如某条序列生成到最后一步时如果映射商品数为0就可以提前剪掉这条候选不用等生成结束再判断省算力也省延迟。我见过有些团队用MySQL存这层知识不是不能用而是高并发下MySQL范式化查询的延迟太高动不动就是几十毫秒解码阶段等不起。我们最后用的是自研缓存加Redis的组合Trie树全量加载到进程内存Redis存更变动的部分比如商品池的实时上下架状态、类目维度的库存量级。线上实验下来约束解码的P99延迟能控制在几毫秒以内跟beam search本身的耗时在同一量级这才有条件把生成式召回接到在线链路上。这里提醒一个容易被忽略的坑前缀树和KV里的知识一旦更新不及时会导致模型生成路径和实际商品池不一致。比如某天运营把“潮玩”类目下架了一批商品知识库里“潮玩”对应的商品集合变了但前缀树里“潮玩”仍然是合法节点模型照样生成这条路径线上就是不返回结果召回率瞬间掉一个点。所以我们上线后专门加了一个“一致性对账”任务每小时跑一次模型生成高频路径与实际商品映射集合的差异对比差异超过阈值就告警强制人工介入。4. 训练、调参与线上效果4.1 样本构造点击日志不等于相关性训练样本是生成式召回最容易翻车的地方。最朴素的想法是用“query → 用户点击的商品ID”作为训练对但直接这么干模型学到的是“用户爱点什么”而不是“用户该点什么”会把大量点击集中在头部爆品上的偏置学进去。比如搜“羽绒服”用户点了一堆“北面1996”的链接模型就会倾向于生成的意图路径里只带“北面”品牌长尾品牌全部被压制。我们处理样本的思路是分三个层次。第一层是“正样本做约束”不是所有点击都算正样本只保留“有点击且在曝光位上停留超过一定时长的行为”过滤掉误触和无意识的点击。第二层是“负样本做平衡”把曝光未点击的query-商品对做成负样本让模型学会区分“相关的爆款”和“不相关但热门的商品”。第三层是“标签做校正”用离线商品标签体系对点击样本做自动校验如果用户点了一个商品但商品结构化标签跟query明显不符大概率是误点直接丢弃。训练数据最终的形式是“query文本 语义原子序列”。这个序列可不是直接从商品标签里抄的而是要经过一个“意图对齐”的步骤。比如用户搜“iPhone 15 Pro 原色 256G”用户点击的商品是“Apple iPhone 15 Pro 256G 原色钛金属”但商品标签体系里可能写的是“颜色原色钛金属”而query里写的是“原色”这两个表述不一致。我们会在训练前做一个“query-标签归一化”把用户的口语表述映射到商品标签体系的规范词上否则模型学了半天也学不会“原色”和“原色钛金属”是同一个原子。4.2 线上推理延迟预算怎么卡线上部署生成式模型最让人担心的就是延迟。传统向量召回一次ANN查询基本在几毫秒到十几个毫秒生成式模型如果是那种标准Encoder-Decoder一个query进来要自回归地跑十几步每步还要做beam search延迟很容易飙到几十毫秒这在线上的搜索链路里是接受不了的。我们的处理思路有三个。第一模型规模做减法。生成式召回不需要上那种几十亿参数的大模型几亿参数的Encoder-Decoder在小样本上已经能学到交易搜索的意图规律了我们甚至用蒸馏把线上模型压到一两亿参数级别单机单卡推理的延迟直接降下来。第二beam search卡上限。beam size别开太大线上用4或5就够输出序列长度上限也做硬限制比如最多12个语义原子生成路径一旦超过就截断宁可截掉尾巴也不让它无限延展。第三缓存热点路径。对于高频query比如“羽绒服”“AJ1”这类词提前离线算好它的TopK语义路径线上直接命中缓存根本都不用走模型推理只有长尾query才需要在线生成。我拉过一个延迟拆解数据纯模型推理占了大头约束解码的Trie查询和倒排映射加起来只占20%左右。所以想优化延迟核心是优化模型推理而不是折腾解码组件。还有一个细节batch推理在交易搜索里用处不大因为搜索请求是离散到达的几乎不可能凑出batch反而是“单query多候选同时解码”这个角度能省更多算力因为同一个beam里不同候选可以共享前缀部分的计算结果。4.3 效果评估不能只看召回率生成式召回上线之后评估体系也得跟着换。传统召回评估最常用的是RecallK意思是前K个召回结果里有多少相关商品。但生成式召回天然跟这套指标不太合拍模型输出的是一条路径映射出来的商品数量是不固定的你没法固定K。所以我们引入了“意图命中率”和“路径置信度”两个指标。意图命中率看的是模型生成的语义原子序列跟用户实际点击商品的标签序列有多大的重叠路径置信度看的是模型对这条路线的平均概率分数。这两个指标跟端到端效果的相关性比传统RecallK要更密切。当然最终业务方看的还是GMV、转化率、搜索UV价值这些硬指标。我们在AB实验里观察到的收益曲线很有意思主搜整体转化率是稳定上涨的但涨得最猛的是“多意图组合query”和“长尾query”这两类头部大词反而没有明显变化。比如“大码女鞋 显瘦 粗跟短靴”这种多重约束的query向量召回经常顾此失彼生成式召回因为直接解析出[女鞋][长靴/短靴][粗跟][大码]这些路径召回集合明显更紧凑转化率涨幅能到十几个百分点。这里要想清楚一个问题生成式召回不是拿来做“所有query统一提升”的它是拿来做“结构化意图query”的精确召回。如果AB实验里发现整体大盘没啥变化先别急着否定方案按query分组拆一下重点看那些信息量大、约束多的query那才是生成式召回的主战场。5. 那些年我踩过的坑5.1 束搜索的“尾部不置信”beam search在生成式召回里是最常用的解码方式但它有一个隐蔽问题序列越往后解码的可信度越低。前面的语义原子类目、品牌往往高度确定后面的属性词比如“情侣款”“加绒”“2024新款”分布非常散模型在尾部经常摇摆不定。后果就是生成的序列前半部分是对的后半部分开始“胡诌”映射出来的商品池自然偏离用户意图。我们的解决办法是“分位置信度惩罚”在beam search打分时对序列尾部的Token做额外衰减宁愿让它提前结束也不要瞎补全。另外一个手段是“两段式生成”第一段生成[类目][品牌][系列]这类粗粒度原子第二段根据第一段的结果再生成属性细节。两段之间加一层候选过滤属性细节填充时只能从第一段确定类目下的合法属性里选这样能显著减少尾部乱飞的情况。这两个手段组合起来线上生成路径的有效率从80%出头提上了90%以上。5.2 一致性分裂生成结果和向量召回各说各话这是多路召回架构里的老问题但在生成式召回接入后会被放大。因为我们保留了向量召回作为兜底所以同一个query会同时产出“生成式路径命中的商品”和“向量相似的商品”这两批商品重叠度往往很低。重叠低不是问题问题是两路召回的后续粗排打分尺度不统一有些商品明明在生成式召回里质量很高进了粗排反而被压下去了因为粗排的输入特征是为向量召回的“候选近似度”设计的跟生成式召回的“意图路径置信度”不是一个语义空间。我们解决这个问题做了一次“特征对齐改造”在粗排特征里把生成式召回的路径置信度、意图命中率、合法路径深度这三个新特征显式加进去并给粗排模型做了针对生成式召回样本的微调。改造之后两路召回的候选在粗排层终于有了统一的话语体系。这件事给我的教训是引入一种新的召回范式不只是召回层的事整条搜索链路都得跟着适配跳过这个环节端到端效果一定打折扣。5.3 什么时候别上生成式召回说到最后我反而想说点泼冷水的话。生成式召回不是什么场景都适用至少这三类情况我不建议硬上。第一候选商品池太小、太稳定的场景。如果全站商品只有几千个倒排加规则就已经能精确召回生成式模型是杀鸡用牛刀效果还不一定比规则好。第二query本身没有结构化意图的场景。比如闲逛型搜索用户搜“好看的衣服”里面没有品牌、类目、属性任何一个强约束生成式模型学不出稳定路径这时候向量召回反而更合适。第三知识库基础一塌糊涂的场景。前面说过生成式召回极度依赖类目体系、品牌库、商品标签的规范程度如果连叶子类目都还没定义清楚、商品标签缺失率达到三成以上先别碰生成式。我在实际项目里的判断标准很简单先跑一周日志分析算一算有多少比例的搜索query包含两个以上的“可提取的语义原子”。如果这个比例低于30%说明你家的用户搜索习惯还偏模糊生成式召回投入产出比不会好看如果超过50%那这就是一个非常值得投入的方向。这个测试不用跑模型纯规则抽取就能算个八九不离十花不了半天功夫但能帮你避免一个动辄几个月的大项目踩空。最后再分享一个小观察搜索技术这个赛道很多人喜欢追着新概念跑但真正在线上创造价值的往往是把一个概念吃透、针对业务场景做取舍的团队。向量检索是这样过来的生成式召回也会是这样过来的。你不需要在每一波技术浪潮里都当第一个冲浪的人你需要的是判断这一波浪到底适不适合自己的海域。