リアルタイムのリテールインテリジェンス：Databricks上でLakebaseとAI Searchを活用したEコマースレコメンデーションの構築

ビジネスチャンス：収益を牽引するパーソナライズ

買い物客がファッションECアプリで過ごす1秒1秒が、インテントシグナル（検索、商品表示、お気に入りへの追加、カート操作など）の流れを生み出します。これらのシグナルをリアルタイムで適切な商品レコメンデーションに変換できるプラットフォームが、競争を制します。業界のベンチマークによると、効果的なパーソナライズによってコンバージョン率が10〜30%向上し、客単価（平均注文額）が大幅に増加することが示されています。

しかし、本番環境レベルのレコメンデーションシステムを構築することは、依然として最も困難なMLエンジニアリングの課題の1つです。リアルタイムのデータ取り込み、複雑な特徴量エンジニアリング、連携して動作する複数のMLモデル、ミリ秒単位で応答するサービングインフラが必要であり、これらすべてを在庫、位置情報、ビジネスルールと同期させながら行う必要があります。

このブログでは、10万点以上のSKUカタログにわたり月間アクティブユーザー数100万人以上にサービスを提供する、アジアの主要なファッションECプラットフォームでの実際の導入事例に基づき、Databricks上でこのようなシステムを構築するための完全なリファレンスアーキテクチャを紹介します。

システム概要：アーキテクチャの全体像

このアーキテクチャは、取り込みからサービングまでのすべてのコンポーネントがDatabricks上で動作し、Unity Catalogによって管理される、統合プラットフォームアプローチを採用しています。

システム全体のアーキテクチャ：

データ取り込み：クリックストリームからレイクハウスへ数秒で

このプラットフォームは、商品の閲覧、検索、カートへの追加、購入、セッションメタデータなど、1秒あたり約1,000件のイベントを取り込みます。Lakeflow ConnectのZerobus Ingestが取り込みの骨格（バックボーン）を提供し、自主管理のメッセージブローカーを必要とせずに、イベントをUnity CatalogのDeltaテーブルに直接格納します。

アーキテクチャ上の重要な違いとして、クリックストリームデータはオフラインの特徴量計算とモデルトレーニングのためにZerobus経由でレイクハウスに流れますが、リアルタイム推論（パスB）の間は、セッション内のユーザーシグナル（買い物客が今まさに閲覧しているもの）がAPIリクエストのペイロードの一部としてModel Servingエンドポイントに直接送信されます。これにより、推論パスの実行中にレイクハウスストレージを完全にバイパスし、取り込みの遅延を発生させることなくリアルタイムのコンテキストを利用できるようになります。

Zerobusは、簡単な設定変更（ブートストラップサーバーをZerobusエンドポイントに指定するだけ）により、標準的なKafkaプロデューサークライアント（Java、Python、Go）からのデータを受け入れ、レコードをターゲットのDeltaテーブルに格納します。すでにKafkaインフラを運用しているチーム向けには、Structured StreamingとDeclarative Pipelines（宣言型パイプライン）を組み合わせることで、同じダウンストリームアーキテクチャを持つ代替パスを提供します。

データはメダリオンアーキテクチャに流れ込みます：

Bronzeレイヤー — 未加工の追加専用イベントストリームと参照データ：

• ユーザーシグナル：
  • 行動：閲覧シーケンス、検索クエリ、滞在時間のパターン、クリック履歴
  • 取引：購入頻度、平均注文額、返品率、カテゴリ別の支出分布
  • 好み：お気に入り登録された商品、保存された検索、ブランドの好み、サイズ設定
  • デモグラフィック：年齢層、地域クラスター、デバイスタイプ、アプリのエンゲージメント層
• アイテムシグナル：
  • カタログ：カテゴリ階層、ブランド、価格帯、素材、色、季節性
  • パフォーマンス：コンバージョン率、閲覧からカートへの追加率、返品率、平均評価
  • ビジュアル：画像埋め込み（テキスト属性を超えたスタイルの類似性をキャプチャ）
  • 新しさ：掲載からの日数、トレンドの勢い、在庫の推移
• コンテキストシグナル：
  • 時間的要素：時間帯、曜日、給料日への近さ、フェスティバル/セール期間
  • 地理的要素：ユーザーの都市、最寄りのフルフィルメントセンター、地域ごとのスタイルの好み
  • 環境的要素：天気（カテゴリの好みに影響）、地域のイベント
  • セッション：現在の閲覧目的（セッション内の行動から推測）

