这是什么?

《推荐系统自动研究知识库》 是一个面向推荐系统 auto research 的知识库,内容重写并扩展自 Datawhale 开源项目 fun-rec。

📖 在线阅读：访问 https://haozhe-xing.github.io/fun-rec-mdbook/ 阅读最新版本。

本书围绕推荐系统的两条核心主线展开：

• 判别式推荐 ：召回、排序、重排、多目标、多场景、去偏、冷启动等工业级推荐系统基础能力。
• 生成式推荐 ：语义 ID、生成式排序、端到端推荐、推荐推理、扩散模型与生成式推荐系统实战。

如果你希望从「算法原理」走到「系统实践」，并理解推荐系统从经典架构走向生成式范式的完整脉络，这本书就是为你准备的。

内容地图

本书共 12 个 Part ，建议按顺序阅读；如果你已有推荐系统基础，也可以直接跳到感兴趣的主题。

完整目录见 SUMMARY.md。

1. 安装依赖

cargo install mdbook
cargo install mdbook-katex

2. 本地预览（中英双语一键启动）

./serve.sh

默认在 http://localhost:3000 启动，中文版在 /zh/、英文版在 /en/，根路径按浏览器语言自动跳转。

3. 构建静态站点

mdbook build                          # 中文版 → book/zh/
cp book-en.toml book.toml && mdbook build   # 英文版 → book/en/（构建后恢复 book.toml）

项目结构

本项目提供 中英双语 版本，结构与 agent_learning 一致：

.
├── src/
│   ├── zh/                   # 中文源（当前目录）
│   │   ├── SUMMARY.md        # mdBook 目录结构
│   │   ├── part1-introduction/ … part11-project/
│   │   ├── appendix/         # 附录
│   │   ├── images/           # SVG 图表资源
│   │   └── viz/              # 交互式可视化资源
│   └── en/                   # 英文源（与 zh 1:1 对齐）
├── book.toml                 # 中文版配置 → book/zh/
├── book-en.toml              # 英文版配置 → book/en/
├── root-index.html           # 语言选择首页（按浏览器语言自动跳转）
├── serve.sh                  # 一键构建并本地预览
├── styles/                   # 自定义样式
└── scripts/                  # 自定义交互脚本

推荐阅读路径

初学者路径

适合刚接触推荐系统、希望建立完整知识框架的读者：

Part 1 → Part 2 → Part 3 → Part 4 → Part 5

你会先掌握推荐系统的经典级联架构，再理解召回、排序、重排各模块如何协同工作。

进阶工程路径

适合已经做过推荐算法或推荐工程，希望补齐系统设计能力的读者：

Part 2 → Part 3 → Part 4 → Part 11

你会重点理解工业推荐链路中的候选生成、偏好预测、列表优化和线上服务架构。

生成式推荐路径

适合关注大模型、生成式排序、语义 ID 与下一代推荐系统的读者：

Part 5 → Part 6 → Part 7 → Part 8 → Part 9 → Part 10 → Part 11

你会从范式迁移开始，逐步进入生成式推荐的建模、推理和系统落地。

适合谁读？

• 推荐算法学习者 ：希望系统学习推荐系统核心模型与技术路线。
• 机器学习工程师 ：希望理解推荐系统从离线训练到在线服务的工程链路。
• 推荐系统从业者 ：希望补齐生成式推荐、语义 ID、端到端推荐等新方向。
• 技术面试准备者 ：希望建立清晰的推荐系统知识地图与表达框架。

写作约定

• 章节顶部使用徽章标注 章节编号、预计阅读时间、难度级别。
• 数学公式使用 $行内公式$ 与 $$独立公式$$，由 mdbook-katex 渲染。
• 图表统一放在 images/，交互式可视化放在 viz/。
• 每章尽量包含 常见错误、核心要点、FAQ、章节关联与分层练习。

参与贡献

欢迎通过 Issue 或 Pull Request 参与改进：

• 修正错别字、公式、图表或链接问题。
• 补充推荐系统论文、工业案例或工程实践经验。
• 改进章节结构、示例代码、练习题与可视化内容。
• 提出你希望新增的推荐系统主题。

在提交内容时，建议保持：

• 术语统一 ：优先参考 GLOSSARY.md。
• 结构一致 ：遵循已有章节的组织方式。
• 解释清晰 ：优先说明直觉、边界条件和工程取舍。

致谢

本书重写自 Datawhale 开源项目 fun-rec，感谢原项目作者与社区贡献者为推荐系统学习资料建设做出的贡献。

也感谢推荐系统、信息检索、机器学习与大模型社区中的研究者和工程师。本书中的许多内容都受益于公开论文、工业实践分享和开源社区讨论。

推荐系统是现代互联网最核心的基础设施之一，但其内部逻辑远比「帮用户找内容」复杂。本部分先帮你建立 立体的认知框架 ：从微观的两种范式，到工业的两条技术路线，再到宏观的生态平衡；最后再落到工程底座，理解业务字段如何变成模型可用的特征与 Embedding。

本章涵盖

What You'll Be Able to Do After This Part

• 🟢 描述 推荐问题的两种根本范式（判别式打分 vs 生成式序列生成）及其核心公式
• 🟢 解释 工业级推荐为何采用「召回—排序—重排」三阶段漏斗，以及各阶段的职责
• 🟡 辨析 端到端生成式架构如何消解级联架构的目标不一致、信息损失与计算碎片化
• 🟡 对照 本书的技术地图，定位后续每一章在「能力演进」曲线上的位置
• 🟡 解释 业务字段如何经 slotId / featureSign / value 进入模型，并区分 Sparse、Dense、分桶与 Embedding

核心概念

前置知识

• 具备基础机器学习概念（监督学习、概率、向量表示）
• 了解基本的 Python 与神经网络常识

无需推荐系统前置知识——本部分正是为初学者建立的起点。

Tips for This Part

1. 先建立框架，再抠细节。 前两节重在「认知地图」，具体算法在后续 Part 逐步展开。
2. 对比着读两种范式。 每遇到一个新模型，先判断它属于判别式还是生成式。
3. 记住三阶段漏斗。 它是后续 Part 2–4 的组织线索。
4. 把 1.3 当作表示基础。 后续看到 Embedding、特征交叉或向量拼接时，随时回到 slotId / featureSign / value 检查信息究竟放在哪里。

Let's dive in! 🚀

推荐系统是什么

📝 Before You Continue: 本章是基础起点，不需要任何推荐系统前置知识。你只需要知道「机器学习是让模型从数据中学习规律」这一基本事实即可。

当你早晨打开手机刷新闻，或在电商 App 里闲逛时，可能并未意识到：有一套精密的系统正在毫秒之间做出成千上万个判断，决定你看到什么、错过什么。这就是 推荐系统——现代互联网最底层的基础设施之一。

但「帮用户找到感兴趣的内容」只是表面描述。要真正理解它，我们需要从三个层次去观察：从最微观的 单个预测 ，到工业级的 规模流程 ，再到宏观的 生态平衡。只有层层递进，才能把握推荐系统的核心逻辑。

读完本章，你将能够：

• 用 一句话 说清推荐系统要解决的微观问题，并区分其两种根本范式
• 写出 判别式 与 生成式 的核心公式，并解释二者「问的问题」有何不同
• 解释工业级推荐为何采用「召回—排序—重排」三阶段漏斗 ，以及各阶段职责
• 说明 端到端生成式架构 如何消解级联架构的三大痛点
• 从 生态三角 （用户/创作者·内容·平台）理解推荐系统的长期价值
• 完成 4 道分层练习题，巩固三种视角

1.1.0 三种视角：从微观到宏观

理解推荐系统，最忌「只看到算法」。同样一套系统，放在不同尺度下看到的东西完全不同：

接下来我们逐一拆解。

1.1.1 微观视角：推荐问题的两种根本范式

让我们从最基本的单元想起。推荐系统面临的核心问题看似简单——如何为用户找到最有价值的内容？ 但对这个问题的回答，存在两种截然不同的思路。

无论哪种思路，系统都需要先深入理解三个关键要素：

• 理解用户（User）——你是谁、兴趣如何。历史行为是最重要的信号；显式反馈（如「不感兴趣」按钮）和画像信息（年龄、地域）提供线索；实时意图（刚搜了什么）同样关键。
• 理解物品（Item）——它的内容属性（品类、时长、质量）与统计属性（观看数、评分、互动趋势）。
• 理解场景（Context）——工作日早晨还是周末深夜？地铁通勤还是居家休闲？细微差别显著影响偏好。

💡 Key Insight: 两种范式的输入相同（都要理解用户、物品、场景），但它们提出的问题截然不同。这一点决定了后续所有的架构与优化目标差异。

第一种思路：判别式推荐（Discriminative）

它将推荐定义为：给定一个具体的「用户—物品—场景」三元组，预测用户会对该物品产生正面行为的概率。核心是 打分函数 ：

$$Score=f(User,Item,Context)$$

系统对每个候选物品逐一评估、计算分数、再择优推荐。这就像一位评委，面对所有选手逐一打分，最后选出高分者。

判别式推荐通过整合用户特征 $U$、物品特征 $I$ 与场景特征 $C$，对每个候选物品逐一打分，预测「有价值连接」的可能性。

🧠 Mental Model: 评委打分

把推荐想成「选秀评委」。台上站满选手（候选物品），评委（模型）对每一个选手单独打分，最后按分数高低发通行证。评委从不「直接报出名单」，他只负责打分。

第二种思路：生成式推荐（Generative）

它从根本上重新定义了问题：不再逐一评估候选，而是让模型根据用户与场景的理解， 直接「创作」推荐结果。核心是 生成函数 ：

$$[I_1,I_2,\dots ,I_k]=g(User,Context)$$

模型以用户的历史交互序列和当前场景为输入，通过自回归解码直接生成推荐物品序列。这就像一位了解你品味的朋友，不需要翻遍所有选项，而是直接说「你接下来该看这几个」。

生成式推荐以用户历史交互与场景为输入，通过生成模型直接输出推荐物品序列，无需逐一评估候选。

🤔 Why 两种范式共存？ 判别式在「有限候选中择优」上极其成熟稳定；生成式在「开放空间中创造」上潜力巨大。前者问「用户会喜欢这个物品吗？」，后者问「用户接下来想看什么？」——前者是择优，后者是创造。

能力演进的四个阶段

从更纵深的时间线看，推荐算法呈现出一条清晰的能力演进轨迹，它同时贯穿两种范式：

1. 纯 ID 的记忆——协同过滤将物品视为不透明符号，记忆「看过 A 的人也看了 B」的共现模式。
2. 深度学习的泛化——深度网络通过特征交叉与序列建模，把知识泛化到未见过的用户—物品组合，但物品仍是原子 ID。
3. 语义 ID 的理解——当物品被编码为携带语义的结构化 Token，系统开始真正「理解」内容含义，新物品无需积累行为数据即可被推荐。
4. 大模型的推理——模型不再隐式算分，而是显式分析意图、评估匹配、给出理由，从「模式匹配器」进化为「能解释决策的推理者」。

💡 Key Insight: 这四个阶段并非线性替代，而是层层叠加、彼此共存。今天的工业系统里，基于 ID 的协同过滤仍是召回要道，深度泛化支撑着召回到排序各环节，语义 ID 与大模型推理则在最前沿崭露头角。

1.1.2 工业视角：规模化的两条技术路线

理解了两种基本范式，我们立刻面临共同的现实挑战： 规模。一个典型视频平台拥有数亿用户、上亿物品，推荐要在毫秒级延迟内完成从海量物品到个性化列表的全过程——页面加载超过几秒，大部分用户就会离开。

⚠️ Warning: 推荐系统工程化的核心矛盾是——如何在极有限时间内，从海量候选中找到最优结果？ 两种范式给出了截然不同的解法。

判别式的解法：多阶段流水线

判别式范式的核心困难在于：若为每个用户计算他与所有物品的匹配分数，再强的服务器也会瞬间崩溃。工业界的答案是 分阶段的漏斗式架构 ，用「召回—排序—重排」三层流水线逐步缩小候选，在效率与效果间找平衡。

