刷到一条好内容，看起来只是“模型猜你喜欢”。但打分之前，系统就已经决定了去哪里找、哪些内容有资格出现；打分以后，还得把候选（candidate）排成一屏。
这一组先跟着一次刷新，看候选怎样被找出、打分，再组成一屏。之后再回来看：为什么把计算分成这几步，换一种模型或索引会影响什么。
先分清请求、更新和训练
下面用一套教学架构说明 3 条路径，不是 Twitter / X 的线上部署图。先看“用户刷新”，再切到“内容更新”和“模型训练”，比较哪些步骤不需要每次请求都重做。在线路径里还可以模拟超时和过滤，看看为什么候选会变少。
先记住：一个框不一定是一台独立服务；更新内容向量，也不等于重新训练模型。 架构导读会展开这两个区别。
按你现在的问题来读
第一次读，建议按 架构导读 → 01 → 02 → 03 → 05 走一遍。之后用 04 对照新方法，用 06–08 深挖设计。不必一次把所有代码读完。
每一期解决一个问题
| 章节 | 这次要想清楚什么 | 读完试着做什么 |
|---|---|---|
| 00 · 架构导读 | 请求、更新、学习怎样接在一起？ | 标出每个组件何时运行、交出什么 |
| 01 · 一次刷新 | 为什么推荐不是一个模型？ | 追踪一条候选的来源、特征和去向 |
| 02 · 多路召回 | 多加一路到底补了什么？ | 固定预算，检查独有相关候选 |
| 03 · 排序与列表 | 单条不错，为什么一屏仍然无聊？ | 拖动惩罚权重，区分模型分数和列表选择 |
| 04 · 新方法放在哪 | Transformer、生成式检索（retrieval）替换了哪一层？ | 把新模型放回架构，而不是只记名字 |
| 05 · 评估实验 | 分数变了，模型一定变了吗？ | 切换候选池、Top-K 和分母 |
| 06 · 为什么是双塔 | 省掉什么计算，放弃什么交互？ | 比较一条混合查询与分开查询 |
| 07 · 组件怎么选 | 同一个框有哪些合理实现？ | 先写约束，再写方案与退出条件 |
| 08 · 工程落地 | 接口成功，为什么结果仍可能错？ | 检查版本、超时、新鲜度（freshness）与回滚 |
每篇都会比较可选方案，也会算一笔计算、延迟或候选预算。实验用的是小型教学数据，帮助理解机制；真实用户是否喜欢这些结果，还需要另外验证。
用到了哪些公开资料
| 材料 | 怎么用 | 不据此推断什么 |
|---|---|---|
| Twitter 2023 · ee5e7fc | 01–03 的公开组件阅读 | 今天 X 的完整线上架构 |
| X 公开快照 · 77d431a | 04 的版本对照，核验于 2026-09-30 | 真实训练数据、所有实验配置或生产收益 |
| 官方论文与工程资料 | 比较不同设计的前提 | 某一家公司的做法代表唯一答案 |
| 本站架构图、代码与交互 | 用虚构数据检查机制 | 任何公司的业务结果或内部实现 |
版本固定在链接里，不把不同时期的模块偷偷拼成一套“最新系统”。这里不使用内部项目、私有数据或非公开面试材料。
想先自己画一版，可以做推荐 Feed 练习；对向量还不熟，先读向量与相似度。
本页术语 3
- 候选 candidate
- 召回阶段捞出来、等待精排挑选的内容
- 检索 retrieval
- 从外部语料里找出相关内容
- 新鲜度 freshness
- 内容产生到可被检索之间的延迟