核心组件速览

本文面向产品与运营人员，简要说明推荐系统各组核心组件的职责与协作方式。本页不贴代码；每节末尾链接到对应的技术页。

组件分组一览表

早期版本只开源了 5 个组件。2e2295b 的上游 README 把组件分成六组，共二十多个目录（README.md:256-339）。本页保留原文件名，按这六组介绍。

flowchart TB
    REQ([你打开 For You]) --> HM
    HM["编排：home-mixer"] -->|"取候选"| SRC["候选源：Thunder / Phoenix 召回 / SimClusters / 热门帖子"]
    IDX["召回索引：phoenix-rankall"] -.-> SRC
    SRC --> RANK["排序：Phoenix 排序 + vm-ranker"]
    RANK --> VF["可见性过滤：ALLOW / NOTICE / INTERSTITIAL / DROP"]
    VF --> FEED([排好的信息流])
    CU["内容理解：Grox / 媒体模型 / 账号信号"] -.-> LBL["打标签：scarecrow + botmaker / 处置服务"]
    LBL -.-> VF

图中实线是请求路径，用户打开 For You 时实时运行。虚线是标签路径，在后台持续运行。两条路径在可见性过滤处汇合。详见 系统架构总览。

1. 编排：home-mixer 与 candidate-pipeline

核心定位：home-mixer 是 For You 的服务进程，candidate-pipeline 是它所用的流水线框架。

用户刷新客户端时，请求先到 home-mixer。home-mixer 按固定阶段调度下游：补齐请求信息、向候选源取帖、补资料（水合）、预打分过滤、打分、选择、选后检查，最后混排广告。内层流水线有 9 个候选源、21 个预打分过滤器、5 个打分器（home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:285-543）。

candidate-pipeline 定义这些阶段的类型，并规定哪些阶段并行、哪些阶段顺序执行（candidate-pipeline/candidate_pipeline.rs:239-445）。主信息流和其他流水线共用这套框架。

机制类比：类似生产线调度总管，自己不加工，但决定各工序的顺序。

技术文档：home-mixer 编排层、candidate-pipeline 框架与七个组件 trait、CandidatePipeline trait（流水线执行器）

2. 候选源：从哪里取帖子

核心定位：候选源决定哪些帖子有机会被打分。内层流水线装配了 9 个候选源（home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:380-390），README 列出其中四个主要来源：

• Thunder（站内）：在内存里保存最近 172800 秒（2 天）发布的帖子，返回你关注的人发的帖（thunder/args.rs:48-49）。它只按时间取，不做相关性排序。
• Phoenix 召回（站外）：把你和每条帖子都变成向量，返回离你最近的帖子。
• SimClusters（站外）：按“谁和什么互动”把账号和帖子聚成社区，用你最近互动过的帖子找相似帖子。开源默认开启（home-mixer/params/param.rs:48-53）。
• 热门帖子源（站外）：一份全站共享的热门列表。离线任务按粉丝数从高到低选作者，人数为近 7 天活跃发帖人数的 0.005%，每人最多 5 条、共 500 条（home-mixer/util/popular_authors.rs:11,25-30、home-mixer/util/popular_posts.rs:39-40）。

机制类比：类似多个进货渠道，每个渠道各自送来一批货，统一进入后面的质检和评审。

技术文档：home-mixer 编排层、Thunder 站内帖子内存库、Thunder Kafka 摄入、PostStore、Phoenix 召回、SimClusters 站外候选源

3. 召回索引：phoenix-rankall

核心定位：phoenix-rankall 维护 Phoenix 召回要查询的帖子索引，phoenix-rankall-strato 决定一条帖子进哪个索引。

发帖和点赞事件触发索引更新。帖子进索引前，phoenix-rankall-strato 先以站外推荐的安全级别查询可见性过滤；被判丢弃的帖子不进主索引（phoenix-rankall-strato/lib/eventProcessing.strato:260-279）。

机制类比：类似仓库的货架清单。清单只收质检放行的货，召回只在清单里找。

技术文档：Phoenix 召回索引：rankall 与事件层

4. 排序：Phoenix 排序与 vm-ranker

核心定位：Phoenix 排序模型预测行为概率；vm-ranker 把概率变成最终分，再挑出一组彼此不太相似的帖子。

• Phoenix 排序：transformer 模型读取你的互动历史，预测你对每条候选点赞、回复、转发、停留、举报等行为的概率。仓库发布的是生产实现本身，不再是早期从 Grok-1 移植的示例（phoenix/README.md:9-21）。
• vm-ranker：独立服务。它把每个概率乘以权重再求和，得到价值模型分（xai-value-model/scoring.rs:79-218），再做作者多样性、站外降权和新作者扶持。之后可用 DPP 挑出多样的子集：入选者保留原分，其余分数置 0（vm-ranker/scoring/dpp_model.rs:196-206）。

内层流水线按序运行 5 个打分器：PhoenixScorer → ImmersiveVideoScorer → VMRanker → PageDecodeRerankScorer → PageRlExplorationScorer，后两个开源默认关闭（home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:475-481）。

