モデルのデプロイ パターン

この記事では、ML 成果物をステージングによって運用環境に移動するための 2 つの一般的なパターンについて説明します。 モデルとコードに対する変更の非同期的な性質は、ML 開発プロセスで利用できるパターンが複数あることを意味します。

モデルはコードによって作成されますが、結果のモデル成果物と、それを作成したコードは、非同期的に動作できます。 つまり、新しいモデル バージョンとコードの変更が、同時に発生しない可能性があります。 たとえば、次のシナリオがあるとします。

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

この 2 つのパターンは、運用環境にプロモートされるのが、"モデル成果物" か、"モデル成果物を生成するトレーニング コード" かという違いがあります。

コードをデプロイする (推奨)

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

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

長所:

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

短所:

• データ サイエンティストがコードをコラボレーターに渡す学習曲線が、急激になる可能性があります。 定義済みのプロジェクト テンプレートとワークフローが役に立ちます。

また、このパターンでは、データ サイエンティストは、ML 固有の問題を識別して修正するための知識があるため、運用環境からのトレーニング結果を確認できる必要があります。

ステージングで完全な運用データセットに対してモデルをトレーニングする必要がある場合は、コードをステージングにデプロイし、モデルをトレーニングしてから、モデルを運用環境にデプロイすることで、ハイブリッド アプローチを使用できます。 この方法では、運用環境でのトレーニング コストを節約できますが、ステージングで余分な運用コストが発生します。

モデルをデプロイする

このパターンのモデル成果物は、開発環境でトレーニング コードによって生成されます。 成果物は、ステージング環境でテストされてから、運用環境にデプロイされます。

次の 1 つ以上が適用される場合は、このオプションを検討してください:

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

長所:

• データ サイエンティストに対するハンドオフがいっそう簡単です
• モデルのトレーニングにコストがかかる場合、モデルで必要なトレーニングが 1 回だけです。

短所:

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

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

次の図は、上記のデプロイ パターンのコードのライフサイクルを異なる実行環境について比較したものです。

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