这两年聊搜索召回十个人里有八个开口就是向量检索。我自己的团队也是从向量召回一路做到线上但说实话在得物交易搜索的场景里纯向量路子越走越窄。所以今年我们干脆把重心挪到了另一条路上——生成式召回。不是拿大模型给结果做排序也不是用LLM改写query而是让模型直接“生成”候选商品序列把召回这个环节从“在库里找相似”变成“照着意图现造”。这篇就把我们选型、落地、踩坑的过程完整写出来给正在卷向量检索的同学一个不一样的参考。1. 先聊聊“卷向量检索”这件事1.1 向量检索为什么会被捧上天向量检索这几年确实火得有道理。它把用户query和商品都映射到同一个语义空间用向量距离表达相关性这比纯靠字面匹配的稀疏检索BM25、倒排term权重前进了一大步。好处是显而易见的能处理同义词、近义表达比如用户搜“AJ1 芝加哥 低帮”即使商品标题里写的是“Air Jordan 1 Low Chicago”字面完全不重合稀疏检索很可能直接漏掉向量检索却能在embedding空间里准确找回。从工程实现的角度讲向量检索的生态也成熟得可怕。开源方案一大堆Facebook的faiss是入门标配单机亿级向量可以硬扛上了分布式规模有Milvus或者直接用ES的dense vector插件甚至PostgreSQL的pgvector也能撑起中小业务。我自己在不同项目里都用过faiss的IVFPQ在几百万量级上能把单次检索压在10毫秒内HNSW的召回质量更高但构建索引更吃内存。说实话这些工具把向量召回的门槛压得很低你不需要理解hnswlib里面的图结构细节调几个参数就能上线。更大的推手还是Transformer和对比学习。双塔结构加in-batch负采样一个下午就能训出一个能用的召回模型再往上卷有CLIP那套跨模态对齐的经验迁移过来做图文双塔有利用用户行为序列做兴趣向量抽取的还有用大规模LLM生成伪标签来增强embedding语义的。业界分享一个比一个漂亮指标一个比一个高。在这种氛围下团队如果不碰向量检索出门都不好意思跟人打招呼。但问题恰恰出在这里大家都默认向量召回是“标配底座”很少有人停下来想它在特定业务场景下到底是不是最优解。得物交易搜索就给了我一个很强烈的反面案例。1.2 但向量检索在交易搜索场景里卡在哪得物交易搜索和通用网页搜索、内容搜索有明显的差异核心在于用户带着非常明确的交易意图。搜“AJ1 黑白 低帮 42码”他不是想泛泛了解这个鞋而是想直接找到能买的那个SKU。这个场景下query的信息密度极高——品牌、系列、配色、尺码、价格区间每一个属性都是硬约束。双塔向量模型在这种场景下有几个绕不开的硬伤。第一embedding是“压缩”过的语义它在表达颗粒度上是有限的。你把“AJ1 黑白 低帮”压成一个768维向量和把另一个“AJ1 黑红 低帮”压成的向量在欧式空间里的距离可能非常近但交易结果完全不同一个是黑白配色一个是黑红配色用户看了就是两个东西。第二双塔的query端和item端是独立encode的交互发生在最后一层内积这种结构天然不擅长处理“属性值必须精确匹配”的逻辑。第三向量检索很容易放大头部效应训练数据里高频商品反复出现embedding空间被大爆款占据中长尾商品即便语义正确相似度分数也被压得很低。还有个工程上的蛋疼点向量库也是有维护成本的。类目、品牌、上下架状态变了对应的embedding必须跟着更新训练迭代一版模型全量索引要重建增量同步逻辑要处理各种不一致。我们运维同学有段时间最怕的就是“今天向量索引又挂了”。这些不是不能解决但它提示我们向量检索不是一个可以无脑依赖的银弹。当时我们线上实际遇到一个很典型的case用户搜“科比 6 青峰侠”实际上他想要的是Nike Kobe 6 Grinch配色翻译过来江湖俗称“青蜂侠”。商品的官方标题里只有英文名向量模型靠语义近似勉强能召回来一部分但排在最前面的经常是其他科比系列。真正的交易搜索体验用户希望的是“你说什么它就给什么”不是“它猜你可能想要什么”。这两种范式之间的差距就是我们在思考范式转换时的起点。2. 生成式召回到底在做什么2.1 从“匹配”到“生成”的思维转换先说我理解的生成式召回Generative Retrieval是什么。学术界有一个很直接的想法检索任务可以建模成“给定一个query模型直接产生一个相关文档的ID序列”。最早的代表工作是Google的DSIDifferentiable Search Index和NCI它们的思路是训练一个seq2seq模型像做翻译一样输入query的token序列输出目标文档ID的token序列。也就是说模型本身就是索引不需要外部的向量库或倒排索引来“查”而是直接“答”。放到电商搜索里这个思路就变成输入用户query和上下文模型直接生成相关商品ID的序列。在推理时你不需要做ANN检索不需要跟向量库交互模型自己把所有商品知识“背诵”在参数里。这个想法听起来有点疯狂但它确实在多个数据集上验证了可行性DSI在MS MARCO上甚至能跟双塔掰手腕。我之所以说这是“范式跃迁”是因为它改变了召回的定义。传统召回是在一个固定候选池里做筛选本质是“匹配”生成式召回的候选空间是模型参数里编码的整个商品知识本质是“构造”。匹配的上限受限于索引质量和召回策略构造的上限取决于模型理解query意图的能力。对得物交易搜索来说这个转换最直接的收益是生成式模型天然是“把query中每个词都当硬约束”来用的它会倾向于生成满足所有属性约束的商品而不是像向量那样打一个“总分”来近似。当然这里必须泼一盆冷水生成式召回不是要消灭向量检索。它更像在召回漏斗的最前端增加一个“高精度意图理解”的入口跟其他召回通道做互补。我们内部的口号是“用生成式做头部的精准通道用向量做腰部尾部的泛化通道”后面我会详细说这个混合架构。2.2 三个关键技术要素拆解如果要在得物落地生成式召回技术上有三件事必须先想清楚。第一是商品ID怎么编码。DSI的核心就是把document ID当token但商品ID如果是纯数字模型很难学到数字之间的语义关系。我们的做法是引入“商品描述性标识”——把商品映射成语义化ID序列比如“品牌-系列-型号-配色-尺码”这种结构化标识再结合一个短的随机ID段做区分。这样模型在训练中能学到“科比6”→“Nike Kobe 6”→“这串ID”的映射链路泛化性比纯随机ID好很多。这个点非常关键我后面会展开讲。第二是解码目标怎么定。生成式召回的输出是一个商品序列但trade-off在于beam search解码出来的前K个结果可能高度相似比如全是同一个型号的不同尺码。这时需要做多样性约束我们参考了文本生成里的no-repeat ngram策略同时加了一个按类目分组的多样性惩罚。另外一个问题是生成一个item就需要一个解码步如果解码长度太长延迟会不可控。所以我们在目标侧做成了“先输出一组商品ID再做短路解码”控制最大解码步数在8步以内。第三是训练信号怎么构造。这是最核心的工程问题。我们不能直接套用文本翻译的平行语料因为搜索没有现成的“query→商品”平行数据。可行的做法是从线上搜索日志里提取“query→曝光点击商品”作为弱监督信号再用成交和加购行为加权。还需要处理一个关键问题query和商品的映射是一对多的而且存在大量噪声比如用户搜一个query点了好几个不相关的商品。所以我们对样本做了清洗只保留在同一个session里点击停留超过一定时长、或者有成交行为的样本。这块的数据质量直接决定模型上限我们前前后后花了大约一周半的时间来搭清洗管道。3. 得物交易搜索的生成式召回落地实录3.1 场景分析与方案选型先交代一下我们的约束条件。得物交易搜索的供给是潮流单品核心类目是球鞋、服饰、配饰、潮玩商品总量在百万级SKU的规模。这个规模很关键——它远小于全网网页搜索的百亿量级但又比一般的电商长尾品类大一个量级。百万级商品全部塞进一个seq2seq模型的词表token规模在可控范围内。如果十亿级商品我可能不会考虑生成式做全量召回那个复杂度不是我们当前资源能覆盖的。方案选型时我们对比过三条技术路线第一基于T5的编码器-解码器第二基于LLM的prompt式生成比如让大模型直接输出商品描述再走向量检索第三自研的轻量级seq2seq。LLM路线最酷但我们第一时间排除了。原因很现实线上搜索召回是几毫秒到几十毫秒延迟的链路塞一个十几B的LLM进去无论怎么做蒸馏和量化成本都太高。而且LLM的幻觉问题在交易场景是致命的——它可能生成一个“看起来合理但根本不存在”的商品描述。最终我们选择了第二条路T5-base级别的模型商品侧用语义化ID编码做受限解码配合商品白名单校验。这套组合拳能同时解决成本、延迟和幻觉问题。3.2 训练数据的构造训练数据是整个项目的地基也是我们踩坑最多的地方。我详细讲讲怎么从零开始建这个数据集。第一步是取样本。我们从线上搜索日志里取过去90天的“搜索曝光点击”数据字段包括query、设备信息、曝光商品列表、点击行为序列、后续是否有加购或成交。这里有一个工程师很容易犯的错误直接拿“曝光未点击”当负样本。这在向量召回里很常用但在生成式召回里不行因为我们训练的目标是生成“用户想要的商品ID序列”而不是判断曝光商品是否相关。曝光未点击可能是用户根本没看到不一定是商品不相关。第二步是过滤。我们定了几条清洗规则去掉query长度超过25个字的日志太长的query大多是粘贴复制的意图质量差去掉点击商品少于2个的session去掉商品在窗口期内无任何成交记录的样本去掉明显反爬和机器人行为的session。清洗完之后数据量大概剩原来的40%。这个比例不算高但留下的样本意图质量非常干净。第三步是构造目标序列。我们把一个session内用户点击且有成交的商品按时间顺序排成目标序列没有成交的点击商品排在第二优先级曝光未点击的商品不进目标序列。这里还有一个小技巧我们给目标序列加了“截至当前点击”的相对时间戳让模型学习“用户先看了A又看了B最后买了C”的递进关系。这个设计让模型生成的序列更有“交易推进感”而不只是一堆相似商品的堆积。最后一步是生成训练样本对。我们把query分词后作为source目标序列分词后作为target组织成标准seq2seq格式。为了增强模型的稳定性我们做了数据增强对query做简单的同义词替换比如“鞋”和“球鞋”“白”和“白色”同时用随机裁剪的方式丢弃query中的非核心词。这招实测下来对长尾query的提升很大大概有5%左右的召回率增益。3.3 模型结构与解码细节模型我们选用的是T5-base主要原因是它在seq2seq任务上足够成熟并且我们团队对它的分布式训练和推理部署都比较熟。词表方面source端使用T5的sentencepiece词表target端提前把所有商品语义化ID拆成子词。这里有一个关键选择语义化ID里品牌名Nike、Jordan、系列名Kobe、AJ等高频词保留为整词token型号和尺码拆成分词。这样做的原因是品牌名、系列名是用户query里会直接用到的词需要让模型建立“query里的Jordan”和“target里的Jordan”的直接联系而型号、尺码是商品侧的属性拆分后模型更容易泛化到新商品。训练时有一点跟普通翻译任务不一样我们加入了一个“返回原query”的辅助任务。也就是给模型一部分样本让它的输出不是商品ID而是把用户的query重写一遍。你别小看这个设计它让encoder学到更强的query理解能力并且会在beam search时给解码器一个“稳定锚点”。实测下来这个辅助任务让最终召回率提升了大概2个百分点而且模型在遇到冷门商品时的输出明显更有逻辑性。解码侧我们用的是beam searchbeam size设为8。这里也有一个值得分享的细节如果直接拿beam top 8作为召回结果你会发现里面很可能有5个是同一款商品的不同尺码多样性惨不忍睹。我们的处理是“按类目去重跨类目排序”——先按商品类目分组在组内用beam打分排序每组取top 1或top 2把所有组的头名集合起来再按总分数做一次排序。这样既能保证多样性又不会让排序逻辑失真。这个方案比在打分函数里加惩罚项要稳定得多尤其是面对多类目场景时几乎不需要调参。3.4 线上服务与混合召回架构线上服务我们分了三层。第一层是同步服务接受query后先经过一个轻量的query理解头然后把序列化输入送给T5模型做beam search解码解码结果通过商品映射表还原成真实商品ID列表再走商品过滤上下架、类目黑名单、风控规则。这个同步服务的P99延迟我们压在45毫秒以内靠的是T5-base int8量化 粗粒度batch。第二层是异步的生成通道这个通道不直接服务首屏请求而是提前针对热门query批次生成候选缓存成离线索引用于首屏融合时快速取用。说白了就是一个“离线生成在线读取”的混合模式。热门query一天内的变化不大提前生成既省在线算力又降低了高峰期的延迟压力。第三层跟传统召回融合。我们的排序链路是标准的两阶段召回拿到一批候选粗排过滤精排打分重排做多样性控制。生成式召回生成的候选会直接进入粗排与向量召回、稀疏召回、协同召回的结果做并集。融合策略不是简单的去重拼接而是给每个召回路带一个“通道分”精排模型会把通道分作为特征。一开始我们担心精排模型会因为“生成式通道”分数偏高而学出选择偏好后来通过把通道分做归一化并按场景开关控制权重这个问题基本解决了。有一点必须强调我们不是用生成式取代向量召回而是用它做“精准意图捕捉”。线上同时跑着四个召回通道稀疏倒排召回、双塔向量召回、图协同召回、生成式召回。前三个各司其职生成式召回专门负责那些意图明确、多属性约束强、传统方法容易丢的query。混合架构的收益远大于单通道替换这是我们跑了几轮A/B实验后得到的明确结论。4. 效果评估与实验细节4.1 评估指标与口径评估生成式召回最忌讳直接用传统的RecallK。原因是生成式召回的“候选池”不是固定的它生成的商品ID如果不在预先定义的候选池里算Recall就很不公平——它是被模型“造”出来的而传统召回不可能“造”出不在索引里的商品。所以我们自己定义了一套评估口径内部叫“意向命中率”Intent Hit Rate K看生成的K个商品里有多少是用户真实点击过或购买过的分母是用户点击/购买过的商品集合分子是生成的K个商品与这个集合的交集。这个口径更贴近交易搜索的本质。用户搜“AJ1 芝加哥”系统生成出来的候选里如果有他要的那个配色哪怕那个配色不是热门爆款、不在向量检索的高频索引里它也应该是好召回。意向命中率能捕捉到这种“精准命中”而传统的Recall因为候选池的限制会漏掉“生成出的正确商品”。除了排序和召回指标我们主要关注三个业务指标搜索点击率、点击后转化率、人均成交笔数。这三个指标分别对应召回“找得准不准”、补全“商品详情页接不接得住”、以及最终的交易价值。除此之外还盯住了两个健康度指标召回通道的覆盖率生成的候选在全站商品池的覆盖比例和多样性候选里不同叶子类目、不同品牌的数量。覆盖率和多样性是防止生成式召回“自我强化”过度、只盯着少部分爆款商品的重要手段。4.2 实跑效果观察数据我先说个定性的结论生成式召回不是在所有query上都赢它赢在“硬约束多”的那部分。我们把线上query按意图类型分了四组品牌型“Nike 空军一号”、系列型“AJ1 黑红”、属性型“白色 低帮 板鞋”、泛化型“夏天穿什么鞋好看”。生成式召回在前三组的意向命中率明显高于双塔向量召回大概高出6到9个百分点而在泛化型query上它跟向量召回基本持平偶尔还会低1个百分点。这个结果其实完全在预期之内。生成式模型的优势在于按约束“构造”候选query里的每一个属性词它都会尝试在target序列里去对齐而双塔模型把query整体压成一个向量属性之间的精确关系会被“平均”掉。泛化型query没有硬约束模型容易生成过于具体的商品反而不如向量召回的平滑分布。业务指标上我们把生成式召回作为额外通道全量上线后搜索点击率提升了约1.2%点击后转化率提升了约0.8%人均成交笔数提升了约1.5%。这里面的增量主要来自两类需求一类是“指名道姓”型需求用户说得越具体生成式召回表现得越好另一类是长尾需求那些搜索量不大但意图明确的query传统向量召回被头部商品带偏生成式召回能准确给出用户真正想要的小众商品。这个发现对我们后续优化很有帮助现在我们会用意图分类器提前判断query类型再决定给生成式召回分配多大权重。4.3 向量库还要不要留很多人问既然生成式召回这么猛向量库是不是可以扔了我的答案是短期内绝对不要扔长期看会变成“混合形态”。先说不扔的理由。生成式召回最大的软肋是“知识覆盖不全”。它对训练样本里高频出现的商品学习得很好但对新增商品、超长尾商品、临时促销品的覆盖能力偏弱。模型参数是固定的新增一个商品必须经过训练或至少增量微调才能“认识”它向量库不一样新商品把embedding算出来插进索引就能被检索到秒级生效。电商的供给变化非常快新品、限量发售、清仓活动几乎每天都有如果只靠生成式这些新供给会大面积漏掉。再说不扔的第二个理由生成式召回的“可解释性”是一把双刃剑。它可能生成一个精确命中的商品但你也很难说清楚它为什么生成这个而不是另一个。向量检索至少还能用embedding相似度作为证据。在需要跟业务方解释“为什么这个商品没被召回”的时候向量库的排查路径清晰得多。所以我们的定位是向量库继续承担泛化和新供给召回生成式召回承担精准意图和属性约束召回两者通过融合层协同。短期内的架构形态不会变。我们也在实验“生成式向量”的级联用法——用生成式产出“关键属性集合”再用这些属性去向量库做约束检索这个方向效果还在验证中。5. 踩坑记录与排查方法5.1 生成不存在的商品ID这应该是所有做生成式召回的人都会遇到的问题。模型训练的时候见过商品ID但beam search解码时它完全有可能组合出一个从来没见过的ID——它把品牌token拼错了或者把型号子词组合成了一个不存在的商品。这在交易搜索里是绝对不能容忍的给用户看一个不存在的SKU直接就是事故。我们的解法是双层的。第一层是设计层面target侧用受限解码constrained decoding解码每一步只能在“当前前缀下合法”的商品ID集合中选择下一个token这个合法集合由商品库的ID映射关系实时计算。简单说我们不在算法层面做事后修正而是在解码过程中就不允许非法路径诞生。第二层是工程兜底解码完成后所有商品ID都要过一个商品中心数据库的校验查一遍是否存在、是否在售、是否命中风控策略。如果一个候选被校验拦下来我们不会硬着头皮替换一个相近ID而是直接丢弃让融合层从其他召回通道取候选。这一层拦截宁可多不可少因为安全合规在交易系统里是红线。5.2 头部商品霸榜、多样性崩盘这个坑我们大概踩了两周才彻底解决。生成式模型天生有“马太效应”热门商品在训练语料里出现次数多解码时分数天然偏高于是你发现生成的K个候选里有七个是同一个大爆款的不同码数或不同卖家链接。从单个item的角度看每个都“相关”但从整页结果看用户看到的全是同一个东西体验极差。我们的解决思路是前文提到的“类目分组再融合”策略但这只是第一层。第二层更关键我们给target序列的每个商品标注了“叶子类目”和“品牌”两个元信息训练时在loss中加入一个多样性的正则项——如果解码生成的候选里类目分布过于集中就给这些候选打一个额外的惩罚分。这个正则项不能加太猛否则模型会为了多样性牺牲相关性我们调了一周才找到一个平衡点多样性惩罚只在beam search的最后一步生效不影响中间解码的路径选择。5.3 延迟与吞吐平衡生成式是自回归解码延迟天然比向量检索高一个数量级。向量检索是内存里的hash查找加距离计算单次查询零点几毫秒到几毫秒T5-base的beam search一次生成8个token我们测试下来单query在GPU上大概要8到12毫秒如果跟其他链路串行线上P99会飙到80毫秒以上这在线搜场景是不可接受的。我们做了三件事把延迟压下来。第一int8量化模型体积从400多MB压到120多MB推理加速约2.5倍第二把beam search改成“先生成轮廓再并行查详情”的两段式轮廓阶段只生成8个token详情阶段用一个内存映射表把token映射到商品不走神经网络第三在线服务做了动态batch——把并发请求攒成一个batch送进GPUbatch size在16到32之间时GPU利用率最高吞吐量提升了3倍多。5.4 线上回退与兜底策略搜索系统最怕的不是效果差而是链路故障直接线上资损。生成式召回这种新链路上线之前必须设计好回退方案。我们做了三层兜底整链路熔断、单通道降级、结果兜底填充。整链路熔断的逻辑很简单如果生成式服务的错误率连续10秒超过5%就自动把生成式通道从融合层摘除请求全部走传统通道。这个熔断阈值不能设得太敏感流量抖动会引起频繁开关反而影响体验。我们最终把阈值放在错误率5%、P99延迟超过150毫秒持续20秒这两个条件的“或”关系上。单通道降级就更细了我们会给生成式召回通道设置一个配额当服务不稳定时配额自动从30%降到10%再到0%阶梯式降级。最后的结果兜底填充也很重要如果生成式通道没有产出候选融合层不能让“这个位置空着”必须从向量召回或协同召回的结果里拿相近的商品补位。我们的兜底策略是“类目补位”优先补跟query主类目一致的商品如果主类目没货再补次类目。这个策略业务侧贡献很大因为用户对“搜索没结果”的容忍度很低但有时候“没结果”只是召回通道配合失误不是真没货兜底补位能挽救很多本可以成交的流量。6. 给想跟进的同学一些实在建议6.1 什么样的业务适合生成式召回不是所有搜索场景都适合上生成式召回这个判断比技术选型更重要。我根据这一年的经验总结出三个“适合”和三个“不适合”。适合的是第一商品库规模在千万级以下且商品具有强结构化属性品牌、型号、系列、尺码这样语义化ID编码才有意义第二用户query普遍有明确的交易意图而不是泛泛的浏览意图交易搜索比内容搜索更适合第三业务允许你接受一定比例的“指导式召回”换句话说你愿意让模型直接决定结果而不是把决定权完全交给候选池。不适合的是第一商品库规模过亿且SKU生命周期极短模型根本来不及学更适合靠更新索引解决第二query高度碎片化、口语化比如短视频评论区里的“求链接”这种生成式模型很难建模这种意图第三业务对搜不到结果的容忍度极低、要求绝对不可遗漏的场景生成式的覆盖率短板会被无限放大。6.2 从零到一的最小落地路径如果你们的业务决定尝试生成式召回我建议按这个顺序来可以少走我们走过的弯路。先花两周时间做“语义化ID编码 小规模离线训练”。编码方案是最值得花时间的它决定了整个模型的学习难度。你可以直接拿现有的类目体系拼一个层级编码先别追求完美跑通流程再说。然后做“生成式召回通道的服务化”哪怕只吃一个类目的数据也要把完整的线上链路打通请求进来、模型生成、商品校验、结果输出、监控打点。这一步的目的是验证工程可行性不是为了效果。打通之后再做“与现有召回路融合”。先在离线复盘中看生成的候选与现有召回路的重叠度和互补度再决定融合权重。这里特别提醒别急着让生成式通道全量上线先让它只为一个叶子类目服务比如“篮球鞋”跟大盘对比看增量。最后才是“全量扩展和调优”。全量开发时模型蒸馏、量化、缓存、批量预热这些优化都要安排上但那是后话。最小路径的核心是先证明“生成式召回在这个业务里能产生增量”再投入资源规模化。6.3 知识库与生成式召回的关系最后聊一个跟我们业务关系很密切的话题知识库。市面上讨论生成式AI经常会提到外部知识库接进来增强检索。但交易搜索里的生成式召回跟那种“LLM 向量知识库”的问答式用法有本质区别很多人会搞混。“LLM 向量知识库”的本质仍然是“检索增强生成”它的生成是靠外部知识支撑的模型自己不作知识存储。而我们做的生成式召回恰恰相反是把商品知识“内化”到模型参数里让模型直接输出商品ID。这里不存在外部知识库和向量库的依赖关系。但我们在实践里发现企业内部沉淀的类目知识、品牌知识、属性知识库在生成式召回里依然有重要的用途——它们更多是用于训练数据的构造和校验规则的生成而不是线上推理的依赖项。比如我们会用类目知识库来补齐商品语义化ID里的缺失属性用品牌知识库来确认用户query里的昵称、俗称对应到哪个官方品牌名。这些知识库以离线的方式参与训练样本构造再以校验规则的方式参与线上拦截属于“知识增强生成”的思路而不是“检索增强生成”。把这两者的边界想清楚才不会把架构搞成四不像。我个人在实际操作中最大的体会是生成式召回不是一个“酷炫但遥远”的技术它完全可以作为交易搜索召回的一个真实通道落地。前提是你不要抱着“取代一切”的心态而是把它放在一个合适的位置上。它解决向量检索解决不了的那部分精准意图问题而向量检索继续解决它擅长的那部分泛化召回问题。两者不是替代关系是共同把召回这个漏斗的第一层做得更厚实。最后再分享一个小技巧我们在做生成式召回服务监控时除了常规的延迟、吞吐、错误率一定会盯着一个指标——生成候选在最终曝光列表里的平均位置。如果这个位置持续往后掉说明生成式召回在跟其他召回路竞争的时候在失去优势这往往是数据分布发生变化的预警信号比看任何离线指标都及时。这个指标我们内部叫“生成席位率”推荐你也在自己的系统里加一个。