1. 推荐系统的拐点已经来了这两年只要聊到推荐系统大家的第一反应还是“召回、排序、重排”那套经典三段式再配上一堆特征工程和深度模型。结果前两天看到一条消息说某头部流媒体平台正在用 LLM 替换掉传统推荐引擎。说实话第一次看到这个说法我以为是标题党但仔细翻了翻行业里的技术动向和招聘需求发现这已经不是实验室里的玩具而是实打实正在发生的架构迁移。这里先把这个“替换”说清楚避免误解。它不是把整个推荐系统推倒重来而是把传统推荐链路里最重、最死板的那部分——比如基于物品的协同过滤、多目标排序塔、以及需要反复训练的离线模型——逐步替换成以 LLM 为核心的语义推荐链路。简单说以前的推荐是“你看了 A所以推 B”现在变成了“你看了 A模型理解 A 的深层含义再理解你这个人最后直接生成你可能会喜欢的内容清单”。这个转变的本质是从“统计关联”走向“语义理解”。如果你正在做推荐系统或者刚入门想选方向这篇文章会非常值得看。我会把 LLM 替换传统推荐引擎这件事拆开揉碎讲清楚它到底改了哪几个环节、核心的技术点是什么、实操中怎么落地、以及团队踩过的坑。这里不堆论文只讲能用的东西。2. 传统推荐引擎哪里不行了我们得先接受一个现实传统推荐系统不是不行是它的“上限”已经被卡死了。这个上限来自三个层面。2.1 特征工程的边际收益已经接近零传统推荐系统的地基是特征。用户画像、行为序列、物品属性、上下文信号这些特征被拼成一条条训练样本喂给模型学习。问题在于特征表达能力的上限取决于人工对业务的理解。你花三个月做出来的“用户对某品类近 7 天点击率衰减系数”这种特征可能只带来千分之一的 AUC 提升。我见过不少团队模型结构换了三版最后发现涨点全靠特征组合而特征组合越做越复杂维护成本越来越高但收益肉眼可见地递减。更麻烦的是长尾物品的特征长什么样一个刚上架的小众纪录片没有点击、没有收藏、没有播放时长传统模型只能把它丢进冷启动池靠粗糙的规则勉强分发给少数用户。这种“猜”的效率和准确率都低得可怜。2.2 用户意图是割裂的不是一串行为序列传统推荐把用户表达成一条行为序列看了哪几个视频、点了哪几个赞、在哪些页面停留了多久。但人的真实意图是叠加的——你可能白天搜“减脂餐”是为了做午饭晚上搜“科幻电影”是为了放松。这两种意图混在同一条序列里传统模型很难自动区分更别提识别你今天的需求和上周的需求哪个占主导。LLM 就不一样它天然会把用户所有历史信息当成一段“文本”来读。用户过去的行为被现金流式地组织成上下文模型能理解“减脂餐”和“科幻电影”属于两种不同的意图而且在当前会话里它能感知到你此刻更需要哪种内容。这种“动态意图理解”是传统特征工程做不到的。2.3 推荐的解释能力几乎为零传统模型输出的只有一堆 item_id 和分值产品经理问“你为什么推这个给我”的时候我们只能回答“因为模型算出来你感兴趣”这跟没说一样。但 LLM 推荐链路天然能生成推荐理由比如“因为你最近在看太空探索类纪录片而这部片子讲述了火星探测任务的幕后细节和你的兴趣标签‘航天’匹配度高达 92%”。这种解释不只是给用户看的更是给运营、审核、产品团队看的它让推荐系统的行为变得可干预、可调试。3. LLM 推荐引擎的核心技术架构要理解 LLM 怎么替换传统推荐引擎得先知道它替换的是哪几根柱子。传统链路是“召回→粗排→精排→重排”LLM 不是把这四段全干掉而是把其中和“理解”强相关的段全部接住。3.1 召回阶段从“双塔”到“语义向量检索”传统召回的主力是双塔模型user 塔和 item 塔分别产出 embedding然后在向量库里做 ANN 检索。这玩意儿有个硬伤两个塔各自独立训练它们学到的空间不一定对齐而且对语义的理解很浅。谁和谁像全靠标签隐式告诉它。LLM 召回的做法是把物品的所有描述文本——标题、简介、标签、甚至字幕片段——丢给 LLM生成一个 Rich Embedding然后对用户的历史行为序列也用 LLM 生成 Session Embedding最后在同一个语义空间里做检索。这一步的效果提升非常明显尤其对长尾内容因为 LLM 的 embedding 空间里“太空纪录片”和“火星探索”天然是近邻而不是靠用户行为硬学出来的共现关系。我实际测过一组数据把物品描述从简单标签换成 LLM 生成的语义向量后在长尾内容上的召回率能提升 20% 到 40%具体取决于内容库的多样性。这不是玄学是文本分布决定的。3.2 排序阶段从“多目标塔”到“生成式打分”传统精排通常是多个 tower 分别预测点击率、时长、完播率再用加权公式融合。麻烦在于每个目标的权重要反复调而且模型对“用户为什么点”没有概念。LLM 排序有两种主流做法。第一种是 Score-based把候选物品的元信息、用户画像、当前上下文拼成一个 Prompt让 LLM 直接输出打分比如用 1 到 10 分评估匹配度。这个做法实现简单但效率低不适合被线上调用太多次而且打分稳定性需要大量 Prompt 工程来调。第二种是 Generation-based直接让 LLM 输出一个排序后的列表比如给一排候选 item 的编号LLM 按“最符合用户当前意图”的顺序输出。这种方式看着神奇实际上是在利用 LLM 对用户意图和候选内容的联合理解它不是去拟合人工标注的 CTR而是拟合“人会觉得什么更相关”这个更接近本质的目标。我们自己的实验中Generation-based 在“用户主动搜索后无关键词匹配”的场景下效果尤其好。比如用户搜“有空看电影的感觉”传统模型只能匹配到标题或标签中带“电影”二字的视频但 LLM 能理解这句模糊描述背后的情绪和场景直接推荐出几部慢节奏的文艺片这已经不是传统排序能完成的事。3.3 重排阶段从“硬规则”到“可对话式干预”传统重排就是上一堆规则去掉用户不喜欢的频道、控制多样性、打散重复内容。规则一多就打架而且规则是全局静态的没法针对某个用户动态调整。LLM 重排可以让用户直接参与调整比如“最近不想看太压抑的片子”“多推点 20 分钟以内的”“我不想再看任何丧尸题材了”。这些自然语言指令传统系统得靠一堆新标签和规则去拼还拼不对但 LLM 直接就能理解并应用。它相当于把推荐系统的后门打开让用户自己能“调参”。4. 实操落地从 0 到 1 搭建一个 LLM 推荐 Demo说再多架构不如直接跑通一个最小化系统。我自己搭过一个简化版技术栈就是常用的那些普通配置就能跑核心在于流程设计。4.1 最小可用链路设计整体链路分五步物品语义化把每个视频的标题、简介、标签、字幕片段拼接成一段描述文本统一走 Embedding 模型得到向量。用户上下文构造把用户最近 20 条行为对应的物品描述文本按时间顺序拼接起来作为“用户语义画像”。候选生成用用户画像 Embedding 去向量库做 ANN 检索取 Top 100。精排把 Top 100 的物品描述、用户画像、额外上下文拼成 Prompt让 LLM 输出一个有序列表。解释生成让 LLM 为每次推荐结果生成一段自然语言理由交给前端展示。这个链路里前三步的耗时在几十毫秒级第四步比较重但可以通过只让 LLM 对 Top 50 做排序来压缩成本。实际线上部署时还会用一个小模型做预过滤减少 LLM 的调用量。4.2 关键代码实现思路这里分享一个 Item 语义化的示例用的就是常见的文本转向量方式from sentence_transformers import SentenceTransformer model SentenceTransformer(paraphrase-multilingual-miniLM-L12-v2) def build_item_text(item): # 把物品的各个字段拼成一段描述 text f标题{item[title]}简介{item[desc]}标签{,.join(item[tags])} return text item_texts {item_id: build_item_text(item) for item_id, item in items.items()} item_embeddings {item_id: model.encode(text) for item_id, text in item_texts.items()}这一步的重点不是代码而是文本拼装的方式。千万不能把字段简单用句号拼接要让 LLM 理解字段之间的关系。比如在标题后加个冒号在简介后加个分号这种微小的格式差异会影响 embedding 的质量。用户画像构造也一样把历史行为按时间排序每行一条前面加上行为类型比如用户历史行为 - 观看到一半 标题「星际穿越」 简介「关于虫洞和五维空间」 - 点赞 标题「宇宙时空之旅」 简介「天体物理科普纪录片」这种结构化的文本比用 JSON dump 出来的效果好得多因为 LLM 在预训练时对“类似日志格式”的文本更敏感。4.3 精排 Prompt 的一个可复用模板精排的关键是 Prompt 设计下面是我试过相对稳定的一版你是一个视频推荐排序引擎。下面有用户信息和一批候选视频请根据用户的兴趣将候选视频按匹配度从高到低排序。 用户信息 {user_context} 候选视频 1. 标题「XXX」简介「XXX」 2. 标题「XXX」简介「XXX」 ... 请只输出排序后的编号例如2,5,1,3,4这里有个经验必须加上“只输出编号”的约束否则 LLM 会输出一堆解释解析和稳定性都很难处理。另外候选视频数量控制在 20 个以内再多了 LLM 的注意力会分散排序质量明显下降。如果想让排序结果更可控可以再加一句约束“如果某个视频与用户历史过往内容高度重复降低它的优先级。”这就相当于把特定业务规则注入 Prompt比改规则权重容易多了。5. 上线前必须考虑的工程化问题Demo 跑通不难但真的要替换线上传统引擎工程问题才是大头。5.1 延迟和成本控制传统的双塔召回加排序塔单次推荐服务延迟一般在 50ms 以内GPU 量也不大。但 LLM 推理的延迟很高尤其如果用 7B 以上的模型做精排单次推理可能要几百毫秒到一秒这个延迟没法直接上推荐链路。几个实际可用的优化手段用 1.5B 左右的小模型做精排只关注排序不关注生成效果够用。蒸馏先让大模型离线生成一批排序结果用小模型去学线上只跑小模型。做两级过滤先用向量召回 Top 200再用轻量模型粗排到 Top 30最后只让 LLM 看这 30 个。缓存用户级结果很多用户短时间内兴趣变化不大可以按用户粒度缓存 5 分钟以内的排序结果。5.2 数据回流与模型更新传统推荐系统是“训练→评估→发布→回收日志→再训练”的闭环更新周期天级。LLM 推荐链路更像“写 Prompt→评估→发布→改 Prompt→再发”更新周期小时级但模型本身的参数更新还是需要依赖微调。这里最容易被忽视的是评估体系。LLM 推荐的输出是文字和排序评估时不能只看 CTR要看用户是否真的对“推荐理由”产生反馈。我建议至少要盯住三个指标推荐结果的多样性防止 LLM 因为语义相近把结果都收敛到同一题材解释文本的“幻觉率”防止推荐的物品和理由对不上长尾物品曝光占比这个比整体 CTR 更重要因为长尾是 LLM 的核心增量5.3 线上灰度与回滚方案替换传统引擎是一个高风险动作必须做影子模式和灰度。影子模式新链路和旧链路同时在线但新链路结果只记录不展示通过离线对比指标评估优劣。这一步至少跑 1 到 2 周积累足够多的真实用户反馈。灰度模式按用户在线上逐步放开从 1% 到 5%、10%、20%、50%。每放一个梯度都要盯住核心指标和负向指标。尤其要盯住“取消推荐”和“举报”这类负向反馈LLM 一旦理解跑偏产生的错误推荐比传统模型还要离谱因为它会把一个不该推荐的理由说得头头是道。回滚方案也很重要。LLM 链路和传统链路要并行部署一段时间保证传统推荐服务随时能切回去不要上来就把旧链路下线。我见过有的团队太自信直接下线旧引擎结果新引擎出了问题重新冷启动损失了整整两周的推荐质量。6. 真实场景中的问题排查与调优经验下面这些坑全部来自我自己的实测或者和同行交流每一件都有对应的解决思路。6.1 “LLM 排序结果偏爱某些题材”这是最常见的问题。LLM 在排序时会受到训练数据分布的影响倾向于把热门题材排在前面导致推荐结果多样性下降。排查思路先统计排序结果和候选题材的分布差异如果 LLM 输出中科幻题材占比明显高于候选分布就说明 Prompt 里缺少多样性指令。我采用的解决方法是在 Prompt 里加入一句“请确保排序结果覆盖多个类型避免集中推荐单一题材”同时在候选输入时按题材做一次均匀采样从根源上保证候选池分布均衡。6.2 用户历史行为过长导致上下文溢出用户用了一两年历史行为可能有几千条全塞进 Prompt 肯定超限。轻则截断重则影响推荐质量。处理方法是先做行为摘要而不是简单截断。比如归纳出用户最稳定的三类兴趣标签、最近强意图的几条行为、以及最排斥的内容类型。这一步本身也可以用 LLM 来做离线定期更新用户画像线上只拿摘要进 Prompt。我给自己加的一道保险是原始行为序列最长保留 50 条再多就必须走摘要。如果用户行为确实跨度大就按时间切片保留最近 30 天加长期兴趣摘要两层。6.3 “解释生成了但理由和排序结果对不上”这类问题出现频率很高。比如 LLM 把纪录片排在第一位但解释却说因为用户喜欢科幻。本质原因是“排序”和“解释”用的是同一份 Prompt但模型在生成解释时过度自由发挥。解决办法解释生成不直接从排序结果反推而是单独构造一个 Prompt把“用户画像 排序结果的 Top 1 物品描述”传进去让 LLM 只专注解释这一个物品。同时给解释模板加约束比如“只能基于用户历史行为和该物品的内容属性不能编造用户偏好”。我还试过在解码阶段降低 temperature 到 0.2解释和事实的对齐度会明显提高。6.4 修改 Prompt 后效果不稳定LLM 推荐和传统模型不同你改一个词整体效果可能天翻地覆。这种不稳定性对团队协作是很大的挑战。我的经验是建立一套 Prompt 版本管理每次修改不仅要记录文本还要记录当时评估的指标结果甚至包括测试样本集。回退时必须连样本集一起回退否则没法判断当前效果好是 Prompt 的原因还是换了一批测试数据的原因。另外做 Prompt 修改要一次只改一处。我见过有人一次改三个地方效果变好但不知道哪个改动起效下次想复用都没法提取有效变量。7. 这套方案适合哪些团队和业务不是所有推荐业务都适合立刻用 LLM 替换。我自己会从三个维度判断一个团队适不适合上手。第一内容库的语义丰富度。如果你的物品描述只有几个分类标签没有任何长文本信息LLM 的上手空间就很小。反之如果有标题、简介、评论、字幕等多元文本LLM 就能大展拳脚。第二用户行为的复杂程度。如果用户行为十分单调比如只有点击和收藏两种传统模型也够用。但如果行为类型多样且不同行为反映的意图差异很大LLM 的意图理解能力就很重要。第三对解释和可控性的需求。如果产品需要给用户推荐理由需要让运营能通过自然语言干预推荐策略那 LLM 几乎是最佳选择。如果只是默默推荐不需要解释那传统模型加规则也能撑住。从我目前观察到的情况来看最适合落地的场景是长视频内容平台、知识社区、短视频中内容质量较高的垂类以及电商中非标品推荐。这些业务有个共同点物品的信息密度高用户决策需要“理解”而不是单纯靠点击统计。8. 最后说点实际的体会做了这么多年推荐我有一种很明显的感觉传统的特征工程和模型结构已经走到了一个平台期大家都在拼算力、拼特征但真正影响体验上限的是系统能不能理解“人到底想要什么”。而 LLM 提供的是完全不同的路径——它不靠统计靠语义不靠表格靠语言。这条路径虽然现在还有很多工程问题比如成本和延迟、可解释性、幻觉控制但方向已经非常清晰。如果你正好在做推荐系统我建议不要急着全量替换可以先找一个窄场景比如“搜索无结果时的相关推荐”或“新用户冷启动推荐”用 LLM 链路做影子测试。这两个场景是传统模型最弱的部分也是 LLM 最容易出效果的地方。跑通后再去碰核心推荐页风险会小得多。我自己在搭 Demo 的时候最大的收获其实不是模型效果而是理解了“把推荐问题变成文本生成问题”之后原来很多绕来绕去的规则、特征、权重的破事全变成了 Prompt 里的一句话。这个转变值得每一位做推荐的同学认真体验一次。