把决策降维：LLM 在推荐系统里的位置

观点来自作者本人与 AI 的讨论，文字整理由 AI 辅助完成。

前两篇里，我先说 LLM 替代的是「人」，而不是概率模型；又说如果让 LLM 自主迭代推荐系统，它缺的不是智力，而是 runway。

这一篇的起点，是我最近的一点亲身体会。我在试用一类专门做判断、直接输出校准概率的模型，¹ 让它给内容打标：是不是用户原创、是不是 AI 生成。它做得非常好。

这让我联想到混排、重排阶段的一类做法：加上 contextual bandit，根据用户实际的兴趣去改变候选的组合。这类方法过去取得过非常好的效果。而传统推荐系统在根据实时兴趣做调整这件事上，一直做得不太理想：要么很刻意，要么很笨重。

那么，既然 LLM 在内容理解、打标这类任务上做得这么好，能不能让它根据实时兴趣，给候选组合打标、做调整？这样不就既把决策降了维，又能提升系统指标了吗？

要回答这个问题，得先想清楚两件事。现在业界都在谈「LLM native」的推荐，可到底什么才算 LLM native？在信息流这种场景里，它究竟能落在哪？

「像 LLM」不等于「LLM native」#

现在很多生成式推荐，比如快手的 OneRec，以及更早的 TIGER，都把每个内容切成一串离散的语义 ID，再用 Transformer 自回归地生成下一个内容的 ID，后面还会接上 MoE、强化学习对齐。² 从模型结构到训练方式，都很像 LLM。

但它的「词表」，是从内容和行为的 embedding 里从零学出来的。里面没有语言，也没有世界知识。它借的是 LLM 的形式，不是 LLM 的知识。我更愿意把这类模型叫做 LLM-style。

在我看来，LLM native 的本质是：底座是语言预训练带来的语义理解和世界知识，行为数据再对齐进同一个空间。 前者提供先验，让系统不靠流量就能懂内容、懂人；后者提供校准，补上那些语言里没有的协同规律，比如「喜欢 A 的人也喜欢 B」。Google 把语义 ID 接进预训练语言模型继续训练的 PLUM，就是往这个方向走。³

至于漏斗后面还接不接精排，只是实现上的选择，不改变它是不是 LLM native。事实上，今天这些生成式模型落地时，大多仍然只是一个召回源，后面照样接着精排。⁴

判断一个系统是不是真的 LLM native，可以问四个问题：

• 产品经理改一句话，系统的行为会不会跟着变？
• 一条全新的内容，在零互动的情况下，能不能推给对的人？
• 系统能不能用一句话，解释为什么给你推这个？
• 用户说一句「最近少推点这类」，系统听不听得懂？

今天的级联系统一个都做不到。这四件事，正是 LLM 能给推荐系统带来的真正增量。

三笔账#

可一旦想把 LLM native 放进信息流，就要算三笔账：延迟、量级、实时意图。

延迟，可以绕开。 真正拖慢速度的，是 LLM 在请求的关键路径上一个字一个字地生成。绕开的办法基本都是把它移出关键路径：内容理解、用户画像在请求来之前就异步算好；需要在线的部分，让 LLM 只跑一次前向、直接给出判断，而不是逐字生成；再不行，就把它的语义空间蒸馏到一个线上跑得动的小模型里。

量级，取决于成本摊在哪个维度上。 用一个专门做判断的模型的公开价格粗算一下，¹ 假设有 10 亿用户：

两者差了六千多倍。这还只是只收输入费的判断模型；换成要生成文字的 LLM，第二行还要贵得多。按用户、按内容摊，账算得过来；按每个候选摊，永远算不过来。

实时意图，才是真正的硬伤。 一次刷视频的过程中，用户的意图几秒钟就会变：连着划走三条，又完整看完一条。提前算好的画像，从定义上就是旧的；每划一次就调一次 LLM，又回到了上面那张表的第二行。

两种「快」#

想到这里，我对 LLM 和经典模型的区别有了一个更清楚的感觉：LLM 更灵活、更实时，但不精确；经典模型更教条、更能扩展、更精确，但反应慢。

这里的「实时」和「反应慢」，其实说的是两种不同的快。

LLM 适应得快、算得慢；经典模型算得快、适应得慢。

用户刚搜了「露营装备」，或者刚看了一条突发新闻，新的兴趣冒出来了。经典模型要等数据积累，LLM 一眼就能看懂。但要它在每一次划动之间，给几百个候选各打一个精确的分，它又跟不上。

有点讽刺的是，那个专门做判断的模型给自己取名「System One」，用的是卡尼曼「快思考」的说法。⁵ 可在推荐系统里，真正的 System 1 是经典精排：快、靠统计、靠记忆。LLM 更像 System 2：慢、会推理、懂世界。

把决策降维#

