行业范式:经典级联漏斗

先建立参照系。今天各家信息流产品 —— 抖音/TikTok、小红书、YouTube、Instagram Reels —— 的推荐系统,基本都收敛到同一套级联排序架构(cascade ranking):用一层比一层重的模型,把候选量级一级级压下来,让最贵的模型只算最少的帖子。下面这块面板把「量级」和「延迟」放在同一个状态里:上半是漏斗(每层看到多少条),下半是同一状态下的延迟瀑布(每步花多少毫秒)。我们的主角是一条叫 №4711 的帖子,它会在后面每张图里出现。

各层职责一句话:召回负责「别漏」(高召回率,宁滥勿缺),粗排负责「省钱」(轻模型控制精排算力),精排负责「排准」(重模型逐条预估),重排负责「好看」(多样性与业务规则),混排负责「营收与生态」(广告与运营内容)。各家叫法略有差异:粗排也叫轻排 / L1,精排也叫 L2 / Heavy Ranker。

延迟分账:从下拉到内容出现

面板下半就是延迟预算的分账。用户下拉刷新的忍耐上限决定了体感总延时:典型请求(P50)约 400ms,尾部(P99)可到 800ms;服务端排序预算按 P99 设,约 300ms。三个让账面 ≠ 体感的机制,都能在面板上亲手验证:

• 墙钟时间不是各阶段之和。多路召回并行、广告与自然内容并行(把「广告并行」关掉,总延时立刻多出一截)。悬停任一行,会高亮它的上游串行链 —— 只有这条链决定墙钟。
• 预算按 P99 设,靠降级兜底。切到 P99,网络两头和每个阶段都变长;超预算时括线变红并标出降级手段:丢弃超时的召回通道、精排回退粗排分。
• 最好的延迟是没有延迟。「下拉秒出」多半是预取:上一次请求时已经准备好下一页,刷新时先展示缓存再后台补新 —— 这 400ms 被挪到了用户看不见的时刻。

反过来读,这张分账表就是架构的成因:精排在关键路径上只分到约 100ms,所以必须单卡毫秒级(把精排模型切到 Transformer 再关掉粗排,看它怎么把预算撑破);召回只分到约 50ms,所以必须亚线性(双塔 + ANN)。带着这个参照系,下一讲看 𝕏 的实际实现 —— 它与范式的几处偏离,恰恰是最值得学的部分。

𝕏 的全景:一条请求的旅程

每次下拉刷新 For You,都由信息流服务 𝕏-Home Mixer(Rust)现场组装一条时间线。它构建在 candidate-pipeline 框架上,把工作拆成标准化的阶段 —— 来源、水合、过滤、打分、选择、副作用 —— 能并行的阶段并行执行。对照上一讲的经典漏斗,𝕏 的链路是 召回 → 精排 → 重排 → 混排,外加水合与两道过滤 —— 注意少了粗排,后面会解释为什么。先看全景,后面各讲逐段展开:

行业漏斗术语对照

唯一「对不上」的环节值得琢磨:多数大厂在召回和精排之间放一个轻量粗排模型,先把几千条筛到几百条再上重模型。𝕏 用「强召回 + 规则过滤」直接对接精排 —— 候选隔离让精排打分可缓存(第 6 讲),重模型吃几百条的成本可以接受,粗排层就省了。

记住一个贯穿全课的分工:排序决定顺序,可见性决定能否展示。第 ⑤ 步的模型只管「你有多可能喜欢它」;第 ⑦ 步引用的是另一套完全独立的内容安全系统(第 5 讲),两者输入不同、规则不同、服务也不同。

召回(Candidate Retrieval):数百万 → 数百

三条召回通道(retrieval channels)并行取货:

• 𝕏-Thunder —— 关注内召回(In-Network):帖子发布时就写进内存,请求来时直接返回你关注账号的近期帖子。它还会接收「已看过」列表,提前剔除。
• 𝕏-Phoenix 召回 —— 关注外(Out-of-Network,OON)模型召回:双塔模型(Two-Tower)做近似最近邻检索(ANN),是「破圈」内容的主力,详见下图。
• 𝕏-SimClusters —— 关注外协同召回:按「谁和谁互动同样的内容」给账号与帖子做协同过滤式聚类,再用簇的相似度找候选。

两个值得停下来品的细节:

• 召回不用用户 ID 向量(use_user_embedding=False)。系统几乎完全用「你最近互动过什么」来表示你 —— 你的兴趣画像每天都在被你自己的行为改写,而不是固化在一个学出来的 ID 嵌入里。
• 帖子用「语义 ID」表示(Semantic ID):把帖子的多模态嵌入量化成 6 层、每层 256 选 1 的残差编码。同主题的帖子共享编码前缀,于是模型对从没见过的新帖也有组合泛化能力 —— 帖子发出的那一刻就能被召回,物品侧没有冷启动(item cold-start)问题。

