2026年1月最新版のXのレコメンドシステムについて [2026.03作成]

2026年2,3月頃に公開されたXのレコメンドシステムのコードの内容について自分の勉強用にまとめたスライドです
自己解釈など不明確な点にはご注意ください

Transcript

1. X Recommend SystemのAlgorithmについて 苅山 湊 © 2026 So Kariyama. All rights reserved for original slide content. Third-party figures, screenshots, logos, and code excerpts remain under their respective licenses.
2. 自己紹介 苅山 湊 (かりやま　そう) 東京大学工学部システム創成学科PSIコース 松尾・岩澤研究室　学部4年 大阪大学栁澤研究室　技術補佐員 他三社スタートアップ　エンジニア・研究員 等・・・ 興味範囲： 表現学習、潜在空間　・　生体センシング×AI HP LinkdIn 既存研究： Wifiの波形の歪みパターンから個人識別、動作識別を行うMambaベースモデル 　　　　　 脈波から心電図を推定する生成モデル(Rectified flow)において拍動タイミング条件付け 　　　　　 文埋め込み空間の異方性による統計的バイアスの効果を辞書学習で検証　　　　等...　
3. X Recommend Systemについて Twitterのレコメンドシステムのアルゴリズムは公開されていた 2026年1月20日にXから最新版のレコメンドシステムのアルゴリズムが公開された 旧システムにおける既存解説記事例
4. Twitter時代(2023年公開) X時代(2026年1月公開) 言語 MLモデル 手動特徴量　+　軽量ML Grok-based Transformer Retrieval Earlybird, SimClusters, etc. Two-Tower Model Ranking HeavyRanker (多段特徴量エンジニアリング) Candidate Isolation Transformer In-Network Earlybird (検索エンジンベース) Thunder (インメモリKafkaストリーム) X Reccomend System そもそも、Twitter時点でのシステムに対しての差分を一覧 (Twitter時点のシステムはAppendixに)
5. For You Feed Request Home Mixer Query Hydration User Action Sequence (engagement history) User Features (Following List, Preferences) Candidate Sources Thunder (In-Network Posts) Phoenix Retrieval (Out-of-Network Posts) Hydration Additional: core post metadata, author info, media entities, etc. Filtering muted keywords, blocked authors, self-posts, duplicates, etc. Filtering (Post-selection) visibility filtering (deleted, spam, violence, gore etc.) Selection Sort by Final Score, select TopK candidates Scoring Phoenix Scorer Grok-based Transformer P(like), P(reply), etc. Weighted Scorer Σ (weight × P(action)) Author Diversity Ranked Feed Response X Reccomend System
6. X Reccomend System　ーQuery Hydrationー gRPCリクエスト UserActionSeqQueryHydrator UserFeaturesQueryHydrator Userの行動列 user_action_sequence 入力時に埋まっているフィールド user_id client_app_id country_code language_code seen_ids served_ids in_network_only is_bottom_request bloom_filter_entries ユーザー特徴 user_features １.　UserActionSeqQueryHydrator ユーザーの直近のエンゲージメント履歴を取得・集約する 生ログ Pre-aggregation Filter 派生アクション由来を除外した オリジナルのエンゲージメントのみを保持 時間集約 同一投稿に対する like → reply → retweetなどの 連続アクションを 一定の時間窓でまとめて扱う Post-aggregation Filter 切り詰め 最新N件 一定の閾値で 密なアクションだけ残す 派生とは？ RT経由は派生扱いなのか コードから隠蔽 時間窓自体は隠蔽 閾値自体隠蔽
7. X Reccomend System　ーQuery Hydrationー gRPCリクエスト UserActionSeqQueryHydrator UserFeaturesQueryHydrator Userの行動列 user_action_sequence 入力時に埋まっているフィールド user_id client_app_id country_code language_code seen_ids served_ids in_network_only is_bottom_request bloom_filter_entries ユーザー特徴 user_features 2.　UserFeaturesQueryHydrator ソーシャルな関係構造を取得→フィルタリングやソース選択のための情報を埋め込む ミュートしたキーワード ブロックしたユーザー ミュートしたユーザー フォロー中ユーザー サブスク登録中ユーザー
8. 更新前はIn-NetworkとOut-of-Networkの候補の数の比率が50:50だったが、今回実装では隠蔽されている(互いのmax_resultsの数がパラメータで隠蔽されているため) ＊Default値は2日 max_resultの取得最大数は隠蔽 X Recommend System ーCandidate Sourcesー Thunder Phoenix Retrieval In-Network フォロー中ユーザーの最新投稿を取得 Out-of-Network フォロー外からNNモデルによる候補検索を取得 User featuresを使用する UASを使用し、Two-Towerモデルによる類似度 Dot Product ANNでの高速検索 Post_hash特徴 Author_hash特徴 User Tower Candidate Tower Concat Linear(2D) SiLU Linear(D) L2 Norm Candidate Representation User_hash特徴 History_post hash特徴 History_author hash特徴 History_action 特徴 Product_surface 特徴 Blockユーザー・投稿を削除 Concat User Representation Grok-Transformer Mean pooling + L2Norm
9. 更新前はIn-NetworkとOut-of-Networkの候補の数の比率が50:50だったが、今回実装では隠蔽されている(互いのmax_resultsの数がパラメータで隠蔽されているため) ＊Default値は2日 max_resultの取得最大数は隠蔽 X Recommend System ーCandidate Sourcesー Thunder In-Network フォロー中ユーザーの最新投稿を取得 User featuresを使用する もし、フォローユーザーが多かったら、 特定ユーザーのみの投稿だけ候補生成？ max_per_userパラメータで、その分だけ最大で 取得して、Recencyで並び替えて新しい順に max_result分取得する 極端な例でも、つまりフォローユーザーが5000人いたとして max_per_userが50だったとすると、もし各々が100件以上最新で投稿していてかつそれが 最新で会った場合は50投稿者の投稿のみが渡される形となる ラウンドロビン方式にはなっていないので、1著者あたりの上限分特定の多投稿ユーザーに 偏ることは防がれるが、最新の投稿でかつ活発な投稿者の投稿が候補に入る
10. X Recommend System ーCandidate Sourcesー History_actions特徴について Query Hydrationで整理した actionの投稿毎に19次元の特徴(右図) Product_surface特徴について webなのかiOS, Androidなのか 他特徴については、ハッシュ埋め込み ユーザーを表すハッシュ 投稿を表すハッシュ 投稿者を表すハッシュ 識別子としてのハッシュを与えるだけ
11. X Recommend System ーHydration・Filteringー In-Network Flag テキスト+RT情報 動画長 サブスク著者ID フォロワー数 情報をスコアリング用に追加で付与(並列処理) Filteringは10件 重複削除や古い投稿の削除、既読削除など 古いの定義は隠蔽 2日以上は確定と考えるのが妥当
12. X recommendation System ーScoringー User特徴 ×１ History特徴 ×S Candidates特徴 ×C User_hash post_hash author_hash actions(19次元)→signed product_surface post_hash author_hash product_surface それぞれ線形射影でD次元に圧縮して、まとめてconcat [B, 1+S+C, D] 入力設計について
13. u h1 h2 c1 c2 u 1 0 0 0 0 h1 1 1 0 0 0 h2 1 1 1 0 0 c1 1 1 1 [1] 0 c2 1 1 1 0 [1] X recommendation System ーScoringー Grok-Transformer Candidate Isolation Mask 　このモデルの最重要設計として位置づけられている 　候補間を独立に扱うようAttenitionをmaskすることで 　順序や組み合わせに依存しない historyに関してはcausal (未来情報を参照させない) candidateに関しては独立したattenition Key Query
14. X recommendation System ーScoringー Grok-Transformer 19種類のアクションの確率を独立でsigmoidで出力 詳しいアーキテクチャの解説は別個するかもしれません unembedding行列、及びpre-post norm併用型など 工夫点は多め
15. X recommendation System ーScoringー 得られた19の確率値を重み付き線形結合でスコア化 パラメータは勿論隠蔽 注：動画については隠蔽されているが、 　　max_timeパラメータ以下のものは 　　重み0として扱われているため、 　　短すぎる動画は重み０になる 注：画像や動画があったほうがいいのか？ 　　引数より画像あるのか等の情報は 　　含まれているため追加の正規化の部分として 　　完全に隠蔽されたnormalize_scoreが 　　これらを調整している可能性がある
16. Step1　全候補をweighted score順にソート(降順)、著者毎に出現カウント X recommendation System ーScoringー AuthorDiversityScorer　ー同一著者の多様性ペナルティー Step2　下記の形での計算(floorは下限パラメータ) 「同じ著者の中で何番目か」がpositionで、同じ著者の投稿であれば、 下位のスコアのものを低く補正する(decay, floor, positionは隠蔽) Out-of-Network Scorer　ーout-of-networkの投稿スコアに係数で重み付けー 係数は隠蔽
17. recommned部分だけ抽出 Stage-1： Retrieval (Two-Tower) ユーザーリクエスト Stage-2： Ranking (Transformer) Feed Millions　→ 1000s 1000s → Ranked 具体的な候補数は基本隠蔽されているが、旧システムでは1500だったため、近い値と推察 Phoenix Scorer Wheighted Scorer Author Diversity Scorer OOM Scorer
18. X recommend System　ーSelection・Filteringー TopKでK件スコア上位から取得 In-networkは制限をゆるく、 out-of networkは制限を厳し目にフィルタリングをかける Visibility Filteringは外部サービスへのRPCを伴うために、 Scoringでselection後に実行
19. X recommend System　ー確認事項ー どの時点でも、明示的にテキスト情報やトピック情報については一切考慮されない コンテンツベースでの汎化が困難という設計になっている →これが意図的なのか？ 基本In-Network(フォローしているユーザー)によって新規投稿は発信される Out-of-Networkの投稿はengagementを初期でしっかり集めないと候補にすら上がらない (In-Networkは候補に確実に入り、OONはengagementを稼いでいないと) コンテンツベースで汎化できないので、フォローになんとか食い込む必要がある → 有効な攻撃手段； 例として技術系等でフォローを集めて、フォロワーに入りこんだ上で 　　　　　　　　　 投稿内容を一気に変更する等？ フォローを外されない限り、候補には高確率で入るという強いバイアス(50/50の仮説) ただし、Out-of-Network側の候補生成においては、 著者とその著者の投稿に対するエンゲージメントが最重要で 継続的なエンゲージメントが重要
20. X recommend System　ー確認事項ー 現状のcandidate representationについては、Two-Tower方式を採用した理由が薄い 全候補のスコアリングを行列積1回で完了する計算効率のためだけにTwo-Tower構造が維持 hash値は実質的に著者IDのみ意味的に機能、さらにルックアップテーブルと同値 Grok-transformer側が以下のように著者間の関係をエンゲージメントを通じて関係を学習 著者A (バケット312): ユーザー群X（アニメ好き）がいいねする → embed[312]はユーザー群Xのuser_reprと近くなるよう更新 著者B (バケット8847): ユーザー群X（アニメ好き）がいいねする → embed[8847]もユーザー群Xのuser_reprと近くなるよう更新 結果的に、embed[312]とembed[8847]は「似たユーザーに好まれる」ことを通じて、同じ方向に引っ張られる。 Hash衝突が存在するため、政治ユーザーもアニメユーザーが同一ハッシュに入る場合は 意図しない形での関係性にバイアスが入る (Nが大きいのでこの影響は微量かつ、攻撃も特に困難)
21. X recommend System　ー確認事項ー 基本著者ベースの協調フィルタリング 内容は基本関係しない In-networkとout-of-networkは別個で候補として扱われるため、followの重要性が増す actionsが非常に重要な指標となりTransformerで出力される とにかく読ませる(動画を一定時間見る、滞在時間を一定稼ぐ、何かしらクリックさせる、 画像の拡大表示、リンクをコピーされる等) これらを継続的に多くの人間にさせること自体が最重要で、かつ攻撃対象が行いそうなアク ションを模倣しつつ、見せたい投稿に正のfeedbackをかけ続けてTransformer側を汚染す る攻撃が有効 既存よりかなりブラックボックス化しており、具体的パラメータとしての指標を得づらい アーキテクチャに結果的になっている
22. Appendix. 　旧システム 苅山 湊
23. https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm 旧システム Multi-Stageレコメンドシステム
24. 旧システム 候補生成　ー8つのモジュールー In-Networkから660件　(Earlybird)　 デフォルトで24時間、拡張で48時間が対象 フォローユーザー上限は1500 同一ユーザー投稿最大数は3件まで Real-time (過去7日間) Protected (過去7日間) Archive (2日前~全期間) SuperRoot(検索基盤) １. 公式が手動設計した最重要投稿を優先(Static) ２. キャッシュ済みの候補投稿はそのまま再利用 ３. EarlyBird In-Network(キャッシュが少ない時) ４. Direct UTEG (User-Tweet Entity Graph) フォロー外のユーザーのツイートの探索(GraphJet) 簡単に言えば、二次つながりのユーザーの投稿からエンゲージメントが大きい投稿を取得 24時間以内、最大数300件　重みつきグラフからの集約で推薦するグラフシステム
25. https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm?_fsi=m83DWTb9 旧システム ５.CR-Mixer　 Consumer Producer 14.5万コミュニティ　(Simclusters) フォロー Producer間の類似度(フォロワー集合の)グラフを作成 → Metropolis-Heistingsサンプリングによるコミュニティ検出 →Known for行列を出力
26. 旧システム ５.CR-Mixer　 ユーザー埋め込み： ユーザーがどのコミュニティに興味を持つかを計算 U = A × V - A = フォロー/いいねグラフ（ユーザー-ユーザー隣接行列） - V = KnownFor行列（Producer-コミュニティ対応） - U = InterestedIn行列（ユーザー-コミュニティ興味度） 投稿埋め込み いいねしたユーザーのInterestedInベクトルを加算 ＝ユーザーが主軸なため、汚染が容易 SimClusters ANN
27. 旧システム ５.CR-Mixer　 TwHINグラフについて、ユーザー、投稿、動画の異種ノード、またいいね、返信といった異 種エッジを組み合わせた異種ナレッジグラフからの埋め込み表現を利用する (エンゲージメント16以下は０化しているため閾値) リツイートの拡散構造を予測して、拡散した投稿を候補に入れる構造など、計10種類のシステ ムを並列で回して候補に統合 実験的導入の痕跡等もあるため、simclustersANNを把握しておけばよい？(今となっては更新 済みなためどうだっていいが) 6. Twitterリストから各20個最大100個までツイートを取得 7. Backfill で候補から足りなくなった場合にtimelineから一時的に取得する安全弁 8. Communitiesに所属している場合最大100件まで候補に入れる
28. 旧システム いいね（Favorite） ：0.5 リツイート（Retweet） ：1.0 リプライ（Reply） ：13.5 良質プロフィールクリック（Good Profile Click） ：12.0 動画50%再生（Video Playback 50%） ：0.005 著者が反応するリプライ（Reply Engaged by Author） ：75.0 良質クリック（Good Click） ：11.0 良質クリック v2（Good Click v2） ：10.0 ネガティブフィードバック v2（Negative Feedback v2） ：-74.0 報告（Report） ：-369.0 基本変わらず、MLにより確率を各行動に出力して、重み付けのスコアを出力 show moreで20倍、showlessで 0.05倍 これはcosine類似度が0.67以上の投稿にもこの影響は波及する
29. 旧システム out-of-networkはファクターで0.75にスコアを低減 リプライも0.75で低減 著者多様性の担保のための複数投稿に対する減衰 著者Aの1件目: (1-0.25)×0.5⁰ + 0.25 = 1.000 ← 減衰なし 著者Aの2件目: (1-0.25)×0.5¹ + 0.25 = 0.625 ← 37.5%減 著者Aの3件目: (1-0.25)×0.5² + 0.25 = 0.438 ← 56.2%減 著者Aの4件目: (1-0.25)×0.5³ + 0.25 = 0.344 ← 65.6%減 著者Aの5件目: (1-0.25)×0.5⁴ + 0.25 = 0.297 ← 70.3%減 コンテンツ特徴は多分に埋め込みも含め て手動特徴量としてほとんど組み込み 二次のつながりがあるユーザー以外の投 稿は問答無用で候補から削除される (UTEG候補では)
30. 旧システム この投稿に興味ない系統は140日で回復 時間減衰：ポストの関連性スコアは6時間ごとに半減（半減期360分） 初速の重要性：投稿後30分以内のエンゲージメント速度が大きく影響 フォロー比ペナルティ：フォロー数500以上かつフォロー/フォロワー比率が0.6超の場合、重いペナ ルティが適用 メディアブースト：画像・動画付きポストは2倍のブースト Premium効果：X Premiumユーザーはフォロワー向け4倍、フォロー外向け2倍の露出ブースト 信憑性はわからないが、以下内容
31. Source - xai-org/x-algorithm, GitHub, Apache-2.0 License. 　https://github.com/xai-org/x-algorithm - twitter/the-algorithm, GitHub, AGPL-3.0 License. 　https://github.com/twitter/the-algorithm-ml 　https://github.com/twitter/the-algorithm 　 - X Engineering Blog, “Twitter Recommendation Algorithm,” 2023. 　https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter- recommendation-algorithm?_fsi=m83DWTb9
32. Thank You So Kariyama 本スライドはコード内容に基づいて学習目的でまとめた内容です 内容には誤りや異なる解釈が含まれる可能性があります。 正確な情報は元ソースをご確認ください 🙇‍♂️ © 2026 So Kariyama. All rights reserved for original slide content. Third-party figures, screenshots, logos, and code excerpts remain under their respective licenses.