ML モデルのトレーニングが完了したら、次のステップは、そのモデルを使用して新しいデータに対する予測を行います。推論と呼ばれるこのプロセスでは、アプリケーションのレイテンシとスループットの要件に応じた適切な戦略が必要です。バッチ推論は、オフライン推論または非同期処理とも呼ばれ、リアルタイムの即時応答が不要な場合に、大量のデータに対して予測を生成する強力で高効率な方法です。
バッチ推論は、トレーニング済みの ML モデルを使用して、大量の観測データ、すなわち「バッチ」に対する予測を一度に生成するプロセスです。
オンライン推論では、単一のデータポイントが到着するたびに予測が行われますが、バッチ推論では、一定期間にわたって収集されたデータに対して予測が行われます。このアプローチでは、低レイテンシよりも高スループットと計算効率が優先されます。処理はオフラインで行われ、ユーザーのリクエストに直接応答するものではないため、静的推論とも呼ばれます。予測は生成されて保存され、後で使用されます。
バッチ推論とオンライン推論のどちらを選ぶかは、ML システムを設計する上でアーキテクチャの根幹をなす決定です。それぞれのアプローチは異なる目的に対応しており、異なるパフォーマンス特性に合わせて最適化されています。
機能 | バッチ推論 | オンライン推論 |
データ処理 | 1 つのジョブで大量のデータポイントをまとめて処理。 | 単一のデータポイントまたはごく少数のデータポイントが到着するたびに処理します。 |
主な最適化 | 高スループットで費用対効果が高い。 | 低レイテンシと即時の応答性。 |
レイテンシ | 高レイテンシ。予測はすぐには利用できない(数分から数時間かかる)。 | レイテンシが非常に低く、予測はミリ秒単位で返されます。 |
呼び出し | スケジュール(cron ジョブなど)またはオンデマンドでトリガーされます。 | ユーザーの直接的なリクエストまたはシステム内のイベントによってトリガーされます。 |
コンピューティング能力の使用率 | 強力なコンピューティング リソースを短期間使用し、その後ゼロまでスケールダウンできます。 | サーバーまたはエンドポイントが常に実行され、リクエストを受け入れる準備ができている必要があります。 |
使用例 | e コマースサイトのすべてのユーザーへのおすすめ商品を毎日生成。 | クレジット カード取引ごとのリアルタイム不正予測。 |
同義語 | オフライン推論、非同期処理、静的推論。 | リアルタイム推論、同期処理、動的推論。 |
機能
バッチ推論
オンライン推論
データ処理
1 つのジョブで大量のデータポイントをまとめて処理。
単一のデータポイントまたはごく少数のデータポイントが到着するたびに処理します。
主な最適化
高スループットで費用対効果が高い。
低レイテンシと即時の応答性。
レイテンシ
高レイテンシ。予測はすぐには利用できない(数分から数時間かかる)。
レイテンシが非常に低く、予測はミリ秒単位で返されます。
呼び出し
スケジュール(cron ジョブなど)またはオンデマンドでトリガーされます。
ユーザーの直接的なリクエストまたはシステム内のイベントによってトリガーされます。
コンピューティング能力の使用率
強力なコンピューティング リソースを短期間使用し、その後ゼロまでスケールダウンできます。
サーバーまたはエンドポイントが常に実行され、リクエストを受け入れる準備ができている必要があります。
使用例
e コマースサイトのすべてのユーザーへのおすすめ商品を毎日生成。
クレジット カード取引ごとのリアルタイム不正予測。
同義語
オフライン推論、非同期処理、静的推論。
リアルタイム推論、同期処理、動的推論。
バッチ推論パイプラインは、構造化された自動ワークフローであり、データを元の状態から実用的な予測に変換します。このプロセスは、通常はワークフロー マネージャーまたはスケジュール システムによってオーケストレートされる、次の主要なステップに分けることができます。
このプロセスは、まず、時間をかけてデータを蓄積することから始まります。ユーザー アクティビティ ログ、トランザクション レコード、センサー測定値など、さまざまなソースから収集された入力データは、一元化されたストレージに保存されます。多くの場合、このストレージは、Google Cloud Storage などのサービス上に構築されたデータレイクや、BigQuery などのデータ ウェアハウスです。
推論パイプラインはトリガーによって開始されます。このトリガーは、次のいずれかです。
トリガーされると、ジョブは元の入力データのバッチ全体を読み込みます。次に、必要な前処理と特徴量エンジニアリングのステップを実行して、データを ML モデルが想定する正確な形式に変換します。これには、欠損値のクリーニング、数値特徴量のスケーリング、カテゴリ変数のエンコードなどのタスクが含まれます。
システムは、Vertex AI Model Registry などの中央リポジトリからトレーニング済みの ML モデルを取得します。その後、前処理されたデータバッチがモデルに供給され、モデルはセット内のすべての観測値について推論を実行し、対応する予測を生成します。
モデルの出力(一連の予測)は、次にストレージ システムに書き込まれます。この出力先は、予測の用途に基づいて選択されます。一般的な出力先には、分析のために結果を BigQuery テーブルに読み込む、アプリケーションで迅速に検索するために Cloud SQL データベースに保存する、Cloud Storage にファイルとして保存する、などがあります。
予測データが保存され、準備が整ったので、ダウンストリーム システムで使用できます。ビジネス インテリジェンス ツールは、結果に対してクエリを実行して、予測された顧客行動のダッシュボードを作成する場合があります。ウェブ アプリケーションのバックエンドで、事前に算出されたおすすめ商品を読み込んでユーザーに表示したり、マーケティング自動化プラットフォームで、離脱が予測される顧客のリストを取得して新しいキャンペーンのターゲットにしたりできます。
多くのエンタープライズ ユースケースでは、バッチ推論はリアルタイム処理よりも大きなメリットが見込まれます。
費用対効果
バッチ処理により、コンピューティング リソースの使用を最適化できます。強力なハードウェアで大規模なジョブを短期間実行し、その後リソースをシャットダウンすることで、継続的にサーバーを実行する費用を回避できます。
高スループットとスケーラビリティ
バッチシステムは、テラバイト単位のデータを効率的にスケーリングして処理するように設計されています。これにより、オンライン システムでは処理速度が遅すぎたり、費用が高すぎたりするような非常に大規模なデータセットにも複雑なモデルを適用できます。
運用の簡素化
バッチ推論パイプラインは、高可用性で低レイテンシのオンライン推論システムよりも構築やメンテナンスが簡単です。一般に、一時的な障害に対する復元力が優れており、ジョブが失敗した場合でも簡単に再実行できます。
複雑な特徴量エンジニアリングを可能にする
バッチ推論は低レイテンシ要件に制約されないため、入力データに対してより複雑で計算負荷の高い特徴量エンジニアリングを実行できます。これにより、多くの場合、より正確なモデルが実現します。
リソース使用率の向上
バッチジョブをオフピーク時に実行するようにスケジュールすることで、アイドル状態のコンピューティング容量を活用し、仮想マシンのスポット料金を低く抑えることができます。
バッチ推論は、リアルタイムで生成する必要はないものの、予測によって製品やサービスを強化する多くのコア ビジネス プロセスで推奨される方法です。このアプローチは、さまざまな業界で大規模なデータ問題を解決するのに非常に効果的です。
業種 | 解決すべき問題 | ソリューションの例 |
e コマースと小売業 | ユーザーベース全体に対して、毎日パーソナライズされた商品のおすすめを生成し、ユーザーがサイトにアクセスしたときにすぐに取得できるようにします。 | Vertex AI バッチ予測では、レコメンデーション モデルを実行し、その結果を Cloud SQL や Bigtable などの高速ルックアップ データベースに読み込むことができます。 |
通信と SaaS | 顧客データベース全体の使用パターンを分析して、来月解約するリスクが高い顧客を特定します。 | BigQuery ML を使用すると、データ ウェアハウスに保存されている顧客データに対して分類モデルを直接実行し、その結果を顧客維持を担当するチーム用の新しいテーブルに書き込むことができます。 |
金融と保険 | 金融市場のトレンドを予測したり、資産のポートフォリオ全体のリスクスコアを算出したりします。これは、定期的に実行されるコンピューティング負荷の高いタスクです。 | Vertex AI バッチ予測は、複雑な時系列モデルをスケジュールに従って実行し、戦略レポートやダッシュボードに必要なデータを提供します。 |
物流とサプライ チェーン | 毎週の販売データと物流データに基づいて複雑な需要予測シミュレーションを実行し、数百もの倉庫の在庫レベルを最適化します。 | Google Kubernetes Engine(GKE)は、特定のライブラリとハードウェア要件を備えた特殊なシミュレーション モデルを実行するために必要な、カスタムの高性能環境を提供します。 |
医療 | 大量の医療画像(X 線や CT スキャンなど)を毎日分析し、潜在的な異常を検出して、放射線科医が確認できるようにします。 | GPU アクセラレータを備えた GKE は、大規模な画像セットでディープ ラーニング コンピュータ ビジョン モデルを実行するのに最適で、最大限の制御とパフォーマンスを提供します。 |
法律とコンプライアンス | 数百万の既存のドキュメントを処理および分類し、主要なエンティティを抽出して感情を評価し、コーパス全体を検索可能かつ分析可能にします。 | Dataflow を使用して、テキストを前処理して推論を実行するスケーラブルな NLP パイプラインを構築できます。一方、GKE は、よりカスタムなモデル要件に使用できます。 |
業種
解決すべき問題
ソリューションの例
e コマースと小売業
ユーザーベース全体に対して、毎日パーソナライズされた商品のおすすめを生成し、ユーザーがサイトにアクセスしたときにすぐに取得できるようにします。
Vertex AI バッチ予測では、レコメンデーション モデルを実行し、その結果を Cloud SQL や Bigtable などの高速ルックアップ データベースに読み込むことができます。
通信と SaaS
顧客データベース全体の使用パターンを分析して、来月解約するリスクが高い顧客を特定します。
BigQuery ML を使用すると、データ ウェアハウスに保存されている顧客データに対して分類モデルを直接実行し、その結果を顧客維持を担当するチーム用の新しいテーブルに書き込むことができます。
金融と保険
金融市場のトレンドを予測したり、資産のポートフォリオ全体のリスクスコアを算出したりします。これは、定期的に実行されるコンピューティング負荷の高いタスクです。
Vertex AI バッチ予測は、複雑な時系列モデルをスケジュールに従って実行し、戦略レポートやダッシュボードに必要なデータを提供します。
物流とサプライ チェーン
毎週の販売データと物流データに基づいて複雑な需要予測シミュレーションを実行し、数百もの倉庫の在庫レベルを最適化します。
Google Kubernetes Engine(GKE)は、特定のライブラリとハードウェア要件を備えた特殊なシミュレーション モデルを実行するために必要な、カスタムの高性能環境を提供します。
医療
大量の医療画像(X 線や CT スキャンなど)を毎日分析し、潜在的な異常を検出して、放射線科医が確認できるようにします。
GPU アクセラレータを備えた GKE は、大規模な画像セットでディープ ラーニング コンピュータ ビジョン モデルを実行するのに最適で、最大限の制御とパフォーマンスを提供します。
法律とコンプライアンス
数百万の既存のドキュメントを処理および分類し、主要なエンティティを抽出して感情を評価し、コーパス全体を検索可能かつ分析可能にします。
Dataflow を使用して、テキストを前処理して推論を実行するスケーラブルな NLP パイプラインを構築できます。一方、GKE は、よりカスタムなモデル要件に使用できます。
Vertex AI は Google Cloud のマネージド ML プラットフォームであり、バッチ推論のための合理化されたサーバーレス アプローチを提供します。このプロセスでは、ジョブの構成に重点を置き、基盤となるインフラストラクチャはプラットフォームで処理します。
開始するにあたって、次の 3 つが必要です。
ジョブは、Google Cloud コンソール、gcloud コマンドライン ツール、Vertex AI SDK のいずれかを使用してプログラムで開始できます。ジョブを作成する際に、次の構成を指定します。
ジョブを送信すると、Vertex AI が処理を引き継ぎます。指定したコンピューティング リソースを自動的にプロビジョニングし、入力データをモデルで処理して予測を生成し、指定した出力場所に保存します。ジョブが完了すると、Vertex AI はすべてのリソースを自動的にゼロにスケールダウンするため、使用したコンピューティング時間に対してのみ料金が発生します。ジョブの進行状況をモニタリングでき、Google Cloud コンソールでログを直接確認できます。
ジョブのステータスが「Succeeded」になったら、予測の準備は完了です。Cloud Storage の出力ファイルや BigQuery の新しいテーブルに、ダウンストリーム アプリケーション、分析ツール、BI ダッシュボードからアクセスできるようになります。
バッチ推論に Google Kubernetes Engine(GKE)を使用すると、最大限の制御と移植性が得られるため、すでに Kubernetes の専門知識があるチームや、特殊な要件のあるチームに最適です。セットアップでは、推論ロジックをコンテナ化し、Kubernetes リソースでその実行を管理します。
ステップ 1: 推論アプリケーションをコンテナ化する。最初のステップは、予測コードをコンテナ イメージにパッケージ化することです。
ステップ 2: Kubernetes Job を定義する。長時間実行されるデプロイの代わりに、Kubernetes ジョブまたは CronJob マニフェスト(YAML ファイル)を使用してバッチタスクを定義します。このファイルでは、次の内容を指定します。
ステップ 3: GKE クラスタでジョブを実行する。kubectl を使用して、マニフェストを GKE クラスタに適用します。GKE のコントロール プレーンは、クラスタ内の適切なノードで推論コンテナを実行する Pod をスケジュールします。繰り返しタスクの場合、CronJob リソースは、事前定義されたスケジュールに基づいて新しいジョブを自動的に作成します(例: 0 2 * * * は、毎日午前 2 時を表します)。
ステップ 4: データの処理を実装し、結果を保存する。マネージド Vertex AI アプローチとは異なり、コンテナ内のアプリケーション コードがすべてのデータ I/O を処理します。スクリプトには、データソース(Cloud Storage バケットなど)に接続して読み取るロジックと、選択した宛先(Cloud SQL データベースなど)に最終的な予測を書き戻すロジックを含める必要があります。