リアルタイムレコメンデーションとバッチレコメンデーションの比較

リアルタイムレコメンデーションとバッチレコメンデーションの比較

レコメンデーションシステムは「いつ計算するか」の観点から大きく二つに分類されます。バッチシステムは定期的（毎時、毎日）にオフラインで計算し結果をストアします。リアルタイムシステムはユーザーのリクエスト時点で動的に計算します。多くの本番システムはハイブリッドアーキテクチャで、バッチとリアルタイムの両方の利点を活かします。

バッチレコメンデーションのアーキテクチャ

パイプライン設計

典型的なバッチパイプライン：（1）データウェアハウス（BigQuery、Redshift）からユーザー行動データを抽出、（2）Spark/Beam等の分散処理フレームワークで特徴量計算と推薦スコア生成、（3）結果をKVストア（DynamoDB、Redis）に書き込み、（4）サービングAPIはKVストアから事前計算結果をルックアップして返却。Apache AirflowやPrefectでスケジュール管理します。

バッチの強みと限界

強み：インフラコストが低い（バッチ処理はスポットインスタンスで安価に実行可能）、複雑なモデル（行列分解、深層学習）を制限なく使用可能、デバッグとモニタリングが容易、サービングレイテンシが極めて低い（KVルックアップで<5ms）。限界：セッション内の直前行動を反映できない（Netflixで「今見たばかりのコンテンツと似たもの」をすぐ推薦できない）、カタログ変化（新着コンテンツ）への反応が遅い、ユーザー数×アイテム数のスコア行列は巨大になる。

リアルタイムレコメンデーションのアーキテクチャ

セッション内行動の即時反映

リアルタイムシステムはKafkaやKinesis等のストリーミングプラットフォームでユーザーイベントを受信し、セッションウィンドウ内でユーザーの最新状態を更新します。セッションベースのレコメンデーション（RNN、Transformer、GRU4Rec）はユーザーIDなしで直前の行動シーケンスのみから次のアクションを予測します。TikTokのFYPはリアルタイムシグナル（視聴完了率、再視聴）を秒単位で反映します。

リアルタイムの技術スタック

イベントストリーム：Apache Kafka（Confluent Cloud）またはAWS Kinesis。ストリーム処理：Apache Flink（複雑なウィンドウ処理）またはKafka Streams（シンプルな変換）。リアルタイム特徴量ストア：Redis（低レイテンシ読み取り、TTL付きユーザーセッション特徴量）。ANN検索：PineconeまたはQdrantのマネージドサービス（クエリp99 <20ms）。モデルサービング：FastAPI + ONNX Runtime（Pythonモデルをプロダクションに最適化）。

ハイブリッドアーキテクチャ：Lambda/Kappa アーキテクチャ

Lambdaアーキテクチャパターン

Lambdaアーキテクチャでは、バッチレイヤー（精度重視）とスピードレイヤー（鮮度重視）を並行させ、サービングレイヤーで統合します。実際のレコメンデーション例：バッチで計算した長期嗜好スコアにリアルタイムセッション特徴量を組み合わせます。例：バッチスコア0.7×（ユーザーの長期的な好み）+リアルタイムスコア0.3×（直前30分の行動）= 最終スコア。

使い分けの判断基準

バッチが適するケース：長編動画（Netflix）、音楽プレイリスト（Spotify）、ECの「あなたにおすすめ」（Amazon）。ユーザー嗜好が安定しており、数時間の遅延が許容されます。リアルタイムが必要なケース：ニュースフィード、ソーシャルメディア（Twitter、TikTok）、検索結果の動的再ランキング。セッション内の急激な興味変化への対応が必須です。ハイブリッドが最適なケース：ほぼすべての大規模本番システム。バッチで候補を生成し、リアルタイムで再ランキング。

レイテンシ要件とSLAの設計

ページレンダリングとの関係

レコメンデーションAPIがページレンダリングのクリティカルパスにある場合、p99レイテンシは50〜100ms以内が目標です。Googleの調査では100ms遅延ごとにコンバージョンが約1%低下します。タイムアウト戦略：リアルタイム計算が100ms以内に完了しない場合はバッチ結果にフォールバックします。非同期ローディング（ページ表示後にレコメンデーションウィジェットを遅延ロード）もユーザー体験を損なわず遅延を吸収する手法です。

コストとパフォーマンスのトレードオフ

リアルタイム推薦はバッチ推薦より5〜20倍のインフラコストがかかります。ROI分析：リアルタイム化によるCTR向上（通常5〜15%）がインフラコスト増加を正当化するか検証します。段階的移行：まずバッチから始め、リアルタイム化が最もインパクトをもたらすコンテキスト（直後の関連アイテム推薦など）に絞って部分的に導入するのが実用的なアプローチです。

まとめ

リアルタイムvsバッチの選択は技術的な問題であるとともにビジネス上の意思決定です。ユーザーの行動がセッション内で急激に変化するサービス（ニュース、ソーシャル）はリアルタイムから始め、安定した嗜好のサービス（映画、音楽プレイリスト）はバッチから始めます。多くの場合、シンプルなバッチシステムを本番稼働させてから、測定可能な改善機会に基づいてリアルタイム化を追加するアプローチが最も効率的です。