メインコンテンツまでスキップ
に最終更新

機械学習ライフサイクル

このページでは、機械学習 (ML) プロジェクトを初期の範囲設定から本番運用までエンドツーエンドで進め、継続的に高いパフォーマンスを維持する方法について説明します。コード、データ、モデルは、開発、ステージング、本番運用の3つの主要な段階を通過します。各ステージには独自の目標と要件があります：

  1. ユースケースの範囲を設定し、成功を定義します。
  2. データを探索し、理解する
  3. データ準備と特徴量
  4. モデルのトレーニングとエクスペリメントの追跡
  5. 評価
  6. 登録する、ステージング、モデルのテスト
  7. 本番運用へのデプロイ
  8. モニタリングと再トレーニング

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

何かを構築する前に、モデルが何を行う必要があるか、そしてそれが機能していることをどのように確認するかについて合意してください。

  • 予測ターゲットとは何ですか、その場合、どのような種類の機械学習の問題が示唆されますか：分類、回帰、予測、レコメンデーション、ランキング、異常検出、またはその他の問題ですか？
  • どのような入力データが利用可能で、ターゲットパターンを学習するのに十分でしょうか？
  • 成功を定義するメトリクスは何ですか：精度、AUC、Kにおける精度、またはビジネスKPI？
  • サービスと本番運用の要件：レイテンシ、スループット、データの鮮度とは何ですか？
  • どの関係者が本番運用のデプロイメントを承認する必要がありますか？説明可能性に関する要件は何ですか？

上記の要件は、特定の機械学習手法を規定するものではありません。勾配ブースティングツリーのような、よりシンプルなアプローチでモデリングを開始することもできますが、その後、より強力なディープラーニング手法が必要であると判断するかもしれません。

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

特徴量を準備したり、モデルをトレーニングしたりする前に、データを調査し、その構造、品質、および予測ターゲットとの関係を理解してください。 探索的データ解析（EDA） は、下流のモデリングの意思決定を左右する分布、相関、欠損値、および外れ値を明らかにするために、データセットを要約し視覚化するプロセスです。

早期に、トレーニングから除外される有効なテストデータがあるかを確認する方法を決定します。EDA中であっても、テストデータに基づいてモデリングの決定を下さないように注意してください。

EDA は、その後のライフサイクルを導く質問に答えます。

  • ターゲットの予測に最も寄与する入力はどれで、サービング時に利用できないものはありますか？
  • クリーニングや変換を必要とする欠損値、外れ値、または歪んだ分布はありますか？
  • データセットは、ターゲットパターンを学習するのに十分な大きさで、かつ代表的ですか？

Databricksは、インタラクティブで共同作業が可能なAIアシスト型ツールによってEDAを簡素化します。自然言語チャット、UI、またはコードを使用してデータを探索し、リアルタイムの共同編集とGitベースのコード共有の両方を通じて共同作業できます。

  • ノートブックは、探索、可視化、ドキュメント作成のための共同作業スペースを提供します。
  • ダッシュボードは、SQLと視覚化ベースの探索を提供します。
  • Genie Chatは、データに関する質問をするための全画面表示の自然言語インターフェースを提供します。
  • Genie Codeは、完全に自動化されたEDAを実行したり、インタラクティブなアシスタントとして機能したりできます。

3. データと特徴量の準備​

データが理解できたら、EDA中に特定された未加工のソースと変換を、機械学習モデル用の特徴量に変換します。トレーニングと提供のためのデータパイプラインを、速度、ボリューム、新鮮さ、データソースの所有権を含めて評価します。 データエンジニアリング （データの準備と変換）と 特徴量エンジニアリング （機械学習の入力導出）の境界線は曖昧です。Databricks では、データエンジニアリングと機械学習は、Unity Catalog で同じプラットフォームとガバナンス層を共有しているため、あるチームによって準備されたデータは、データ移動やパイプラインの重複なしに、別のチームの機能としてすぐに利用できます。

既存のデータと特徴量の定義の検索：

  • Unity Catalog で利用可能なデータと機能を調べます。組織に関連モデルがある場合は、Unity Catalogのリネージを使用して、それらのモデルで使用されているデータソースと特徴量を発見できます。
  • ワークスペース検索により、どのような管理されたデータ、モデル、またはアプリケーションが存在するかを発見することができます。

必要に応じて新規アセットを作成・管理：

  • AIアシスト機能とノーコード体験を提供するLakeflow Designer を含む、データ取り込みとデータエンジニアリングのツールについてさらに詳しくは、「Databricks を使用したデータエンジニアリング 」を参照してください。
  • Feature Store を使用して、特徴量を再利用可能で管理されたアセットとして定義および管理します。同じ特徴量定義がトレーニングと本番運用で使用され、バッチおよびリアルタイムデータの取り込みと、バッチおよびリアルタイムサービングに対応しています。

Genie Codeを使用して、Unity Catalogを閲覧することで関連テーブルを発見し、特徴量変換を提案し、取り込みと特徴量パイプラインのためのスターターコードを生成することで、データディスカバリーと準備を促進します。

4. モデルをトレーニングし、エクスペリメントを追跡する​

データサイエンスと機械学習アプリケーションは様々なアプローチを使用しますが、それぞれが機械学習アルゴリズムやライブラリ、コンピュート、ワークフローに対する独自の要件を持っています。Databricks は、さまざまなワークロードに対応する柔軟な環境とコンピュートを提供し、エクスペリメントトラッキングはMLflowの下に統合されています。