机制类比：Phoenix 像评审考官，给每位候选的各项表现打分；vm-ranker 像排班员，按总分排名，并避免同类节目扎堆。

技术文档：Phoenix 排序模型、打分与排序、VM Ranker 重排服务、Grok Transformer 骨架、PhoenixModel（排序模型）、PhoenixRetrievalModel（召回模型）

5. 内容理解：给帖子和账号算分

核心定位：这一组在后台运行，不在推荐请求的关键路径上。它们产出分数和嵌入，供打标签规则和召回使用。

• Grox：帖子发布后运行分类器，判断垃圾内容、成人内容、暴力媒体等，并生成帖子的文本和图片嵌入。分类器用 Grok 型号和 Gemma 系列模型（grox/config/config.py:79-94）。旧版的 banger 质量分已删除，写入时固定为 1.0（grox/flows/upa/task_write.py:177）。
• media-model-proxy：把图片和视频转发给 7 个媒体模型，例如成人内容、暴力血腥、仇恨符号（media-model-proxy/src/main/scala/com/twitter/media_understanding/model_proxy/model_descriptors/ModelDescriptorRegistry.scala:9-19）。
• clip、adult-content、pnsfwmedia：训练图文嵌入模型和成人媒体分类器。
• agatha：离线统计别人对一个账号的拉黑、举报相对站外点赞的比率，给账号打分（agatha/scalding/labels/rate_based_labels/RateBasedLabels.scala:29-57）。
• bdsm：读取账号一段时间内的行为序列，识别不真实或滥用行为。
• user-cred-v2：在关注图上跑 PageRank，换算成 0–100 的账号分（user-cred-v2/UserCredV2.scala:10-19）。

机制类比：类似质检实验室。实验室只出化验单，不直接决定商品上不上架。

技术文档：Grox 服务架构、Grox 内容分类器、多模态帖子嵌入器、图片与视频模型、账号级信号（agatha、bdsm、user-cred-v2）

6. 可见性与标签：决定帖子能不能展示

核心定位：这一组把分数变成标签，再按标签回答“这条帖子能不能给这位用户看”。

• scarecrow + botmaker + botmaker-rules：scarecrow 在事件发生时执行打标签规则，botmaker 是规则引擎。部分规则不在仓库中（README.md:447）。
• abuse-enforcement-service：读取模型分数，给账号或帖子打标签、发起验证或封禁。
• abuse-ledger-service：回答一个账号是否处在申诉保护期。处置服务查询保护期的这道检查开源默认关闭（abuse-enforcement-service/service-lib/src/overturn_hold.rs:150-162）。
• safety-label-user-agg：按账号最近帖子的标签给账号打标签。例如最近 5 条里有 3 条 NSFW_HIGH_PRECISION，账号得到同名标签，有效 7 天（safety-label-user-agg/postToUserLabelRules.strato:395-426）。
• visibility-filtering：读取标签和关系，对每条帖子给出 ALLOW、NOTICE、INTERSTITIAL 或 DROP。home-mixer 在选出帖子后查询它（home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:485-487）。
• under-the-hood：生成按月的 Under the Hood 报告，向账号本人展示白名单内的标签。
• takedowns、visibility-filtering-client：前者产出下架原因列表，后者是调用可见性过滤的客户端。

机制类比：类似质检结论与放行闸口。实验室出化验单，规则把化验单写成标签，闸口按标签放行、加遮罩或拦下。

技术文档：可见性过滤（Visibility Filtering）、打标签规则（scarecrow 与 botmaker）、处置与标签聚合、Under the Hood 透明度报告

各组协同流程

用户刷新 For You 推荐流时，各组按以下顺序协作：

1. 编排：home-mixer 接收请求，按 candidate-pipeline 的阶段启动流水线。
2. 候选源：Thunder、Phoenix 召回、SimClusters、热门帖子源等同时取帖。Phoenix 召回查询 召回索引 里的帖子。
3. 编排：水合补齐资料，21 个预打分过滤器去掉不合格的候选。
4. 排序：Phoenix 预测行为概率，vm-ranker 算最终分并做多样性调整。
5. 编排：按分数先取 50 条，最终保留 35 条（home-mixer/params/config.rs:17-18，开源默认值）。
6. 可见性与标签：可见性过滤读取 内容理解 与打标签规则提前写好的标签，决定每条帖子是否展示。
7. 编排：插入广告和其他模块，把结果交给客户端。

出处

每组的关键源码如下。精确行号、结构体与函数名见对应技术页的“源码锚点”。

相关页面

• 推荐系统工作原理 —— 端到端执行流程说明
• 候选帖子选择与成型机制 —— 打分完成后的候选截断与选择机制
• 运营迷思与源码真相 —— 运营经验与源码实现对照
• 算法发帖指南 —— 基于底层算法机制总结的创作者分发建议
• 端到端数据流:一条帖子从发布到被推荐 —— 帖子从发布到被推荐的数据流
• 术语速查表 —— 核心术语速查表
• 常见疑问 FAQ —— 推荐系统高频疑问解答
• 系统架构总览 —— 技术架构全景文档