精排与融合:Σ 权重 × 概率

进入精排(ranking)的每条帖子,由 𝕏-Phoenix 排序模型(一个 Transformer,读你的行为序列作上下文)做多目标互动预估(multi-task engagement prediction),逐条(pointwise)输出约二十种行为各自的概率:点赞、回复、转发、引用、分享、各类点击、停留时长、关注作者,以及负反馈(negative feedback)类的「不感兴趣」、静音、拉黑、举报。然后 RankingScorer 用一行融合公式(score fusion / value model)合成最终分:

下面是仓库 2026-08 快照里 param.rs 的部分真实默认权重(线上以配置系统为准,官方用 cron 把生产值回写到仓库):

融合之后还有三个业务调整,再进入重排(re-ranking):

• 同作者打散(author diversity):同一作者第二条起分数乘衰减系数(有下限),避免刷屏。
• 关注外降权(OON discount):未关注账号的帖子乘一个小于 1 的系数;关注账号的转发和回复同样打折。
• 新作者扶持(冷启动探索,explore):曝光量低于阈值的作者,帖子被提升到目标位置附近,给新人冷启动机会。
• 多样性重排:𝕏-VMRanker —— 独立重排服务,用行列式点过程(DPP)在帖子嵌入上重排:牺牲一点点分数,换相邻帖子之间更低的相似度,你的时间线才不会连着五条同一个话题。

可见性:排序之外的另一套系统

模型说「你会喜欢」,不代表就能给你看。这部分对应行业里的内容安全 / 信任与安全(Trust & Safety)体系:一条帖子能否展示,由可见性过滤服务 visibility-filtering 独立裁决,依据是一整条持续运行的打标签链路 —— 内容理解(content understanding)模型给帖子和账号打分,规则引擎写入安全标签(safety labels);它不在请求路径上,请求来时只做读取:

一个精细的设计:有一组规则只对「推荐」生效 —— 仅当帖子来自你未关注的账号时才可能 drop(比如高召回率抓到的疑似垃圾内容),同一条帖子对关注者照常展示。系统宁可少推荐,也不轻易在粉丝面前隐藏内容。

配套的透明度工具「Under the Hood」让每个人查看自己账号和帖子上影响可见性的标签统计 —— 部分规则文件(如 𝕏-Grox 的提示词、部分 𝕏-Botmaker 规则)为防对抗没有开源,官方以「代码 + 可查询的结果」组合来补足透明度。

设计取舍

• 多行为预测,而非单一「相关分」。模型输出约二十个概率,合成是显式、可审计的一步 —— 想调整产品价值观,改的是明文权重,不用重训模型。
• 候选隔离。排序推理时,候选帖子之间不能互相 attend,只能看观看者上下文。一条帖子的分数不受同批次其他帖子影响,分数因此稳定、可缓存。
• 哈希嵌入,没有词表。召回和排序都用多个哈希函数查嵌入,新帖、新作者发出即刻可表示,不用维护和更新词表。
• 排序与可见性彻底分离。不同服务、不同输入、不同规则。安全裁决不会被「用户可能爱看」的分数稀释,反之亦然。
• 管线框架化。candidate-pipeline 把阶段类型标准化,执行与监控和业务逻辑分离,加一路召回通道或一个过滤器都是插件式的。

动手实践与思考题

这次开源和 2023 年那次的最大区别:𝕏-Phoenix 目录里是真实的生产训练与推理代码(JAX 训练 + Rust gRPC 推理引擎),配了确定性的合成数据生成器和单卡 nano 配置(home_direct_packed_nano 精排、xrecsys_two_tower_nano 召回),几分钟就能在一张 GPU 上端到端跑通:训练 → 出 checkpoint → 用生产同款引擎对外服务。入口见 phoenix/QUICKSTART.md 与 phoenix/TRAINING.md。

思考题

1. 为什么召回塔不给每个用户学一个 ID 嵌入?如果加上,对「兴趣快速变化的用户」和「僵尸粉画像」各会发生什么? 提示:行为序列是实时的,ID 嵌入是滞后的;ID 嵌入还会给刷量行为一个可被固化利用的载体。
2. 举报的权重是 −234,点赞是 +0.5。构造一个数值例子,说明为什么这不等于「1 个举报抵 468 个赞」。 提示:代入典型概率,比如 P(点赞)=10%,P(举报)=0.01%,比较两项贡献的绝对值。
3. 「只对推荐生效、对关注者不生效」的 drop 规则,换成对所有人生效会有什么代价?反过来全部放开呢? 提示:考虑误伤(高召回意味着假阳性)与订阅关系承载的知情选择。
4. 候选隔离放弃了「批内比较」的信息。如果允许候选互相 attend,分数会怎么不可缓存?listwise 排序的收益该在哪个环节找补? 提示:VMRanker 的 DPP 重排正是在打分之后做批内多样性。