環境とコンピュート​

デフォルトでは、インタラクティブ ノートブックと自動ジョブの両方に、サーバレス コンピュートを使用します。サーバレスコンピュートはすぐに起動し、ワークロードに応じて自動的にスケールします。

GPUアクセラレーションには、サーバレスコンピュートにGPUをアタッチします。これにより、GPUトレーニングと推論のために事前設定された環境であるAI Runtimeが使用されます。

CPU および GPU ワークロードの両方で、クラシック コンピュートとDatabricks Runtime for Machine Learningも使用できます。

機械学習ライブラリを使用して前述のいずれかの環境をカスタマイズできます。機械学習アプリケーション向けに高度にカスタマイズされた環境では、MLflowトラッキングを活用して、依存関係を記録し、再現性を検証し、トレーニングと提供のずれを回避します。

MLflow トラッキング​

実験のトラッキングおよびモデルメタデータのログ記録には、Databricks が管理する MLflow を使用してください。

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

モデリングの使用を開始する​

Genie Code は、予測タスクの平易な言語の説明から、Feature Storeからの特徴量選択、機械学習のトレーニング、MLflowのトラッキングを含む完全な機械学習ノートブックを生成できます。

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

ディープラーニングおよび GPU で高速化された従来の機械学習トレーニングについては、AI Runtime のサンプルノートブックを参照してください。

5. 評価​

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

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

選択した機械学習ライブラリまたはフレームワーク、MLflow の組み込みメトリクスモジュール、または独自のロジックを使用してメトリクスを定義します。すべてのメトリクスについて、MLflow 実行でメトリクスをログに記録し、対応するモデルにリンクさせてください。開発およびトレーニング中に定義するメトリクスは、後で本番運用のモニタリングのメトリクスとして再利用できます。

6. モデルを登録、ステージング、テストする。​

機械学習モデルまたはパイプラインをトレーニングした後、モデルを本番運用にプロモートする際にガバナンスと管理を簡素化するために、Unity Catalog の MLflow Model Registry に登録します。登録済みモデルには複数のバージョンがあり、各バージョンは、その生成元となった元のトレーニング実行にリンクしています。モデルバージョンを使用すると、安全なデプロイメントワークフローが可能になります：本番運用に昇格させる前にステージングで新しいバージョンをテストしたり、品質が低下した場合は以前のバージョンにロールバックしたり、デプロイされた内容とタイミングの完全な監査証跡を維持したりすることができます。

新しいモデルバージョンが本番運用のトラフィックを処理する前に、現実的な条件下で、ステージング環境でバージョンをテストしてください：

この説明は、デプロイメントのプラクティスと機械学習運用（MLOps）を過度に単純化しています。MLOps の詳細については、DatabricksでのMLOpsワークフローを参照してください。

7. 本番運用にデプロイします。​

ステージング検証後、モデルを昇格および本番運用にデプロイし、実際の入力に対する予測を生成します。Databricks では、2つの主要なサービングパターンをサポートしています。

  • リアルタイムサービス ：トランザクション時の不正検出、ライブパーソナライゼーション、動的な価格設定など、低レイテンシでの意思決定が求められるユースケース向けに、Model Servingを使用してモデルを低レイテンシのRESTエンドポイントとしてデプロイします。
  • バッチ推論 ： 「ai_query」 は、Model Serving エンドポイントとしてデプロイされたカスタムモデルに効率的なバッチ推論を提供します。バッチ推論には、Apache Spark UDF（例）を使用してカスタムコードを利用することも、またはmlflow.pyfuncを使用することも可能です。バッチパイプラインは、下流のアプリケーション、ダッシュボード、またはパイプライン向けに、結果をDeltaテーブルに書き込みます。このパターンは、日次予測、夜間レコメンデーション更新、およびその他の定期的なジョブを処理します。

両方のパターンは同じ学習済みモデルアーティファクトを使用します。一度トレーニングし、同じ登録済みバージョンから、同じガバナンスとリネージを使用して、バッチまたはリアルタイムサービングにデプロイします。

Genie Codeは、デプロイ用のコードを生成するとともに、サービスの問題のトラブルシューティング、エンドポイントの動作の説明、およびモデルを更新または再デプロイする必要がある場合の反復開発の加速を支援します。

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

ユーザーの行動が変化したり、データパイプラインが変更されたりするにつれて、本番運用の機械学習システムは時間とともに劣化する可能性があります。本番運用データとモデル予測を継続的に監視する：

  • デプロイ済みのモデルのインプットとアウトプットを記録します。リアルタイムでの提供には、推論テーブルはモデルコードを変更することなく自動的にログを記録します。バッチサービングでは、パイプラインは自然に Unity Catalog によって管理される Delta テーブルを読み取り、書き込みます。
  • データ品質、特徴ドリフト、および経時的な予測分布を追跡するためのデータ品質モニタリングに、これらのログをフィードします。グラウンドトゥルースまたはフィードバックデータをお持ちの場合、このデータをサービングログと結合して、予測品質メトリクスをコンピュートできます。
  • 品質が著しく低下する前に、モニタリング UI と 異常検出アラート を使用して、エスカレーションまたは再トレーニングをトリガーしてください。

本番運用機械学習の詳細については、DatabricksにおけるMLOpsワークフローをご覧ください。

詳細を表示​

このページの見出し