• ① 召回（Recall）——快速从全量物品库筛出几千个可能相关的候选。奉行「宁可错杀一千，不可放过一个」，不求精准但求全面；模型简单、特征有限（如用协同过滤找相似用户，或基于内容相似性召回）。
• ② 排序（Ranking）——预测函数 $f$ 真正发威的地方。动用最复杂的深度模型，融合用户/物品/场景全特征，为每个候选算精确分数；追求预测精度最大化。
• ③ 重排（Re-ranking）——对排序结果做最终优化。解决「分数最高的列表 ≠ 体验最佳的列表」问题：引入多样性、新颖性，避免前十全是同类内容造成审美疲劳，同时处理广告、运营等业务规则。

💡 Key Insight: 三阶段流水线的精髓是——在不同阶段用不同策略，逐步从「可能相关」筛到「最优匹配」。召回求全、排序求准、重排求体验，三者缺一不可。

生成式的解法：端到端生成

生成式提出一种截然不同的思路：既然模型能直接「生成」结果，为何还需要多阶段筛选？生成式推荐把用户历史交互序列当作「上下文」，通过 Transformer 等自回归模型直接解码出物品 Token 序列——整个过程在一个统一模型里端到端完成 ，无需召回/排序/重排的级联。

💡 Key Insight: 端到端架构消除了级联架构的三个核心痛点：

• 目标不一致——召回优化相关性、排序优化点击率、重排优化多样性，各自为战；
• 信息损失——召回过滤掉的优质物品，后续阶段永远看不到；
• 计算碎片化——不同阶段用不同模型，难以充分利用现代 GPU 算力。

下面用交互演示直观感受「亿级 → 一份列表」的漏斗过程：

点击「下一步」或「自动播放」，观察候选池如何从亿级逐步收缩到最终 10 条列表，以及每一阶段所承担的不同职责。

📊 Data Point: 目前两种架构在工业界并行发展：判别式流水线以「分而治之」在成熟场景中稳定服务；生成式架构以「端到端优化」在前沿探索中展现巨大潜力。

1.1.3 宏观视角：构建多方共赢的生态系统

把推荐系统放在更大视野中，会浮现一个更深层的问题： 一个技术上完美的推荐系统，是否就是一个真正优秀的推荐系统？ 答案往往是否定的。

经典的 「准确率陷阱」 ：用户刚把一部手机加入购物车，此时系统向他推荐这部手机，点击率与转化率可能接近 100%。从指标看极其「准确」，但它创造了什么价值？几乎没有——用户本来就要买，推荐只是重复了他已知的信息，没有增量价值。

💡 Key Insight: 推荐系统的最终目标不是单纯最大化技术指标，而是构建一个让所有参与方长期受益的健康生态。生态中有三个基本支点：用户与创作者、内容、平台，三者相互依存。

• 用户与创作者——分处内容消费与供给两端。用户是最终服务对象，系统应帮其发现「尚未接触但真正感兴趣」的内容，而非困在「越看越窄」的过滤气泡；创作者是内容供给核心，分发能力直接决定其生存空间与动力。供给端正从专业团队（PGC）为主，走向普通用户自发创作（UGC）为主体，并涌现出 AI 辅助生成（AIGC），模糊消费者与生产者边界。
• 内容——连接用户与创作者的媒介，是真正分发的「原子单位」。健康系统不仅要分发受欢迎内容，还要持续发掘潜力内容，避免「头部集中、长尾沉没」。
• 平台——生态协调者。既要优化效果、提升满意度与时长，又要关注长期健康（多样性、抑制低质、保护创作者积极性），有时需牺牲短期指标换取长期信任。

⚡ Pro Tip: 真正优秀的推荐系统是一个精巧的平衡器——在用户、创作者、内容质量与平台发展间找动态平衡点。这要求设计者不仅是技术专家，更需具备生态思维。

⚠️ Common Mistakes in 1.1

本章小结

📌 Key Takeaways

❓ FAQ

Q1: 判别式和生成式，哪个更好？

A: 没有绝对优劣。判别式在成熟场景稳定高效，生成式在前沿探索潜力大。当前工业界两者并行发展，应按业务阶段选择。

Q2: 为什么不能直接给用户展示全量物品让他挑？

A: 上亿物品中，用户只会看极少数。推荐的价值正是替用户在亿级空间里做减法，且要在毫秒级完成——这是工程现实，不是设计偏好。

Q3: 召回阶段为什么可以用「简单模型」？

A: 召回奉行「宁可错杀不可放过」，目标是覆盖而非精准。候选集随后会被排序精筛，所以召回侧可用轻量模型换速度。

前后关联

• 1.2 （本书概览）把本节三种视角落到全书技术地图，定位每章在能力演进曲线上的位置。
• 2.1–2.5 （召回）展开三阶段中「召回」的具体算法家族。
• 3.1–3.5 （排序）深入判别式打分函数 $f$ 的工程实现。
• 5.3 （生成式范式演进）回头呼应本节，系统梳理从判别式到生成式的跃迁。

Practice Problems

Work through all problems in order — they get progressively harder. Each has a complete solution you can reveal after trying it yourself.

Problem 1.1.1 — 区分范式 🟢 Easy

给定以下两个系统描述，判断它们更接近 判别式 还是 生成式 范式，并说明理由。

• (a) 系统为每个候选广告计算「用户点击概率」，按概率排序展示前 5 个。
• (b) 系统读取用户近 20 次播放记录，直接输出「接下来你可能想看的 3 个视频 ID」。

Problem 1.1.2 — 补全流水线 🟢 Easy

一个推荐系统面对 1 亿物品，最终展示 10 条。请在括号中填入正确的阶段名，使其符合工业级漏斗：

全量物品 (1亿) → [ ① ] → 候选 (约2000) → [ ② ] → 候选 (约200) → [ ③ ] → 最终列表 (10条)

全量物品 (1亿) → [ 召回 Recall ] → 候选 (约2000)
               → [ 排序 Ranking ] → 候选 (约200)
               → [ 重排 Re-ranking ] → 最终列表 (10条)

Problem 1.1.3 — 准确率陷阱分析 🟡 Medium

某新闻 App 发现：向刚读完一篇「世界杯决赛」报道的用户，立即推荐另一篇「世界杯决赛」报道，点击率高达 95%。产品经理据此认为推荐「非常精准」。请指出这个结论的问题，并给出更合理的评估角度。

🏆 Challenge: 设计权衡论证

假设你要为一款日活千万的新App从零搭建推荐系统。请写一段 150 字内的论证，说明：在初期数据稀疏、算力有限时，为何应 优先采用判别式三阶段流水线 而非端到端生成式架构？并指明当业务进入成熟期后，可在哪类场景尝试引入生成式。

本书概览与技术地图

📝 Before You Continue: 请先读完 1.1 的三种视角。本章把那张「立体认知」展开成一张可导航的技术地图，帮你定位后续每一章。

理解了推荐系统的核心逻辑后，真正的挑战是把认知变成可操作的技术方案。研究者与工程师提出过数百种算法，初学者常陷入迷茫：这些模型有什么关系？什么场景选哪种？如何拼出完整系统？

本章给你一张地图。本书沿 判别式 与 生成式 两条主线组织，同时串起从「记忆·泛化」到「理解·推理」的能力演进。

读完本章，你将能够：

• 说出本书 上下两篇 的划分逻辑与各自的落脚点
• 把 基础篇（Part 1–5） 每一章对应到三阶段流水线或前沿趋势
• 解释为何「召回→排序→重排」是判别式的组织线索
• 预判 生成式主线 在后续版本（Part 6–11）将如何展开
• 完成 4 道分层练习题，检验对技术地图的掌握

1.2.0 一张地图，两条主线

本书的编排可用一张图概括：横轴是 时间/能力演进 （从纯 ID 记忆到 LLM 推理），纵轴是 两条范式主线 （判别式 vs 生成式）。

• 上篇：判别式推荐的工业实践——沿「召回 → 排序 → 重排」流水线逐步深入，是记忆与泛化能力的主战场。
• 下篇：生成式推荐的技术图景——从基础范式出发，经 Scaling Law、端到端建模、推理能力到扩散模型，是理解与推理能力的探索场。

💡 Key Insight: 两条主线不是割裂的。生成式架构往往在判别式成熟模块的基础上「端到端化」；而判别式的语义 ID、特征交叉等技术，又为生成式提供了表示基石。

1.2.1 上篇：判别式推荐的工业实践（本版覆盖）

本版（基础篇）完整收录上篇及承上启下的趋势章，共 5 个 Part：

召回：从亿到千（Part 2）

召回是流水线起点，要在毫秒级从亿级物品筛出千级候选。其技术演进沿五节展开：

• 协同过滤——经典起点：从 ItemCF 的物品相似度，经 Swing 工业优化、UserCF 用户视角，到矩阵分解把用户/物品映射为隐向量，开启向量化先河。
• I2I 向量召回——把 Word2Vec 序列建模思想迁移到推荐：从 Item2Vec 直接迁移，到 EGES 融合属性，再到 Airbnb 把业务目标融入序列构建。
• 双塔模型（U2I）——用户与物品分别编码为向量，以 FM、DSSM、YoutubeDNN 为代表，实现高效向量检索。
• 序列召回——关注被前面方法忽略的时序信息：MIND 用多向量表示多元兴趣，SDM 分离长短期偏好并以门控动态融合。
• 流式索引召回——跳出模型内部压缩：Trinity 用聚类统计保留全量历史兴趣，Streaming VQ 让索引结构实时适应数据分布。

排序：从千到百（Part 3）

排序对千级候选精准打分，是深度泛化的主战场：

• Wide & Deep——联合训练线性模型与深度网络，确立「记忆 + 泛化」基础框架。
• 特征交叉——从 FM 二阶交叉，经 DeepFM、xDeepFM，走向自动高阶交叉。
• 序列建模——DIN 用注意力按候选动态激活历史；DIEN 显式建模兴趣时序演化。
• 多目标 / 多场景——MMoE、ESMM 平衡多目标；多塔与动态权重适配多场景差异。

重排：从百到一屏（Part 4）

排序输出常高度同质化，重排在保相关性的前提下优化整张列表体验：

• 贪心重排——MMR 线性组合相关性与多样性；DPP 用行列式框架更精确控制多样性。
• 个性化重排——PRM 用 Transformer 建模物品间相互影响，实现端到端个性化列表生成。

1.2.2 下篇预览：生成式推荐（后续版本覆盖 Part 6–11）

为帮你建立完整认知，这里简要预告下篇，让你知道本版之后的路通向何方：

📝 Note: 本版聚焦基础篇（Part 1–5）。下篇内容将在后续版本以相同 book-writer 规范续写。

⚠️ Common Mistakes in 1.2

本章小结

📌 Key Takeaways

❓ FAQ

Q1: 基础篇为什么停在 Part 5，不连同生成式主线一起？

A: 生成式主线的基石（Part 6），概念密度陡增（语义 ID、Transformer、扩散模型）。先夯实判别式工业实践，再进生成式，认知更稳。

Q2: 召回、排序、重排必须都用深度学习吗？

A: 不一定。召回常用轻量方法（协同过滤、双塔）；排序才动用最复杂深度模型；重排可用规则或轻量模型。复杂度随候选收缩而递增。

Q3: 我该按什么顺序读？

A: 严格按 Part 1→5 顺序。后一章常以前一章为前置（如序列建模建立在特征交叉之后）。

前后关联

• Part 2 召回（2.1–2.5） 把本章「召回：从亿到千」展开为五个算法家族。
• Part 3 排序（3.1–3.5） 深入判别式打分函数 $f$ 的工业实现。
• Part 4 重排（4.1–4.2） 收尾三阶段流水线，并衔接趋势章。
• Part 5 趋势（5.1–5.3） 用「去偏 / 冷启动 / 生成式」承上启下，指向后续版本的下篇。

Practice Problems

Problem 1.2.1 — 定位章节 🟢 Easy

把下列算法拖入（写出对应 Part/章节）它在流水线中的正确位置： (a) DPP 重排　(b) YoutubeDNN 双塔　(c) DeepFM 特征交叉　(d) Swing 协同过滤

Problem 1.2.2 — 能力阶段归类 🟢 Easy

