このドキュメントでは、 Google Cloudで ML を実装するためのベスト プラクティスを紹介します。データとコードに基づいたカスタム トレーニング モデルに重点を置いています。主なアクションや詳細情報のリンクなど、ML ワークフロー全体でカスタム トレーニング モデルを開発する方法に関する推奨事項を示します。
このドキュメントでは、ML ワークフローの次の段階について説明します。
- ML 開発: ビジネス上の問題を解決するモデル プロトタイプを設計、テスト、開発します。
- データの準備: 元データからノイズをクリーンアップし、特徴量をエンジニアリングして、モデルに高品質で高シグナルの入力が確実に提供されるようにします。
- ML トレーニング: データセットに対してトレーニング スクリプトを実行し、パフォーマンス指標が要件を満たすまでモデル パラメータを最適化してハイパーパラメータを調整します。
- モデルのデプロイとサービング: モデルを本番環境にデプロイし、API またはコンテナを介してユーザー アクセスを提供します。
- ML ワークフロー オーケストレーション: データの取り込みからデプロイまで、ML ワークフローをスケジュールするエンドツーエンドのパイプラインを自動化します。
- アーティファクトの整理: すべてのデータセット、モデルファイル、構成を一元化されたレジストリに記録してバージョン管理します。
- モデル モニタリング: ダッシュボードを使用して、モデルのライブ パフォーマンスとパフォーマンスのドリフトを追跡します。
このドキュメントは、すべての推奨事項を網羅したものではありません。目的は、データ サイエンティストと ML アーキテクトが、 Google Cloud での ML の使用に関連するアクティビティの範囲を把握し、それに応じて計画できるようにすることです。また、AutoML などの代替 ML 開発については、推奨ツールとプロダクトの使用で説明していますが、このドキュメントではカスタム トレーニング モデルに主に焦点を当てています。
このドキュメントのベスト プラクティスを実施する前に、Gemini Enterprise Agent Platform の概要を読むことをおすすめします。
このドキュメントの前提条件は次のとおりです。
- 主に Google Cloud サービスを使用する。ここでは、ハイブリッド アプローチとオンプレミス アプローチについては説明しません。
- トレーニング データを収集し、 Google Cloudに保存する。
- ML、ビッグデータ ツール、データ前処理に関する中級レベルの知識と、Cloud Storage、BigQuery、Google Cloud の基礎知識を持っている。
ML を初めて使用する場合は、Google のML 集中講座をご覧ください。
推奨されるツールとプロダクトを使用する
次の表に、このドキュメントで説明する ML ワークフローの各フェーズで推奨されるツールとプロダクトを示します。
| ML ワークフローのステップ | 推奨ツールとプロダクト |
|---|---|
| ML 環境の設定 | |
| ML の開発 | |
| データの準備 | |
| ML トレーニング | |
| モデルのデプロイとサービング | |
| ML ワークフローのオーケストレーション | |
| アーティファクトの整理 | |
| モデルのモニタリング | |
| マネージド オープンソース プラットフォーム |
Google は、Agent Platform カスタム トレーニング モデル ソリューションに代わる事前構築済みのトレーニング ルーチンとして、AutoML、Agent Platform による予測、BigQuery ML を提供しています。次の表に、これらのオプションや Agent Platform を使用する場合の推奨事項を示します。
| ML 環境 | 説明 | この環境を選択すべきケース |
|---|---|---|
| BigQuery ML | BigQuery ML でデータ、インフラストラクチャ、事前定義されたモデルタイプが 1 つのシステムにまとめられている。 |
|
| AutoML（Agent Platform のコンテキスト） | AutoML には、画像分類や表形式の回帰などの一般的な問題のトレーニング ルーチンが用意されています。アーキテクチャの選択、ハイパーパラメータ チューニング、マシンのプロビジョニングなど、モデルのトレーニングとサービス提供のあらゆる局面が自動的に処理されます。 |
|
| Agent Platform カスタム トレーニング済みモデル | Vertex では、独自のカスタム トレーニング ルーチンを実行し、サーバーレス アーキテクチャ上であらゆるタイプのモデルをデプロイできます。Agent Platform では、ハイパーパラメータのチューニングやモニタリングなどの追加サービスが提供されるため、モデルの開発が容易になります。カスタム トレーニング方法を選択するをご覧ください。 |
|
ML 環境の設定
ML 環境を設定する場合は、次のベスト プラクティスを使用することをおすすめします。
- テストと開発に Agent Platform Workbench インスタンスを使用する。
- チームメンバーごとに Agent Platform Workbench インスタンスを作成する。
- 企業のポリシーに基づいて ML リソースとアーティファクトを保存する。
- Agent Platform SDK for Python を使用する。
テストと開発に Agent Platform Workbench インスタンスを使用する
使用しているツールを問わず、Agent Platform Workbench インスタンスを使用して、テストと開発（コードの作成、ジョブの開始、クエリの実行、ステータスの確認など）を行うことをおすすめします。Agent Platform Workbench インスタンスを使用すると、 Google Cloudのすべてのデータと AI サービスに簡単かつ再現可能な方法でアクセスできます。
Agent Platform Workbench インスタンスには、直ちに使用を開始できる一連の安全なソフトウェアとアクセス パターンが用意されています。ネットワーク、Identity and Access Management などのGoogle Cloud プロパティや、（コンテナを経由して）Agent Platform Workbench インスタンスに関連付けられているソフトウェアをカスタマイズするのが一般的な方法です。詳細については、Agent Platform の概要と Agent Platform Workbench インスタンスの概要をご覧ください。
また、Colab Enterprise を使用することもできます。これは、 Google Cloudのセキュリティ機能とコンプライアンス機能を備えたコラボレーション指向のマネージド ノートブック環境です。
チームメンバーごとに Agent Platform Workbench インスタンスを作成する
データ サイエンス チームの各メンバー用に Agent Platform Workbench インスタンスを作成します。チームメンバーが複数のプロジェクト、特にさまざまな依存関係があるプロジェクトに関与している場合は、複数のインスタンスを使用し、各インスタンスを仮想ワークスペースとして扱うことをおすすめします。Agent Platform Workbench インスタンスは、使用されていない場合は停止できます。
企業のポリシーに基づいて ML リソースとアーティファクトを保存する
最も簡単なアクセス制御は、未加工のデータと Agent Platform のリソースやアーティファクト（データセットやモデルなど）を同じ Google Cloud プロジェクトに保存することです。一般的に、企業にはアクセスを制御するポリシーがあります。リソースとアーティファクトがプロジェクトをまたいで保存されている場合は、Identity and Access Management（IAM）を使用して、プロジェクト間の企業アクセス制御を構成できます。
Vertex AI SDK for Python を使用する
Agent Platform をエンドツーエンドのモデル構築ワークフローに使用するために、Agent Platform SDK for Python を使用します。これは、PyTorch、TensorFlow、XGBoost、scikit-learn などの使い慣れた ML フレームワークとシームレスに連携します。
または、ブラウザを介するユーザー インターフェースとして Agent Platform の機能をサポートする Google Cloud コンソールも使用できます。
ML の開発
ML 開発には、次のベスト プラクティスをおすすめします。
トレーニング データを準備する。
構造化データと半構造化データを BigQuery に保存する。
画像、動画、音声、非構造化データを Cloud Storage に保存する。
構造化データには Agent Platform Feature Store を使用する。
Gemini Enterprise Agent Platform の Vertex AI TensorBoard と Experiments を使用してテストを分析する。
Agent Platform Workbench インスタンスの内部で小規模データセット用のモデルをトレーニングする。
ハイパーパラメータ チューニングを使用してモデルの予測精度を最大化する。
Agent Platform Workbench インスタンスを使用してモデルを理解する。
特徴アトリビューションを使用してモデル予測の分析情報を取得する。
ML 開発では、データの準備、テスト、モデルの評価を行います。ML の問題を解決するには、通常、さまざまなモデルを構築して比較し、何が最適かを見極める必要があります。
通常、データ サイエンティストは、さまざまなアーキテクチャ、入力データセット、ハイパーパラメータ、ハードウェアを使用してモデルをトレーニングします。データ サイエンティストは、テスト データセットの精度、適合率、再現率などの集計パフォーマンス指標を通して、結果として得られるモデルを評価します。最後に、データ サイエンティストは、データの特定のサブセット、さまざまなモデル バージョン、さまざまなモデル アーキテクチャに対してモデルのパフォーマンスを評価します。
トレーニング データを準備する
モデルのトレーニングに使用するデータは、オンライン サービス システムのログ、ローカル デバイスの画像、ウェブからスクレイピングされたドキュメントなど、任意の数のシステムから取得できます。
データの出所に関係なく、ソースシステムからデータを抽出し、ML トレーニング用に最適化された形式とストレージ（稼働中のソースとは別）に変換します。Agent Platform で使用するトレーニング データの準備の詳細については、独自のモデルをトレーニングして使用するをご覧ください。
構造化データと半構造化データを BigQuery に保存する
構造化データまたは半構造化データを扱う場合は、プロジェクト構造に対する BigQuery の推奨事項に従ってすべてのデータを BigQuery に保存することをおすすめします。ほとんどの場合、中間の処理済みデータも BigQuery に保存できます。速度を最大化するには、トレーニング データのビューやサブクエリを使用する代わりに、実体化されたデータを保存することをおすすめします。
BigQuery Storage API を使用して BigQuery からデータを読み取ります。アーティファクト トラッキングの場合は、表形式のマネージド データセットの使用を検討してください。次の表に、API を使いやすくするための Google Cloud ツールを示します。
| 以下を使用している場合 | 使用する Google Cloud ツール |
|---|---|
| TensorFlow for Keras | BigQuery 用の tf.data.dataset リーダー |
| TFX | BigQuery クライアント |
| Dataflow | Google BigQuery I/O コネクタ |
| その他のフレームワーク（PyTorch、XGBoost、scikit-learn など） | BigQuery でのモデルのインポート |
画像、動画、音声、非構造化データを Cloud Storage に保存する
これらのデータは Cloud Storage に大規模なコンテナ形式で保存します。これは、シャーディングされた TFRecord ファイル（TensorFlow を使用している場合）または Avro ファイル（他のフレームワークを使用している場合）に適用されます。
個々の画像、動画、音声クリップを大規模なファイルに結合すると、Cloud Storage に対する読み取りと書き込みのスループットが向上します。100～10,000 個のシャードを含む、100 MB 以上のファイルにします。
データ マネジメントを有効にするには、Cloud Storage バケットとディレクトリを使用してシャードをグループ化します。詳細については、Cloud Storage のプロダクト概要をご覧ください。
Google Cloud コンソールで Data Labeling Service を使用する
トレーニング データの作成とインポートは、 Google Cloud コンソールの Agent Platform ページから行えます。Gemini のプロンプトとチューニング機能を使用すると、カスタマイズされた分類、エンティティ抽出、感情分析を使用してテキストデータを管理できます。 Google Cloud コンソールの Marketplace には、Labelbox や Snorkel Flow などのデータラベル付けソリューションもあります。
構造化データに Agent Platform Feature Store を使用する
Feature Store を使用すると、ML 特徴を一元的な場所で作成、維持、共有、サービングできます。これは低レイテンシが必要なワークロードをサービングするように最適化されており、特徴データを BigQuery のテーブルまたはビューに保存できます。Agent Platform Feature Store を使用するには、オンライン ストア インスタンスを作成し、特徴ビューを定義する必要があります。BigQuery には、オフラインで作業できるように過去の特徴データを含むすべての特徴データが保存されます。
Gemini Enterprise Agent Platform の Vertex AI TensorBoard と Experiments を使用してテストを分析する
モデルを開発する際に Vertex AI TensorBoard を使用して、ハイパーパラメータなどに基づいて特定のテストを視覚化して比較します。Vertex AI TensorBoard は、エンタープライズ対応のマネージド サービスで、費用対効果に優れ、データ サイエンティストと ML 研究者がテストをシームレスに追跡、比較、共有してコラボレーションできる安全なソリューションです。Vertex AI TensorBoard を使用すると、損失や精度などのテスト指標の経時的な追跡、モデルグラフの可視化、下位次元スペースへのエンべディングの投影などを行えます。
Agent Platform の Experiments を使用して Vertex ML Metadata とのインテグレーションを実行し、パラメータ、指標、データセット、モデル アーティファクト間のリンクを記録して構築します。
Agent Platform Workbench インスタンスの内部で小規模データセット用のモデルをトレーニングする
小規模なデータセットや大規模なデータセットのサブセットでは、Agent Platform Workbench インスタンス内でモデルをトレーニングするだけで十分な場合もあります。大規模なデータセットや分散トレーニングには、トレーニング サービスを使用すると便利です。トレーニングをスケジュールに沿って行う場合や、追加データの受信に応じて行う場合は、小規模なデータセットでも、Gemini Enterprise エージェント プラットフォームのマネージド トレーニング サービスを使用してトレーニングを提供する方法をおすすめします。
ハイパーパラメータ チューニングを使用してモデルの予測精度を最大化する
モデルの予測精度を最大化するには、Gemini Enterprise Agent Platform Managed Training サービスが提供する自動モデル拡張機能であるハイパーパラメータ チューニングを使用します。この機能では、 Google Cloud と Vertex AI Vizier の処理インフラストラクチャを活用して、モデルのトレーニング時にさまざまなハイパーパラメータ構成をテストします。ハイパーパラメータ チューニングにより、最適な値を得られるまで多くのトレーニングを実行する過程で、ハイパーパラメータを手動で調整する必要がなくなります。
ハイパーパラメータ チューニングの詳細については、ハイパーパラメータ チューニングの概要とハイパーパラメータ チューニング ジョブを作成するをご覧ください。
Agent Platform Workbench インスタンスを使用してモデルを理解する
Agent Platform Workbench インスタンスを使用して、モデルを評価し、理解します。Agent Platform Workbench インスタンスには、scikit-learn などの一般的な組み込み共通ライブラリに加えて、What-if ツール（WIT）と言語解釈ツール（LIT）があります。WIT では複数の手法を使用してモデルのバイアスをインタラクティブに分析でき、LIT では視覚的で対話型の拡張可能なツールを使用して自然言語処理モデルの動作を理解できます。
特徴アトリビューションを使用してモデル予測の分析情報を取得する
Vertex Explainable AI は、ML 実装プロセスに不可欠な部分であり、特徴アトリビューションによって、モデルがどのような根拠で予測を導き出したかに関する分析情報を提供します。Vertex Explainable AI により、モデルが予測のために入力として使用する各特徴の重要度を詳細に確認して、モデルの動作をより深く理解し、モデルの信頼性を高めることができます。
Vertex Explainable AI は、表形式データと画像データに基づくカスタム トレーニング モデルをサポートします。
Vertex Explainable AI の詳細については、以下をご覧ください。
データの準備
データ準備には、次のベスト プラクティスをおすすめします。
BigQuery を使用して表形式データを処理する。
Dataflow を使用してデータを処理する。
サーバーレス Spark データ処理に Managed Service for Apache Spark を使用する。
Vertex ML Metadata でマネージド データセットを使用する。
データを処理するための推奨方法は、使用するフレームワークとデータ型によって異なります。このセクションでは、一般的なシナリオに対する推奨事項の概要を説明します。
BigQuery を使用して構造化データと半構造化データを処理する
BigQuery は、未処理の構造化データまたは半構造化データの保存に使用します。BigQuery ML を使用してモデルを構築する場合は、BigQuery に組み込まれている変換をデータの前処理に使用します。AutoML を使用している場合は、AutoML に組み込まれている変換をデータの前処理に使用します。カスタムモデルを構築する場合は、BigQuery 変換を使用するのが最も費用対効果の高い方法になります。
大規模なデータセットの場合、BigQuery でパーティショニングの使用を検討してください。この方法により、クエリのパフォーマンスと費用対効果を向上させることができます。
Dataflow を使用してデータを処理する
大量のデータを処理する場合は、Apache Beam プログラミング モデルを使用する Dataflow の使用を検討してください。Dataflow を使用すると、非構造化データを TFRecord などのバイナリデータ形式に変換できます。これにより、トレーニング プロセス中にデータ取り込みのパフォーマンスを向上させることができます。
サーバーレス Spark データ処理に Managed Service for Apache Spark を使用する
または、Apache Spark のコードベースとスキルに投資している場合は、Managed Service for Apache Spark の使用を検討してください。メモリに収まる小さなデータセットには、1 回限りの Python スクリプトを使用します。
Cloud SQL で表現できない変換やストリーミングを目的とした変換が必要な場合は、Dataflow と pandas ライブラリを組み合わせて使用できます。
ML メタデータでマネージド データセットを使用する
データを ML 用に前処理した後、Agent Platform でのマネージド データセットの使用を検討できます。マネージド データセットを使用すると、データとカスタム トレーニング モデルを明確にリンクできるほか、記述統計を提供したり、データをトレーニング セット、テストセット、検証セットに自動または手動で分割したりすることもできます。
マネージド データセットは必須ではなく、トレーニング コード内のデータの分割をさらに細かく制御したい場合や、データとモデル間のリネージがアプリケーションに重要でない場合には使用を避けることも考えられます。
詳細については、データセットとカスタム トレーニング アプリケーションでマネージド データセットを使用するをご覧ください。
ML トレーニング
ML トレーニングには、次のベスト プラクティスをおすすめします。
マネージド サービスでコードを実行する。
トレーニング パイプラインを使用してジョブ実行を運用化する。
トレーニングのチェックポイントを使用して、テストの現在の状態を保存する。
Cloud Storage でサービスを提供するモデルのアーティファクトを準備する。
新しい特徴値を定期的に計算する。
ML トレーニングでは、運用化されたトレーニングとは、繰り返しをトラッキングしてモデル トレーニングを繰り返し可能にし、パフォーマンスを管理するプロセスを指します。Agent Platform Workbench インスタンスは、小規模なデータセットの反復開発を行う際に簡便に使用できますが、再現可能かつ大規模なデータセットに拡張できるように、コードを運用することをおすすめします。このセクションでは、トレーニング ルーティンを運用化するためのツールとベスト プラクティスについて説明します。
マネージド サービスでコードを実行する
Gemini Enterprise Agent Platform Managed Training サービスでコードを実行するか、Agent Platform Pipelines でオーケストレートすることをおすすめします。必要に応じて、Deep Learning VM Image、Deep Learning Containers、Compute Engine でコードを直接実行できます。ただし、自動スケーリングやバースト機能などの Agent Platform の機能を使用する場合は、このアプローチはおすすめしません。
トレーニング パイプラインを使用してジョブ実行を運用化する
Agent Platform でトレーニング ジョブの実行を運用化するには、トレーニング パイプラインを作成します。トレーニング パイプラインは一般的な ML パイプラインとは異なり、トレーニング ジョブをカプセル化します。トレーニング パイプラインの詳細については、トレーニング パイプラインの作成と REST リソース: projects.locations.trainingPipelines をご覧ください。
トレーニングのチェックポイントを使用して、テストの現在の状態を保存する
このドキュメントの ML ワークフローでは、インタラクティブにトレーニングしていないことを前提としています。モデルが失敗し、チェックポイントが設定されていない場合、モデルがメモリ内にないため、トレーニング ジョブまたはパイプラインが終了し、データが失われます。この状況を回避するには、状態を失わないように常にトレーニング チェックポイントを使用するようにします。
トレーニングのチェックポイントを Cloud Storage に保存することをおすすめします。テストやトレーニングの実行ごとに異なるフォルダを作成します。
チェックポイントの詳細については、TensorFlow Core 用のトレーニング チェックポイント、PyTorch で一般的なチェックポイントを保存して読み込む、ML の設計パターンをご覧ください。
Cloud Storage でサービスを提供するモデル アーティファクトを準備する
カスタム トレーニングされたモデルまたはカスタム コンテナの場合は、本番環境で使用しているリージョン エンドポイントとリージョンが一致する Cloud Storage バケットにモデル アーティファクトを保存する必要があります。詳細については、バケットのリージョンをご覧ください。
Cloud Storage では、オブジェクトのバージョニングがサポートされています。偶発的なデータの損失や破損を防ぐには、Cloud Storage でオブジェクトのバージョニングを有効にします。
Cloud Storage バケットを同じ Google Cloud プロジェクトに保存します。Cloud Storage バケットが別の Google Cloud プロジェクトにある場合、モデル アーティファクトを読み取るには、Gemini Enterprise Agent Platform にアクセス権を付与する必要があります。
Gemini Enterprise Agent Platform のビルド済みコンテナを使用する場合は、モデル アーティファクトのファイル名が以下の例と完全に一致していることを確認します。
- TensorFlow SavedModel:
saved_model.pb - Scikit-learn:
model.joblib - XGBoost:
model.bst - PyTorch:
model.pth
1 つ以上のモデル アーティファクト形式でモデルを保存する方法については、予測に使用するモデル アーティファクトのエクスポートをご覧ください。
新しい特徴値を定期的に計算する
多くの場合、モデルでは、Agent Platform Feature Store から生成された特徴のサブセットが使用されます。Agent Platform Feature Store の特徴は、すでにオンライン サービングする準備ができています。データレイクからデータを取得してデータ サイエンティストが作成した新しい特徴量については、特徴量の鮮度要件に応じて、対応するデータ処理ジョブと特徴エンジニアリング ジョブ（または理想的には Dataflow）をスケジュールして、必要なケイデンスで新しい特徴値を定期的に計算し、オンライン サービングまたはバッチ サービングのために Agent Platform Feature Store に取り込むことをおすすめします。
モデルのデプロイとサービング
モデルのデプロイとサービングには、次のベスト プラクティスをおすすめします。
必要なマシンの数とタイプを指定する。
モデルへの入力を計画する。
自動スケーリングをオンにする。
BigQuery ML を使用してモデルをモニタリングする。
モデルのデプロイとサービングとは、モデルを本番環境に投入することです。トレーニング ジョブの出力は Cloud Storage に保存された 1 つ以上のモデル アーティファクトです。このファイルを Model Registry にアップロードして、予測処理に使用できます。予測のサービス提供には次の 2 つのタイプがあります。バッチ予測ではデータのバッチを定期的にスコア付けし、オンライン予測はライブ アプリケーションの準リアルタイムのスコア付けに使用します。どちらの方法でも、クラウドでホストされている ML モデルに入力データを渡し、各データ インスタンスについて推定を取得することによって、トレーニング モデルから予測を取得できます。詳細については、バッチ予測の取得とカスタム トレーニング モデルからオンライン予測を取得するをご覧ください。
クライアントとモデルサーバー間のピアツーピア リクエストのレイテンシを短縮するには、Agent Platform プライベート エンドポイントを使用します。これらは、予測リクエストを行うアプリケーションとそのサービスを提供するバイナリが同じローカル ネットワーク内にある場合に特に役立ちます。インターネット ルーティングのオーバーヘッドを回避し、Virtual Private Cloud を使用してピアツーピア接続を確立できます。
必要なマシンの数とタイプを指定する
予測に使用するモデルをデプロイするには、さまざまな中央処理装置（CPU）の仮想マシン（VM）のタイプや画像処理装置（GPU）のタイプなど、モデルに適したハードウェアを選択します。詳細については、マシンタイプ、スケールティアの指定をご覧ください。
モデルへの入力を計画する
モデルをデプロイするだけでなく、入力をモデルに渡す方法を決定する必要があります。バッチ予測を使用している場合は、データレイクまたは Feature Store Batch Serving API からデータを取得できます。オンライン予測を使用している場合は、入力インスタンスをサービスに送信すると、レスポンスで予測が返されます。詳細については、レスポンス本文の詳細をご覧ください。
オンライン予測のためにモデルをデプロイする場合は、モデルのエンドポイントに渡す必要がある入力や特徴を提供するための低レイテンシでスケーラブルな方法が必要です。そのためには、多数の Google Cloud上のデータベース サービスのいずれかを使用するか、Feature Store のオンライン サービング API を使用します。オンライン予測エンドポイントを呼び出すクライアントは、特徴サービス提供ソリューションを呼び出して特徴の入力を取得し、それらの入力で予測エンドポイントを呼び出すことができます。モデルを段階的に置き換えるなど、同じエンドポイントに複数のモデルをサービングできます。また、デプロイメント間でリソースを共有して、テスト環境と本番環境など、複数のエンドポイントにモデルをデプロイすることもできます。
ストリーミング取り込みにより、特徴値をリアルタイムで更新できます。この方法は、オンライン サービングで最新の利用可能なデータを優先する場合に役立ちます。たとえば、ストリーミング イベントデータを取り込むことができ、数秒以内に Feature Store のストリーミング取り込みによってそのデータを、オンライン サービングのシナリオで使用できるようにします。
さらに、カスタム予測ルーチンを使用して、モデルサーバーとの間の入力（リクエスト）と出力（レスポンス）の処理やフォーマットをカスタマイズできます。
自動スケーリングをオンにする
オンライン予測サービスを使用する場合、ほとんどの場合は、最小ノード数と最大ノード数を指定して自動スケーリングを有効にすることをおすすめします。詳細については、カスタム トレーニング モデルの予測を取得するをご覧ください。高可用性のサービスレベル契約（SLA）を確保するには、少なくとも 2 つのノードで自動スケーリングを設定します。
スケーリング オプションの詳細については、ML 予測のスケーリングをご覧ください。
ML ワークフローのオーケストレーション
インフラストラクチャと統合のニーズに応じて、ML ワークフローのオーケストレーションに次のベスト プラクティスをおすすめします。
Managed Service for Apache Airflow を使用して、エンドツーエンドのエンタープライズ MLOps と異種データ ワークフローをオーケストレートします。
Agent Platform を使用して、サーバーレスのコンテナ ネイティブ ML ワークフローをオーケストレートする。
Agent Platform 内で柔軟な ML パイプラインを構築するために Kubeflow Pipelines を使用する。
分散 ML ワークフローに Ray on Gemini Enterprise Agent Platform を使用する。
Google Cloud は、ML ワークフローのオーケストレーションのための包括的なスイートを提供します。抽出、読み込み、変換（ELT）、ML トレーニング、外部ビジネス システムなどのデータ エンジニアリング タスクにまたがる複雑なエンドツーエンドのプロセスには、エンタープライズ オーケストレーターとして Managed Airflow をおすすめします。Agent Platform エコシステム内に厳密に留まる自己完結型のワークフローの場合、Agent Platform Pipelines は、必要に応じて必要な頻度でモデルを再トレーニングできるサーバーレスのフルマネージド サービスを提供します。再トレーニングを行うことで、モデルの変更に適応し、時間の経過に伴ってパフォーマンスを維持できますが、最適なモデルの再トレーニング サイクルの選択時にデータがどの程度変化するかを考慮してください。
ML オーケストレーション ワークフローは、モデルを設計および構築し、本番環境に配置し、ML ライフサイクルを自動化するお客様に最適です。テストに使用するコードは、ML ワークフローの他の箇所で一部を変更すると効果的です。Agent Platform Pipelines でコンテナ ネイティブ ML ワークフローを操作するには、Python に精通し、コンテナなどの基本的なインフラストラクチャを理解し、ML の知識を持っていることが必要です。ML 以外のタスク用にカスタム コンテナを管理する必要がない、より広範なオーケストレーションには、Managed Airflow を使用します。Managed Airflow には、1,000 を超える事前構築済みのオペレーターと、データ サイエンティスト向けのアクセス可能な YAML ベースの構成フレームワークが用意されています。
エンドツーエンドの Enterprise MLOps ワークフローに Managed Airflow を使用する
各データ処理、トレーニング、評価、デプロイを手動で開始することもできますが、アーキテクチャが異種システムにまたがる場合は、Managed Airflow を使用してフロー全体をオーケストレートすることをおすすめします。マネージド Airflow は Apache Airflow 上に構築されています。Managed Airflow は統合コントロール プレーンとして機能し、 Google Cloud サービス（BigQuery や Dataflow など）を Agent Platform やサードパーティのエンタープライズ ツールとシームレスに統合できます。
複雑な Airflow Python DAG を記述する代わりに、Orchestration Pipelinesを使用して、ビジネス ロジックと依存関係を簡潔な YAML で定義できます。この宣言型アプローチにより、導入のハードルが大幅に下がり、データ サイエンティストは Apache Airflow の深い専門知識がなくても、マルチステップ パイプラインをシームレスに構築してデプロイできます。Orchestration Pipelines での MLOps の詳細については、数週間から数分へ: データ パイプラインの新たなエージェントの時代をご覧ください。
Agent Platform に組み込まれたサーバーレス ワークフローに Gemini Enterprise Agent Platform Pipelines を使用する
ワークフローが完全にコンテナベースで、Agent Platform エコシステム内で厳密に実行される場合は、Agent Platform Pipelines を使用してフローをオーケストレートすることをおすすめします。詳細については、MLOps レベル 1: ML パイプラインの自動化をご覧ください。Agent Platform Pipelines は、Kubeflow と TensorFlow Extended（TFX）によって生成された DAG のサーバーレス実行を提供します。
柔軟なパイプライン構築のために Kubeflow Pipelines を使用する
Kubeflow Pipelines SDK は、Agent Platform パイプライン用のマネージド パイプラインを作成するほとんどのユーザーに推奨されます。Kubeflow Pipelines は柔軟性が高く、コードを使用してコンテナ化されたパイプラインを作成できます。また、 Google Cloud パイプライン コンポーネントを提供しているため、AutoML などの Agent Platform 機能をパイプラインに組み込むことができます。Kubeflow Pipelines の詳細については、Kubeflow Pipelines と Agent Platform Pipelines をご覧ください。
分散 ML ワークフローに Gemini Enterprise Agent Platform で Ray を使用する
Ray は、Python のスケーラブルなオープンソースの分散コンピューティング フレームワークを介して ML ワークフローをスケーリングするための、統一された汎用分散フレームワークを提供します。このフレームワークは、ML エコシステムにさまざまな分散フレームワークが存在することによる課題（複数のモードのタスク並列処理、スケジューリング、リソース管理に対処する必要があるなど）の解決に役立ちます。Gemini Enterprise Agent Platform の Ray を使用して、Agent Platform でアプリケーションを開発できます。
アーティファクト構成
アーティファクトの整理には、次のベスト プラクティスをおすすめします。
アーティファクトは、ML ワークフローの各ステップから出力されます。標準化された方法で整理することをおすすめします。
ML モデルのアーティファクトを整理する
アーティファクトを次の場所に保存します。
| ストレージのロケーション | アーティファクト |
| ソース管理リポジトリ |
|
| テストと ML メタデータ |
|
| Model Registry |
|
| Artifact Registry |
|
| Gemini Enterprise Agent Platform の推論 |
|
パイプラインの定義とトレーニング コードのためにソース管理リポジトリを使用する
ソース管理を使用して、ML パイプラインとそれらのパイプライン用に構築するカスタム コンポーネントをバージョン管理できます。Artifact Registry を使用すると、Docker コンテナ イメージを公開することなく、保存、管理、保護できます。
モデルのモニタリング
スキュー検出とドリフト検出を使用する。
アラートのしきい値を微調整する。
特徴アトリビューションを使用してデータドリフトやスキューを検出する。
BigQuery を使用してモデル モニタリングをサポートする。
モデルを本番環境にデプロイした後、パフォーマンスをモニタリングして、モデルが期待どおりに機能していることを確認する必要があります。Gemini Enterprise Agent Platform では、次の 2 つの方法で ML モデルをモニタリングできます。
- スキュー検出: この方法では、モデルのトレーニングと本番環境のデータの間の歪み度を確認します。
- ドリフト検出: このタイプのモニタリングでは、本番環境データのブレを探します。ドリフトは、入力の統計特性と、モデルが予測しようとしているターゲットが、予期しないあり方で時間の経過とともに変化した場合に発生します。これによって、時間の経過とともに予測の精度が低下する可能性があるため、問題が発生します。
モデルのモニタリングは、数値特徴やカテゴリ特徴などの構造化データでは機能しますが、画像などの非構造化データに対しては機能しません。詳細については、モデルの特徴のスキューまたはドリフトのモニタリングをご覧ください。
スキュー検出とドリフト検出を使用する
できる限りスキュー検出を使用します。これは、本番環境データがトレーニング データから逸脱していることを知ることは、モデルが本番環境で想定どおりに機能しないことを示す強力な指標であるためです。スキュー検出の場合は、モデルのトレーニングに使用したトレーニング データへのポインタを指定して、モデル モニタリング ジョブを設定します。
トレーニング データへのアクセス権がない場合は、ドリフト検出を有効にして、時間の経過とともに入力が変化したときに通知されるようにします。
ドリフト検出を使用して、本番環境データが時間の経過とともに逸脱しているかどうかをモニタリングします。ドリフト検出の場合は、モニタリングする特徴と対応するしきい値を有効にして、アラートをトリガーします。
アラートのしきい値を微調整する
アラートに使用するしきい値を調整して、データにスキューやドリフトが発生したときに把握できるようにします。アラートのしきい値は、ユースケース、ユーザーの専門知識、初期モデル モニタリング指標によって決まります。モニタリングを使用してダッシュボードを作成する方法や、指標に基づいてアラートを構成する方法については、Cloud Monitoring の指標をご覧ください。
特徴アトリビューションを使用してデータドリフトやスキューを検出する
Vertex Explainable AI の特徴アトリビューションを使用して、モデル性能の低下の早期インジケーターとしてデータのドリフトまたはスキューを検出できます。たとえば、トレーニング データとテストデータで予測を行うためにモデルが最初に 5 つの特徴を利用していたものの、本番環境に移行する際にまったく別の特徴を利用するようになった場合、モデル性能の低下を検出するために特徴アトリビューションが役立ちます。
これは特に、従来のスキュー法とドリフト法では比較するのが難しいエンベディングや時系列などの複雑な特徴タイプに有効です。Vertex Explainable AI を使用すると、特徴アトリビューションによって、モデルのパフォーマンスが低下しているかどうかを把握できます。
BigQuery を使用してモデルのモニタリングをサポートする
BigQuery ML モデル モニタリングは、ML モデルのパフォーマンスの経時的な追跡と評価に役立つツールと機能のセットです。モデルのモニタリングは、実際のアプリケーションでモデルの精度と信頼性を維持するために不可欠です。次の問題をモニタリングすることをおすすめします。
- データスキュー: この問題は、トレーニング データとサービング データで特徴値の分布が異なる場合に発生します。モデルのトレーニング中に保存されるトレーニング統計により、元のデータがなくてもスキュー検出が可能になります。
- データドリフト: 実際のデータは時間の経過とともに変化することがよくあります。モデル モニタリングは、モデルに本番環境で提供される入力データ（サービング データ）と、トレーニングに使用されたデータ（トレーニング データ）の差異が大きくなり始めたタイミングを特定するのに役立ちます。このドリフトにより、パフォーマンスが低下する可能性があります。
- 高度なデータスキューまたはデータドリフト: スキューまたはドリフトの詳細な統計情報を必要とする場合は、高度なデータスキューまたはデータドリフトのモニタリングを行います。
次のステップ
- Agent Platform のドキュメント
- ML オペレーション（MLOps）の実践的な運用ガイド: ML の継続的デリバリーと自動化のフレームワーク
- Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、Well-Architected Framework の AI と ML の視点を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。