企业官网建设流程全解析

引言：当“卷向量”不再是最优解，交易搜索的下一站在哪里？

做搜索召回的同学，这两年多少都有点“向量焦虑”。周围人张口闭口就是embedding、Faiss、HNSW，好像不把向量检索玩出花来，就不配谈“召回先进性”。但天天跟交易搜索打交道的人心里都清楚：向量化只是把文本/图片映射到高维空间的一种表示手段，它解决的是“语义相似”问题，但解决不了“意图理解”和“结果生成”的问题。搜索的终点从来不是“召回归档”，而是“用户找到并且愿意买”。尤其在高转化诉求极强的交易场景里，用户输入“黑色连衣裙显瘦”这种多意图混杂query，你光靠召回一堆向量近邻，哪怕相关性再高，用户还是得自己做二次筛选，体验和成交效率都上不去。

我最近在看得物交易搜索的做法时，发现他们提出了一个很值得聊的思路——别再只卷向量检索了，用“生成式”直接实现召回范式跃迁。说白了，就是把搜索从“匹配”逻辑，推到“生成”逻辑：让系统不只是从百万商品库里挑出最像的，而是直接“生成”一个满足用户需求的结果集。这篇我就想把它拆开聊透：为什么交易搜索不适合纯向量范式？生成式召回到底在解决什么结构性问题？落地的时候要避哪些坑？以及这套思路对做搜索、做推荐、做AI应用的人有哪些可迁移的启发。

这篇内容适合正在做搜索召回、做电商/交易类推荐系统、或者研究大模型应用落地的工程师和架构师。特别是那种已经卷完向量检索、但发现线上指标瓶颈愈发明显的团队，值得花十几分钟把这套范式转变的底层逻辑理一遍。

1. 交易搜索的召回困局：为什么“向量检索”不是终点

1.1 向量检索解决的是“语义相关”，而不是“交易意图”

向量检索确实带来了很大进步。早年间靠BM25、TF-IDF做关键词匹配，最大的问题是“词汇鸿沟”：用户说“耐克Air Force 1”，商品标题写“空军一号”，字面不匹配，召回直接挂掉。引入embedding之后，文本被映射到语义空间，至少能通过向量距离捕捉“同义改写”、“口语化表达”和“语境相似”，这个能力在开放域搜索里非常管用。

但交易搜索有个特殊点：用户不只是要“相关”，而是要“能买、想买、愿意下单”。同样是“运动鞋”，有人要通勤缓震，有人要实战篮球，有人要配色好看，有人预算只有300块。向量空间里的相似度，本质上反映的是“语义分布接近”，它不建模“用户此刻要什么类型的结果组合”，更不建模“怎样的排序混合策略能促进成交”。

我举个实际例子：用户搜“夏季跑步短袖男”，如果我们只做向量召回，系统很可能召回到大量“材质凉感”、“速干排汗”的相近商品。这没什么问题，但如果用户其实是刚跑完半马、想买一件“适合夜跑反光条设计”的上衣呢？向量模型如果没有“反光条”这个属性的强监督信号，它很难在语义空间里把这个需求精准压出来。这就是纯向量范式的第一个死角——相关不等于意图匹配。

1.2 向量召回的结果是“集合”，用户仍要自己消化信息

再往深一层说。向量召回本质上做的是“TopK检索”，系统给用户的是一个无序或粗排之后的有序列表。用户需要自己翻、自己比、自己决定买哪个。这在标品、低价、决策成本低的品类里问题不大，但遇到高客单、强个性化、决策链路长的商品（比如潮鞋、配饰、美妆礼盒），纯列表式召回就是在偷懒。

用户真正需要的，很多时候不是“一页商品”，而是“一个答案”：比如“最近通勤适合穿哪双复古跑鞋？”、“毕业照穿什么风格的衣服显气质？”、“送男朋友千元预算有什么推荐？”——这些问题里包含了多重约束：场景约束、预算约束、风格约束、甚至社交约束。把这种query打平成向量去“检索”，信息损耗不是一般的大。

我自己的体会是，交易搜索做到后期，瓶颈往往不在召回率上，而在“信息整合能力”上：单点召回再准，不会聚合，用户照样觉得搜得“散”。这也是为什么大家开始尝试“搜索直达结果页”、“聚合卡片”、“攻略型内容”这些新形态——本质都是在补“整合”这一课。

