两年前我们团队做召回方案评审的时候听到最多的一句话就是“再加一路向量召回吧”。那阵子整个圈子都在卷embedding、双塔、ANN索引得物交易搜索自然也顺着主流做了不少向量化改造效果确实有提升。但越往后越明显向量检索解决的只是“看起来相似”解决不了“理解得透”。得物这个交易场景比较特殊用户搜索词和商品文本之间隔着大量网络黑话、型号别称、联名梗比如搜“倒钩”其实要的是AJ1倒钩球鞋搜“熊猫”要的是Dunk熊猫配色搜“小闪电”要知道指的是Air Jordan 1的特定配色。这些词在商品标题里通常根本不存在纯靠语义表示去逼近天花板很低。所以去年开始我们把重心从向量检索挪开试着让生成式模型直接参与召回让系统先“读懂”用户这句话再自动构造候选集。这篇文章就把我们在得物交易搜索里做生成式召回的思路、落地和踩坑过程完整梳理一遍给还在拼命堆向量路数的团队一个参考。1. 得物交易搜索的召回困境向量检索卷不动的那部分1.1 交易搜索的“黑话”问题得物是一个潮玩和潮流服饰的交易平台商品以限量球鞋、服饰、潮玩为主。这类商品有一个共同特点用户怎么叫它和商品文档怎么写它经常是两套语言。商品标题通常由运营和商家维护走的是相对规范的写法比如“Nike Air Jordan 1 Retro High OG 复刻 篮球鞋”。“但用户搜索时不会这么说话圈子里的人会说‘倒钩’‘熊猫’‘小闪电’‘大魔王’‘黑脚趾’这些都是用户的自然语言也是交易搜索里最典型的‘黑话’。如果系统只会拿query去商品标题里做字面匹配甚至只会拿query的embedding去商品embedding里做相似度计算很大概率找不回这些词对应的商品。这就是交易搜索和通用搜索的本质区别通用搜索里用户搜“苹果”意图可能模棱两可但交易搜索里用户搜“倒钩”他脑子里的目标是非常清晰的一双鞋。检索系统要面对的不是“理解个大概”而是“精确理解到具体商品属性级别”。这种语义gap小则让召回结果不准大则直接导致无结果。1.2 向量检索擅长什么解决不了什么向量检索能在过去几年成为主流是因为它确实解决了字面匹配解决不了的问题同义改写、跨语言、上下位概念。比如用户搜“跑步鞋”商品标题里写的是“运动鞋”字面匹配可能漏掉但向量表示能把两个句子拉近。但在得物交易搜索里向量检索有几个绕不开的短板精确属性表达困难。用户搜“AJ1 44码”这里的“44码”是硬约束。embedding做的是“整体的相似性”它很难把“尺码必须等于44”这种精确条件在向量空间里完整表达出来最后还是得靠属性过滤。交易意图建模薄弱。搜“倒钩 值得买吗”和搜“倒钩 全新”用户意图完全不一样一个偏评测比价一个偏交易购买但embedding很可能把它们编码成很接近的表示因为字面太相似了。新词和热点词冷启动慢。一个梗要在社交媒体上发酵一阵子才会出现在商品标题里模型训练数据里更是没有。等向量模型能表征它的时候热点已经过去了。组合条件很难一次表达。“求一双灰色的Aj1倒钩40-42码价格2000以内”这种多个槽位的组合查询在向量检索里基本只能退化成多路召回后再做精排召回阶段经常顾此失彼。我做了一张对比表方便大家直观感受向量检索在交易搜索里的能力边界查询类型典型query字面匹配向量检索实际效果黑话昵称“熊猫”差中容易召回到熊猫玩偶等无关商品精确属性“AJ1 44码”中中需要靠过滤兜底向量本身表达不了组合意图“灰色倒钩 两千内”差差多条件相互干扰召回分散热点新词“新出的xx联名”差差模型没学过表示质量极差1.3 “多路召回”堆砌的收益递减向量检索有短板大家自然想到的就是多路召回文本一路、向量一路、swing这种行为序列一路、热销榜一路各路召回再合并去重喂给粗排精排。我们团队很早期就把这套体系搭起来了路数从最初的五六路涨到接近二十路效果也确实是涨的。但越往后收益递减越明显。新增一路召回带来的增量候选越来越少反而引入三个问题重复率飙升。各路召回都在竞相召回热门商品合并后大量重复排序压力变大真实增量候选没多少。维护成本变高。每路都要保索引、调参、做监控接近二十路的规模光排查“某一路上线导致整体指标波动”就能把人耗干。长尾无结果问题依旧。多路召回本质上是同一思想的不同变体在既有商品集合里“找相似”。如果商品集合本身和用户query差距太大路数再多也是零相乘等于零。我们后来统计了一个数字新增的召回路对头部热门词基本没有增量对长尾query的召回率提升也极其有限。真正让效果起飞的场景往往不是多一路相似检索而是换一种完全不同的召回思路。这也是我们开始认真琢磨生成式召回的契机。2. 从“近似匹配”到“意图重构”生成式召回的思路转变2.1 一句话说清生成式召回是什么传统的召回链路无论做多少路本质都是同一个范式给定一个query在已有商品集合里找一个“和它最相似”的子集。区别只在于“相似”怎么定义有的用词频有的用向量距离有的用行为共现。生成式召回把这个问题重新定义了一遍先让模型根据query生成一个用户意图的结构化表达再基于这个表达去构造候选集。换句话说召回不再是被动的“找”而是主动的“重构”加“筛选”。打个比方传统召回是拿着一张小照片在人群里找对应的人照片不清晰或者对方换了衣服基本就找不到了生成式召回是先听目击者描述画出一张嫌疑画像再拿着画像去人群里比对。画像可能比原来的照片更抽象但它抓住了“关键属性”反而能覆盖更多外观变化。在我们的实践里生成式召回具体做了两件事意图画像生成把“倒钩 灰色 44 两千内”这种口语query解析成“品牌Air Jordan型号AJ1系列倒钩颜色灰色尺码44价格区间0-2000交易意图求购”的结构化画像。候选集重构拿着这份画像在商品索引里做精确的属性筛选和条件匹配生成一批候选。这套流程的本质是把“表示学习”的比拼转成了“意图理解知识运用”的比拼。后者能处理前者处理不了的精确条件和组合逻辑这是范式层面的一次变化。2.2 生成式模型在召回链路里能干哪些活围绕生成式召回我们在实验里发现LLM能承担好几类职责每类的技术难度和收益都不一样Query语义解析把raw query拆解成语义槽位识别类目、品牌、型号、颜色、尺码、价格段、交易意图。这是收益最大的一类也是后续所有动作的基础。黑话翻译和别名归一把“熊猫”归一为“Dunk Low Retro White Black”把“倒钩”归一为“AJ1 Reverse Swoosh”。这一步解决的是向量模型吃不动的新词、圈层词。属性补全用户可能只说了“灰水泥”模型可以根据商品知识库补全“Air Jordan 4 灰水泥配色”从而精确到具体SKU系列。候选描述生成让模型生成一段“理想商品描述”再用这段描述做伪文档检索。这种方式适合商品文档本身质量差、索引稀疏的场景。直接生成候选商品ID在上下文里塞入用户历史行为序列和热门商品ID让模型直接输出最可能的候选商品ID列表。这个方案更激进对模型能力和上下文窗口要求都高一些我们当成兜底和补充来用。需要说明的是这五类不是每一步都必须做。我们的实践里收益最稳定的是前两类即query解析和黑话归一。这两类做扎实了召回效果就能有明显提升后面三类属于锦上添花。2.3 为什么生成式能突破表示学习的上限理解了生成的几种方式再回到一个根本问题凭什么生成式能做到向量检索做不到的事我觉得有三点值得说。第一向量检索的边界由语料决定。一个query能不能被召回取决于query和商品文档的表示是否足够接近。如果“倒钩”这个词在商品标题里从来没出现过训练阶段也没在描述文本里和AJ1共同出现过太多次表示学习就很难把它俩拉近。而生成式模型预训练阶段读过的数据里包含大量社区讨论、社交媒体帖子、百科条目模型的“世界知识”天然覆盖了语言和商品之间的连接不需要显式依赖当前商品库里的文本。第二生成式可以做组合推理。向量检索的本质是整体相似度它很难同时满足“灰色且价格低于2000且尺码44”这种条件组合。LLM可以把这些条件显式解析出来再交给确定性的过滤和筛选逻辑去执行。一个负责“理解”一个负责“精确”组合起来上限远高于纯表示匹配。第三生成结果可解释、可控。向量召回出了错很难说清为什么这两个句子相似生成式召回至少能输出一个结构化的画像我们能检查是哪个槽位解析错了。上线排查时这种可解释性价值极高能省下大量定位问题的精力。3. 生成式召回落地的具体方案画像生成、候选构造与校验3.1 整体链路从query到商品画像我们在得物交易搜索里的生成式召回落地结构大致可以分成四层接入层接收搜索query同时带上用户的浏览和购买序列作为上下文。理解层LLM将query解析成结构化的商品画像输出为一份JSON。执行层基于画像中的类目、品牌、颜色、尺码、价格区间等字段向商品索引发起检索并对关键字段做条件过滤。兜底层生成结果未通过校验时降级到原有文本向量召回链路。核心的设计决策是LLM不直接生成候选商品而是生成中间的结构化画像再交给传统检索引擎执行筛选。这样做有两个好处一是避免模型幻觉直接污染候选集二是可以复用已经搭好的索引和检索基础设施不需要为生成式单独建一套存储和检索体系。画像的JSON结构我们是这么约定的{ semantic_slots: { category: [运动鞋], brand: [Nike], product_line: [Air Jordan 1], nickname: [倒钩, Reverse Swoosh], color: [灰色], size_range: [40, 41, 42], price_range: [0, 2000], condition: [全新, 二手] }, trade_intent: { type: buy, scene: 求购, premium: false }, confidence: 0.87 }这个JSON的设计花了我们不少时间。一开始字段定得太多模型输出不稳定后来收敛到十几个关键槽位稳定性和可用性都显著提升。经验是画像字段宁少勿多只留能给召回带来实际约束能力的字段那些对过滤没有帮助的槽位不要放进来。3.2 候选集构造的两种路径画像生成之后下一步是怎么从画像得到候选商品集。我们在工程上实现了两条路径互为补充。路径A是画像转检索条件。把JSON里的字段翻译成检索引擎里的查询语句。类目、品牌、系列、颜色做精确匹配或倒排匹配尺码和价格做区间过滤。这条路径适合绝大多数场景因为它完全复用了我们现有的倒排索引和属性索引性能稳定逻辑可控。路径B是模型直接生成候选ID。把用户最近浏览和收藏的商品ID列表、当前query的画像、热度榜前N个商品ID一起塞进上下文让模型直接输出它认为最相关的候选ID集合。这条路径的适用场景是那些画像转检索条件后仍然匹配不到结果的极端长尾query。我们把它设计成紧急兜底方案不会默认开启。两条路径跑完都会进入同一个合并器和向量、文本、swing等其他路的召回结果合并再做去重和粗排。3.3 输出校验与兜底策略生成式模型最大的风险是输出不可控。我们在这上面踩过很多坑最终形成了一套四层校验机制格式校验用JSON Schema检查输出是否是可解析的JSON字段类型是否正确。枚举校验品牌、类目、颜色这些字段必须落在我们维护的合法枚举表里。模型输出一个库里不存在的品牌直接判无效。逻辑校验尺码区间和价格区间是否符合常识比如价格上限不该为负数、尺码不该是字母。置信度阈值模型输出越低置信度的解析结果越要降级处理宁可走传统召回也不要硬吃生成结果。这里有一个经验教训生成式召回的上限再高也必须在“宁缺毋滥”的前提下使用。宁可用传统召回结果顶上让用户体验平稳也不能让一张错误画像把原本能召回的候选全过滤掉导致无关结果甚至无结果。3.4 技术选型为什么在Java技术栈里用LangChain4j得物后端整体以Java为主我们的搜索工程代码也基本都在Java生态内。引入生成式能力时团队其实纠结过要不要单独起一个什么服务来调LLM让Java服务通过HTTP去访问。后来决定维持Java单栈引入LangChain4j作为接入层框架。选择LangChain4j有几个现实原因Java生态里直接调LLM接口要自己处理prompt模板管理、JSON输出解析、上下文组装这些琐碎但容易出错的事LangChain4j把这些抽象做得比较成熟。它的AI Service层可以直接定义一个Java接口把“输入query返回画像JSON”声明成一次方法调用团队里Java工程师上手成本低。它支持prompt模板、输出解析器、多轮上下文管理正好覆盖我们画像生成这个核心场景。实际使用中我们把prompt模板、few-shot示例和输出解析器都放在LangChain4j的配置层管理业务代码里只看到一次queryIntentService.parse(query, context)调用维护起来清爽很多。4. 与多路召回协同编排合并、去重、评测与灰度4.1 生成式召回在多路召回里的角色定位必须承认一点生成式召回不是来“消灭”向量检索或其他召回路的它是来给整个召回体系补一块短板的。得物交易搜索目前仍是多路召回体系向量路、文本路、行为序列路都在正常服役。生成式召回在体系里的定位是“高质增量路”和“长尾修复路”。它的使命不是和向量路抢头部query而是把那些向量路和文本路都搞不定的黑话query、组合条件query接住。这一块理解上的分歧我们内部也争论过很久。有的同学主张把生成式召回做成默认强制走一遍我坚持把它放在“增量”和“兜底”两个位置上。理由很简单生成式能力当前的延迟和成本都高于传统召回把它用在所有query上是浪费而且头部query传统召回表现已经足够好生成式对它们的边际收益很低。4.2 结果合并与去重策略多路召回合并时去重策略直接决定增量收益能不能体现出来。我们为每路召回的结果打上source标签生成式召回的结果标记为gen然后在合并器里做两层处理。第一层是按商品ID去重不同路召回同一商品时保留得分更高路的来源但把生成式路召回的来源信息记下来作为后续排序的上下文信号。第二层是控制重叠率如果生成式召回的候选与向量路重叠超过一定比例说明这一路的增量价值有限会把生成式结果中与已有候选重复的部分降权。合并器的设计还考虑了一个细节不能让生成式结果的增量全部集中在热门商品上。生成式模型天然对热门商品更熟悉容易反复输出头部候选如果不去控制生成式召回会变成第N路热门商品召回失去意义。我们做了候选池层面的多样性约束限制同一品牌、同一系列在生成式结果里的占比。4.3 离线与在线评测指标生成式召回上线前我们设计了专门的评测方案而不是直接拿整个召回链路的所有指标笼统看。离线上重点看这几个指标指标说明我们的目标RecallK候选集里是否包含目标商品长尾query显著提升HitRate至少命中一个有效商品的比例下降无结果率增量覆盖率生成式结果中与其他路不重复的比例不低于40%画像解析准确率槽位解析与人工标注的一致性核心槽位不低于90%在线指标里我们最关心的是无结果率、搜索点击率和交易转化率。考虑到交易搜索的属性转化指标最终一定比单纯的点击指标更重要。灰度时按类目切分先选潮流球鞋这种黑话浓度最高的类目跑验证有效后再逐步扩到服饰和潮玩。4.4 灰度与迭代节奏灰度策略上我们坚持“慢启动、带降级”。先切5%流量观察画像解析成功率和召回增量确认没有明显性能回退后再逐步放开到10%、20%、50%。迭代节奏是两周一个版本。第一版只做query理解和黑话归一解决无结果问题第二版加入组合条件解析提升精确召回能力第三版才把直接生成候选ID的激进方案放进来对比。整体走下来一个明显的变化是带型号别称和黑话的query无结果率显著下降之前向量检索和文本检索都空手而归的很多长尾词现在能拿回有效候选了。价格条件和尺码条件这类精确滤过的场景召回结果也更贴合用户实际需求。5. 实际踩过的坑延迟、幻觉、长尾和成本5.1 延迟搜索主链路放不下一整个LLM第一个坑来自性能。搜索主链路的延迟预算通常按50到100毫秒设计一次LLM调用的延迟普遍在百毫秒级起步直接把生成式塞进主链路是不现实的。我们的解法是把LLM调用从主链路里“拆出去、缓下来”热点query离线预生成对高频query离线批量生成画像并缓存线上直接读缓存。在线异步首猜用户输入过程中利用搜索联想和上一轮搜索结果旁路异步触发生成等用户真正提交搜索时结果已就绪。低延迟推理在线实时场景用蒸馏后的小参数量模型推理快一档只处理缓存未覆盖的中长尾。这套组合下来真正在线实时跑LLM的query占比控制在很小的范围内主链路延迟基本不受影响。如果要给一个实操建议就是不要把生成式召回设计成“每条query都必须经过”的强制环节把它设计成缓存优先、小流量实时的增强环节工程上会更顺畅。5.2 属性幻觉一本正经地胡说八道生成式召回另一个大坑是属性幻觉。模型在生成画像时可能信心十足地把一个不存在的配色当成系列属性或者把品牌映射错误。比如“灰水泥”这个query模型可能会写成“Nike Air Force 1 水泥灰”实际用户想要的可能是“Air Jordan 4 Rain or Shine”那种灰水泥配色品牌和系列都需要对齐到具体商品知识库里。我们一开始对幻觉的警惕不够以为解析出结构化字段就万事大吉结果线上出现了一批“标签完全对但商品完全错”的召回。后来把校验机制补上又把商品知识库里的合法品牌、系列、昵称对列表灌给模型做约束幻觉比例才降到可控范围。经验是生成式召回里校验层和模型层同等重要。宁可多写一层枚举校验也不能把模型的输出当可信输入直接进检索。5.3 长尾与头部的平衡第三个坑是资源分配。我们早期把生成式能力均匀铺到所有query上线上看效果平平甚至头部词的指标还有轻微抖动。原因前面提过头部热门词传统召回已经很成熟生成式很难提供增量反而可能因为画像解析偏差把原来能召回的候选过滤掉。后来我们加了query分级头部query完全走缓存和传统召回不做生成中等热度query做缓存优先的生成式补充真正的长尾、低频、黑话query才走实时的生成式解析。这样一调整整体收益成本比明显改善。总结起来就是生成式召回该用在“传统手段明显失效”的地方而不是全面铺开。5.4 成本与收益的真实账本最后说成本。LLM调用的token成本和GPU成本都比传统检索高一个量级。我们控制成本的方式主要是三块尽量用缓存命中吸收高频流量缓存命中率稳定在高位。prompt设计走简洁路线few-shot控制在少量精选示例不塞大段冗余指令。画像解析用小参数量模型为主大模型只用于离线生成示例和困难case复核。算下来边际成本是可控的但这件事一定要在立项时就规划清楚等项目跑起来再控制成本和延迟改动成本会高很多。我们的感觉是这套方案的收益主要集中在长尾转化和无结果率这类指标上如果业务场景本身没有明显的语义gap、没有黑话新词、没有复杂组合条件那生成式召回带来的增量可能不值得这份成本。最后再分享一点个人体会。做完这个项目我的感觉是信息检索系统的演进从字面匹配到向量检索解决的是“相似”问题从向量检索到生成式召回解决的是“理解”问题。得物交易搜索里大量黑话、圈层词、组合条件的场景天然适合生成式这套玩法。但如果你的业务场景词表稳定、商品文档规范、用户query直白可能向量检索加多路召回已经够用不用盲目追这个方向。技术选型这事永远是场景决定范式而不是范式决定场景。