X 推荐算法开源：深度解读"For You"背后的技术架构
X 推荐算法开源：深度解读"For You"背后的技术架构
2026 年 5 月 15 日，xAI 在 GitHub 上更新了 X（原 Twitter）的"For You"推荐算法源码（xai-org/x-algorithm）。核心排序模型换成了基于 Grok 的 Transformer，所有手工特征被彻底移除，系统完全依赖深度学习来理解用户行为。同时新增了端到端推理管线、预训练模型权重、内容理解服务和广告混排系统。
本文对这份开源代码做完整的技术梳理。
仓库结构与技术栈
xai-org/x-algorithm/
├── candidate-pipeline/ # 通用推荐管线框架（Rust）
├── grox/ # 内容理解服务（Python）
├── home-mixer/ # 编排调度层（Rust）
├── phoenix/ # ML 模型核心（Python / JAX）
├── thunder/ # 网内内容实时引擎（Rust）
├── README.md
├── LICENSE # Apache 2.0
└── CODE_OF_CONDUCT.md
服务层和管线框架用 Rust 实现（高性能、亚毫秒延迟），ML 模型用 Python + JAX 实现（灵活迭代、GPU 加速）。Transformer 架构从 Grok-1 开源移植而来，针对推荐场景做了定制。
系统全貌
当你打开 X 刷"For You"信息流时，后台做的事情可以用一句话概括：从两个来源获取候选帖子，用一个大模型给它们打分排序，选出最好的结果返回给你。
两个候选来源：
- Thunder（网内内容）：你关注的人发的帖子
- Phoenix Retrieval（网外内容）：通过机器学习从全局语料库中发现的帖子
两路候选汇合后，由 Phoenix 排序模型统一打分。Phoenix 基于 Grok 架构，专门预测你对每条帖子的互动概率。最终得分是多个预测概率的加权组合。
官方表述：我们已经移除了系统中所有手工特征和绝大部分启发式规则。 Transformer 直接从用户的互动序列中学习什么内容与你相关。
FOR YOU FEED REQUEST
│
▼
HOME MIXER（编排调度）
│
├── Query Hydration：用户上下文（互动历史、关注列表、话题、IP、互关图谱）
│
├── Candidate Sources
│ ├── Thunder（关注者的帖子）
│ └── Phoenix Retrieval（全局 ML 检索）
│
├── Hydration：补充元数据（帖子正文、作者信息、媒体、互动计数）
│
├── Pre-Scoring Filters：去重、过期、自身帖、拉黑/静音、屏蔽词
│
├── Scoring
│ ├── Phoenix Scorer（Transformer 预测 19 种行为概率）
│ ├── Weighted Scorer（加权组合为最终分数）
│ ├── Author Diversity Scorer（衰减同作者重复分数）
│ └── OON Scorer（网外内容分数调整）
│
├── Selection：按分数排序，选取 Top K
│
└── Post-Selection Filters：可见性检查（删除/垃圾/暴力/血腥）
│
▼
RANKED FEED RESPONSE
Home Mixer：编排调度层
路径： home-mixer/
Home Mixer 是整个推荐流程的中枢。它通过 CandidatePipeline 框架将各阶段串联成完整管线，对外暴露 gRPC 端点（ScoredPostsService）返回排序后的帖子。
| 阶段 | 作用 |
|---|---|
| Query Hydrators | 获取用户上下文：互动历史、关注列表、关注话题、Starter Packs、曝光布隆过滤器、IP、互关图谱、已推送历史 |
| Sources | 从 Thunder 和 Phoenix 获取候选帖子 |
| Hydrators | 为候选补充数据：互动计数、品牌安全信号、语言代码、媒体检测、引用帖展开、互关分数 |
| Filters | 移除不合格候选 |
| Scorers | 预测互动概率并计算最终得分 |
| Selector | 按得分排序，选取 Top K |
| Post-Selection Filters | 最终可见性检查和去重 |
| Side Effects | 缓存请求信息，供后续使用 |
候选来源（sources/）： 12 个来源模块
| 文件 | 作用 |
|---|---|
thunder_source.rs |
关注者的帖子（网内） |
phoenix_source.rs |
Phoenix 检索的网外内容 |
phoenix_moe_source.rs |
Phoenix MoE 来源（新增） |
phoenix_topics_source.rs |
按话题的 Phoenix 来源（新增） |
ads_source.rs |
广告来源（新增） |
who_to_follow_source.rs |
推荐关注（新增） |
prompts_source.rs |
提示词来源（新增） |
scored_posts_source.rs |
预打分帖子 |
cached_posts_source.rs |
缓存帖子 |
tweet_mixer_source.rs |
Tweet Mixer |
push_to_home_source.rs |
推送到首页 |
打分器（scorers/）： 6 个打分模块
| 文件 | 作用 |
|---|---|
phoenix_scorer.rs |
调用 Phoenix 模型获取原始预测概率 |
weighted_scorer.rs |
加权组合 19 种预测为最终分数 |
author_diversity_scorer.rs |
衰减同一作者重复出现的分数 |
oon_scorer.rs |
网外内容分数调整 |
ranking_scorer.rs |
排序打分 |
vm_ranker.rs |
VM 排序器 |
过滤器（filters/）： 17 个过滤模块
| 文件 | 作用 |
|---|---|
drop_duplicates_filter.rs |
移除重复帖子 ID |
core_data_hydration_filter.rs |
移除元数据注水失败的帖子 |
age_filter.rs |
移除过旧帖子 |
self_tweet_filter.rs |
移除用户自身帖子 |
retweet_deduplication_filter.rs |
同一内容多次转发去重 |
ineligible_subscription_filter.rs |
移除无权访问的付费内容 |
previously_seen_posts_filter.rs |
移除已看过的帖子 |
previously_served_posts_filter.rs |
移除当前会话已推送的帖子 |
muted_keyword_filter.rs |
移除包含屏蔽关键词的帖子 |
author_socialgraph_filter.rs |
移除拉黑/静音作者的帖子 |
vf_filter.rs |
可见性过滤（删除/垃圾/暴力/血腥） |
dedup_conversation_filter.rs |
同一对话线程多分支去重 |
video_filter.rs |
视频过滤 |
topic_ids_filter.rs |
话题过滤 |
new_user_topic_ids_filter.rs |
新用户话题过滤 |
previously_seen_posts_backup_filter.rs |
已看帖子备份过滤 |
ancillary_vf_filter.rs |
辅助可见性过滤 |
广告混排（ads/）： 新增模块，处理广告在信息流中的注入和定位，内置品牌安全追踪，确保广告不出现在敏感内容旁边。
数据模型（models/）：
| 文件 | 定义 |
|---|---|
candidate.rs |
候选帖子结构体 |
candidate_features.rs |
候选特征 |
query.rs |
查询结构体 |
user_features.rs |
用户特征 |
brand_safety.rs |
品牌安全信号 |
in_network_reply.rs |
网内回复 |
Thunder：网内内容实时引擎
路径： thunder/
Thunder 是一个内存级帖子存储和实时摄取管线，专门处理关注者的内容。查找延迟在亚毫秒级别，无需访问外部数据库。
| 文件/目录 | 作用 |
|---|---|
main.rs / lib.rs |
服务入口 |
thunder_service.rs |
核心服务逻辑 |
kafka/ + kafka_utils.rs |
从 Kafka 消费帖子创建/删除事件 |
deserializer.rs |
事件反序列化 |
posts/ |
按用户维护的内存帖子存储（原创帖、回复/转发、视频帖） |
工作流程：
- 从 Kafka 消费帖子创建和删除事件
- 为每个用户维护独立的帖子存储：原创帖、回复/转发、视频帖三类
- 收到请求时，返回目标用户关注列表中所有人的近期帖子
- 自动清理超过保留期限的旧帖
Phoenix：ML 模型核心
路径： phoenix/
Phoenix 是整个系统的机器学习核心，承担检索和排序两个功能。Transformer 架构从 Grok-1 开源移植，针对推荐场景做了自定义输入嵌入和注意力掩码。
| 文件 | 作用 |
|---|---|
grok.py |
从 Grok-1 移植的 Transformer 架构 |
recsys_model.py |
排序模型：带候选隔离的 Transformer，预测 19 种互动概率 |
recsys_retrieval_model.py |
检索模型：双塔架构（用户塔 + 候选塔） |
run_pipeline.py |
端到端推理入口：检索 → 排序（新增） |
run_ranker.py |
单独运行排序 |
run_retrieval.py |
单独运行检索 |
runners.py |
运行器工具函数 |
test_recsys_model.py |
排序模型测试 |
test_recsys_retrieval_model.py |
检索模型测试 |
artifacts/ |
预训练模型权重（约 3GB，Git LFS）（新增） |
检索：双塔模型
用于发现网外内容，经典的 Two-Tower 架构：
- 用户塔（User Tower）：将用户特征和互动历史通过 Transformer 编码为归一化向量
[B, D] - 候选塔（Candidate Tower）：将所有帖子编码为归一化向量
[N, D] - 相似度搜索：通过向量点积检索 Top-K 相关帖子
从数百万候选中缩窄到数千条。
排序：带候选隔离的 Transformer
对检索出的候选进行精排。关键设计——候选隔离（Candidate Isolation）：Transformer 推理时候选帖子之间不能互相注意（attend），只能注意到用户上下文和历史互动序列。
注意力掩码逻辑：
Keys（注意力目标）
────────────────────────────────────────▶
│ User │ History (S) │ Candidates (C) │
┌────┼──────┼─────────────────┼──────────────────┤
Q │ U │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ │
u ├────┼──────┼─────────────────┼──────────────────┤
e │ H │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ │
r │ i │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ │
i │ s │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ │
e ├────┼──────┼─────────────────┼──────────────────┤
s │ C │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✓ ✗ ✗ ✗ ✗ ✗ ✗ │
│ │ a │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✓ ✗ ✗ ✗ ✗ ✗ │
▼ │ n │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✓ ✗ ✗ ✗ ✗ │
│ d │ ✓ │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ │ ✗ ✗ ✗ ✓ ✗ ✗ ✗ │
└────┴──────┴─────────────────┴──────────────────┘
✓ = 可注意 ✗ = 不可注意（被掩码屏蔽）
- User + History：彼此间完全双向注意
- Candidates → User/History：候选可以注意到用户和历史
- Candidates → Candidates：候选之间互不可见，只有自注意（对角线）
这意味着一条帖子的得分只取决于它本身和你的历史，不受同批次其他帖子的影响。评分一致且可缓存。
开源模型规格（Mini Config）：
| 参数 | 值 |
|---|---|
| 嵌入维度 | 128 |
| Transformer 层数 | 4 |
| 注意力头数 | 4 |
| Key 维度 | 32 |
| 宽度因子 | 2 |
| 历史序列长度 | 127 |
| 候选序列长度 | 64 |
| User/Item/Author 词表 | 各 1,000,000 |
| 每实体哈希数 | 2 |
| 行为类型数 | 19 |
注意：这是一个 mini 版本，生产环境使用更大的模型（更多层、更宽嵌入、256 维）。开源版本是生产持续训练过程中的一个冻结快照。
打分与排序机制
Phoenix 排序模型同时预测 19 种互动行为的概率：
| 预测项 | 含义 | 权重方向 |
|---|---|---|
| P(favorite) | 点赞概率 | 正 |
| P(reply) | 回复概率 | 正 |
| P(repost) | 转发概率 | 正 |
| P(quote) | 引用概率 | 正 |
| P(click) | 点击概率 | 正 |
| P(profile_click) | 点击作者头像概率 | 正 |
| P(video_view) | 视频观看概率 | 正（需视频时长 > 阈值） |
| P(photo_expand) | 展开图片概率 | 正 |
| P(share) | 分享概率 | 正 |
| P(share_via_dm) | 通过私信分享概率 | 正 |
| P(share_via_copy_link) | 复制链接分享概率 | 正 |
| P(dwell) | 停留概率 | 正 |
| P(dwell_time) | 停留时长（连续值） | 正 |
| P(follow_author) | 关注作者概率 | 正 |
| P(quoted_click) | 引用帖点击概率 | 正 |
| P(not_interested) | "不感兴趣"概率 | 负 |
| P(block_author) | 拉黑作者概率 | 负 |
| P(mute_author) | 静音作者概率 | 负 |
| P(report) | 举报概率 | 负 |
加权打分器（Weighted Scorer） 将所有预测组合为最终分数：
最终得分 = Σ (weight_i × P(action_i))
正向行为对应正权重，负向行为对应负权重。从源码（weighted_scorer.rs）可以看到几个细节：
- 视频时长门槛：只有视频时长超过
MIN_VIDEO_DURATION_MS时，VQV（视频观看质量）权重才生效，否则为 0 - 偏移校正：当组合分数为负时，会用负权重总和做归一化处理，再乘以偏移系数，确保分数分布合理
- 归一化：加权后的原始分数会经过
normalize_score处理
四个打分器依次执行：Phoenix Scorer（原始预测） → Weighted Scorer（加权组合） → Author Diversity Scorer（同作者衰减） → OON Scorer（网外调整）。
Candidate Pipeline：通用管线框架
路径： candidate-pipeline/
一套可复用的推荐管线框架，Home Mixer 基于它构建。
| 文件 | 定义 |
|---|---|
candidate_pipeline.rs |
管线编排主逻辑：串联 Source → Hydrator → Filter → Scorer → Selector → SideEffect |
source.rs |
Source trait：从数据源获取候选 |
hydrator.rs |
Hydrator trait：为候选补充特征 |
query_hydrator.rs |
QueryHydrator trait：为查询补充用户上下文 |
filter.rs |
Filter trait：移除不应展示的候选 |
scorer.rs |
Scorer trait：计算排序得分 |
selector.rs |
Selector trait：排序并选取 Top K |
side_effect.rs |
SideEffect trait：异步副作用（缓存、日志） |
util.rs |
工具函数 |
框架在可能的地方并行执行独立阶段，支持可配置的错误处理。
Grox：内容理解服务
路径： grox/（新增）
独立的内容理解管线，提供分类、嵌入、摘要等能力，支撑垃圾检测、帖子分类、平台政策（PTOS）执行等任务。
| 目录/文件 | 作用 |
|---|---|
classifiers/ |
分类器（垃圾检测、帖子分类、政策违规判定） |
embedder/ |
内容嵌入器 |
summarizer/ |
内容摘要 |
generators/ |
生成器 |
data_loaders/ |
数据加载器 |
engine.py |
任务执行引擎 |
dispatcher.py |
任务调度器 |
tasks/ |
任务定义 |
plans/ + schedules/ |
执行计划与调度配置 |
lib/ |
公共库 |
main.py |
服务入口 |
关键设计决策
彻底抛弃手工特征。 传统推荐系统依赖大量人工设计的特征工程。X 的新系统把这些全部交给 Grok Transformer，模型直接从用户互动序列中学习内容相关性。这大幅简化了数据管线和线上服务的复杂度。
候选隔离保证评分一致性。 排序时候选之间互不可见，一条帖子的得分只取决于它本身和你的历史，不受同批次其他帖子的影响。评分可以被缓存和复用，对大规模服务至关重要。
基于哈希的嵌入查找。 检索和排序都使用多个哈希函数进行嵌入查找（每个实体 2 个哈希），用户、帖子、作者各有 100 万的词表。在保持合理精度的同时极大压缩了嵌入表规模。
多行为联合预测。 预测 19 种具体行为的概率，通过加权组合得到最终分数。负向行为（拉黑、静音、举报）的负权重会主动压低用户可能反感的内容。
可组合的管线架构。 candidate-pipeline 将管线执行与业务逻辑分离，支持并行执行独立阶段、优雅的错误处理，以及灵活增减来源、注水、过滤和打分组件。
如何运行开源代码
安装依赖：
uv sync
# 或
pip install jax jaxlib dm-haiku numpy
下载模型权重：
cd phoenix
unzip artifacts/oss-phoenix-artifacts.zip -d artifacts/
解压后的内容：
oss-phoenix-artifacts/
retrieval/
model_params.npz # 检索 Transformer + 候选塔权重（3 MB）
embedding_tables.npz # User/Item/Author 哈希嵌入表，各 100 万（1.4 GB）
config.json # 模型配置 + 哈希函数参数
ranker/
model_params.npz # 排序 Transformer + 行为预测头权重（3 MB）
embedding_tables.npz # User/Item/Author 哈希嵌入表，各 100 万（1.4 GB）
config.json # 模型配置 + 哈希函数参数
sports_corpus.npz # 53.7 万条体育帖子，含预计算候选向量
example_sequence.json # 示例用户互动历史（3 条帖子：NFL、NBA、NHL）
运行端到端管线：
uv run run_pipeline.py --artifacts_dir artifacts/oss-phoenix-artifacts
系统会加载示例用户历史，从 53.7 万条语料中检索 Top-200 相关帖子，再精排输出每条帖子在各行为维度上的预测概率。
可选参数：
--top_k_retrieval 500：调整检索深度--top_k_display 50：显示更多排序结果- 修改
example_sequence.json自定义用户历史。行为索引遵循ActionName枚举：1= favorite，4= reply，5= quote，6= repost，11= dwell，13= video quality view
运行测试：
uv run pytest test_recsys_model.py test_recsys_retrieval_model.py
本次更新变化汇总
| 变化 | 内容 |
|---|---|
| 端到端推理管线 | phoenix/run_pipeline.py 取代独立的检索/排序脚本，一个入口完成检索 → 排序 |
| 预训练模型权重 | Mini Phoenix 模型（256 维嵌入、4 头、2 层），约 3GB，Git LFS 分发，开箱即用 |
| Grox 内容理解 | 新增 grox/ 服务：分类器、嵌入器、任务引擎，支撑垃圾检测和政策执行 |
| 广告混排 | 新增 home-mixer/ads/：广告注入、定位、品牌安全追踪 |
| 查询注水增强 | 用户上下文扩展：关注话题、Starter Packs、曝光布隆过滤器、IP、互关图谱、已推送历史 |
| 候选注水增强 | 互动计数、品牌安全信号、语言代码、媒体检测、引用帖展开、互关分数 |
| 候选来源扩展 | 新增广告、推荐关注、Phoenix MoE、Phoenix Topics、提示词等来源 |
If you read this far — thank you.
Come tell me what you thought on X.