这两年聊搜索召回，十个人里有八个开口就是向量检索。我自己的团队也是从向量召回一路做到线上，但说实话，在得物交易搜索的场景里，纯向量路子越走越窄。所以今年我们干脆把重心挪到了另一条路上——生成式召回。不是拿大模型给结果做排序，也不是用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的DSI（Differentiable 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 search，beam 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 评估指标与口径
评估生成式召回，最忌讳直接用传统的Recall@K。原因是生成式召回的“候选池”不是固定的，它生成的商品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送进GPU，batch 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里的昵称、俗称对应到哪个官方品牌名。这些知识库以离线的方式参与训练样本构造，再以校验规则的方式参与线上拦截，属于“知识增强生成”的思路，而不是“检索增强生成”。把这两者的边界想清楚，才不会把架构搞成四不像。
我个人在实际操作中最大的体会是：生成式召回不是一个“酷炫但遥远”的技术，它完全可以作为交易搜索召回的一个真实通道落地。前提是你不要抱着“取代一切”的心态，而是把它放在一个合适的位置上。它解决向量检索解决不了的那部分精准意图问题，而向量检索继续解决它擅长的那部分泛化召回问题。两者不是替代关系，是共同把召回这个漏斗的第一层做得更厚实。
最后再分享一个小技巧：我们在做生成式召回服务监控时，除了常规的延迟、吞吐、错误率，一定会盯着一个指标——生成候选在最终曝光列表里的平均位置。如果这个位置持续往后掉，说明生成式召回在跟其他召回路竞争的时候在失去优势，这往往是数据分布发生变化的预警信号，比看任何离线指标都及时。这个指标我们内部叫“生成席位率”，推荐你也在自己的系统里加一个。
