x-algorithm
xai-org/x-algorithm加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下：你每天打开 X（Twitter），首页那串帖子是怎么决定顺序的？点赞、转发、拉黑、举报、停留时长——这些动作被赋予不同权重，乘上模型预测的概率，加总成一个分数。但这个分数具体怎么算？权重是多少？哪些帖子被过滤掉了？为什么我的帖子没人看见？
这些问题在 2026 年 8 月之前，答案是「不告诉你」。而现在，xAI 把答案写进了代码。
xai-org/x-algorithm 是 X 官方开源的 For You 时间线核心算法，Apache-2.0 协议，34,004 星、5,502 fork、316 watcher。项目 2026 年 1 月 19 日建仓，到 8 月 13 日一次大规模扩容后代码量涨到原来的 10~15 倍，仓库里有 2,353 个文件、30 个顶级子系统。X 的产品副总裁 Keith Coleman 对 TechCrunch 的说法很直接：「你拿到的是把帖子拉出来、为你排序、并组装成信息流的核心排序代码。有些系统——比如排序器和打分——你甚至可以在公司之外自己跑起来。」
整个仓库是 X 推荐系统的生产代码切片，按请求路径组织成三层：
第一层，候选召回（sources）。 帖子从两个方向来：thunder/ 在内存里保存你关注的账号的近期帖子（In-Network）；phoenix/ 的检索模型和 simclusters/ 从你没关注的账号里挖内容（Out-of-Network），再加上 popular_posts_source 提供的一份全站热门列表。两类候选由同一个模型排序。
第二层，排序打分。 Phoenix 是核心：JAX 写的 transformer，同时承担两段式推荐里的检索（从百万候选缩到几百）和排序（给这几百个排序）。它的做法不是预测一个「相关度」分数，而是预测每一种具体动作的概率：
互动类 favorite · reply · repost · quote · share · 私信分享 · 复制链接分享
点击类 post · profile · link · 图片展开 · 视频播放 · 引用帖
注意力 视频质量观看 · dwell · dwell time · 视频续播秒数 · profile 访问秒数
作者类 follow author
负向 not interested · mute author · block author · report · 未产生停留
RankingScorer 把它们合成一个数：Final Score = Σ(weight_i × P(action_i))，权重就写在 home-mixer/params/param.rs 里，算术在 xai-value-model/scoring.rs。
这里有个官方特意在 2026 年 8 月 14 日补充说明的误解纠正：权重乘的是模型预测的概率，不是原始互动次数。所以看到「举报权重是点赞的 468 倍」不能推断「1 个举报抵消 468 个赞」——两者都乘在你自己的行为预测概率上。
打分之后还有三道修正：作者多样性（同一作者第二帖起乘以衰减因子）、站外折扣（未关注账号的帖子、以及已关注账号的转发回复，乘以小于 1 的系数）、新作者加权（曝光量低于阈值的作者被拉向目标位置）。最后 vm-ranker/ 用**行列式点过程（DPP）**在嵌入空间里重排，牺牲一点分数换取邻居之间更少的相似度——这是为了避免首页塞满同质内容。
第三层，可见性过滤（visibility-filtering）。 这是最容易被误解的设计：排序和可见性是两件事，由不同服务、不同输入、不同规则决定。排序管顺序，过滤管「能不能出现」。规则注册在 visibility-filtering/rules/registry.rs，由 scarecrow/ 把 botmaker/（一个 Scala/Java 写的规则引擎）嵌入到事件流里实时执行。过滤项包括去重、48 小时年龄限制、自己发的帖、重复转发、已读过的帖、静音关键词、拉黑/静音的作者、新用户互动阈值、以及两个留出实验过滤器（按帖子和用户确定性划出一定比例的帖子供 A/B 实验）。
排序之外，仓库还公开了一整套内容理解系统：grox/ 跑垃圾内容、成人内容、暴力媒体的分类器和多模态向量；media-model-proxy/ 提供图像视频模型服务；clip/ 训练图文嵌入模型；agatha/ 离线批量给账号打标；bdsm/ 用账号行为时序识别异常或滥用；user-cred-v2/ 在关注图和互动边上跑 PageRank 生成账号可信分。违规处置侧有 abuse-enforcement-service/、abuse-ledger-service/（处理申诉撤销后的冷却期）和 takedowns/（下架原因清单）。
还有一个特别有意思的东西：Under the Hood 标签透明度工具（under-the-hood/），用 Scala Scalding 写离线作业，收集施加在你账号和帖子上的可见性影响标签，聚合成报告展示在网页或 JSON 文件里（under-the-hood/jetfuel/ 是 TSX 路由）。2026 年 9 月 18 日起，报告里还会说明你的帖子是否因遵守某国法律要求而被限制展示、以及是哪一国。这实际上是把「影子封禁」这件事做成了可自查的机制。
candidate-pipeline/ 定义了 source / hydrator / filter / scorer / selector / side_effect 六种阶段类型，能并行的就并行这是评估这个项目时最需要说清楚的地方。
能跑的一半：phoenix/。 仓库里唯一被设计成端到端可运行的部分。phoenix/QUICKSTART.md 是一份被测试过的路径：用 reference/world_snapshots.py 和 reference/dump_gen.py 生成确定性的合成世界（训练 dump、语义 ID 快照、多模态嵌入快照、检索候选语料），用 reference/train_synth.py 训练 nano 规模的排序和双塔检索模型，写 checkpoint、续训，然后 bench.py 起 gRPC 服务、发请求、关服务。依赖是 Linux + NVIDIA GPU + CUDA 12、uv + Python 3.11+、Rust 工具链 + protoc 3.15+。
官方提供了 nano 单卡预设：home_direct_packed_nano（排序，与生产模型几何同构）和 xrecsys_two_tower_nano（检索，额外用 dense attention、1022 步历史、不带 user-features token）。排序旗舰配置和 nano 用的是生产同款 Muon 优化器（一致 RMS 缩放 + 解耦权重衰减），只在 legacy dense-optimizer 槽位上把生产的定制 Adam 变体替换成了标准 AdamW——这一点在 phoenix/TRAINING.md 里明确披露了。
跑不起来的一半：整个 For You 流水线。 README 自己承认得很直白：基础设施脚手架——部署、编排、内部客户端（xai_service_runner、xai_kafka）——被 stub 或缺失，「你没法把这套东西在家拼起来跑通」。生产数据馈送、生产 checkpoint、多机编排、生产规模配方都不包含。
没有的东西也要点名： 模型权重没有发布（只有训练代码），grox/ 的 LLM 分类器提示词没公开（你能看到分类器被调用、看到判定结果去哪，但看不到模型被问了什么），botmaker-rules/ 里部分规则刻意不放出来，理由官方写得很直白：「为降低这些系统被游戏化绕过的风险」。媒体理解服务还带着 Twitter 时代的内部路径痕迹（README 里是 https://example.invalid/...）。
没有交互日志，推荐系统就是空骨架。 所有价值在模型学到的东西里，而不在流水线怎么写。合成数据训出来的 nano 模型，只是个形状验证，不是模型质量的证据——官方自己在 QUICKSTART 里写明「不要把六步训练当作模型质量的证据」。
部署门槛对多数人是拦路虎。 跑通 Phoenix 需要 CUDA 12 显卡机器；仓库里只有一个 Dockerfile（bdsm/rust/accumulator/），没有 docker-compose、没有 K8s manifest、没有 Helm chart、没有可构建的 Web UI 工程文件（under-the-hood/jetfuel/ 有 TSX 路由但没有 package.json）。对绝大多数团队而言，这是「读得懂、跑不动」级别的开源。
透明度仍是部分的。 关键的业务决策——哪些帖子因为什么被压制——有一层被故意保留。规则引擎在，但规则不全；分类器在，但提示词不在。你能验证排序是公开权重驱动的，但无法完整复现可见性判定。
体量带来的阅读成本。 30 个顶级子系统、661 个 Rust 文件、568 个 Scala 文件、483 个 Python 文件、313 个 Java 文件。README 是入口，但想真正读懂要横跨四种语言。
推荐算法长期是各大平台的护城河——公开的部分都是外围（训练框架、通用召回库），核心排序逻辑从不示人。x-algorithm 打破这个惯例的程度是罕见的：它给的是生产实现本身，包括真实的模型代码、真实的训练步骤、真实的 Rust gRPC 服务引擎，而不是一个玩具示例。
TechCrunch 报道中 Keith Coleman 那句「有些系统你甚至可以在公司之外自己跑起来」，配合 Phoenix 里带 Muon 优化器、带 nano 单卡预设、带合成数据生成器的完整训练路径，说明这不是一次「放点代码出来做公关」的公关式开源，而是真的想让外部研究者能动手。
对行业的示范意义有两层。其一，它给开源社区提供了一个可以跑起来的高质量推荐系统参考实现——两段式召回+排序、候选隔离、哈希嵌入、DPP 多样性重排、多任务动作预测，这些技术在论文里散落各处，第一次被放进同一个可运行的仓库里。其二，它把「算法透明度」这件在欧盟 DSA 语境下反复被讨论的事，做成了一个具体的工程动作——Under the Hood 工具就是可验证的产物。
对做开源情报、平台治理、推荐系统研究的团队，这个仓库的价值主要在阅读而非运行：它是当前公开可得的、最接近超大规模社交平台生产推荐栈的一份材料。34,004 星的速度增长也说明，看热闹的人远不止看热闹的那一类。
home-mixer/ → candidate-pipeline/ → phoenix/ → visibility-filtering/ 的顺序读，先看 home-mixer/params/param.rs 的权重表，那是最直观的入口phoenix/QUICKSTART.md 走，目标是理解两段式架构和训练-服务闭环，而非模型效果Apache-2.0 协议，X 官方背书，四种语言的工业级代码体量。对做推荐系统、内容理解、平台治理的人，这是 2026 年最值得读的一份开源代码。