1. 从“卷向量”到“生成式召回”一次搜索架构的认知刷新得物交易搜索团队最近做了一件在圈内挺有讨论度的事把召回链路从传统的“向量检索为主”切换到“生成式召回”范式。这不是小修小补而是把整个召回层的设计哲学换了个方向。我第一时间看到这个标题时的反应是——终于有人把这件事从论文里拽到真实交易场景里跑通了。先说清楚这个项目到底在做什么。得物是一个交易属性极强的平台用户搜索行为带着明确的购买意图比如“AJ1 低帮 白红 42码”“北面冲锋衣 男 春秋”。这类query的特点是短、碎、强意图、带大量结构化属性品牌、品类、尺码、颜色、季节。传统做法是把query和商品都编码成向量然后在向量空间里做近邻检索。这套方案在过去几年几乎是搜索召回的标准答案但得物团队发现在交易搜索这个特定场景下纯向量检索开始遇到天花板。为什么因为交易搜索的query往往不是“语义相似”就能解决的。用户搜“AJ1 低帮 白红”他真正想要的是“Air Jordan 1 Low 白色红色配色”而不是“看起来像AJ1的某双鞋”。向量检索擅长捕捉模糊语义但在精确属性匹配、多条件组合、长尾query上召回率和准确率都会明显下滑。更关键的是向量检索的“召回”本质上是检索一个预先建好的索引索引里没有的东西就永远召不回来——这在商品SKU快速变化的交易场景里是个硬伤。生成式召回的核心思路是不再从索引里“找”而是让模型“生成”可能相关的商品标识或属性组合。这背后依赖的是LLM大语言模型和多模态模型的能力跃迁。LLM可以理解query的深层意图甚至补全用户没说出来的条件多模态模型则可以把商品的主图、标题、属性文本统一处理让召回不再局限于文本向量空间。这个项目适合谁看如果你是搜索/推荐方向的工程师正在纠结召回链路怎么优化这篇内容会给你一个完整的范式迁移思路。如果你是算法团队的技术负责人在评估要不要把LLM引入核心搜索链路这里的工程取舍和踩坑记录会帮你少走弯路。哪怕你只是对“生成式AI怎么落地到真实业务”感兴趣得物这个案例也足够具体能让你看到从论文到生产的完整距离。我接下来会从设计思路、核心细节、实操过程、问题排查四个维度把这个项目的里子面子都拆开讲。不是复述官方通稿而是以一个从业者的视角把那些文档里不会写的判断逻辑和踩坑经验都摊出来。2. 内容整体设计与思路拆解2.1 为什么纯向量检索在交易搜索里会“卷不动”得物交易搜索的query分布有个很明显的特征头部query高度集中但长尾query极其分散且变化快。比如“Dunk 熊猫 女 36”“椰子 350 黑武士 男 42.5”这类query每天都有新的组合出现。向量检索的底层逻辑是“先建索引再查索引”索引的更新周期和商品上新周期之间存在天然的时间差。一个新款球鞋上架后如果索引还没更新用户搜相关关键词就召不回来这在交易场景里直接意味着GMV损失。更深层的问题是向量检索的相似度计算是“整体性”的。它把query编码成一个稠密向量商品也编码成一个稠密向量然后算余弦相似度。这种做法的好处是能捕捉语义相似坏处是“属性级别的精确匹配”会被稀释。比如用户搜“白红 AJ1 低帮”向量检索可能会召回“白红 AJ1 中帮”或者“白蓝 AJ1 低帮”因为整体语义相似度很高但属性组合并不精确。在交易场景里这种“差不多”的召回结果用户根本不买账。还有一个容易被忽略的点向量检索的召回上限受限于索引规模和检索算法的精度。ANN近似最近邻算法在召回率和延迟之间要做权衡想要高召回就得牺牲延迟想要低延迟就得接受召回损失。得物这种级别的交易平台每天亿级搜索请求延迟敏感度极高纯向量检索的召回天花板很快就摸到了。2.2 生成式召回到底“生成”的是什么很多人第一次听到“生成式召回”会懵召回不是检索吗怎么变成生成了这里的“生成”不是让模型写一段文案而是让模型直接生成“可能相关的商品ID列表”或者“商品属性组合”。具体来说得物团队的做法是把用户query输入LLM让LLM输出一组结构化的商品标识比如SPU ID、SKU ID或者属性约束条件品牌耐克品类篮球鞋配色白红帮高低帮。然后系统根据这些生成的标识或条件去商品库做精确匹配。这个思路的巧妙之处在于它把“召回”从“相似度计算”变成了“条件生成精确匹配”。LLM负责理解query意图并补全隐含条件精确匹配负责保证属性级别的准确性。两者结合既解决了向量检索在属性匹配上的模糊性又绕开了索引更新滞后的问题——因为生成的是条件条件可以直接查实时商品库。但这里有个关键前提LLM必须对商品体系有足够的“知识”。得物团队的做法是把商品标题、属性、类目体系通过指令微调的方式注入LLM让模型学会“得物式”的商品表达。比如用户搜“椰子”模型要知道这指的是Yeezy系列而不是椰子鞋垫或者椰子水。这种领域知识的注入是生成式召回能跑通的基础。2.3 多模态在召回链路里扮演什么角色交易搜索的query不只是文本商品也不只是标题。得物的商品主图承载了大量信息配色、款式、材质、联名标识。用户搜“倒钩 AJ1”时纯文本匹配可能召回一堆标题里带“倒钩”但实际不是Travis Scott联名的商品。多模态模型的作用就是把商品主图和文本描述统一编码让召回阶段能同时利用视觉和文本信号。得物团队用的是CLIP类的多模态模型做商品侧的特征提取然后在生成式召回阶段LLM生成的属性条件会同时作用于文本字段和视觉特征。比如LLM生成“联名方Travis Scott鞋型Air Jordan 1 Low配色棕色系”系统会同时检索标题里包含这些关键词的商品以及主图视觉特征匹配这些条件的商品。两条路的结果做融合排序召回准确率比纯文本方案提升明显。多模态的另一个价值是处理“以图搜图”场景。得物用户经常上传一张球鞋照片来搜同款这时候query本身就是图像。多模态模型可以直接把图像编码成条件向量再结合LLM生成的文本条件做联合召回。这种多模态融合的召回方式在传统向量检索架构里很难优雅实现但在生成式框架下反而很自然——因为生成的条件本身就是结构化的文本条件和视觉条件可以拼在一起做联合查询。2.4 范式跃迁的代价与收益怎么算任何架构升级都要算账。生成式召回的收益很明显召回率提升、长尾query覆盖更好、属性匹配更精确、索引更新滞后问题被绕过。但代价也不小LLM推理延迟远高于向量检索生成式召回的响应时间通常在百毫秒级而向量检索可以做到十毫秒级。得物团队的解法是分层召回头部高频query走缓存或轻量模型长尾query才走完整LLM生成链路。这样既保证了长尾覆盖又控制了整体延迟。另一个代价是工程复杂度。向量检索的链路很成熟编码、建索引、查索引、返回结果。生成式召回要引入LLM推理服务、条件解析模块、多模态特征提取、联合查询引擎每个环节都有新的故障点。得物团队在初期踩了不少坑比如LLM生成的商品ID格式不对导致查询失败、多模态特征和文本条件冲突导致召回为空、LLM推理超时拖垮整个链路。这些问题的排查和解决我后面会详细展开。从投入产出比来看得物团队的数据是生成式召回上线后长尾query的召回率提升了约30%交易转化率有可观测的正向变化。考虑到得物的搜索流量基数这个提升带来的GMV增量相当可观。但团队也强调这不是“替换”向量检索而是“补充”——头部query仍然走向量检索保证低延迟生成式召回主要覆盖长尾和复杂query。3. 核心细节解析与实操要点3.1 LLM选型与领域微调的关键决策得物团队在LLM选型上做了几轮对比。最初考虑过直接用开源大模型做zero-shot推理但实测发现通用模型对得物商品体系的理解几乎为零。用户搜“Dunk 熊猫”通用模型可能生成“熊猫玩偶”相关的商品ID完全跑偏。后来团队转向领域微调路线用得物的商品标题、属性、类目数据构造指令微调数据集让模型学会“得物式”的商品理解。微调数据的构造是个细致活。团队从历史搜索日志里挖掘“query-点击商品”对把点击商品的结构化属性作为监督信号。比如query“AJ1 低帮 白红 42”点击商品的属性是“品牌Air Jordan鞋型1 Low配色白红尺码42”模型要学会从query生成这组属性条件。训练数据量级在百万级覆盖了得物主要的商品类目。选型上团队最终用的是中等规模的LLM参数量在十亿级别而不是最大的模型。原因是推理延迟和成本。十亿级模型在领域微调后生成属性条件的准确率已经能满足召回需求而推理延迟可以控制在可接受范围内。更大的模型虽然zero-shot能力更强但推理成本高出一个数量级在召回这种高并发场景里不划算。实操心得领域微调的数据质量比数量更重要。得物团队最初用了一千万条训练数据但其中大量是噪声样本比如query和点击商品不匹配导致模型学偏。后来清洗到三百万条高质量数据效果反而更好。清洗的标准是query和点击商品的属性匹配度必须达到一定阈值且点击行为不是误触。3.2 生成条件的结构化解析与校验LLM生成的输出是自然语言文本但召回系统需要的是结构化条件。得物团队在LLM和召回引擎之间加了一个“条件解析与校验”模块。这个模块做三件事第一把LLM输出的文本解析成键值对格式品牌、品类、属性、尺码等第二校验条件的合法性比如尺码必须在得物支持的尺码范围内第三对条件做优先级排序核心条件必须匹配辅助条件可以放宽。解析环节用的是规则小模型结合的方式。规则负责处理高频的固定表达比如“42码”直接映射到尺码字段小模型负责处理模糊表达比如“偏大”“修身”这类主观描述。校验环节会过滤掉明显非法的条件比如LLM生成了“品牌阿迪达斯”但query里明确写了“耐克”这种冲突条件会被拦截并触发重新生成。条件优先级排序是个容易被忽略但很关键的细节。得物团队把条件分成三档硬条件品牌、品类、鞋型、软条件配色、材质、联名、可放宽条件尺码、季节。召回时硬条件必须精确匹配软条件做加权匹配可放宽条件允许一定范围的模糊匹配。这样既保证了召回精度又避免了条件过严导致召回为空。注意LLM生成的条件不一定总是对的。得物团队遇到过模型把“AJ1”生成成“AJ11”的情况原因是训练数据里这两个鞋型的query表达有重叠。解法是在校验模块里加入“query-条件一致性检查”用一个小分类模型判断生成的条件是否和原始query语义一致不一致就丢弃或重新生成。3.3 多模态特征与文本条件的融合策略多模态融合在召回阶段有两种做法早期融合和晚期融合。得物团队用的是晚期融合——文本条件和视觉特征分别检索然后对两路结果做融合排序。早期融合把视觉特征和文本特征拼成一个向量再检索在实验中发现效果不稳定因为视觉特征和文本特征的尺度差异大直接拼接容易导致某一模态主导召回结果。晚期融合的具体实现是LLM生成文本条件后一路走文本检索匹配商品标题和属性字段一路走视觉检索用CLIP类模型编码商品主图和query的图像特征做相似度匹配。两路各返回Top-K结果然后用一个轻量级排序模型做融合。融合模型的输入包括文本匹配得分、视觉相似度得分、商品历史点击率、价格区间匹配度等特征。视觉检索的索引构建是个工程难点。得物的商品主图数量在亿级每张图都要用多模态模型编码成向量然后建ANN索引。团队用的是分片量化的方案把商品按类目分片每个分片单独建索引查询时只查相关类目的分片。量化方面用的是PQ乘积量化把向量压缩到原大小的十分之一检索速度提升明显精度损失控制在可接受范围内。实操心得多模态融合的权重需要根据query类型动态调整。得物团队发现当query包含明确的文本属性比如“白红”“低帮”时文本检索的权重应该更高当query是纯图片或者模糊描述比如“那双很火的联名鞋”时视觉检索的权重应该更高。他们用一个轻量级分类模型判断query类型然后动态调整融合权重效果比固定权重好很多。3.4 召回结果的后处理与去重逻辑生成式召回的一个副作用是LLM可能生成多个相似的条件组合导致召回结果大量重复。比如用户搜“AJ1 低帮”LLM可能生成“品牌Air Jordan鞋型1 Low”“品牌AJ鞋型1 Low”“品牌Air Jordan鞋型1 Low帮高低帮”三组条件这三组条件召回的商品高度重叠。得物团队在后处理阶段加了去重逻辑先按商品ID去重再按SPU去重最后按“商品标题主图”的相似度做语义去重。去重之后还有排序。生成式召回的排序和传统向量检索不同因为每个商品可能被多组条件召回每组条件的置信度不同。得物团队的做法是给每组条件一个置信度分数来自LLM的生成概率或校验模块的评分商品被多组条件召回时取最高置信度作为该商品的召回分数。然后结合商品的历史CTR、价格、库存等特征做最终排序。后处理阶段还有一个重要环节多样性控制。交易搜索的召回结果如果全是同一款鞋的不同尺码用户体验会很差。得物团队在排序阶段加入了类目多样性和价格带多样性的约束确保召回结果覆盖不同价位、不同风格的商品。这个约束是通过MMR最大边际相关性算法实现的在相关性和多样性之间做平衡。4. 实操过程与核心环节实现4.1 从零搭建生成式召回链路的完整步骤得物团队把整个链路的搭建分成五个阶段每个阶段都有明确的交付物和验收标准。我按他们的实际推进顺序来拆解。第一阶段是数据准备。团队从搜索日志里抽取了最近半年的query-点击商品对清洗后得到约三百万条高质量训练样本。每条样本的格式是query文本、点击商品的SPU ID、商品的结构化属性品牌、品类、鞋型、配色、尺码等。同时团队还构造了负样本从曝光未点击的商品里随机采样作为对比学习的数据。第二阶段是LLM微调。团队选了一个十亿参数级别的开源模型作为基座用LoRA低秩适配做指令微调。训练目标是让模型学会从query生成结构化的商品属性条件。训练时用了A100集群batch size设为64学习率用余弦退火策略训练了约三天。验收标准是在留出的测试集上模型生成的属性条件与真实点击商品属性的匹配率达到85%以上。第三阶段是条件解析与校验模块的开发。这个模块用Python实现核心是一个规则引擎加一个小型分类模型。规则引擎处理高频的固定表达分类模型处理模糊表达。校验模块的验收标准是对LLM输出的解析准确率达到95%以上非法条件的拦截率达到99%。第四阶段是多模态特征提取与索引构建。团队用CLIP类模型对商品主图做编码每张图输出一个512维的向量。然后用Faiss建ANN索引索引类型选的是IVF-PQ聚类中心数设为4096PQ分段数设为64。索引构建完成后用一批测试query做召回率验证确保视觉检索的召回率不低于文本检索的80%。第五阶段是链路联调和上线。团队先把生成式召回和向量检索并行跑用A/B测试对比效果。初期只对10%的长尾query开放生成式召回观察延迟和召回率指标。稳定后逐步扩大流量比例最终覆盖了约40%的query量。整个联调周期约两个月期间修复了十几个工程问题。4.2 LLM推理服务的部署与性能优化LLM推理是整条链路里最耗时的环节。得物团队最初用单机部署推理延迟在500毫秒以上完全无法满足搜索的延迟要求。后来做了几轮优化把延迟压到了100毫秒以内。优化手段主要有四个。第一是模型量化把FP16的模型量化到INT8推理速度提升约40%精度损失控制在1%以内。第二是推理引擎替换从原生PyTorch切换到ONNX Runtime利用图优化和算子融合加速。第三是请求批处理把多个query的推理请求合并成一个batch提高GPU利用率。第四是缓存对高频query的生成结果做缓存命中缓存时直接返回不走模型推理。缓存策略的设计有个细节得物团队用的是两级缓存。第一级是精确缓存query文本完全一致时命中第二级是语义缓存query文本不同但语义相似时命中。语义缓存用向量相似度做匹配阈值设得比较高0.95以上避免缓存污染。两级缓存加起来高频query的缓存命中率能达到60%以上大幅降低了LLM推理的压力。注意模型量化后需要重新做一轮效果验证。得物团队发现INT8量化后模型在长尾query上的生成质量有轻微下降尤其是涉及复杂属性组合的query。解法是对量化后的模型做一轮小规模的领域微调用少量高质量数据把损失补回来。4.3 多模态索引的构建与查询流程多模态索引的构建分三步。第一步是商品主图预处理把商品主图统一裁剪成224x224做归一化处理。第二步是特征提取用CLIP类模型的图像编码器把每张图编码成512维向量。第三步是索引构建用Faiss的IVF-PQ索引把向量存入索引文件。查询流程是这样的用户发起搜索请求后系统先判断query类型。如果是纯文本query走LLM生成文本条件然后文本检索和视觉检索并行执行。视觉检索时系统会用同一个CLIP模型的文本编码器把query编码成文本向量然后在图像索引里做跨模态检索。如果是图片query系统直接用图像编码器编码query图片然后在图像索引里做图搜图。跨模态检索的精度是个挑战。CLIP类模型在通用场景下表现不错但在得物这种垂直领域商品主图的风格高度统一白底、正面、多角度通用CLIP模型的区分度不够。得物团队的做法是用得物的商品图文对做了一轮对比学习微调让模型学会区分“AJ1低帮白红”和“AJ1低帮白蓝”这种细粒度差异。微调后的模型在内部测试集上的Top-10召回率提升了约15%。4.4 召回效果评估与A/B测试设计评估生成式召回的效果不能只看召回率还要看下游指标。得物团队设计了一套多层评估体系第一层是离线指标包括召回率、准确率、覆盖率第二层是在线指标包括点击率、转化率、搜索跳出率第三层是业务指标包括GMV、客单价、复购率。离线评估用的是历史搜索日志构造的测试集。团队从日志里抽取了十万条query每条query标注了真实相关的商品集合。评估时对比生成式召回和向量检索的召回率、准确率、F1值。结果显示生成式召回在长尾query上的召回率提升约30%在头部query上和向量检索持平。在线A/B测试的设计有个关键点分流要按query类型分层。得物团队把query分成头部、腰部、长尾三层每层独立分流确保实验组和对照组的query分布一致。实验周期设为两周覆盖了工作日和周末的不同流量模式。在线指标显示实验组的点击率提升了约5%转化率提升了约3%搜索跳出率下降了约8%。实操心得A/B测试的周期不能太短。得物团队最初设了一周结果发现周末的流量模式和工作日差异很大一周的数据不能代表整体。后来延长到两周指标才稳定下来。另外实验组和对照组的商品池要一致否则商品上新或下架会影响实验结果的可比性。5. 常见问题与排查技巧实录5.1 LLM生成条件为空或格式错误怎么排查这是上线初期最常见的问题。表现是用户搜了一个正常query但LLM没有生成任何条件或者生成的条件格式不对导致召回引擎解析失败。排查思路分三步。第一步检查LLM的输入。得物团队发现有些query包含特殊字符比如emoji、生僻字LLM的tokenizer处理不了导致输入被截断或乱码。解法是在输入LLM之前做一轮文本清洗过滤掉特殊字符把生僻字转成拼音或近义词。第二步检查LLM的输出。有些query的意图太模糊比如“那个”“这个”LLM无法生成有效条件。这时候需要触发兜底策略用query的原始文本直接做文本检索或者用向量检索兜底。得物团队的兜底策略是LLM生成失败时自动降级到向量检索保证召回不为空。第三步检查解析模块。有时候LLM生成的文本格式是对的但解析模块的规则没覆盖到。比如LLM生成了“品牌耐克”但解析模块只认“品牌耐克”的格式。解法是让解析模块支持多种分隔符和表达方式同时加日志记录把解析失败的case收集起来做规则迭代。5.2 多模态检索结果与文本检索结果冲突怎么处理冲突的典型表现是文本检索召回了“AJ1低帮白红”视觉检索召回了“AJ1低帮白蓝”两路结果融合后排序混乱。得物团队的解法是引入一个“冲突检测”模块当两路结果的属性差异超过阈值时触发人工规则或小模型仲裁。仲裁的逻辑是优先信任文本检索的结果因为文本条件来自LLM的生成置信度可量化视觉检索的结果作为补充只在文本检索结果不足时才提升权重。具体实现是融合排序时文本匹配得分乘以一个较高的权重系数比如0.7视觉相似度得分乘以较低的权重系数比如0.3。当文本检索结果数量少于阈值时动态提升视觉权重。还有一种冲突是“视觉相似但文本不匹配”。比如用户搜“AJ1低帮”视觉检索召回了一双“AJ1中帮”因为两者主图角度相似。这种冲突靠权重调整解决不了需要在视觉检索阶段加一个“帮高分类器”把帮高作为硬过滤条件。得物团队训练了一个轻量级的帮高分类模型在视觉检索返回结果后做二次过滤把帮高不匹配的商品剔除。5.3 召回延迟突然飙升的紧急排查路径延迟飙升是生产环境最危险的问题。得物团队遇到过几次排查路径总结如下。先看LLM推理服务的监控。如果GPU利用率突然打满说明推理请求量激增或者有长尾query导致推理时间变长。解法是临时扩容推理实例或者对超长query做截断处理。再看缓存命中率。如果缓存命中率突然下降说明有大量新query涌入缓存没覆盖到。解法是临时调低语义缓存的相似度阈值让更多query命中缓存同时观察召回质量是否下降。再看多模态索引的查询延迟。如果视觉检索的延迟飙升可能是索引分片不均匀导致某些分片过载。解法是重新平衡分片或者临时降级到只走文本检索。最后看下游存储的查询延迟。生成的条件最终要查商品库如果商品库的查询延迟高整条链路都会慢。解法是给商品库加缓存或者把高频查询结果预计算好。注意延迟排查要有优先级。得物团队的顺序是先保可用性降级到向量检索再查根因。不要为了查根因让整个搜索不可用这是生产环境的大忌。5.4 常见问题速查表问题现象可能原因排查方法解决方案LLM生成条件为空query含特殊字符或意图模糊检查LLM输入输出日志文本清洗兜底向量检索条件解析失败解析规则未覆盖生成格式查看解析失败日志扩展解析规则日志迭代多模态结果冲突文本和视觉权重固定对比两路结果属性差异动态权重冲突仲裁模块召回延迟飙升LLM推理过载或缓存失效检查GPU利用率和缓存命中率扩容调低缓存阈值降级召回结果重复LLM生成多组相似条件统计商品ID重复率后处理去重条件合并长尾query召回差训练数据覆盖不足分析长尾query的生成质量补充长尾训练数据微调视觉检索精度低通用CLIP模型区分度不够测试细粒度商品区分领域对比学习微调缓存污染语义缓存阈值过低检查缓存命中后的召回质量提高相似度阈值缓存淘汰5.5 几个只有踩过坑才知道的细节第一个细节LLM生成的商品ID需要做格式校验。得物团队遇到过LLM生成了不存在的SPU ID导致查询返回空结果。解法是在生成后加一个ID存在性校验不存在的ID直接丢弃同时记录日志用于模型迭代。第二个细节多模态索引的更新频率要和商品上新频率对齐。得物的商品上新很快如果索引更新滞后新商品的视觉特征就搜不到。团队把索引更新做成了准实时商品上新后触发特征提取和索引插入延迟控制在分钟级。第三个细节A/B测试的指标要看长期。得物团队发现生成式召回上线初期点击率提升明显但两周后趋于平稳。原因是用户对新召回结果的新鲜感消退。所以评估时要看稳定期的指标而不是上线初期的峰值。第四个细节LLM的推理成本要算清楚。得物团队算过一笔账生成式召回的LLM推理成本是向量检索的几十倍但只覆盖40%的query量整体成本增加在可接受范围内。如果全量替换向量检索成本会失控。所以分层召回不仅是性能考虑也是成本考虑。6. 这套范式还能怎么延展得物这个项目跑通之后我一直在想它的延展空间。生成式召回的本质是“用生成模型做意图理解和条件补全”这个思路不局限于交易搜索。比如内容社区的搜索可以用LLM生成“内容标签”而不是“商品ID”然后按标签召回。再比如本地生活搜索可以用LLM生成“服务类型地理位置时间约束”的条件组合然后做精确匹配。多模态的延展空间更大。得物目前主要用主图做视觉召回但商品还有视频、用户评价图、买家秀。这些多模态信号如果都能纳入召回链路召回精度还能再上一个台阶。技术上需要解决的是多模态特征的统一编码和联合索引这块得物团队还在探索。LLM的领域微调也有优化空间。得物目前用的是十亿级模型如果换成更大的模型做蒸馏把小模型的能力再提一提召回质量可能还有提升。或者用MoE混合专家架构让不同类目的query走不同的专家模型推理效率和效果都能兼顾。最后说个我自己的判断生成式召回不会完全替代向量检索两者是互补关系。向量检索负责“快”和“广”生成式召回负责“准”和“深”。未来的搜索召回架构大概率是分层的头部query走向量检索保延迟长尾query走生成式召回保覆盖中间层做动态路由。得物这个项目最大的价值不是证明了生成式召回有多好而是证明了它在真实交易场景里能跑通、能算得过账。这对整个行业来说是个很有参考意义的信号。