モデルの依存関係の記録

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

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

機械学習フローは、一部の Python 機械学習ライブラリをネイティブにサポートしており、機械学習フローはこれらのライブラリを使用するモデルの依存関係を確実にログに記録できます。 組み込みのモデル フレーバーを参照してください。

たとえば、MLflow は mlflow.sklearn モジュールで Scikit-Learn をサポートし、コマンド mlflow.sklearn.log_model sklearn のバージョンをログに記録します。 同じことが、これらの機械学習ライブラリを使用した 自動ロギング にも当てはまります。 その他の例については、 MLflow github リポジトリ を参照してください。

注

生成AI ワークロードのトレースログを有効にするために、 MLflow は OpenAI 自動ログをサポートしています。

pip install PACKAGE_NAME==VERSIONと共にインストールできるが、機械学習フローモデルフレーバーが組み込まれていない機械学習ライブラリの場合は、 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 のみのモデルのカスタマイズに適しています。

  • 簡単な例については、 N モデルの追加の例を参照してください。

  • より複雑な例については、カスタム XGBoost モデルの例を参照してください。

• カスタムフレーバーを記述します。このシナリオでは、一般的な pyfunc フレーバーよりもログをカスタマイズできますが、そのためには実装により多くの作業が必要です。

カスタム Python コード

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

MLflowモデルをログに記録するときに、code_path mlflow.pyfunc.log_model の 懸念を使用して、モデルが指定されたパスでこれらの依存関係を見つけることができることを に伝えることができます。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 では、そのランタイム バージョンが MLmodel メタデータ ファイルの databricks_runtime フィールド ( databricks_runtime: 10.2.x-cpu-ml-scala2.12など) に自動的に保存されます。

オンライン配信: Mosaic AI Model Serving

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

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

これらのモデル サービング シナリオについては、以下を参照してください。

• Model Servingでカスタム Python ライブラリを使用する

• Model Serving用のカスタム成果物とファイルをパッケージ化する

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

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

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

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

• Docker ベースのサービング ソリューションのための MLflow の Docker 統合: MLflow モデル ビルド ドッカー

バッチおよびストリーミングジョブ

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

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

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

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

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

   • 推論を実行する前に、モデルの Python 以外の依存関係をクラスター構成の一部として Databricks クラスターに手動でインストールします。

   • または、スコアリング ジョブのデプロイにカスタム ロジックを記述して、クラスターへの依存関係のインストールを自動化することもできます。 「Python 以外の パッケージ モデルの依存関係をログに記録する」の説明に従って、Python 以外の依存関係をアーティファクトとして保存したと仮定すると、この自動化ではライブラリ API を使用してライブラリをインストールできます。 または、特定のコードを記述して、依存関係をインストールするための クラスター スコープの初期化スクリプト を生成することもできます。

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

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

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

   • mlflow.pyfunc.spark_udf の呼び出し env_manager=['virtualenv'/'conda'] 引数で。

   • mlflow.pyfunc.get_model_dependencies を使用した要件の抽出 %pipインストールを使用してそれらをインストールします。

   注

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