Silverレイヤー — クリーニング、セッション化、強化済み：

• セッション化されたユーザー行動（閲覧シーケンス、滞在時間、インタラクションパターン）
• クリーニングされた商品特徴量（正規化された属性、カテゴリ階層）
• 集計されたエンゲージメントシグナル（7日間の閲覧数、トレンドスコア、人気指標）
• ユーザーと商品のインタラクションマトリクス（暗黙的なフィードバックシグナル）

Goldレイヤー — モデルに対応した特徴量テーブルとトレーニングデータセット：

• ユーザー特徴量ベクトル（行動埋め込み、好みのプロファイル、デモグラフィッククラスター）
• アイテム特徴量ベクトル（商品埋め込み、属性エンコーディング）
• トレーニングデータセット（モデルトレーニング用のラベル付きインタラクションペア）
• 事前計算されたレコメンデーションリスト（バッチ生成され、高速ルックアップのために保存）

特徴量は異なるサイクルで更新されます。行動集計はスケジュールされたDatabricks Workflowsを通じて毎日更新され、完全な商品カタログは毎週同期されます。ユーザーとアイテムの両方の埋め込みは、変化する好みや新しい在庫を反映するために毎日再計算されます。Databricks Feature Storeは、オフライン特徴量（トレーニング用）とオンライン特徴量（サービング用）の両方を管理し、トレーニングとサービングの一貫性を確保します。これにより、モデルトレーニング中に使用されたものと同じ特徴量定義が、推論時にもLakebaseオンラインテーブルを介して自動的に利用可能になります。

Unity Catalogはすべてのレイヤーを管理し、未加工のクリックストリームイベントからアプリに提供される最終的な予測までのリネージを提供します。きめ細かなアクセス制御により、集計された特徴量がモデルトレーニングにスムーズに流れる一方で、PII（個人を特定できる情報）は確実に保護されます。

リアルタイムサービング：低遅延レスポンスを実現する2つのパス

サービングアーキテクチャは、それぞれ異なるインタラクションパターンに最適化された、2つの補完的なパスを提供します。パスAは、事前計算が可能かつ最適である、大量で予測可能なサーフェス（表示領域）を処理します。パスBは、ユーザーの即座の意図をリアルタイムでレスポンスに反映させる必要がある、動的でセッションを意識したサーフェスを処理します。

パスA — 事前計算されたバッチレコメンデーション（2桁ミリ秒未満）

パスAは、ホームページのカルーセル、カテゴリページのランキング、メールキャンペーン、プッシュ通知など、レコメンデーションサーフェスの大部分に対応します。これらのサーフェスには共通の特徴があります。ユーザーの識別情報とサーフェスタイプが事前にわかっているため、結果を前もって計算しておくことができます。

Databricks Workflowsによってオーケストレーションされる夜間のバッチジョブは、すべてのアクティブユーザーに対してオフラインで完全な3段階のファンネルを実行します。最新のユーザー埋め込みを取得し、AI Searchのアイテムインデックスに対してバッチANNクエリを実行して候補を生成し、Goldレイヤーの特徴量を使用してLightGBMモデルでスコアリングを行い、ビジネスルール（在庫スコアリング、配送の近接性、多様性、プロモーションのブースト）を適用します。出力（通常、サーフェスあたり50〜100アイテムの、ユーザーごとの上位N件のランク付けされた商品リスト）は、ユーザーIDとサーフェスタイプをキーとして、Lakebaseオンラインテーブルに書き込まれます。

サービング時、アプリはシンプルなキーバリュールックアップ（user_id + surface → ランク付けされた商品リスト）を実行します。モデルの推論も、ベクトル検索も、特徴量の組み立て（アセンブリ）も不要で、Lakebaseから直接読み取るだけです。

バッチジョブは夜間に実行されるため、パスAには前日のシグナルと在庫状況が反映されます。ほとんどの表示面（サーフェス）において、この新しさは十分すぎるほどです。長期的な好みやブランドへの親近感は、数分単位ではなく数日かけて変化するものであり、初期エンベディングが生成された新商品も24時間以内にレコメンデーションに表示されます。

パスB — リアルタイムのセッションを考慮したスコアリング（2桁ミリ秒未満）

パスBは、商品詳細ページの「似ている商品」や「コーディネートを完成させる」提案、あるいはユーザーの閲覧行動に合わせて動的に再ランク付けされる検索結果など、リクエスト時にのみレコメンデーションのコンテキストが存在する場合に有効になります。