The industry paradigm: the classic cascade

First, a frame of reference. Today's feed products — TikTok/Douyin, Xiaohongshu, YouTube, Instagram Reels — have converged on the same cascade ranking architecture: a chain of progressively heavier models, each cutting the candidate count by an order of magnitude or two, so the most expensive model only ever sees the fewest posts (Chinese shorthand for the layers: 召回 / 粗排 / 精排 / 重排 / 混排). The panel below keeps "how many" and "how long" in one state: the top half is the funnel (what each layer sees), the bottom half is the latency waterfall of that same state (what each step costs). Our protagonist is a post called №4711; it appears in every figure from here on.

Each layer in one line: retrieval must not miss (high recall — err on the side of too many), pre-ranking saves money (a light model protects the heavy model's compute), ranking gets the order right (heavy model, per-item prediction), re-ranking makes it pleasant (diversity and business rules), and blending pays the bills and feeds the ecosystem (ads and editorial content). Names vary by company: pre-ranking is also called light ranking / L1, ranking is L2 / the heavy ranker.

The latency ledger: from pull-to-refresh to content on screen

The bottom half of the panel is the latency budget, itemised. A user's patience on pull-to-refresh caps perceived end-to-end latency: a typical request (P50) lands around 400 ms, the tail (P99) can reach 800 ms; the server-side ranking budget is set at P99, about 300 ms. Three reasons the ledger differs from what users feel — each can be verified by hand on the panel:

• Wall-clock time is not the sum of the stages. Retrieval channels run in parallel, and so does the ads auction (switch "Ads in parallel" off and the total grows by a whole rod). Hover any row to light up its upstream serial chain — only that chain sets the wall-clock.
• Budgets are set at P99 and held by degradation. Switch to P99: both network legs and every stage stretch; past the budget the bracket turns red and names the fallback — drop the timed-out retrieval channel, fall back to pre-ranking scores.
• The best latency is none. "Instant refresh" is mostly prefetch: the next page was prepared during the previous request and is shown first while fresh results load behind it — those 400 ms are spent when the user isn't looking.

Read backwards, this ledger is the architecture's cause: ranking gets about 100 ms on the critical path, so it must run in milliseconds on one GPU (set the model to Transformer, then switch pre-ranking off, and watch it break the budget); retrieval gets about 50 ms, so it must be sublinear (two-tower + ANN). With this frame in hand, the next lecture looks at 𝕏's real implementation — the places where it departs from the paradigm are the most instructive parts.

𝕏 end to end: the life of a request

Every pull-to-refresh of For You is assembled on the spot by the feed service 𝕏-Home Mixer (Rust). It is built on the candidate-pipeline framework, which splits the work into standardized stages — sources, hydrators, filters, scorers, selectors, side effects — and runs independent stages in parallel. Against the cascade from Lecture 1, 𝕏's path is Retrieval → Ranking → Re-ranking → Blending, plus hydration and two rounds of filtering — note the missing pre-ranking layer; we'll come back to why. The big picture first; later lectures expand each segment:

Funnel terminology, mapped

The one stage that doesn't line up deserves a pause: most large platforms put a light pre-ranking model between retrieval and ranking to cut thousands down to hundreds before the heavy model runs. 𝕏 wires strong retrieval plus rule-based filtering straight into ranking — candidate isolation makes ranking scores cacheable (Lecture 6), the heavy model can afford a few hundred posts, and the pre-ranking layer is simply skipped.

One division of labour runs through the whole course: ranking decides the order; visibility decides whether a post can be shown at all. The model in stage ⑤ only answers "how likely are you to like this"; stage ⑦ consults an entirely separate Trust & Safety system (Lecture 5) with different inputs, different rules and different services.

Retrieval(召回): millions → hundreds

Three retrieval channels fetch in parallel:

• 𝕏-Thunder — in-network retrieval: posts are written to memory as they are published; at request time it returns recent posts from accounts you follow. It also receives the "already seen" list and drops those up front.
• 𝕏-Phoenix retrieval — out-of-network (OON) model retrieval: a two-tower model with approximate nearest-neighbour (ANN) search, the main engine of "beyond your bubble" content; see the figure below.
• 𝕏-SimClusters — OON collaborative retrieval: clusters accounts and posts by "who engages with the same things," collaborative-filtering style, then uses cluster similarity to find candidates.

Two details worth savouring:

• Retrieval uses no user-ID embedding (use_user_embedding=False). The system represents you almost entirely by what you engaged with recently — your interest profile is rewritten daily by your own behaviour, not frozen into a learned ID embedding.
• Posts are represented by semantic IDs: each post's multimodal embedding is quantized into 6 levels of residual codes, 256 choices per level. Posts on the same topic share code prefixes, so the model generalizes compositionally to posts it has never seen — a post is retrievable the moment it is published, with no item cold-start problem.

Ranking & fusion: Σ weight × probability

Each post entering ranking(精排) is scored by the 𝕏-Phoenix ranking model — a Transformer that reads your action sequence as context — with multi-task engagement prediction, pointwise, producing probabilities for roughly twenty actions: like, reply, repost, quote, share, various clicks, dwell time, follow author, plus negative-feedback actions — not interested, mute, block, report. RankingScorer then combines them with a one-line fusion formula (score fusion / value model):

Some real default weights from param.rs in the 2026-08 snapshot (production reads them from a config system; a cron job writes production values back into the repository):

After fusion come three business adjustments, then re-ranking:

• Author scatter (author diversity): from an author's second post onward, the score is multiplied by a decaying factor (with a floor), so nobody floods the feed.
• OON discount: posts from accounts you don't follow are multiplied by a factor below 1; reposts and replies from followed accounts get the same discount.
• New-author boost (cold-start exploration): authors below an impression threshold have their posts lifted toward a target position, giving newcomers a chance.
• Diversity re-ranking: 𝕏-VMRanker — a separate re-ranking service that runs a determinantal point process (DPP) over post embeddings: it gives up a little score for lower similarity between neighbours, so your timeline doesn't show five posts in a row on one topic.

Visibility: a separate system from ranking

The model saying "you'd like this" doesn't mean you get to see it. This is the industry's Trust & Safety layer: whether a post can be shown is decided independently by the visibility-filtering service visibility-filtering, based on a continuously running labeling path — content-understanding models score posts and accounts, and a rule engine writes safety labels. None of it runs on the request path, which only reads:

A subtle design: one set of rules applies only to recommendations — a post can be dropped only when it comes from an account you don't follow (e.g. suspected spam caught at high recall); the same post is shown to followers as usual. The system would rather recommend less than hide content from a creator's own followers.

A companion transparency tool, Under the Hood, lets anyone see aggregate statistics of the visibility-affecting labels on their account and posts. Some rule files (𝕏-Grox's prompts, some 𝕏-Botmaker rules) are withheld to resist gaming; the stated position is that code plus queryable outcomes together make up the transparency.

Design decisions

• Multi-action prediction, not a single "relevance" score. The model outputs about twenty probabilities; combining them is an explicit, auditable step — changing the product's values means editing plaintext weights, not retraining.
• Candidate isolation. During ranking inference, candidates cannot attend to each other, only to the viewer context. A post's score does not depend on what else is in the batch, so scores are stable and cacheable.
• Hash-based embeddings, no vocabulary. Both retrieval and ranking look up embeddings through multiple hash functions; a new post or author is representable the moment it appears, with no vocabulary to maintain.
• Ranking and visibility fully separated. Different services, inputs and rules. Safety verdicts are never diluted by "the user would probably like it," and vice versa.
• A pipeline framework. candidate-pipeline standardizes stage types and separates execution and monitoring from business logic; adding a retrieval channel or a filter is a plug-in.

Hands-on & discussion questions

The biggest difference from the 2023 open-sourcing: the 𝕏-Phoenix directory holds the real production training and serving code (JAX training plus a Rust gRPC serving engine), with deterministic synthetic-data generators and single-GPU nano configs (home_direct_packed_nano for ranking, xrecsys_two_tower_nano for retrieval). In minutes on one GPU you can run it end to end: train → checkpoint → serve with the same engine production uses. Start at phoenix/QUICKSTART.md and phoenix/TRAINING.md.

Discussion questions

1. Why doesn't the retrieval tower learn an ID embedding per user? If it did, what would happen to users whose interests shift quickly — and to bot-farm profiles? Hint: the action sequence is live while an ID embedding lags; an ID embedding also gives inflated engagement a durable place to live.
2. Report's weight is −234 and like's is +0.5. Build a numeric example showing why this is not "one report cancels 468 likes." Hint: plug in typical probabilities, e.g. P(like) = 10% and P(report) = 0.01%, and compare the absolute contributions.
3. What would it cost to make the "recommendations only, not followers" drop rules apply to everyone? And to remove them entirely? Hint: think about collateral damage (high recall means false positives) and the informed choice a follow relationship carries.
4. Candidate isolation gives up within-batch comparison. If candidates could attend to each other, why would scores stop being cacheable — and where should listwise gains be recovered instead? Hint: 𝕏-VMRanker's DPP re-ranking is exactly within-batch diversity, applied after scoring.