将下列技术归入「记忆 / 泛化 / 理解 / 推理」四个能力阶段之一： (a) 协同过滤共现　(b) 深度特征交叉　(c) 语义 ID（RQ-VAE）　(d) OneRec-Think 显式推理

Problem 1.2.3 — 动机追问 🟡 Medium

为什么「特征交叉」要从 FM 的二阶，演进到 xDeepFM 的自动高阶？请用一个具体例子说明：仅用二阶交叉会遗漏什么类型的模式。

🏆 Challenge: 设计你的阅读路线

假设一位同事「只会写 SQL 和简单 LR，没碰过深度学习」，但又急需两周内上手贵司的推荐排序模块。请基于本章技术地图，为他设计一份 两周学习路线 （列出每日/每阶段该读哪几章、跳过哪些、为什么），并说明理由（150 字内）。

特征与 Embedding 入门

📝 Before You Continue: 请先读完 1.1 的用户—物品—场景三元组与 1.2 的技术地图。你需要会读基础 C++，并知道哈希函数能把字符串稳定映射为整数；不要求机器学习背景。

推荐系统最终处理的不是抽象的“用户兴趣”，而是一组具体字段：性别=男、城市=北京、广告ID=10001、预估点击率=0.073。业务代码认识这些字段，但神经网络只接受数字张量。两者之间缺少一座桥。

这座桥就是 特征处理。它把原始业务字段变成 slotId + featureSign + value，再由模型服务把无语义的编号查成可学习的 Embedding 向量。这条链路看似只是数据格式转换，却决定了模型能看见什么、怎样泛化，以及训练与线上是否一致。

1.3.0 从业务字段到模型输入

一个排序请求通常同时包含四类信息：

这些可被模型利用的信息统称为 特征（Feature）。但原始值不能原样送进模型：字符串无法参加矩阵乘法；业务 ID 的数字大小没有语义；不同连续值的量纲又可能相差数十亿倍。

上图给出了完整职责边界：业务服务负责特征生成，模型服务负责查 Embedding、组合特征并完成网络计算。二者通过稳定的特征协议连接。

💡 Key Insight: 特征处理不是“把东西变成数字”这么简单。它要同时保留类别身份、数值大小和工程稳定性，并确保离线训练与在线预测看到的是同一种表达。

1.3.1 三元组：slotId / featureSign / value

工业系统常把一条特征整理为如下记录：

struct FeatureInfo {
  int slotId;              // 特征属于哪个字段或特征组
  int64_t featureSign;     // 具体取值的查表 key
  float value;             // 数值或权重
};

三个字段各管一件事：

例如，用户性别为“男”时，可以表达为：

FeatureInfo sex_feature{
  .slotId = SEX,
  .featureSign = gen_feasign_string(SEX, "男"),
  .value = 1.0F
};

它可以读成：“去 SEX 书架，找到‘男’这个取值对应的条目，本次权重为 1.0。”

连续特征的分工不同。若预估点击率为 0.073：

FeatureInfo ctr_feature{
  .slotId = AD_ETR_DENSE,
  .featureSign = 1,
  .value = 0.073F
};

这里 featureSign=1 只是固定占位，真实信息放在 value 中。先记住这个对照：

⚠️ Warning: featureSign 应被视为不透明的 64 位 key。若用 uint64_t 生成、再存入 int64_t，最高位为 1 时在常见二进制补码实现中会显示为负数。只要下游按相同位模式查表通常没有问题，但不要对它做大小比较、abs() 或带符号取模。

1.3.2 featureSign 如何生成

一种常见设计，是把 slotId 放进高 32 位，把具体取值的编号放进低 32 位：

这样，即使两个字段的低位编号碰巧相同，只要 slotId 不同，最终 key 仍然不同。

字符串取值：先哈希，再拼接

static uint64_t gen_feasign_string(
    uint64_t slot_id,
    const std::string& value) {
  const uint32_t value_hash = gen_hash_new(value.data(), value.size());
  const uint64_t slot_bits = (slot_id << 32) & 0xffffffff00000000ULL;
  return slot_bits | value_hash;
}

这段代码分三步：

1. gen_hash_new 把字符串稳定映射为 32 位整数。
2. slot_id << 32 把特征类型移到高 32 位。
3. 按位或 | 把高位类型与低位取值合成一个 key。

例如 SEX=男 与 AGE_BUCKET=20 的低位哈希即使都等于 111，最终 key 仍分别是 [SEX][111] 与 [AGE_BUCKET][111]。Slot 分段把不同字段隔离开了。

💡 Key Insight: featureSign 像“班级号 + 学号”。学号只在班级内部区分学生；高位的班级号让不同班级的相同学号不冲突。

整数取值：能直接编码就不要哈希

如果取值本来就是小整数，例如网络类型 4、星期 2 或桶编号 7，可以直接放进低 32 位：

static uint64_t gen_feasign_int32(
    uint64_t slot_id,
    uint32_t value) {
  const uint64_t slot_bits = (slot_id << 32) & 0xffffffff00000000ULL;
  return slot_bits | value;
}

只要取值能被 32 位无符号整数完整表示，这种编码没有额外的哈希冲突。因此，小枚举和桶编号应优先使用整数版本。

哈希冲突是取舍，不是异常

字符串被压进 32 位空间后，冲突无法避免。低 32 位只有 $2^{32}$ 个位置；根据生日悖论，一个 slot 内约有 7.7 万个不同取值 时，出现至少一次冲突的概率就超过 50%。

两个不同取值发生冲突后，会共享同一条 Embedding，模型无法再区分它们。为什么工业系统仍常用这种 Feature Hashing ？因为它换来了无状态、可扩展的特征生成：不需要维护巨大的字符串词表，新取值也能立即得到 key。

Analysis:

• 收益： 无需中心词表，新增取值天然可处理，线上服务可水平扩展。
• 代价： 少量语义混淆，无法从 key 反查原值，高基数特征更难调试。
• 缓解： 增大哈希空间、使用双哈希、过滤低频值，或为关键高基数 slot 维护独立词表。

1.3.3 为什么需要 Embedding

这是本章最容易混淆、也最关键的一点：

💡 Key Insight: featureSign 是查 Embedding 的 key，不是 Embedding 本身。 它负责稳定地指出“是哪一个类别”，但不负责表达这个类别与其他类别的关系。

二者的区别如下：

从 One-Hot 到 Embedding

假设 CITY 只有“北京、上海、深圳”三个取值。最直接的编码是 One-Hot：

北京 -> [1, 0, 0]
上海 -> [0, 1, 0]
深圳 -> [0, 0, 1]

One-Hot 有两个性质：第一，它不会错误地制造大小关系；第二，不同类别彼此等距。但当广告 ID 有 1000 万种取值时，一个样本需要逻辑上占据 1000 万维空间，而且向量中只有一个位置为 1。直接把这种超高维稀疏向量送进网络，参数量和计算量都难以接受。

Embedding 层可以看成一个大矩阵 $E\in {\mathbb{R}}^{N\times d}$。One-Hot 向量乘以矩阵，本质上就是从 $E$ 中选择一行：

$$\underset{N\text{ 维 One-Hot}}{\underbrace{[0,\dots ,1,\dots ,0]}}E=E_i\in {\mathbb{R}}^d$$

因此工程上不必真的构造 One-Hot。只需传入类别对应的 featureSign，直接查出 $E_i$。这既节省计算，又让模型能通过训练把行为相似的类别拉到相近的向量区域。

为什么不能直接把 featureSign 当 Embedding

假设有三个广告：

运动鞋广告 -> featureSign = 105
篮球广告   -> featureSign = 980001
婴儿奶粉   -> featureSign = 106

若直接把 sign 当成一个标量输入，模型会得到荒谬的几何关系：运动鞋 105 与奶粉 106 的距离只有 1，而与语义更接近的篮球 980001 相距近百万。这个距离完全由编号或哈希偶然决定，不代表用户行为相似度。

直接使用 sign 还有四个问题：

1. 虚假的顺序关系。 500222 > 500111 不代表某个类别“更大”或“更好”。
2. 虚假的距离关系。 两个哈希值接近，不代表两个类别相似；相差很远也不代表不相似。
3. 无法学习类别语义。 sign 是固定整数，不会在反向传播中朝“更像篮球”或“更像运动鞋”的方向移动。
4. 数值精度风险。 64 位 sign 若转成 float32，超过 $2^{24}$ 后很多相邻整数无法被精确区分，不同 key 可能被舍入成同一个浮点数。

Embedding 则为每个 key 提供一组 可训练参数。若观看篮球内容的用户经常点击运动鞋广告，训练会让这两个类别的向量逐渐靠近；奶粉广告的向量则可能位于另一片区域。类别之间的距离由数据学习，而不是由哈希值决定。

⚠️ Warning: “把 sign 转成 8 维二进制、十进制拆位或做归一化”仍然不是 Embedding。这些操作只是以另一种方式暴露任意编号，不能产生可学习的类别语义。正确做法是把 sign 当索引，查询独立的可训练向量。

一次完整的查表过程

假设 SEX=男 生成 featureSign=500111，Embedding 表当前保存：

E[500111] = [ 0.12, -0.03, 0.45]
E[500222] = [-0.21,  0.34, 0.08]

前向传播时，模型用 500111 查出第一行 [0.12, -0.03, 0.45]。若本次预测误差反向传播到这个特征，只更新 E[500111] 及相关网络参数，而不会把整数 500111 改掉。

这说明两者职责严格分离：

featureSign：稳定定位参数，训练前后保持不变
Embedding：承载可学习语义，会随训练持续更新

同一取值为什么共用一条 Embedding

两个用户都具有 SEX=男，就会生成相同的 featureSign，进而查询同一条 Embedding。这不会让两个用户变得无法区分，因为模型看到的是多个 slot 的组合：

共享反而带来泛化能力：所有男性用户的样本共同更新“男性”这条参数，而年龄、城市、身份等其他特征继续保留个体差异。

Embedding 维度由谁决定

维度不由 C++ 特征生成代码决定，而由模型配置决定，通常按 slot 或特征组设置：

维度越大，表示能力越强，但内存、通信和计算成本也越高；数据不足时还更容易过拟合。它是模型容量与系统成本之间的超参数，而不是“基数越大就无限加维度”。

1.3.4 离散特征与 Dense 特征如何编码

离散与 Dense 都可以装进 slotId + featureSign + value，但两条路径中“真正承载信息的字段”完全不同：

离散特征用 featureSign 选择“哪一行参数”；Dense 特征通常固定 sign，用 value 决定“同一组参数放大多少”。

离散特征：编码“是哪一个类别”

离散特征 的取值来自有限或可枚举集合。它们的数字形式只是身份，不应被解释为连续大小。例如网络类型 4 并不意味着它是网络类型 2 的两倍；广告 ID 10002 也不比 10001 更优。

一条离散特征通常经过五步：

1. 规范化原始值。 统一编码、大小写、空格和缺失值，例如把空城市映射为 __UNKNOWN__。
2. 选择 slot。 CITY、SEX、AD_ID 各有独立的 slotId。
3. 生成 sign。 字符串先哈希，小整数可直接编码到低 32 位。
4. 设置权重。 单值类别通常令 value=1.0。
5. 查 Embedding。 模型用 sign 选择参数表中的一行。

例 1：字符串类别 SEX=男

假设 SEX 的 slotId=12，并假设 hash("男")=0x3A91F20B，那么：

高 32 位：slotId = 12       -> 0x0000000C00000000
低 32 位：hash("男")        -> 0x000000003A91F20B
最终 sign                    -> 0x0000000C3A91F20B

业务服务生成：

const std::string normalized_sex = user.sex.empty()
    ? "__UNKNOWN__"
    : user.sex;

features.emplace_back(
    SEX,
    gen_feasign_string(SEX, normalized_sex),
    1.0F);

模型侧的处理可写成：

embedding = E_SEX[0x0000000C3A91F20B]
          = [0.12, -0.03, 0.45]
output    = 1.0 × embedding
          = [0.12, -0.03, 0.45]

这里 value=1.0 只表示“该类别本次出现”。真正区分男、女、未知的是不同的 sign，以及它们各自对应的 Embedding。

例 2：整数枚举 APN_TYPE=4

