生成式召回技术实践：用大语言模型为推荐系统注入惊喜与探索

1. 项目概述：当“猜你喜欢”遇上生成式AI

在电商和内容推荐领域，“召回”环节就像是给用户准备一份海量商品的“候选清单”。传统的召回模型，无论是基于协同过滤的“喜欢A的人也喜欢B”，还是基于向量化双塔模型的“语义相似度匹配”，本质上都是在已有的商品池里做“选择题”。它们擅长从历史行为中挖掘关联，但想象力有限，很难跳出用户既有兴趣的“舒适圈”，去发现那些看似不相关、实则可能引发惊喜的潜在兴趣点。这就像一位只根据你过去点过的菜来推荐新菜品的厨师，虽然稳妥，但少了点“开盲盒”的惊喜感。

“生成式召回”的出现，正在尝试打破这个局面。它不再仅仅是“匹配”和“筛选”，而是试图“创造”出候选。想象一下，不是在海里捞针，而是根据你对“针”的描述，直接“生成”几根最符合你描述的“针”的草图，再去库里找最像的实物。在得物这样的潮流社区电商平台上，用户对“潮流”、“风格”、“搭配”的追求充满了主观性和探索性，传统的召回方式有时会显得力不从心。生成式AI，特别是大语言模型所具备的强大语义理解、逻辑推理和内容生成能力，为我们打开了一扇新窗：能否让模型像一位资深的潮流买手或搭配师一样，根据用户当下的语境和意图，“脑补”出他可能感兴趣的商品？

这正是我们在得物探索生成式召回技术的核心驱动力。我们面对的挑战和机遇并存：一方面，电商场景对结果的准确性、相关性和可控性要求极高，生成模型的“幻觉”问题在这里是致命的；另一方面，社区丰富的用户生成内容（UGC）、商品详情的图文信息、以及用户复杂的浏览、搜索、互动序列，又为生成式模型提供了肥沃的“理解”土壤。这篇分享，我将从一个一线工程师的视角，拆解我们如何将“生成式召回”这个听起来很前沿的概念，一步步落地到得物的真实业务流中，分享其中的技术选型、核心实现、踩过的坑以及我们对未来的一些思考。无论你是对推荐系统感兴趣的新手，还是正在探索AIGC落地的同行，希望这些实打实的经验能带来一些启发。

2. 核心思路：从“匹配”到“生成”的范式转变

2.1 传统召回的技术瓶颈与业务诉求

在深入生成式召回之前，有必要先看看我们为什么需要它。得物的业务场景有几个鲜明特点：商品非标品化严重（同是T恤，设计、联名、潮流元素天差地别）、用户兴趣动态且多元（今天看球鞋，明天可能看露营装备，后天又被一篇穿搭笔记种草了某款配饰）、强社区属性驱动（大量穿搭分享、开箱测评内容直接影响消费决策）。

传统的向量召回模型（如双塔DSSM）在这里会遇到几个典型问题：

1. 冷启动与长尾商品曝光不足：新上架的潮流单品、小众设计师品牌，由于缺乏足够的交互数据，其向量表示不够精准，很难在召回阶段被有效触达。
2. 多模态信息利用不充分：商品标题、详情文案、图片、用户评论、社区笔记等都是宝贵的信息源。传统模型通常将这些信息压缩成一个静态的向量，过程中会损失大量细粒度语义和视觉风格信息。例如，用户搜索“落日余晖配色”，传统模型可能只能匹配到标题含“橙色”、“黄色”的商品，而无法理解这是一种充满氛围感的色彩风格。
3. 复杂意图理解能力弱：用户的真实意图往往隐藏在多轮交互和复杂查询中。比如，用户先浏览了几双复古跑鞋，又搜索了“cityboy穿搭”，他的意图可能不再是单一的“跑鞋”，而是“适合cityboy风格的、带有复古元素的鞋款或服装”。这种需要结合上下文进行推理的意图，传统匹配模型难以精准捕捉。

业务侧对我们的核心诉求很明确：在保证相关性和准确率基本盘的前提下，显著提升推荐的惊喜度（Serendipity）和探索性（Exploration），尤其要能挖掘潜在兴趣和带动长尾优质商品。生成式召回，正是我们应对这些挑战的一次关键尝试。

2.2 生成式召回的基本原理与架构设计

