Von Artefakten zu Modellen in MLflow

Artikel
01/02/2024

Im folgenden Artikel werden die Unterschiede zwischen einem MLflow-Artefakt und einem MLflow-Modell erläutert, und wie Sie vom einen zum anderen wechseln. Außerdem wird erläutert, wie Azure Machine Learning das Konzept eines MLflow-Modells verwendet, um optimierte Bereitstellungsworkflows zu ermöglichen.

Was ist der Unterschied zwischen einem Artefakt und einem Modell?

Wenn Sie mit MLflow nicht vertraut sind, kennen Sie möglicherweise nicht den Unterschied zwischen der Protokollierung von Artefakten oder Dateien und der Protokollierung von MLflow-Modellen. Es gibt einige wesentliche Unterschiede zwischen beiden:

Artefakt

Ein Artefakt ist jede Datei, die aus der Ausführung oder dem Auftrag eines Experiments generiert (und erfasst) wird. Ein Artefakt kann ein Modell serialisiert als Pickle-Datei, die Gewichtungen eines PyTorch- oder TensorFlow-Modells oder sogar eine Textdatei darstellen, die die Koeffizienten einer linearen Regression enthält. Einige Artefakte können auch nichts mit dem Modell selbst zu tun haben. Stattdessen könnten sie Konfigurationen zum Ausführen des Modells, zum Vorverarbeitung von Informationen oder Beispieldaten usw. enthalten. Artefakte können in verschiedenen Formaten vorliegen.

Möglicherweise haben Sie bereits Artefakte protokolliert:

filename = 'model.pkl'
with open(filename, 'wb') as f:
  pickle.dump(model, f)

mlflow.log_artifact(filename)

Modell

Ein Modell in MLflow ist auch ein Artefakt. Bei dieser Art von Artefakten gehen wir jedoch von strengeren Annahmen aus. Diese Annahmen bieten einen klaren Vertrag zwischen den gespeicherten Dateien und deren Bedeutung. Wenn Sie Ihre Modelle als Artefakte (einfache Dateien) protokollieren, müssen Sie wissen, was der oder die Ersteller*in des Modells sich bei jeder dieser Dateien gedacht hat, um zu wissen, wie das Modell für den Rückschluss geladen wird. Im Gegensatz dazu können MLflow-Modelle können mit dem Vertrag geladen werden, der im MLmodel-Format angegeben ist.

In Azure Machine Learning haben Protokollierungsmodelle die folgenden Vorteile:

Sie können sie an Echtzeit- oder Batchendpunkten ohne ein Bewertungsskript oder eine Umgebung bereitstellen.
Wenn Sie Modelle bereitstellen, werden die Bereitstellungen automatisch generiert, und das Feature Testen kann in Azure Machine Learning Studio verwendet werden.
Sie können die Modelle direkt als Pipelineeingaben verwenden.
Sie können das Dashboard für verantwortungsvolle KI mit Ihren Modellen verwenden.

Sie können Modelle mithilfe des MLflow-SDK protokollieren:

import mlflow
mlflow.sklearn.log_model(sklearn_estimator, "classifier")

Das MLModel-Format

MLflow übernimmt das MLModel-Format als Möglichkeit, einen Vertrag zwischen den Artefakten und dem zu erstellen, was sie darstellen. Das MLModel-Format speichert Ressourcen in einem Ordner. Unter diesen Ressourcen gibt es eine Datei mit dem Namen MLmodel. Diese Datei ist die einzige Quelle der Wahrheit darüber, wie ein Modell geladen und verwendet werden kann.

Der folgende Screenshot zeigt den Ordner eines MLflow-Beispielmodells in Azure Machine Learning Studio. Das Modell wird in einem Ordner mit dem Namen credit_defaults_model gespeichert. Für die Benennung dieses Ordners gibt es keine Vorgaben. Der Ordner enthält die MLmodel-Datei und andere Modellartefakte.

Der folgende Code ist ein Beispiel dafür, wie die MLmodel-Datei für ein Modell für maschinelles Sehen aussehen kann, die mit fastai trainiert wurde:

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]}
            }]'