网络类型本来就是小整数，无需先转字符串再哈希：

features.emplace_back(
    APN_TYPE,
    gen_feasign_int32(APN_TYPE, 4),
    1.0F);

它会生成 [APN_TYPE][4]。与字符串版本相比，这种方式更直观，也不会引入额外的 32 位哈希冲突。

多值离散特征如何处理

“用户兴趣标签”可能同时包含 篮球、跑步、摄影。这时一个 slot 会产生多条 sign：

[INTEREST][hash(篮球)]  value=1.0
[INTEREST][hash(跑步)]  value=1.0
[INTEREST][hash(摄影)]  value=1.0

模型查出三条 Embedding 后，通常做 sum、mean、加权池化或注意力聚合。若标签数量变化很大，mean 可以避免“标签越多，向量范数越大”的偏差；若不同标签重要性不同，可以把业务权重放进 value。

Analysis:

• 优点： 不制造虚假顺序，参数可按类别独立学习，也能通过向量空间共享行为模式。
• 成本： 高基数 slot 会产生大表；低频类别的向量训练不足。
• 关键检查： 同一业务值在离线与在线必须得到完全相同的 sign。

Dense 特征：编码“具体数值是多少”

Dense 特征 是有连续大小意义的数值。CTR=0.08 确实比 CTR=0.02 大，播放 100 秒也通常比播放 10 秒更长。编码时应保留这种数值关系，而不是为每个小数创建一条独立 Embedding。

Dense 特征在不同框架里有两种常见实现：

1. 直接标量输入。 把归一化后的 $x$ 与其他向量拼接，再送入 MLP。
2. 统一 slot 协议。 使用固定 featureSign=1 查一条参数向量 $W$，输出 $xW$。

本章工程采用第二种。它在数学上等价于把一维标量通过无偏置线性层投影到 $d$ 维：

$$\text{dense\_vector}=x\times W,W=E_{slot}[1]$$

一条 Dense 特征通常经过四步：

1. 校验与兜底。 处理缺失、NaN、inf 和非法负值。
2. 变换与归一化。 根据分布选择直接使用、log1p、Min-Max、Z-Score 或分位变换。
3. 固定 sign。 该 slot 统一使用 featureSign=1，表示只需一组投影参数。
4. 把数值放入 value。 value=x，模型计算 x × E[1]。

例 1：已经归一化的 CTR=0.073

CTR 本身位于 $[0,1]$，可以先直接使用：

double ctr = ad.estimated_ctr;
if (!std::isfinite(ctr)) ctr = 0.0;
ctr = std::clamp(ctr, 0.0, 1.0);

features.emplace_back(
    AD_ETR_DENSE,
    1,
    static_cast<float>(ctr));

假设这个 slot 的固定参数向量为：

W = E_AD_ETR_DENSE[1] = [0.40, -0.20, 0.10]

那么该样本送给上层网络的向量为：

0.073 × W = [0.0292, -0.0146, 0.0073]

另一个样本若 CTR=0.20，仍查同一条 $W$，但输出变为 [0.08, -0.04, 0.02]。因此 Dense 路径保留了“0.20 比 0.073 大”的连续关系。

例 2：长尾播放时长 watch_seconds=3600

时长常呈长尾分布。直接把 3600 放进 value 会让它的量级远大于 CTR 等特征。可以先做 log1p：

double seconds = watch_seconds;
if (!std::isfinite(seconds) || seconds < 0.0) seconds = 0.0;
seconds = std::min(seconds, 86400.0);  // 顶部截断为 24 小时

const float encoded = static_cast<float>(std::log1p(seconds));
features.emplace_back(WATCH_TIME_DENSE, 1, encoded);

3600 秒被压缩为约 8.19，既保留“更长”的单调关系，也降低极端值对梯度和其他特征的支配。

📝 Note: Dense slot 中的 E[1] 有时也被口头称为“Embedding”，但它与离散类别 Embedding 的角色不同。离散 Embedding 是“每个类别一行”；Dense slot 只有固定的一行，本质上是一组可学习的投影权重。

⚠️ Warning: Dense 特征不能不加检查地塞进 value。时间戳、金额、次数等大量级值会淹没其他特征并放大梯度。必须先做量纲压缩与异常值处理。

常见处理方式：

无论采用哪种方式，都要明确 NaN、inf、缺失值和异常负值的兜底规则。min/max/\mu/\sigma、分位点和截断阈值也必须在离线训练与在线服务之间共享。

Bucket：落在哪个区间

分桶特征 先把连续值切成区间，再把桶编号当类别：

static uint32_t cut_bucket(double value, uint32_t width) {
  return static_cast<uint32_t>(value / width);
}

若 eCPM=57、桶宽为 20，则桶编号为 2。最终表达为 [AD_ECPM][2]，value=1.0。

这不是 dense 特征。它表达的是“落在哪个区间”，每个桶都有独立 Embedding，因此可以学习非单调的区间效应。

原始 cut_bucket 仍有三个工程陷阱：

1. 负值： $(-width,0)$ 内的值截断后可能悄悄落到 0 桶；更小的负值转无符号整数时可能超出可表示范围，不能依赖其结果。
2. NaN / inf： 转整数没有可用语义，可能触发未定义行为。
3. 桶宽为 0： 除零后结果无效。

更安全的实现应先校验参数、钳制异常值，并设置顶桶：

#include <algorithm>
#include <cmath>
#include <cstdint>
#include <stdexcept>

uint32_t safe_cut_bucket(
    double value,
    double width,
    uint32_t max_bucket) {
  if (!std::isfinite(width) || width <= 0.0) {
    throw std::invalid_argument("bucket width must be positive");
  }
  if (!std::isfinite(value) || value < 0.0) {
    value = 0.0;  // ← KEY LINE: 异常输入统一兜底
  }

  const double raw_bucket = std::floor(value / width);
  const double capped = std::min(raw_bucket,
                                 static_cast<double>(max_bucket));
  return static_cast<uint32_t>(capped);
}

Analysis:

• 等宽分桶： 实现简单，但长尾分布常让大多数样本挤在前几个桶。
• 等频分桶： 每桶样本更均衡，但依赖稳定的分位点统计。
• 对数分桶： 适合跨多个数量级的正值，能兼顾头部与长尾。
• 顶桶截断： 防止极端值制造大量只出现一两次的稀疏桶。

分桶与 Dense 为什么常同时使用

两者并用不是无意义重复。分桶告诉模型“处在哪个区间”，dense 告诉模型“准确是多少”。它们从不同角度表达同一个业务量。

1.3.5 Embedding 表与工程边界

表大小由唯一取值数决定

Embedding 表的主体内存可以粗略估算为：

$$\text{Memory}\approx \sum _{slot}\left(|V_{slot}|\times d_{slot}\times 4\text{ bytes}\right)$$

其中 $|V_{slot}|$ 是该 slot 的唯一 featureSign 数，$d_{slot}$ 是 Embedding 维度。实际系统还要计算哈希表元数据、key、指针和优化器状态；Adam 等优化器还可能额外保存一到两组同尺寸状态。

表大小不直接取决于请求量。十亿用户都只有三种性别时，SEX slot 仍只需要少量条目；但 GUID 本身接近“一用户一取值”，它的规模就会随用户增长。

准入、淘汰与 OOV

高基数 slot 会持续产生新 key，生产系统必须限制表增长：

“查询不到 key 时会发生什么”必须在加新特征前确认。若下游默认“随机初始化并立即写入”，一个高基数特征可能在短时间内撑大参数表；若返回零向量，则冷启动阶段该特征没有贡献，需要依赖其他可泛化特征。

Embedding 如何训练

Embedding 是推荐模型的一部分，与上层网络联合训练：

1. 前向传播根据 featureSign 查询向量。
2. 多个向量与 dense 特征拼接或池化。
3. DNN 输出点击率、转化率或排序分。
4. 预测误差反向传播，同时更新 Embedding 与网络参数。

只有被训练样本覆盖到的 key 才能得到有效更新。只出现一两次的长尾特征，其向量接近随机初始值，既占内存又可能引入噪声——这正是频次准入存在的原因。

离线与在线一致性

这是特征工程中最隐蔽、也最常见的事故来源。训练样本与线上请求必须严格对齐：

• 哈希算法、种子和字符串编码；
• slotId 枚举值及候选位置偏移；
• 分桶边界、桶宽与顶桶；
• 归一化统计量；
• 缺失值、异常值和大小写规则；
• 字符串 trim、拼接顺序和分隔符。

这类错误往往不会崩溃。服务仍能返回分数，监控也可能全绿，只是模型查到了“错误但合法”的参数，导致线上效果悄悄下降。

⚡ Pro Tip: 把改哈希、改 slot、改桶边界视为“换模型”，而不是普通代码热更新。优先让离线与在线共用同一份特征库；上线前抽取真实请求，逐字段对比两侧生成的三元组。

1.3.6 完整案例：给广告增加一个 eCPM 特征

假设业务已有 ad.ecpm，我们希望同时保留它的精确大小与非线性区间效应。合理做法是创建两个不同的 slot：

#include <algorithm>
#include <cmath>
#include <cstdint>
#include <vector>

struct FeatureInfo {
  uint32_t slot_id;
  uint64_t feature_sign;
  float value;
};

enum Slot : uint32_t {
  AD_ECPM_BUCKET = 101,
  AD_ECPM_DENSE = 102
};

uint64_t make_int_sign(uint32_t slot_id, uint32_t value_id) {
  return (static_cast<uint64_t>(slot_id) << 32) | value_id;
}

uint32_t safe_bucket(double value,
                     double width,
                     uint32_t max_bucket) {
  if (!std::isfinite(value) || value < 0.0) value = 0.0;
  if (!std::isfinite(width) || width <= 0.0) return 0;
  const double bucket = std::floor(value / width);
  return static_cast<uint32_t>(
      std::min(bucket, static_cast<double>(max_bucket)));
}

void append_ecpm_features(double raw_ecpm,
                          std::vector<FeatureInfo>& output) {
  const double clean_ecpm =
      (!std::isfinite(raw_ecpm) || raw_ecpm < 0.0) ? 0.0 : raw_ecpm;

  const uint32_t bucket = safe_bucket(clean_ecpm, 20.0, 100);
  output.push_back({
      AD_ECPM_BUCKET,
      make_int_sign(AD_ECPM_BUCKET, bucket),
      1.0F
  });

  const float dense_value =
      static_cast<float>(std::log1p(clean_ecpm));
  output.push_back({
      AD_ECPM_DENSE,
      1,
      dense_value
  });
}

输入 raw_ecpm=57 时，两条特征分别表达：

Analysis:

• 表达力： 分桶捕捉非线性，dense 保留连续变化，两者互补。
• 参数成本： 分桶 slot 最多 101 条参数；dense slot 只有一条向量。
• 一致性要求： 离线侧必须使用同样的桶宽、顶桶、log1p 与异常兜底。
• 上线检查： 对正常值、负值、NaN、极大值分别做三元组快照测试。

新增真实特征时，可以按下面清单逐项确认：

• 它是类别、连续值，还是需要“分桶 + dense”双表达？
• 字符串的编码、大小写、trim 与拼接规则是否固定？
• 小整数是否可以直接编码，避免不必要的哈希？
• Dense 值的量级、归一化和异常兜底是否明确？
• 分桶应使用等宽、等频还是对数边界？是否设置顶桶？
• 唯一取值规模与 Embedding 内存能否接受？
• 高基数 slot 是否受准入和淘汰规则约束？
• OOV 时模型服务返回什么？
• 离线训练与在线服务是否复用相同逻辑和配置？
• 上线前是否完成逐字段一致性对比？

⚠️ Common Mistakes in 1.3

本章小结

📌 Key Takeaways

❓ FAQ

Q1：为什么不能直接把 featureSign 当作 Embedding？

A：因为 sign 只是任意编号，数值大小和距离都没有业务语义，而且 64 位 sign 转成 float32 还可能丢失精度。Embedding 是按 sign 查询的一组独立可训练参数，类别之间的相似性由点击、转化等数据学习，而不是由哈希值决定。

Q2：为什么 Dense 特征也需要一个 featureSign？

