LLM做推荐系统：技术范式、证据边界与渐进式落地路径-平芜编程栈

1. 为什么大模型做推荐值得认真对待

推荐系统这个行当，过去十年基本是特征工程和深度模型的天下。从最早的协同过滤，到后来的Wide&Deep、DeepFM，再到双塔召回加精排的经典架构，大家拼的是特征质量、样本设计和模型结构的微创新。但最近一两年，情况明显变了——大语言模型（LLM）的介入，让推荐系统的技术范式开始出现真正的松动。

我最初对“LLM做推荐”这件事是持怀疑态度的。原因很直接：推荐系统的核心诉求是低延迟、高吞吐、强实时性，而LLM动辄几十亿参数，推理成本高得离谱，线上QPS稍微大一点就扛不住。但后来深入看了不少实践案例，也自己动手跑了一些实验，发现事情没那么简单。LLM在推荐场景里的价值，未必是直接替代现有的召回或排序模型，而是在语义理解、冷启动、跨域迁移、交互式推荐这些传统方法比较吃力的地方，展现出了明显的优势。

这篇文章想聊的，就是LLM在推荐系统里到底能做什么、不能做什么，技术范式有哪几种，证据边界在哪里，以及如果要落地，路径应该怎么设计。适合推荐算法工程师、搜索推荐方向的产品经理，以及对LLM应用感兴趣的技术同学参考。不管你是刚接触这个方向，还是已经在做相关尝试，希望这些内容能帮你少踩几个坑。

2. 技术范式的三条主线

2.1 范式一：LLM作为特征增强器

这是目前工业界最容易落地、风险最低的一种方式。核心思路很简单：不改变现有推荐模型的主体结构，而是用LLM来生成更好的特征或语义表示，喂给下游的推荐模型。

具体怎么做？举几个我实际试过的方向。第一种是用LLM对物品的标题、描述、评论做摘要和标签抽取。传统做法是靠人工规则或者小模型做NER，覆盖率和准确率都有限。换成LLM之后，你可以让它输出结构化的物品属性，比如“适合场景”“风格标签”“功能卖点”，这些字段直接作为离散特征进入精排模型。第二种是用LLM的embedding替代或补充原有的item embedding。LLM对文本的语义编码能力比传统双塔里的文本塔强不少，尤其是在长文本和稀疏行为场景下，优势更明显。

这种范式的最大好处是解耦。LLM的推理可以离线做，把结果存成特征表，线上推荐系统照常跑，延迟完全不受影响。缺点是LLM的能力被“冻结”在特征里了，没法根据实时交互动态调整。另外，LLM生成的特征质量参差不齐，需要设计一套过滤和校验机制，否则噪声特征反而会拖累模型效果。

注意：用LLM生成特征时，一定要做离线评估。我见过不少团队直接拿LLM输出的标签进模型，结果AUC不升反降，原因是LLM的“常识”和推荐场景的“统计规律”并不总是一致。

2.2 范式二：LLM作为推荐模型本身

这条路更激进，直接把LLM当推荐模型来用。做法通常是把用户历史行为、物品信息、上下文拼成一个prompt，让LLM输出下一个可能感兴趣的物品ID或物品描述。学术界有不少工作沿着这个方向在做，比如把推荐任务转化成语言建模任务，用指令微调的方式让LLM学会“推荐”。

我实际跑过一些开源方案的复现，感受比较复杂。优点很明显：LLM天然具备跨域知识，对冷启动用户和长尾物品的推荐效果，在特定场景下确实比传统模型好。而且它能做交互式推荐——用户可以直接用自然语言说“我想找一款适合送长辈的保健品”，LLM能理解这种模糊需求，传统模型很难做到。

但问题同样突出。首先是物品空间太大，LLM的输出层没法直接覆盖百万级甚至千万级的物品候选集。常见做法是先用LLM生成语义描述，再用向量检索匹配物品，但这中间会损失精度。其次是推理延迟，即使用量化和小模型，单次推理也很难压到50ms以内，对于需要实时响应的推荐场景，压力很大。最后是评估困难，LLM生成的推荐结果不像传统模型那样有明确的概率分数，离线评估指标和线上效果之间的相关性需要重新验证。

2.3 范式三：LLM作为推荐系统的“大脑”

这是我个人最看好的长期方向，也是目前工程挑战最大的。核心思想是让LLM充当推荐系统的调度中枢，负责理解用户意图、拆解任务、调用不同的召回和排序工具，最后整合结果。

你可以把它理解成一个agent架构：LLM不直接做推荐，而是决定“现在该用哪个召回通道”“要不要触发探索”“这个用户是不是需要换一种推荐策略”。比如用户最近行为很稀疏，LLM可以判断应该走热门召回还是社交召回；用户行为很丰富，LLM可以决定走个性化向量召回。这种动态策略调整，传统推荐系统通常靠规则引擎或者多臂老虎机来做，LLM的语义理解能力可以让决策更精细。