生成式召回的核心思想，是将召回任务重新定义为“条件生成”任务。具体来说，我们利用大语言模型（LLM），将用户的历史行为序列、当前查询、上下文信息等作为“条件”或“提示”，让模型生成一系列可能符合用户兴趣的“商品描述”或“商品标识符”，然后再将这些生成的内容映射回实际的商品库。

我们设计的整体架构分为离线和在线两个部分：

离线部分：

1. 商品知识库构建：这是基础。我们不是让LLM凭空创造商品，而是让它基于一个丰富的“商品知识库”进行生成。这个知识库包含了所有商品的结构化信息（ID、类目、品牌、价格）和非结构化信息（精炼后的标题、核心卖点、风格标签、从图片中提取的视觉特征关键词等）。我们使用一个轻量级的Embedding模型为每个商品生成一个向量，用于后续的快速检索。
2. 提示工程与模型微调：设计用于引导LLM生成商品描述的提示模板。例如：“根据用户的浏览历史：[历史商品序列]，以及他当前的搜索词‘[查询词]’，生成5个该用户可能感兴趣的商品描述。描述应包含商品类型、主要风格、关键特征，并避免生成实际品牌名和商品ID。” 为了提高生成结果与得物商品池的对齐度和可控性，我们采用了LoRA等参数高效微调技术，在高质量的<用户上下文， 理想商品描述>数据对上对基础LLM进行微调。

在线部分：

1. 用户实时上下文编码：当用户发起请求时，系统会实时拼接用户的近期交互序列（如最后点击的5个商品）、搜索词、所在页面上下文等，形成一段完整的提示文本。
2. 条件生成：将拼接好的提示输入到部署好的、经过微调的LLM服务中。模型会基于概率生成多条（例如10-20条）商品描述文本。这里我们使用集束搜索或核采样策略，在保证多样性的同时控制生成质量。
3. 生成描述到商品映射：这是关键且富有挑战的一步。生成的描述是文本，我们需要将其“落地”为具体的商品ID。我们采用了两阶段映射法：
   • 阶段一：粗筛。使用一个高效的向量检索服务（如Milvus、Faiss），将生成的商品描述通过同一个轻量级Embedding模型向量化，然后从全量商品向量库中进行近似最近邻搜索，召回Top K个（例如200个）候选商品。
   • 阶段二：精排。由于向量检索可能存在语义漂移，我们引入一个轻量级的交叉编码器模型。该模型以“生成的描述”和“候选商品的详情文本”作为输入，直接输出一个匹配分数。根据这个分数对Top K个商品进行重排序，选出最匹配的Top N个商品（例如50个）作为生成式召回通道的最终结果。
4. 多路召回融合：生成式召回的结果不会单独使用。它会与传统的向量召回、协同过滤召回、热门召回等多路结果一起，送入后续的排序模型进行统一打分和混排。我们的策略是让生成式召回充当“探索先锋”和“补充部队”的角色。

关键设计思考：为什么选择“生成描述->检索映射”的路径，而不是让LLM直接输出商品ID？这是出于可控性和可扩展性的考虑。直接输出ID要求模型记忆海量ID与特征的映射，几乎不可能且极易出错。而生成描述的方式，将LLM擅长的语义理解、推理生成能力，与向量检索/交叉编码器擅长的精确匹配能力解耦，架构更清晰，也便于单独优化每一环。

3. 核心实现：提示工程、模型优化与系统集成

3.1 提示词设计的艺术与科学

提示工程是生成式召回效果的“方向盘”。我们的目标是设计出能让LLM稳定输出高质量、多样化、且符合业务约束的商品描述的提示词。经过大量AB测试，我们总结出几个有效的设计模式：