A：在统一的 slot 协议中，它仍需定位该 slot 的一组权重。固定 key 意味着所有样本共享这组参数，再由不同 value 缩放。

Q3：一个连续值应该选分桶还是 Dense？

A：需要精确大小与连续变化时用 dense；关系明显非线性或需要区间效应时用分桶。重要特征常同时使用两种表达。

Q4：Embedding 表为什么不会随请求量线性增长？

A：重复出现的相同 sign 会复用同一条参数。它随“唯一取值数”增长；只有 GUID、广告 ID 等高基数 slot 才可能接近用户或物品规模。

Q5：改桶宽为什么通常需要重训模型？

A：桶宽改变后，同一个业务值会查到不同 key，对应的旧 Embedding 语义已经错位。规则变化必须与新模型一起发布。

🔗 Connections to Later Chapters

• Chapter 2.3 （双塔模型）会把用户与物品的多组 Embedding 聚合成两侧向量，再用于大规模检索。
• Chapter 3.1 （Wide & Deep）会把离散 Embedding 与连续特征送入 Deep 部分，建立排序模型的泛化能力。
• Chapter 3.2 （特征交叉）会进一步研究不同特征 Embedding 之间如何发生二阶与高阶交互。
• Chapter 6.4 （Codebook 量化与语义 ID）会展示另一种离散表示：让物品 ID 本身带上层次化语义。
• Part 11 （生成式推荐系统实战）会把离线特征生成、在线特征服务与模型部署串成完整工程链路。

Practice Problems

请按顺序完成。后面的题目会逐渐加入规模、异常值与一致性约束。

Problem 1.3.1 — 三元组分工 🟢 Easy

给定 CITY=北京 与 estimated_ctr=0.08，分别说明它们的关键信息应该放在 featureSign 还是 value 中。

Problem 1.3.2 — 判断 key 与向量 🟢 Easy

假设 hash("男") = hash("20") = 111。SEX=男 与 AGE_BUCKET=20 是否会得到相同的 featureSign？又能否把最终 sign 直接当作模型向量？

Problem 1.3.3 — 选择表达方式 🟡 Medium

你要加入“近 30 天购买金额”，分布极度长尾，既希望保留金额大小，又怀疑不同消费区间存在非单调效应。请设计特征表达。

Problem 1.3.4 — 定位静默故障 🔴 Hard

新模型离线 AUC 正常，上线后服务无报错，但效果显著下降。排查发现离线 Python 使用 value.strip().lower() 后哈希，在线 C++ 直接对原字符串哈希。解释原因并设计修复与防复发方案。

🏆 Challenge: 估算高基数特征的成本

某 AD_ID slot 有 5000 万个活跃 key，Embedding 维度为 16，使用 FP32。只计算向量本体需要多少内存？若训练时还保存两份同尺寸优化器状态，总量至少是多少？再说明实际部署为什么还会更大。

召回是「召回—排序—重排」三阶段漏斗的起点。它要在毫秒级延迟内，从亿级全量物品中快速筛出千级候选——奉行「宁可错杀，不可放过」，目标是 覆盖 而非精准。一个召回器即使效果平庸，只要漏掉了真正相关的物品，后序的排序与重排也无能为力。

本部分沿技术演进展开五个章节：从最经典的 协同过滤 到 向量召回（I2I） 、 双塔模型（U2I） ，再到 序列召回 与 流式索引 ，共同构成工业界召回层的方法图谱。各章要点见下表。

本章涵盖

What You'll Be Able to Do After This Part

• 🟢 区分 基于邻域的协同过滤（ItemCF / UserCF）与基于模型的矩阵分解，说清各自面对稀疏性的优劣
• 🟢 解释 Swing 如何利用二部图结构过滤噪声，以及 EGES 如何用注意力解决冷启动
• 🟡 推导 FM 二阶交互项的 $O(kn)$ 化简，并说明它如何被重新组织为双塔内积形式
• 🟡 对比 双塔模型与序列召回（MIND / SDM）在「用户表示」上的根本差异：单一向量 vs 多向量 / 长短期融合
• 🔴 分析 Trinity 与 Streaming VQ 如何用聚类统计与流式索引解决「兴趣遗忘」与「索引时效」问题
• 🔴 完成 5 章共 25+ 道分层练习题，巩固从共现到向量检索的全链路

核心概念

前置知识

• 已读完 Part 1 （尤其是 1.1 的三阶段漏斗与 1.2 的技术地图）
• 具备基础的线性代数（向量内积、矩阵）、概率（softmax、余弦相似度）与神经网络常识
• 了解 Python 与 Embedding 的基本概念

召回层方法偏「轻量、覆盖导向」，复杂度大多可控；但向量化方法（矩阵分解、双塔、序列）需要你熟悉 Embedding 与梯度下降。

Tips for This Part

1. 先理解「动机」再抠公式。 每个方法都为了解决前一个方法的某个局限——例如 ItemCF 被热门物品主导，于是有了 Swing；共现稀疏，于是有了矩阵分解。
2. 抓住「用户/物品如何被表示」这条主线。 从 CF 的 ID 共现，到 MF 的隐向量，到双塔的独立编码，再到序列召回的多向量，表示越来越精细。
3. 注意召回的检索效率。 凡是能在线上离线预计算物品向量（双塔、I2I）的方法，往往最容易规模化。
4. 配合可视化练习。 每章的交互式 HTML 与 SVG 都值得亲手点一遍，把抽象公式落到「候选池如何收缩」的直觉上。

Let's dive in! 🚀

协同过滤

📝 Before You Continue: 请先读完 Part 1 的 1.1 关于「召回是三阶段漏斗起点」的论述，以及 1.2 中「召回：从亿到千」的脉络。本章是召回层最经典的方法家族。

当你打开电商 App，系统如何判断「你还可能喜欢什么」？最朴素也最强大的直觉来自 协同过滤（Collaborative Filtering, CF） ：利用「人」与「物」群体的集体行为来推断个人偏好——喜欢同一个东西的人，口味往往相似；被同一群人喜欢的东西，性质往往相近。

协同过滤的思想几乎与推荐系统同龄，但它远不止「找相似」这么简单。从基于邻域的 ItemCF / UserCF，到为工业鲁棒性而生的 Swing，再到把用户与物品映射为隐向量的矩阵分解，本章带你走完这条从 统计共现 到 向量表示 的演进之路。

读完本章，你将能够：

• 用 余弦相似度 / 皮尔逊相关系数 计算物品与用户之间的相似度，并说清二者差异
• 解释 Swing 如何通过二部图结构过滤随机噪声，以及 Surprise 如何挖掘互补商品
• 说明 UserCF 与 ItemCF 在用户冷启动、可解释性上的取舍
• 描述 矩阵分解（FunkSVD / BiasSVD） 如何用低秩隐向量缓解数据稀疏性
• 完成 5 道分层练习题，巩固从共现到向量化的全链路

2.1.0 协同过滤的两大视角

协同过滤可以沿两个方向切分： 基于物品（ItemCF） 关注「和你喜欢的物品相似的还有什么」； 基于用户（UserCF） 关注「和你相似的人还喜欢什么」。前者更贴合工业场景（物品集合稳定、可离线预计算），后者在社交属性强的场景下更自然。

无论哪种视角，核心都绕不开一个概念——共现（co-occurrence） ：两个物品被同一批用户交互过，或两个用户交互过同一批物品。共现越频繁，相似度越高。后面三节我们会看到，所有 CF 方法不过是对「如何定义与利用共现」的不同回答。

2.1.1 ItemCF：基于物品相似度的协同过滤

ItemCF 的核心想法是：用户的兴趣具有连贯性，喜欢某物品的人往往也对相似物品感兴趣。当我们要给用户推荐时，系统先找出他 最近交互过的物品 （种子物品），再为每个种子找最相似的候选，最后汇总打分。

物品相似度计算

大多数真实场景只有隐式反馈（点击、购买），没有评分。ItemCF 用 余弦相似度 量化物品间相似程度：

$$w_{ij}=\frac{\mathbf{C}[i][j]}{\sqrt{|\mathcal{N}(i)|\cdot |\mathcal{N}(j)|}}$$

其中 $|\mathcal{N}(i)|$ 是与物品 $i$ 交互过的用户总数，$\mathbf{C}[i][j]$ 是两个物品的共现次数（同时交互过两者的用户数）。分母对共现次数做了标准化， 防止热门商品凭借庞大交互量占据绝对优势——这正是朴素共现的最大陷阱。

候选物品推荐

有了相似度矩阵，线上流程分三步：① 取用户最近交互的几百个物品作种子；② 为每个种子找 Top-10 相似物品，快速生成大量候选；③ 计算用户对候选物品 $i$ 的兴趣分数：

$$p(u,i)=\sum _{j\in \mathcal{N}(u)}{w}_{ij}\cdot r_{uj}$$

$\mathcal{N}(u)$ 是用户交互过的物品集合，$r_{uj}$ 是用户对物品 $j$ 的兴趣强度（简单取 1，或按交互时间/类型加权）。最后对所有候选按分数排序取 Top-N。

🧠 Mental Model: 借书人的书单

把物品想成「书」，用户想成「借书人」。ItemCF 的逻辑是：如果 Alice 借过《三体》和《球状闪电》，而 Bob 也借过《三体》，那么系统推测 Bob 大概率也会喜欢《球状闪电》——因为这两本书总是被同一批人借阅。重点不在书的内容，而在「谁在读它们」。

计算效率优化

暴力计算所有物品对相似度是 $O(|\mathcal{I}{|}^2\cdot |\mathcal{U}|)$，但绝大多数物品对没有共同用户，相似度必为 0。基于 用户-物品倒排表 可大幅提速：为每个用户维护物品交互列表，遍历时把列表内物品两两配对，累加共现矩阵 $\mathbf{C}[i][j]$，再除以标准化项。优化后复杂度约 $O(R\cdot \bar{m})$（$R$ 为总交互数，$\bar{m}$ 为用户平均交互物品数），在稀疏场景下远低于暴力计算。

处理评分数据的相似度（皮尔逊相关系数）

当系统有显式评分（如 5 星）时， 皮尔逊相关系数 比余弦更稳健，因为它通过中心化消除了物品间评分分布的差异：

$$w_{ij}=\frac{{\sum }_{u\in {\mathcal{U}}_{ij}}(r_{ui}-{\bar{r}}_i)(r_{uj}-{\bar{r}}_j)}{\sqrt{{\sum }_{u\in {\mathcal{U}}_{ij}}(r_{ui}-{\bar{r}}_i{)}^2}\sqrt{{\sum }_{u\in {\mathcal{U}}_{ij}}(r_{uj}-{\bar{r}}_j{)}^2}}$$

基于它可预测用户对未接触物品的评分：

$${\hat{r}}_{u,j}={\bar{r}}_j+\frac{{\sum }_{k\in {\mathcal{S}}_j}{w}_{jk}\left(r_{u,k}-{\bar{r}}_k\right)}{{\sum }_{k\in {\mathcal{S}}_j}{w}_{jk}}$$

在大规模系统中，出于计算与稀疏性考虑，多数仍用余弦相似度辅以加权归一化。

Analysis: ItemCF 离线可预计算全量物品相似度矩阵，线上只需取种子物品的 Top-N 相似项，延迟极低、可解释性强；但对物品冷启动无能为力（新物品没有共现），且相似度固定、难以融入上下文特征。适合物品集合稳定、交互密集的场景。

2.1.2 Swing：面向工业场景的相似度优化

ItemCF 朴素有效，但工业中暴露明显问题：热门物品因共现多而主导结果；随机误点击等噪声被一视同仁。Swing 给出优雅回答——分析用户-物品二部图的子结构来过滤噪声。

其核心洞察是： 如果多个用户在其他共同购买行为很少的情况下，同时购买了同一对物品，那么这对物品的关联更可信。 也就是说，共同购买行为的「特异性」越高，相似度贡献越大。

物品相似度计算

设 $U_i$、$U_j$ 为与物品 $i$、$j$ 交互的用户集合。对每一对共同用户 $(u,v)$，若他们其他共同购买越少（$|I_u\cap I_v|$ 越小），说明共同选择这对物品越具特异性，应贡献更高分数：