1.3 “范式跃迁”的本质：从“match”走向“generate”

所以得物交易搜索提的“生成式召回”，不是突然冒出来的新词，而是把检索任务重新定义了一遍：不再把召回看作“从候选库里选”，而是把它看作“从用户意图出发，构造一个结果集合”。

这个“构造”的过程，就带上了生成式模型的底子：模型不是对比商品的向量距离，而是学习“当用户表达某种意图时，怎样的商品组合、怎样的属性分布、怎样的价格带结构，是最可能带来正向反馈的”。它输出的不是单个商品的排序，而是一个“结果方案的生成”。

这里我多说一句。很多同学一看到“生成式”，第一反应是大模型LLM。但在这个场景里，“生成”的含义可以更宽——它指的是“目标函数从相关性到用户满足度的跃迁”。你可以用LLM来做，也可以用传统序列模型、甚至规则+模型混合来做。关键是思路转变：搜索系统从一个“检索器”，变成一个“答案生成器”。这一下子就打开了操作空间：不仅能召回商品，还能召回理由、召回搭配、召回攻略、召回品牌故事，然后统一编排成一个“可行动的答案”。这才是交易搜索卷完向量之后，真正该卷的方向。

2. 生成式召回的架构思路与核心设计

2.1 整体框架：意图解析、条件生成、结果校验三层

想落地生成式召回，第一件事不是选模型，而是搭框架。我梳理了一套相对通用的三层架构，适合大多数交易搜索场景复用：

第一层：意图解析层。用LLM或轻量模型把用户query拆成结构化约束。比如“夏季跑步短袖男”可以拆成：性别=男，季节=夏季，场景=跑步，品类=短袖上衣，隐含需求=透气/速干。这一步的核心是“从自然语言里榨出可计算的约束条件”，而不是直接做向量化。

第二层：条件生成层。基于解析出的约束，模型“生成”一个候选结果方案。这里生成的动作可以有很多种形态：可以是生成一个检索式（相当于自动构造多个查询去召回）；可以是直接生成一组商品ID序列；也可以是先生成一个“商品描述模板”，再拿模板去匹配商品库。这个层是“范式跃迁”发生的地方——它不再依赖单一的向量近邻，而是组合多个约束来“推演出结果”。

第三层：结果校验与融合层。生成的东西不一定靠谱，所以要校验：生成的商品是否存在？是否有库存？是否满足价格带约束？再和传统向量召回的结果做融合，最后交给排序层。这一步非常关键，它保证“生成式”不是“放飞式”。

这三层看起来简单，但每一层都有不少需要较真的细节。我逐个拆开讲。

2.2 意图解析：不是简单套一个“分类器”

如果你觉得意图解析就是给query打个标签（比如“品类=男装”、“场景=运动”），那大概率做出来效果不行。交易场景的query往往是复合意图，表达还高度口语化，单纯分类会丢失大量信息。

我们实际落地时，更推荐的方案是“槽位填充+兜底自由文本”双通道：

• 槽位填充通道：对常见结构化属性（品类、性别、价格带、风格、材质）做抽取，转成可检索的过滤条件。
• 自由文本通道：对槽位抽取不干净的部分，保留完整语义文本，用于后面做语义匹配或者生成细粒度描述。

举个例子，用户搜“复古越野跑鞋小众品牌”，槽位抽取能拿到“品类=跑鞋”、“风格=复古”，但“小众品牌”这种偏好就很难落成具体槽位。这时候就需要把“小众品牌”作为一个软约束，传到生成层去影响结果——比如在生成检索式的时候，加入“非大众热销品牌”的过滤逻辑，或者调整品牌分布权重。

这里面有个非常容易踩的坑：不要把意图解析做成一个巨大的多分类任务。交易搜索的意图空间太稀疏、太长尾了，你枚举不完。更务实的做法是“解析出能落地的那部分，剩下的交给语义兜底”，把“理解不透”的部分留给后面的校验融合层去修正。

2.3 条件生成：从检索式生成到商品序列生成

条件生成层是整个范式跃迁的技术核心。我见过几种落地路径，各有取舍：

第一种：生成检索式（Query Generation）。模型根据意图约束生成多个检索式，比如“夏季跑步短袖男”生成：“男 速干 短袖 T恤”、“跑步 训练 上衣 夏季”、“透气 运动T恤 男款”。然后拿这些生成的检索式分别做召回，再合并结果。这个方案的好处是改动小，能复用已有的检索基建；缺点是生成检索式不一定会比用户原query更好，容易“绕了一圈回到原点”。

