别再只卷向量检索了得物交易搜索如何用“生成式”实现召回范式跃迁从向量检索到生成式召回这篇聊聊我们团队在得物交易搜索场景里做的一次范式升级。如果你也在做搜索、做推荐、做召回平时刷了不少向量检索的技术文章大概率会有这种感觉向量召回确实好用但把它当万能药的时候性能和人力成本都在偷偷吃掉你的收益。尤其是电商交易搜索这种 query 又短又杂、用户意图又高度依赖场景的领域纯向量那条路越往后走越觉得天花板就在头顶。这篇文章不聊虚的直接讲清楚我们为什么决定不再把所有资源砸进向量召回而是用“生成式”的思路重构了整个召回链路回答了三个问题向量检索到底卡在哪了生成式召回和它本质区别是什么落地到交易搜索这个场景具体怎么做、效果如何、踩了哪些坑内容会涉及范式原理解析、模型选型、训练数据处理、推理链路设计和评测对比读完你可以直接判断这套思路能不能迁移到自己的业务里。1. 向量检索的天花板明明在算相似度为什么丢了真实需求先说一个核心观点向量检索的本质是“相似度匹配”它的强项是在已有候选池里找出最相似的但这个前提本身在电商搜索里就是个大漏洞——你的候选池是按什么逻辑进来的如果第一关就没把用户真实想要的商品放进来后面向量模型算得再准也是白搭。1.1 用户搜索意图的解析其实一直没解决电商交易搜索和通用搜索有一个非常明显的差异用户query极短且大量query不是标准的“类目词属性词”结构。比如在得物App上用户搜“过年送男友”“夜跑穿搭”“通勤不撞包”这类query的频率相当高。这类query有一个共同点它们不是对某一个具体商品的描述而是对一种场景、一种人群、一种需求的描述。向量检索处理这类query时天然要面对一个尴尬局面用一个不足十个字的短query去嵌入成向量在整个商品向量空间里做最近邻搜索模型必须靠仅有的几个token去猜用户的深层意图。这中间的信息缺口太大了。语义向量再强也架不住“信息输入就不完整”这个结构性限制。你可以把向量检索想象成一个夜店门口的酒保他见过很多客人能认出熟客的脸但当一个新客人只说了一句“今天心情不错”他很难判断这位客人到底是想喝烈的还是想喝甜的。向量检索本质上就是这类“看脸认人”的机制——有过近似表达、有过对应的交互行为它才能召回得准。1.2 向量召回在交易搜索里的三项结构性短板把问题收敛到交易搜索这个具体场景里向量检索的短板其实可以归纳成三项每项都很致命。第一项是可用向量空间的维度限制。做向量召回的人都有经验embedding维度太高检索性能下降维度太低语义表达力不够。无论怎么调总是在表达力和性能之间做折中。而且商品的向量一旦训练完成就基本固化了如果这个商品是过季款、新品、或者只有极少交互行为的冷门商品它的向量质量极差几乎等于在向量空间里随机撒了一个点。第二项是query端和doc端的信息不对称。用户query侧的向量来自外部的用户输入doc侧的向量来自商品标题、品牌、属性等结构化字段的语义编码。两个方向缺乏一个共享的高层意图表示。用户的口语化表达和商品的标准品类描述之间存在巨大的“语言鸿沟”。向量模型理论上可以拉近它们但实际上需要的是海量的、高质量的“query→商品”训练样本而这类样本在交易搜索里天然稀缺。第三项也是最容易被忽视的一项向量检索只是匹配不是推理。用户搜“过年送男友”这个query背后隐含的是“礼赠场景男性偏好中高价位段品牌认知度”这样一组复合条件。向量检索最多能做到把“过年”“送”“男友”这几个词的语义向量叠在一起去找相似这套做法本质上是退化的它没有推理能力去把query拆解成一组子条件再组合成路召回条件。这三点叠加在一起就构成了交易搜索向量召回的天花板。传统多路召回文本匹配、倒排索引、类目id召回、品牌召回解决的是其中一部分问题但当query越来越口语化、越来越场景化多路召回的规则维护成本就会指数上涨。搜“过年送男友”你到底出几路出哪几路每路的权重怎么配这条路也会越走越重。2. 生成式召回的范式逻辑把“找相似”变成“做推断”既然检索式召回包括向量检索的路有天花板那换个思路不“找”了直接“生成”。这不是一句口号而是一个可以实现的工程方案。2.1 从候选池检索到候选集生成传统召回的逻辑是我有一整个商品池子要通过某个手段从池子里捞出一批候选。候选池越大、索引结构越复杂检索的天花板就越明显。生成式召回的思路完全反过来我不假设有一个完整的候选池需要去遍历而是让模型学会“根据用户query直接生成最终的候选结果”。在工业级搜索引擎里这种召回方式被称为生成式检索Generative Retrieval。拿得物交易搜索来举例用户搜“通勤不撞包”传统向量召回的做法是把query向量化然后去商品向量库里做最近邻。生成式召回的做法是先让模型把query“翻译”成一组可执行的召回指令比如类目锁定箱包皮具-女士单肩包/斜挎包风格属性极简、百搭、轻奢感价格带约束800-3000元品牌白名单可选但非必须然后基于这组指令去执行一次结构化召回和语义召回的组合查询。注意这里模型做的是“推断用户想要什么”而不是“猜测哪件商品长得像这个query”。2.2 和向量检索的本质区别匹配关系 vs 生成关系更数学化地讲向量检索学习的是一个匹配函数 f(query, doc)——把两个对象映射进一个向量空间用距离表示相关度。生成式召回学习的是一个条件概率分布 P(retrieval_target | query)其中retrieval_target不仅可以是商品ID也可以是类目、属性、品牌、场景标签甚至是最终商品集合的索引表示。这个区别在企业级业务里有着非常实际的影响。匹配关系决定了你只能获得“相似的东西”生成关系让你能获得“合理的东西”。用户在query里表达的是潜在需求合理的候选集很可能在字面上和query没有任何交集。比如“过年送男友”和某款男士机械腕表之间没有字符级别重叠但在意图层面高度相关。向量模型理论上希望通过语义向量拉近两者的距离但实际操作中因为train和inference时数据分布会偏这个拉近效果非常有限。生成式模型直接跨过“语义相似”这道中介从query直接预测意图标签再基于标签体系建设候选集从源头解决匹配断层。2.3 为什么向量库不能直接覆盖这个需求顺着这个逻辑说回“知识库、向量库检索需要什么数据库”这个热门问题。在过去两年做交易搜索的基础设施时我们确实把大量精力花在向量库的选型和优化上试过专门的向量数据库也试过在关系型数据库上挂向量索引插件。效果最好的时候线上召回延迟能压到10ms以内但接着就发现一个本质问题向量库只是存储和计算的载体它不产生“意图”。向量库里存的向量怎么来训练出来的。训练数据哪里来标注加日志挖掘。到头来准确率的天花板取决于训练好的向量质量而向量质量的上限由“已有匹配样本的丰富度”决定这是一个死循环。生成式召回并没有完全抛弃向量库恰恰相反它会大量使用向量库作为中间结果的存储和召回介质。但在这个范式里向量库不再是“唯一的智能来源”它退化成一块高性能索引板负责执行来自上游意图解析模块下发的“紧凑向量条件查询”。知识库在生成式召回里承担的是“意图标签约束”的作用确保模型不会生成出不符合业务逻辑的召回条件。3. 实际落地从Query解析到候选集生成的全链路实现理论讲完重点说一下我们在得物交易搜索上实际怎么落地的。整个链路分两大块离线部分负责训练意图理解和生成模型在线部分负责执行生成指令并完成候选召回。3.1 训练数据构造如何把搜索日志变成生成模型的燃料生成式召回对训练数据的要求比向量模型高一个量级。向量模型有不那么完美的样本也能训练起来因为匹配信号可以来自曝光点击等弱标签生成式模型不一样它需要的是精确的“query→意图标签组合→正反馈商品”的结构化样本。我们的做法是先把搜索日志里的query按类型做了一套体系化分类类目查询型搜“篮球鞋”“羽绒服”“手链”属性查询型搜“防水冲锋衣”“老爹鞋复古”场景查询型搜“过年送男友”“日常上学通勤包”泛需求查询型搜“百搭”“显瘦”“性价比”前两种query用传统NLP手段就能抽取标签难度不大。真正有价值的训练样本集中在后两种。我们做了一个多级标注和挖掘管线第一级是用户行为挖掘。如果一个query在搜索后用户产生超过一定数量的点击行为我们就统计这些点击商品在类目、价格带、品牌、风格标签上的分布用统计分布特征生成候选意图。比如搜“通勤不撞包”的用户点击了大量单肩包和斜挎包价格集中在700到2500之间风格集中在简约和轻奢那这条query的意图标签就自动生成。第二级是人工审核修正。自动生成标签的准确率大概在八成左右剩下两成存在明显偏差比如用户搜“通勤”结果点了很多水桶包从统计上是显性的但人工看过后会发现水桶包和通勤相关性并不强样本里就有干扰需要人工标注剔除。第三级是引入外部知识库做约束。我们在标签生成过程中引入了自建的电商知识图谱里面包含类目树、属性库、品牌关系、风格标签体系。生成模型输出的意图标签必须能在知识图谱中找到对应节点否则会被判定为非法输出并丢弃。这一步在推理阶段同样启用作为幻觉防护网。最终我们拿到了约500万条“query→意图标签组合”的训练样本覆盖了得物主要的交易类目和用户的典型搜索需求。3.2 生成模型选型不是越大越好是够用且好控很多人一听“生成式召回”第一反应是上一个大语言模型。但说实话在召回链路这个位置直接上一两百B参数的LLM是不现实的延迟和成本都扛不住。我们最终选型的是一个参数量在100M到300M量级的轻量序列生成模型基于Transformer架构做编码器-解码器设计输入是query的token序列输出是一组结构化的意图标签序列。这个模型的训练目标不是生成人类可读的语句而是生成机器可执行的指令串格式大概是[CLS] 通勤不撞包 [SEP] 类目:女士单肩包, 女士斜挎包 | 属性:极简, 百搭 | 价格带:800-3000 | 场景:通勤, 日常格式很简单但设计上有一个关键细节所有标签必须来源自固定的知识库词汇表模型输出层做了一层受限解码constrained decoding每一步生成的时候只允许在“当前类目下合法属性集合”里选词。这个约束直接把幻觉问题削掉了大半模型不可能生成“女士高跟鞋”出现在“通勤不撞包”的类目组合里这样的荒唐结果。离线评测的时候我们对比过三个方案直接用生活中的大语言模型API做prompt解析、训练一个序列到序列模型做受限生成、以及基于检索的标签检索方案。效果上大语言模型API的意图解析full体现得最全面但延迟不稳定、成本高、输出延迟还是概率性的受限生成的序列模型在支持的业务意图集合内精确率和召回率都达到并略超过大模型API的水平延迟稳定控制在5ms以内适合放在在线链路上。3.3 在线推理链路生成、校验、召回三道闸门在线部分的设计原则是“宁可慢两毫秒不可错一路”。完整链路分为四个节点第一个节点是意图生成。用户进入搜索后query先经过一个轻量意图分诊器判断这条query走传统文本召回、向量召回还是生成式召回。分诊器本身就是一个二分类模型训练数据来自对历史query的标注。流量分层以后大约有35%的query会命中生成式召回路径其余的还是走原链路降低上线风险。第二个节点是生成校验。命中生成式的query送入序列生成模型输出候选意图标签组合。这里的校验分为两层第一层是知识库合法性校验看标签关系是否合法第二层是上下文时效校验比如用户之前浏览过什么类目标签和当前session的品类偏好冲突过大会被降权。第三个节点是候选集执行。生成出来的标签组合会被翻译成多路召回查询结构化条件类目属性价格带直接走倒排索引向量条件生成式模型输出的“意图向量”即意图标签组合的embedding去向量库做有限范围检索知识库关系扩展场景标签可以映射到品牌和类目集合同步走标签召回这个节点和传统多路召回最大的差异在于传统多路召回的路由规则是运营和算法人工配置的生成式模型的路由规则是自己生成的业务需求变更时只需要更新模型的训练数据和知识库不用重写一堆判断逻辑。第四个节点是融合器。这个融合器不是简单的加权融合它会把生成式模型的意图标签和历史行为数据做交叉对候选集做一次统一的预排序。预排序分数会传给下游粗排模型如果生成式召回的候选集覆盖了某个未曝光过的新品类融合器会看session内用户行为信号决定是给机会还是压一压。整个在线链路的端到端延迟增加了大约8到12ms对一个电商搜索场景来说在可接受范围内。但换来的是一个非常大的能力跃迁搜索引擎第一次有条件把“用户真正想要什么”这个推理过程本身变成可在线执行的模块。3.4 知识库和向量库在链路中的分工回到方前提到的基础设施选型问题。生成式召回落地时我们对原有技术架构做了一次不小的调整其中最核心的一点就是明确知识库和向量库的职责边界。向量库在这套链路里承担的是一个降维检索的角色。意图标签组合生成后我们把组合映射成若干语义向量去向量库里找相关的商品和内容。这个场景下向量库只需要做到两点单次检索快、支持按条件过滤比如按类目id、价格带做预过滤。实测下来我们用的向量库在这两个条件上基本都能满足但注意它不再承担“语义理解”的职责语义理解已经在上游的生成式模型里完成。知识库则是整个生成式召回的地基。我们自建了一套交易场景的电商实体知识库包含类目层级、属性关系、品牌库、风格体系、场景词库。这套知识库由专门的规则团队和维护每周都会有更新。所有的知识都冻结成结构化schema生成式模型训练和推理共用这一份schema。这样做的好处是想更新召回逻辑不需要重训模型只要更新schema和对应的标签词汇表模型生成时受限解码的合法集自动变化。选型数据库的时候我们并没有刻意追求一种“数据库解决一切”的即视感。知识的存储直接用关系型数据库加缓存通常用HotDB或原生的阿里云RDS-like方案就可以标签倒排索引用Elasticsearch就能抗住向量部分单独用专门的向量检索服务。每个组件做自己最擅长的事链路清晰出问题也好排查。4. 收益评估与对比哪些Query吃到了红利哪些地方翻车了新范式上线不是自嗨要把收益讲清楚。我们在得物交易搜索上做了一个月的灰度对比实验对照组是全量走老链路文本召回向量召回多路融合实验组是将约35%的query切到生成式召回的混合链路。4.1 核心指标对比长尾Query的提升幅度远超预期实验组整体效果最好的还不是那些被看好的复杂场景query而是一群之前完全无法被召回的“长尾口语化query”。这里贴一组我们实际观察到的数据“过年送男友”召回命中率提升19.7%搜索转化率提升11.3%“夜跑穿搭”召回命中率提升23.4%加购率提升8.6%“通勤不撞包”点击率提升16.8%搜索后有样式的浏览深度提升12.1%这些query的共同特征是没有明确的类目词也没有品牌词纯场景口语表达。老链路里它们要么走向量召回但向量模型被这类query逼近死角要么走文本匹配基本只能返回一个宽泛的匹配结果。生成式召回从意图推断出发能拆解出这些query背后的结构性标签组合再用标签组合做精确召回效果自然不同。更意外的是一组偏“泛需求”的query也得到了不错的提升。比如“百搭”“小众”“显瘦”这类query以前在排序阶段很容易被淹没因为召回出来的品类太杂。生成式模型会把“百搭”进一步拆解成“基础色系风格适配度高出街百搭”配合知识库里风格属性的映射候选结果一下子聚焦了很多用户搜索体验明显改善。4.2 边界场景复盘哪些query不适合走生成式不是所有query都适合生成式召回这一点我们早期吃了不少亏。复盘下来有三类query不适合或者需要设计专门的旁路处理。第一类是极其明确的商品型号或SKU级搜索比如直接搜索某个商品的货号。这类query不存在意图理解的空间意图是明确且唯一的走精确匹配即可用生成式召回反而画蛇添足增加延迟。第二类是品牌词的泛搜索。比如搜“耐克”这时候用户Ta想要的不是帮我推断什么风格最适合我而是一个完整的品牌ok产品列表。生成式模型如果非要对这个query做意图标签拆解生成结果往往会过度限定反而丢失品牌下的长尾商品。第三类是词义高度模糊的query比如“小王子”。既可能是书籍、也可能是联名款服装、还可能是文创周边。生成式模型会依据知识库标签输出一个大概率意图而这个概率判断一旦错了整个候选集就是歪的。这类query我们设计了一个旁路策略生成式和向量检索并行跑融合时按用户历史行为偏好加权不直接二选一。4.3 翻车案例一次数据污染教我们重新做人上线过程中遇到过最典型的翻车事件是“场景词库污染”。当时运营团队在知识库里批量导入了一批“新年礼物”场景词覆盖了非常广的品类包括美妆、数码、潮流服饰、黄金珠宝。结果上线之后搜“新年礼物”的用户大量看到了黄金饰品但从业务数据来看黄金饰品在得物的购买决策链非常长很多用户点击后并不转化导致转化指标一度下滑。复盘发现根因在训练数据我们用了用户点击行为作为意图挖掘的第一信号而“新年礼物”这个query下用户的点击分布非常广模型学习到了“这也要那也要”的意图标签组合生成结果是全品类都要丢失了聚焦性。修复方案是对意图标签组合设定一个卡控逻辑一组标签组合覆盖的类目如果超过三个自动降级为只保留权重最高的两个类目。这相当于给生成式模型加了一条“聚焦性约束”的预防规则。修复后这类泛场景query的效果反而比之前更好因为用户搜“新年礼物”本质上是愿意浏览的但你不能让Ta同时看到所有东西适度收敛反而提升了决策效率。5.1 生成式并不是替代向量检索而是把向量检索装进了更大的坐标系写完方案和效果最后从我的视角做一个总结性对比。如果你问我对这套范式有多大信心我的答案是很坚定但我坚定推荐的不是某一个具体模型或者某一种检索架构而是这个思路本身——召回问题可以从“空间搜索”转换成“意图推断”。向量检索在生成的意图范围内继续发光发热但它不再是引擎而是引擎驱动下的一个传动轴。从团队的技术演进节奏来看生成式召回解决了向量检索的一个更深层次的问题召回不再是一次性的topK计算而是一条“理解-生成-执行-融合”的闭环链路。你可以在任意环节注入业务约束、时效约束和知识约束。相比以前在向量检索上反复调参、换模型、扩样本这套玩法显然是更有生命力的。如果大家也想在业务里尝试这套范式我建议的切入路径是先从覆盖最少的老链路召回稀烂的场景query开始把它们从路径中剥离出来单独走生成式召回跑通以后再看要不要扩大流量范围。不要一上来就把整体架构推翻。数据、约束、聚焦性这三个字是这套方案的护城河也是踩坑之后最深刻的体会。