このドキュメントでは、Vertex AI を使用してエンドツーエンドの 2 タワー候補生成ワークフローを実装する方法を示したリファレンス アーキテクチャについて説明します。Two-Tower モデリング フレームワークは、ウェブクエリや候補アイテムなど、2 つの異なるエンティティ間の意味的類似性を学習するため、パーソナライズ ユースケースに適した強力なリトリーブ手法です。
このドキュメントは、低レイテンシのサービング要件を備えた大規模なレコメンデーション アプリケーションを開発するデータ サイエンティストや ML エンジニアなどの技術担当者を対象としています。2 タワーモデルの構築に使用するモデリング手法、問題のフレーム設定、データ準備の詳細については、TensorFlow Recommender とベクトル検索を使用したディープ リトリーブのスケーリングをご覧ください。
アーキテクチャ
次の図は、Two-Tower モデルをトレーニングし、異なるデプロイ タスクとサービング タスクに応じて各タワーを個別にデプロイするアーキテクチャを示しています。
この図のアーキテクチャには、次のコンポーネントが含まれています。
- トレーニング データ: トレーニング ファイルは Cloud Storage に保存されます。
- Two-Tower トレーニング: 統合された Two-Tower モデルは、Vertex AI Training サービスを使用してオフラインでトレーニングされます。各タワーは別々に保存され、異なるタスクに使用されます。
- 登録済みクエリと候補タワー: タワーがトレーニングされると、各タワーが Vertex AI Model Registry に個別にアップロードされます。
- デプロイされたクエリタワー: 登録されたクエリタワーが Vertex AI オンライン エンドポイントにデプロイされます。
- エンベディングのバッチ予測: 登録された候補タワーは、バッチ予測ジョブで使用され、使用可能なすべての候補アイテムのエンベディング表現を事前計算します。
- エンベディング JSON: 予測されたエンベディングは、Cloud Storage の JSON ファイルに保存されます。
- ANN インデックス: Vertex AI Vector Search を使用して、近似最近傍探索(ANN)用に構成されたサービング インデックスを作成します。
- デプロイされたインデックス: ANN インデックスは Vertex AI ベクトル検索インデックス エンドポイントにデプロイされます。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Vertex AI Training: 大規模なモデル トレーニングを運用できるフルマネージド トレーニング サービス。
- ベクトル検索: 意味的に類似または関連するデータを保存、インデックス化、検索できるベクトル類似性マッチング サービス。
- Vertex AI Model Registry: ML モデルのライフサイクルを管理できる中央リポジトリです。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
ユースケース
低レイテンシでのサービング要件を満たすために、大規模なレコメンダーは多くの場合、2 段階システムとして本番環境にデプロイされます。多段階システムとしてデプロイされることもあります。最初の段階である候補生成の目標は、候補アイテムの膨大なコレクションをふるいにかけ、後工程のフィルタリングとランキング タスクのために関連性の高い数百個のアイテムのサブセットを抽出することです。このリトリーブ タスクを最適化するには、次の 2 つの基本的な目標を検討します。
- モデルのトレーニング中に、解決する問題またはタスクの最適な表現を学習し、この表現を
<query, candidate>
エンベディングにコンパイルします。 - モデルのサービング中に、レイテンシ要件を満たす速さで関連性の高いアイテムを抽出します。
次の図は、2 段階の推奨システムの概念的なコンポーネントを示しています。
この図では、候補の生成で数百万もの候補アイテムがフィルタされています。その後、ランキングによって、数百個の候補アイテムがフィルタされ、数十個のおすすめアイテムが返されます。
このドキュメントのリファレンス アーキテクチャでは、2 つのタワーベースの取得モデルをトレーニングします。このアーキテクチャでは、各タワーがニューラル ネットワークであり、クエリまたは候補アイテムの特徴量を処理して、それらのエンベディング表現を生成します。各タワーは、本番環境で異なるタスクに使用されるため、個別にデプロイされます。
- 候補タワー: 候補タワーは、すべての候補アイテムのエンベディングを事前計算するために使用されます。事前計算されたエンベディングは、低レイテンシの取得用に最適化された Vertex AI Vector Search インデックス エンドポイントにデプロイされます。
- デプロイされたタワー: オンライン サービング中に、デプロイされたクエリタワーは生のユーザークエリをエンベディング表現に変換します。エンベディング表現を使用して、デプロイされたインデックスで類似したアイテムのエンベディングを検索します。
Two-Tower アーキテクチャは、クエリと候補エンティティのセマンティックな関係をキャプチャし、共有エンベディング空間にマッピングするため、多くのリトリーブ タスクに適しています。エンティティが共有エンベディング空間にマッピングされると、意味的に類似したエンティティがクラスタ化されます。したがって、特定のクエリのベクトル エンベディングを計算すると、エンベディング空間内で最も近い(最も類似した)候補アイテムを検索できます。このようなアーキテクチャの主な利点は、クエリと候補の表現の推論を分離できることです。この分離の主なメリットは次の 2 つです。
- 新しいアイテムの語彙を再トレーニングしなくても、新しい(新鮮な)アイテムを配信できます。任意のアイテム特徴セットを候補アイテムタワーにフィードすることで、トレーニング中に遭遇しなかった候補セットのアイテム エンベディングを計算できます。この計算を行うと、コールド スタートの問題に対処できます。
- 候補タワーは、まだおすすめシステムとやり取りしていないアイテムなど、任意の候補アイテムセットをサポートできます。これは、2 つのタワーのアーキテクチャが、各
<query, candidate>
ペアに関するリッチ コンテンツとメタデータ機能を処理するためです。この種の処理により、システムは既知のアイテムの観点から未知のアイテムを記述できます。
- 候補タワーは、まだおすすめシステムとやり取りしていないアイテムなど、任意の候補アイテムセットをサポートできます。これは、2 つのタワーのアーキテクチャが、各
- すべての候補アイテムのエンベディングを事前に計算することで、取得推論を最適化できます。これらの事前計算されたエンベディングは、インデックスに登録して、低レイテンシの取得用に最適化されたサービング インフラストラクチャにデプロイできます。
- タワーの共同学習により、アイテムをクエリの観点から記述したり、その逆を行ったりできます。クエリなど、ペアの片方があり、対応するもう一方のアイテムを検索する必要がある場合は、事前に式の半分を事前計算できます。事前計算により、残りの決定をできるだけ迅速に行うことができます。
設計上の考慮事項
このセクションでは、セキュリティとパフォーマンスのニーズを満たす候補生成アーキテクチャを Google Cloud で開発する際に役立つガイダンスを提供します。このセクションのガイダンスはすべてを網羅しているわけではありません。特定の要件に応じて、追加の設計要素とトレードオフを検討することもできます。
セキュリティ
Vertex AI ベクトル検索は、パブリック エンドポイントと Virtual Private Cloud(VPC)エンドポイントの両方のデプロイをサポートしています。VPC ネットワークを使用する場合は、まず VPC ネットワーク ピアリング接続を設定するをご覧ください。ベクトル検索インデックスが VPC 境界内にデプロイされている場合、ユーザーは同じ VPC ネットワーク内から関連リソースにアクセスする必要があります。たとえば、Vertex AI Workbench から開発する場合は、デプロイされたインデックス エンドポイントと同じ VPC ネットワーク内に Workbench インスタンスを作成する必要があります。同様に、エンドポイントを作成するか、エンドポイントにインデックスをデプロイする予定のパイプラインは、同じ VPC ネットワーク内で実行する必要があります。
パフォーマンスの最適化
このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。
トレーニング ジョブのプロファイリング
データ入力パイプラインと全体的なトレーニング グラフを最適化するには、Cloud Profiler でトレーニング パフォーマンスをプロファイリングすることをおすすめします。プロファイラは、オープンソースの TensorBoard Profiler のマネージド実装です。
トレーニング ジョブで –profiler
引数を渡すことで、TensorFlow コールバックを有効にして、各エポックに設定されたバッチ数をプロファイリングできます。プロファイルは、ホスト CPU とデバイスの GPU または TPU ハードウェアからのトレースをキャプチャします。トレースには、トレーニング ジョブのリソース使用量に関する情報が含まれます。メモリ不足エラーを回避するには、プロファイルの長さを 2 ~ 10 個のトレーニング ステップから始めて、必要に応じて増やすことをおすすめします。
Vertex AI Training と Vertex AI TensorBoard で Profiler を使用する方法については、モデルのトレーニング パフォーマンスをプロファイリングするをご覧ください。デバッグのベスト プラクティスについては、GPU パフォーマンスの最適化をご覧ください。パフォーマンスを最適化する方法については、プロファイラを使用して TensorFlow のパフォーマンスを最適化するをご覧ください。
アクセラレータを最大限に活用する
NVIDIA GPU や Cloud TPU などのトレーニング アクセラレータをアタッチする場合は、アクセラレータを常に最大限に活用することが重要です。アクセラレータはアーキテクチャで最も費用のかかるコンポーネントであるため、トレーニング アクセラレータを最大限に活用することが費用管理のベスト プラクティスです。トレーニング アクセラレータを最大限に活用することも、ジョブの効率化に役立つベスト プラクティスです。アイドル状態がなくなると、全体的なリソース消費量が削減されるためです。
通常、アクセラレータを最大限に活用するには、ボトルネックの特定、ボトルネックの最適化を数回繰り返して、アクセラレータ デバイスの使用率が許容できるレベルになるまでこれらの手順を繰り返します。このユースケースのデータセットの多くはメモリに収まらないほど大きいため、通常、ボトルネックが発生するのはストレージ、ホスト VM、アクセラレータの間です。
次の図は、ML トレーニング入力パイプラインの概念的なステージを示しています。
この図では、データがストレージから読み取られ、前処理されています。データは前処理された後、デバイスに送信されます。パフォーマンスを最適化するには、まず、全体的なパフォーマンスがホスト CPU によって制限されているのか、アクセラレータ デバイス(GPU または TPU)によって制限されているのかを判断します。デバイスはトレーニング ループを高速化しますが、ホストはトレーニング データをデバイスにフィードし、デバイスから結果を受信します。以降のセクションでは、入力パイプラインのパフォーマンスとデバイスのパフォーマンスを改善してボトルネックを解決する方法について説明します。
入力パイプラインのパフォーマンスを改善する
- ストレージからのデータの読み取り: データの読み取りを改善するには、キャッシュ、prefetching、シーケンシャル アクセス パターン、並列 I/O を試してください。
- データの前処理: データの前処理を改善するには、データの抽出と変換に並列処理を構成し、データ入力パイプラインで
interleave
変換を調整します。 - デバイスへのデータの送信: ジョブの全体的な時間を短縮するには、ホストから複数のデバイスにデータを並行して転送します。
デバイスのパフォーマンスを改善する
- ミニバッチ サイズの増加。ミニバッチとは、トレーニング ループの 1 回の反復で各デバイスで使用されるトレーニング サンプルの数です。マイクロバッチサイズを増やすと、オペレーション間の並列処理が増加し、データの再利用が改善されます。ただし、ミニバッチは、残りのトレーニング プログラムとともにメモリに収まる必要があります。ミニバッチサイズを大きくしすぎると、メモリ不足エラーやモデルの分散が発生する可能性があります。
- ユーザー定義関数をベクトル化する。通常、データ変換は、入力データセットの各要素を変換する方法を記述するユーザー定義関数として表現できます。この関数をベクトル化するには、1 つの要素を 1 つずつ変換するのではなく、入力のバッチ全体に変換オペレーションを一度に適用します。ユーザー定義関数には、スケジューリングと実行に関連するオーバーヘッドがあります。入力のバッチを変換する場合、オーバーヘッドはデータセット要素ごとに 1 回ではなく、バッチごとに 1 回発生します。
スケールアウトの前にスケールアップする
トレーニング ジョブのコンピューティング リソースを構成する場合は、スケールアウトする前にスケールアップすることをおすすめします。つまり、低性能のデバイスを複数使用する前に、より大きく強力なデバイスを選択する必要があります。次のようにスケーリングすることをおすすめします。
- 単一ワーカー + 単一デバイス
- 単一ワーカー + より強力なデバイス
- 単一ワーカーと複数のデバイス
- 分散トレーニング
ANN ベクトル検索のレイテンシに対する再現率を評価する
ANN 検索のメリットを評価するには、特定のクエリのレイテンシとリコールを測定します。インデックスのチューニングに役立つように、Vertex AI Vector Search にはブルート フォース インデックスを作成する機能が用意されています。ブルート フォース インデックスは、レイテンシが高くなることを犠牲にして、特定のクエリベクトルの真の最近傍を見つけるために完全検索を実行します。ブルート フォース インデックスは、本番環境での使用を目的としたものではありませんが、インデックス チューニング中に再現率を計算する場合に適したベースラインを提供します。
レイテンシに対する再現率を評価するには、事前計算された候補エンベディングを、ANN 検索用に構成されたインデックスと、ブルートフォース検索用に構成された別のインデックスにデプロイします。ブルートフォース インデックスは絶対最近傍を返しますが、通常は ANN 検索よりも時間がかかります。検索レイテンシの短縮のために検索レコールを犠牲にすることはありますが、このトレードオフは評価する必要があります。再現率とレイテンシに影響するその他の特性には、次のものがあります。
- モデリング パラメータ: 多くのモデリングの決定はエンベディング空間に影響し、最終的にはサービング インデックスになります。シャロー検索モデルとディープ検索モデルの両方から構築されたインデックスに対して取得された候補を比較します。
- ディメンション: ディメンションは、最終的にはモデルによって決定されるもう 1 つの要素です。ANN インデックスのディメンションは、クエリと候補タワー ベクトルのディメンションと一致している必要があります。
- クラウディングとフィルタリングのタグ: タグを使用すると、さまざまな本番環境のユースケースに合わせて結果を調整できる強力な機能を利用できます。タグが取得された候補に与える影響とパフォーマンスへの影響を理解することをおすすめします。
- ANN 数: この値を大きくすると再現率が向上し、それに比例してレイテンシも増加する可能性があります。
- 検索するリーフノードの割合: 検索するリーフノードの割合は、レイテンシと再現率のトレードオフを評価するうえで最も重要なオプションです。この値を大きくすると再現率が向上し、それに比例してレイテンシも増加する可能性があります。
次のステップ
Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Jordan Totten | カスタマー エンジニア
- カスタマー エンジニア | Jeremy Wortz
- Lakshmanan Sethu | テクニカル アカウント マネージャー
その他の寄稿者: Kaz Sato | スタッフ デベロッパー アドボケイト