機械学習のライフサイクル

このページでは、機械学習 (ML) プロジェクトを最初のスコープから運用環境に移行し、時間の経過と同時に良好なパフォーマンスを維持するためのエンドツーエンドの取り組みについて説明します。 コード、データ、モデルは、開発、ステージング、運用という 3 つの広範なステージを通過します。 各ステージには、個別の目標と要件があります。

  1. ユース ケースのスコープを設定し、成功を定義する
  2. データを探索して理解する
  3. データと機能を準備する
  4. モデルを学習し、実験を追跡
  5. Evaluate
  6. モデルの登録、ステージング、テスト
  7. 運用環境にデプロイする
  8. 監視と再トレーニング

1. ユース ケースの範囲を指定し、成功を定義する

何かを構築する前に、モデルが実行する必要がある内容と、モデルが動作していることを認識する方法に合わせて調整します。

  • 予測ターゲットとは何ですか。また、分類、回帰、予測、推奨事項、ランク付け、異常検出など、ML の問題のクラスは何を意味しますか?
  • どの入力データを使用でき、ターゲット パターンを学習するだけで十分ですか?
  • 成功を定義するメトリックは、精度、AUC、K での精度、またはビジネス KPI です。
  • サービスと運用の要件は何ですか。待機時間、スループット、データの鮮度。
  • 本番環境へのデプロイを承認する必要がある関係者は誰ですか? 説明可能性に関する要件は何ですか?

上記の要件では、特定の ML メソッドは規定されていません。 勾配ブースト ツリーなどのよりシンプルなアプローチでモデリングを開始し、後で、より強力なディープ ラーニング方法が必要であると判断する場合があります。

2. データを探索して理解する

特徴を準備したり、モデルをトレーニングしたりする前に、データを調べて、その構造、品質、予測ターゲットとの関係を理解します。 探索的データ分析 (EDA) は、データセットを集計して視覚化し、分布、相関関係、欠損値、および下流モデリングの決定を形成する外れ値を視覚化するプロセスです。

早い段階で、学習に使わずに取り分けておいた有効なテストデータを確保できているかを、どのように検証するか決めておきます。 EDA 中でも、テスト データに基づいてモデリングを決定することに注意してください。

EDA は、ライフサイクルの残りの部分を通知する質問に回答します。

  • ターゲットを最も予測できる入力はどれですか。また、どの入力も提供時に使用できませんか?
  • クリーニングまたは変換を必要とする欠損値、外れ値、または偏った分布はありますか?
  • データセットは、ターゲット パターンを学習するのに十分な大きさであり、十分に代表的ですか?

Azure Databricksは、対話型、コラボレーション、AI 支援ツールを使用して EDA を簡素化します。 自然言語チャット、UI、またはコードを使用してデータを探索し、リアルタイムの共同編集と Git ベースのコード共有の両方を通じて共同作業を行います。

  • ノートブックは、 探索、視覚化、およびドキュメントのための共同作業スペースを提供します。
  • ダッシュボードは、 SQL と視覚化ベースの探索を提供します。
  • Genie Chat には、データに関する質問をするためのフル ページの自然言語インターフェイスが用意されています。
  • Genie Code は、完全に自動化された EDA を実行することも、対話型アシスタントとして機能することもできます。

3. データと機能を準備する

データが理解されたら、EDA 中に識別された生のソースと変換を ML モデルの機能に変換します。 データ ソースの速度、ボリューム、鮮度、所有権など、トレーニングとサービスのためにデータ パイプラインを評価します。 データ エンジニアリング (データの準備と変換) と特徴エンジニアリング (ML 入力の派生) の境界はあいまいです。 Azure Databricksでは、データ エンジニアリングと ML は Unity カタログで同じプラットフォームとガバナンス レイヤーを共有するため、あるチームによって準備されたデータを、データ移動や重複したパイプラインなしで、別のチームの機能としてすぐに利用できます。

既存のデータと機能の定義を検索します。

  • Unity カタログで使用できるデータと機能について調べる。 組織に関連するモデルがある場合は、Unity カタログ系列を使用して、それらのモデルに使用されるデータ ソースと機能を検出します。
  • ワークスペース検索 は、既に存在する管理データ、モデル、またはアプリケーションを検出するのに役立ちます。

