機械学習ワークフローを Unity Catalog のターゲットモデルにアップグレードする

この記事では、機械学習 ワークフロー を Unity Catalogのターゲットモデルに移行およびアップグレードする方法について説明します。

要件

開始する前に、「 要件」の要件を満たしていることを確認してください。 特に、モデルのトレーニング、デプロイ、推論ワークフローの実行に使用されるユーザーまたはプリンシパルが、Unity Catalog に登録されているモデルに対して必要な権限を持っていることを確認してください。

  • トレーニング: 登録済みモデルの所有権 (新しいモデル バージョンの作成に必要)、および含まれているカタログとスキーマに対する USE CATALOG と USE SCHEMA の特権。

  • デプロイ: 登録済みモデルの所有権 (モデルにエイリアスを設定するために必要)、および外側のカタログとスキーマに対する USE CATALOG および USE SCHEMA 権限。

  • 推論: 登録済みモデルに対する EXECUTE 権限 (モデル バージョンの読み取りと推論の実行に必要)、および外側のカタログとスキーマに対する USE CATALOG 権限と 'USE SCHEMA 権限。

並列トレーニング、デプロイ、ワークフロー の作成

モデルのトレーニングと推論のワークフローを Unity Catalogにアップグレードするには、Databricks では、 Unity Catalogのモデルを活用する並列トレーニング、デプロイ、推論パイプラインを作成する増分アプローチをお勧めします。 Unity Catalog を使用した結果に慣れたら、ダウンストリームのコンシューマーを切り替えてバッチ推論出力を読み取るか、エンドポイントを提供する Unity Catalog のモデルにルーティングされるトラフィックを増やすことができます。

モデルトレーニングワークフロー

モデルのトレーニング ワークフローを複製します 。次に、次のことを確認します。

  1. ワークフロー クラスターは Unity Catalog にアクセスでき、「 要件」で説明されている要件を満たしています。

  2. ワークフローを実行するプリンシパルには、 Unity Catalogに登録されているモデル に対する必要な権限 があります。

次に、複製されたワークフローでモデル トレーニング コードを変更します。 ワークフローによって実行されるノートブックを複製するか、複製されたワークフローで新しい git ブランチを作成してターゲットにすることが必要になる場合があります。 次の手順に従って 、必要なバージョンの MLflow をインストールし、トレーニング コード内の Unity Catalog をターゲットにするようにクライアントを構成し、モデル トレーニング コードを Unity Catalogに登録する モデルを更新します。

モデル展開ワークフロー

モデルトレーニング ワークフローと同様の手順に従ってモデルデプロイワークフローを複製し、コンピュート構成を更新して Unity Catalogにアクセスできるようにします。

複製されたワークフローを所有するプリンシパル に必要なアクセス許可があることを確認します。 デプロイ ワークフローにモデル検証ロジックがある場合は、 UC からモデル バージョンを読み込むように更新します。 エイリアス を使用して、実稼働モデルのロールアウトを管理します。

モデル推論ワークフロー

バッチ推論ワークフロー

モデルトレーニングワークフロー と同様のステップ に従って、バッチ推論ワークフローを複製し、そのコンピュート構成を更新して Unity Catalogにアクセスできるようにします。複製されたバッチ推論ジョブを実行しているプリンシパルに、推論のためにモデルを読み込む ために必要なアクセス許可 があることを確認します。

環境間でのモデルの昇格

Databricks 、機械学習パイプラインをコードとしてデプロイすることをお勧めします。 これにより、すべての本番運用モデルを本番運用環境で自動化されたトレーニング ワークフローを通じて生成できるため、環境間でモデルをプロモートする必要がなくなります。

ただし、場合によっては、環境間でモデルを再トレーニングするにはコストがかかりすぎることがあります。 代わりに、Unity Catalog に登録されているモデル間でモデルバージョンをコピーして、環境間で昇格させることができます。

以下のコード例を実行するには、次の権限が必要です。

  • USE CATALOG staging および prod カタログにあります。

  • USE SCHEMA staging.ml_team スキーマと prod.ml_team スキーマ。

  • EXECUTE staging.ml_team.fraud_detection日に.

さらに、登録されたモデルの所有者である必要があります prod.ml_team.fraud_detection。

次のコード スニペットでは、MLflow バージョン 2.8.0 以降で使用できる copy_model_version MLflow クライアント API を使用しています。

import mlflow
mlflow.set_registry_uri("databricks-uc")

client = mlflow.tracking.MlflowClient()
src_model_name = "staging.ml_team.fraud_detection"
src_model_version = "1"
src_model_uri = f"models:/{src_model_name}/{src_model_version}"
dst_model_name = "prod.ml_team.fraud_detection"
copied_model_version = client.copy_model_version(src_model_uri, dst_model_name)

モデル バージョンが本番運用環境になったら、必要なデプロイ前の検証を実行できます。 その後、 エイリアスを使用して、デプロイするモデル バージョンをマークできます。

client = mlflow.tracking.MlflowClient()
client.set_registered_model_alias(name="prod.ml_team.fraud_detection", alias="Champion", version=copied_model_version.version)

上記の例では、 staging.ml_team.fraud_detection 登録済みモデルからの読み取りと prod.ml_team.fraud_detection 登録済みモデルへの書き込みが可能なユーザーのみが、本番運用環境にステージング モデルを昇格できます。 同じユーザーがエイリアスを使用して、本番運用環境内にデプロイされるモデルバージョンを管理することもできます。 モデルの昇格とデプロイを管理するために他のルールやポリシーを構成する必要はありません。

このフローをカスタマイズして、 dev、 qa、 prodなど、設定に一致する複数の環境でモデルバージョンを昇格させることができます。 アクセス制御は、各環境で構成されているとおりに適用されます。

モデルのデプロイの手動承認にジョブ Webhook を使用する

Databricks では、モデルのデプロイ プロセス中に適切なチェックとテストを使用して、可能な場合はモデルのデプロイを自動化することをお勧めします。 ただし、モデルをデプロイするために手動承認を実行する必要がある場合は、モデルが正常に完了した後、 ジョブ Webhook を使用して外部のCI/CDシステムを呼び出し、モデルのデプロイに対する手動承認をリクエストできます。 手動で承認されると、CI/CD システムは、たとえば「Champion」エイリアスを設定することで、モデル バージョンをデプロイしてトラフィックを処理できるようになります。