Metaが広告推薦にLLM型スケーリング則を持ち込んだ話 — マルチステージ・シーケンスモデルの解説

なぜ今、シーケンスモデリングなのか

広告推薦システムは、毎日数十億件のユーザーインタラクションを処理します。クリック・閲覧・購入といった行動の順序とタイミングをそのまま学習すれば、手作業で設計した静的な特徴量よりもはるかに豊かなユーザー関心表現が得られる——これは以前から知られていた事実です。

問題はスケールです。ハイブリッド構成(シーケンスモデル + 別系統の疎な特徴量モデル)はプロダクション要件は満たせますが、構造的に3つのトレードオフを抱えます。

• コンポーネント間の損失を伴う知識転送(lossy knowledge transfer)
• 依然として残る手作業の特徴量エンジニアリングへの依存
• ランキングモデルとシーケンスモデル間の干渉(interference)によるスケーリング上限

シーケンス長とTransformerの規模を同時に拡大すると、このトレードオフがボトルネックになります。そこでMetaが打ち出したのがマルチステージ・シーケンスモデルです。

根拠資料: From user sequences to scaling laws (Meta Engineering)

日本の推薦システム開発現場でも同様の悩みは一般的です。特にEC/広告ドメインで、リアルタイムランキングのレイテンシ予算が厳しいのにモデルは拡大したい、という状況であれば、この設計は現実的な参考になります。

マルチステージ・シーケンスモデル: オフラインとオンラインを分離する

核心はシンプルです。重いユーザーモデリングはオフライン、軽量なランキングはオンラインに分離する。2つのステージはそれぞれ別の目的に最適化されます。

第1ステージ: オフラインユーザーモデル(Upstream)

• ユーザー履歴を**非同期(async)**で処理
• 数千長のシーケンスを扱う深いTransformerレイヤスタック
• 結果をユーザーレベルの埋め込みとしてキャッシュ
• ユーザー特徴量と広告/コンテキスト特徴量を厳密に分離し、埋め込みが特定の広告候補に依存しないことを保証

第2ステージ: オンラインランキングモデル(Downstream)

• キャッシュ済みユーザー埋め込み + リアルタイムのユーザーシグナル + 広告候補情報を結合
• 厳しいレイテンシ予算内で動作するよう速度最適化
• オフラインで計算済みの深い表現力をそのまま活用

# 概念的疑似コード: マルチステージパイプライン
class OfflineUserModel:
    def __init__(self, num_layers: int, seq_len: int):
        self.transformer = DeepTransformer(layers=num_layers, max_len=seq_len)

    def compute_embedding(self, user_history: list) -> "Tensor":
        # ユーザー履歴のみを使用。広告/コンテキスト特徴量は絶対に混ぜない。
        return self.transformer.encode(user_history)


class OnlineRankingModel:
    def __init__(self, ranking_head):
        self.head = ranking_head

    def rank(self, cached_user_emb, ad_candidate, realtime_signals):
        # キャッシュ済みユーザー表現 + リアルタイムシグナル + 広告候補を結合してスコア算出
        fused = fuse(cached_user_emb, ad_candidate, realtime_signals)
        return self.head(fused)


# サービングパイプライン
user_emb = offline_model.compute_embedding(user_history)  # 非同期・キャッシュ済み
for ad in candidate_ads:
    score = online_model.rank(user_emb, ad, realtime_signals)  # ミリ秒予算

この分離の真の効果は、計算曲線を分離できる点にあります。オフラインモデルはレイテンシ制約がないため自由に拡大でき、オンラインランキングモデルはサービング予算内でのみチューニングすればよい。結果として、モデル複雑度とサービングコストを独立にスケールできます。

2つのアーキテクチャ革新

Dense Tokenization

従来の推薦システムは、疎な特徴量間の相互作用を手作業の表現で捉えていました。このアプローチは疎な特徴量とシーケンス行動データを単一のdense vocabularyに統合し、Attentionメカニズムが相互作用をデータから直接学習できるようにします。

Target-Aware Multi-Head Attention