必要に応じて、新しい資産を作成および管理します。

  • AI 支援型のコードなしのエクスペリエンスのための Lakeflow Designer など、データ インジェストとエンジニアリング用のツールの詳細については、Databricks を使用したデータ エンジニアリングに関する説明を参照してください。
  • フィーチャー ストアを使用して、再利用可能な管理資産として機能を定義および管理します。 同じ機能定義がトレーニングと運用環境で使用され、バッチデータインジェストとリアルタイムデータインジェスト、およびバッチおよびリアルタイムサービスがサポートされます。

Genie Code を使用して、Unity カタログを参照して関連するテーブルを検出し、特徴変換を提案し、インジェストと機能パイプラインのスターター コードを生成することで、データの検出と準備を高速化します。

4. モデルのトレーニングと実験の追跡

データ サイエンスアプリケーションと ML アプリケーションでは、さまざまなアプローチが使用され、それぞれに ML アルゴリズムとライブラリ、コンピューティング要件、ワークフローに対する独自の要件があります。 Azure Databricksは、MLflow で統合された実験追跡を使用して、さまざまなワークロードに柔軟な環境とコンピューティングを提供します。

環境とコンピューティング

既定では、対話型ノートブックと自動ジョブの両方に サーバーレス コンピューティング を使用します。 サーバーレス コンピューティングは即座に開始され、ワークロードに合わせて自動的にスケールアップとスケールダウンが行われます。

GPU アクセラレーションの場合は、GPU をサーバーレス コンピューティングにアタッチし、GPU のトレーニングと推論用に事前構成された環境である AI ランタイムを使用します。

CPU ワークロードと GPU ワークロードの両方で、Databricks Runtime for Machine Learningでクラシック コンピューティングを使用することもできます。

ML ライブラリを使用して、上記の環境のいずれかをカスタマイズします。 多くの場合、ML アプリケーション用に高度にカスタマイズされた環境では、MLflow 追跡を利用して依存関係を記録し、再現性を確認し、トレーニングサービスの傾斜を回避します。

MLflow の追跡

Azure Databricksマネージド MLflow を使用して、実験とログモデルのメタデータを追跡します。

  • 実験でプロジェクトログを整理し、トレーニングまたは評価用に記録されたランを管理します。
  • 各実行で、パラメーター、メトリック、および成果物を 自動的 または 手動でログに記録します。
  • 実験中に、 MLflow UI で実行を比較 して、最適なパフォーマンスの構成を見つけます。
  • MLflow でモデルをログに記録し、完全な来歴情報、つまりどのデータセット、どのコード、どの環境でこのモデルが生成されたかという情報とともに、モデルアーティファクトを保存します。 このメタデータにより、運用環境へのモデルのデプロイと、監査とトラブルシューティングが簡素化されます。

モデリングを始める

Genie Code では、Feature Store からの特徴選択、ML トレーニング、MLflow 追跡など、予測タスクのプレーン言語の説明から完全な ML ノートブックを生成できます。

ハイパーパラメーター調整に関するリソース、モデルのトレーニング例、および Databricks 上の Ray も参照してください。

ディープ ラーニングと GPU で高速化されたクラシック ML トレーニングについては、 AI ランタイムのノートブックの例を参照してください。

5. 評価

開発中に、スコーピングの要件に基づいて品質評価メトリックを定義します。

  • ベース メトリックは、精度、AUC、RMSE、ドメイン固有のメトリックなどの一般的な ML メトリックである場合があります。
  • また、評価には、データのセグメント間の基本メトリックを比較して測定された、母集団セグメント間のバイアスや公平性などの派生メトリックも含まれる場合があります。

選択した ML ライブラリまたはフレームワーク、 MLflow の組み込みメトリック モジュール、またはカスタム ロジックを使用してメトリックを定義します。 すべてのメトリックについて、 MLflow のログ メトリックが実行され 、対応するモデルにリンクされます。 開発中とトレーニング中に定義したメトリックは、後で 運用監視のメトリックとして再利用できます。

