📑 本页目录（点开跳转）
14 · 生成式推荐：2026 年的前沿
⏱ 30 分钟 ｜ 🎁 想卷再看 ｜ ⚠️ 这一节的内容变化很快，参考时请注意时效
🎯 一句话
推荐系统正在经历它的 "GPT 时刻"：从「几十个模型拼成的漏斗」变成 「一个大模型端到端生成推荐结果」——而且第一次出现了 Scaling Law（模型越大效果越好，且可预测）。
🤔 先说清楚：为什么这是件大事
过去二十年，推荐系统有一个尴尬的事实：
模型做大，效果不涨。
你把 DeepFM 从 1 亿参数扩到 10 亿参数，AUC 可能只涨 0.0005，甚至不涨。 这和 NLP/CV 完全不同——那边是「参数翻倍，效果稳定提升」。
2024 年 Meta 的 HSTU 论文第一次打破了这个僵局，在十亿用户级别的线上系统里展示了推荐领域的 Scaling Law。
传统推荐模型 生成式推荐 (HSTU 之后)
效果 效果
▲ ▲
│ ╭───────────── │ ╱
│ ╱ │ ╱
│ ╱ 很快就饱和了 │ ╱ 幂律增长
│ ╱ │ ╱ 像 LLM 一样
└────────────────► 参数量 └──────────────► 训练算力
这意味着什么：推荐系统可能第一次有了「基础模型（Foundation Model）」—— 一个预训练的大模型，微调后能同时服务推荐、搜索、广告。
🧩 核心概念一：Semantic ID（语义 ID）⭐
问题：传统 item_id 是「哑」的
item_id = 8823174 ← 这个数字本身没有任何含义
item_id = 8823175 ← 和上面那个毫无关系
后果：
· Embedding 表巨大（1 亿物品 × 64 维）
· 新物品的 Embedding 从零学起 → 冷启动灾难
· 完全没有泛化能力（学会 8823174 帮不了 8823175）
解法：让 ID 携带语义
一个视频
↓ 用多模态模型编码（标题+封面+内容）
连续向量 [0.23, -0.51, 0.88, ...]
↓ RQ-VAE（残差量化）：逐层逼近，每层挑一个码字
Semantic ID = <c₁=42, c₂=17, c₃=203, c₄=88>
↑ ↑ ↑ ↑
粗粒度 细化 更细 最细
「科技」「数码」「键盘」「机械键盘评测」
💡 人话翻译：
把物品 ID 从「身份证号」改成「分类编码」。 就像图书馆的索书号：
TP391.4/L23—— 光看编号就知道是计算机类的书。好处：
<42,17,203,88>和<42,17,203,91>前三位相同 → 模型立刻知道它们相关， 哪怕第二个是刚发布的新物品。
🎁 Semantic ID 的四个红利
| 红利 | 说明 |
|---|---|
| 词表大幅缩小 | 1 亿物品 → 4 层 × 256 个码字 = 1024 个 token。Embedding 表从 GB 级降到 MB 级 |
| 冷启动几乎消失 ⭐ | 新物品编码后立刻有语义 ID，模型天然知道它属于哪一类 |
| 可以用生成的方式做推荐 | 像语言模型生成单词一样，逐个 token 生成物品 ID |
| 跨域/跨模态统一 | 推荐、搜索、广告可以共享同一套 token 和同一个预训练骨干 |
⚠️ 但也有真实的坑
- 码字冲突：不同物品可能编到同一个 Semantic ID → 需要加去重后缀
- 语义 ≠ 行为：内容相似 ≠ 用户行为上相似（《甄嬛传》和《延禧攻略》内容像，但受众可能不同）
- Tokenizer 质量决定一切：RQ-VAE 训得不好，整个系统就垮了。2025–2026 年有多篇论文专门研究 Semantic ID tokenizer 的评测可靠性问题
- 码本坍塌（Codebook Collapse）：大量码字从不被使用
🧩 核心概念二：把推荐变成序列生成
TIGER（2023）：开创性的思路
传统召回：
用户向量 ──点积──► 1亿个物品向量 ──ANN──► top-K
（检索式：从库里"挑"）
生成式召回 (TIGER)：
用户历史 → [<42,17,203,88>, <91,3,55,12>, ...]
↓ Transformer Decoder
直接"写出"下一个物品的 Semantic ID：<42,17,205,>
（生成式：直接"造"出答案）
💡 这是范式转变：
从「在候选库里搜索」变成「直接生成答案」。 不需要 ANN 索引了，因为模型直接吐出 ID。
⚠️ 代价：生成的 ID 可能不存在（幻觉）→ 需要受约束解码（Constrained Beam Search）， 用一棵前缀树（Trie）限制每一步只能生成合法的码字。
🧩 核心概念三：HSTU —— 让 Scaling Law 出现
HSTU = Hierarchical Sequential Transduction Unit（Meta, ICML 2024）
它做对了什么
1. 把「所有东西」统一成一个序列
传统推荐把特征分成几百个字段。HSTU 把用户的全部行为（点击、点赞、购买、搜索…）和物品，统一成一条时间序列的 token 流：
[看了A] [赞了A] [搜索"键盘"] [看了B] [买了B] [看了C] ...
↑ 每个动作和每个物品都是序列里的一个 token
论文题目 "Actions Speak Louder than Words" 就是这个意思：行为序列本身就是最好的特征，不需要几百个手工特征。
2. 为推荐场景重新设计的注意力 标准 Transformer 在推荐的超长序列（8000+）上太慢。HSTU 改造了注意力结构， 论文报告在 8192 长度序列上比基于 FlashAttention2 的 Transformer 快 5.3–15.2 倍。
3. M-FALCON 推理优化 把多个候选物品的推理批量微融合，大幅降低线上推理成本。
📊 论文报告的结果
| 指标 | 结果 |
|---|---|
| 线上 A/B | +12.4% |
| 参数规模 | 1.5 万亿 |
| 公开数据集 NDCG | 最高 +65.8% |
| 长序列速度 | 比 FlashAttention2 Transformer 快 5.3–15.2× |
| Scaling Law | 效果随训练算力呈幂律增长，跨越三个数量级 |
📌 代码开源：meta-recsys/generative-recommenders 论文：arXiv:2402.17152
🏭 2026 年的工业界现状
已经落地的（不是论文，是线上系统）
| 公司 | 系统 | 关键点 |
|---|---|---|
| Meta | HSTU / GEM | 生成式推荐进入主推荐和广告 |
| 快手 | OneRec ⭐ | 把「召回→粗排→精排→重排」整个漏斗塌缩成一个生成式模型，报告运营成本约为原多阶段系统的 1/10 |
| Netflix | 个性化基础模型 | 一个基础模型同时服务首页和搜索 |
| Spotify | Semantic-ID 生成式检索 | 用于播客发现 |
🔥 OneRec 的意义：漏斗要没了？
OneRec 的几个技术选择值得注意： - Encoder-Decoder + 稀疏 MoE：扩容量不成比例增加计算 - Session-wise 生成（一次生成整个会话列表，而不是逐个物品）→ 天然解决了第 11 节的「列表整体最优」问题 - DPO 偏好对齐：借用 LLM 的对齐技术做推荐
🎁 开源：快手开放了 OneRec 基础模型和 benchmark（OpenOneRec）
🤖 LLM 在推荐里的四种用法（分清楚，别混）
- 用 LLM 生成物品的文本描述、标签、摘要 → 变成 Embedding 特征
- ✅ 不改架构，直接接入现有系统
- ✅ 对冷启动帮助巨大
- 直接让 LLM 输出推荐结果："用户看过A,B,C，推荐什么？"
- ❌ 慢（几百 ms 起）、贵、幻觉、无法处理亿级物品
- ✅ 但在「对话式推荐」「解释推荐理由」上有独特价值
- 不用 LLM 的权重，只借用它的架构和训练范式
- 把用户行为序列翻译成自然语言画像，再喂给推荐模型
🔑 重要认知：③ 才是工业界真正在做的事。 「直接让 ChatGPT 推荐」（②）在演示里很酷，但在亿级流量的生产系统里不实用。
🎯 2026 年的活跃研究方向
| 方向 | 在解决什么 |
|---|---|
| Semantic ID Tokenizer 的可靠性 | 不同 tokenizer 的对比结论是否可复现？码本坍塌怎么治？ |
| 超长序列 | 用户一生的行为（10 万+）怎么建模 |
| 推理时扩展（Test-time Scaling） | 借鉴 LLM 的思路，推理时多想一会儿能不能更准 |
| 蒸馏到轻量模型 | 大模型效果好但太贵 → 蒸馏成 MLP 部署 |
| 多目标 + 生成式 | 生成式框架下怎么做「点击/时长/点赞」的多目标平衡 |
| 搜广推统一 | 一个基础模型同时服务搜索、推荐、广告 |
| 强化学习对齐 | 用 DPO/RLHF 类方法对齐长期用户价值而非短期点击 |
⚖️ 泼一盆冷水：你现在该学吗？
🚫 大部分人不该从这里开始
| 如果你… | 建议 |
|---|---|
| 在找工作 / 刚入门 | 先把第 6、8、12 节吃透。面试 90% 问的是漏斗架构、DIN、双塔、AUC/GAUC、A/B 实验 |
| 在小公司做推荐 | 生成式推荐需要海量数据 + 大量算力，小规模数据上它打不过 DeepFM |
| 想做研究 / 在大厂核心团队 | ✅ 这就是主战场，赶紧跟 |
现实约束
HSTU / OneRec 的门槛：
· 数据：亿级用户 × 千亿级行为
· 算力：数百到数千张 GPU
· 团队：算法 + 基础设施 + 训练框架，跨团队协作
· 时间：从实验到上线通常以「年」计
💡 数据量不够时，大模型只会过拟合。
Scaling Law 的前提是「数据也一起 scale」。
✅ 但有两件事你现在就能做
- 用 LLM 做特征工厂（上面的用法①）。成本低、见效快、不用改架构，对冷启动帮助立竿见影。这是 2026 年性价比最高的「AI 增强推荐系统」的做法（第 18 节·专题六有可直接抄的操作流程）。
- 在笔记本上复现核心机制。RQ-VAE + Semantic ID + 受约束生成，完全可以小规模跑通 —— 挑战项目C 手把手带你造一个 TIGER-mini。
🔗 这一章连到哪里
| 去哪 | 为什么 |
|---|---|
| 全景导论 02 | TIGER / HSTU / OneRec 骨子里都是 Decoder：self-attention、causal mask、逐 token 生成，先在这里补齐 |
| 全景导论 03 | Semantic ID 就是推荐系统的 tokenizer——「码本坍塌」和 LLM 的词表设计问题是同一类病 |
| 强化学习 13 | OneRec 用 DPO 做偏好对齐：LLM 那套对齐技术被原样搬进了推荐 |
✅ 检查点
- 为什么说生成式推荐是推荐系统的「GPT 时刻」？（关键词：Scaling Law）
- Semantic ID 是什么？它相比传统 item_id 的三个好处？
- TIGER 式的生成式召回和传统 ANN 召回，根本区别是什么？
- HSTU 论文的核心主张是什么？（提示：看它的标题）
- OneRec 最激进的地方是什么？
- LLM 用在推荐里的四种方式，哪一种是工业界主流？
- 一个团队该不该上生成式推荐？判断标准是什么？
👀 答案
1. 传统推荐模型做大效果不涨，HSTU 首次在十亿用户级线上系统展示了效果随训练算力幂律增长，推荐领域第一次有了「基础模型」的可能。 2. 用 RQ-VAE 把物品的多模态向量量化成一串有层次含义的离散码字。好处：词表大幅缩小、冷启动几乎消失（新物品编码后立刻有语义）、可以用生成方式做推荐、跨域跨模态统一。 3. 传统是「检索式」——在候选库里搜；生成式是直接「写出」物品 ID，不需要 ANN 索引。代价是可能生成不存在的 ID，需要受约束解码。 4. "Actions Speak Louder than Words" —— 用户行为序列本身就是最好的特征，把所有行为和物品统一成一条 token 序列，不需要几百个手工特征。 5. 把「召回→粗排→精排→重排」整个多阶段漏斗塌缩成一个端到端生成式模型，报告成本降到约 1/10。 6. 用法③（借用 LLM 的架构和训练范式，配推荐数据训练，如 HSTU/OneRec/TIGER）。用法①（LLM 做特征工厂）是最实用、性价比最高的落地方式。 7. 看数据量和算力。亿级用户+千亿行为+数百 GPU 才有意义。数据量不够时大模型只会过拟合，DeepFM 更划算。🛑 可以停在这里
⚡ 走神救援
生成式推荐 = 推荐的 GPT 时刻，首次出现 Scaling Law。三个核心概念：① Semantic ID（RQ-VAE 把物品编成有层次的码字，解决冷启动+缩小词表）② 生成式召回（TIGER：直接生成 ID，不用 ANN）③ HSTU（Meta，行为统一成 token 序列，线上+12.4%，1.5万亿参数）。工业落地：快手 OneRec 把整个漏斗塌缩成一个模型，成本降到 1/10。LLM 四种用法，主流是「借架构不借权重」。小公司别跟，先把第 6/8/12 节吃透。⚠️ Semantic ID 不是免费午餐，四个真实的坑：码字冲突（两个物品编到同一串，要加去重后缀）、语义 ≠ 行为（《甄嬛传》和《延禧攻略》内容很像，受众可能完全不同）、码本坍塌（大量码字从不被使用），以及最要命的一条——tokenizer 训不好，上面所有东西全垮。⭐ OneRec 真正激进的地方不只是「一个模型吃掉漏斗」，而是 session-wise 生成：一次生成整个会话列表而不是逐个物品，等于把第 11 节「列表整体最优」的难题在架构层面直接解掉了；再配上 Encoder-Decoder + 稀疏 MoE 扩容量、DPO 做偏好对齐。⚠️ 看到 Scaling Law 别上头：它的前提是数据也一起 scale，日志量撑不起来的话，堆参数只会烧钱。⭐ 但有两件事你今天就能做：① 用 LLM 当特征工厂（不改架构、对冷启动立竿见影，第 18 节专题六有可直接抄的流程）；② 在笔记本上小规模复现 RQ-VAE + Semantic ID + 受约束生成（挑战项目 C 手把手带你造 TIGER-mini）。
下一节 👉 15-工程落地.md