レコメンデーションシステムのスケーリング

数百万ユーザーへのレコメンデーションシステムのスケーリング

単純な行列分解や協調フィルタリングは数万ユーザーまでは機能しますが、規模が数百万に達すると根本的なアーキテクチャの見直しが必要です。レイテンシ要件（p99で100ms以下）、スループット（秒間数万リクエスト）、更新頻度（準リアルタイム vs 日次バッチ）の3軸を同時に最適化する必要があります。

Spotifyの2023年のブログでは、数億ユーザーへのサービス提供に向けて二段階パイプライン（候補生成＋ランキング）に移行した経緯が説明されています。Netflixも同様のパターンを採用しており、候補生成段階で数百万アイテムから数百件に絞り込み、ランキングモデルで最終的な並び順を決定しています。

近似最近傍探索（ANN）の採用

総当たりの最近傍探索（kNN）は線形時間 O(n×d) であり、数百万アイテムでは非実用的です。ANNアルゴリズムは精度をわずかに犠牲にして対数時間での検索を実現します。

主要な選択肢：HNSW（Hierarchical Navigable Small World）はFaissやhnswlibで実装されており、メモリ効率が高くクエリ速度も速い。IVF（Inverted File Index）はFaissのIVFFlat/IVFPQで利用可能で、大規模データセットに適しています。LSH（Locality Sensitive Hashing）はストリーミングシナリオに向きますが精度はやや劣ります。実運用ではHNSWがデフォルト選択肢となることが多く、recall@10で95%以上、p99レイテンシ5ms以下を達成できます。

量子化とシャーディング

512次元のfloat32埋め込みは1ベクトルあたり2KBを消費します。1億アイテムなら200GB、これはシングルマシンのRAMを超えます。積量子化（PQ）は埋め込みを16〜32バイトに圧縮でき、メモリを10〜20倍削減できます。FaissのIVFPQはこれを効率よく実装しています。シャーディングにより、各シャードが全カタログのサブセットを担当し、ファンアウト検索で全シャードに並列クエリを発行します。

二段階検索パイプラインの設計

候補生成フェーズ

候補生成の目的は数百万アイテムから数百〜数千件の有望な候補を高速に絞り込むことです。一般的な手法：（1）ユーザー埋め込みによるANN検索、（2）ユーザーが過去に操作したアイテムの類似アイテム取得（item-to-item CF）、（3）人気度や新着に基づくルールベースの候補。複数のソースを組み合わせることで再現率を向上させます。

ランキングフェーズ

ランキングモデルはより多くの特徴量を使って候補リストを精緻化します。特徴量例：ユーザー属性（年齢、地域、登録日数）、アイテム属性（ジャンル、人気度、鮮度）、コンテキスト（時刻、デバイス、セッション内の行動）、インタラクション履歴（過去のCTR、視聴率）。モデルとしてはXGBoost、LightGBM、あるいはTwoTower DNNが使われます。推論時間は候補1件あたり1ms以下が目安です。

埋め込みの事前計算と特徴量ストア

埋め込みの更新戦略

ユーザー埋め込みは行動ログを処理してバッチ更新（1〜24時間ごと）するのが一般的です。Spark MLまたはKafka Streamsでリアルタイムに更新することも可能ですが、インフラコストが増大します。アイテム埋め込みは新着コンテンツのみを差分更新し、全再計算は週次で行うのが効率的です。

特徴量ストアの役割

特徴量ストア（Feast、Tecton、Redis+Hive）はトレーニングとサービングで同じ特徴量を使えることを保証します。オンラインストア（Redis、DynamoDB）は低レイテンシ（<10ms）でのリアルタイム特徴量取得に使い、オフラインストア（S3、BigQuery）はトレーニングデータの生成に使います。特徴量のポイントインタイム結合を正しく実装しないと学習/サービング乖離（training-serving skew）が生じ、オフラインメトリクスは良くても本番で悪化する典型的な落とし穴になります。

インフラ構成とサービング

モデルサービングの選択肢

TensorFlow ServingまたはTorchServeはディープランキングモデルに適します。軽量モデル（XGBoost）はFastAPIやカスタムgRPCサービスで直接サービングできます。Triton Inference Serverは複数フレームワークのモデルを統合管理でき、GPUバッチ処理もサポートします。モデルのバージョン管理とA/Bテストのロールアウトを考慮したデプロイ設計が重要です。

キャッシュ戦略

レコメンデーション結果のキャッシュ（Redis、Memcached）は高トラフィック環境で必須です。TTLは新鮮さとコストのトレードオフです：ニュースは15分、映画は1時間、音楽は4時間が一般的な目安です。ユーザーセグメントごとに事前計算したレコメンデーションをウォームキャッシュとして保持し、キャッシュミス時にリアルタイム計算にフォールバックするパターンが実運用で広く使われます。

モニタリングとフィードバックループ

本番メトリクスの設計

オフラインメトリクス（NDCG、Precision@K、Recall@K）は開発中の指標として有用ですが、本番のビジネス指標（CTR、コンバージョン率、セッション長、リテンション）と必ずしも相関しません。両方を測定し、定期的にオフライン指標のビジネス指標への予測力を検証することが重要です。

データ品質とドリフト監視

埋め込みの分布シフト（コンセプトドリフト）を監視します。ユーザー行動の季節変動やトレンド変化により、古いモデルはパフォーマンスが劣化します。埋め込みの余弦類似度分布、特徴量の統計的分布（平均、分散）をPrometheusやDatadogで継続的に追跡し、有意なドリフトを検出した場合は自動リトレーニングをトリガーします。

まとめ：スケーラブルなレコメンデーションシステムを構築するためのチェックリスト

10万ユーザー以下ではシンプルなCollaborative Filtering + Redis キャッシュで十分です。100万を超えたらANN（HNSW）と二段階パイプライン（候補生成＋ランキング）への移行を検討してください。特徴量ストアで学習/サービング乖離を防ぎ、オフラインとオンラインの両メトリクスを常に測定します。段階的に複雑さを増やすことが、過剰エンジニアリングを避ける最善策です。