第二种：生成商品描述/属性分布，再匹配商品库（Profile Generation）。这个思路更接近“生成式”的本意：模型不是直接生成商品ID，而是先生成一个“理想商品的画像”——维度包括品牌偏好、价格中位数、设计风格、材质倾向、功能卖点。画像生成好后，用画像向量或者画像约束去商品库里圈选商品。这个方案的好处是生成结果可解释性强，而且能比较好地处理长尾query；缺点是对画像维度的设计能力要求很高。

第三种：直接生成商品序列（Item Generation）。利用序列模型或者大模型，直接从商品库中“推理”出最合适的一串商品ID。这个最激进，也最像“生成式”，但落地风险也最大：商品库有百万级规模，直接生成很容易产生幻觉，生成一些不存在的商品或者明显不符合约束的结果，校验成本很高。

我的建议是，初版落地优先考虑“检索式生成 + 画像生成”的混合方案：先用检索式生成保证基本盘覆盖，再用画像生成处理长尾意图。直接生成商品序列可以作为后期迭代方向，对校验层的要求会非常高。

2.4 为什么要留着传统向量召回做“底座”

这里特别想强调一下：生成式召回不是来取代向量召回的，而是来“叠buff”的。一定要把它当作新增的一路召回，而不是唯一的召回。

原因很好理解。生成式模型再强，它也有“幻觉”问题。特别是面对高热度的突发话题商品（比如某明星同款突然火了），生成式模型的知识是滞后的，它不知道这个商品现在应该被召回。但向量召回基于实时索引，只要有新款上架、有新的用户行为反馈，它就能迅速反应过来。所以“生成式”管长尾意图和复杂约束，向量召回管热点和新品，两条腿走路才稳。

融合策略上，我们团队的经验是“保底不抢量”：生成式召回的结果先过一层规则校验（是否包含禁售品、库存是否充足），再和向量召回结果做比例混排。初期建议生成式召回的占比控制在10%到20%，等线上指标验证OK了再逐步放量。一口吃不成胖子，召回层的调整尤其要稳。

3. 实操过程与关键环节实现

3.1 基础数据准备与样本构造

任何召回模型的训练都离不开样本，生成式召回对样本的要求比普通向量模型更高。

首先，我们需要“用户行为反馈样本”：用户点了什么、买了什么、在搜索结果页停留了多久、最终成交了什么。这些数据是训练“用户满足度”信号的基础。

其次是“意图-商品配对样本”：一条query对应哪些商品是“好结果”。这个不能只看点击，因为点击有偏置——排在前面的容易被点。建议用“成交+加购+收藏”这类强正反馈，再结合“点击后长时间停留”做辅助判断。

还有一个容易被忽视的样本来源：客服对话记录。用户咨询“有没有适合跑步穿的黑色短袖，不要太紧身的”，客服的回答往往包含了精准的约束拆解和商品推荐。这一类“会话级”数据，对于训练意图解析和画像生成非常有价值。

样本量方面，我的经验是：意图解析层至少需要几十万量级的query标注数据，而画像生成层需要百万量级的“user-item”交互对才能训练出稳定的生成质量。如果冷启动来不及积累这么多数据，可以先用规则生成一批伪样本，再用线上真实反馈逐步迭代。

3.2 意图解析模块的离线训练与线上调用

意图解析模块我们用的是“轻量LLM + 小模型兜底”的组合。线上不可能每个query都调大模型，延迟受不了。所以实际落地时是这么做的：

• 离线环节：用大模型对历史query做批处理，产出高质量的槽位标注，然后把这些标注作为训练数据，蒸馏到一个轻量分类/序列标注模型上。
• 在线环节：query进来先走轻量模型，如果置信度低，再决定是否升级到大模型兜底。

这里分享一个调优细节：槽位解析的“阈值”不要一刀切。比如“品类”字段的置信度要求可以放到0.7，“材质”这种长尾属性放到0.5就行——因为材质识别错了，后面还有校验层能兜住，但品类错了影响面就大了。不同槽位的风险等级不一样，阈值设计要有差异化思维。

3.3 生成式召回模型的离线训练与推理服务

