企业官网建设流程全解析

1. 当“搜不准”成为交易搜索的瓶颈，问题到底出在哪

做电商搜索的人大概都有过这种体验：用户搜“适合小个子的显瘦牛仔裤”，传统向量检索返回的结果里，前几条可能是“牛仔裤男直筒宽松”“牛仔裤女高腰”“小个子连衣裙”。字面上看，每个词都沾点边，但用户真正想要的那件商品，可能排在第三页。这不是向量模型不够强，而是召回阶段的信息损耗在作祟。

得物交易搜索面临的场景更极端。商品标题短、属性多、用户 query 口语化严重，还夹杂大量品牌缩写、型号黑话、场景描述。比如“aj1 低帮 北卡蓝 女码”“通勤能装的托特包 不塌”“送男朋友 2000 以内 手表”。这些 query 背后是明确的交易意图，但传统“query 编码 → 向量相似度 → topK”的链路，在第一步就把大量语义压进了一个固定维度的向量里。维度就那么多，信息密度再高也装不下“品牌+型号+颜色+性别+价格+场景”这六个维度的联合约束。

更麻烦的是，交易搜索对召回率的容忍度极低。内容搜索漏掉一篇还可以接受，交易搜索漏掉一个 SPU，用户可能直接跳失。得物团队在公开分享中提到过一个数据：召回阶段每提升 1% 的命中率，下游转化率有可观测的正向波动。这就是为什么“只卷向量检索”越来越卷不动了——向量模型再精调，也解决不了“信息在编码阶段就被压缩”这个结构性问题。

生成式召回的出现，本质上是把“压缩后再匹配”换成了“理解后再生成”。大语言模型不急着把 query 压成一个点，而是先读懂用户到底要什么，再直接生成可能命中的商品标识或属性组合。这个范式跃迁的核心，不是模型变大，而是召回逻辑从“相似度排序”变成了“意图到商品的直接映射”。

2. 生成式召回到底“生成”了什么：从向量点到商品集合的映射

2.1 传统向量召回的三个硬伤

先把传统链路拆开看。Query 经过 tokenizer 变成 token 序列，再过 encoder 变成固定维度向量，然后和商品库的向量做 ANN 检索。这里有三处信息损耗：

第一，query 侧的信息压缩。一个 20 字的 query，经过 BERT 类模型编码后，CLS 向量只有 768 维。这 768 个浮点数要同时表达品类、品牌、属性、场景、价格区间，平均每个维度承载的信息量极低。遇到“不要纯棉的 要那种滑滑的 夏天穿”这种否定+材质+季节的复合意图，向量根本区分不开“纯棉”和“不要纯棉”。

第二，商品侧的表征偏差。商品向量通常由标题+属性+图片多模态融合而来，但融合权重是离线固定的。一个卖点是“限量配色”的球鞋，和一个卖点是“透气网面”的跑鞋，如果标题长度相近，它们的向量在空间里的距离可能比实际语义距离更近。

第三，相似度度量的刚性。余弦相似度只关心方向，不关心“哪个维度更重要”。用户搜“2000 以内”，价格维度应该是硬约束，但在向量空间里它只是 768 维中的几维，很容易被其他语义维度淹没。

2.2 生成式召回的“生成”对象是什么

得物交易搜索的生成式召回，并不是让 LLM 直接生成商品 ID 列表——那样既不可控也不可扩展。它生成的是结构化的召回意图表示，我把它拆成三层：

• 属性槽位填充：LLM 把 query 解析成{品类: 牛仔裤, 性别: 女, 版型: 显瘦, 身高: 小个子, 风格: 通勤}这样的槽位。每个槽位对应倒排索引里的一个字段，直接走精确匹配或范围匹配。
• 商品标题生成：对于槽位无法覆盖的长尾意图，LLM 生成若干条“理想商品标题”，再用这些标题去和商品库做轻量级匹配。这相当于用生成模型“翻译”了用户的模糊表达。
• 多路召回路由：LLM 判断这个 query 应该走哪几条召回通道——是走属性倒排、还是走向量、还是走品牌型号精确匹配。路由决策本身也是生成出来的。

注意：这里的“生成”不是自由文本生成，而是受约束的、面向召回的结构化生成。LLM 的输出会被解析器校验，槽位必须落在预定义的 schema 内，生成的标题必须通过品类分类器验证。

2.3 为什么是“范式跃迁”而不是“增量优化”

向量检索的优化路径是：换更强的 encoder、加更多训练数据、调 ANN 参数、做多向量融合。这些都是在“压缩-匹配”框架内做文章。生成式召回换了一个框架：先理解，再映射，最后匹配。理解阶段用 LLM 的语义解析能力，映射阶段用结构化生成能力，匹配阶段才回到传统检索。