1. 角色扮演与任务明确：给模型赋予一个明确的角色，能显著提升生成结果的专业性和一致性。例如：“你是一个专业的潮流穿搭顾问，熟悉各类运动鞋、服装和配饰。请根据用户的行为，推测他的穿搭喜好和潜在需求。”
2. 结构化输出要求：要求模型按照特定格式输出，便于后续程序化解析。例如：“请严格按照以下格式生成描述，每条描述一行：风格: [具体风格]， 类型: [商品类型]， 关键特征: [特征1， 特征2...]”。我们甚至尝试过让模型输出“伪SQL”或“属性键值对”，以更好地对齐商品知识库。
3. 上下文信息的组织与加权：不是简单罗列用户历史行为。我们会根据行为类型（点击、收藏、购买、搜索）、时间远近、商品价格档位等信息，对历史序列中的商品进行重要性加权，并在提示词中体现。例如：“用户最近重点关注了[商品A， 强调：联名款]， 此外还对[商品B， 强调：机能风]表现出兴趣。”
4. 负面约束与安全护栏：明确告诉模型“不要”做什么，至关重要。这包括：不要生成品牌名称和具体商品ID（避免侵权和事实性错误）、不要生成平台未售卖的品类、避免生成带有敏感或不当特征的描述、避免过度重复相似特征。
5. 引入外部知识：在提示词中动态插入一些实时信息，如当前季节、热门潮流趋势词（通过社区话题挖掘获得），让生成结果更具时效性和潮流感。

一个我们线上在用的简化版提示词示例：

你是一个得物平台的潮流推荐助手。请根据用户的近期行为，为他生成可能感兴趣的商品描述。 用户近期交互序列（按时间由近到远）： 1. 浏览了：Nike Dunk Low 复古板鞋 白灰配色 2. 收藏了：Carhartt 工装风多口袋工装裤 3. 搜索了：“军事风搭配” 当前季节：春季。 平台热趋词：复古运动、轻户外、城市通勤。 请生成5条商品描述。每条描述应包含：主要风格、商品类型、核心设计元素或材质特点。 请确保： - 描述具体，但不要提及任何品牌名和具体商品型号。 - 风格需结合用户历史行为和当前热趋。 - 设计元素符合描述的风格。 输出格式： 风格: [风格1]， 类型: [类型1]， 特征: [特征A， 特征B] ...

3.2 模型选型、微调与推理优化

模型选型：在开源LLM中，我们选择了参数量在7B到13B之间的模型作为基础，如ChatGLM3-6B、Qwen1.5-7B等。这个量级的模型在生成质量、推理速度和部署成本之间取得了较好的平衡。更大的模型（如70B）效果固然可能更好，但线上推理延迟和成本难以承受。

模型微调：

1. 数据构建：这是最大的挑战。我们通过人工标注、规则挖掘、利用排序模型“蒸馏”等方式，构建了一个高质量的配对数据集。样本格式为：{“context”: “用户历史序列和查询”， “target”: “人工编写的理想商品描述”}。其中“理想商品描述”需要紧扣上下文，且能对应到1个或多个真实商品。
2. 微调方法：采用LoRA进行高效微调。在全量参数上微调不仅成本高，还容易导致模型“遗忘”原有的通用知识。LoRA通过在Transformer层的注意力机制中引入低秩适配器，只训练这些新增的少量参数，就能让模型快速学习到我们的特定任务指令。我们主要对Query, Key, Value和输出投影层添加LoRA适配器，秩一般设置为8或16。
3. 损失函数：标准的交叉熵损失。但我们会对描述中关键的结构化部分（如风格、类型）的预测错误给予稍高的权重，以强化模型对输出格式的遵循。

推理优化：

1. 量化：使用GPTQ或AWQ等后训练量化技术，将模型从FP16精度量化到INT4甚至INT3，模型体积减小60%-70%，推理速度提升2-3倍，而对生成质量的影响在可接受范围内。
2. 推理框架：采用vLLM或TensorRT-LLM等高性能推理框架。它们支持连续的批处理、PagedAttention等优化技术，能极大提高GPU利用率和吞吐量，降低单个请求的延迟。对于我们这种需要同时处理大量用户请求的在线服务至关重要。
3. 缓存策略：对于常见的用户行为模式（如“浏览了A、B商品”），其生成结果在一定时间内是稳定的。我们设计了两级缓存：内存缓存高频模式，分布式缓存（如Redis）存储更多结果，有效降低对LLM服务的直接调用压力。

3.3 系统集成与工程化挑战

将生成式召回模块无缝嵌入现有的推荐系统，是一个复杂的工程问题。

1. 延迟与吞吐的平衡： LLM的生成速度相对较慢，即使优化后，生成10条描述也需要几百毫秒。我们的解决方案是异步化与提前计算。

