1. 为什么大模型和推荐系统会走到一起推荐系统这个行当过去十年基本是特征工程和深度模型的天下。从最早的协同过滤到后来的WideDeep、DeepFM再到双塔召回和序列建模整个技术栈的演进逻辑其实很清晰用更复杂的模型去拟合更细粒度的用户行为。但这条路线走到今天瓶颈已经非常明显了。最核心的问题是特征工程的天花板。一个推荐系统里特征数量动辄几百上千个交叉特征、统计特征、实时特征层层叠加维护成本极高。更麻烦的是这些特征大多是硬编码的——你告诉模型用户看了A商品又看了B商品但模型并不知道A和B之间在语义上有什么关系。它只能通过大量样本去记住这种关联而不是理解它。大模型带来的最大变化就是语义理解能力。一个经过充分预训练的LLM天然具备对文本、行为序列、甚至多模态信息的深层理解。它能把用户最近浏览了露营装备、搜索了帐篷、收藏了户外电源这一串行为压缩成一个语义向量而这个向量本身就携带了这个用户可能在准备一次户外露营的高层信息。这种能力传统推荐模型需要大量特征工程和样本才能逼近而LLM几乎是自带的。另一个驱动力是冷启动和长尾问题。传统推荐系统对新用户、新物品非常不友好因为没有历史行为数据协同过滤直接失效。但LLM可以通过物品的文本描述、类目信息、甚至图片直接生成一个合理的初始表示。用户侧也一样哪怕只有一个注册信息LLM也能从人口统计学特征中推断出一些基础偏好。这就把推荐系统的可用门槛大幅降低了。但这里必须泼一盆冷水LLM不是推荐系统的万能药。它的推理成本、延迟、以及幻觉问题在推荐场景下都会被放大。推荐系统要求毫秒级响应而一个7B参数的模型做一次前向推理在GPU上可能就要几十毫秒更别说更大的模型。所以怎么用、用在哪一层、用多大的模型这些才是真正需要想清楚的问题。我见过不少团队一上来就想用LLM替换整个推荐链路结果线上延迟直接爆炸最后灰溜溜地退回原来的方案。LLM在推荐里的定位更像是增强组件而不是替代方案。2. 技术范式的三条主流路线2.1 生成式推荐把推荐当成序列生成任务这是最激进的一条路线核心思想是把推荐问题转化为序列到序列的生成问题。具体来说就是把用户的历史行为序列比如看了A、点了B、买了C作为输入让LLM直接生成下一个可能交互的物品ID或描述。这条路线最早引起关注是因为有研究团队尝试用GPT类的模型做推荐把物品ID映射成特殊的token然后像训练语言模型一样训练推荐模型。它的优势很明显统一了召回和排序不再需要多阶段漏斗理论上一个模型就能端到端完成推荐。但实操中的坑也很多。首先是物品ID的token化问题。一个电商平台可能有上亿个物品如果每个物品都映射成一个独立token词表会爆炸。常见的做法是用层次化编码比如类目-子类目-品牌-单品这样的层级结构或者用语义ID比如用物品的文本描述经过编码后的聚类中心。但无论哪种方式都会损失一部分精度。其次是训练数据的构造。语言模型的训练目标是预测下一个token但推荐场景下用户的行为序列并不是天然的语言。你需要设计合适的模板比如用户之前交互过物品A、物品B、物品C。请预测下一个可能交互的物品。这个模板的设计直接影响模型效果而且不同业务场景下最优模板可能完全不同。我试过在同一个数据集上用不同的模板格式训练效果差异能达到10%以上。模板里的措辞、分隔符、甚至标点符号都会影响模型对任务的理解。2.2 表征增强用LLM生成更好的Embedding这条路线相对温和也是目前工业界落地最多的方式。核心思路是不改变原有推荐模型的结构而是用LLM来生成更高质量的特征表示。具体做法有很多种。一种是用LLM对物品的文本描述进行编码得到一个语义向量然后把这个向量作为物品的额外特征输入到原来的双塔模型里。另一种是用LLM对用户的行为序列进行摘要生成一段自然语言描述再把这段描述编码成向量。还有一种是用LLM做特征交叉比如把用户画像和物品属性拼接成一段文本让LLM输出一个交互后的表示。这条路线最大的好处是对现有系统改动小。你不需要重新训练整个推荐模型只需要在特征工程环节加一个LLM编码器把生成的embedding灌进去就行。而且LLM的推理可以离线做线上只需要查表延迟完全可控。但它的局限性也很明显LLM的语义表示和推荐任务的目标并不完全对齐。LLM是在通用语料上预训练的它理解的相似是语义上的相似而推荐系统需要的相似是行为上的相似。比如苹果和香蕉在语义上都是水果但在电商场景下买苹果的人可能和买香蕉的人行为模式完全不同。所以直接用LLM的embedding效果往往不如预期需要做进一步的微调或对齐。2.3 混合架构LLM做推理传统模型做打分这是目前最务实的方案。核心思想是让LLM负责它擅长的事情——语义理解、逻辑推理、可解释性生成而把大规模打分和排序交给传统模型。一个典型的架构是这样的用户请求进来后先用传统召回模型从海量物品中粗筛出几百个候选然后LLM对这几百个候选进行重排序。LLM可以看到用户的完整行为序列和每个候选物品的详细描述进行更精细的偏好判断。最后传统排序模型再对LLM重排后的结果做最终打分输出给用户。这种架构的好处是兼顾了效果和效率。LLM只处理几百个候选推理成本可控传统模型处理海量物品保证响应速度。而且LLM的重排结果还可以作为训练信号反过来提升传统模型的效果。但这里有个关键问题LLM的重排延迟。即使只处理几百个候选如果每个候选都要单独构造prompt让LLM打分延迟依然很高。常见的优化手段包括把多个候选放在同一个prompt里让LLM一次性排序或者用LLM生成一个查询向量然后用向量检索的方式快速筛选。这些工程细节往往决定了方案能不能真正上线。3. 证据边界LLM在推荐里到底能解决什么问题3.1 效果提升的边界在哪里从公开的研究和工业实践来看LLM在推荐系统里的效果提升主要集中在以下几个场景冷启动场景。这是LLM优势最明显的领域。新用户没有行为数据传统模型只能推热门物品而LLM可以根据用户的注册信息、首次搜索query、甚至设备信息推断出初步偏好。有实验表明在冷启动阶段LLM增强的推荐系统相比传统方案点击率能提升20%以上。长尾物品推荐。长尾物品因为交互数据少传统模型很难学好它们的表示。但LLM可以通过物品的文本描述、图片、类目信息生成一个合理的语义表示从而让长尾物品也有机会被推荐出去。这对平台生态多样性有重要意义。可解释性推荐。LLM可以生成自然语言的推荐理由比如因为你最近在看露营装备这款帐篷和你的需求很匹配。这种可解释性不仅能提升用户信任还能反过来帮助模型调试——当推荐效果不好时你可以看LLM给出的理由判断是哪个环节出了问题。但在头部热门物品的推荐上LLM的优势并不明显。因为这些物品已经有大量交互数据传统模型已经学得很好了LLM的语义理解带来的边际收益很小。而且LLM的推理成本远高于传统模型在头部物品上投入LLM算力性价比很低。3.2 延迟与成本的硬约束这是LLM推荐落地最大的障碍。一个线上推荐系统通常要求在100毫秒内完成从召回、排序到返回结果的整个流程。而一个7B参数的LLM即使经过量化单次推理也需要几十毫秒。如果要在排序阶段对几百个候选逐一打分延迟直接不可接受。目前的解决方案主要有几种离线预计算。把LLM的推理结果提前算好存起来线上只做查表。比如物品的语义embedding、用户的偏好摘要都可以离线生成。这种方式延迟最低但缺点是实时性差无法捕捉用户的即时兴趣变化。模型蒸馏。用LLM作为教师模型训练一个小模型来模仿LLM的行为。小模型线上推理延迟可控同时保留了一部分LLM的能力。但蒸馏过程会损失信息效果通常不如直接用LLM。缓存与增量更新。对高频请求的结果做缓存只对新增或变化的请求调用LLM。这种方式适合用户行为变化不快的场景比如电商推荐用户兴趣在短时间内相对稳定。实测下来离线预计算缓存的方式在大多数场景下能把LLM的延迟影响控制在可接受范围内。但前提是你的业务场景允许一定的实时性损失。3.3 幻觉与一致性问题LLM的幻觉问题在推荐场景下尤其危险。如果LLM在生成推荐理由时编造了不存在的物品属性或者错误理解了用户意图会直接损害用户体验。更严重的是如果LLM在重排序时给出了不合理的排序结果可能导致整个推荐链路的效果下降。解决这个问题目前主要靠约束解码和后处理校验。约束解码是指在生成时限制LLM只能从候选物品中选择不能自由发挥。后处理校验是指对LLM的输出做规则检查比如检查推荐理由中提到的属性是否真实存在排序结果是否符合基本业务规则。但这些手段都无法完全消除幻觉。所以在关键业务场景下LLM的输出通常只作为参考信号最终决策还是由传统模型或规则引擎来做。4. 落地路径从POC到上线的完整流程4.1 场景选择与价值评估第一步不是急着调模型而是想清楚在哪个场景用LLM。不是所有推荐场景都适合LLM你需要评估几个维度数据稀疏程度冷启动问题越严重LLM的价值越大语义理解需求如果物品和用户行为富含文本信息LLM优势更明显延迟容忍度实时性要求越低的场景LLM越容易落地成本预算LLM的推理成本是传统模型的几十倍需要算清楚ROI一个实用的方法是先在小流量上做A/B测试对比LLM增强方案和基线方案的核心指标。如果提升不明显或者成本增加太多就要重新考虑。4.2 数据准备与Prompt设计LLM推荐的效果很大程度上取决于输入数据的质量和Prompt的设计。你需要准备几类数据物品侧数据标题、描述、类目、属性、图片描述等。这些数据要尽量结构化、干净避免噪声。如果物品描述本身质量很差LLM也救不了。用户侧数据历史行为序列、搜索query、人口统计学信息等。行为序列需要做清洗和截断太长的序列会超出LLM的上下文窗口太短的序列信息量不足。交互数据点击、购买、收藏等正负样本。这些数据用于评估LLM推荐的效果也可以用于微调。Prompt设计是门手艺活。你需要明确告诉LLM任务是什么、输入是什么、输出格式是什么。比如你是一个推荐系统。根据用户的历史行为从候选物品中选择最可能被用户交互的5个物品。 用户历史行为 - 浏览了露营帐篷 - 搜索了户外电源 - 收藏了登山鞋 候选物品 1. 双人帐篷 2. 便携式电源 3. 登山背包 4. 野餐垫 5. 头灯 请按可能性从高到低排序并给出简短理由。这个Prompt看起来简单但里面的每个细节都会影响效果。比如候选物品的数量、排序的要求、理由的长度限制都需要反复调试。4.3 模型选型与微调策略模型选型要考虑效果、成本、延迟三个因素的平衡。闭源大模型效果最好但成本高、延迟大、数据隐私风险高。开源模型可以私有化部署成本可控但效果可能差一些。目前工业界常用的方案是用大模型做离线数据生成和蒸馏用小模型做线上推理。具体来说先用一个大模型比如70B级别对大量样本进行推理生成高质量的推荐结果或embedding然后用这些小模型比如1B到7B级别去学习大模型的输出。这样线上推理用小模型延迟和成本都可控同时保留了大模型的大部分能力。微调策略也很关键。全量微调成本太高通常采用LoRA或Adapter这样的参数高效微调方法。微调数据的选择上要尽量覆盖不同的用户行为和物品类型避免模型过拟合到某个特定场景。4.4 线上部署与效果监控线上部署时LLM通常作为一个独立的服务通过API调用。这个服务需要做好几件事请求批处理把多个用户的请求合并成一个batch一次性送给LLM推理提高GPU利用率。超时与降级设置合理的超时时间如果LLM服务响应超时自动降级到传统推荐方案保证系统可用性。缓存机制对高频请求的结果做缓存减少重复推理。效果监控除了常规的点击率、转化率指标还要监控LLM输出的质量比如推荐理由的合理性、排序结果的一致性等。我踩过的一个坑是LLM服务刚上线时没有做超时降级结果某次GPU负载过高整个推荐接口全部超时线上直接挂了。后来加了降级逻辑才稳定下来。5. 常见问题与排查技巧实录5.1 LLM推荐效果不如传统模型这是最常见的问题。原因可能有几个Prompt设计不合理。LLM没有正确理解任务或者输入信息不完整。排查方法是把Prompt打印出来人工检查LLM的输入输出看是否符合预期。候选集质量差。如果传统召回阶段给出的候选物品本身就不相关LLM再强也无力回天。需要先优化召回环节。LLM的语义相似和推荐相似不一致。LLM认为相似的物品用户可能并不感兴趣。这时候需要用推荐数据对LLM做微调或者用传统模型对LLM的embedding做二次映射。评估指标不匹配。LLM优化的是生成概率而推荐系统关心的是点击率、转化率。两者之间存在gap需要通过微调或后处理来对齐。5.2 延迟过高无法上线延迟问题的排查思路问题环节可能原因解决方案模型推理模型太大、batch太小量化、蒸馏、增大batch网络传输服务部署在远端本地部署、边缘计算数据处理特征拼接耗时预计算、缓存排队等待GPU资源不足扩容、优先级调度实测下来量化蒸馏批处理三件套通常能把延迟降低一个数量级。如果还是不行就要考虑把LLM从在线链路移到离线链路。5.3 输出结果不稳定LLM的输出有随机性同样的输入可能得到不同的推荐结果。这在推荐场景下是个问题因为用户会感到困惑。解决方法包括设置temperature为0让输出尽量确定固定随机种子保证可复现后处理排序对LLM的输出做规则化的重排保证稳定性。但完全消除随机性是不可能的也不一定必要。适度的多样性对推荐系统反而是好事可以避免信息茧房。关键是要控制随机性的范围不能让结果完全不可预测。5.4 成本失控LLM的推理成本是传统模型的几十倍甚至上百倍。如果不加控制很容易成本失控。控制成本的手段限制LLM的调用频率只对关键请求调用使用小模型在效果和成本之间找平衡离线预计算减少在线推理次数缓存结果避免重复计算。我建议在项目初期就建立成本监控按天统计LLM的调用次数和费用。一旦发现成本增长过快及时排查原因。6. 一些实操中的个人体会LLM在推荐系统里的落地技术只是一部分更多是工程和业务的权衡。我见过太多团队在技术上做得很漂亮但因为成本、延迟、或者业务方不认可最终没能上线。一个实用的建议是从小场景切入快速验证价值。不要一上来就想着替换整个推荐链路先找一个冷启动或者长尾推荐的子场景用LLM做增强看效果和成本是否可接受。如果验证通过再逐步扩大范围。另一个体会是LLM不是越强越好。一个70B的模型效果可能比7B的好但推理成本高10倍。在推荐场景下很多时候7B的模型已经足够好了多出来的效果提升不值得多花10倍的成本。选型时要算清楚这笔账。最后不要忽视传统模型的价值。LLM和传统模型不是替代关系而是互补关系。LLM擅长语义理解和冷启动传统模型擅长大规模打分和实时响应。把两者结合起来往往能得到最好的效果。这个方向还在快速演进新的方法和技术层出不穷。但核心逻辑是不变的用LLM补足传统推荐系统的短板而不是推翻重来。想清楚这一点落地路径就会清晰很多。