再来说生成模型这部分。如果我们选“检索式生成 + 画像生成”的混合路径，那模型结构上可以这样做：

检索式生成可以建模成Seq2Seq任务：输入是query和意图槽位，输出是多个检索式。训练的时候用历史的高转化query及其对应的“有效检索式”做监督。所谓有效检索式，可以反推：那条query最终成交的商品，是通过哪个检索词/哪个类目路径成交的，这个路径就可以当作标签。

画像生成则可以建模成“属性预测”任务：输入是query和意图槽位，输出是一组商品属性分布（价格带、风格权重、功能关键词权重）。训练目标是让预测出的画像分布，能够覆盖该query下高转化商品的属性分布。注意这里用的是“分布”而不是“具体值”，目的是为了生成结果的多样性——用户搜“运动鞋”，你不能只给他推单一品类，得覆盖跑鞋、篮球鞋、板鞋等潜在子类。

推理部署这块有个现实约束：如果整个链路都串行调用大模型，延迟很难压到100ms以内。我们用的解法是“分层缓存 + 异步化”：意图解析和画像生成的结果，按键值缓存，同一个query或相似query直接命中缓存；真正需要实时生成的，只有那些长尾新query。这能省掉大部分在线开销。

另外要特别提一下“生成结果的去重与多样性控制”。生成式模型天生容易坍缩到少数几种高分模式，结果就是召回来的商品长得都差不多。我们的做法是在解码阶段引入“MMR最大边际相关性”做多样性惩罚：如果一条新召回商品和前几条已选商品在向量空间里太近，就适当降权。这个细节对交易搜索尤其重要——用户不喜欢一页全是同款不同色的商品。

3.4 结果校验层：把“幻觉”挡在门外

生成结果的校验，我强烈建议做成独立的一层服务，而不是散落在各环节里。校验服务统一提供以下几个能力：

• 库存校验：生成结果的商品必须当前可售、有库存。
• 合规校验：过滤违禁品、侵权品、风险商品。
• 约束校验：检查结果商品是否满足意图解析出的硬约束（比如性别、价格带上限）。
• 真实性校验：确认商品ID真实存在于索引中，防止模型“编造”不存在的商品。

校验层看起来枯燥，但它决定了生成式召回能不能上线。我见过团队在模型阶段投入了大量精力，结果因为校验没做好，上线第一天生成了一堆“好看但不存在”的商品卡，用户点进去全是404，体验直接崩盘。生成式召回落地，校验比生成更重要。这句话我写在这，等你们踩过坑之后会回来点赞的。

3.5 实验设计与效果评估办法

生成式召回上线前，实验设计要特别的细致。常规的“召回率+点击率”两个指标不够，建议额外关注这四类指标：

• 意图覆盖率：生成式召回结果覆盖了多少种不同意图。可以按query聚类后看每个意图簇是否有结果命中。
• 约束满足率：人工抽样生成结果，看价格带、性别、品类约束的满足比例。
• 多样性指标：计算召回归一化熵或者类目覆盖数，防止结果过度集中。
• 业务转化指标：最终还是要看加购率、成交转化率这些硬指标，因为召回方式变了，用户满足度最终会体现在转化上。

实验建议用分层实验：先小流量（比如5%）观测生成召回占比和基础体验指标，确认无负面后，再逐步扩大到20%、50%。每一步都要监控延迟、超时率、无结果率这三个底线指标。生成式召回如果拖慢了整体检索速度，那是捡了芝麻丢西瓜。

4. 落地过程中的坑与排查心法

4.1 Query改写后“离题”了怎么办

我们在做检索式生成的时候，遇到过最典型的坑：生成出来的检索式比原query还抽象。比如用户搜“复古跑鞋”，模型生成了“旧款 运动鞋 经典”，结果召回了大量老头鞋，跟用户想要的复古潮流跑鞋完全不是一个东西。

排查思路很直接：给生成的检索式打分时，加入“与原query语义相似度”这个约束。生成式检索不是自由创作，它必须跟原query保持语义在同一个主题域内。实操上，可以在生成模型的loss里加一项“生成结果与query的余弦相似度”作为正则，偏离太远就降低奖励，能有效压制这个问题。

4.2 新品类冷启动阶段，生成式召回“无米下锅”

用户搜了一个刚刚入驻平台的新品类，意图解析做得很完美，画像也生成得很漂亮，但商品库里就是没几个对应商品。这种情况不是模型问题，是供给问题。

