In Teil 1 wurde gezeigt, wie mit MLflow in der Entwicklungsphase der Überblick über Metriken und Parameter behalten werden kann. Im zweiten Teil werden die Herausforderungen beschrieben, die sich beim Model Management ergeben.

Problem 2: Model Management

Trainierte Modelle werden in der Regel in anderen Software-Umgebungen eingesetzt als denen, in denen sie trainiert wurden. Daraus ergeben sich zwei Herausforderungen: Erstens müssen Modelle persistiert werden können. Zweitens muss Portabilität der Modelle zwischen unterschiedlichen Umgebungen gewährleistet sein. Hier besteht also ein Bedarf für ein einheitliches Format zum Speichern von Modellen und deren Abhängigkeiten. Die gespeicherten Modelle müssen außerdem den Parametern und Metriken aus den Trainingsläufen zugeordnet werden können.

MLflow Models

In MLflow können zusätzlich zu den Metriken und Parametern pro Run beliebige Dateien als Artefakte im Artifact Store gespeichert werden. Zu den Artefakten zählen auch trainierte Modelle. So kann der im Beispiel mit scikit-learn trainierte Entscheidungsbaum (fitted_model) als Artefakt gespeichert werden. Die Zuordnung geschieht über die ID des Runs. Zum Speichern von Modellen bietet das Modul MLflow Models ein plattformunabhängiges Format für Machine Learning Modelle. Es werden Schnittstellen für viele verbreitete Bibliotheken bereitgestellt, um trainierte Modelle im MLflow Models Format zu speichern. Unterstützte Frameworks sind unter anderem scikit-learn, tensorflow, keras, pytorch, h2o, xgboost, R und spark. Außerdem wird mit ONNX ein offenes Format zur Repräsentation von Deep Learning Modellen unterstützt.

Im vorigen Beispiel wurde ein scikit-learn Modell trainiert. Das Modell kann über das Python-Modul mlflow.sklearn exportiert werden:

Das Modell ist über drei Dateien definiert: MLmodel, conda.yaml und model.pkl. Diese drei Dateien werden von der log_model Funktion im Artifact Store in einem Verzeichnis abgelegt, das als Namen die ID des Runs trägt. Das Argument artifact_path legt das Unterverzeichnis fest.

Die model.pkl enthält das trainierte Modell als serialisiertes Python-Objekt.

In conda.yaml ist die zur Verwendung des Modells benötigte Umgebung definiert, in diesem Fall als Conda Environment. Alternativ können für manche flavors, also Modell-Typen, die Abhängigkeiten auch direkt mitgegeben werden.

In der MLmodel Datei sind Meta-Information über das Modell im YAML Format hinterlegt.

Links

 Lesen Sie auch Teil 1: Model Tracking und Teil 3: Model Serving.