ECアプリは、ここ数分間に閲覧された商品、アクティブな検索クエリ、カートの内容、滞在時間のパターンなどの現在のセッションシグナルを、REST APIを介してリクエストペイロードとしてModel Servingエンドポイントに直接送信します。エンドポイントは、単一のリクエスト/レスポンスサイクル内で、3段階のファネル全体を同期的に実行します。

• ステージ1 — リアルタイムの候補抽出 エンドポイントは、セッションシグナルをクエリエンベディングに変換します。これは、閲覧中の商品のアイテムエンベディング、または長期的な好みのプロファイル（Lakebaseから取得）とセッション内の行動を融合させ、最近のシグナルをより重視したブレンドユーザーエンベディングのいずれかです。このエンベディングはDatabricks AI Searchに送信され、ハイブリッド検索（ANN類似度検索と、カテゴリの適合性、地域の在庫、最小在庫しきい値などの厳密なメタデータフィルタの組み合わせ）が実行されます。在庫切れの商品や対象外の商品は、候補セットに決して入りません。AI Searchは、1回のネットワーク往復で200〜500個の候補を返します。セッションを考慮する表示面の場合、エンドポイントはブレンドクエリエンベディングを計算します。これは、ユーザーの事前計算された長期的な好みのエンベディング（Lakebaseから取得）と、最近閲覧された商品から派生したセッションエンベディングを組み合わせ、直近の意図を捉えるために最近のシグナルに重みを置いたものです。このブレンドはエンドポイント内で行われる軽量な計算であり、個別のモデル呼び出しではありません。
• ステージ2 — 特徴量の組み立てとスコアリング 候補となるアイテムIDをキーとしてLakebaseオンラインテーブルに対するポイントルックアップが実行され、事前計算されたユーザー特徴量（行動集計、デモグラフィックセグメント、価格感度）とアイテム特徴量（コンバージョン率、トレンドスコア、掲載からの経過日数）が取得されます。リアルタイムのコンテキスト特徴量（時間帯、デバイス、位置情報、アクティブなプロモーション）は、リクエストペイロードから直接導出されます。エンドポイントは、ユーザーと候補のペアごとに特徴量ベクトル（ユーザーとカテゴリの親和性やブランドの好みの重複などのクロス特徴量を含む）を構築し、それらをLightGBMスコアリングモデルに渡します。このモデルは、GPUリソースを使用せずに、1回のバッチ推論呼び出しでコンバージョン確率を予測します。
• ステージ3 — ビジネスルールと再ランク付け スコア付けされたリストは、決定論的な再ランク付けレイヤーを通過します。在庫を考慮したスコアリングによって在庫が減少している商品の優先度を下げ、配送の近接性スコアリングによって迅速なフルフィルメントのために近い倉庫を優先し、多様性の注入によって最終リストで特定のブランドやカテゴリが独占するのを防ぎ、プロモーションブーストによってアクティブなキャンペーンに沿った商品を表示します。再ランク付けされたリストは、リクエストされたサイズ（通常10〜20アイテム）に切り詰められ、APIレスポンスとして返されます。

ビジネスルールは設定駆動型です。プロモーションの重み、多様性のしきい値、在庫のカットオフ値は、サービング時に管理された設定テーブルから読み込まれるため、ビジネスチームはモデルを再デプロイすることなくルールを調整できます。

エンドポイントは、カスタムのMLflow PyFunc modelとして実装されており、単一のpredict()呼び出し内で、AI Searchへのクエリ、Lakebaseのルックアップ、LightGBMの推論の実行、ビジネスルールの適用など、マルチステージパイプラインを内部でオーケストレートします。

フォールバック戦略により、レジリエンスが確保されます。リアルタイムパスがレイテンシ予算を超えた場合、システムは段階的に縮退し、キャッシュされた人気商品や、パスAから事前計算されたユーザー向けレコメンデーションを提供します。

コールドスタート問題への対処

すべてのレコメンデーションシステムは、2つのコールドスタートシナリオに対処する必要があります。

新規ユーザー（閲覧履歴なし）：ユーザーが初めてアクセスした際、システムは利用可能なデモグラフィックシグナル（位置情報、デバイスタイプ、登録時のコンテキスト、明示された好みなど）からデフォルトのユーザーエンベディングを構築します。このエンベディングは、アイテムインデックスに対するANN検索に使用され、新規ユーザーを類似したデモグラフィックの行動クラスターに効果的に配置します。ユーザーが操作を行うにつれて、そのエンベディングは真の好みに向けて急速に収束します。

