Van artefacten naar modellen in MLflow

Artikel
12/28/2023

In het volgende artikel worden de verschillen uitgelegd tussen een MLflow-artefact en een MLflow-model en hoe u kunt overstappen van het ene naar het andere. Ook wordt uitgelegd hoe Azure Machine Learning gebruikmaakt van het concept van een MLflow-model om gestroomlijnde implementatiewerkstromen mogelijk te maken.

Wat is het verschil tussen een artefact en een model?

Als u niet bekend bent met MLflow, bent u mogelijk niet op de hoogte van het verschil tussen logboekregistratieartefacten of bestanden versus het vastleggen van MLflow-modellen. Er zijn enkele fundamentele verschillen tussen de twee:

Artefact

Een artefact is een bestand dat wordt gegenereerd (en vastgelegd) vanuit de uitvoering of taak van een experiment. Een artefact kan een model vertegenwoordigen dat is geserialiseerd als een pickle-bestand, de gewichten van een PyTorch- of TensorFlow-model, of zelfs een tekstbestand dat de coëfficiënten van een lineaire regressie bevat. Sommige artefacten kunnen ook niets te maken hebben met het model zelf; In plaats daarvan kunnen ze configuraties bevatten om het model uit te voeren, of informatie vooraf te verwerken, of voorbeeldgegevens, enzovoort. Artefacten kunnen in verschillende indelingen worden geleverd.

Mogelijk hebt u al artefacten logboekregistratie uitgevoerd:

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

mlflow.log_artifact(filename)

Model

Een model in MLflow is ook een artefact. We maken echter sterkere veronderstellingen over dit type artefact. Dergelijke veronderstellingen bieden een duidelijk contract tussen de opgeslagen bestanden en wat ze betekenen. Wanneer u uw modellen als artefacten (eenvoudige bestanden) aanmeldt, moet u weten wat de opbouwfunctie voor modellen voor elk van deze bestanden betekende, zodat u weet hoe u het model moet laden voor deductie. Integendeel, MLflow-modellen kunnen worden geladen met behulp van het contract dat is opgegeven in de MLmodel-indeling.

In Azure Machine Learning hebben logboekregistratiemodellen de volgende voordelen:

U kunt ze implementeren in realtime- of batcheindpunten zonder een scorescript of een omgeving op te geven.
Wanneer u modellen implementeert, worden voor de implementaties automatisch een swagger gegenereerd en kan de functie Test worden gebruikt in Azure Machine Learning-studio.
U kunt de modellen rechtstreeks als pijplijninvoer gebruiken.
U kunt het verantwoordelijke AI-dashboard gebruiken met uw modellen.

U kunt modellen registreren met behulp van de MLflow SDK:

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

De MLmodel-indeling

MLflow gebruikt de MLmodel-indeling als een manier om een contract te maken tussen de artefacten en wat ze vertegenwoordigen. In de MLmodel-indeling worden assets opgeslagen in een map. Onder deze assets bevindt zich een bestand met de naam MLmodel. Dit bestand is de enige bron van waarheid over hoe een model kan worden geladen en gebruikt.

In de volgende schermopname ziet u een voorbeeldmap van het MLflow-model in de Azure Machine Learning-studio. Het model wordt in een map geplaatst met de naam credit_defaults_model. Er is geen specifieke vereiste voor de naamgeving van deze map. De map bevat het MLmodel bestand onder andere modelartefacten.

De volgende code is een voorbeeld van hoe het MLmodel bestand voor een computer vision-model dat is getraind fastai , eruit kan zien:

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

Modelaroma's

Gezien het grote aantal machine learning-frameworks dat beschikbaar is voor gebruik, heeft MLflow het concept smaak geïntroduceerd als een manier om een uniek contract te bieden voor gebruik in alle Machine Learning-frameworks. Een smaak geeft aan wat u kunt verwachten voor een bepaald model dat is gemaakt met een specifiek framework. TensorFlow heeft bijvoorbeeld een eigen smaak, die aangeeft hoe een TensorFlow-model moet worden bewaard en geladen. Omdat elke modelsmaak aangeeft hoe het model moet worden behouden en geladen voor een bepaald framework, dwingt de MLmodel-indeling geen enkel serialisatiemechanisme af dat alle modellen moeten ondersteunen. Met deze beslissing kan elke smaak de methoden gebruiken die de beste prestaties of beste ondersteuning bieden volgens hun best practices, zonder de compatibiliteit met de MLmodel-standaard in gevaar te brengen.

De volgende code is een voorbeeld van de flavors sectie voor een fastai model.

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

Modelhandtekening

Een modelhandtekening in MLflow is een belangrijk onderdeel van de specificatie van het model, omdat het fungeert als een gegevenscontract tussen het model en de server waarop het model wordt uitgevoerd. Een modelhandtekening is ook belangrijk voor het parseren en afdwingen van de invoertypen van een model tijdens de implementatie. Als er een handtekening beschikbaar is, dwingt MLflow invoertypen af wanneer gegevens naar uw model worden verzonden. Zie MLflow-handtekening afdwingen voor meer informatie.

