ログ モデルの依存関係

  • [アーティクル]

この記事では、モデルの提供などの運用タスクに使用できるように、モデルとその依存関係をモデル成果物としてログに記録する方法について説明します。

Python パッケージ モデルの依存関係をログに記録する

MLflow には、一部の Python ML ライブラリに対するネイティブ サポートがあります。ここでは、MLflow が、これらのライブラリを使用するモデルの依存関係を確実にログに記録できます。 組み込みのモデルフレーバーに関するページ (英語) を参照してください。

たとえば、MLflow は mlflow.sklearn モジュールで scikit-learn をサポートし、コマンド mlflow.sklearn.log_model が sklearn バージョンをログに記録します。 これらの ML ライブラリでの自動ログ記録でも同様です。 その他の例については、MLflow github リポジトリを参照してください。

pip install PACKAGE_NAME==VERSION を使用してインストールできるが、MLflow モデルのフレーバーが組み込まれていない ML ライブラリの場合は、mlflow.pyfunc.log_model メソッドを使用してこれらのパッケージをログに記録できます。 要件は、ライブラリの正確なバージョン (たとえば、単に nltk ではなく f"nltk=={nltk.__version__}") でログに記録するようにしてください。

mlflow.pyfunc.log_model は、次のログ記録をサポートします。

  • Python egg または Python wheel ファイルとしてパッケージ化されたパブリックとカスタムのライブラリ。
  • PyPI 上のパブリック パッケージと、独自の PyPI サーバー上でプライベートにホストされているパッケージ。

mlflow.pyfunc.log_model を使用すると、MLflow は依存関係を自動的に推論しようとします。 MLflow は、mlflow.models.infer_pip_requirements を使用して依存関係を推論し、それらをモデル成果物として requirements.txt ファイルにログ記録します。

古いバージョンで、特にライブラリが組み込みのモデル フレーバーでない場合には、MLflow が Python 要件のすべては自動識別しない場合があります。 このような場合は、log_model コマンドの extra_pip_requirements パラメーターを使用して追加の依存関係を指定できます。 extra_pip_requirements パラメーターの使用例を参照してください。

重要

要件のセット全体を conda_env と pip_requirements パラメーターで上書きすることもできますが、そうすると、MLflow が自動的に取得する依存関係をオーバーライドするため、通常は推奨されません。 要件を上書きするための pip_requirements パラメーターの使用方法の例を参照してください。

カスタマイズされたモデルのログ記録

よりカスタマイズされたモデルのログ記録が必要なシナリオでは、次のいずれかを実行できます。

  • カスタム Python モデルを記述する。 これにより、mlflow.pyfunc.PythonModel をサブクラス化して初期化と予測をカスタマイズできます。 このアプローチは、Python 専用モデルのカスタマイズに適しています。
  • カスタム フレーバーを記述する。 このシナリオでは、汎用の pyfunc フレーバーよりも多くのログ記録をカスタマイズできますが、これを行うには実装にさらに多くの作業が必要です。

カスタム Python コード

%pip install コマンドを使用してインストールできない Python コードの依存関係 (1 つ以上の .py ファイルなど) が存在する場合があります。

モデルをログに記録するときに、code_pathmlflow.pyfunc.log_model で パラメーターを使用して、指定したパスでモデルがそれらの依存関係を見つけることができることを MLflow に伝えることができます。 MLflow は、code_path を使用して渡されたファイルまたはディレクトリを、モデルとともに成果物としてコード ディレクトリに格納します。 モデルを読み込むときに、MLflow がこれらのファイルまたはディレクトリを Python パスに追加します。 この方法は、カスタム Python wheel ファイルでも機能します。これらは、.py ファイルと同様に、code_path を使用してモデルに含めることができます。

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Python 以外のパッケージ モデルの依存関係をログに記録する

MLflow は、Java パッケージ、R パッケージ、ネイティブ パッケージ (Linux パッケージなど) などの Python 以外の依存関係は自動的に取得しません。 これらのパッケージについては、追加のデータをログに記録する必要があります。

  • 依存関係リスト: Databricks は、これらの Python 以外の依存関係を指定するモデルとともに成果物をログに記録することをお勧めします。 これは単純な .txt または .json ファイルでかまいません。 mlflow.pyfunc.log_model を使用すると、artifacts 引数を使用してこの追加の成果物を指定できます。
  • カスタム パッケージ: 上記のカスタム Python 依存関係の場合と同様に、パッケージをデプロイ環境で使用できるようにする必要があります。 Maven Central や独自のリポジトリなどの中央の場所にあるパッケージの場合は、スコアリングや機能の提供時にその場所を使用できることを確認してください。 他の場所にもホストされていないプライベート パッケージの場合は、成果物としてモデルとともにパッケージをログに記録できます。