$$s(i,j)=\sum _{u\in U_i\cap U_j}\sum _{v\in U_i\cap U_j}\frac{1}{\alpha +|I_u\cap I_v|}$$

$\alpha$ 是平滑系数，防止分母过小导致数值不稳定。为降低活跃用户过度影响，引入用户权重 $w_u=1/\sqrt{|I_u|}$：

$$s(i,j)=\sum _{u\in U_i\cap U_j}\sum _{v\in U_i\cap U_j}{w}_u\cdot w_v\cdot \frac{1}{\alpha +|I_u\cap I_v|}$$

如图，用户 A、B 之间有 4 个 swing 子图 $[A,h,B]$、$[A,t,B]$、$[A,r,B]$、$[A,p,B]$。若 $\alpha =1$，且 A、B 其他共同行为数为 4，则用户对 $[A,B]$ 贡献 $1/5$；h 与 p 之间因还共享 t、r 而额外贡献两个 $1/3$，最终 $s(h,p)=13/15$ 高于 $s(h,t)=1/5$。共现少但「独家」的组合得分更高 ，这正是 Swing 过滤热门噪声的机制。

Surprise：互补商品推荐

Swing 分数已能捕捉关联，但处理互补商品（先买手机后买手机壳）仍吃力——互补关系有时序性与方向性。Surprise 算法从 类别、商品、聚类 三个层面衡量互补相关性：

• 类别层面 ：用 user-category 矩阵算类别间条件概率 ${\theta }_{i,j}=N(c_{i,j})/N(c_j)$，并用最大相对落点自适应截断长尾。
• 商品层面 ：考虑购买顺序与时间间隔，越近互补性越强：

$$s_1(i,j)=\frac{{\sum }_{u\in U_i\cap U_j}\frac{1}{1+|t_{ui}-t_{uj}|}}{\Vert U_i\Vert \times \Vert U_j\Vert }$$

• 聚类层面 ：用标签传播算法在数十亿商品图（边权为 Swing 分数）上聚类，缓解稀疏性，最终线性组合：

$$s(i,j)=\omega \cdot s_1(i,j)+(1-\omega )\cdot s_2(i,j)$$

Analysis: Swing 在保持 ItemCF 高效性的同时显著提升鲁棒性，是工业级 I2I 召回的常青树；代价是需构建与遍历二部图、计算量较朴素 ItemCF 更高。Surprise 进一步针对互补场景，但引入了多层面超参与聚类步骤，工程复杂度上升。

2.1.3 UserCF：基于用户相似度的协同过滤

与 ItemCF 镜像相对，UserCF 假设： 有相似历史行为的用户，未来偏好也相似。它先找与目标用户最像的「邻居」，再基于邻居行为预测目标用户兴趣。

用户相似度计算

给定用户 $u$、$v$ 的物品集合 $N(u)$、$N(v)$，三种常用度量：

• 杰卡德系数 （仅隐式反馈）：

$$w_{uv}=\frac{|N(u)\cap N(v)|}{|N(u)\cup N(v)|}$$

• 余弦相似度 （考虑活跃度差异）：

$$w_{uv}=\frac{|N(u)\cap N(v)|}{\sqrt{|N(u)|\cdot |N(v)|}}$$

• 皮尔逊相关系数 （有评分时，中心化消除评分习惯差异）：

$$w_{uv}=\frac{{\sum }_{i\in I}(r_{ui}-{\bar{r}}_u)(r_{vi}-{\bar{r}}_v)}{\sqrt{{\sum }_{i\in I}(r_{ui}-{\bar{r}}_u{)}^2}\sqrt{{\sum }_{i\in I}(r_{vi}-{\bar{r}}_v{)}^2}}$$

候选物品推荐

选相似度最高的 $K$ 个用户作邻居集合 ${\mathcal{S}}_u$。简单加权平均预测评分：

$${\hat{r}}_{u,p}=\frac{{\sum }_{v\in S_u}{w}_{uv}{r}_{v,p}}{{\sum }_{v\in S_u}{w}_{uv}}$$

考虑评分偏置的版本进一步消除个人习惯：

$${\hat{r}}_{u,p}={\bar{r}}_u+\frac{{\sum }_{v\in S_u}{w}_{uv}(r_{v,p}-{\bar{r}}_v)}{{\sum }_{v\in S_u}{w}_{uv}}$$

线上推荐时，为目标用户找最相似的 $K$ 个用户，收集其交互物品作候选，计算兴趣分数 $p(u,i)={\sum }_{v\in S_u\cap N(i)}{w}_{uv}\cdot r_{vi}$，排序取 Top-N。优化后复杂度约 $O(R\cdot \bar{n})$，远低于 $O(|U{|}^2)$。

Analysis: UserCF 在「新闻热点」「突发事件」等用户兴趣趋同的场景表现出色，且天然利于「发现相似人群」的社交推荐；但用户数远大于物品数时计算与存储压力大，且用户冷启动困难（新用户没有行为）。工业中 ItemCF 更常用，因其物品集合稳定、可离线全量预计算。

2.1.4 矩阵分解：从相似度到向量表示

UserCF 与 ItemCF 都面临根本性挑战： 数据稀疏性。真实交互矩阵极度稀疏，难有足够共同评分算可靠相似度。矩阵分解换了个思路——不再显式算相似度，而是学习用户与物品的 隐向量表示 ，让向量空间的距离自然反映偏好。这标志着 CF 从统计方法转向机器学习方法。

隐向量时代的开端

矩阵分解建立在两个假设上： 低秩假设——看似复杂的评分矩阵其实只受少数隐含因子（如「面向男性 vs 面向女性」「严肃 vs 轻松」）支配； 隐向量假设——每个用户/物品都能用一个包含这些因子的向量表示。

FunkSVD：基础模型

FunkSVD 把评分矩阵分解成用户特征矩阵与物品特征矩阵。用户 $u$ 用 $K$ 维向量 $p_u$ 表示，物品 $i$ 用 $q_i$ 表示，预测评分为二者内积：

$${\hat{r}}_{ui}=p_u^T{q}_i=\sum _{k=1}^K{p}_{u,k}\cdot q_{i,k}$$

优化目标让预测尽量逼近真实评分（仅对已知评分）：

$$\underset{P,Q}{\min }\frac{1}{2}\sum _{(u,i)\in \mathcal{K}}{\left(r_{ui}-p_u^T{q}_i\right)}^2$$

用梯度下降更新，误差 $e_{ui}=r_{ui}-p_u^T{q}_i$：

$$p_{u,k}\leftarrow p_{u,k}+\eta \cdot e_{ui}\cdot q_{i,k},q_{i,k}\leftarrow q_{i,k}+\eta \cdot e_{ui}\cdot p_{u,k}$$

实践中加 L2 正则防过拟合：$\min \frac{1}{2}\sum (\dots {)}^2+\lambda (\Vert p_u{\Vert }^2+\Vert q_i{\Vert }^2)$。

🧠 Mental Model: 口味坐标轴

把每个用户和每部电影画到一张二维图里：横轴是「男性向 ↔ 女性向」，纵轴是「严肃 ↔ 轻松」。喜欢《公主日记》的用户与这部电影的向量都落在「女性向、轻松」角落，内积自然大。即使两个用户没看过同一部电影，只要他们在隐因子上相近，就能互推——这就是向量表示破解稀疏性的关键。

BiasSVD：改进模型

基础模型忽略了一个事实：有人天生给高分（「老好人」），有人很严格；有的电影因明星云集普遍高分。BiasSVD 引入偏置项：

$${\hat{r}}_{ui}=\mu +b_u+b_i+p_u^T{q}_i$$

$\mu$ 是全局平均分，$b_u$ 是用户偏置，$b_i$ 是物品偏置。优化目标同步更新偏置：

$$\underset{P,Q,b_u,b_i}{\min }\frac{1}{2}\sum _{(u,i)\in \mathcal{K}}{\left(r_{ui}-\mu -b_u-b_i-p_u^T{q}_i\right)}^2+\lambda (\Vert p_u{\Vert }^2+\Vert q_i{\Vert }^2+b_u^2+b_i^2)$$

$$b_u\leftarrow b_u+\eta (e_{ui}-\lambda b_u),b_i\leftarrow b_i+\eta (e_{ui}-\lambda b_i)$$

Analysis: 矩阵分解能自然处理稀疏数据（两个用户无需共同评分也能通过隐因子关联），且内积检索高效；但它仍是线性模型，难以融入side information与复杂特征交叉。这恰好引出了后续章节的双塔与深度模型。

⚠️ Common Mistakes in 2.1

本章小结

📌 Key Takeaways

❓ FAQ

Q1: 什么时候用 ItemCF，什么时候用 UserCF？

A: 物品集合稳定、需可解释「为什么推荐这个相似物」时用品 ItemCF（工业主流）；用户兴趣高度趋同（如突发新闻）或需做社交「相似人群」推荐时用 UserCF。用户冷启动场景 ItemCF 更稳。

Q2: 余弦相似度和皮尔逊相关系数到底差在哪？

A: 余弦只看交互向量夹角，受物品绝对热度影响；皮尔逊先中心化（减去各自均值），消除「老好人 vs 严师」的评分习惯差异，关注相对趋势。有评分数据首选皮尔逊，隐式反馈用余弦。

Q3: 矩阵分解为什么比 ItemCF 更能应对稀疏数据？

A: ItemCF 需要两物品有共同交互用户才能算相似；矩阵分解通过共享的隐因子空间，让两个无共同评分的用户也能因隐向量相近而互推，泛化到未见组合。

前后关联

• 2.2（向量召回 I2I） 把序列建模（Word2Vec）迁移进相似度学习，并用品注意力解决 MF 难融 side info 的问题。
• 2.3（双塔模型） 将 MF 的内积思想升级为深度网络编码，实现高效 U2I 检索。
• 2.4（序列召回） 进一步捕捉 ItemCF/MF 忽略的时序兴趣动态。
• 3.x（排序） 后续用复杂深度模型对本章召回的千级候选精排。

Practice Problems

Work through all problems in order — they get progressively harder. Each has a complete solution you can reveal after trying it yourself.

Problem 2.1.1 — 相似度标准化 🟢 Easy

用户 A 交互过 100 个物品，用户 B 交互过 10 个物品，他们共同交互了 5 个物品。请计算杰卡德系数，并说明若改用「原始共现数 = 5」作相似度会有什么问题。

Problem 2.1.2 — ItemCF 打分 🟢 Easy

用户 $u$ 交互过物品 $\{j_1,j_2\}$，对它们的兴趣强度 $r_{u{j}_1}=1$、$r_{u{j}_2}=0.5$。物品 $i$ 与 $j_1$ 相似度 $0.8$、与 $j_2$ 相似度 $0.3$。求用户对候选物品 $i$ 的兴趣分数 $p(u,i)$。

Problem 2.1.3 — Swing 的特异性直觉 🟡 Medium

考虑两对物品 $(h,p)$ 与 $(h,t)$。用户 A、B 都交互过它们，且 A、B 的其他共同行为数分别为 4（对 h,p）和 2（对 h,t）。设 $\alpha =1$，且 $(h,p)$ 只有这一对共同用户、$(h,t)$ 除此之外还被另一对共同用户 C、D 以相同结构贡献。请比较 $s(h,p)$ 与 $s(h,t)$，并解释 Swing 想过滤什么。

Problem 2.1.4 — FunkSVD 梯度更新 🔴 Hard

给定已知评分 $r_{ui}=4$，当前 $p_u=[0.5,0.2{]}^T$、$q_i=[1.0,0.5{]}^T$，$\eta =0.1$，无正则。请手算一步梯度下降后的 $p_u$、$q_i$（保留 3 位小数）。

🏆 Challenge: 设计一个召回组合

某短视频平台日增千万物品，长尾内容极多。请写一段约 150 字，说明你会如何 组合 本章的 ItemCF、Swing 与矩阵分解作为多路召回（各路负责什么、如何互补），并指出长尾新物品应由哪路兜底、为什么。

向量召回 (I2I)

📝 Before You Continue: 建议先读完 2.1 的 ItemCF 与矩阵分解。本章是「把物品当作向量」思路的自然延伸——区别在于，相似度不再由共现统计得出，而由序列建模学到的稠密向量决定。

