搜索圈这两年最热闹的话题莫过于向量检索。随便翻开一场技术分享十场里有八场在讲双塔、ANN、HNSW、向量库调优。大家卷完模型卷索引卷完索引卷量化到了2024年很多团队发现一个尴尬的事实向量检索的精度曲线已经走得非常平了同样的优化手段翻来覆去线上指标就是不动。得物交易搜索团队在去年也撞上了这堵墙。商品搜索和通用搜索不一样用户的query里藏着大量的属性约束、价格区间、尺码偏好光靠“语义相似”根本接不住这些结构化诉求。比如用户搜“AJ1芝加哥42码预算2000以内”传统向量检索能理解“AJ1芝加哥”是鞋但“42码”“预算2000”这种精确约束向量空间很难表达清楚。我们后来换了一条思路不再只盯着向量检索这一条路而是把生成式模型引入召回链路让模型先“理解”再“生成”把召回从“近似匹配”升级成“结构化生成检索融合”。这篇文章就把我们的完整思路、架构选型、落地过程中踩过的坑一次性讲清楚希望能给同样在和召回精度死磕的团队一些参考。1. 从向量检索到生成式召回为什么必须换范式1.1 向量检索的天花板在哪里先说说为什么大家都会默认选择向量检索。这套范式的基本逻辑很简单用双塔模型把query和item分别编码成向量离线把全部item向量建好索引线上拿到query向量后在向量库Faiss、Milvus这类引擎里做ANN近邻检索返回TopK个候选。它的优势非常明显离线友好、召回速度快、工程链路成熟而且对“语义相似”类query的效果确实比传统关键词匹配高一大截。但向量检索的本质是“在固定向量空间里找最近邻”这个设定本身就带着三层天花板第一层交互太晚。双塔结构里query和item的交互发生在最后一层点积前面的编码过程各自为政。这种“晚交互”设计保证了算力可控但也意味着模型很难捕捉query内部的组合关系。就拿“AJ1芝加哥42码”来说模型把整句话压成一个向量颜色、款式、尺码的信息被混在一起变成高维空间里的一个模糊坐标。表达力不够召回自然会有损失。第二层精确约束失效。向量空间擅长表达“语义相近”但不擅长表达“数值精确”。价格区间、尺码、新旧程度、发货地这类硬约束在向量空间里很难找到清晰的几何边界。你就算把价格特征拼进embedding里训练数据不够多时模型依然学不会“2000以内到底意味着什么”。第三层长尾query吃不消。向量检索的效果非常依赖训练数据的丰富度。头部query比如“篮球鞋”“卫衣”数据量足效果还行一遇到长尾query比如带有明显个人意图的说法、口语化的表达模型就抓瞎。用户搜“适合去见家长的礼物”和搜“送岳父的酒”语义相近但词面完全不同向量检索经常在这类请求上翻车。这三层天花板叠加在一起让我们那些年的优化动作逐渐变成了“在固定的池子里捞鱼”捞来捞去就是那几条。想要质变就得换一种召回范式。1.2 生成式召回到底在想什么“生成式召回”这几年在研究圈其实不算新概念Google前几年发表的DSIDifferentiable Search Index就尝试过直接用生成模型输出文档ID跳过向量检索步骤。当时关注的人不少但落地的人不多主要卡在候选空间太大、生成结果不可控。我们这次没有走那种激进的“纯生成”路线而是把生成能力拆解后重新塞进已有链路里。核心思路可以概括成三句话用生成模型替代“语义编码器”不再让模型把query压成一个向量而是让它生成出结构化的“意图表示”把query从自然语言翻译成一套可执行的检索条件。用结构化解码解决精确约束生成模型输出品类、品牌、尺码、价格区间这些独立字段每一个字段都可以在后端精确过滤。用生成结果反哺检索生成的约束条件不直接当作最终结果而是拿去和知识库、向量库联合检索做到既有语义泛化能力又有结构化精度。我用一个生活化的类比来解释传统向量检索就像你去图书馆管理员听你模糊描述一句“想找本讲人工智能的书”然后凭感觉带你去某一排书架前让你自己翻。生成式召回则像是管理员先把你的需求拆开——“要计算机分类下的、偏机器学习方向的、中文出版的、2019年以后的书”——然后拿着这个清单精准地到对应书架上去找。后者多了一步“需求理解”但这一步恰恰是之前链路里缺失的。1.3 为什么得物交易搜索特别适合这个方案得物的商品搜索场景有点特殊。平台上大量商品是球鞋、潮流服饰、潮玩用户搜索时经常是一句话里混着款式、配色、尺码、预算多重意图。比如“AJ1 黑红脚趾 42码”“女生穿的黑色运动鞋 500以内”“科比4 篮球鞋 白色 41”这类query如果丢给双塔模型模型很难精准地把“42码”和“41码”区分开向量空间里这两个语义太近了。但用户对这个数字极其敏感召回结果差一码转化率就是天壤之别。传统向量检索解决这个问题的方式是硬训把尺码特征拼进模型寄希望于数据多到模型能记住。但商品库里有几百万商品用户query是无限变化的靠记住来解决组合爆炸问题根本不现实。生成式召回天然就是为了解决这类“组合约束型”query而生的。模型先解析出“AJ1”是Air Jordan 1、“黑红脚趾”是配色、“42码”是尺码再拿这些结构化字段到商品知识库里做精确匹配。这样既保留了语义理解能力又让精确约束变成普通数据库查询就能完成的动作。可以说交易搜索的query结构特征决定了它是生成式召回最合适的落地场景之一。2. 生成式召回的架构设计与选型思考2.1 不能盲目“全生成”三种路径的对比我们在方案设计初期梳理过三条可能的实现路径第一条是纯生成式直接把候选商品ID列表作为输出目标模型训练成“输入query、输出一组商品ID”。这条路理论最性感但落地最痛苦。商品库几百万个ID模型要学的输出空间太大生成结果极易出现库里根本不存在的ID而且线上更新一个新商品模型还得重新训练才能“知道”它时效性完全跟不上。第二条是纯结构化生成让模型只输出结构化的检索条件不输出商品。比如生成品类、品牌、颜色、尺码、价格区间后端再用倒排索引做过滤。这条路的好处是可控性极强坏处是丢掉了语义召回能力。用户搜“适合学生党的平价实战篮球鞋”模型很难直接拆出明确的品牌和颜色“学生党”“平价”“实战”这些词都得靠语义泛化去召。第三条是混合式也是我们最终选择的方案生成式负责产出结构化约束和语义标签再结合向量检索和倒排索引做多路召回。结构化约束保证精确性语义标签提供泛化能力向量检索兜住那些模型解析不出来的模糊请求。三条路各有分工谁也别想一肩挑。2.2 混合式方案的整体流程拆解我们的完整链路分为四个阶段第一阶段Query意图解析。用户输入query后先生成式模型先做一次意图结构化解码。这一步的输出是一份“检索条件表”包含内容大致包括品类意图篮球鞋、跑鞋、卫衣、潮玩……品牌约束Nike、Air Jordan、New Balance……属性标签配色、材质、款式类型精确参数尺码、价格上/下限、新旧程度泛化标签场合标签、风格标签实战、通勤、送礼、学院风……第二阶段多路召回。拿这份结构化条件去同时打三路召回倒排索引路精确匹配品类品牌尺码价格把符合硬约束的商品全部捞出。向量检索路把query和结构化标签一起编码成向量去向量库做语义召回。知识库属性路部分用户会关心“商品是否支持鉴定”“是否现货”这些在商品知识库里做布尔过滤。第三阶段融合与截断。三路召回结果做并集然后根据生成条件的置信度加权排序截断到固定候选池大小。这一步的核心是控制噪声不能让语义召回的结果冲淡精确匹配的结果。第四阶段兜底与日志。如果生成模型解析失败或解析结果置信度极低直接回退到传统向量检索链路。同时每一份解析结果都落到日志里方便后续离线分析模型薄弱环节。2.3 生成模型怎么选不能只看参数规模在实际选型时我们对比过好几个量级的模型。一开始大家都有参数崇拜觉得要上就上几十B的大模型但上了测试环境就发现完全不现实线上召回服务要求的是几十毫秒级别的延迟一个几十B的模型生成一次结构化输出光推理就要好几秒根本扛不住。我们的最终选择是一个中等规模的序列到序列模型参数量在百M到1B之间专门做“query → 结构化检索条件”的翻译任务。别小看这个任务它比通用对话简单得多输出空间是固定的schema字段不需要太强的自由生成能力但要求模型对商品领域词汇、用户搜索习惯有足够的理解。这种垂直任务中小模型只要训练数据够扎实效果完全可以打。真正费劲的不是模型选型而是训练数据的构建。历史搜索日志里有几百万条真实query但query本身没有标注好的结构化字段。我们得先做一轮离线打标用规则抽取出能直接识别的品牌、尺码、价格再用人工标注一批困难样本。整套数据管线花了将近一个月才攒出第一批可用的训练集。3. 核心细节与实操要点从环境搭建到参数配置3.1 向量库检索需要什么数据库选型实测对比虽然文章标题在说“别只卷向量检索”但我们的落地架构里向量库依然是重要一环只是角色从“主力”变成了“多路之一”。这里顺便说说我们在向量库选型上的实测对比毕竟这也是很多人问过的问题。先把市面上常见的向量检索引擎摆一张表引擎部署方式索引类型适合规模优势劣势Faiss独立库IVF-PQ / HNSW千万级以上性能极强、灵活度高不支持分布式、缺少内置高可用Milvus分布式服务HNSW / IVF / DiskANN亿级以上云原生、支持持久化与过滤运维成本高小团队慎选Elasticsearch服务HNSW 倒排百万到千万级自带倒排与过滤、上手快并发和召回性能弱于专用引擎Qdrant服务HNSW / 稀疏向量千万级以下支持payload过滤、Rust写的性能好生态相对小Weaviate服务HNSW百万到千万级内置模块多、使用简单大并发场景性能待验证我们在得物交易搜索场景里商品量级是百万到千万之间query并发很高对过滤条件尺码、价格支持要求非常严格。最终选了Elasticsearch做主力向量检索引擎不是因为它向量性能最强而是因为它同时支持倒排索引和向量检索可以在一次查询里完成“向量召回硬条件过滤”。这在这个场景里是决定性的优势。几个面试官常问、实战里也容易踩的参数细节分享一下HNSW的M值决定了图连接密度M越大召回越准但内存开销越大。我们线上设置M32efConstruction200在这个量级下内存和精度的平衡最舒服。如果选用IVF-PQ方案nlist聚类中心数量建议设为数据量的平方根量级。100万条数据时nlist取1000左右过大反而增加无效计算。过滤字段必须建docvalue否则压测一上来过滤耗时直接翻倍这个问题线上踩过一次排查了半天。3.2 训练数据与标签体系生成式模型的“粮草供应”生成式召回模型的训练数据质量比模型结构重要十倍。我们花了大力气做了一套“三源标注”管线第一源搜索日志回放。历史上有大量用户搜索后点击了哪些商品把click行为当作弱标签。用户搜“AJ1芝加哥”最后点了“Air Jordan 1 Retro High OG Chicago”这就是一组天然的“query到商品”的对应关系。再通过商品库反查把商品的结构化属性提取出来。这个源的数据量最大但噪声也大因为用户可能点错也可能点击商品和query只部分相关。第二源人工标注。抽出一批覆盖长尾表达的query让运营同学按照统一的标注规范填schema。比如query是“两千左右的黑红球鞋 42码”标注结果是品牌不限、颜色黑红、尺码42、价格上限2500“两千左右”我们定义为2000到2500。这个源的数据量小但质量最高用来校正模型对边界表达的认知。第三源知识库对齐。平台商品知识库里本身就有品牌库、色系库、风格库。我们把query里能命中的实体词自动打上标签作为预标注数据喂给模型做冷启动。这一步能让模型快速掌握商品领域的专有名词分布减少人工标注的工作量。训练时有个细节必须提醒不能只训生成模型还要训一个置信度判别器。因为线上不可能每次生成结果都靠谱得有一个模块判断“这次解析可信度够不够”。我们用生成模型的token概率均值做初版置信度后来又加了一个小的二分类判别器输入是query和生成结果输出是“可不可信赖”。只有判别器认为可信的生成结果才会走生成式召回链路否则直接回退传统链路。这个小心思极大降低了上线初期的badcase率强烈推荐。3.3 生成式召回融合排序不只是简单的RRF多路召回结果的融合看起来简单实际上是个非常讲究的环节。最简单的方式是RRFReciprocal Rank Fusion把各路的排序序号取倒数求和但这个方案忽略了一个重要信息各路结果的置信度是不一样的。假设生成式解析出的“尺码42”置信度是0.97价格是2000以内置信度是0.62那么精确匹配路召回的42码商品应该被赋予更高权重而价格约束路的结果就要适当折扣。所以我们没有用固定权重而是给生成式召回的每个字段单独预测置信度再根据字段置信度动态调节该路结果的得分权重。具体公式上候选商品的最终得分我们用的是加权求和final_score w1 * vector_score(query, item) w2 * gen_score(query, item) w3 * exact_match_score(query, item)其中gen_score不是简单模型打分而是把生成字段和商品属性做字段级匹配后按字段置信度加权求和得到的对齐分数。看起来多绕了一步但这一步直接决定融合效果固定权重上线时精确匹配经常被语义召回淹没动态权重上线后精确约束强的query里精确匹配结果占比显著提升了。融合之后还有一步去重与多样性控制。交易搜索里最怕的情况是召回结果全是同一款鞋的不同尺码或者同一店铺的同款商品。我们的做法是召回端做商品ID级别的聚合同款商品只保留一组代表剩余候选位释放给更丰富的长尾结果。4. 常见问题与排查技巧实录4.1 生成结果和知识库对不上怎么办这是生成式召回落地中最经典的问题也是大家最担心的问题。模型解析出来的结果可能是一个库里根本不存在的东西。比如模型把“午夜蓝”生成了“夜蓝”商品库属性色卡里根本没这个值精确匹配路就白跑了。我们的解法是给生成模型加一层输出约束解码的时候不是完全自由生成所有品类、品牌、颜色字段都从一个“合法取值词典”里采样。词典来自商品知识库的属性表模型只能在这些取值里挑。这样从源头上杜绝了“生成出不存在的实体”这个问题。但词典会漏掉新出现的品牌或新色系所以我们的词典不是静态的每天离线任务会自动从新增商品属性里抽取值并合并进词典。生成模型本身不用每天重训只要词典在更新解码约束就在跟着更新。这个方案的工程成本比想象中低很多效果却很扎实。如果还是碰上了词典里没有的生成结果——比如模型铁了心要输出一个新词我们还有一道兜底生成结果返回到倒排索引里查询如果命中数为0就自动降级为“仅保留品类和泛化标签抛弃具体属性”保证链路不至于空召回。4.2 线上推理延迟太高怎么压生成式模型上线最直观的问题就是延迟。我们最开始把生成服务挂在GPU推理集群上单次推理平均耗时在80ms左右看起来不算太离谱但在大促峰值流量下并发一上来GPU显存和算力直接被打满导致部分请求超时。做了几轮优化后延迟降到了20ms以内第一招是模型蒸馏。用大模型蒸馏小模型把序列到序列模型的层数从12层减到6层输出端从自回归改成非自回归并行解码。生成任务本身是一次性翻译不需要像对话那样逐token依赖非自回归把解码时间压缩了将近一半。第二招是前缀缓存。交易搜索里有大量重复的品类词和品牌词我们把生成模型的前几层输出做了缓存命中前缀直接复用只有后缀部分实时推理。实测下来头部query的缓存命中率能做到30%以上。第三招是引入对照降级策略。我们在生成服务前面加了一个流量调度层根据生成服务实时延迟和队列长度按比例降级流量到传统向量检索链路。即使生成服务被突发流量打爆用户整体体验也不会明显劣化只是召回精度暂时退回到上一版水平。4.3 线上数据回流与评估闭环怎么建新系统上线后最大的风险不是效果不好而是不知道它什么时候开始变差。生成式召回需要一个完整的评估闭环我们做了三件固定工作第一全链路日志埋点。每一份生成解析结果、每一路召回数量、融合阶段被截断的比例全部落到明细日志里。这样任何一次线上效果波动都可以回溯到具体是哪一路出了问题。第二离线指标监控。每天离线跑一遍前一天的真实query集合计算RecallK、MRR、NDCG三个指标再分别统计精确匹配占比、语义召回占比观察分布变化趋势。一旦发现精确匹配占比在下降大概率是某个字段的解析准确率出了问题需要拉数据检查。第三人工badcase周评。每周从线上低转化query里采样人工对比新旧两套链路的结果差异。这些badcase会积攒为新的训练数据进入下一轮模型迭代。我们有超过三分之一的标注数据来自这种线上反馈回流比纯离线标注要“疼”得多也准得多。4.4 常见问题速查表问题现象排查思路解决方案生成字段与商品库对不上精确匹配路召回为空检查词典是否有该取值词典自动从商品属性更新生成结果置信度虚高明明解析错了还走了生成链路分析置信度分布与badcase相关性引入独立判别器做二次校验延迟飙升GPU推理超时看队列长度和token生成耗时蒸馏前缀缓存降级调度融合后精确结果被淹没精确匹配商品排到很靠后检查权重设置改为字段级动态置信度加权新商品上线不参与生成召回刚发布的热门款召不回来检查商品库同步链路新增商品触发属性抽取入库模型对口语query解析失败用户表达不规范时效果下降抽样分析失败case扩展训练语料降级兜底5. 效果观察与后续演进方向这套生成式召回架构上线后我们观察了持续一个季度的数据。离线评测里RecallK在长尾query上的提升比较明显头部高频query由于原来向量检索已经训得足够好增量不大。真正拉开差距的是中长尾部分尤其是带结构化约束的query精确匹配率比纯向量检索时期高了不少。更值得关注的是线上业务指标的变化。交易搜索场景最看重的不是点击率而是“搜到可买商品”的比率和成交转化。生成式召回让一些原本被向量检索模糊处理掉的精确意图被正确识别原来搜“42码”会给用户推“40码”的badcase明显减少用户后续点击和加购的意愿自然就上来了。往后我们规划的演进方向有三条一是在生成模型中引入多模态信号。用户搜索时不仅搜文字还会上传图片搜同款目前的生成式链路是纯文本输入图片信息没有利用起来。后续打算让模型先对图片做一轮视觉特征抽取再融合文字query一起生成结构化约束。二是加入用户个性化信息。同一个“实战篮球鞋”一米九的用户和一米七的用户对尺码和款式的偏好完全不同。我们现在是按商品确定性约束做召回后续准备在生成阶段就把用户画像特征并进去让生成的约束更贴合单个用户的真实需求。三是探索“生成式排序”的前置接入。召回端已经能用生成式产出结构化条件排序端其实也可以借助生成模型做更细粒度的商品解读比如自动生成商品卖点摘要和用户需求的匹配理由让排序模型的输入特征更丰富。回到开头那个问题——向量检索还值不值得卷我的答案是值得但不能只卷它。向量检索是搜索系统里一个非常成熟的组件它的上限很清晰适合承接语义泛化和粗召回。而生成式召回解决的是它在结构化表达上的盲区两者不是替代关系是配合关系。这次实践下来我最深的体会是技术范式的跃迁不是凭空造一个全新引擎而是把过去被模糊处理的环节拿出来用更合适的模型重新做一遍。搜索链路里还有很多这样的环节值得逐个重新审视。最后再分享一个落地层面的小技巧生成式召回这种新架构上线时强烈建议保留一条“降级开关”并且把开关粒度做到字段级。比如只关闭“尺码生成”但保留“品类生成”这样线上出问题时可以精确到单个字段去排查而不用整条链路回滚。这个设计在几次线上波动里帮我们省下了大量返工时间属于花了小成本省了大麻烦的典型做法。