依存関係を含むモデルをデプロイする

MLflow 追跡サーバーまたはモデル レジストリからモデルをデプロイするときは、デプロイ環境に適切な依存関係がインストールされていることを確認する必要があります。 最も単純なパスは、デプロイ モード (バッチ/ストリーミングまたはオンライン サービス) と依存関係の種類によって異なります。

Databricks は、すべてのデプロイ モードについて、トレーニング中に使用したのと同じランタイム バージョンで推論を実行することをお勧めします。モデルを作成した Databricks Runtime にはさまざまなライブラリが既にインストールされているためです。 Databricks の MLflow は、databricks_runtime フィールドの MLmodel メタデータ ファイルにそのランタイム バージョン (databricks_runtime: 10.2.x-cpu-ml-scala2.12 など) を自動的に保存します。

オンライン サービス: Databricks の Model Serving

Databricks は Model Serving を提供します。ここには、MLflow 機械学習モデルがスケーラブルな REST API エンドポイントとして公開されます。

requirements.txt ファイル内の Python 依存関係の場合、Databricks と MLflow はパブリック PyPI の依存関係のすべてを処理します。 同様に、code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。

これらの Model Serving シナリオについては、次を参照してください。

requirements.txt ファイル内の Python 依存関係の場合、Databricks と MLflow はパブリック PyPI の依存関係のすべてを処理します。 同様に、code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。

オンライン サービス: サード パーティのシステムまたは Docker コンテナー

シナリオでサードパーティが提供するソリューションまたは独自の Docker ベースのソリューションにサービスを提供する必要がある場合は、Docker コンテナーとしてモデルをエクスポートできます。

Databricks は、Python の依存関係を自動的に処理するサードパーティのサービスに対して、次のことをお勧めします。 ただし、Python 以外の依存関係の場合は、それらを含むようにコンテナーを変更する必要があります。

バッチとストリーミング ジョブ

バッチとストリーミング スコアリングは、Databricks ジョブとして実行する必要があります。 多くの場合、ノートブック ジョブで十分です。コードを準備する最も単純な方法は、Databricks モデル レジストリを使用してスコアリング ノートブックを生成することです。

依存関係がインストールされ、それに応じて適用されるようにするためのプロセスと手順を次に示します。

  1. トレーニング中に使用されたのと同じ Databricks Runtime バージョンでスコアリング クラスターを開始します。 MLmodel メタデータ ファイルから databricks_runtime フィールドを読み取り、そのランタイム バージョンでクラスターを開始します。

    • これは、クラスター構成で手動で行うか、カスタム ロジックを使用して自動化できます。 自動化の場合、Jobs API と Clusters API でメタデータ ファイルからランタイム バージョン形式を読み取ります。

  2. 次に、Python 以外の依存関係をインストールします。 Python 以外の依存関係にデプロイ環境から確実にアクセスできるようにするには、次のいずれかを行います。

    • 推論を実行する前に、モデルの Python 以外の依存関係をクラスター構成の一部として Databricks クラスターに手動でインストールします。
    • 別の方法として、スコアリング ジョブのデプロイにカスタム ロジックを記述して、クラスターへの依存関係のインストールを自動化できます。 「Python 以外のパッケージ モデルの依存関係をログに記録する」で説明したように、Python 以外の依存関係を成果物として保存したとすると、この自動化では Libraries API を使用してライブラリをインストールできます。 あるいは、依存関係をインストールするクラスター スコープの初期化スクリプトを生成する特定のコードを記述することもできます。

  3. スコアリング ジョブは、ジョブ実行環境に Python の依存関係をインストールします。 Databricks でモデル レジストリを使用すると、次を自動的に行う推論用のノートブックを生成できます。

    • Databricks モデル レジストリを使用してスコアリング ノートブックを生成するときに、モデルの requirements.txt ファイルに Python の依存関係をインストールするコードがノートブックに含められます。 バッチまたはストリーミング スコアリング用のノートブック ジョブの場合、このコードがノートブック環境を初期化し、モデルの依存関係がインストールされて、モデルに対して準備されます。

  4. MLflow が、log_model の code_path パラメーターに含まれるカスタム Python コードを処理します。 このコードは、モデルの predict() メソッドが呼び出されたときに Python パスに追加されます。 これは、次のように手動で行うこともできます。

    Note

    code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。