系统设计 Lab
推荐系统是一个 funnel：廉价的 retrieval 把数百万 item 收窄到几百个，然后一个昂贵的 ranker 给幸存者打分。
调节用户数、catalog 大小、请求速率、每请求 retrieve 的 candidate 数、ranking 模型延迟、embedding 维度和 feature 数量。设计会从一个 popularity list，走到 collaborative filtering，再到带 ANN retrieval 的 two-tower embedding，然后是由 feature store 支撑的 ranking model，最后到 real-time feature 和规模化的完整 multi-stage serving。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
客户端
Client 请求一个排好序的列表，并发出点击、观看等交互
Serving API
Serving API 在 latency budget 内把一个请求扇过 retrieval、ranking 和 re-ranking
Re-ranker 在返回前给排好序的列表施加业务规则、diversity 和新鲜度
Retrieval
Two-tower model 把 user query 嵌入成向量，好按距离找到相似的 item 向量
ANN search 在数百万 item 上以毫秒级找到近似最近邻的 item 向量
Ranking
Ranking model 用一个重型模型、借助大量 user-item feature 给每个 candidate 打分
Feature store 低延迟地为每个 user-item pair 提供预计算和实时的 feature
存储
Item index 保存 item embedding 和 metadata，随 catalog 增长做 shard
Feature DB online feature store 背后的 batch 和 streaming feature 的 durable 存储
训练回路
Interaction log 在 hot path 之外捕获 impression 和参与度，供训练和实时 feature 使用
Training job 从记录的交互里重建 embedding 和 ranking model
瓶颈
Retrieval 扫描成本
Ranking 计算
Feature-store 负载
Item index 内存
端到端延迟预算
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
Sampling-Bias-Corrected Neural Modeling (Yi et al., 2019)
分开的 user tower 和 item tower 产出 embedding，其点积近似相关性，于是 retrieval 就变成在预计算好的 item 向量上做 nearest-neighbor 搜索。
Google ResearchANN 搜索让 nearest-neighbor retrieval 扩展到数十亿向量
approximate nearest neighbor 库（ScaNN、FAISS）和 vector database 用一点点 recall 换来快几个数量级的相似度搜索，正是这点让 retrieval 能在毫秒内扫过一个巨大的 catalog。
ScaNN (Google Research)feature store 在 online 和 offline 提供同一套 feature
feature store 为 serving 提供低延迟的 online feature lookup，为训练提供一致的历史 feature，从而避免 training/serving skew。
Feast大规模推荐是分阶段的：先 candidate generation 再 ranking
经典模式是先用一个廉价的 retrieval 阶段把巨大的 item 集合收窄，再让更昂贵的 ranking 阶段给幸存者打分，于是重型计算只触及几百个 item。
System Design Primer教学用假设
- retrieval 成本被建模成一次 per-request 扫描，ANN 把它从随 catalog 大小线性变成大致对数级，所以 brute force 只在小 catalog 上还活得下去。
- 每台 server 的 ranking throughput 会随模型延迟和 feature 数量下降；这些数字是保守的教学预算，不是厂商 benchmark。
- feature-store 负载按每请求每 candidate 每 feature 一次 lookup 来算，是 batching 和 caching 之前的最坏情况。