2.1 的协同过滤靠「谁和谁一起被交互」来定义相似。但如果一个物品几乎没被交互过（新品冷启动），共现统计就失效了。更根本地：共现只告诉你「相关」，却没把物品编码成语义向量，难以进一步融合属性、做近邻检索。

本章的主角是 Word2Vec 的序列建模思想。它有一个简单而深刻的假设： 在相似语境中出现的词，含义也相似。当我们把「句子」替换为「用户的行为序列」，把「词」替换为「物品」，同一套方法就能学到「语义相近、向量相近」的物品表示，用于 I2I 召回。从最直接的 Item2Vec 迁移，到融合属性的 EGES，再到把业务目标写进序列的 Airbnb——你会看到这条线如何一步步贴近工业真实。

读完本章，你将能够：

• 解释 Word2Vec Skip-Gram 的核心公式，以及 负采样 为何不可或缺
• 描述 Item2Vec 如何把「用户行为序列 = 句子」的映射用于 I2I 向量召回
• 说明 EGES 的商品特定注意力如何解决冷启动与稀疏性
• 分析 Airbnb 的全局上下文与同市场负采样如何把「预订转化」融入训练
• 完成 5 道分层练习题，巩固序列建模召回

2.2.0 从词语到物品：一个结构性的类比

Word2Vec 的成功建立在「共现反映语义」之上。在自然语言里，一个句子由词组成，词间共现反映语义；在推荐里，一个用户的交互历史可看作「句子」，其中的物品就是「词」。这就是 Item2Vec 的全部出发点——结构同构，迁移即用。

下面四节我们会看到，这个看似简单的映射，如何支撑起一整个 I2I 向量召回家族。

2.2.1 Word2Vec：序列建模的理论基础

📎 本节只讲 Skip-Gram 的直觉与它在推荐里的迁移。要补 CBOW 架构、中心词/上下文双向量表 $\mathbf{W}$/${\mathbf{W}}^c$ 的结构细节、负采样精确形式与词向量类比性质，见 附录 · Word2Vec 专题。

Word2Vec 包含两种架构： Skip-Gram （用中心词预测上下文）与 CBOW （用上下文预测中心词）。推荐中 Skip-Gram 表现更好，采用更广。

Skip-Gram 模型

给定序列中位置 $t$ 的中心词 $w_t$，模型最大化其窗口内（大小 $m$）所有上下文词的出现概率：

$$P(w_{t+j}|w_t)=\frac{e^{v_{w_{t+j}}^T{v}_{w_t}}}{{\sum }_{k=1}^{|V|}{e}^{v_{w_k}^T{v}_{w_t}}}$$

$v_{w_i}$ 是词 $w_i$ 的向量，$|V|$ 是词表。Softmax 保证概率和为 1，分子内积衡量中心词与上下文词的相似度。

🧠 Mental Model: 猜邻居的游戏

想象你在玩「我说一个词，你猜它旁边可能是什么词」。听到「国王」，你大概率猜「王后」「城堡」。Skip-Gram 就是让模型玩这个游戏：它不问「这两个词是否共现」，而是问「给定中心词，周围最可能是哪些词」——通过反复猜，模型被迫把语义相近的词放到向量空间里相近的位置。

负采样优化

直接算 Softmax 分母需遍历整个词表，代价过高。负采样把多分类转为多个二分类：

$$\log \sigma (v_{w_{t+j}}^T{v}_{w_t})+\sum _{i=1}^{n_{\mathrm{neg}}}{\mathbb{E}}_{w_i\sim P_n(w)}\log \sigma (-v_{w_i}^T{v}_{w_t})$$

其中 $\sigma (x)=1/(1+e^{-x})$，$n_{\mathrm{neg}}$ 是负样本数。直觉是：对真实词对 抬高 相似度，对随机采样的负样本词对 压低 相似度。这一范式正是后续推荐模型训练的技术基石。

Analysis: Skip-Gram + 负采样高效、可扩展，是直接迁移到推荐的理论原型；但它本身处理的是「词」，需要把「用户行为序列」正确映射为训练语料才能用于推荐。

2.2.2 Item2Vec：最直接的迁移

Item2Vec 的核心洞察，就是上一节的「结构同构」：把用户交互历史视作「句子」，物品视作「词」。

模型实现

Item2Vec 直接采用 Word2Vec 的 Skip-Gram，但序列构建更简化——将每个用户的交互历史视为一个 集合 而非序列， 忽略时序权重 （窗口仍依赖按时间排序后的位置 $i+j$，只是不再给不同位置不同的权重）。目标函数保持一致：

$$\mathcal{L}=\sum _{s\in \mathcal{S}}\sum _{l_i\in s}\sum _{-m\le j\le m,j\ne 0}\log P(l_{i+j}|l_i)$$

其中 $l_i$ 是物品，$m$ 是窗口大小，$P(l_{i+j}|l_i)$ 用与 Word2Vec 相同的 Softmax 形式。训练后每个物品得到稠密向量，可做近邻检索实现 I2I 召回。

Analysis: Item2Vec 实现极简（几行 gensim 调用即可），验证了序列建模在推荐的可行性；但它把历史当无序集合、丢失时序，且对新物品冷启动无能为力——没有交互就没有向量。这两点正是 EGES 的改进动机。

2.2.3 EGES：用属性信息增强序列

Item2Vec 把交互史当无序集合、且对冷启动无力。EGES（Enhanced Graph Embedding with Side information）用两个创新解决： 会话级图 更好地反映行为模式， 融合辅助信息 解决稀疏与冷启动。

构建商品关系图

EGES 用「一小时时间窗」切分会话，只在窗口内的连续行为间建 有向边 ，边权为转移频率。相比把整段历史当一条序列，这更准地捕捉特定时段的连续兴趣转移。在图上用 带权随机游走 生成训练序列，转移概率由边权决定：

