1. 项目概述当搜索系统不再“找相似”而是“猜意图”得物交易搜索团队最近内部流传一句话“向量召回再卷天花板也摸得到。”这句话背后不是技术悲观主义而是对搜索本质的重新叩问——我们到底是在“检索已存在的商品”还是在“理解用户此刻真正想要什么”标题里那个带引号的“生成式”不是指随便调个大模型API、把query扔进去吐个结果就完事它是一次底层范式的切换从“匹配已有索引”转向“动态构造候选空间”。我参与过三轮得物搜索架构迭代前两轮都在优化向量召回的精度、速度和覆盖度——用更细粒度的embedding、更复杂的负采样、更精巧的ANN索引结构。但到了2023年Q4我们发现一个硬伤当用户搜“能配AJ1黑红的袜子”向量模型会召回大量“黑红色袜子”却漏掉“纯白短筒袜”因为视觉上不相似但穿搭逻辑上高度匹配当搜“送男友的生日礼物小众不撞款”传统召回根本无法理解“小众”“不撞款”这种主观、反事实、强语境的表达。这时候“生成式召回”不是锦上添花而是破局刚需。核心关键词“生成式”在这里有明确的技术定义它指利用大语言模型LLM的语义理解与文本生成能力在用户query输入的毫秒级内动态生成一组高相关性、高多样性、强可解释性的中间召回词或结构化召回条件再将这些生成物作为传统检索系统的输入驱动倒排索引、向量索引甚至图谱查询。它不替代原有检索链路而是插在query理解与召回执行之间充当一个“意图翻译器候选放大器”。这和“无限制无审核生成式AI”完全无关——得物的生成式召回模块运行在严格受控的私有模型服务上所有生成内容经过多层业务规则校验、安全词库过滤、商品知识图谱约束输出必须是合法、合规、可检索的商品属性组合或品类路径。所谓“范式跃迁”跃的不是技术炫技而是从“系统能找什么”到“系统该帮用户想什么”的思维转变。适合读这篇的是搜索算法工程师、电商推荐系统负责人、以及正在被“长尾query低召回率”折磨的产品经理——你不需要会写prompt但得懂为什么传统方案卡在哪儿以及生成式介入后每个环节该怎么重新设计。2. 整体设计思路为什么非得用生成式向量召回的三大硬边界2.1 向量召回的物理极限相似性≠相关性向量检索的核心假设是“语义相似即业务相关”。这个假设在图文匹配、同品类比价等场景很稳但在得物这样的垂直交易场景里它频繁失效。我们做过一次归因分析随机抽样1000个低召回率query召回商品数3其中68%的问题根源不是embedding不准而是语义鸿沟。比如用户搜“刘亦菲同款耳坠”向量模型会召回所有embedding距离近的“刘亦菲”相关商品但得物库里实际只有“某品牌×刘亦菲联名款耳坠”这一款。向量空间里“刘亦菲”和“耳坠”是两个独立向量它们的乘积或拼接向量并不能天然表达“同款”这个强关系约束。而生成式模块可以明确生成“品牌某品牌品类耳坠合作艺人刘亦菲限定款是”这个结构化条件直接喂给倒排索引召回精准度立升。这里的关键不是生成能力本身而是生成过程强制引入了领域知识约束——模型不是自由发挥而是按预设schema填空。2.2 长尾Query的稀疏性困境没有训练数据就没有好向量得物每天新增query中约42%是从未出现过的长尾词来源2023年Q3搜索日志统计。这些query往往包含新晋明星、小众设计师、跨界联名事件比如“《繁花》宝总同款金丝眼镜框”。传统向量方案依赖海量历史query-item点击对来训练embedding但这类新query零样本embedding只能靠字面拆解效果极差。生成式方案绕开了这个死结它不依赖query的历史表现而是基于LLM对通用世界知识的理解如知道《繁花》是电视剧、宝总是角色、金丝眼镜框是配饰结合得物商品库的实体知识如“金丝眼镜框”对应品类ID 12789“宝总”在商品描述中常关联“复古”“港风”标签动态生成召回条件。我们实测过“《繁花》宝总同款金丝眼镜框”这个query向量召回TOP50里只有2个相关商品而生成式召回首轮就命中7个且全部是真实在售款。这不是模型更“聪明”而是把知识推理前置到了召回阶段让系统具备了“没见过也能猜”的能力。2.3 多模态意图的不可压缩性文字、图片、行为信号必须协同表达用户搜“这个包配什么裙子”附了一张包的照片。传统方案要么只处理文字要么只处理图片要么简单拼接特征。但“配什么裙子”是个典型的跨模态推理任务需要理解包的风格复古/通勤/度假、颜色莫兰迪/亮色、材质皮质/帆布、尺寸迷你/托特再映射到裙子的对应属性。向量模型强行把图像和文字压进同一空间损失巨大。生成式模块则采用分治策略先用CV模型解析图片输出结构化描述“包型托特包主色燕麦色材质磨砂皮风格简约通勤”再用LLM将文字query“配什么裙子”与图片描述融合生成召回条件“品类连衣裙风格简约通勤主色燕麦色/米白色/浅卡其材质真丝/垂感棉长度及膝/小腿中段”。这个生成过程天然支持多源信号融合且输出可直接对接现有检索系统。我们上线后图文混合query的召回率提升31.7%更重要的是生成的条件具备强可解释性——运营同学能一眼看出系统“理解”了什么方便快速调优。3. 核心细节解析生成式召回不是调API而是构建可控的“意图翻译流水线”3.1 模型选型为什么不用百亿大模型而选7B级别LoRA微调模型网上很多文章鼓吹“用GPT-4做搜索召回”这在得物是行不通的。原因很现实延迟、成本、可控性。GPT-4单次调用平均耗时800ms而得物搜索P99延迟要求300msAPI费用按token计费日均亿级query下成本不可控最关键的是大模型“幻觉”无法规避——它可能生成“品牌爱马仕品类球鞋”而得物根本没有爱马仕球鞋。我们的方案是基于Qwen-7B-Chat进行领域微调冻结大部分参数仅对LoRA适配器进行训练。选择7B规模是因为它在A100显卡上单卡推理延迟稳定在120ms内含前后处理吞吐量达350 QPS/卡满足线上峰值需求。微调数据来自三部分① 人工标注的10万组“原始query→标准召回条件”样本由资深买手和搜索产品经理联合标注② 利用商品知识图谱自动生成的50万组“属性组合→合理query”反向样本③ 历史bad case中抽取的20万组“向量召回失败query→正确召回条件”修正样本。训练目标不是让模型自由生成而是精确拟合预设的JSON Schema{ category: [连衣裙, 半身裙], attributes: { style: [简约通勤, 法式复古], color: [燕麦色, 米白色], material: [真丝, 垂感棉], length: [及膝, 小腿中段] }, constraints: [品牌需在得物在售列表中, 价格区间200-800元] }提示Schema设计是成败关键。我们刻意避免开放字段如other_notes所有字段都对应后端检索系统的可执行参数。模型输出必须严格符合JSON格式否则整条请求被丢弃并触发告警——宁可召回为空也不能召回错误。3.2 Prompt工程不是写文艺提示词而是设计“结构化指令模板”很多人以为生成式召回就是写个好prompt比如“请根据用户query生成相关商品条件”。这在得物会彻底失败。我们的prompt是一个精密的“指令模板”包含四层约束角色定义 “你是一名得物搜索资深买手熟悉所有在售商品、品牌授权关系、季节趋势和用户穿搭常识。你的任务是将用户模糊需求转化为精确、可执行、合规的召回条件。”输入规范 “用户输入包含[QUERY]文字query、[IMAGE_DESC]图片结构化描述若无则为空、[USER_PROFILE]脱敏后的用户历史偏好如‘常购品类运动鞋偏爱品牌Nike, Adidas’”。输出协议 “严格按以下JSON Schema输出字段缺失则填空数组[]或空对象{}禁止添加额外字段禁止解释性文字。”业务红线 “禁止生成未授权品牌、禁止生成违禁品类如医疗器械、禁止生成价格超出用户历史消费区间的商品、禁止生成与图片描述矛盾的属性如图片为黑色包生成条件含‘主色白色’。”这个模板不是一蹴而就的。我们花了两个月做AB测试对比“自由生成prompt”、“结构化schema prompt”、“带业务校验规则的schema prompt”最终后者在准确率生成条件100%可执行上达到99.2%而自由生成版只有63.5%。关键教训是Prompt不是引导模型“思考”而是给模型一套不可逾越的操作手册。3.3 召回条件后处理生成只是开始校验与增强才是核心LLM生成的JSON只是中间产物它必须经过三层后处理才能进入检索系统语法与格式校验用JSON Schema Validator检查字段类型、必填项、枚举值范围如style只能是预设的12个风格标签。失败则降级为向量召回。业务规则引擎校验调用得物实时商品库API验证生成的品牌是否在售、品类ID是否存在、价格区间是否合理。例如若生成品牌Gucci但Gucci在得物当前无女装授权则自动替换为品牌Coach, Michael Kors等同档位授权品牌。多样性增强为避免生成条件过于集中我们设计了一个轻量级重排序模块。对生成的category数组按“品类热度×用户画像匹配度”加权保留Top3对attributes中的color强制加入1个互补色如生成燕麦色则追加深棕色以覆盖不同肤色用户。这个模块不增加延迟却让召回结果覆盖更广的用户需求光谱。注意后处理模块的代码必须极致轻量。我们规定单次处理耗时15ms所有外部API调用必须设置50ms超时超时即跳过该步骤——可用性永远优先于完美性。4. 实操过程从0到1搭建生成式召回模块的六步落地法4.1 第一步定义“可生成”的最小可行范围MVP Scope别一上来就想覆盖所有query。我们第一期只聚焦三类高价值、高痛点场景明星同款类如“XXX同款商品品类”占比长尾query的18%穿搭搭配类如“配XXX的YYY”占比15%风格描述类如“小众不撞款品类”、“复古港风品类”占比22%。选择依据很务实这三类query的向量召回率长期低于40%且人工标注样本充足买手团队每月产出2000条。其他query如纯品牌词、型号词仍走传统路径。MVP范围确定后我们画出清晰的流量分发图所有query先过规则引擎命中三类场景的才进入生成式模块其余直连向量召回。这样既控制风险又快速验证价值。4.2 第二步构建领域知识注入管道Knowledge Injection PipelineLLM的通用知识不够用必须注入得物特有的知识。我们没用RAG那种复杂方案而是构建了轻量级知识注入管道商品知识图谱快照每日凌晨导出商品库的实体关系品牌-品类-风格-价格带-授权状态转为CSV格式热点事件词典运营同学维护的实时词典如“《繁花》热播期”、“巴黎奥运会备战期”包含关联商品ID和标签用户行为模式库离线计算的高频搭配组合如“Air Force 1 直筒牛仔裤”、“Celine Box Bag 羊毛大衣”存为键值对。在模型推理前系统自动检索这三类知识拼接到prompt末尾。例如query为“《繁花》宝总同款”知识注入后prompt末尾会追加“当前热点《繁花》电视剧关联商品ID[12345, 67890]风格标签复古、港风、90年代”。这比RAG快一个数量级且知识更新延迟2小时。4.3 第三步设计双通道Fallback机制Fail-Safe Design生成式模块必须有优雅的降级方案。我们设计了双通道Fallback一级Fallback毫秒级当生成模块超时150ms或输出格式错误立即切换至向量召回延迟增加5ms二级Fallback秒级当生成条件经业务校验后无匹配商品召回数0触发“条件松弛”机制——自动放宽一个约束如去掉price区间、扩大color范围重新生成并校验最多尝试2次。这个机制上线后生成式模块的P99延迟稳定在132ms整体搜索成功率从99.1%提升至99.7%。关键经验是Fallback不是备胎而是主链路的一部分它的性能必须和主流程同等对待。4.4 第四步效果验证的黄金指标Not Just RecallK别只盯着Recall50。我们定义了四个核心验证指标全部线上实时监控指标计算方式达标线为什么重要Gen-Valid-Rate生成JSON通过语法校验的比例≥98.5%衡量模型稳定性低于此值说明prompt或微调出问题Biz-Check-Pass通过业务规则校验品牌/品类/价格的比例≥95.0%衡量知识注入和规则引擎有效性Diversity-Score召回商品在品类、品牌、价格带的Shannon熵值提升≥15%防止生成条件过于集中保障用户体验广度Click-Through-Gain生成式召回商品的CTR vs 向量召回商品CTR≥8%终极业务指标证明用户认可生成结果特别强调Diversity-Score我们发现单纯追求高Recall会导致生成条件越来越保守如所有query都生成“Nike运动鞋”反而降低用户体验。所以必须用熵值量化多样性并将其纳入模型训练的reward函数。4.5 第五步灰度发布与渐进式切流Canary Release我们没用简单的百分比切流而是按query难度分层Level 1易明确包含品牌品类的query如“Nike Air Force 1”生成式模块只负责补充风格标签切流100%Level 2中含明星/风格但缺品类的query如“刘亦菲同款”切流50%A/B测试效果Level 3难纯描述性query如“小众不撞款生日礼物”切流5%重点观察bad case。每层切流后监控上述四个黄金指标。当Level 2连续3天达标才开放Level 3。这种分层法让我们在上线首周就捕获了关键问题Level 3中“小众”一词被模型过度解读为“冷门小品牌”导致召回大量低销量商品。我们立刻调整prompt加入约束“小众指设计独特、非大众爆款但需保证月销≥50件”。这种基于真实数据的快速迭代是灰度发布的最大价值。4.6 第六步建立人工反馈闭环Human-in-the-Loop再好的自动化也需要人把关。我们开发了一个轻量级运营后台Bad Case上报搜索PM看到bad case一键截图标注问题类型如“品牌错误”“风格不符”自动聚类系统按问题类型、query pattern、生成条件字段自动聚类样本注入聚类后的人工标注样本4小时内加入微调数据集次日凌晨模型自动重训。这个闭环让模型迭代周期从“周级”压缩到“小时级”。最典型的一次运营上报“生成条件含‘儿童’但用户是成人”系统聚类发现是prompt中“USER_PROFILE”字段解析错误。修复后同类问题下降92%。生成式系统不是建完就结束而是启动了一个持续进化的人机协作引擎。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 问题生成条件看似合理但召回商品全是滞销款CTR不升反降现象上线后发现生成式召回的Recall50提升明显但用户点击率CTR只2%远低于预期的8%。排查思路先查Diversity-Score发现熵值下降说明生成条件过于集中在低价位、老款商品再查Biz-Check-Pass日志发现“价格区间”校验过于宽松模型常生成“100-500元”而得物该品类热销款集中在300-800元最后看人工反馈运营上报多例“生成条件正确但召回商品图片质量差、详情页简陋”。根因与解决 根本原因是生成模块只管“条件正确”不管“商品质量”。我们增加了“商品质量权重”到后处理环节对生成的category优先召回“近30天销量Top20%”、“详情页图片数≥5”、“用户好评率≥4.8”的商品。同时调整prompt加入约束“优先匹配近90天有销售记录的商品”。修改后CTR一周内拉升至7.3%。实操心得生成式召回的价值不仅是“找得到”更是“找得好”。必须把商品质量信号销量、评价、内容丰富度作为生成条件的隐式约束而不是事后筛选。5.2 问题图文混合query中图片描述错误导致生成条件全盘失效现象用户上传一张“黑色托特包”照片但生成条件里出现“主色白色”召回结果完全偏离。排查思路查CV模型日志发现该图片因反光被误判为“浅色系”查生成模块输入确认传入的IMAGE_DESC确实是“主色白色”查端到端链路发现CV模型输出后缺少对置信度的校验。根因与解决 CV模型对“主色”的识别置信度阈值设为0.6而这张图的置信度只有0.58本应触发人工审核或降级但代码漏掉了这个判断。我们补上校验逻辑当任一关键属性主色、包型、材质置信度0.7IMAGE_DESC字段清空降级为纯文字query处理。同时为提升鲁棒性CV模型增加“多区域采样”——对图片分9宫格分别提取主色取出现频次最高的3个颜色作为最终结果。这个改动让图文混合query的准确率从81%提升至94%。注意多模态系统里任何一个模块的误差都会被放大。必须为每个上游模块设置“可信度熔断机制”而不是盲目信任输入。5.3 问题热点事件爆发时生成条件滞后错过流量高峰现象某明星突然官宣恋情相关“同款”query暴增300%但生成式模块召回率在爆发后2小时才回升。排查思路查知识注入管道发现热点词典是T1更新凌晨同步查模型缓存发现LLM对“新事件”的泛化能力弱依赖知识注入查人工运营流程热点词典需运营手动录入平均响应时间1.5小时。根因与解决 我们重构了热点响应机制① 接入微博热搜API实时监听TOP50热搜词② 对含“同款”“穿搭”“风格”等关键词的热搜自动触发“热点词典预生成”——用规则模板如“{热搜词}同款{品类}”批量生成100个潜在query③ 这些预生成query的召回条件提前缓存到Redis热点爆发时直接命中。改造后热点响应时间从小时级压缩到秒级。最成功的一次某综艺播出后“节目同款”query在15秒内生成条件准确率即达92%。实操心得生成式系统不是静态的它必须具备“感知-响应-学习”的实时能力。把热点响应做成自动化流水线而不是依赖人工救火。5.4 问题模型微调后在测试集上准确率很高但线上bad case激增现象离线测试Gen-Valid-Rate 99.5%但线上监控显示首日Bad Case上报量是向量召回的3倍。排查思路查bad case分布发现87%集中在“风格描述类”query如“慵懒风”“Y2K”查测试集构成发现测试集里“慵懒风”样本只有200条且多为买手标注的规范表达查线上query发现用户真实表达是“看起来不想上班但很贵的那种衣服”模型无法映射到“慵懒风”。根因与解决 测试集严重缺乏“用户口语化表达”样本。我们立即启动“口语化样本采集计划”① 抽取线上query日志用规则筛选含“看起来”“感觉”“像”“那种”等口语词的query② 交由买手团队标注其对应的标准风格标签③ 将这批5000条样本加入微调数据集。同时在prompt中强化指令“用户口语表达需映射到得物标准风格标签如‘看起来不想上班但很贵’→‘慵懒风’”。两周后口语化query的准确率从41%提升至89%。关键教训模型的瓶颈不在算力而在数据的“真实性”。线上bad case是最好的数据来源必须建立快速采集-标注-注入的闭环。6. 工具与资源清单一份可直接抄作业的实战装备表6.1 模型与框架选型清单已验证类别推荐方案选型理由替代方案慎用基础模型Qwen-7B-Chat中文理解强、7B规模适配A100、社区支持完善、license允许商用Llama-3-8B中文弱、ChatGLM3-6B推理慢微调框架HuggingFace PEFT LoRA资源占用低、支持热更新、社区案例多Full Fine-tuning显存爆炸、QLoRA精度损失推理引擎vLLMP99延迟120ms、支持连续批处理、GPU利用率85%Text Generation Inference配置复杂、llama.cpp功能少知识注入Redis CSV快照延迟5ms、运维简单、支持热更新MilvusOverkill、PostgreSQL延迟高规则引擎Drools业务规则可视化、热部署、与Java生态无缝集成自研脚本难维护、Python rule engine性能差6.2 关键配置参数速查表得物实测最优值模块参数推荐值调优说明LLM推理max_new_tokens512生成JSON需足够长度但过长增加延迟temperature0.3降低随机性保证输出稳定性top_p0.85平衡多样性与准确性知识注入热点词典更新频率实时API触发避免T1延迟商品图谱快照频率每日02:00平衡新鲜度与系统负载Fallback机制生成超时阈值150ms确保P99延迟可控条件松弛次数2次防止无限循环效果监控Gen-Valid-Rate报警阈值98.0%需立即介入Click-Through-Gain基线8%业务验收红线6.3 避坑指南那些踩过三次才总结出的经验不要试图用生成式解决所有问题纯品牌词如“Nike”、型号词如“iPhone 15 Pro”交给传统检索生成式专注解决“模糊意图”场景。混用才能发挥各自优势。Prompt里的业务红线必须可执行写“禁止生成违禁品”不如写“禁止生成品类ID在[1001,1005,1009]列表中的商品”前者是口号后者是代码。监控要深入到字段级不仅要监控“生成成功”还要监控“style字段准确率”、“color字段准确率”因为不同字段的错误影响完全不同。人工反馈必须闭环到模型上报的bad case如果48小时内没进入训练集这个机制就形同虚设。我们用钉钉机器人自动提醒标注同学确保T1完成。成本意识贯穿始终7B模型单卡支撑350 QPS但如果用13B同样硬件只能撑120 QPS成本翻倍。规模选择永远基于ROI计算而非“越大越好”。我在得物落地这个项目时最大的体会是生成式召回不是给旧系统装个炫酷插件而是重新定义搜索工程师的工作界面——你不再只是调参、换模型、刷指标而是要深度理解业务规则、用户心理、商品知识然后把这些“软知识”变成模型能执行的“硬约束”。当看到运营同学说“终于不用半夜改词典了系统自己学会猜用户心思”那一刻比任何技术指标都让人踏实。这个范式跃迁的终点不是让AI更像人而是让人能更专注于创造真正有价值的东西。