那 LLM 在信息流里到底能落在哪？我想来想去，只有一个地方，这笔账是算得过来的。

经典系统先把排序整体排好，并且按语义分成三四组候选，每组内部已经精排完毕。用户来了新的兴趣，由 LLM 根据实时意图，在这几组之间做选择和调整，就像一个价值模型或者 bandit 在做混排微调。

为什么这样账就算得过来？因为 LLM 要做的决策，维度被降下来了：

• 不是给几百个候选各打一个分，而是在三四组里挑一组，或者给一组权重；
• 不是每个候选都调用一次，而是每刷新一屏，甚至只在兴趣变化时才调用一次；
• 输入只是最近几次行为的摘要，加上每组候选的语义描述；
• 它不需要知道你喜欢 75% 还是 83%，只需要知道你此刻更想看哪一组；
• 延迟也可以藏起来：在用户看当前视频的十几秒里，提前把下一屏算好。

还是按上面的价格粗算，10 亿用户、每人每天 20 次这样的决策，一天大约 84 万美元。不算便宜，但完全可以承受；只在兴趣变化时才触发，或者换成自研的小模型，还能再低一个数量级。

用一个比喻：经典模型负责做菜，LLM 负责点菜。 每道菜有多好，要精确地算；可今天这顿先上哪几道，要看你此刻的心情。这件事过去是运营在做，现在交给 LLM，在每一次会话里实时地做。这其实就是「LLM 替代的是人」的实时版本。

它和 bandit 也能自然地结合：LLM 给每一组提供先验，bandit 用实时反馈快速修正后验。⁶ LLM 负责「懂」，bandit 负责「快」。

这也是我觉得它比过去的做法更有希望的原因。contextual bandit 的瓶颈，一直在于上下文怎么表达。过去的上下文特征大多是手工设计的，所以根据实时兴趣做调整，才常常显得刻意或者笨重。LLM 的打标能力，正好补上这一块，而且可以拆开来做：内容的标签，每条内容算一次；用户此刻的意图，只在兴趣变化时总结一次；两者之间怎么匹配，交给 bandit 用实时反馈去学。LLM 产出的是 bandit 的上下文，而不是在每个候选上实时打分。

当然，这还只是一个思路，有几个问题必须想清楚。

LLM 到底比 bandit 强在哪？ 经典的序列模型本来就会在会话里调整。LLM 的优势，只会出现在语义上的跳变、历史里从没出现过的新兴趣，以及用户用语言给出的反馈这几类场景。它们在流量里占多大比例，决定了这一层值不值得做。

候选组要分得有意义。 每组要有语义标签，LLM 才能推理；几组之间要真的不同，才有选择的空间；还要给 LLM 留一个「去取新的一组」的动作，新兴趣不在任何一组里的时候，它能发起一次新的召回。

不能追着一时的兴趣跑。 刚看了一条就猛推一类，很容易掉回低质量的局部最优。需要用长期画像做先验，限制住调整的幅度。

按成本分层#

把这个思路推广开，LLM native 推荐的理想形态，应该是按「多久算一次」来分层的：

• 系统层，按周或按季度： LLM 像工程师和运营一样，读实验、提方案、组合模块，把用自然语言写的策略翻译成 reward。人只负责定价值取向和 runway。
• 内容层，每条内容算一次： LLM 读懂内容，给出语义标签和质量判断。算一次，被这条内容之后的所有曝光复用。
• 用户层，每个用户每小时或每天，异步： LLM 读懂人，写一份「用户备忘录」：稳定的兴趣、刚冒头的兴趣、该探索什么、该避开什么。算一次，被这个用户之后的所有请求复用。
• 请求层，每次请求，毫秒级： 经典模型负责召回和精确打分；LLM 只在降维后的少数决策点上出手。

一句话：LLM 出先验，经典模型出后验。 LLM 提出的假设变成探索流量，经典模型测出的结果，再回过头修正 LLM。

边界会移动#

这几层之间的边界，本质上是一条成本曲线。

推理成本每降一个数量级，边界就往下移一格：用户层从每天刷新，变成每次会话刷新，再变成每次请求刷新；请求层里经典模型负责的部分越来越窄。一次前向就给出判断的模型越来越成熟，手机上能跑的小模型越来越强，也都在推着这条线往下走。

如果有一天，每次请求的 LLM 成本低于这次请求能带来的价值，精度和校准的问题也解决了，「完全替换」也许就自然发生了。所以我说过，我对完全替换始终保持开放。理想形态不是一张固定的架构图，而是成本函数的结果。

只是在今天，答案是清楚的：

经典模型擅长把一件事算准，LLM 擅长判断现在该算哪件事。

第一篇说，LLM 替代的是人；第二篇说，它缺的是 runway；这一篇想说的是：要让它在推荐系统里真正落地，就把它要做的决策降维。