新商品（インタラクションデータなし）：新しいSKUがカタログに追加されると、システムはその属性（タイトル、カテゴリ、ブランド、価格帯、商品画像から抽出された視覚的特徴など）からアイテムエンベディングを生成します。このエンベディングは、ベクトル空間内の類似する既存商品を見つけるために使用され、新商品は最も近い近傍から初期レコメンデーションスコアを引き継ぎます。新商品は、翌日のバッチサイクルでレコメンデーションに表示されます。

モデルのライフサイクルと継続的な改善

モデルはDatabricks Workflowsを使用して毎週再学習され、実験の追跡とバージョニングはMLflowを通じて管理されます。プラットフォームはチャンピオン/チャレンジャーデプロイをサポートしており、新しいモデルバージョンが本番モデルと並行してデプロイされ、オンラインのパフォーマンス指標に基づいてトラフィックが徐々に移行されます。

監視される主なML指標は以下の通りです。

• AUC-ROC — ユーザーがエンゲージするアイテムとエンゲージしないアイテムをスコアリングモデルが区別する能力を測定します
• NDCG@K（Normalized Discounted Cumulative Gain） — 最も関連性の高いアイテムがランク付けされたリストの上位に表示されているかどうかを評価します
• Recall@K — 候補生成ステージが関連するアイテムのどれだけの割合を正常に取得できたかを測定します
• Log Loss — 予測のキャリブレーションを追跡し、コンバージョン確率スコアが時間の経過とともに適切に調整された状態を維持できるようにします

これらのモデル指標は、ビジネスKPI（クリック率、コンバージョン率、セッションあたりの売上など）によって補完され、モデルの改善が実際のビジネス成果につながっているかどうかの最終的な検証として機能します。

自動化されたドリフト検出は、特徴量の分布や予測スコアの分布がベースラインから逸脱したときにフラグを立て、調査や迅速な再学習をトリガーします。サービングログは、リクエストレベルの識別子を介してトレーニングパイプラインに関連付けられ、フィードバックループが次のモデルイテレーションに向けて、リーケージのないクリーンなトレーニングデータを生成することを保証します。位置を考慮したトレーニング手法により、モデルは表示位置による偏りではなく、ユーザーの真の好みを学習します。

期待される成果

このアーキテクチャにより、以下が可能になります。

• 現代のモバイルファーストの買い物客が期待するパフォーマンスに応える、大規模で2桁ミリ秒台の低レイテンシなパーソナライズされたレスポンス
• 最新の在庫、トレンド商品、変化するユーザーの好みを反映した、毎日更新される新鮮なレコメンデーション
• Unity Catalogによる完全なリネージとアクセス制御を備えた、生のクリックストリームから本番環境の予測にいたるまでの統一されたガバナンス
• 迅速な実験 — 新しいモデルのバリアントを、数ヶ月ではなく数日以内にトレーニング、評価、デプロイ可能
• 運用のシンプルさ — 単一のプラットフォームにより、取り込み、特徴量エンジニアリング、トレーニング、サービングのための個別のシステムをパッチワークのように組み合わせる必要がなくなります
• サーバーレスコンピューティングと管理されたインフラストラクチャを活用し、アーキテクチャを再設計することなく、数千から数百万のユーザーへとスムーズにスケール

まとめ

本番環境レベルのレコメンデーションおよびランキングエンジンを構築するために、もはや十数個もの専門システムを繋ぎ合わせる必要はありません。リアルタイムの取り込み（Zerobus）、特徴量管理（Feature Store + Lakebase）、モデルトレーニング（MLflow + Workflows）、ベクトル検索（AI Search）、低レイテンシのサービング（Model Serving）を、ガバナンスの効いた単一のプラットフォームに統合することで、ECチームは最も重要なこと、すなわち顧客を理解し、適切なタイミングで適切な商品を届けることに集中できます。

その結果、単なるレコメンデーションエンジンにとどまらず、あらゆるEC体験のインテリジェントなバックボーンとして機能する、本番環境に対応した完全なパーソナライズプラットフォームが実現します。

独自のシステムを構築する準備はできましたか？Databricksレコメンデーションエンジンソリューションアクセラレータを探索するか、AI Searchのドキュメントに目を通すか、またはDatabricksのアカウントチームに連絡してアーキテクチャワークショップをご依頼ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事