• 异步生成：用户请求到来时，系统立即返回由传统召回通道构成的初始结果。同时，异步触发生成式召回任务。当用户进行下一页浏览或短暂停留时，生成式召回的结果已经就绪，可以混入后续的推荐流中。这保证了首屏的响应速度。
• 用户行为预计算：对于活跃用户，系统会定期（如每半小时）根据其最新的行为序列，预运行生成式召回，并将结果缓存起来。当用户请求发生时，直接使用缓存结果，实现“准实时”的效果。

2. 映射检索的准确性保障： 生成描述到商品ID的映射是效果衰减的主要环节。我们除了使用“向量检索+交叉编码器精排”的两阶段方案，还做了以下优化：

• 商品知识库的Embedding模型对齐：用于构建商品向量库的Embedding模型，与用于向量化生成描述的模型，必须是同一个。如果不同，两者向量空间不一致，检索效果会急剧下降。我们选择了在电商语料上微调过的BGE或M3E等中文Embedding模型。
• 交叉编码器的训练：我们收集了<生成描述， 匹配商品， 不匹配商品>的三元组数据，训练一个轻量级的BERT模型作为交叉编码器。负样本的构建很有讲究，除了随机负例，我们还加入了“困难负例”，即向量检索得分较高但实际不匹配的商品，这能显著提升模型的判别能力。

3. 效果评估与监控体系： 生成式召回的效果不能只看线上AB测试的最终业务指标（如点击率、转化率），还需要建立中间过程的监控。

• 生成质量评估：我们定义了几个自动评估指标：生成描述的多样性（Distinct-n）、与用户历史的相关性（通过一个小的判别模型打分）、是否符合格式要求。这些指标会实时监控并报警。
• 映射成功率监控：跟踪“生成描述->成功映射到商品”的比例，以及映射后商品的曝光点击情况。如果映射成功率持续走低，需要排查是生成描述的问题还是检索模型的问题。
• 线上AB实验：这是最终检验场。我们为生成式召回设置了独立的实验桶，对比基线桶（无生成式召回），核心观察指标不仅是CTR，更重要的是人均曝光商品品类数、长尾商品曝光占比、惊喜商品的点击率等，这些才是生成式召回价值的核心体现。

4. 实战挑战与效果分析

4.1 遇到的主要问题与解决方案

在项目落地过程中，我们踩了不少坑，也积累了一些有效的应对策略。

问题一：LLM的“幻觉”与事实性错误这是生成式技术落地的通病。模型可能会生成平台根本不售卖的商品（如“某奢侈品牌限量款跑鞋”），或者描述与真实商品严重不符。

• 我们的解法：
  1. 强化微调数据中的“真实性”约束：在构造微调数据时，确保每条“理想商品描述”都能明确对应到1-N个真实在售商品。在指令中反复强调“基于平台现有商品进行推测”。
  2. 建立动态商品知识黑名单：在提示词中，可以加入当前不推荐或无效的品类、品牌列表作为负面约束。
  3. 后置严格过滤：在映射检索后，增加一层基于商品类目、属性等规则的强过滤。对于映射到的商品，会检查其类目是否与生成描述中的“类型”强相关，不相关的直接过滤掉。

问题二：生成结果多样性不足或过度发散模型有时会陷入“模式复制”，给不同用户生成高度相似的描述；有时又会过于天马行空，生成完全不靠谱的结果。

• 我们的解法：
  1. 采样策略调优：放弃贪心解码，采用核采样，并精心调整温度参数和top-p值。温度稍高（如0.8-0.9）有助于多样性，但需要配合较低的top-p值（如0.8）来截断长尾低概率词，防止胡言乱语。
  2. 在提示词中注入随机种子：在提示词末尾加入一个轻量的、可变的元素，如“请从[街头、复古、运动、简约]等风格角度进行思考”，其中的风格列表可以随机轮换，以打破模型的固定思维。
  3. 多提示词集成：为同一个用户请求，设计2-3个在角色或侧重点上略有不同的提示词模板，分别生成结果后再去重合并，可以有效增加候选集的多样性。

问题三：线上服务性能与成本压力LLM服务的高延迟和高成本是规模化应用的最大拦路虎。