这种范式的落地难度在于系统工程复杂度高。你需要把召回、排序、重排都封装成LLM可以调用的工具，还要设计好prompt模板和输出解析逻辑。另外，LLM的决策过程需要可解释、可监控，否则出了问题很难排查。我目前看到的一些实践，大多还停留在原型阶段，真正上线的案例不多。

3. 证据边界：LLM做推荐到底靠不靠谱

3.1 哪些场景下LLM确实有优势

根据我自己的实验和公开案例的观察，LLM在以下几类场景里表现明显优于传统方法：

冷启动场景。新用户没有历史行为，新物品没有交互数据，传统协同过滤基本失效。LLM可以基于用户注册时填写的少量信息，或者物品的文本描述，做出合理的推荐。我做过一个对比实验，在用户只有1-2条行为记录的情况下，LLM方案的点击率比传统双塔模型高出15%左右。

跨域推荐。用户在A场景的行为，能不能迁移到B场景？传统做法是靠共享embedding或者迁移学习，但效果不稳定。LLM的通用语义理解能力，让它天然具备跨域知识。比如用户在电商场景买过露营装备，在内容场景推荐户外视频，LLM能理解这层关联，传统模型很难。

交互式推荐。用户用自然语言表达需求，比如“帮我找一部适合周末放松的喜剧片”，LLM能直接理解并给出推荐。这种场景下，传统推荐系统需要用户先点击几个物品才能建立兴趣画像，LLM可以跳过这个冷启动过程。

长尾物品推荐。热门物品的推荐，传统模型已经做得很好。但长尾物品因为交互数据少，传统模型很难学好。LLM基于内容理解做推荐，对长尾物品更友好。我实测下来，在长尾物品的召回覆盖率上，LLM方案比传统i2i召回高出不少。

3.2 哪些场景下LLM并不划算

反过来，以下场景我建议谨慎使用LLM：

高并发实时推荐。如果你的推荐场景QPS很高，延迟要求严格，LLM的推理成本很难接受。即使做了量化、蒸馏、缓存，单次推理的延迟和算力消耗仍然远高于传统模型。这种场景下，LLM更适合做离线特征生成，而不是在线推理。

行为序列非常丰富的场景。如果用户有几千条历史行为，传统序列模型（如DIN、DIEN）已经能很好地建模兴趣。LLM处理长序列的注意力计算成本很高，而且效果未必更好。我试过把用户行为序列拼成prompt喂给LLM，效果提升有限，但推理成本翻了好几倍。

对可解释性要求极高的场景。推荐系统需要解释“为什么推荐这个物品”，传统模型可以通过特征权重给出解释。LLM的决策过程是黑盒，虽然可以生成自然语言解释，但解释的可靠性需要验证。在金融、医疗等强监管场景，这一点可能是硬伤。

数据隐私敏感的场景。LLM的prompt里如果包含用户敏感信息，存在泄露风险。虽然可以做脱敏，但工程复杂度会增加。传统模型在本地训练，数据不出域，安全性更容易保证。

3.3 评估指标的陷阱

LLM做推荐，评估是个大问题。传统推荐系统的离线评估靠AUC、GAUC、NDCG这些指标，但LLM的输出是自然语言或者物品描述，没法直接算这些指标。常见的做法是：

把LLM输出的物品描述映射到物品ID，再算准确率、召回率
用LLM生成推荐列表，人工评估相关性
用另一个LLM做评估器，判断推荐结果是否合理

这三种方法各有问题。第一种映射过程会损失信息，第二种成本高、不可规模化，第三种存在评估偏差。我个人的经验是，离线评估只能做粗筛，最终还是要靠线上A/B实验。而且线上实验要关注的不只是点击率，还要看多样性、新颖性、用户留存这些长期指标。

实操心得：做LLM推荐实验时，建议先在小流量上跑，观察用户行为变化。我见过不少案例，离线指标很好看，上线后点击率反而降了，原因是LLM推荐的物品太“正确”了，缺乏惊喜感，用户觉得无聊。

4. 落地路径：从离线到在线的渐进式方案

4.1 第一阶段：离线特征增强

如果你刚开始尝试LLM做推荐，我强烈建议从离线特征增强入手。这个阶段的目标不是替换现有模型，而是用LLM生成补充特征，验证LLM在你们场景下的价值。

具体步骤：

选一个特征生成任务。比如物品标签抽取、用户兴趣摘要、评论情感分析。选一个传统方法做得不够好的任务，作为切入点。
设计prompt模板。prompt要尽量结构化，明确输出格式。比如要求LLM输出JSON，包含“标签列表”“置信度”“理由”三个字段。
批量推理并存储。用离线任务跑全量物品或用户，把LLM输出存成特征表。注意要做去重和缓存，避免重复推理。
离线评估。把新特征加入现有模型，看离线指标是否有提升。如果没有提升，分析原因：是特征质量不行，还是特征和现有特征冗余？
小流量上线。离线验证通过后，在小流量上做A/B实验，观察线上指标。

