Google
Cloud Platform
Amazon Web Services
Microsoft AzureDatabricksでの MLOps ワークフロー
この記事では、Databricks プラットフォームで MLOps を使用して、機械学習 (ML) システムのパフォーマンスと長期的な効率を最適化する方法について説明します。 これには、MLOps アーキテクチャの一般的な推奨事項が含まれており、Databricks ML開発から本番運用までのプロセスのモデルとして使用できる プラットフォームを使用した一般化されたワークフローについて説明します。LLMOps アプリケーション用のこのワークフローの変更については、 「LLMOps ワークフロー」を参照してください。
詳細については、「 The Big Book of MLOps」を参照してください。
MLOps とは何ですか?
MLOps 、コード、データ、モデルを管理してMLシステムのパフォーマンス、安定性、長期的な効率を向上させるための一連のプロセスと自動化されたステップです。 DevOps、DataOps、ModelOps を組み合わせたものです。
コード、データ、モデルなどの機械学習資産は、アクセス制限や厳密なテストが行われていない開発初期段階から、中間テスト段階を経て、厳密に管理された最終的な本番運用段階へと段階的に開発されます。 Databricks プラットフォームでは、統一されたアクセス制御を使用して、これらの資産を 1 つのプラットフォームで管理できます。 データアプリケーションと機械学習アプリケーションを同じプラットフォーム上で開発できるため、データの移動に伴うリスクと遅延を軽減できます。
MLOpsに関する一般的な推奨事項
このセクションでは、Databricks での MLOps に関する一般的な推奨事項と、詳細情報へのリンクを示します。
ステージごとに個別の環境を作成する
実行環境は、モデルとデータがコードによって作成または使用される場所です。 各実行環境は、コンピュート・インスタンス、そのランタイムとライブラリ、および自動ジョブで構成されます。
Databricks では、ステージ間の遷移を明確に定義して、機械学習コードとモデル開発のさまざまなステージ用に個別の環境を作成することをお勧めします。 この記事で説明するワークフローは、ステージの共通名を使用して、このプロセスに従います。
他の構成を使用して、組織の特定のニーズを満たすこともできます。
アクセス制御とバージョン管理
アクセス制御とバージョン管理は、ソフトウェア運用プロセスの主要なコンポーネントです。 Databricks では、次のことをお勧めします。
バージョン管理には Git を使用します。 パイプラインとコードは、バージョン管理のために Git に格納する必要があります。 ステージ間での ML ロジックの移動は、開発ブランチからステージング ブランチ、リリース ブランチにコードを移動すると解釈できます。 Databricks Git フォルダーを使用して Git プロバイダーと統合し、ノートブックとソース コードを Databricks ワークスペースと同期します。Databricks には、Git 統合とバージョン管理のための追加ツールも用意されています。 「開発者ツール」を参照してください。
Delta テーブルを使用してレイクハウス アーキテクチャにデータを格納します。 データは、クラウドアカウントの レイクハウスアーキテクチャ に保存する必要があります。 生データと特徴量テーブルはどちらも、読み取りと変更ができるユーザーを決定するためのアクセス制御を備えた Delta テーブル として格納する必要があります。
MLflow を使用してモデル開発を管理します。 MLflow を使用して、モデル開発プロセスを追跡し、コード スナップショット、モデル パラメーター、メトリクス、その他のメタデータを保存できます。
Unity Catalogのモデルを使用して、モデルのライフサイクルを管理します。 Unity Catalogのモデルを使用して、モデルのバージョン管理、ガバナンス、および展開ステータスを管理します。
モデルではなくコードをデプロイする
ほとんどの場合、Databricks では、機械学習の開発プロセス中に、 モデルではなく コードをある環境から次の環境に昇格することをお勧めします。この方法でプロジェクト資産を移動すると、機械学習開発プロセスのすべてのコードが同じコードレビューおよび統合テストプロセスを確実に通過します。 また、モデルの運用バージョンが運用コードでトレーニングされることも保証されます。 オプションとトレードオフの詳細については、「 モデルのデプロイ パターン」を参照してください。
推奨される MLOps ワークフロー
以下のセクションでは、開発、ステージング、本番という 3 つのステージのそれぞれをカバーする一般的な MLOps ワークフローについて説明します。
このセクションでは、"データサイエンティスト" と "機械学習エンジニア" という用語を典型的なペルソナとして使用します。機械学習 Ops ワークフローにおける特定の役割と責任は、チームや組織によって異なります。
開発フェーズ
開発フェーズの焦点は実験です。 データサイエンティスト フィーチャーとモデルを開発し、エクスペリメントを実行してモデルのパフォーマンスを最適化します。 開発プロセスの出力は、特徴計算、モデル トレーニング、推論、およびモニタリングを含めることができる機械学習パイプライン コードです。
番号付きのステップは、図に示されている番号に対応しています。
1. データソース
開発環境は、Unity Catalog の開発カタログによって表されます。 データサイエンティストは、開発ワークスペースで一時データと特徴量テーブルを作成するときに、開発カタログへの読み取り/書き込みアクセス権を持ちます。 開発段階で作成されたモデルは、開発カタログに登録されます。
理想的には、開発ワークスペースで作業するデータサイエンティストは、本番カタログ内の本番運用データへの読み取り専用アクセスも持っています。 データサイエンティストは、本番運用データ、推論表、メトリクス表を本番カタログに読み取るアクセスを許可することで、現在の本番運用モデルの予測とパフォーマンスを分析できます。 また、データサイエンティストは、実験や分析のために本番運用モデルを読み込むことができる必要があります。
本番カタログへの読み取り専用アクセス権を付与できない場合は、本番運用データのスナップショットを開発カタログに書き込んで、データサイエンティストがプロジェクトコードを開発および評価できるようにすることができます。
2. 探索的データ解析(EDA)
データサイエンティスト ノートブックを使用して、対話型の反復プロセスでデータを探索および分析します。 目標は、利用可能なデータがビジネス上の問題を解決できる可能性があるかどうかを評価することです。 このステップでは、データサイエンティストは、モデルトレーニングのためのデータの準備と特徴付けのステップの特定を開始します。 このアドホック プロセスは、通常、他の実行環境にデプロイされるパイプラインの一部ではありません。
Mosaic AutoML は、データセットのベースラインモデルを生成することで、このプロセスを高速化します。 AutoML は、一連のトライアルを実行および記録し、各トライアル実行のソースコードを Python ノートブックに提供するため、コードを確認、再現、変更できます。 また、AutoML はデータセットの要約統計を計算し、この情報をノートブックに保存して確認できるようにします。
3. コード
コード リポジトリには、機械学習プロジェクトのすべてのパイプライン、モジュール、およびその他のプロジェクト ファイルが含まれています。 データサイエンティストは、プロジェクトリポジトリの開発(「開発」)ブランチに新規または更新されたパイプラインを作成します。 データサイエンティストは、EDA とプロジェクトの初期段階からリポジトリで作業し、コードを共有し、変更を追跡する必要があります。
4. モデルをトレーニングする(開発環境)
データサイエンティストは、開発カタログまたは本番カタログのテーブルを使用して、開発環境でモデルトレーニングパイプラインを開発します。
このパイプラインには、次の 2 つのタスクが含まれています。
トレーニングとチューニング。 トレーニング プロセスでは、MLflow 追跡サーバーに記録済みモデル パラメーター、メトリクス、および成果物が記録されます。 ハイパーパラメーターのトレーニングとチューニングの後、最終的なモデルアーティファクトがトラッキングサーバーに記録され、モデル、トレーニングされた入力データ、およびその生成に使用されたコード間のリンクが記録されます。
評価。 ホールドアウトされたデータでテストして、モデルの品質を評価します。 これらのテストの結果は、MLflow 追跡サーバーに記録されます。 評価の目的は、新しく開発したモデルが現在の本番運用モデルよりも優れた性能を発揮するかどうかを判断することです。 十分な権限があれば、本番カタログに登録されている本番運用モデルを開発ワークスペースに読み込み、新しくトレーニングしたモデルと比較できます。
組織のガバナンス要件にモデルに関する追加情報が含まれている場合は、 MLflow 追跡を使用して保存できます。 典型的なアーティファクトは、プレーンテキストの説明と、SHAPによって生成されたプロットなどのモデル解釈です。 特定のガバナンス要件は、データガバナンス担当者またはビジネス利害関係者から提供される場合があります。
モデル トレーニング パイプラインの出力は、開発環境の MLflow 追跡サーバーに格納されている機械学習モデル成果物です。 パイプラインがステージング ワークスペースまたは本番運用ワークスペースで実行される場合、モデル成果物はそのワークスペースの MLflow 追跡サーバーに格納されます。
モデルのトレーニングが完了したら、Unity Catalog にモデルを登録します。 モデル パイプラインが実行された環境に対応するカタログにモデルを登録するようにパイプライン コードを設定します。この例では、開発カタログです。
推奨アーキテクチャでは、最初のタスクがモデル トレーニング パイプラインで、その後にモデル検証タスクとモデル デプロイ タスクが続くマルチタスク Databricks ワークフローをデプロイします。 モデル トレーニング タスクは、モデル検証タスクで使用できるモデル URI を生成します。 タスク値を使用して、この URI をモデルに渡すことができます。
5. モデルの検証とデプロイ (開発)
モデル トレーニング パイプラインに加えて、モデル検証パイプラインやモデル デプロイ パイプラインなどの他のパイプラインが開発環境で開発されます。
モデルの検証。 モデル検証パイプラインは、モデル トレーニング パイプラインからモデル URI を取得し、Unity Catalog からモデルを読み込み、検証チェックを実行します。
検証チェックはコンテキストによって異なります。 これには、形式や必要なメタデータの確認などの基本的なチェックや、事前定義されたコンプライアンスチェックや選択したデータスライスでのモデルパフォーマンスの確認など、規制の厳しい業界で必要になる可能性のあるより複雑なチェックを含めることができます。
モデル検証パイプラインの主な機能は、モデルがデプロイ ステップに進む必要があるかどうかを判断することです。 モデルがデプロイ前のチェックに合格した場合、Unity Catalog で "Challenger" エイリアスを割り当てることができます。 チェックが失敗した場合、プロセスは終了します。 検証の失敗をユーザーに通知するようにワークフローを構成できます。 ジョブイベントのEメール通知とシステム通知の追加を参照してください。
モデルのデプロイ。 モデル デプロイ パイプラインは、通常、エイリアスの更新を使用して、新しくトレーニングされた "Challenger" モデルを "Champion" 状態に直接昇格させるか、既存の "Champion" モデルと新しい "Challenger" モデルの比較を容易にします。 このパイプラインでは、モデルサービング エンドポイントなど、必要な推論インフラストラクチャを設定することもできます。 モデル・デプロイメント・パイプラインに関連するステップの詳細は、 本番運用を参照してください。
ステージングフェーズ
このステージの焦点は、機械学習パイプライン コードをテストして、運用の準備ができていることを確認することです。 このステージでは、モデル トレーニング用のコード、特徴エンジニアリング パイプライン、推論コードなど、すべての機械学習パイプライン コードがテストされます。
機械学習エンジニアは、この段階で実行される単体テストと統合テストを実装するためのCIパイプラインを作成します。 ステージング プロセスの出力は、CI/CD システムが運用ステージを開始するようにトリガーするリリース ブランチです。
1. データ
ステージング環境には、機械学習パイプラインをテストし、モデルを Unity Catalog に登録するための独自のカタログが Unity Catalog にある必要があります。 このカタログは、図に「ステージング」カタログとして表示されます。 このカタログに書き込まれる資産は、通常、一時的なものであり、テストが完了するまで保持されます。 開発環境では、デバッグ目的でステージング カタログへのアクセスが必要になる場合もあります。
2. コードをマージする
データサイエンティストは、開発カタログまたは本番運用カタログのテーブルを使用して、開発環境でモデルトレーニングパイプラインを開発します。
プル要求。 デプロイ プロセスは、ソース管理のプロジェクトのメイン ブランチに対してプル要求が作成されたときに開始されます。
単体テスト (CI)。 プル要求は、ソース コードを自動的にビルドし、単体テストをトリガーします。 単体テストが失敗すると、プル要求は拒否されます。
単体テストはソフトウェア開発プロセスの一部であり、コードの開発中に継続的に実行され、コードベースに追加されます。 CI パイプラインの一部として単体テストを実行すると、開発ブランチで行われた変更によって既存の機能が損なわれることがなくなります。
3. 統合テスト (CI)
その後、CI プロセスによって統合テストが実行されます。 統合テストでは、すべてのパイプライン (特徴エンジニアリング、モデル トレーニング、推論、モニタリングなど) を実行して、それらが一緒に正しく機能することを確認します。 ステージング環境は、妥当な範囲で運用環境と一致している必要があります。
リアルタイム推論を使用して機械学習アプリケーションを配置する場合は、ステージング環境でサービス提供インフラストラクチャを作成してテストする必要があります。 これには、ステージング環境にサービスエンドポイントを作成し、モデルを読み込むモデル・デプロイメント・パイプラインのトリガーが含まれます。
統合テストの実行に必要な時間を短縮するために、テストの忠実度と速度またはコストの間でトレードオフするステップがあります。 たとえば、モデルのトレーニングにコストや時間がかかる場合は、データの小さなサブセットを使用したり、実行するトレーニングの反復回数を減らしたりできます。 モデルサービングの場合、本番運用の要件に応じて、統合テストで本格的な負荷テストを行ったり、小さなバッチジョブや一時的なエンドポイントへのリクエストをテストしたりする場合があります。
本番運用フェーズ
機械学習エンジニアは、機械学習パイプラインをデプロイして実行する本番運用環境を所有しています。 これらのパイプラインは、モデルのトレーニングをトリガーし、新しいモデル バージョンを検証してデプロイし、ダウンストリーム テーブルまたはアプリケーションに予測を発行し、プロセス全体を監視してパフォーマンスの低下と不安定性を回避します。
データサイエンティストは、通常、本番運用環境での書き込みまたはコンピュートアクセス権を持っていません。 ただし、テスト結果、記録済みモデル成果物、本番運用パイプラインステータス、およびモニタリングテーブルを可視化することが重要です。 この可視性により、本番運用の問題を特定して診断し、新しいモデルのパフォーマンスを現在本番運用中のモデルと比較することができます。 これらの目的のために、データサイエンティストに本番運用カタログ内のアセットへの読み取り専用アクセス権を付与できます。
番号付きのステップは、図に示されている番号に対応しています。
1. モデルをトレーニングする
このパイプラインは、コードの変更または自動再トレーニング ジョブによってトリガーできます。 このステップでは、本番運用カタログのテーブルを以下のステップで使用します。
トレーニングとチューニング。 トレーニング プロセス中に、ログは本番運用環境の MLflow 追跡サーバーに記録されます。 これらのログには、モデルメトリクス、パラメーター、タグ、およびモデル自体が含まれます。 特徴量テーブルを使用する場合、モデルは Databricks Feature Store クライアントを使用して MLflow に記録され、推論時に使用される特徴検索情報でモデルがパッケージ化されます。
開発中、データサイエンティストは多くのアルゴリズムとハイパーパラメーターをテストする場合があります。 運用環境のトレーニング コードでは、パフォーマンスの高いオプションのみを検討するのが一般的です。 この方法でチューニングを制限すると、時間が節約され、自動再トレーニングでのチューニングによる差異を減らすことができます。
データサイエンティストが本番運用カタログへの読み取り専用アクセス権を持っている場合、モデルに最適なハイパーパラメーターのセットを決定できる可能性があります。 この場合、本番運用にデプロイされたモデルトレーニングパイプラインは、通常、パイプラインに構成ファイルとして含まれている、選択されたハイパーパラメーターのセットを使用して実行できます。
評価。 モデルの品質は、ホールドアウトされた本番運用データでテストすることによって評価されます。 これらのテストの結果は、MLflow 追跡サーバーに記録されます。 このステップ は、開発段階でデータサイエンティストが指定した評価メトリクスを使用します。 これらのメトリクスには、カスタムコードが含まれる場合があります。
登録する model. model トレーニングが完了すると、モデル成果物は Unity Catalogの本番運用カタログ内の指定したモデルパスに登録されたモデルバージョンとして保存されます。 モデル トレーニング タスクは、モデル検証タスクで使用できるモデル URI を生成します。 タスク値を使用して、この URI をモデルに渡すことができます。
2. モデルの検証
このパイプラインでは、ステップ 1 のモデル URI を使用し、Unity Catalog からモデルを読み込みます。 次に、一連の検証チェックを実行します。 これらのチェックは組織とユースケースによって異なり、基本的な形式とメタデータの検証、選択したデータスライスのパフォーマンス評価、タグやドキュメントのコンプライアンスチェックなどの組織の要件への準拠などが含まれます。
モデルがすべての検証チェックに合格すると、Unity Catalog でモデル バージョンに "Challenger" エイリアスを割り当てることができます。 モデルがすべての検証チェックに合格しない場合、プロセスは終了し、ユーザーに自動的に通知されます。 タグを使用して、これらの検証チェックの結果に応じてキーと値の属性を追加できます。 たとえば、タグ "model_validation_status" を作成し、テストの実行時に値を "PENDING" に設定し、パイプラインの完了時に "PASSED" または "FAILED" に更新できます。
モデルは Unity Catalog に登録されているため、開発環境で作業しているデータサイエンティストは、本番運用カタログからこのモデル バージョンを読み込んで、モデルが検証に失敗したかどうかを調査できます。 結果にかかわらず、本番運用カタログに登録されたモデルには、モデルバージョンへの注釈が付けられて結果が記録されます。
3. モデルのデプロイ
検証パイプラインと同様に、モデル・デプロイメント・パイプラインは組織とユースケースによって異なります。 このセクションでは、新しく検証されたモデルに「Challenger」エイリアスが割り当てられており、既存の本番運用モデルに「Champion」エイリアスが割り当てられていることを前提としています。 新しいモデルをデプロイする前の最初のステップは、少なくとも現在の本番運用モデルと同等のパフォーマンスを確認することです。
「CHALLENGER」と「CHAMPION」モデルを比較します。 この比較は、オフラインまたはオンラインで実行できます。 オフライン比較では、両方のモデルがホールドアウトされたデータ セットに対して評価され、MLflow 追跡サーバーを使用して結果が追跡されます。 リアルタイム モデルサービングでは、A/B テストや新しいモデルの段階的なロールアウトなど、実行時間の長いオンライン比較を実行できます。 「Challenger」モデルバージョンが比較でより優れたパフォーマンスを発揮する場合は、現在の「Champion」エイリアスに置き換わります。
Mosaic AI Model ServingとDatabricksレイクハウスモニタリングを使用すると、エンドポイントのリクエストと応答のデータを含む推論テーブルを自動的に収集して監視できます。
既存の "チャンピオン" モデルがない場合は、ベースラインとして "チャレンジャー" モデルをビジネス ヒューリスティックまたはその他のしきい値と比較できます。
ここで説明するプロセスは完全に自動化されています。 手動承認ステップが必要な場合は、モデル・デプロイメント・パイプラインからのワークフロー通知またはCI/CDコールバックを使用して設定できます。
モデルをデプロイします。 バッチまたはストリーミング推論パイプラインは、「Champion」エイリアスを持つモデルを使用するように設定できます。 リアルタイムのユースケースでは、モデルを REST API エンドポイントとしてデプロイするためのインフラストラクチャを設定する必要があります。 このエンドポイントは、Mosaic AI Model Serving を使用して作成および管理できます。 エンドポイントが現在のモデルで既に使用されている場合は、エンドポイントを新しいモデルで更新できます。 Mosaic AI Model Serving は、新しい構成が準備されるまで既存の構成を実行し続けることで、ダウンタイムなしの更新を実行します。
4. モデルサービング
モデルサービング エンドポイントを構成するときは、Unity Catalog 内のモデルの名前と、提供するバージョンを指定します。 モデル バージョンが Unity Catalog のテーブルの特徴を使用してトレーニングされた場合、モデルには特徴と関数の依存関係が格納されます。 モデルサービングは、この依存関係グラフを自動的に使用して、推論時に適切なオンライン ストアから特徴を検索します。 このアプローチは、データの前処理に関数を適用したり、モデルのスコアリング中にオンデマンドの特徴をコンピュートしたりするためにも使用できます。
複数のモデルを持つ 1 つのエンドポイントを作成し、それらのモデル間で分割されるエンドポイント トラフィックを指定することで、オンラインで「チャンピオン」と「チャレンジャー」を比較できます。
5.推論:バッチまたはストリーミング
推論パイプラインは、本番運用カタログから最新のデータを読み取り、オンデマンド特徴量をコンピュートする関数を実行し、"Champion" モデルを読み込み、データをスコアリングし、予測を返します。 バッチまたはストリーミング推論は、一般に、高スループット、高レイテンシーのユースケースで最も費用対効果の高いオプションです。 低レイテンシーの予測が必要であるが、予測をオフラインでコンピュートできるシナリオでは、これらのバッチ予測を DynamoDB や Cosmos DB などのオンラインのキー値ストアに発行できます。
Unity Catalog に登録されているモデルは、そのエイリアスによって参照されます。 推論パイプラインは、"Champion" モデル バージョンを読み込んで適用するように構成されています。 "Champion" バージョンが新しいモデル バージョンに更新されると、推論パイプラインは次回の実行に新しいバージョンを自動的に使用します。 このようにして、モデルのデプロイ手順は推論パイプラインから切り離されます。
バッチジョブは、通常、本番運用カタログのテーブル、フラットファイル、またはJDBC接続を介して予測を公開します。 ストリーミング ジョブでは、通常、Unity Catalog テーブルまたは Apache Kafka などのメッセージ キューに予測が発行されます。
6. レイクハウスモニタリング
レイクハウスモニタリングは、入力データとモデル予測のデータ ドリフトやモデルのパフォーマンスなどの統計プロパティを監視します。 これらのメトリクスに基づいてアラートを作成するか、ダッシュボードで公開できます。
データ取り込み. このパイプラインは、バッチ、ストリーミング、またはオンライン推論からログを読み取ります。
精度とデータドリフトを確認します。 パイプライン コンピュート 入力データ、モデルの予測、およびインフラストラクチャのパフォーマンスに関するメトリクス。 データサイエンティストは開発時にデータとモデルのメトリクスを指定し、機械学習エンジニアはインフラストラクチャのメトリクスを指定します。 また、レイクハウスモニタリングを使用してカスタムメトリックを定義することもできます。
メトリクスを公開し、アラートを設定します。 パイプラインは、分析とレポート作成のために本番運用カタログのテーブルに書き込みます。 これらのテーブルは、データサイエンティストが分析のためにアクセスできるように、開発環境から読み取り可能に構成する必要があります。 Databricks SQL を使用して、モデルのパフォーマンスを追跡するためのモニタリング ダッシュボードを作成し、メトリクスが指定したしきい値を超えたときに通知を発行するようにモニタリング ジョブまたはダッシュボード ツールを設定できます。
モデルの再トレーニングをトリガーします。 モニタリング メトリクスがパフォーマンスの問題や入力データの変更を示している場合、データサイエンティストは新しいモデル バージョンを開発する必要がある場合があります。 これが発生したときにデータサイエンティストに通知するように SQL アラートを設定できます。
7. 再トレーニング
このアーキテクチャでは、上記と同じモデル トレーニング パイプラインを使用した自動再トレーニングがサポートされています。 Databricks では、スケジュールされた定期的な再トレーニングから開始し、必要に応じてトリガーによる再トレーニングに移行することをお勧めします。
予定。 新しいデータが定期的に利用可能な場合は、スケジュールされたジョブを作成して、利用可能な最新のデータでモデル トレーニング コードを実行できます。 「Databricks ジョブのトリガーの種類」を参照してください
トリガー。 モニタリング パイプラインでモデルのパフォーマンスの問題を特定し、アラートを送信できる場合は、再トレーニングをトリガーすることもできます。 たとえば、受信データの分布が大幅に変化した場合や、モデルのパフォーマンスが低下した場合、自動再トレーニングと再デプロイにより、人間の介入を最小限に抑えてモデルのパフォーマンスを向上させることができます。 これは、メトリクスが異常かどうかをチェックする SQL アラート (たとえば、しきい値に対するドリフトやモデル品質のチェック) によって実現できます。 アラートは、Webhook の宛先を使用するように構成でき、その後、トレーニング ワークフローをトリガーできます。
再トレーニング パイプラインまたは他のパイプラインでパフォーマンスの問題が発生した場合、データサイエンティストは、問題に対処するために追加の実験のために開発環境に戻る必要がある場合があります。