MLflow の成果物とモデル
この記事では、MLflow 成果物と MLflow モデル、MLflow モデルが他の成果物と異なる点について説明します。 この記事では、Azure Machine Learning で MLflow モデルの特性を使って合理化されたデプロイ ワークフローを実現する方法についても説明します。
成果物とモデル
MLflow で単純なファイル成果物をログする処理と MLflow モデルをログする処理には、基本的な違いがいくつかあります。
Artifact
成果物とは、実験の実行またはジョブから生成され、取り込まれたファイルです。 成果物には、pickle ファイルとしてシリアル化されたモデル、PyTorch または TensorFlow モデルの重み、または線形回帰の係数を含むテキスト ファイルなどがあります。 一部の成果物には、モデル自体とは関係なく、実行の構成、前処理の情報、サンプル データなどが含まれています。 成果物にはさまざまな形式があります。
次の例では、ファイル成果物をログしています。
filename = 'model.pkl'
with open(filename, 'wb') as f:
pickle.dump(model, f)
mlflow.log_artifact(filename)
モデル
MLflow モデルとは、保存されたファイルとそれらが意味するものの間の明確なコントラクトを提供する、より強力な仮定を行う成果物です。 ただし、モデルのファイルを単に成果物としてログする場合は、各ファイルの意味と、推論のためにファイルを読み込む方法を把握している必要があります。
MLflow SDK を使用して、MLflow モデルをログできます。次に例を示します。
import mlflow
mlflow.sklearn.log_model(sklearn_estimator, "classifier")
Azure Machine Learning で MLflow モデルをログすると、次の利点があります。
- スコアリング スクリプトや環境を用意することなく、MLflow モデルをリアルタイムまたはバッチ エンドポイントにデプロイできます。
- MLflow モデルをデプロイすると、デプロイによって Swagger ファイルが自動的に生成されるため、Azure Machine Learning スタジオのテスト機能を使用できます。
- MLflow モデルをパイプラインの入力として直接使用できます。
- MLflow モデルには、責任ある AI ダッシュボードを使用できます。
MLmodel 形式
単純な成果物ファイルとしてログされたモデルの場合、推論のためにモデルを読み込む前に、モデル ビルダーが各ファイルについて何を意図したかを把握しておく必要があります。 ただし、MLflow モデルの場合は、"MLmodel 形式" を使用してモデルを読み込み、成果物とそれが表すものの間のコントラクトを指定します。
MLmodel 形式では、特定の名前付け要件がないフォルダーに資産が保存されます。 資産の中には、モデルの読み込みと使用方法に関する信頼できる唯一の情報源である MLmodel というファイルがあります。
次の画像は、Azure Machine Learning スタジオの credit_defaults_model という MLflow モデル フォルダーを示しています。 このフォルダーには、MLmodel ファイルとその他のモデル成果物が保存されています。
次の例は、fastai を使用してトレーニングされたコンピューター ビジョン モデルの MLmodel ファイルを示しています。
artifact_path: classifier
flavors:
fastai:
data: model.fastai
fastai_version: 2.4.1
python_function:
data: model.fastai
env: conda.yaml
loader_module: mlflow.fastai
python_version: 3.8.12
model_uuid: e694c68eba484299976b06ab9058f636
run_id: e13da8ac-b1e6-45d4-a9b2-6a0a5cfac537
signature:
inputs: '[{"type": "tensor",
"tensor-spec":
{"dtype": "uint8", "shape": [-1, 300, 300, 3]}
}]'
outputs: '[{"type": "tensor",
"tensor-spec":
{"dtype": "float32", "shape": [-1,2]}
}]'
モデル フレーバー
MLflow では、使用できる多数の機械学習フレームワークを考慮し、あらゆる機械学習フレームワークに適した独自のコントラクトを提供する方法として、"フレーバー" の概念を導入しました。 フレーバーは、特定のフレームワークで作成された特定のモデルに期待されることを示します。 たとえば、TensorFlow には、TensorFlow モデルを永続化して読み込む方法を指定する独自のフレーバーがあります。
特定のフレームワークのモデルを永続化して読み込む方法は各モデル フレーバーで示すので、MLmodel 形式では、すべてのモデルがサポートする必要がある 1 つのシリアル化メカニズムが強制されません。 そのため、各フレーバーは、MLmodel 標準との互換性を損なうことなく、ベスト プラクティスに従って最適なパフォーマンスまたは最適なサポートを提供するメソッドを使用できます。
次の例は、fastai モデルの flavors セクションを示しています。
flavors:
fastai:
data: model.fastai
fastai_version: 2.4.1
python_function:
data: model.fastai
env: conda.yaml
loader_module: mlflow.fastai
python_version: 3.8.12
モデル シグネチャ
MLflow のモデル シグネチャは、モデルとモデルを実行しているサーバー間のデータ コントラクトとして機能するため、モデルの仕様の重要な部分を占めています。 モデル シグネチャは、デプロイ時にモデルの入力の種類を解析して適用する場合にも重要です。 シグネチャを使用できる場合、データがモデルに送信されるときに、MLflow によって入力の種類が適用されます。 詳細については、MLflow シグネチャの適用に関する記事を参照してください。
シグネチャはモデルがログされるときに示され、MLmodel ファイルの signature セクションに保存されます。 MLflow の自動ログ機能を使用すると、ベスト エフォート形式で自動的にシグネチャを推測できます。 ただし、推測されたシグネチャが必要なものでない場合は、モデルを手動でログできます。 詳細については、「How to log models with signatures」(シグネチャを使ってモデルをログする方法) を参照してください。
シグネチャには、2 つの種類があります。
- 列ベースのシグネチャは表形式のデータに対して機能します。 この種のシグネチャを持つモデルの場合、MLflow は
pandas.DataFrameオブジェクトを入力として提供します。 - テンソルベースのシグネチャは、n 次元の配列またはテンソルで機能します。 このシグネチャを持つモデルの場合、MLflow は入力として
numpy.ndarray、または名前付きテンソルの場合はnumpy.ndarrayのディクショナリを提供します。
次の例は、fastai を使用してトレーニングされたコンピューター ビジョン モデルの signature セクションを示しています。 このモデルは、シェイプ (300, 300, 3) のテンソルとして表現された画像のバッチと、符号なし整数形式の RGB 表現を受け取ります。 このモデルは、2 つのクラスの確率として予測のバッチを出力します。
signature:
inputs: '[{"type": "tensor",
"tensor-spec":
{"dtype": "uint8", "shape": [-1, 300, 300, 3]}
}]'
outputs: '[{"type": "tensor",
"tensor-spec":
{"dtype": "float32", "shape": [-1,2]}
}]'
ヒント
Azure Machine Learning により、使用できるシグネチャを持つ MLflow モデルのデプロイ用の Swagger ファイルが生成されます。 このファイルにより、Azure Machine Learning スタジオを使用したデプロイのテストが簡単になります。
モデル環境
実行するモデルの要件は、conda.yaml ファイルで指定されます。 MLflow を使って依存関係を自動的に検出することや、mlflow.<flavor>.log_model() メソッドを呼び出して手動で依存関係を示すことができます。 MLflow によって環境に含まれたライブラリを使用する予定がない場合に、このメソッドを呼び出すと便利です。
次の conda.yaml の例は、fastai フレームワークを使用して作成されたモデルの環境を示しています。
channels:
- conda-forge
dependencies:
- python=3.8.5
- pip
- pip:
- mlflow
- astunparse==1.6.3
- cffi==1.15.0
- configparser==3.7.4
- defusedxml==0.7.1
- fastai==2.4.1
- google-api-core==2.7.1
- ipython==8.2.0
- psutil==5.9.0
name: mlflow-env
Note
MLflow 環境はモデルのレベルで機能しますが、Azure Machine Learning 環境は、登録済み環境の場合はワークスペース レベルで、匿名環境の場合はジョブおよびデプロイ レベルで機能します。 MLflow モデルをデプロイすると、Azure Machine Learning によってモデル環境が構築し、それがデプロイに使用されます。 Azure Machine Learning CLI を使用すると、この動作をオーバーライドし、MLflow モデルを特定の Azure Machine Learning 環境にデプロイできます。
Predict 関数
すべての MLflow モデルには、コードなしのデプロイを使用してモデルをデプロイするときに呼び出される predict 関数が含まれています。 predict 関数から返される内容 (クラス、確率、予測など) は、トレーニングに使用されたフレームワークやフレーバーによって変わります。 各フレーバーのドキュメントには、返される内容が記載されています。
predict 関数をカスタマイズして、推論の実行方法を変更できます。 異なる動作でモデルをログするか、カスタム モデル フレーバーをログすることができます。
MLflow モデルを読み込むためのワークフロー
MLflow モデルは次の場所から読み込むことができます。
- モデルがログされた実行から直接
- モデルが保存されているファイル システムから
- モデルが登録されているモデル レジストリから
MLflow は、場所に関係なく、これらのモデルを読み込む一貫した方法を提供します。
モデルを読み込むには 2 つのワークフローがあります。
ログされたものと同じオブジェクトと型を読み込みます。 MLflow SDK を使用してモデルを読み込み、トレーニング ライブラリに属する型を持つモデルのインスタンスを取得できます。 たとえば、Open Neural Network Exchange (ONNX) モデルからは
ModelProtoが返されますが、scikit-learnを使用してトレーニングされたデシジョン ツリー モデルからはDecisionTreeClassifierオブジェクトが返されます。mlflow.<flavor>.load_model()を使って、ログされたものと同じモデル オブジェクトと型を読み込みます。推論を実行するためのモデルを読み込みます。 MLflow SDK を使用してモデルを読み込み、保証された
predict関数を持つラッパーを取得できます。 すべての MLflow モデルにはpredict関数があるため、どのフレーバーを使用するかは問題ではありません。MLflow では、モデルのシグネチャに応じて、確実に型
pandas.DataFrame、numpy.ndarray、またはdict[string, numpyndarray]の引数を使用してこの関数を呼び出すことができます。 MLflow により、モデルで想定される入力の型への型変換が処理されます。mlflow.pyfunc.load_model()を使って、推論を実行するためのモデルを読み込みます。