Modellvarianten

Angesichts der Vielzahl der verfügbaren Machine-Learning-Frameworks hat MLflow das Konzept von Varianten als Möglichkeit eingeführt, einen einzigartigen Vertrag für alle Machine-Learning-Frameworks anzubieten. Eine Variante gibt an, was für ein bestimmtes, mit einem spezifischen Framework erstellten Modell erwartet werden soll. Beispielsweise verfügt TensorFlow über eine eigene Variante, die angibt, wie ein TensorFlow-Modell beibehalten und geladen werden soll. Da jede Modellvariante angibt, wie Modelle für ein bestimmtes Framework gespeichert und geladen werden sollen, erzwingt das MLmodel-Format keinen einzelnen Serialisierungsmechanismus, den alle Modelle unterstützen müssen. Diese Entscheidung ermöglicht es jeder Variante, die Methoden zu verwenden, die die beste Leistung oder beste Unterstützung gemäß der Best Practices bieten – ohne die Kompatibilität mit dem MLmodel-Standard zu beeinträchtigen.

Das folgende Beispiel ist ein Beispiel des flavors-Abschnitts für ein fastai-Modell.

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

Modellsignatur

Die Modellsignatur in MLflow ist ein wichtiger Bestandteil der Modellspezifikation, da sie als Datenvertrag zwischen dem Modell und dem Server dient, auf dem das Modell ausgeführt wird. Eine Modellsignatur ist auch wichtig für das Parsen und die Erzwingung der Eingabetypen eines Modells zur Bereitstellungszeit. Wenn eine Signatur verfügbar ist, erzwingt MLflow Eingabetypen, wenn Daten an Ihr Modell übermittelt werden. Weitere Informationen finden Sie unter Erzwingen von MLflow-Signaturen.

Signaturen werden angegeben, wenn Modelle protokolliert werden. Sie werden im Abschnitt signature der MLmodel-Datei gespeichert. Das Autolog-Feature in MLflow leitet Signaturen automatisch auf optimale Weise ab. Möglicherweise müssen Sie die Modelle jedoch manuell protokollieren, wenn die abgeleiteten Signaturen nicht die benötigten sind. Weitere Informationen finden Sie unter Protokollieren von Modellen mit Signaturen.

Es gibt zwei Arten von Signaturen:

Spaltenbasierte Signatur: Diese Signatur basiert auf Tabellendaten. Bei Modellen mit dieser Signatur liefert MLflow pandas.DataFrame-Objekte als Eingaben.
Tensorbasierte Signatur: Diese Signatur funktioniert mit n-dimensionalen Arrays oder Tensoren. Bei Modellen mit dieser Signatur liefert MLflow numpy.ndarray oder ein Wörterbuch von numpy.ndarray im Fall benannter Tensoren.

Das folgende Beispiel entspricht einem mit fastai trainierten Modell für maschinelles Sehen. Dieses Modell erhält einen Batch von Bildern, die als Tensoren der Form (300, 300, 3) mit der RGB-Darstellung dargestellt werden (ganze Zahlen ohne Vorzeichen). Das Modell gibt Batches von Vorhersagen (Wahrscheinlichkeiten) für zwei Klassen aus.

MLmodel

signature:
  inputs: '[{"type": "tensor",
             "tensor-spec": 
                 {"dtype": "uint8", "shape": [-1, 300, 300, 3]}
           }]'
  outputs: '[{"type": "tensor", 
              "tensor-spec": 
                 {"dtype": "float32", "shape": [-1,2]}
            }]'

Tipp

Azure Machine Learning generiert eine Swagger-Datei für die Bereitstellung eines MLflow-Modells mit einer verfügbaren Signatur. Dadurch wird es einfacher, Bereitstellungen mit Azure Machine Learning Studio zu testen.

Modellumgebung