这个阶段的投入产出比最高，风险也最低。即使LLM效果不好，也不会影响线上主流程。

4.2 第二阶段：LLM辅助召回

当离线特征增强验证有效后，可以尝试让LLM参与召回环节。常见做法有两种：

生成式召回。用LLM生成用户可能感兴趣的物品描述或关键词，再用向量检索匹配物品。这种方式的优势是能捕捉用户的模糊意图，缺点是生成结果可能不准确，需要设计过滤机制。

语义召回。用LLM的embedding做物品和用户的向量表示，替代或补充现有的双塔召回。LLM的语义编码能力更强，尤其是在文本信息丰富的场景下。我实测下来，在物品标题和描述质量较高的场景，LLM embedding的召回效果比传统文本塔好10%-20%。

这个阶段的关键是控制延迟。LLM的推理不能放在在线主路径上，通常的做法是离线生成embedding，线上只做向量检索。如果一定要在线推理，建议用蒸馏后的小模型，或者做结果缓存。

4.3 第三阶段：LLM驱动重排与交互

这是最激进的阶段，也是目前工业界案例最少的。核心思路是让LLM参与重排，或者直接做交互式推荐。

重排场景下，LLM的输入是粗排后的候选集（通常几十到几百个物品），输出是重排后的顺序。LLM可以综合考虑多样性、新颖性、用户当前上下文等因素，做出比传统重排模型更灵活的决策。但延迟是最大挑战，我见过的一些方案是用小模型做重排，LLM只做离线策略生成。

交互式推荐场景下，LLM直接和用户对话，理解需求并推荐物品。这种模式适合低频、高决策成本的场景，比如买房、买车、旅游规划。高频场景下，用户没有耐心和LLM对话，传统推荐效率更高。

4.4 落地路径的优先级建议

阶段	技术方案	落地难度	预期收益	建议优先级
一	离线特征增强	低	中	高
二	LLM辅助召回	中	中高	中高
三	LLM重排与交互	高	高	中

我的建议是：先把第一阶段做扎实，再考虑第二阶段。很多团队一上来就想用LLM做在线推荐，结果工程复杂度失控，效果还不如传统模型。渐进式落地，每一步都验证清楚，才是稳妥的做法。

5. 常见问题与排查技巧实录

5.1 LLM生成的推荐结果不稳定怎么办

这是最常见的问题。同一个用户，同样的历史行为，LLM两次输出的推荐结果可能不一样。原因是LLM的生成过程有随机性，temperature参数、采样策略都会影响输出。

解决方法有几个：一是把temperature设成0，做确定性生成；二是设计更严格的prompt，限制输出空间；三是在LLM后面加一层规则过滤，把明显不合理的推荐去掉。我通常会用第一种加第三种组合，既保证稳定性，又保留一定的灵活性。

5.2 推理成本太高怎么优化

LLM推理成本是落地的最大障碍。我试过几种优化手段：

量化：把模型从FP16量化到INT8，推理速度提升明显，效果损失可控。
蒸馏：用大模型生成训练数据，蒸馏到小模型。小模型推理成本低，效果能保留大部分。
缓存：对高频请求做结果缓存，比如热门用户的推荐结果可以缓存几分钟。
批处理：离线任务用批处理，提高GPU利用率。
模型选择：不是所有场景都需要最大的模型，7B参数的小模型在很多推荐任务上已经够用。

5.3 如何评估LLM推荐的效果

前面提到过，离线评估只能做粗筛。我补充几个实操细节：

人工评估：抽样一批推荐结果，让标注人员判断相关性。样本量不用太大，几百条就能看出趋势。
LLM评估：用另一个LLM做评估器，但要注意评估偏差。建议用不同的prompt模板做交叉验证。
线上A/B：这是最终标准。实验设计要注意控制变量，比如只改变召回通道，其他环节保持不变。
长期指标：除了点击率，还要看用户留存、使用时长、多样性指标。LLM推荐容易陷入“信息茧房”，要特别关注。

5.4 常见问题速查表

问题	可能原因	排查方法	解决方案
推荐结果重复	LLM输出多样性不足	检查prompt是否限制了输出空间	增加多样性约束，或后处理去重
延迟过高	在线推理未优化	分析推理耗时分布	量化、蒸馏、缓存、批处理
效果不如传统模型	特征质量差或场景不匹配	对比特征覆盖率和分布	调整prompt，或换场景验证
输出格式错误	prompt不够结构化	检查输出解析日志	用JSON schema约束输出
冷启动效果差	LLM缺乏场景知识	检查prompt是否包含场景描述	补充场景上下文和示例