1. 为什么大模型做推荐这件事值得认真聊推荐系统这个行当过去十年基本是特征工程和深度模型的天下。从最早的协同过滤到后来的WideDeep、DeepFM再到双塔召回加精排的经典架构整套技术栈已经相当成熟。但最近一两年情况在变。大语言模型展现出的语义理解、常识推理和零样本泛化能力让不少人开始琢磨能不能把LLM直接拿来做推荐这个问题的吸引力在于传统推荐系统有几个绕不开的痛点。冷启动问题——新用户没有行为数据新物品没有交互记录模型基本抓瞎。语义鸿沟问题——用户看了三篇关于露营的帖子系统只能学到户外这个粗粒度标签但用户到底是想买帐篷还是想找露营地模型分不清。还有解释性问题——推荐理由往往是看了又看这种统计口径缺乏真正的语义逻辑。LLM的介入理论上能在这几个方向上带来质变。它可以把用户行为序列当成一段文本来理解把物品描述当成语义向量来匹配甚至直接用自然语言生成推荐理由。但理论归理论落地归落地。我见过不少团队兴冲冲地拿LLM做推荐结果要么效果不如传统模型要么成本高到无法上线要么离线指标好看但线上A/B测试一塌糊涂。所以这篇内容我想把LLM做推荐这件事拆开来讲。从技术范式到证据边界再到实际落地路径尽量把我知道的、踩过的、验证过的东西说清楚。适合正在考虑技术选型的推荐算法工程师、对LLM应用感兴趣的产品经理以及想了解这个方向真实进展的技术管理者。不吹不黑只讲能落地的部分。2. 技术范式拆解LLM到底怎么切入推荐系统2.1 四种主流范式及其适用场景把LLM用在推荐系统里目前能看到的做法大致可以归为四类。这四类不是互斥的很多实际系统是组合使用但每类的技术逻辑和适用边界差别很大。第一类LLM作为特征增强器。这是最保守也最容易落地的做法。传统推荐模型依赖大量离散特征比如用户ID、物品ID、类别标签。LLM的作用是把这些离散特征转化成稠密的语义向量。举个例子物品标题便携式折叠桌椅套装户外露营野餐装备经过LLM编码后得到的向量不仅包含户外这个类别信息还隐含了便携折叠套装等语义维度。这些向量喂给下游的排序模型能显著提升泛化能力。这种做法的好处是改动小、风险低。你不需要推翻现有架构只需要在特征工程环节加一个LLM编码模块。但缺点是LLM的能力没有被充分利用它只是个高级的embedding工具。第二类LLM作为推荐主模型。这是最激进的做法直接把用户历史行为序列和候选物品列表拼成prompt让LLM输出推荐结果或排序分数。比如用户最近看了A、B、C三件商品请从以下候选中选出最可能感兴趣的五个。这种做法理论上能利用LLM的全部推理能力但实际面临几个硬伤推理延迟高、token成本大、输出格式不稳定。我试过用这种方式做小规模实验效果确实有亮点但工程上很难支撑大规模线上服务。第三类LLM作为交互式推荐引擎。这类做法不追求一次性给出最优推荐而是通过多轮对话逐步澄清用户需求。比如用户说想买个礼物送朋友LLM会追问预算、朋友喜好、场合等信息然后给出推荐。这种范式适合客单价高、决策周期长的场景比如家电、珠宝、课程推荐。但对话式推荐的转化路径很长用户愿不愿意跟你聊那么多轮是个大问题。第四类LLM作为推荐系统的大脑传统模型作为手脚。这是我个人最看好的方向。LLM负责理解用户意图、生成候选集、提供解释传统模型负责大规模召回和实时排序。两者各司其职LLM做它擅长的事传统模型做它擅长的事。比如LLM可以从用户评论中提取细粒度的偏好标签这些标签再喂给传统排序模型做特征。范式类型核心逻辑优势主要瓶颈适用阶段特征增强器LLM编码语义特征改动小、风险低未充分利用LLM能力冷启动、长尾物品推荐主模型LLM直接输出推荐推理能力强延迟高、成本大小规模实验交互式引擎多轮对话澄清需求理解深度好转化路径长高客单价场景大脑手脚LLM理解传统模型执行平衡效果与成本架构复杂度高大规模线上系统2.2 为什么大脑手脚模式更靠谱我之所以更看好第四类范式是因为它符合工程上的一个基本原则让每个组件做它最擅长的事。LLM的强项是语义理解和常识推理弱项是数值计算和大规模并发。传统推荐模型的强项是处理海量稀疏特征和实时打分弱项是理解自然语言和跨域知识。把两者结合起来一个典型的架构是这样的用户行为序列先经过LLM做意图理解提取出结构化的偏好表示比如用户最近关注轻量化户外装备预算敏感偏好国产品牌。这些结构化信息再输入到传统排序模型中作为高阶特征使用。同时LLM还可以对召回结果做重排序把语义上更匹配的物品往前排。这种架构的关键在于LLM的调用频率可以控制。不需要对每个请求都调用LLM可以离线批量处理用户画像或者只对高价值用户实时调用。成本可控效果也有保障。2.3 一个容易被忽略的范式LLM做数据增强除了上面四类还有一个做法值得单独提用LLM生成训练数据。推荐系统最缺的是什么是高质量的标注数据。用户点击了不代表喜欢用户没点击也不代表不喜欢。LLM可以根据物品描述和用户历史生成这个用户会不会喜欢这个物品的合成样本用来扩充训练集。我做过一个实验用LLM生成了十万条合成交互数据混入真实数据训练排序模型。在冷启动场景下AUC提升了大概3个点。这个提升不算惊人但考虑到零人工标注成本性价比很高。不过要注意合成数据的分布和真实数据有偏差不能完全替代真实数据只能作为补充。3. 证据边界LLM做推荐到底行不行3.1 离线指标好看不等于线上有效这是我最想强调的一点。很多论文和实验报告展示的LLM推荐效果都是在特定数据集上的离线指标。比如在Amazon Review数据集上LLM的NDCG比基线高了多少。但这些离线指标和线上效果之间隔着一条巨大的鸿沟。原因有几个。第一离线数据集往往是静态的而线上环境是动态的。用户的兴趣会漂移物品的流行度会变化LLM在静态数据上学到的模式放到线上可能很快就过时了。第二离线评估通常只考虑排序质量不考虑延迟、成本、多样性等线上约束。一个NDCG很高的模型如果推理要三秒钟线上根本没法用。第三离线数据集的构造方式本身就有偏。很多公开数据集是用户已经交互过的物品负样本是随机采样的这和线上真实的曝光-点击分布差别很大。我自己的经验是LLM推荐模型在离线指标上的提升通常要打三到五折才能对应到线上效果。如果离线只提升了2个点线上大概率看不出来。要做出线上可感知的提升离线指标至少要有5到10个点的进步。3.2 冷启动场景LLM的真正优势区LLM做推荐最被认可的优势场景是冷启动。新用户没有行为数据传统模型只能推热门物品千人一面。LLM可以通过用户注册时填写的少量信息或者首次交互的几句话推断出大致偏好。比如一个用户注册时选择了科技爱好者标签LLM可以推断出他可能对数码产品、编程书籍、科技新闻感兴趣而不是简单地推全站最热门的商品。这种推理能力是传统模型不具备的。但冷启动场景也有边界。LLM的推理是基于常识的不是基于真实行为的。它推断出的偏好可能很宽泛不够精准。而且冷启动用户的价值本身就不确定花大成本用LLM服务他们ROI未必划算。我的建议是对冷启动用户做分层高价值渠道来的用户用LLM做精细化推荐低价值渠道的用户还是走传统热门兜底。3.3 长尾物品推荐LLM的另一个亮点长尾物品的问题是交互数据少传统协同过滤学不到好的表示。LLM可以通过物品的文本描述理解它的语义属性从而在长尾物品之间建立关联。举个例子一个小众的手工皮具品牌没有多少用户点击数据。但LLM读了它的产品描述后可以把它和复古风格手工制作头层牛皮等语义标签关联起来。当用户搜索复古手工钱包时这个长尾物品就有机会被召回。这个能力在内容推荐场景尤其有价值。新闻、文章、视频这些内容文本信息丰富LLM的语义理解能发挥很大作用。但在电商场景物品描述往往很简短LLM能提取的信息有限效果就没那么明显。3.4 证据边界总结什么情况下LLM推荐值得投入综合来看LLM做推荐在以下几种情况下值得投入冷启动问题严重、长尾物品占比高、物品文本信息丰富、用户对推荐解释有需求、团队有LLM工程能力。反过来如果物品描述稀疏、用户行为数据充足、延迟要求极高、成本预算紧张那LLM推荐的优先级可以往后放。注意不要因为LLM火就硬上。推荐系统的核心指标是CTR、转化率、留存不是用了多先进的技术。技术选型要服务于业务目标。4. 落地路径从实验到上线的完整流程4.1 第一步明确业务目标和评估体系在动手之前先想清楚你要解决什么问题。是提升新用户的次日留存还是提高长尾物品的曝光占比还是降低推荐结果的同质化不同的目标对应不同的技术方案和评估指标。评估体系要分层设计。离线层面看召回率、NDCG、覆盖率、多样性。线上层面看CTR、转化率、人均停留时长、用户反馈。还要有成本指标比如单次推荐的LLM调用成本、平均响应延迟。我见过一个团队离线指标做得漂漂亮亮上线后发现LLM调用成本是传统模型的二十倍ROI算不过来项目直接搁置。所以成本评估一定要前置不要等上线了才发现烧不起。4.2 第二步数据准备与Prompt设计LLM推荐的效果很大程度上取决于输入数据的质量和Prompt的设计。数据准备包括用户行为序列的清洗和格式化、物品描述的标准化、负样本的构造。用户行为序列不能直接丢给LLM需要做预处理。比如把用户点击了物品A收藏了物品B购买了物品C转化成结构化的文本描述。时间间隔、行为类型、物品类别这些信息都要保留。Prompt设计有几个原则。第一指令要明确告诉LLM你要它做什么输出格式是什么。第二上下文要精简不要把无关信息塞进去浪费token还干扰判断。第三要给出示例few-shot learning对LLM的效果提升很明显。一个典型的Prompt模板你是一个推荐系统助手。根据用户的历史行为从候选物品中选出最可能感兴趣的5个。 用户历史行为 - 浏览了轻量徒步鞋停留时间较长 - 收藏了户外防风外套 - 搜索过露营装备清单 候选物品 1. 专业登山背包 2. 城市休闲运动鞋 3. 便携露营灯 4. 商务休闲裤 5. 户外急救包 请输出推荐序号并简要说明理由。4.3 第三步模型选型与微调策略用哪个LLM开源还是闭源大参数还是小参数这些问题没有标准答案取决于你的预算、延迟要求和数据隐私约束。如果只是做特征增强用中小规模的开源模型就够了比如7B参数级别的模型经过领域微调后效果可以接受。如果要做复杂的推理和交互可能需要更大参数的模型或者调用闭源API。微调策略上我建议先从Prompt engineering开始不要一上来就微调。Prompt调优的成本低、迭代快能快速验证方向。等Prompt优化到瓶颈了再考虑用领域数据做SFT。LoRA这类参数高效微调方法在推荐场景下性价比很高不需要全量微调就能获得不错的领域适配效果。4.4 第四步离线评估与线上实验离线评估要设计合理的测试集。不要只用随机划分要模拟线上的时间切分。比如用前三个月的数据训练第四个月的数据测试。这样才能反映模型在时间维度上的泛化能力。线上实验要遵循A/B测试的基本规范。对照组用传统模型实验组用LLM增强的模型。实验周期要足够长覆盖用户行为的周期性波动。指标要看核心业务指标不要只看推荐系统的内部指标。我踩过的一个坑是实验组只在小流量上跑了三天看到CTR涨了就全量上线结果一周后效果回落。后来分析发现LLM推荐的新鲜感导致短期点击率上升但用户很快审美疲劳。所以实验周期至少要两周覆盖完整的行为周期。4.5 第五步工程优化与成本控制LLM推荐的工程优化核心是降低延迟和成本。几个常用手段缓存对相同或相似的请求缓存LLM的输出结果。用户画像的更新频率不需要太高可以离线批量处理。蒸馏用大LLM的输出训练一个小模型线上用小模型推理。这样既保留了大模型的能力又降低了推理成本。异步非实时场景下LLM的调用可以异步化。比如用户画像的更新、物品语义向量的生成都可以离线做。降级设计好降级策略。当LLM服务不可用或延迟超标时自动切换到传统模型兜底。优化手段适用场景预期收益实施难度缓存用户画像、物品向量降低50%以上调用量低蒸馏排序模型、意图理解推理成本降80%中异步离线特征生成不影响线上延迟低降级所有线上场景保障可用性中5. 常见问题与排查技巧实录5.1 LLM输出格式不稳定怎么办这是最常见的问题。你让LLM输出JSON它有时候输出Markdown有时候加一堆解释文字。解决办法有几个第一在Prompt里明确输出格式并给出示例。第二用结构化输出功能很多LLM API支持强制JSON schema。第三后处理做容错解析用正则表达式提取关键信息。我通常的做法是Prompt里写清楚只输出JSON不要任何其他文字然后在代码里做两层解析先尝试直接解析JSON失败则用正则提取。这样能覆盖95%以上的情况。5.2 推荐结果同质化严重怎么破LLM有个倾向就是喜欢推荐安全的选项。你让它推荐五部电影它可能给出五部经典大片缺乏多样性。解决办法是在Prompt里加入多样性约束比如推荐五个不同风格的电影或者在解码阶段用多样性采样。另一个技巧是把LLM的推荐结果和传统模型的推荐结果做融合。传统模型在多样性上往往做得更好因为它的打分是基于统计分布的不会像LLM那样有语义偏好。5.3 冷启动用户效果不达预期冷启动是LLM的卖点但实际效果可能不如预期。原因往往是输入信息太少。用户只填了性别和年龄LLM也推不出什么精准的结果。我的建议是在冷启动阶段设计一些轻量级的交互比如让用户选择感兴趣的品类或者展示几个物品让用户点击。这些交互数据比注册信息有价值得多。LLM可以根据这几个点击快速推断出用户的偏好方向。5.4 成本超预算怎么优化成本问题通常出现在两个环节Prompt太长导致token消耗大以及调用频率太高。优化Prompt去掉冗余信息用更简洁的表达。调用频率上做分层处理高价值用户实时调用普通用户离线批量处理。还有一个思路是用更小的模型做初步筛选只把最难的部分交给大模型。比如先用小模型召回100个候选再用大模型对Top20做精排。这样大模型的调用量能降一个数量级。5.5 线上效果波动大怎么排查LLM推荐的效果波动可能来自几个方面。一是LLM服务本身的稳定性不同时间的输出可能有差异。二是用户群体的变化新用户涌入会拉低整体指标。三是外部事件的影响比如节假日、促销活动。排查时先看LLM服务的调用成功率、延迟、输出分布是否稳定。再看分群指标新老用户分开看不同渠道分开看。最后看时间维度是不是某个时间段突然变差。定位到具体原因后再针对性解决。实操心得建议在LLM推荐系统上线初期保留传统模型作为影子模式同时运行。这样一旦LLM出问题可以快速对比和切换。6. 我对这个方向的一些个人判断LLM做推荐目前还处于早期探索阶段。技术范式没有收敛证据边界不够清晰落地路径也在摸索中。但方向是对的。传统推荐系统的瓶颈已经很明显语义理解和常识推理是绕不过去的坎。我个人的判断是未来两三年内LLM不会完全替代传统推荐模型但会成为推荐系统架构中不可或缺的一层。它可能不直接做排序但在意图理解、特征增强、解释生成、冷启动这些环节会发挥越来越大的作用。对于正在这个方向上的团队我的建议是小步快跑先从一个具体的痛点切入比如冷启动或者长尾推荐验证效果后再逐步扩展。不要一上来就搞大而全的LLM推荐系统那样大概率会烂尾。最后分享一个我在实际项目中总结的小技巧把LLM的输出当作建议而不是决策。让LLM生成多个候选方案再用传统模型或规则做最终决策。这样既能利用LLM的推理能力又能保留传统系统的可控性和稳定性。这个思路在多个项目中验证过效果比让LLM直接做决策要稳得多。