Handtekeningen worden aangegeven wanneer modellen worden geregistreerd en blijven behouden in de signature sectie van het MLmodel bestand. Met de functie Autolog in MLflow worden handtekeningen automatisch op een best mogelijke manier afgeleid. Mogelijk moet u de modellen echter handmatig registreren als de uitgestelde handtekeningen niet het model zijn dat u nodig hebt. Zie Modellen vastleggen met handtekeningen voor meer informatie.

Er zijn twee typen handtekeningen:

Handtekening op basis van kolommen: deze handtekening werkt op tabelgegevens. Voor modellen met dit type handtekening levert pandas.DataFrame MLflow objecten als invoer.
Handtekening op basis van tensor: deze handtekening werkt met n-dimensionale matrices of tensors. Voor modellen met deze handtekening levert numpy.ndarray MLflow invoer (of een woordenlijst in numpy.ndarray het geval van benoemde tensors).

Het volgende voorbeeld komt overeen met een Computer Vision-model dat is getraind met fastai. Dit model ontvangt een batch afbeeldingen die worden weergegeven als tensors van vorm (300, 300, 3) met de RGB-weergave ervan (niet-ondertekende gehele getallen). Het model voert batches voorspellingen (waarschijnlijkheden) uit voor twee klassen.

MLmodel

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

Tip

Azure Machine Learning genereert een swagger-bestand voor een implementatie van een MLflow-model met een handtekening die beschikbaar is. Hierdoor kunt u eenvoudiger implementaties testen met behulp van de Azure Machine Learning-studio.

Modelomgeving

Vereisten voor het model dat moet worden uitgevoerd, worden opgegeven in het conda.yaml bestand. MLflow kan automatisch afhankelijkheden detecteren of u kunt ze handmatig aangeven door de methode aan te mlflow.<flavor>.log_model() roepen. Dit laatste kan handig zijn als de bibliotheken die zijn opgenomen in uw omgeving niet de bibliotheken zijn die u wilt gebruiken.

De volgende code is een voorbeeld van een omgeving die wordt gebruikt voor een model dat is gemaakt met het fastai framework:

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

Notitie

Wat is het verschil tussen een MLflow-omgeving en een Azure Machine Learning-omgeving?

Hoewel een MLflow-omgeving op het niveau van het model werkt, werkt een Azure Machine Learning-omgeving op het niveau van de werkruimte (voor geregistreerde omgevingen) of taken/implementaties (voor anonieme omgevingen). Wanneer u MLflow-modellen implementeert in Azure Machine Learning, wordt de omgeving van het model gebouwd en gebruikt voor implementatie. U kunt dit gedrag ook overschrijven met de Azure Machine Learning CLI v2 en MLflow-modellen implementeren met behulp van een specifieke Azure Machine Learning-omgeving.

Functie voorspellen

Alle MLflow-modellen bevatten een predict functie. Deze functie wordt aangeroepen wanneer een model wordt geïmplementeerd met behulp van een implementatie zonder code. Wat de predict functie retourneert (bijvoorbeeld klassen, waarschijnlijkheden of een prognose), is afhankelijk van het framework (dat wil gezegd de smaak) die wordt gebruikt voor training. Lees de documentatie van elke smaak om te weten wat ze retourneren.

In dezelfde gevallen moet u deze predict functie mogelijk aanpassen om de manier waarop deductie wordt uitgevoerd te wijzigen. In dergelijke gevallen moet u modellen vastleggen met een ander gedrag in de voorspellingsmethode of de smaak van een aangepast model vastleggen.

Werkstromen voor het laden van MLflow-modellen

U kunt modellen laden die zijn gemaakt als MLflow-modellen vanaf verschillende locaties, waaronder:

rechtstreeks vanaf de uitvoering waar de modellen zijn geregistreerd
van het bestandssysteem waarin ze modellen worden opgeslagen
uit het modelregister waarin de modellen zijn geregistreerd.

MLflow biedt een consistente manier om deze modellen te laden, ongeacht de locatie.

Er zijn twee werkstromen beschikbaar voor het laden van modellen:

Laad hetzelfde object en dezelfde typen die zijn vastgelegd: u kunt modellen laden met behulp van de MLflow SDK en een exemplaar van het model verkrijgen met typen die behoren tot de trainingsbibliotheek. Een ONNX-model retourneert bijvoorbeeld een ModelProto tijdje een beslissingsstructuurmodel dat is getraind met scikit-learn retourneert een DecisionTreeClassifier object. Gebruik mlflow.<flavor>.load_model() dit om hetzelfde modelobject en dezelfde typen te laden die zijn vastgelegd.
Een model terug laden voor het uitvoeren van deductie: u kunt modellen laden met behulp van de MLflow SDK en een wrapper verkrijgen waarbij MLflow garandeert dat er een predict functie is. Het maakt niet uit welke smaak u gebruikt, elk MLflow-model heeft een predict functie. Bovendien garandeert MLflow dat deze functie kan worden aangeroepen met behulp van argumenten van het type pandas.DataFrame, numpy.ndarrayof dict[string, numpyndarray] (afhankelijk van de handtekening van het model). MLflow verwerkt de typeconversie naar het invoertype dat het model verwacht. Gebruik mlflow.pyfunc.load_model() deze functie om een model weer te laden voor het uitvoeren van deductie.