1. 当“搜不准”成为交易搜索的瓶颈问题到底出在哪做电商搜索的人大概都有过这种体验用户搜“适合小个子的显瘦牛仔裤”传统向量检索返回的结果里前几条可能是“牛仔裤男直筒宽松”“牛仔裤女高腰”“小个子连衣裙”。字面上看每个词都沾点边但用户真正想要的那件商品可能排在第三页。这不是向量模型不够强而是召回阶段的信息损耗在作祟。得物交易搜索面临的场景更极端。商品标题短、属性多、用户 query 口语化严重还夹杂大量品牌缩写、型号黑话、场景描述。比如“aj1 低帮 北卡蓝 女码”“通勤能装的托特包 不塌”“送男朋友 2000 以内 手表”。这些 query 背后是明确的交易意图但传统“query 编码 → 向量相似度 → topK”的链路在第一步就把大量语义压进了一个固定维度的向量里。维度就那么多信息密度再高也装不下“品牌型号颜色性别价格场景”这六个维度的联合约束。更麻烦的是交易搜索对召回率的容忍度极低。内容搜索漏掉一篇还可以接受交易搜索漏掉一个 SPU用户可能直接跳失。得物团队在公开分享中提到过一个数据召回阶段每提升 1% 的命中率下游转化率有可观测的正向波动。这就是为什么“只卷向量检索”越来越卷不动了——向量模型再精调也解决不了“信息在编码阶段就被压缩”这个结构性问题。生成式召回的出现本质上是把“压缩后再匹配”换成了“理解后再生成”。大语言模型不急着把 query 压成一个点而是先读懂用户到底要什么再直接生成可能命中的商品标识或属性组合。这个范式跃迁的核心不是模型变大而是召回逻辑从“相似度排序”变成了“意图到商品的直接映射”。2. 生成式召回到底“生成”了什么从向量点到商品集合的映射2.1 传统向量召回的三个硬伤先把传统链路拆开看。Query 经过 tokenizer 变成 token 序列再过 encoder 变成固定维度向量然后和商品库的向量做 ANN 检索。这里有三处信息损耗第一query 侧的信息压缩。一个 20 字的 query经过 BERT 类模型编码后CLS 向量只有 768 维。这 768 个浮点数要同时表达品类、品牌、属性、场景、价格区间平均每个维度承载的信息量极低。遇到“不要纯棉的 要那种滑滑的 夏天穿”这种否定材质季节的复合意图向量根本区分不开“纯棉”和“不要纯棉”。第二商品侧的表征偏差。商品向量通常由标题属性图片多模态融合而来但融合权重是离线固定的。一个卖点是“限量配色”的球鞋和一个卖点是“透气网面”的跑鞋如果标题长度相近它们的向量在空间里的距离可能比实际语义距离更近。第三相似度度量的刚性。余弦相似度只关心方向不关心“哪个维度更重要”。用户搜“2000 以内”价格维度应该是硬约束但在向量空间里它只是 768 维中的几维很容易被其他语义维度淹没。2.2 生成式召回的“生成”对象是什么得物交易搜索的生成式召回并不是让 LLM 直接生成商品 ID 列表——那样既不可控也不可扩展。它生成的是结构化的召回意图表示我把它拆成三层属性槽位填充LLM 把 query 解析成{品类: 牛仔裤, 性别: 女, 版型: 显瘦, 身高: 小个子, 风格: 通勤}这样的槽位。每个槽位对应倒排索引里的一个字段直接走精确匹配或范围匹配。商品标题生成对于槽位无法覆盖的长尾意图LLM 生成若干条“理想商品标题”再用这些标题去和商品库做轻量级匹配。这相当于用生成模型“翻译”了用户的模糊表达。多路召回路由LLM 判断这个 query 应该走哪几条召回通道——是走属性倒排、还是走向量、还是走品牌型号精确匹配。路由决策本身也是生成出来的。注意这里的“生成”不是自由文本生成而是受约束的、面向召回的结构化生成。LLM 的输出会被解析器校验槽位必须落在预定义的 schema 内生成的标题必须通过品类分类器验证。2.3 为什么是“范式跃迁”而不是“增量优化”向量检索的优化路径是换更强的 encoder、加更多训练数据、调 ANN 参数、做多向量融合。这些都是在“压缩-匹配”框架内做文章。生成式召回换了一个框架先理解再映射最后匹配。理解阶段用 LLM 的语义解析能力映射阶段用结构化生成能力匹配阶段才回到传统检索。这个顺序变化带来的最大好处是召回率的上限不再受向量维度限制。一个 query 可以生成 50 个槽位组合、20 条候选标题、3 条召回路由信息量远超一个 768 维向量。而且每个槽位和标题都是可解释的运营可以干预badcase 可以归因。3. 得物交易搜索的生成式召回链路拆解3.1 Query 理解层LLM 做槽位解析与意图分类得物的 query 有一个显著特点短、碎、黑话多。比如“dunk 熊猫 女 36”“北面 1996 黑”“ccd 相机 学生”。传统 NER 模型在这些 query 上表现不稳定因为很多黑话不在训练集里。LLM 的 few-shot 能力在这里很关键——给几个示例它就能把“dunk 熊猫”解析成{品牌: Nike, 系列: Dunk, 配色: 熊猫}。实际落地时他们用的是小参数 LLM 领域微调的方案。原因很直接交易搜索的 QPS 很高用百亿参数模型做在线推理算力成本扛不住。微调数据来自历史点击日志和人工标注的 query-槽位对规模在百万级。微调后的模型在槽位解析任务上F1 比通用 LLM 高出一截推理延迟控制在 20ms 以内。槽位 schema 的设计也有讲究。得物把商品属性分成硬属性和软属性硬属性包括品牌、型号、品类、性别、尺码这些必须精确匹配软属性包括风格、场景、材质偏好这些可以走向量或文本匹配。LLM 解析时硬属性槽位置信度阈值设得很高宁可漏填也不填错软属性则允许模糊填充。3.2 生成层从槽位到多路召回 query 的构造槽位解析完下一步是生成召回 query。这里不是简单地把槽位拼成布尔查询而是生成多路异构召回请求。得物的做法是倒排路硬属性槽位直接构造倒排索引查询。比如{品牌: Nike, 系列: Dunk, 性别: 女, 尺码: 36}会生成一条精确匹配请求命中商品库中同时满足这四个条件的 SPU。向量路软属性槽位和原始 query 拼接后生成一条向量检索请求。比如“显瘦 小个子 通勤”会编码成向量去和商品的多模态向量做 ANN。生成标题路对于槽位覆盖不全的 queryLLM 生成 3-5 条“理想商品标题”每条标题走一次轻量级文本匹配。比如“适合小个子的显瘦牛仔裤”可能生成“高腰显瘦九分牛仔裤 小个子”“弹力修身小脚牛仔裤 女 小个子”“垂感直筒牛仔裤 显瘦 小个子通勤”。多模态路如果 query 包含视觉描述“那种滑滑的面料”“和图片同款”LLM 会触发多模态召回通道用 CLIP 类模型做图搜或文搜图。这四路召回并行执行每路返回 topN最后做融合排序。融合不是简单加权而是按召回路的置信度动态调权。倒排路的置信度最高因为硬属性匹配是确定的生成标题路的置信度取决于 LLM 的生成质量通常设得较低但覆盖面广。3.3 融合与去重多路召回结果的合并策略多路召回的结果合并得物用的是分层去重 动态配额。先去重同一个 SPU 被多路召回命中只保留一次但记录命中路数。命中路数越多说明这个商品和 query 的相关性越强在后续排序中会获得加权。动态配额是指每一路召回的 topN 不是固定的而是根据 query 类型动态调整。比如品牌型号类 query倒排路配额给到 80%向量路只给 20%而场景描述类 query生成标题路和向量路各给 40%倒排路只给 20%。这个配额策略是离线用强化学习调出来的目标函数是最终成交转化率。实操心得多路召回的融合阶段最容易出问题的是“热门商品霸屏”。某个爆款 SPU 可能同时被倒排、向量、生成标题三路命中如果不去重和配额控制它会挤掉其他潜在相关商品。得物的做法是给每个 SPU 设一个“跨路命中上限”超过上限后降权。3.4 在线服务架构延迟与算力的平衡生成式召回的在线链路比传统向量检索长延迟压力大。得物的架构做了几件事来压延迟LLM 推理异步化槽位解析和标题生成不在主链路同步等待而是异步触发先返回倒排路和向量路的结果生成路的结果后到后补。缓存复用高频 query 的槽位解析结果和生成标题会缓存TTL 设得很短分钟级因为交易搜索的 query 分布变化快。模型蒸馏在线用的 LLM 是蒸馏后的小模型参数量控制在十亿以内用 TensorRT 加速单次推理延迟压到 15ms 以下。降级策略如果 LLM 服务超时或不可用自动降级到纯向量倒排的兜底链路保证可用性。这套架构的算力成本比纯向量检索高但得物团队算过一笔账召回率提升带来的 GMV 增量覆盖了额外的算力开销。这也是交易搜索和内容搜索的区别——交易搜索的 ROI 可以直接用成交额衡量。4. 落地过程中绕不开的四个坑4.1 槽位 schema 的粒度怎么定太粗LLM 解析不出有用信息太细解析准确率下降而且倒排索引维护成本高。得物踩过的坑是一开始把“风格”槽位拆成 20 多个子类结果 LLM 在“通勤”和“职场”之间反复摇摆解析 F1 掉了 8 个点。后来合并成 5 个大类准确率回升召回效果反而更好。我的经验是槽位粒度应该由倒排索引的字段粒度决定而不是由业务语义的精细度决定。倒排索引里没有“通勤风”这个字段那槽位就不该拆到那么细。得物最终的 schema 是 12 个硬属性槽位 8 个软属性槽位覆盖了 95% 以上的 query 意图。4.2 生成标题的“幻觉”怎么控LLM 生成的商品标题可能包含商品库里根本不存在的属性组合比如生成“羊绒牛仔裤”——羊绒和牛仔裤在得物商品库里几乎没有交集。这种幻觉标题会导致召回为空浪费算力。控制手段有三层第一生成时用 constrained decoding限制 token 只能来自商品库的高频词表第二生成后用品类分类器校验标题的品类预测必须和 query 的品类槽位一致第三召回为空时记录 badcase定期回流到微调数据里。得物上线初期生成标题的幻觉率在 15% 左右经过三轮迭代降到了 3% 以下。4.3 多路召回的“路数爆炸”一开始他们设计了 7 路召回结果融合阶段的计算量翻了 3 倍延迟超标。后来砍到 4 路把“品牌精确匹配”合并进倒排路把“图搜”合并进多模态路。路数不是越多越好每增加一路融合排序的复杂度就指数上升。4 路是一个比较平衡的点倒排、向量、生成标题、多模态覆盖了交易搜索的主要意图类型。4.4 离线评估和在线效果的 gap离线用 recallK 评估生成式召回比纯向量高 12 个点但上线后在线 A/B 只涨了 3 个点。排查发现离线评估用的 query 集是随机采样的而在线流量里高频 query 占比很高这些高频 query 的槽位解析已经被缓存优化过提升空间本来就小。后来他们改成按 query 频次分层评估低频 query 看召回率高频 query 看延迟和转化率离线在线 gap 才收窄到 2 个点以内。5. 生成式召回之后交易搜索还能往哪走得物这套方案跑通后最直接的扩展方向是生成式排序。召回阶段已经拿到了结构化的槽位和生成标题排序阶段可以复用这些信号做更细粒度的相关性打分。比如“显瘦”这个软属性在召回阶段只是触发向量路在排序阶段可以用 LLM 判断商品标题里的“显瘦”描述和 query 里的“显瘦”是不是同一个语义——是“版型显瘦”还是“颜色显瘦”。另一个方向是多模态召回的深度融合。目前多模态路还是独立的CLIP 向量和文本向量在融合阶段才汇合。下一步可以把商品的主图、标题、属性在编码阶段就做统一的多模态表征让生成式召回直接生成“视觉文本”的联合 query。得物商品图的质量很高这个方向的收益空间很大。还有一个容易被忽略的点生成式召回的可解释性可以反哺运营。每个 query 的槽位解析结果和生成标题都是可读的运营可以据此调整商品标题、补充属性、优化类目。这比向量检索的黑盒匹配多了一个人工干预的抓手。得物内部已经在用这套信号做商品信息质量分标题里缺失高频槽位的商品会被降权。最后说一个我自己的判断生成式召回不是要取代向量检索而是把向量检索从“唯一召回源”降级为“多路召回中的一路”。向量检索在语义泛化上依然有优势但交易搜索的硬约束太多单靠向量扛不住。得物的实践验证了这一点——四路召回里向量路的贡献占比从原来的 100% 降到了 35% 左右但整体召回率翻了一倍多。这个账做交易搜索的人都算得明白。