6. モデルの登録、ステージング、テスト

ML モデルまたはパイプラインをトレーニングした後、 Unity カタログの MLflow モデル レジストリ に登録して、運用に向けてモデルを昇格する際のガバナンスと管理を簡略化します。 登録済みモデルにはバージョンがあり、それぞれがそれを生成した元のトレーニング実行にリンクされます。 モデル バージョンを使用すると、安全なデプロイ ワークフローを実現できます。ステージングで新しいバージョンを運用環境に昇格させる前にテストし、品質が低下した場合は以前のバージョンにロールバックし、デプロイされた内容とタイミングの完全な監査証跡を維持することができます。

新しいモデル バージョンが運用トラフィックを処理する前に、現実的な条件下でステージングでバージョンをテストします。

  • 成果物の名前を変更せずにライフサイクルの状態を通知するために、候補のモデル バージョンにエイリアス (Staging、Production) のラベルを付けます。
  • ステージング インフラストラクチャに対して統合テストを実行する: サービング エンドポイントが起動すること、レイテンシが要件を満たしていること、そして出力が適切な形式になっていることを確認します。
  • 完全なカットオーバーの前に、運用データに対して A/B またはシャドウ テストを実行してパフォーマンスを検証します。
  • 評価結果に基づいて利害関係者のサインオフを収集します。

この説明では、デプロイプラクティスと ML 操作 (MLOps) を過度に単純化します。 mlOps の詳細については、Azure Databricksの MLOps ワークフローを参照してください。

7. 運用環境にデプロイする

ステージング検証の後、モデルを昇格して運用環境にデプロイし、実際の入力の予測を生成します。 Azure Databricksでは、次の 2 つの主要なサービス パターンがサポートされています。

  • リアルタイム サービス: トランザクション時の不正行為の傍受、ライブ パーソナル化、動的価格など、待ち時間の短い意思決定を必要とするユース ケースにモデル サービス を使用して、モデルを低待機時間の REST エンドポイントとしてデプロイします。
  • バッチ推論: ai_query は、 モデル サービス エンドポイントとしてデプロイされたカスタム モデルに対して効率的なバッチ推論を提供します。 バッチ推論には、Apache Spark UDF (例) または mlflow.pyfunc でカスタム コードを使用することもできます。 バッチ パイプラインは、ダウンストリーム アプリケーション、ダッシュボード、またはパイプラインのデルタ テーブルに結果を書き込みます。 このパターンは、毎日の予測、夜間の推奨事項の更新、およびその他の定期的なジョブを処理します。

どちらのパターンも、同じトレーニング済みモデル成果物を使用します。 一度トレーニングすれば、同じガバナンスとリネージを維持したまま、同じ登録済みバージョンを使ってバッチ推論にもリアルタイム推論にもデプロイできます。

Genie Code では、デプロイ用のコードを生成し 、サービスの問題のトラブルシューティング、エンドポイントの動作の説明、モデルの更新または再デプロイが必要な場合のイテレーションの高速化の両方を行うことができます。

8. 監視と再トレーニング

運用 ML システムは、ユーザーの動作の変化やデータ パイプラインの変化に伴い、時間の経過と同時に低下する可能性があります。 運用データとモデル予測を継続的に監視します。

  • デプロイされたモデルからの入力と出力をログに記録します。 リアルタイム サービスの 場合、推論テーブル では、モデル コードを変更せずに自動ログ記録が提供されます。 バッチ サービスの場合、パイプラインは Unity カタログによって管理される Delta テーブルとの間で自然に読み取りと書き込みを行います。
  • これらのログを データ品質監視にフィードします。これにより、時間の経過に伴うデータ品質、特徴の誤差、予測分布が追跡されます。 地上の真実またはフィードバック データがある場合は、このデータをサービス ログと結合して予測品質メトリックを計算できます。
  • 監視 UI と異常検出アラートを使用して、品質が著しく低下する前にエスカレーションまたは再トレーニングをトリガーします。

Azure Databricksの MLOps ワークフローで運用 ML の詳細を確認します。

その他のリソース

  • Last updated on