$$P(v_j|v_i)=\{\begin{array}{ll}\frac{M_{ij}}{{\sum }_{j=1}^{|N_{+}(v_i)|}{M}_{ij}}& \text{if }{v}_j\in N_{+}(v_i)\\ 0& \text{if }{e}_{ij}\notin E\end{array}$$

融合辅助信息

纯行为序列对稀疏物品学不好。GES 先用简单平均聚合物品 ID 向量与各属性向量：

$$H_v=\frac{1}{n+1}\sum _{s=0}^n{W}_v^s$$

$W_v^s$ 是第 $s$ 种属性的向量，$W_v^0$ 是物品 ID 向量。但平均假设所有属性同等重要，显然不成立（手机看品牌、日用品看价格）。

EGES 的核心创新 是商品特定注意力——为每个物品学一组权重，强调更重要的属性：

$$H_v=\frac{{\sum }_{j=0}^n{e}^{a_v^j}{W}_v^j}{{\sum }_{j=0}^n{e}^{a_v^j}}$$

$a_v^j$ 是可学习权重。对 冷启动新物品 ，没有行为序列与训练好的 $a_v^j$，EGES 退化为对属性向量做 mean pooling，直接获得有意义表示，从而能被纳入 I2I 召回。

训练用类似 Word2Vec 的负采样，损失：

$$L(v,u,y)=-[y\log (\sigma (H_v^T{Z}_u))+(1-y)\log (1-\sigma (H_v^T{Z}_u))]$$

Analysis: EGES 用 side info 显著缓解稀疏与冷启动，在十亿级数据上效果优于传统方法；代价是需维护 $|V|\times (n+1)$ 的注意力参数矩阵，工程与存储成本上升。它是工业 I2I 召回中「兼顾行为与内容」的代表。

2.2.4 Airbnb：将业务目标融入序列

Airbnb 作为短租平台，房源非标品、预订比点击稀疏、地理位置关键，且更需促进 最终预订转化 而非单纯相似。它重新定义了「序列」。

面向业务的序列构建

• 会话切分 ：用户点击间隔超 30 分钟即开新会话，更准捕捉特定搜索场景的连贯意图。
• 行为权重差异化 ：最终预订比简单点击含更强的偏好信号，训练中应给更高权重。

全局上下文机制

传统 Skip-Gram 只看滑动窗口内的局部上下文。Airbnb 让 用户最终预订的房源 $l_b$ 与序列中每个浏览房源形成正样本对，无论距离多远：

$$\underset{\theta }{\mathrm{argmax}}\sum _{(l,c)\in {\mathcal{D}}_p}\log \frac{1}{1+e^{-v_c^T{v}_l}}+\sum _{(l,c)\in {\mathcal{D}}_n}\log \frac{1}{1+e^{v_c^T{v}_l}}+\log \frac{1}{1+e^{-v_{l_b}^T{v}_l}}$$

前两项是标准 Skip-Gram（正/负样本），第三项 $\log \frac{1}{1+e^{-v_{l_b}^T{v}_l}}$ 是创新——预订房源为序列中每个房源提供额外学习信号，让模型捕捉「怎样的房源组合最终会导致预订」。

市场感知的负采样

用户通常只在同市场（城市/地区）预订。若负样本来自异地，模型易学「地理位置」这种简单特征而忽略房源本身差异。Airbnb 让部分负样本来自 相同市场 ：

$$\sum _{(l,l_m^{-})\in {\mathcal{D}}_m}\log \frac{1}{1+e^{v_{l_m^{-}}^T{v}_l}}$$

这迫使模型学同地区内房源的细微差别，提升精细度。

Analysis: Airbnb 把「业务转化」与「地理约束」直接写进训练目标，是「业务目标驱动序列构建」的典范；但它高度领域定制（会话阈值、市场划分需按业务调参），通用性弱于 EGES。

⚠️ Common Mistakes in 2.2

本章小结

📌 Key Takeaways

❓ FAQ

Q1: Item2Vec 和 Word2Vec 本质区别是什么？

A: 架构与目标函数完全一样，区别仅在外语料——Item2Vec 把用户交互历史当「句子」、物品 ID 当「词」，且默认把历史当无序集合（丢时序）。Word2Vec 处理的是真实文本序列。

Q2: EGES 的注意力权重和 Transformer 注意力是一回事吗？

A: 不完全是。EGES 的注意力是「同一物品多种属性源之间的加权聚合」（静态、 per-item），用于得到单个物品向量；Transformer 注意力是序列内 token 间的动态交互。二者都叫 attention，但作用层面不同。

Q3: 为什么 Airbnb 要加全局上下文，而不只靠滑动窗口？

A: 滑动窗口只看局部邻居，会漏掉「最终预订」这一最强正信号（它可能离浏览房源很远）。全局上下文让预订房源与每个浏览房源都成对，强化「什么组合导致转化」的学习。

🔗 前后关联

• 2.3（双塔模型） 用深度网络编码用户/物品向量，把 I2I 的「物品向量」升级为「用户-物品联合向量」做 U2I 检索。
• 2.4（序列召回） 显式建模时序（LSTM/胶囊），弥补 Item2Vec 丢时序的缺陷。
• 2.5（流式索引） 用聚类与流式 VQ 组织海量向量索引，承接本章学到的物品向量。

Practice Problems

Work through all problems in order — they get progressively harder. Each has a complete solution you can reveal after trying it yourself.

Problem 2.2.1 — 负采样直觉 🟢 Easy

Skip-Gram 的 Softmax 分母需遍历整个词表 $|V|$。在推荐里物品库可能有上亿。请用一句话说明负采样解决了什么，并写出它把原目标改成了什么形式的任务。

Problem 2.2.2 — Item2Vec 映射 🟢 Easy

请把下列文本世界概念映射到推荐世界：(a) 词语 (b) 句子 (c) 词语共现。并说明 Item2Vec 训练后如何用于 I2I 召回。

Problem 2.2.3 — EGES 注意力 🟡 Medium

EGES 对物品 $v$ 有 $n$ 种属性加 ID 共 $n+1$ 个向量，注意力权重为 $a_v^j$。给出最终向量 $H_v$ 的公式，并解释：若某手机的「品牌」权重远高于「价格」，mean pooling（GES）会损失什么？

Problem 2.2.4 — Airbnb 全局上下文 🔴 Hard

Airbnb 目标函数第三项 $\log \frac{1}{1+e^{-v_{l_b}^T{v}_l}}$ 中，$l_b$ 是预订房源、$l$ 是序列中某浏览房源。请说明：当 $v_{l_b}^T{v}_l$ 很大（语义相近）时该项对损失的贡献如何变化？这如何帮助模型学到「导致预订的组合」？

🏆 Challenge: 设计冷启动 I2I 方案

某平台每天上新 10 万件商品，其中 80% 上架首周交互不足 5 次。请写约 150 字，说明你会如何用本章方法（Item2Vec / EGES / Airbnb 任选组合）搭建一套 I2I 召回，使新品也能在被交互极少时就被召回，并指出必须与哪类数据配合。

双塔模型 (U2I)

📝 Before You Continue: 请先读完 2.1 的矩阵分解与 2.2 的 Item2Vec。本章把「内积」思想从物品-物品升级为用户-物品，并用深度网络编码两侧表示，是工业 U2I 召回的主干。

前两节你学到的物品向量（Item2Vec / EGES）做的是 I2I 召回——先有种子物品，再找相似物。但线上召回的起点往往不是「物品」而是「用户」：给定一位用户，直接从亿级物品库里捞出他可能感兴趣的。这就需要 用户表示 与 物品表示 在同一空间里各自编码，再用内积检索——这就是 双塔模型（Two-Tower）。

它的工程魅力在于「分而治之」：物品侧塔可以 离线预计算 并存入近邻索引（ANN），用户侧塔 实时计算 ，线上只需一次向量检索。从 FM 的数学雏形，到 DSSM 的深度编码，再到 YouTubeDNN 的「预测下一个观看」，本章带你走完双塔的演进，并用交互演示直观感受检索过程。

读完本章，你将能够：

• 推导 FM 二阶交互项 从 $O(k{n}^2)$ 到 $O(kn)$ 的化简，并说明它如何重组为双塔内积
• 解释 DSSM 的极端多分类训练、向量归一化与温度系数的作用
• 描述 YouTubeDNN 的「非对称双塔」与「时序分割」等工程技巧
• 用交互演示理解双塔召回的「离线建库 / 实时查用户」流程
• 完成 5 道分层练习题，巩固双塔的表示与检索

2.3.0 为什么需要双塔：从 I2I 到 U2I

I2I 召回依赖「用户已交互过某物品」作种子。但很多场景下，用户刚注册、或我们要在他 还没动作时 就推内容。U2I 直接以用户自身（画像 + 行为）为查询，从全库检索候选：

双塔的核心约定是： 两侧塔在训练时几乎不交互，只在最后一步算内积。这换来了宝贵的工程性质——物品向量可离线一次性算好入库，用户向量在线现算，检索成本极低。

2.3.1 FM（因子分解机）：双塔模型的雏形

FM 诞生于深度学习之前，却在思想上预示了双塔。它把用户-物品复杂交互优雅分解为两个低维向量的内积。完整表达式：

$$\hat{y}(\mathbf{x})=w_0+\sum _{i=1}^n{w}_i{x}_i+\sum _{i=1}^n\sum _{j=i+1}^n⟨{\mathbf{v}}_i,{\mathbf{v}}_j⟩x_i{x}_j$$

每个特征 $i$ 对应 $k$ 维隐向量 ${\mathbf{v}}_i$，交互通过内积 $⟨{\mathbf{v}}_i,{\mathbf{v}}_j⟩={\sum }_{f=1}^k{v}_{i,f}{v}_{j,f}$ 建模。

计算复杂度化简

原本 $O(n^2)$ 的二阶项可重写为：

$$\sum _{i=1}^n\sum _{j=i+1}^n⟨{\mathbf{v}}_i,{\mathbf{v}}_j⟩x_i{x}_j=\frac{1}{2}\sum _{f=1}^k\left({\left(\sum _{i=1}^n{v}_{i,f}{x}_i\right)}^2-\sum _{i=1}^n{v}_{i,f}^2{x}_i^2\right)$$

复杂度从 $O(k{n}^2)$ 降到 $O(kn)$，使 FM 能处理大规模稀疏数据。

🧠 Mental Model: 拼积木的隐向量

把每个特征想成一块积木，每块积木藏着一根小指针（隐向量）。两个特征是否「合得来」，不看积木本身，只看两根指针指的方向是否一致（内积大=合得来）。FM 的妙处是：不用真的两两试遍，靠「指针平方和减平方平方和」一次算完所有配对。

分解为双塔结构

召回场景下，特征分两类：用户侧 $U$ 与物品侧 $I$。为同一用户推荐不同物品时， 用户特征内部的交互得分对所有候选相同，排序时可忽略。只保留：物品内部交互 + 用户-物品交互。重排后：

$${\text{score}}_{FM}=\sum _{t\in I}{w}_t{x}_t+\frac{1}{2}\sum _{f=1}^k\left({\left(\sum _{t\in I}{v}_{t,f}{x}_t\right)}^2-\sum _{t\in I}{v}_{t,f}^2{x}_t^2\right)+\sum _{f=1}^k\left(\sum _{u\in U}{v}_{u,f}{x}_u\sum _{t\in I}{v}_{t,f}{x}_t\right)$$

观察最后一项——它恰是两个向量的内积 ${\sum }_{u\in U}{v}_u{x}_u$ 与 ${\sum }_{t\in I}{v}_t{x}_t$。于是：

$${\text{score}}_{FM}=V_{item}\cdot V_{user}^T$$

• 用户向量：$V_{user}=[1;{\sum }_{u\in U}{v}_u{x}_u]$
• 物品向量：$V_{item}=[{\sum }_t{w}_t{x}_t+\frac{1}{2}{\sum }_f(({\sum }_t{v}_{t,f}{x}_t{)}^2-{\sum }_t{v}_{t,f}^2{x}_t^2);{\sum }_t{v}_t{x}_t]$

Analysis: FM 用线性代数把特征交叉转为双塔内积，物品向量可离线预计算，是双塔思想的理论雏形；但它是线性模型，对复杂非线性用户-物品关系表达力有限——这正是 DSSM 用深度网络接棒的原因。

2.3.2 DSSM：深度结构化语义模型

DSSM 用 深度神经网络 替代 FM 的线性变换，把用户与物品映射到共同语义空间，相似度由向量间距离衡量。

推荐中的双塔架构

DSSM 含独立的两个 DNN 塔：用户塔处理用户特征（行为、人口统计），输出用户 Embedding；物品塔处理物品特征（ID、类目、属性），输出物品 Embedding。两塔 Embedding 维度必须一致。相比 FM 的线性组合，DSSM 让两侧特征各自在塔内做复杂非线性变换， 两塔交互仅发生在最终内积。物品向量离线预计算、用户向量实时计算，经 ANN 完成召回。

多分类训练范式

DSSM 把召回视为极端多分类：物料库所有物品都是类别，目标是最大化用户对正样本的预测概率：

$$P(y|x,\theta )=\frac{e^{s(x,y)}}{{\sum }_{j\in M}{e}^{s(x,y_j)}}$$

$M$ 是整个物料库。因库过大，实际用负采样近似。

双塔的关键细节

向量归一化 ：对两侧 Embedding 做 L2 归一化 $u\leftarrow u/\Vert u{\Vert }_2,v\leftarrow v/\Vert v{\Vert }_2$。原始点积不满足三角不等式，会致「距离」不一致。归一化后点积等价于欧式距离：

$$\Vert u-v\Vert =\sqrt{2-2⟨u,v⟩}$$

关键是 训练与检索的一致性——训练用的（归一化点积）与线上 ANN 用的（欧式距离）本质等价，避免训练-服务不一致。

温度系数调节 ：归一化内积再除以 $\tau$：

$$s(u,v)=\frac{⟨u,v⟩}{\tau }$$

$\tau <1$ 放大相似度差异（更「确定」），$\tau >1$ 使分布更平滑（更保守）。它本质是缩放 logits、改变 Softmax 输出形状。

Analysis: DSSM 的表达力来自深度非线性，工程优势来自「离线物品塔 + 在线用户塔」。归一化与温度是上线必调的两个旋钮——前者保证检索一致性，后者控制召回的「集中度」。代价是双塔「晚期交互」损失了部分细粒度特征交叉信号。

2.3.3 YouTubeDNN：从匹配到预测用户下一行为

YouTubeDNN 是双塔演进的里程碑。它延续双塔，但引入关键转变：把召回定义为「预测用户下一个会观看的视频」，类似 NLP 的 next-token 预测。

非对称双塔架构

用户塔集成观看历史、搜索历史、人口统计等多模态信息，视频 ID 经嵌入后平均池化聚合，并引入 Example Age 特征建模内容新鲜度；物品塔则相对简化——本质是一个巨大嵌入矩阵，每视频一个可学向量，避免复杂物品特征工程。目标为极端多分类：

$$P(w_t=i|U,C)=\frac{e^{v_i\cdot u}}{{\sum }_{j\in V}{e}^{v_j\cdot u}}$$

因视频库庞大，用 Sampled Softmax 高效训练。

关键的工程技巧

• 非对称的时序分割 ：不用随机验证，而用「回滚」——预测目标只看其 之前 的历史，避免未来信息泄露（符合真实推荐场景，剧集按顺序看）。
• 负采样策略 ：重要性采样，每次只对数千负样本计算，提速 100 多倍。
• 用户样本均衡 ：每用户生成固定数量训练样本，避免高活跃用户主导学习，对长尾用户效果关键。

Analysis: YouTubeDNN 建立了「可扩展、可工程化」的双塔范式：训练用复杂多分类目标 + 丰富用户特征，服务时预计算物品向量、实时算用户向量、配 ANN 检索。非对称设计让物品塔保持简洁（易离线建库），用户塔可灵活扩展——这一平衡至今被广泛借鉴。

2.3.4 交互演示：双塔召回的检索过程

下面用交互演示感受双塔召回的核心流程：物品塔 离线 把所有物品编码进向量索引；线上来了一位用户，用户塔 实时 编码其向量，再用近邻检索从索引里捞出最相似的 Top-K 候选。点击「下一步」观察每一步。

注意第三步「检索」：它不遍历全库逐一算分，而是用 ANN 在近邻空间直接定位——这正是双塔能在毫秒级服务亿级物品的根本原因。归一化让内积等价于欧式距离，温度系数则控制检索的集中程度。

📊 Data Point: 在 funrec 评测集上，FM 召回 hit_rate@10≈0.047、DSSM≈0.016、YouTubeDNN≈0.013。数值差异主要来自数据集与特征配置，不代表模型优劣——DSSM/YouTubeDNN 在更丰富特征与更大规模上通常更优。

⚠️ Common Mistakes in 2.3

本章小结

📌 Key Takeaways

❓ FAQ

Q1: 为什么双塔「晚期交互」反而是优点？

A: 因为物品向量可完全离线算好、建索引，线上只算用户向量 + 一次 ANN 检索。若塔间早期交互（如特征交叉），物品向量就依赖具体用户，无法预计算，失去规模化能力。

Q2: 温度系数 τ 调大调小分别有什么效果？

A: τ<1 放大相似度差异，模型更「自信」、召回更集中（易扎堆头部）；τ>1 平滑分布、更保守、候选更分散。是平衡精准与多样的旋钮。

Q3: FM 和 DSSM 都用内积，区别在哪？

A: FM 的向量由线性组合 + 固定隐向量得到（线性模型）；DSSM 的向量由深度网络非线性变换得到（表达力更强），且显式处理归一化与采样训练。

前后关联

• 2.4（序列召回） 把用户表示从「单一向量」升级为「多向量 / 长短期融合」，弥补双塔单向量丢时序的不足。
• 2.5（流式索引） 承接双塔产出的物品向量，组织成可实时更新的流式索引。
• 3.x（排序） 排序侧可用更复杂的「早期交互」模型（如特征交叉），与双塔晚期交互互补。

Practice Problems

Work through all problems in order — they get progressively harder. Each has a complete solution you can reveal after trying it yourself.

Problem 2.3.1 — FM 复杂度化简 🟢 Easy

FM 二阶交互项原始形式需对 $n$ 个特征两两组合，复杂度为 $O(k{n}^2)$。请写出化简后形式，并说明为何它只需 $O(kn)$。