1. 为什么推荐系统需要大模型从“特征工程”到“语义理解”的范式迁移推荐系统这个行当干了十几年核心矛盾一直没变过如何从用户的历史行为里猜出他下一秒想要什么。早期我们靠协同过滤后来靠矩阵分解再后来深度学习把特征工程推到了极致——用户ID、物品ID、交叉特征、序列行为统统塞进一个宽深的网络里效果确实好。但问题也来了这套玩法越来越像“记忆机器”它擅长记住“A用户看过B物品”却不擅长理解“A用户为什么看B物品”。大模型进来之后最大的变化不是把模型变大而是把推荐问题重新定义成了一个语义理解问题。以前我们做召回是算向量内积现在做召回是让模型去读用户的行为序列然后生成一个“用户意图摘要”。这个摘要可以是自然语言也可以是稠密向量但本质上它不再是简单的ID映射而是对用户当前状态的语义压缩。我举个实际场景你就明白了。假设一个用户最近看了三篇关于“露营装备”的内容又搜了一次“周末去哪玩”。传统模型会给他推帐篷、睡袋、户外电源。但大模型能读出更深一层他可能在计划一次周末露营需要的是“从零开始的露营清单”而不是单件商品。这就是语义理解和行为记忆的区别。这个范式迁移带来的直接影响有三个。第一冷启动问题被大幅缓解。新用户没有历史行为但只要有几句对话或者一次搜索大模型就能推断出意图。第二跨域推荐变得自然。用户在内容域的行为可以语义化地迁移到商品域不需要复杂的域对齐。第三推荐理由可以生成。以前推荐理由都是模板化的“因为你看了X”现在可以让模型直接写出“你最近在关注露营这款帐篷适合新手搭建只要5分钟”。但这里有个关键点必须说清楚大模型不是替代了推荐系统而是接管了推荐系统里最难的那部分——意图理解。排序、打分、重排这些环节传统模型依然高效。所以落地路径不是“把推荐系统换成LLM”而是“在关键环节插入LLM能力”。2. 技术范式拆解LLM在推荐链路里到底能干什么2.1 四种主流范式及其适用边界把LLM塞进推荐系统目前跑通的路径大概有四条每条都有自己的甜点区和坑。第一条是LLM as Encoder。把用户行为序列、物品描述、上下文信息拼成一段文本喂给LLM取最后一层隐状态或者池化后的向量作为用户/物品的表征。这条路径最成熟改动最小本质上是用LLM替换了原来的特征编码器。优点是工程上容易落地缺点是推理成本高而且LLM的预训练目标跟推荐目标不一致需要做对齐。第二条是LLM as Generator。让LLM直接生成推荐结果比如“根据用户历史推荐以下10个物品”。这条路径听起来很酷但实际落地最难。因为推荐是一个从百万级候选里选Top-K的问题而LLM的生成空间是整个词表你没法保证它生成的物品ID一定在候选集里。所以这条路径目前更多用在重排阶段让LLM对粗排后的几十个结果做精细排序和理由生成。第三条是LLM as Reasoner。不让LLM直接推荐而是让它做中间推理。比如用户问“我想买个适合新手的相机”LLM先推理出“新手、预算敏感、需要轻便、可能拍vlog”然后把这些结构化意图传给下游推荐模型。这条路径最实用因为它把LLM的语义理解能力和传统推荐系统的高效检索能力结合起来了。第四条是LLM as Simulator。用LLM模拟用户行为生成合成数据来训练推荐模型。这条路径在冷启动和数据稀疏场景下特别有价值但风险是模拟数据和真实分布有偏差需要做校准。范式核心思路落地难度典型场景主要风险LLM as Encoder用LLM提取语义表征低召回、粗排推理成本、目标不对齐LLM as Generator直接生成推荐结果高重排、理由生成候选集约束、幻觉LLM as Reasoner做意图推理和结构化中意图理解、查询改写推理延迟、错误传播LLM as Simulator生成合成交互数据中冷启动、数据增强分布偏差、校准困难2.2 为什么“LLM as Reasoner”是当前最务实的切入点我试过直接让LLM生成推荐列表效果很不稳定。同一个用户换个prompt模板推荐结果能差出30%。后来换成Reasoner模式让LLM只负责把用户行为翻译成结构化意图标签比如{意图: 露营装备采购, 阶段: 新手入门, 预算: 中等, 偏好: 轻量化}然后把这些标签喂给下游的召回和排序模型效果立刻稳了。原因很简单LLM擅长的是语义理解和推理不擅长精确检索和打分。你让它做它擅长的事它就很靠谱你让它做它不擅长的事它就开始胡说。所以落地路径的第一步应该是把推荐链路拆开找到那些“需要语义理解但传统模型做不好”的环节把LLM插进去。具体来说这几个环节最适合LLM介入查询理解用户搜“适合送女朋友的生日礼物”传统模型只能匹配关键词LLM能推理出“女朋友、生日、礼物、预算未知、需要惊喜感”。行为序列压缩用户过去100次点击传统模型用Transformer编码LLM可以用自然语言总结成“该用户最近在关注母婴用品可能是有新生儿家庭”。跨域意图迁移用户在内容域看了很多健身视频LLM可以推理出他对健身装备也有潜在兴趣。推荐理由生成这个最直接LLM生成的理由比模板自然得多点击率提升很明显。2.3 一个容易被忽略的细节LLM的“知识边界”问题LLM有一个特性它知道很多世界知识但这些知识是有时效性的而且不一定跟你的物品库对齐。比如你的电商平台刚上了一批新品牌LLM的训练数据里根本没有这些品牌信息。这时候如果你直接让LLM做推理它就会用旧知识去猜结果就是推荐一些你根本没有的物品。解决办法有两个。一是RAG检索增强生成先把物品库里的相关信息检索出来拼进prompt里让LLM基于检索到的内容做推理。二是微调用平台自己的数据对LLM做轻量微调让它对齐你的物品空间。前者工程上更灵活后者效果更稳定但成本更高。我个人的经验是冷启动阶段用RAG数据积累到一定量之后再做微调。RAG的好处是随时可以更新检索库新物品上架立刻就能被检索到微调的好处是推理时不需要拼很长的prompt延迟更低。3. 证据边界LLM做推荐哪些事能信哪些事不能信3.1 离线评估的陷阱为什么AUC涨了线上却没效果这是踩过最大的坑。离线用LLM做召回AUC从0.72涨到0.78团队都很兴奋结果上线之后点击率反而掉了。排查了很久才发现问题LLM的语义表征在离线评估里占了便宜因为离线数据里用户行为序列是完整的LLM能读到全量信息但线上推理时用户行为序列是实时截断的LLM读到的信息不完整表征质量就下降了。这个坑的本质是离线评估和线上推理的信息条件不一致。LLM对输入信息的完整性非常敏感你给它完整的序列它表现很好你给它截断的序列它可能还不如传统模型稳定。所以做LLM推荐离线评估必须模拟线上的信息条件。具体做法是在离线评估时也按照线上的截断策略来构造输入而不是用全量序列。另外要特别关注长尾用户的表现因为长尾用户的行为序列本来就短LLM的优势本来就不明显如果离线评估只盯着头部用户很容易高估效果。3.2 幻觉问题在推荐场景的特殊表现LLM的幻觉在推荐场景里不是“胡说八道”而是生成不存在的物品、错误的物品属性、或者过时的信息。比如你让LLM生成推荐理由它可能会写“这款相机有8K视频功能”但实际上你的商品库里这款相机只支持4K。这种幻觉在传统推荐系统里是不存在的因为传统系统的输出空间被严格限制在候选集里。解决幻觉问题目前最有效的手段是约束解码。具体来说就是在LLM生成的时候把候选集里的物品ID或者属性作为约束条件让LLM只能从这些选项里选。工程上可以用前缀树或者有限状态机来实现确保生成的每个token都在合法空间里。另一个手段是后验校验。LLM生成推荐理由之后用一个轻量级的校验模型去检查理由里的每个事实是否和物品库一致。不一致的就打回重生成或者直接降级到模板理由。这个校验模型不需要很大用BERT级别的模型就够了。3.3 成本边界什么情况下LLM推荐不划算LLM推理成本是传统模型的几十倍甚至上百倍。如果你的推荐场景是“亿级用户、毫秒级响应”那全链路用LLM根本不现实。所以必须做分层处理头部流量用LLM做精细推理和重排因为头部流量贡献大部分收入值得花这个成本。腰部流量用LLM做意图理解但召回和排序还是用传统模型。尾部流量完全用传统模型LLM只做离线数据增强。这个分层策略的核心逻辑是LLM的价值在于处理复杂意图和长尾场景而不是替代所有推荐决策。你把LLM用在它最擅长的地方成本就可控了。流量层级LLM介入程度典型延迟要求成本占比效果提升预期头部全链路推理重排200-500ms高显著腰部仅意图理解50-100ms中中等尾部仅离线增强不涉及在线低有限4. 落地路径从POC到全量上线的完整实操4.1 第一步选一个“小而痛”的场景做POC不要一上来就搞全链路LLM推荐必死。选一个传统模型明显做不好的场景比如跨域推荐或者冷启动推荐用LLM做单点突破。我当时的做法是选了一个“新用户首次推荐”的场景。新用户没有历史行为传统模型只能推热门物品点击率很低。我让LLM读用户的注册信息比如年龄、性别、注册渠道和首次搜索词推理出初始意图然后基于意图做召回。上线之后新用户的首次点击率提升了18%。这个POC的关键是场景要小指标要清晰对比要严格。不要同时改多个变量否则你根本不知道效果提升是LLM带来的还是其他改动带来的。4.2 第二步搭建LLM推理服务的基础设施LLM推理和传统模型推理完全不是一个量级。传统模型一个GPU能扛几千QPSLLM一个GPU可能只能扛几十QPS。所以基础设施必须重新设计。核心组件包括推理引擎用vLLM或者TensorRT-LLM做推理加速支持连续批处理和PagedAttention。缓存层对相同的用户意图做缓存避免重复推理。缓存key可以是用户行为序列的哈希缓存value是LLM输出的意图标签。降级策略LLM推理超时或者失败时自动降级到传统模型。这个必须做否则LLM一挂整个推荐系统就崩了。监控体系除了常规的延迟、QPS、错误率还要监控LLM输出的语义漂移。比如意图标签的分布是否稳定有没有出现大量未知标签。注意LLM推理服务的冷启动很慢模型加载可能要几分钟。所以必须做预热在流量低峰期提前加载好模型避免高峰期扩容时来不及。4.3 第三步Prompt工程与输出解析Prompt的设计直接决定LLM输出的质量。我试过很多模板最后稳定下来的结构是你是一个推荐系统的意图理解模块。根据以下用户行为输出结构化的意图标签。 用户行为序列 {behavior_sequence} 可用意图标签 {intent_labels} 输出格式 {intent: 标签名, confidence: 0.0-1.0, reason: 简短理由} 只输出JSON不要其他内容。这个模板的关键点有三个。第一明确角色让LLM知道自己是在做意图理解不是闲聊。第二限定输出空间给出可用标签列表避免LLM自己造标签。第三强制JSON格式方便后续解析。输出解析这块一定要做容错处理。LLM有时候会输出不完整的JSON或者多输出一段解释文字。所以解析器要能处理这些异常情况解析失败时降级到默认意图。4.4 第四步与传统推荐系统的融合LLM输出的意图标签最终要转化成传统推荐系统能用的信号。融合方式有三种第一种是特征拼接。把意图标签做Embedding拼到传统模型的特征向量里。这种方式改动最小但效果提升有限因为意图标签的信息量不如原始行为序列丰富。第二种是召回通道。把意图标签作为一路召回通道和传统的行为序列召回、热门召回并行。这种方式效果提升明显因为意图召回能覆盖传统召回覆盖不到的长尾物品。第三种是重排信号。把意图标签作为重排模型的输入特征让重排模型根据意图调整排序。这种方式对最终效果影响最大但需要重排模型重新训练。我实际落地时用的是第二种第三种组合意图标签既做一路召回也做重排特征。上线之后整体点击率提升了7%长尾物品的曝光占比提升了12%。4.5 第五步A/B实验与迭代LLM推荐的A/B实验和传统模型不一样因为LLM的输出有随机性。同一个用户同样的输入LLM可能输出不同的意图标签。所以实验设计要特别注意实验组和对照组的流量要足够大因为LLM的方差比传统模型大。实验周期要足够长至少两周因为LLM的效果可能需要时间才能显现。除了点击率还要关注多样性、新颖性、覆盖率等指标因为LLM推荐容易陷入“语义相似”的陷阱推荐结果可能很相关但很单调。我踩过的一个坑是实验初期只看点击率发现实验组涨了5%就急着全量。结果全量之后发现用户留存率反而掉了。后来分析发现LLM推荐的结果太“精准”了用户看多了会觉得无聊。所以后来加了多样性约束在LLM输出的意图标签里强制要求覆盖多个类别。5. 常见问题与排查技巧实录5.1 LLM输出不稳定同一个用户每次意图都不一样这是最常见的问题。原因通常是prompt里的行为序列太长LLM的注意力被分散了。解决办法是对行为序列做摘要不要直接把原始序列喂进去而是先用一个轻量级模型把序列压缩成几个关键事件再把关键事件喂给LLM。另一个原因是温度参数设置过高。做意图理解时温度应该设成0或者0.1让输出尽量确定。只有做推荐理由生成时才需要适当提高温度让理由更多样。5.2 LLM推理延迟太高线上扛不住延迟高的原因通常有三个模型太大、batch太小、prompt太长。对应的解决办法模型太大换小模型或者用量化版本。7B模型在意图理解任务上效果和70B模型差不了太多但延迟低一个数量级。batch太小用连续批处理把多个用户的请求拼成一个batch。vLLM在这方面做得很好可以做到毫秒级的batch调度。prompt太长压缩prompt去掉不必要的说明文字只保留核心信息。行为序列做摘要不要直接拼原始序列。5.3 LLM推荐的物品和用户历史行为太相似缺乏惊喜感这是LLM推荐的固有缺陷它太擅长找语义相似的东西了。解决办法是在prompt里显式要求多样性比如“请推荐3个与用户历史行为相关但类别不同的物品”。另外可以在后处理阶段做打散强制不同类别的物品交替出现。5.4 离线指标涨了线上没效果这个问题在3.1节已经详细说过核心原因是离线评估和线上推理的信息条件不一致。排查步骤检查离线评估时用的行为序列长度是否和线上一致。检查离线评估时用的物品库是否和线上一致。检查LLM的输出解析逻辑离线评估时是否做了容错处理。检查线上是否有降级策略LLM推理失败时是否降级到了传统模型。问题现象可能原因排查方法解决方案输出不稳定温度过高、序列过长检查温度参数、序列长度降温、序列摘要延迟过高模型大、batch小、prompt长检查模型大小、batch size、prompt长度换小模型、连续批处理、压缩prompt推荐太相似缺乏多样性约束检查推荐结果的类别分布prompt加多样性要求、后处理打散离线涨线上不涨信息条件不一致对比离线/线上的输入构造统一输入条件、加降级策略5.5 一个容易被忽略的坑LLM的“位置偏见”LLM对prompt里的位置很敏感。同样的信息放在开头和放在结尾LLM的注意力分配完全不同。做推荐时如果你把用户最近的行为放在序列末尾LLM会过度关注最近行为忽略长期兴趣。解决办法是显式标注时间信息比如“用户3天前看了A1小时前看了B”让LLM自己判断时间权重。这个坑我踩了很久才发现。当时一直以为是模型能力问题后来做了注意力可视化才发现是位置偏见导致的。调整了prompt结构之后长期兴趣的召回率提升了15%。6. 一些实操心得与后续扩展方向LLM做推荐最核心的认知是它不是银弹而是一把手术刀。你用它去切传统模型切不动的地方比如语义理解、跨域迁移、冷启动效果很好。但你如果用它去替代整个推荐链路成本和效果都划不来。我个人的经验是LLM推荐的ROI最高的三个场景是新用户冷启动、跨域推荐、推荐理由生成。这三个场景传统模型做不好LLM做起来很自然而且成本可控。后续扩展方向我觉得有两个值得关注。一是多模态LLM推荐把图片、视频信息也纳入意图理解这对内容平台特别有价值。二是LLM作为推荐系统的“世界模型”用LLM模拟用户对物品的反应做离线策略评估减少对线上A/B实验的依赖。最后分享一个小技巧LLM的输出一定要做后处理。不要直接把LLM的输出喂给下游中间加一层规则引擎或者轻量级模型做校验和修正。这层后处理能过滤掉80%的异常输出让整个系统稳定很多。