トークン化された疎な特徴量 + 広告候補情報をユーザー行動シーケンスと融合し、メモリ効率の良いMulti-Head Attentionで処理します。各レイヤーがユーザーの過去行動をスコアリング対象の広告に照らして重み付けできる構造です。安定したAttention分布で複数のブロックを積み重ねることで、長いシーケンスが段階的に**コンパクトな表現へ蒸留(distill)**されます。

実務感覚で言えば、「特徴量エンジニアリングをモデルに代替させる」方向性と同じです。ただし初期学習コストとデータパイプラインの複雑度は確実に上がるため、チームの力量とデータ規模をまず冷静に見極める必要があります。

スケーリング則: 本当のレバーは何か

Metaの公開結果で最も注目すべきは、LLM型のログ線形(log-linear)スケーリング則が広告推薦でも観測された点です。計算量(FLOPs)が増えるほど、性能(正規化エントロピー、NE)が予測可能に改善するということです。

実測インパクト

• Instagram コンバージョン +6%
• Facebook コンバージョン +3%
• Facebook 広告クリック +3.5%

これらの数値は他のモデル革新との合算による累積リフトである点に注意が必要です。単一アーキテクチャ変更の効果として読むと過大解釈になります。

この技術の限界と注意点

• オフライン埋め込みのstaleness: キャッシュ済みユーザー埋め込みはリアルタイム行動を反映できません。キャッシュ無効化戦略とTTL設計が性能の半分を決めます。
• コールドスタートユーザー: 履歴が短い新規ユーザーはオフラインモデルの恩恵をほとんど受けられません。セマンティック特徴量が一部を補いますが、完全な解決策ではありません。
• 運用複雑度の増加: 2つのモデル、2つのデプロイパイプライン、埋め込みストアまで。チーム規模が小さいと逆に毒になり得ます。
• 評価指標の解釈: NE(正規化エントロピー)の改善がそのままビジネス指標の改善に繋がるかは別途検証が必要です。

日本の開発現場では特に、個人情報保護法制とログ保持ポリシーのため、長いシーケンスをそのまま使うのが難しいケースがあります。シーケンス長を伸ばす戦略を立てる際は、法務/プライバシーチームと早い段階で擦り合わせておくのが安全です。

まとめ: 何を持ち帰るか

Metaのこの事例から実務的に持ち帰れる点は3つです。

1. 構造分離こそがスケーリング戦略である。 重い計算をオフラインに追い出し、オンラインを薄く保つパターンは、広告に限らず検索・フィード・通知ランキングなどレイテンシに敏感なあらゆるシステムに応用できます。
2. シーケンスは長さより多様性が先。 シーケンス長だけを伸ばすのはコスト対効果が悪化しがちです。アクションタイプを混ぜることから始めましょう。
3. スケーリング則とは予測可能性である。 ログ線形の曲線が見えるということは、「いくら投資すればどれだけ良くなるか」を事前に推定できるということです。これは組織説得において強力な武器になります。

このアーキテクチャはGEM(Generative Ads Recommendation Model)の中核コンポーネントとして位置づけられており、著者らはスケーリング則がまだ飽和していないと述べています。次のステップとしては、MoE(mixture-of-experts)、cross-user計算共有、高度なAttention機構など、LLMで検証済みの手法を推薦ドメインに移植する方向が有力です。

次の学習ステップ

• LLMスケーリング則の原論文を先に読み、ログ線形関係とChinchilla最適点の概念を理解しましょう。
• Two-Tower / Retrieval-Ranking分離アーキテクチャを自分で実装すると、この記事の「分離」概念がなぜ強力か体感できます。
• 埋め込みキャッシュストア(例: Redis, Feast)の運用経験を積んでおくと、オフライン/オンライン分離設計が格段に楽になります。

あわせて読みたい

• PDF 의료 기록을 FHIR 데이터로 자동 변환하는 서버리스 파이프라인 구축 가이드 (Bedrock + HealthLake) — 非同期パイプライン設計の感覚を同時に養える実践的な記事です。
• 개인화와 실험은 왜 별도의 기술 스택이 필요한가? (스포티파이의 인사이트) — 本記事と全く同じ問題意識(パーソナライゼーションスタックの分離)を別の角度から扱っています。