モデル・デプロイメント・パターン

この記事では、アーティファクト ML ステージングを通じて本番運用に移行するための 2 つの一般的なパターンについて説明します。 モデルとコードに対する変更の非同期的な性質は、ML 開発プロセスが従う可能性のある複数のパターンがあることを意味します。

モデルはコードによって作成されますが、結果のモデル アーティファクトとそれらを作成したコードは非同期に動作できます。 つまり、新しいモデル バージョンとコードの変更が同時に行われない可能性があります。 たとえば、次のシナリオについて考えてみます。

• 不正なトランザクションを検出するには、モデルを毎週再トレーニングする ML パイプラインを開発します。 コードはそれほど頻繁には変更されないかもしれませんが、新しいデータを組み込むためにモデルが毎週再トレーニングされる場合があります。
• 大型のディープニューラルネットワーク を作成して、ドキュメントを分類することができます。 この場合、モデルのトレーニングは計算コストと時間がかかり、モデルの再トレーニングはまれにしか行われない可能性があります。 ただし、このモデルをデプロイ、提供、および監視するコードは、モデルを再トレーニングせずに更新できます。

この 2 つのパターンは 、モデル アーティファクト と モデル アーティファクトを生成するトレーニング コードの どちらが本番運用に昇格されるかで異なります。

デプロイコード (推奨)

ほとんどの場合、Databricks では「コードのデプロイ」アプローチを推奨しています。 このアプローチは、 推奨される MLOps ワークフローに組み込まれています。

このパターンでは、モデルをトレーニングするコードは開発環境で開発されます。 同じコードがステージングに移動し、次に本番運用に移動します。 モデルは、最初はモデル開発の一部として開発環境で、統合テストの一部としてステージング環境(データの限られたサブセット上)、および本番運用環境(完全な本番運用データ上)で最終モデルを生成するために、各環境でトレーニングされます。

利点：

• 本番運用データへのアクセスが制限されている組織では、このパターンにより、本番運用環境の本番運用データでモデルをトレーニングできます。
• 自動モデルの再トレーニングは、トレーニングコードが本番運用のためにレビュー、テスト、承認されるため、より安全です。
• サポート コードは、モデル トレーニング コードと同じパターンに従います。 どちらもステージングで統合テストを受けます。

欠点：

• data scientistsがコードをコラボレーターに引き渡すための学習曲線は急な場合があります。事前定義されたプロジェクトテンプレートとワークフローが役立ちます。

また、このパターンでは、 data scientists ML 固有の問題を特定して修正するための知識を持っているため、本番運用環境からのトレーニング結果をレビューできる必要があります。

状況で、完全な本番運用データセットに対してモデルをステージングでトレーニングする必要がある場合は、コードをステージングにデプロイし、モデルをトレーニングしてから、モデルを本番運用にデプロイするというハイブリッドアプローチを使用できます。 このアプローチにより、本番運用のトレーニングコストは節約されますが、ステージングの運用コストが増加します。

モデルのデプロイ

このパターンでは、開発環境のトレーニング コードによってモデル アーティファクトが生成されます。 その後、アーティファクトはステージング環境でテストされてから、本番運用にデプロイされます。

このオプションは、次の 1 つ以上が当てはまる場合に検討してください。

• モデルのトレーニングは非常に高価であるか、再現が困難です。
• すべての作業は 1 つの Databricks ワークスペースで行われます。
• 外部リポジトリや CI/CD プロセスを使用していない。

利点：

• data scientistsのためのよりシンプルなハンドオフ
• モデルのトレーニングが高価な場合は、モデルのトレーニングを一度だけ行う必要があります。

欠点：

• 開発環境から本番運用データにアクセスできない場合(セキュリティ上の理由からそうである場合もあります)、このアーキテクチャは実行可能でない可能性があります。
• このパターンでは、自動モデルの再トレーニングは注意が必要です。 開発環境での再トレーニングを自動化することはできますが、モデルを本番運用にデプロイするチームは、結果のモデルを本番運用準備完了として受け入れない場合があります。
• 特徴量エンジニアリング、推論、モニタリングに使用されるパイプラインなどのサポートコードは、別途本番運用にデプロイする必要があります。

通常、環境 (開発、ステージング、または本番運用) は、 Unity Catalogのカタログに対応します。 このパターンの実装方法の詳細については 、アップグレード ガイドを参照してください。

次の図は、さまざまな実行環境間での上記のデプロイ パターンのコード ライフサイクルを対比しています。

図に示されている環境は、ステップが実行される最終的な環境です。 たとえば、デプロイ モデル パターンでは、最終的な単体テストと統合テストが開発環境で実行されます。 デプロイ コード パターンでは、単体テストと統合テストは開発環境で実行され、最終的な単体テストと統合テストはステージング環境で実行されます。