★ FEATURED ARTICLE 推荐系统这几年最明显的一个变化是“排序模型越调越细收益却越来越薄”。特征工程做到极致、双塔结构换了又换、多任务学习堆了一层又一层线上AUC涨个千分之几都要开复盘会。就在这个背景下大语言模型LLM被推到了推荐场景里。很多人第一反应是“把LLM当召回或排序模型用”但真正落地过一轮的人会发现事情远没有这么简单——LLM在推荐里的价值往往不在它直接预测点击率的能力而在于它对语义、意图和世界知识的理解能补上传统推荐系统长期缺失的那一块。这篇文章想聊的是LLM用于推荐的技术范式、证据边界和落地路径。所谓范式是指LLM到底以什么角色介入推荐链路所谓证据边界是指哪些效果是被实验验证过的、哪些只是看起来很美所谓落地路径是指从离线实验到线上灰度中间那些文档里不会写的坑。适合已经有一定推荐系统基础、正在评估要不要引入LLM的算法工程师也适合想理解这个方向真实进展的产品和技术负责人。我会尽量把“为什么这么设计”讲清楚而不是只给一堆结论。1. LLM介入推荐系统的四种角色定位把LLM塞进推荐系统最容易犯的错是把它当成一个“更强的CTR模型”。这个定位从根上就偏了。传统CTR模型的优势是海量ID特征交叉和极低的推理延迟LLM在这两点上都不占优。LLM真正的长板是语义理解和开放域知识所以它的介入位置应该围绕这两点来设计。下面四种角色是我在实际项目和公开资料里反复见到的分类方式按介入深度从浅到深排列。1.1 作为特征增强器把文本变成可用的语义向量这是门槛最低、风险最小的一种用法。推荐系统里本来就有大量文本信息——商品标题、用户评论、内容正文、搜索query。传统做法是用TF-IDF或者小型BERT类模型抽特征但这类模型对长文本、隐晦表达、跨领域语义的捕捉能力有限。LLM可以对这些文本做更深层的语义编码产出稠密向量再喂给下游的排序模型。具体操作上常见做法是取LLM某一层的隐状态做平均池化或者直接用它的embedding接口。这里有个细节不要盲目用最后一层的输出。最后一层往往偏向生成任务的分布语义信息反而不如前几层干净。我试过在同一个商品标题数据集上对比取倒数第二层做池化的向量在相似商品召回任务上的hit rate比最后一层高出几个百分点。这个结论不是绝对的但值得你在自己的数据上验证一遍。另一个坑是维度。LLM的隐层维度动辄几千直接拼进排序模型会让参数量爆炸还会拖慢推理。通常需要先做降维PCA或者一个小的投影矩阵都行。投影矩阵的好处是可以和下游任务联合训练让语义向量朝着推荐目标对齐而不是保留通用的语义信息。这两种选择没有绝对优劣取决于你的下游任务和训练资源。1.2 作为召回通道用语义相似度补充行为召回的盲区传统召回严重依赖用户历史行为。新用户没有行为冷门商品没有曝光这两类问题行为召回天然解决不了。LLM的语义向量可以构建一个独立的召回通道把商品库全部编码成向量用户侧用历史行为或query编码成向量做近似最近邻搜索。这个通道的价值在于“语义泛化”。比如用户买过“露营帐篷”行为召回可能只会推同类帐篷但语义召回能推出“防潮垫”“露营灯”这类关联商品因为它们在同一语义空间里距离近。这种泛化能力是ID类召回做不到的。但要注意语义相似不等于用户喜欢。我见过一个案例语义召回把“高端钢笔”和“练字帖”推给了同一个用户语义上确实相关但用户只买钢笔对练字帖毫无兴趣。所以语义召回通道通常要和行为召回做融合而不是单独扛大梁。融合方式可以是简单的加权也可以用门控网络让模型自己学权重。1.3 作为重排器在候选集上做精细化语义决策精排之后通常还有一个重排阶段负责多样性、新鲜度、业务规则这些目标。LLM可以在这里发挥作用把候选商品的标题、描述、属性拼接成一段文本让LLM判断这个商品和用户当前意图的匹配程度或者直接生成一个重排分数。这个用法的好处是能引入精排模型看不到的上下文信息。精排模型输入的是结构化特征而LLM可以读到完整的商品描述和用户近期行为序列的自然语言表达。比如用户刚搜索了“适合送长辈的礼物”精排模型可能只看到query的embedding而LLM能理解“长辈”“礼物”背后的语义约束从而把保健品、按摩仪这类商品排前面把潮玩手办排后面。代价是延迟。重排阶段候选集通常几十到几百个如果每个都调一次LLM延迟会非常难看。实际做法通常是只对Top N做LLM重排或者用蒸馏后的小模型来近似LLM的判断。蒸馏是个好思路先用LLM在离线数据上打标训练一个小的交叉编码器线上用这个小模型能保留大部分效果延迟可控。1.4 作为交互式推荐引擎对话式理解与实时反馈这是最激进也最有想象空间的用法。用户不再是通过点击行为隐式表达偏好而是直接和系统对话“我想找一款适合油皮的防晒不要太油腻预算两百以内。”LLM解析这段话提取出肤质、品类、预算、肤感偏好等约束然后驱动推荐。这种模式下LLM同时承担了意图理解、约束提取和结果解释的角色。它可以把推荐结果用自然语言组织出来“根据你的油皮和预算这几款防晒的质地比较清爽……”这种交互体验是传统推荐给不了的。但落地难度也最大。对话式推荐需要处理多轮上下文、意图漂移、约束冲突等问题而且用户愿不愿意用对话的方式找商品本身是个问号。目前我看到的成功案例多集中在决策成本高、商品参数复杂的品类比如数码、家电、保险。快消品场景下用户更倾向于直接浏览而不是对话。2. 证据边界哪些效果被验证了哪些还在讲故事LLM用于推荐这个方向论文和工业界分享都很多但信息质量参差不齐。有些结论有扎实的A/B实验支撑有些只是离线指标好看线上未必成立。这一节我想把证据的边界划清楚帮你在评估技术方案时少走弯路。2.1 离线指标与线上收益之间的鸿沟几乎所有LLM推荐论文都会报告离线指标提升比如RecallK、NDCG的提升。但离线指标和线上收益之间隔着好几道坎。第一道坎是数据分布。离线实验用的历史数据是旧推荐系统产生的。旧系统没推过的商品在离线数据里就是没有曝光LLM召回即使召回了这些商品离线评估也无法体现其价值。这就是所谓的“闭环反馈”问题。要评估语义召回的真实价值需要做在线探索或者用反事实评估方法但后者对数据要求很高。第二道坎是用户行为噪声。离线数据里的点击、购买混杂了大量偶然因素。LLM基于语义判断“相关”的商品用户可能因为价格、评价、图片等因素不点击。离线指标涨了线上可能纹丝不动。我的经验是离线指标只用来做方案筛选不要用来做效果承诺。真正判断LLM推荐有没有用必须走线上A/B。而且A/B的周期要足够长因为LLM带来的可能是长期兴趣匹配的改善短期点击率未必有明显变化。2.2 语义相关性不等于用户偏好这是最容易被忽视的一点。LLM擅长判断“A和B语义上是否相关”但推荐系统要的是“用户会不会喜欢B”。这两者有交集但不重合。举个例子。用户最近买了一套《三体》LLM语义召回可能会推《球状闪电》《流浪地球》因为都是同一作者、同一题材。这看起来合理。但如果用户买《三体》是为了送人他自己根本不看科幻那这些推荐就是无效的。LLM不知道购买动机它只看到了语义关联。再比如用户搜索“婴儿奶粉”LLM可能召回“婴儿辅食”“奶瓶”“婴儿车”语义上都相关。但用户此刻的需求非常明确就是要奶粉推辅食和奶瓶反而干扰。语义相关性在这里过度泛化了。所以LLM推荐系统需要一个“意图收窄”的机制。常见做法是用query理解模块先判断用户意图的宽窄宽意图如“夏季穿搭”可以放宽语义召回窄意图如“婴儿奶粉”则要收紧优先精确匹配。这个判断本身也可以用LLM来做但要有明确的策略约束不能完全交给模型自由发挥。2.3 冷启动场景的效果相对确定在所有场景里LLM推荐在冷启动上的效果是最被公认的。新商品没有行为数据传统协同过滤无能为力但LLM可以通过商品标题和描述理解它是什么从而找到可能感兴趣的用户。新用户没有历史行为LLM可以通过注册信息、首次query、甚至设备信息做冷启动推荐。这个方向有比较扎实的实验证据。多个公开数据集上的实验都显示在行为数据稀疏的情况下引入语义信息的推荐模型显著优于纯ID模型。工业界也有不少分享提到LLM语义召回在新品冷启阶段带来了可观的曝光和转化提升。但要注意冷启动的效果会随着行为数据积累而衰减。当商品有了足够曝光、用户有了足够行为后行为信号的预测力会超过语义信号。所以LLM召回通道的权重应该是动态的冷启动阶段权重高随着行为数据丰富逐步降低。这个动态调整策略本身比LLM模型选型更影响最终效果。2.4 生成式推荐的幻觉与可控性问题有一类做法是让LLM直接生成推荐结果比如“给用户推荐10个商品”。这种生成式推荐看起来很优雅但实际落地问题很多。最突出的是幻觉。LLM可能生成不存在的商品ID或者生成已经下架的商品。在开放域对话里幻觉可能只是让回答不准确在推荐系统里幻觉直接导致推荐位开天窗是事故。所以生成式推荐必须有一个约束层把LLM的输出限制在真实商品库里。常见做法是用受限解码或者在生成后做实体链接和校验。另一个问题是可控性。推荐系统有很多业务约束不能推某类商品、某个品牌要加权、某个类目要控制占比。这些约束在传统排序模型里可以通过规则层实现但LLM生成的结果很难精确控制。你可以在prompt里写约束但LLM不保证遵守。所以生成式推荐目前更适合作为候选生成的一环而不是最终决策。3. 从离线到线上一条可复现的落地路径聊完范式和证据接下来是实操。这一节我会给出一条从零开始把LLM引入推荐系统的路径按阶段拆解每个阶段说明目标、做法和验收标准。这条路径不是唯一的但每一步的先后顺序有它的道理跳步容易出问题。3.1 第一阶段用LLM做离线语义特征验证增量价值不要一上来就改线上链路。第一步应该是在离线环境里用LLM生成语义特征喂给现有的排序模型看离线指标有没有提升。这一步的目的是验证“语义信息对你的场景有没有用”成本低风险小。具体做法选一个现有的排序模型作为baseline固定其他特征不变只加入LLM生成的语义向量特征重新训练对比离线AUC或GAUC。如果指标有稳定提升说明语义信息有增量价值可以进入下一阶段。如果没有提升要么是语义特征和现有特征冗余要么是你的场景里语义信息本来就不重要那就没必要继续投入。这一步有几个细节要注意。语义向量的维度要控制通常64到256维比较合适太高会过拟合太低信息损失大。特征的接入方式可以是拼接也可以是单独过一个小的MLP再和主模型融合后者效果通常更好因为可以让语义特征有独立的变换空间。验收标准离线AUC相对提升超过0.3%且在多天数据上稳定。低于这个值线上大概率测不出来。3.2 第二阶段构建独立的语义召回通道离线特征验证通过后下一步是建语义召回通道。这一步的目标是让语义召回在线上真实跑起来和现有召回通道并行观察它的独立贡献。工程上需要做几件事商品库全量编码、向量索引构建、在线查询服务。商品编码可以离线批量做每天更新一次用户侧向量可以实时算也可以用历史行为向量的平均。向量索引用FAISS或者类似的库注意索引类型的选择——IVF适合大规模HNSW适合低延迟具体选哪个看你的数据量和延迟要求。上线时不要直接替换现有召回而是新增一路和现有召回做融合。融合权重先给一个保守值比如语义召回占10%到20%。然后观察几个指标语义召回通道的独立点击率、它对最终结果的边际贡献、以及它带来的商品多样性变化。这里有个容易忽略的点语义召回的商品分布和现有召回差异很大。如果语义召回推的都是长尾商品短期点击率可能不好看但长期可能提升用户兴趣广度。所以评估指标不能只看CTR还要看人均曝光品类数、新品类点击占比这些多样性指标。验收标准语义召回通道独立CTR不低于现有召回通道的60%且融合后整体CTR不降多样性指标有提升。3.3 第三阶段LLM重排的工程化与延迟优化语义召回跑稳之后可以考虑上LLM重排。这一步的核心矛盾是效果和延迟。LLM重排效果好但推理慢必须做工程优化。优化方向有几个。一是候选集裁剪只对精排Top 50到100做LLM重排不要对全量候选做。二是模型蒸馏用大LLM在离线数据上打标训练一个小交叉编码器线上用小模型。三是请求合并把多个候选拼成一个batch一次请求处理多个提高吞吐。四是缓存对相同或相似的query-商品组合缓存LLM打分减少重复计算。我实际做过的方案是蒸馏加缓存。先用一个较大的LLM对历史曝光数据做重排打分得到几十万条训练样本然后训练一个6层的小交叉编码器。线上部署这个小模型单次推理延迟控制在20毫秒以内效果能达到大LLM的85%左右。缓存层用query的语义哈希做key命中率大概30%进一步降低了平均延迟。验收标准LLM重排模块的P99延迟低于100毫秒重排后Top 10的NDCG相对提升超过2%。3.4 第四阶段A/B实验设计与长期效果评估所有离线验证通过后最终还是要上A/B。LLM推荐的A/B实验有几个特殊之处需要提前设计好。第一实验周期要长。LLM带来的可能是兴趣匹配的改善这种改善需要时间积累才能体现在点击率上。建议至少跑两周覆盖一个完整的用户活跃周期。第二指标要分层。除了整体CTR、转化率还要看新用户、老用户、活跃用户、沉默用户的分层指标。LLM推荐对新用户和沉默用户的提升通常更明显如果只看整体指标可能被老用户的行为惯性稀释。第三要关注负面指标。LLM推荐可能带来多样性提升但也可能让推荐结果变得“太发散”用户找不到想要的。所以要监控搜索退出率、推荐位跳过率这些负面信号。第四要留对照组。A/B实验的对照组应该是现有线上策略而不是“去掉LLM但保留其他改动”的版本。这样才能干净地衡量LLM的增量价值。4. 工程实现中的关键细节与踩坑记录前面讲的是路径和框架这一节讲具体实现里的坑。这些坑在论文里不会写但实际做的时候一个都躲不掉。4.1 向量索引的更新频率与一致性问题语义召回依赖向量索引。商品库每天都有新增、下架、信息修改索引必须跟着更新。但全量重建索引成本高增量更新又容易出不一致。我的做法是双索引切换维护两个索引一个在线服务一个离线构建。离线索引构建完成后做一次全量校验确认商品ID和向量能对上然后原子切换。切换过程中新商品可能短暂查不到但不会查到错误结果。这个短暂的空窗期通常可以接受因为新商品本来就没有行为数据晚几个小时上线影响不大。另一个问题是用户侧向量的实时性。用户刚点击了一个商品这个行为应该立刻反映到他的语义向量里。但实时更新用户向量需要在线推理成本高。折中方案是用一个滑动窗口把用户最近N次行为的向量做加权平均权重按时间衰减。这个计算可以放在召回服务里做不需要额外的模型推理。4.2 Prompt设计中的陷阱别让LLM“猜”你的意图如果用LLM做重排或意图理解prompt设计直接决定效果。我踩过的坑包括指令太模糊导致LLM自由发挥、输出格式不稳定导致解析失败、few-shot示例选得不好导致模型偏向示例。一个实用的原则是prompt要像给一个新员工写操作手册而不是像给老朋友发微信。每个约束都要明确写出来每个输出字段都要规定格式。比如做重排时不要写“请判断这个商品是否适合用户”而要写“请根据用户历史行为和当前query判断候选商品与用户意图的匹配程度输出0到1之间的分数保留两位小数只输出分数不要输出其他内容”。few-shot示例的选择也有讲究。示例要覆盖不同的意图类型不能都是同一类。如果示例都是“搜索-购买”场景模型在“浏览-加购”场景下可能表现不好。另外示例的顺序会影响输出通常把最典型的示例放在最后因为LLM对末尾内容更敏感。4.3 成本控制不是所有请求都值得调LLMLLM推理成本是传统模型的几十倍甚至上百倍。如果全量请求都走LLM成本会失控。必须做分层处理。我的策略是按用户价值和请求场景分层。高价值用户高活跃、高消费的请求走LLM重排普通用户走蒸馏小模型。搜索场景走LLM意图理解推荐feed场景走语义召回加传统排序。这样能把LLM的调用量控制在总请求的10%以内成本可控同时把LLM用在最能发挥价值的地方。还有一个技巧是用LLM做离线打标线上用轻量模型。比如用LLM给商品打上细粒度的风格标签、场景标签这些标签作为特征进入线上排序模型。LLM只在离线跑一次线上零成本。这种“LLM离线小模型线上”的模式是目前性价比最高的落地方式之一。4.4 效果归因怎么知道提升是LLM带来的A/B实验跑出正向结果后还要做归因。提升到底来自LLM的语义理解还是来自它带来的多样性还是仅仅因为引入了新的召回通道归因不清楚后续优化就没有方向。归因的常用方法是消融实验。在A/B实验里再分几个组一组只用LLM语义召回一组只用LLM重排一组两者都用。对比这几组的效果就能拆解出每个模块的贡献。另外可以分析LLM推荐带来的增量曝光商品的属性分布看它们和现有推荐的商品有什么差异从而理解LLM到底补了什么。我做过一次归因分析发现LLM带来的提升里大约60%来自语义召回补充的长尾商品30%来自重排对Top结果的调整10%来自意图理解对query的改写。这个拆解对后续优化很有指导意义——既然大头在召回那就继续优化召回通道的覆盖和精度而不是在重排上过度投入。5. 不同业务场景下的选型建议LLM推荐不是万能药不同业务场景下适合的介入方式和优先级完全不同。这一节按场景给一些选型建议都是基于实际项目经验的判断。5.1 电商搜索意图理解优先重排次之电商搜索场景下用户意图相对明确LLM最大的价值在query理解。传统query理解依赖词典和规则对长尾query、口语化query、多意图query处理不好。LLM可以把“适合送女朋友的生日礼物 学生党”这样的query解析成品类、价格带、场景、人群等多个维度的约束大幅提升召回精度。具体做法是用LLM做query改写和意图槽位提取把结果传给下游召回。这一步的ROI很高因为搜索流量的商业价值高意图理解提升一点转化就有明显变化。重排可以作为第二步但优先级低于意图理解。5.2 内容信息流语义召回和多样性重排是重点内容信息流场景下用户没有明确的query兴趣靠行为隐式表达。LLM的价值主要在语义召回和多样性重排。语义召回可以解决新内容冷启和长尾内容分发的问题多样性重排可以避免信息茧房。这个场景下LLM的实时性要求相对低因为信息流对延迟的容忍度比搜索高。所以可以用稍大的模型做更精细的语义编码。另外内容信息流的内容更新快向量索引的更新频率要跟上否则新内容进不来。5.3 本地生活服务约束提取和实时上下文是关键本地生活服务推荐比如到店餐饮、外卖有很强的时空约束。用户在不同时间、不同地点需求完全不同。LLM可以结合时间、地点、天气等上下文做更精准的意图理解。比如用户下午三点在写字楼附近打开AppLLM可以推断出可能是下午茶场景推荐咖啡、甜品晚上八点在住宅区打开可能是晚餐或夜宵场景。这种上下文理解是传统推荐模型不擅长的因为传统模型把这些上下文当作离散特征很难捕捉它们之间的语义关联。这个场景下LLM的调用可以放在召回前的意图理解阶段产出场景标签驱动后续召回和排序。实时性要求高所以要用蒸馏后的小模型或者用规则加LLM的混合方案。5.4 跨场景通用建议先做窄再做宽不管什么场景我的建议都是先找一个窄场景做深做透再考虑扩展。窄场景的数据分布集中评估容易迭代快。比如先只做新用户冷启动或者只做某个品类的语义召回跑通了再复制到其他场景。我见过一些团队一上来就想做通用的LLM推荐中台结果每个场景都做不深效果平平。LLM推荐的效果很依赖场景数据的微调和对齐通用方案很难在所有场景都表现好。窄场景切入积累经验和方法论再横向扩展是更稳妥的路径。6. 一些个人体会做LLM推荐这一年多最大的感受是LLM不是来替代传统推荐系统的它是来补短板的。传统推荐系统在行为数据丰富、用户意图明确的场景下依然高效LLM的优势在冷启动、长尾、语义理解这些传统方法的盲区。把LLM放在对的位置它能发挥很大价值放错位置就是又贵又慢的鸡肋。另一个体会是工程细节决定成败。LLM推荐的效果模型选型可能只占三成剩下七成在工程实现向量索引怎么更新、prompt怎么设计、成本怎么控制、A/B怎么设计。这些细节没有标准答案需要在具体场景里反复试。我踩过的坑很多都不是模型本身的问题而是工程链路上某个环节没处理好。最后对想入这个方向的同行说一句不要被论文里的漂亮指标迷惑也不要被“LLM万能”的叙事带偏。从一个小场景开始用离线实验验证增量用A/B实验验证线上收益一步一步来。LLM推荐的路还很长但方向是清晰的——让推荐系统更懂用户而不只是更懂数据。
阅读完成 · 觉得有帮助？