这个顺序变化带来的最大好处是：召回率的上限不再受向量维度限制。一个 query 可以生成 50 个槽位组合、20 条候选标题、3 条召回路由，信息量远超一个 768 维向量。而且每个槽位和标题都是可解释的，运营可以干预，badcase 可以归因。

3. 得物交易搜索的生成式召回链路拆解

3.1 Query 理解层：LLM 做槽位解析与意图分类

得物的 query 有一个显著特点：短、碎、黑话多。比如“dunk 熊猫 女 36”“北面 1996 黑”“ccd 相机 学生”。传统 NER 模型在这些 query 上表现不稳定，因为很多黑话不在训练集里。LLM 的 few-shot 能力在这里很关键——给几个示例，它就能把“dunk 熊猫”解析成{品牌: Nike, 系列: Dunk, 配色: 熊猫}。

实际落地时，他们用的是小参数 LLM + 领域微调的方案。原因很直接：交易搜索的 QPS 很高，用百亿参数模型做在线推理，算力成本扛不住。微调数据来自历史点击日志和人工标注的 query-槽位对，规模在百万级。微调后的模型在槽位解析任务上，F1 比通用 LLM 高出一截，推理延迟控制在 20ms 以内。

槽位 schema 的设计也有讲究。得物把商品属性分成硬属性和软属性：硬属性包括品牌、型号、品类、性别、尺码，这些必须精确匹配；软属性包括风格、场景、材质偏好，这些可以走向量或文本匹配。LLM 解析时，硬属性槽位置信度阈值设得很高，宁可漏填也不填错；软属性则允许模糊填充。

3.2 生成层：从槽位到多路召回 query 的构造

槽位解析完，下一步是生成召回 query。这里不是简单地把槽位拼成布尔查询，而是生成多路异构召回请求。得物的做法是：

• 倒排路：硬属性槽位直接构造倒排索引查询。比如{品牌: Nike, 系列: Dunk, 性别: 女, 尺码: 36}会生成一条精确匹配请求，命中商品库中同时满足这四个条件的 SPU。
• 向量路：软属性槽位和原始 query 拼接后，生成一条向量检索请求。比如“显瘦 小个子 通勤”会编码成向量，去和商品的多模态向量做 ANN。
• 生成标题路：对于槽位覆盖不全的 query，LLM 生成 3-5 条“理想商品标题”，每条标题走一次轻量级文本匹配。比如“适合小个子的显瘦牛仔裤”可能生成“高腰显瘦九分牛仔裤 小个子”“弹力修身小脚牛仔裤 女 小个子”“垂感直筒牛仔裤 显瘦 小个子通勤”。
• 多模态路：如果 query 包含视觉描述（“那种滑滑的面料”“和图片同款”），LLM 会触发多模态召回通道，用 CLIP 类模型做图搜或文搜图。

这四路召回并行执行，每路返回 topN，最后做融合排序。融合不是简单加权，而是按召回路的置信度动态调权。倒排路的置信度最高，因为硬属性匹配是确定的；生成标题路的置信度取决于 LLM 的生成质量，通常设得较低，但覆盖面广。

3.3 融合与去重：多路召回结果的合并策略

多路召回的结果合并，得物用的是分层去重 + 动态配额。先去重：同一个 SPU 被多路召回命中，只保留一次，但记录命中路数。命中路数越多，说明这个商品和 query 的相关性越强，在后续排序中会获得加权。

动态配额是指，每一路召回的 topN 不是固定的，而是根据 query 类型动态调整。比如品牌型号类 query，倒排路配额给到 80%，向量路只给 20%；而场景描述类 query，生成标题路和向量路各给 40%，倒排路只给 20%。这个配额策略是离线用强化学习调出来的，目标函数是最终成交转化率。

实操心得：多路召回的融合阶段最容易出问题的是“热门商品霸屏”。某个爆款 SPU 可能同时被倒排、向量、生成标题三路命中，如果不去重和配额控制，它会挤掉其他潜在相关商品。得物的做法是给每个 SPU 设一个“跨路命中上限”，超过上限后降权。

3.4 在线服务架构：延迟与算力的平衡

生成式召回的在线链路比传统向量检索长，延迟压力大。得物的架构做了几件事来压延迟：