Anforderungen für das auszuführende Modell werden in der conda.yaml-Datei angegeben. MLflow kann Abhängigkeiten automatisch erkennen oder manuell durch Aufrufen der mlflow.<flavor>.log_model()-Methode angeben. Letzteres kann nützlich sein, wenn die in Ihrer Umgebung enthaltenen Bibliotheken nicht die Bibliotheken sind, die Sie verwenden möchten.

Der folgende Code ist ein Beispiel für eine Umgebung, die für ein mit dem fastai-Framework erstelltes Modell verwendet wird:

conda.yaml

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

Hinweis

Was ist der Unterschied zwischen einer MLflow-Umgebung und einer Azure Machine Learning-Umgebung?

Während eine MLflow-Umgebung auf der Ebene des Modells arbeitet, wird eine Azure Machine Learning-Umgebung auf der Ebene des Arbeitsbereichs (für registrierte Umgebungen) oder Aufträge/Bereitstellungen (für anonyme Umgebungen) ausgeführt. Wenn Sie MLflow-Modelle in Azure Machine Learning bereitstellen, wird die Umgebung des Modells erstellt und für die Bereitstellung verwendet. Alternativ dazu können Sie dieses Verhalten mit der Azure Machine Learning CLI v2 außer Kraft setzen und MLflow-Modelle mithilfe einer speziellen Azure Machine Learning-Umgebung bereitstellen.

Prognosefunktion

Alle MLflow-Modelle enthalten eine predict-Funktion. Diese Funktion wird aufgerufen, wenn ein Modell mithilfe einer No-Code-Bereitstellungsumgebung bereitgestellt wird. Was die predict-Funktion zurückgibt (z. B. Klassen, Wahrscheinlichkeiten oder eine Prognose), hängt vom Framework (d. h. der Variante) ab, das fürs Training verwendet wird. Lesen Sie die Dokumentationen der einzelnen Varianten, um zu wissen, was sie zurückgeben.

In einigen Fällen müssen Sie die predict-Funktion möglicherweise anpassen, um zu ändern, wie der Rückschluss ausgeführt wird. In solchen Fällen müssen Sie Modelle mit einem anderen Verhalten in der Vorhersagemethode protokollieren oder die Variante eines benutzerdefinierten Modells protokollieren.

Workflows zum Laden von MLflow-Modellen

Sie können Modelle laden, die als MLflow-Modelle aus mehreren Speicherorten erstellt wurden, darunter:

direkt aus der Ausführung, in der die Modelle protokolliert wurden
aus dem Dateisystem, in dem die Modelle gespeichert werden
aus der Modellregistrierung, in der die Modelle registriert sind

MLflow bietet eine konsistente Methode, diese Modelle unabhängig vom Ort zu laden.

Es gibt zwei Workflows zum Laden von Modellen:

Zurückladen desselben Objekts und derselben protokollierten Typen: Sie können Modelle mithilfe des MLflow-SDK laden und eine Instanz des Modells mit Typen aus der Trainingsbibliothek abrufen. Beispielsweise gibt ein ONNX-Modell ModelProto zurück, während ein mit Scikit-learn trainiertes Entscheidungsstrukturmodell ein DecisionTreeClassifier-Objekt zurückgibt. Verwenden Sie mlflow.<flavor>.load_model(), um dasselbe Modellobjekt und dieselben protokollierten Typen zurückzuladen.
Zurückladen eines Modells zum Ausführen von Rückschlüssen: Sie können Modelle mithilfe des MLflow-SDK laden und einen Wrapper abrufen, für den MLflow eine predict-Funktion garantiert. Es spielt keine Rolle, welche Variante Sie verwenden, da jedes MLflow-Modell über eine predict-Funktion verfügt. Darüber hinaus garantiert MLflow, dass diese Funktion mithilfe von Argumenten vom Typ pandas.DataFrame, numpy.ndarray oder dict[string, numpyndarray] (je nach Signatur des Modells) aufgerufen werden kann. MLflow führt die Typkonvertierung in den Eingabetyp durch, den das Modell erwartet. Verwenden Sie mlflow.pyfunc.load_model(), um ein Modell für die Ausführung von Rückschlüssen zurückzuladen.