应对办法有两个方向：一是“放宽约束”，当校验层发现某个硬约束下候选商品数量太少时，自动降级为软约束，放宽价格带或风格范围；二是“转向相关类目”，做个简单的类目迁移映射，比如新品类“露营灯”没货，可以召回“氛围灯”、“户外灯”等相邻类目，保证用户体验不落空。

4.3 延迟上涨明显，如何给生成链路“瘦身”

生成式链路天然比传统向量召回多几步：意图解析、检索式生成、画像生成、校验融合，每一步都有可能变成性能瓶颈。

我们实战中做过的几个有效的瘦身动作：

• 把意图解析和检索式生成合并成一个模型，减少一次网络调用。因为两者的输入都是query，输出结构虽然有差异但可以设计成多任务共享。
• 对画像生成做精度换速度：线上推理时，画像里的连续值（如价格带分布）可以做离散化处理，从浮点数预测改成分类预测，模型轻量很多。
• 把校验层做成异步化：高置信度的生成结果先返回给用户，低置信度的标记待校验，后台校验通过后再补发。这个策略可以显著降低首包延迟。

4.4 你以为的“生成式”，其实还是“检索式”

最后一类坑，是认知层面的。有些团队宣称上了生成式召回，结果实际做的是“用LLM给query做了个向量化”。这个严格来说不叫生成式召回，还是向量检索。真正的范式跃迁，必须是输出结果发生了结构性变化：从“一个列表”变成“一个方案”，从“匹配商品”到“按约束构造结果集”。

判断标准很简单：你把生成式召回关掉，看召回结果是否显著变差。如果只是从向量A换成向量B，那说明还是在同一范式里打转，并没有实现跃迁。真正跃迁的标志是——用户搜“通勤一周穿搭”，你返回的不再是七件相似白衬衫，而是一套周一至周五搭配方案的集合。这就是生成式召回的护城河，也是它跟传统向量检索之间最本质的区别。

5. 几个值得持续深挖的延展方向

5.1 生成式排序协同：召回只是上半场

召回变了，排序不可能还守着原来的套路。当前生成式召回的输出天然带有“方案性”。下一步值得尝试的是生成式排序：不只为每个商品打个分，而是综合考虑整页商品组合的互补性与替代性，生成一个“最优结果页”。这跟召回阶段的生成范式是一脉相承的。

5.2 生成式召回在多模态场景的延伸

得物这类平台，商品数据天然是多模态的——图文、短视频、用户评测内容都是很好的信号源。现在我们的画像生成主要基于文本属性，后续完全可以扩展成多模态画像：用商品主图embedding来代替一部分文本属性描述，让画像生成更贴近“视觉决策”的真实购物逻辑。

5.3 用户长期兴趣建模与生成式召回的联动

目前聊的生成式召回，更多是基于当前query做即时推导。如果能把用户历史行为序列也输进去，让生成结果带有明显的个性化颜色，那交易搜索的“答案感”会更强——“最近关注篮球鞋、预算1000到1500、偏好白色系”的用户，搜“篮球鞋”得到的结果方案，跟另一个首购用户一定不同。这层联动做好了，才是真正的搜索体验代差。

一些个人体会

做搜索这些年，我最大的感受是：技术范式的升级，往往不是“旧技术不行了”，而是“旧技术能解决的上限到了”。向量检索把语义召回的墙推倒了一大半，这功劳得认。但交易搜索要的不止是“语义命中”，还要“意图满足”和“消费决策提效”，这就不是单纯的相似度搜索能覆盖的了。

得物交易搜索这次把“生成式召回”摆上台面，与其说他们找到了标准答案，不如说是给行业提了个醒：召回的目标函数该从“相关性”切换到“用户满足度”了。用生成式模型去构造结果方案，本质上是在用模型的理解力，代替用户自己做信息整合。这条路方向是成立的，但落地难度也不小，尤其考验团队在数据、校验、实验设计上的基本功。

如果你正在做搜索或者推荐，不妨试一把：不要急着换更大的向量模型，先盘一盘你的搜索链路里，有多少环节可以用“生成”替代“匹配”。哪怕只是把意图解析做得更结构化一点，或者给检索式生成加上一个语义正则，线上的体验变化可能会超出你的预期。搜索这条路，值得卷的方向还多着呢。