• LLM 推理异步化：槽位解析和标题生成不在主链路同步等待，而是异步触发，先返回倒排路和向量路的结果，生成路的结果后到后补。
• 缓存复用：高频 query 的槽位解析结果和生成标题会缓存，TTL 设得很短（分钟级），因为交易搜索的 query 分布变化快。
• 模型蒸馏：在线用的 LLM 是蒸馏后的小模型，参数量控制在十亿以内，用 TensorRT 加速，单次推理延迟压到 15ms 以下。
• 降级策略：如果 LLM 服务超时或不可用，自动降级到纯向量+倒排的兜底链路，保证可用性。

这套架构的算力成本比纯向量检索高，但得物团队算过一笔账：召回率提升带来的 GMV 增量，覆盖了额外的算力开销。这也是交易搜索和内容搜索的区别——交易搜索的 ROI 可以直接用成交额衡量。

4. 落地过程中绕不开的四个坑

4.1 槽位 schema 的粒度怎么定

太粗，LLM 解析不出有用信息；太细，解析准确率下降，而且倒排索引维护成本高。得物踩过的坑是：一开始把“风格”槽位拆成 20 多个子类，结果 LLM 在“通勤”和“职场”之间反复摇摆，解析 F1 掉了 8 个点。后来合并成 5 个大类，准确率回升，召回效果反而更好。

我的经验是：槽位粒度应该由倒排索引的字段粒度决定，而不是由业务语义的精细度决定。倒排索引里没有“通勤风”这个字段，那槽位就不该拆到那么细。得物最终的 schema 是 12 个硬属性槽位 + 8 个软属性槽位，覆盖了 95% 以上的 query 意图。

4.2 生成标题的“幻觉”怎么控

LLM 生成的商品标题可能包含商品库里根本不存在的属性组合，比如生成“羊绒牛仔裤”——羊绒和牛仔裤在得物商品库里几乎没有交集。这种幻觉标题会导致召回为空，浪费算力。

控制手段有三层：第一，生成时用 constrained decoding，限制 token 只能来自商品库的高频词表；第二，生成后用品类分类器校验，标题的品类预测必须和 query 的品类槽位一致；第三，召回为空时记录 badcase，定期回流到微调数据里。得物上线初期，生成标题的幻觉率在 15% 左右，经过三轮迭代降到了 3% 以下。

4.3 多路召回的“路数爆炸”

一开始他们设计了 7 路召回，结果融合阶段的计算量翻了 3 倍，延迟超标。后来砍到 4 路，把“品牌精确匹配”合并进倒排路，把“图搜”合并进多模态路。路数不是越多越好，每增加一路，融合排序的复杂度就指数上升。4 路是一个比较平衡的点：倒排、向量、生成标题、多模态，覆盖了交易搜索的主要意图类型。

4.4 离线评估和在线效果的 gap

离线用 recall@K 评估，生成式召回比纯向量高 12 个点，但上线后在线 A/B 只涨了 3 个点。排查发现，离线评估用的 query 集是随机采样的，而在线流量里高频 query 占比很高，这些高频 query 的槽位解析已经被缓存优化过，提升空间本来就小。后来他们改成按 query 频次分层评估，低频 query 看召回率，高频 query 看延迟和转化率，离线在线 gap 才收窄到 2 个点以内。

5. 生成式召回之后，交易搜索还能往哪走

得物这套方案跑通后，最直接的扩展方向是生成式排序。召回阶段已经拿到了结构化的槽位和生成标题，排序阶段可以复用这些信号，做更细粒度的相关性打分。比如“显瘦”这个软属性，在召回阶段只是触发向量路，在排序阶段可以用 LLM 判断商品标题里的“显瘦”描述和 query 里的“显瘦”是不是同一个语义——是“版型显瘦”还是“颜色显瘦”。

另一个方向是多模态召回的深度融合。目前多模态路还是独立的，CLIP 向量和文本向量在融合阶段才汇合。下一步可以把商品的主图、标题、属性在编码阶段就做统一的多模态表征，让生成式召回直接生成“视觉+文本”的联合 query。得物商品图的质量很高，这个方向的收益空间很大。

还有一个容易被忽略的点：生成式召回的可解释性可以反哺运营。每个 query 的槽位解析结果和生成标题都是可读的，运营可以据此调整商品标题、补充属性、优化类目。这比向量检索的黑盒匹配多了一个人工干预的抓手。得物内部已经在用这套信号做商品信息质量分，标题里缺失高频槽位的商品会被降权。

最后说一个我自己的判断：生成式召回不是要取代向量检索，而是把向量检索从“唯一召回源”降级为“多路召回中的一路”。向量检索在语义泛化上依然有优势，但交易搜索的硬约束太多，单靠向量扛不住。得物的实践验证了这一点——四路召回里，向量路的贡献占比从原来的 100% 降到了 35% 左右，但整体召回率翻了一倍多。这个账，做交易搜索的人都算得明白。