• 我们的解法：
  1. 模型瘦身与加速组合拳：量化是必选项。结合模型剪枝（移除不重要的神经元权重）和知识蒸馏（用大模型教小模型），我们尝试将13B的模型压缩到3B左右，在效果损失小于5%的情况下，推理速度提升了一个数量级。
  2. 请求合并与批处理：在线服务端会将短时间内多个用户的生成请求（前提是他们的历史序列经过聚类比较相似）合并成一个批次，发送给LLM推理服务。vLLM等框架对此有很好的支持，能大幅提升GPU利用率。
  3. 分级服务策略：并非所有用户和场景都需要调用生成式召回。我们根据用户价值、活跃度以及当前场景（如搜索后的推荐流 vs. 首页推荐流）进行分级，只对高价值用户或关键场景全量开启，其他场景采用降级或抽样策略。

4.2 线上AB实验效果与业务价值

经过多轮迭代和优化，我们将生成式召回接入了得物主站推荐场景进行严格的AB实验。实验周期为两周，核心发现如下：

业务价值解读：

1. 拓宽兴趣边界：最核心的价值是打破了传统推荐系统的“信息茧房”。生成式召回像一个“探索引擎”，能够基于用户已有兴趣进行合理外推，将那些看似不相关、但内在逻辑相连的商品（如从“复古跑鞋”联想到“复古运动夹克”）推荐给用户，带来了可观的惊喜项点击增长。
2. 激活长尾生态：对于得物这样注重独特性和潮流感的平台，大量优质的设计师品牌和新品处于长尾。生成式召回通过语义生成，能更公平地触达这些商品，为生态健康注入了活力。
3. 深化意图理解：在搜索、内容种草等强意图场景下，生成式召回展现出了更强的优势。它能将用户的简短查询或浏览内容，扩展成丰富的商品需求描述，从而进行更精准的匹配，这直接体现在搜索后推荐场景的CTR大幅提升上。

5. 未来展望与迭代方向

生成式召回在得物的初步落地验证了其价值，但这只是一个起点。我们认为，下一步的进化将围绕以下几个方向展开：

1. 从“文本生成”到“多模态生成”当前的生成式召回主要基于文本信息。但得物的商品和内容是高度视觉化的。下一步，我们将探索多模态大模型的应用。让模型不仅能读懂用户的历史文本行为，还能“看到”用户点击过的图片、浏览过的视频，从而生成融合了视觉风格（如“低饱和度莫兰迪色系”、“廓形剪裁”）、材质质感（如“丹宁水洗效果”、“皮质光泽”）的跨模态商品描述。这需要构建一个融合图文信息的统一商品知识库，并在多模态模型上进行指令微调。

2. 从“单点召回”到“序列生成与规划”目前的生成是“一次性”的，生成N个独立的商品描述。未来的方向是生成一个连贯的商品序列或搭配方案。例如，根据用户当前浏览的一件外套，生成与之搭配的裤子、鞋子和配饰的完整描述序列。这需要模型具备更强的规划能力和时尚知识，其输出可以直接用于构建“虚拟穿搭”或“场景化购物清单”等新功能。

3. 与排序模型的深度协同目前生成式召回和后续的排序模型是相对独立的。一个更极致的思路是端到端的生成式推荐，或者至少让生成与排序深度协同。例如，可以将生成式模型作为一个“提案器”，其生成的描述或中间层表示，直接作为特征输入到排序模型中，让排序模型在打分时就能考虑到这些“生成意图”。也可以探索基于强化学习的框架，让生成模型根据排序模型反馈的点击信号进行在线学习。

4. 可控性与可解释性的增强生成式模型的“黑盒”特性在商业系统中是一个风险。我们需要增强其可控性。例如，开发更精细的“控制面板”，允许运营同学通过调整一些参数（如“探索系数”、“风格权重”），来干预生成式召回的整体倾向。同时，研究如何为生成的推荐结果提供简单的解释，例如“根据您喜欢的X风格，推荐了具有Y元素的商品”，提升用户体验和信任度。

生成式AI正在重塑推荐系统的技术架构。生成式召回作为第一块重要的拼图，其价值在于将推荐的逻辑从“历史数据的拟合”部分转向了“未来需求的推理”。这条路充满挑战，包括成本、幻觉、评估等诸多难题，但其带来的推荐多样性和深度，是传统方法难以企及的。在得物的实践中，我们深刻体会到，技术落地没有银弹，关键在于找到技术与业务场景的最佳结合点，用小步快跑、持续迭代的方式，将前沿技术的潜力一步步转化为真实的用户价值和商业增长。这个过程，既需要工程师对技术的深刻理解，也需要对用户需求的敏锐洞察，两者缺一不可。