Från artefakter till modeller i MLflow

Artikel
12/28/2023

I följande artikel beskrivs skillnaderna mellan en MLflow-artefakt och en MLflow-modell och hur du övergår från en till en annan. Den förklarar också hur Azure Machine Learning använder begreppet MLflow-modell för att aktivera effektiva distributionsarbetsflöden.

Vad är skillnaden mellan en artefakt och en modell?

Om du inte är bekant med MLflow kanske du inte känner till skillnaden mellan loggningsartefakter eller filer jämfört med MLflow-loggningsmodeller. Det finns några grundläggande skillnader mellan de två:

Artefakt

En artefakt är en fil som genereras (och hämtas) från ett experiments körning eller jobb. En artefakt kan representera en modell som serialiseras som en pickle-fil, vikten för en PyTorch- eller TensorFlow-modell eller till och med en textfil som innehåller koefficienterna för en linjär regression. Vissa artefakter kan inte heller ha något att göra med själva modellen. I stället kan de innehålla konfigurationer för att köra modellen, förbearbeta information eller exempeldata och så vidare. Artefakter kan komma i olika format.

Du kanske redan har loggat artefakter:

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

mlflow.log_artifact(filename)

Modell

En modell i MLflow är också en artefakt. Vi gör dock starkare antaganden om den här typen av artefakt. Sådana antaganden ger ett tydligt kontrakt mellan de sparade filerna och vad de betyder. När du loggar dina modeller som artefakter (enkla filer) måste du veta vad modellverktyget betydde för var och en av dessa filer så att du vet hur du läser in modellen för slutsatsdragning. Tvärtom kan MLflow-modeller läsas in med hjälp av kontraktet som anges i MLmodel-formatet.

I Azure Machine Learning har loggningsmodeller följande fördelar:

Du kan distribuera dem till realtids- eller batchslutpunkter utan att tillhandahålla ett bedömningsskript eller en miljö.
När du distribuerar modeller har distributionerna automatiskt en swagger genererad och testfunktionen kan användas i Azure Machine Learning-studio.
Du kan använda modellerna direkt som pipelineindata.
Du kan använda instrumentpanelen Ansvarsfull AI med dina modeller.

Du kan logga modeller med hjälp av MLflow SDK:

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

MLmodel-formatet

MLflow använder MLmodel-formatet som ett sätt att skapa ett kontrakt mellan artefakterna och vad de representerar. MLmodel-formatet lagrar tillgångar i en mapp. Bland dessa tillgångar finns en fil med namnet MLmodel. Den här filen är den enda sanningskällan om hur en modell kan läsas in och användas.

Följande skärmbild visar en MLflow-exempelmodells mapp i Azure Machine Learning-studio. Modellen placeras i en mapp med namnet credit_defaults_model. Det finns inget specifikt krav på namngivning av den här mappen. Mappen innehåller MLmodel filen bland andra modellartefakter.

Följande kod är ett exempel på hur MLmodel filen för en modell för visuellt innehåll som tränats med fastai kan se ut:

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

Modellsmaker

Med tanke på det stora antalet maskininlärningsramverk som är tillgängliga att använda introducerade MLflow begreppet smak som ett sätt att tillhandahålla ett unikt kontrakt för att arbeta i alla maskininlärningsramverk. En smak anger vad du kan förvänta dig för en viss modell som skapas med ett specifikt ramverk. TensorFlow har till exempel en egen smak, som anger hur en TensorFlow-modell ska sparas och läsas in. Eftersom varje modellsmak anger hur modellen ska sparas och läsas in för ett visst ramverk, framtvingar MLmodel-formatet inte en enda serialiseringsmekanism som alla modeller måste stödja. Det här beslutet gör att varje smak kan använda de metoder som ger bästa prestanda eller bästa stöd enligt deras bästa praxis – utan att äventyra kompatibiliteten med MLmodel-standarden.

Följande kod är ett exempel på avsnittet flavors för en 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

En modellsignatur i MLflow är en viktig del av modellens specifikation, eftersom den fungerar som ett datakontrakt mellan modellen och servern som kör modellen. En modellsignatur är också viktig för att parsa och framtvinga en modells indatatyper vid distributionstillfället. Om en signatur är tillgänglig framtvingar MLflow indatatyper när data skickas till din modell. Mer information finns i Tillämpning av MLflow-signatur.

Signaturer anges när modeller loggas och de sparas i avsnittet i signatureMLmodel filen. Funktionen Autolog i MLflow härleder automatiskt signaturer på bästa sätt. Du kan dock behöva logga modellerna manuellt om de härledda signaturerna inte är de du behöver. Mer information finns i Så här loggar du modeller med signaturer.

Det finns två typer av signaturer:

Kolumnbaserad signatur: Den här signaturen fungerar på tabelldata. För modeller med den här typen av signatur tillhandahåller pandas.DataFrame MLflow objekt som indata.
Tensor-baserad signatur: Den här signaturen fungerar med n-dimensionella matriser eller tensorer. För modeller med den här signaturen tillhandahåller numpy.ndarray MLflow som indata (eller en ordlista för numpy.ndarray i fallet med namngivna tensorer).

Följande exempel motsvarar en modell för visuellt innehåll som tränats med fastai. Den här modellen tar emot en uppsättning bilder som representeras som tensorer av form (300, 300, 3) med RGB-representationen av dem (osignerade heltal). Modellen matar ut batchar med förutsägelser (sannolikheter) för två klasser.

MLmodel

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

Dricks

Azure Machine Learning genererar en swagger-fil för distribution av en MLflow-modell med en signatur tillgänglig. Det gör det enklare att testa distributioner med hjälp av Azure Machine Learning-studio.

Modellmiljö

Krav för den modell som ska köras anges i conda.yaml filen. MLflow kan automatiskt identifiera beroenden eller så kan du ange dem manuellt genom att anropa mlflow.<flavor>.log_model() metoden. Det senare kan vara användbart om de bibliotek som ingår i din miljö inte är de som du avsåg att använda.

Följande kod är ett exempel på en miljö som används för en modell som skapats med ramverket fastai :

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

Kommentar

Vad är skillnaden mellan en MLflow-miljö och en Azure Machine Learning-miljö?

Medan en MLflow-miljö fungerar på modellnivå fungerar en Azure Machine Learning-miljö på arbetsytans nivå (för registrerade miljöer) eller jobb/distributioner (för anonyma miljöer). När du distribuerar MLflow-modeller i Azure Machine Learning skapas och används modellens miljö för distribution. Du kan också åsidosätta det här beteendet med Azure Machine Learning CLI v2 och distribuera MLflow-modeller med hjälp av en specifik Azure Machine Learning-miljö.

Funktionen Predict (Förutsäga)

Alla MLflow-modeller innehåller en predict funktion. Den här funktionen anropas när en modell distribueras med hjälp av en distributionsmiljö utan kod. predict Vad funktionen returnerar (till exempel klasser, sannolikheter eller en prognos) beror på det ramverk (det vill säga smaken) som används för träning. Läs dokumentationen för varje smak för att veta vad de returnerar.

I samma fall kan du behöva anpassa den här predict funktionen för att ändra hur slutsatsdragningen körs. I sådana fall måste du logga modeller med ett annat beteende i förutsägelsemetoden eller logga en anpassad modells smak.

Arbetsflöden för inläsning av MLflow-modeller

Du kan läsa in modeller som har skapats som MLflow-modeller från flera platser, inklusive:

direkt från körningen där modellerna loggades
från filsystemet där modellerna sparas
från modellregistret där modellerna är registrerade.

MLflow är ett konsekvent sätt att läsa in dessa modeller oavsett plats.

Det finns två tillgängliga arbetsflöden för inläsning av modeller:

Läs in samma objekt och typer som loggades: Du kan läsa in modeller med MLflow SDK och hämta en instans av modellen med typer som tillhör träningsbiblioteket. En ONNX-modell returnerar till exempel ett ModelProto medan en beslutsträdsmodell som tränats med scikit-learn returnerar ett DecisionTreeClassifier objekt. Använd mlflow.<flavor>.load_model() för att läsa in samma modellobjekt och typer som loggades.
Läs in en modell för att köra slutsatsdragning: Du kan läsa in modeller med hjälp av MLflow SDK och hämta en omslutning där MLflow garanterar att det kommer att finnas en predict funktion. Det spelar ingen roll vilken smak du använder, varje MLflow-modell har en predict funktion. Dessutom garanterar MLflow att den här funktionen kan anropas med argument av typen pandas.DataFrame, numpy.ndarrayeller dict[string, numpyndarray] (beroende på modellens signatur). MLflow hanterar typkonverteringen till den indatatyp som modellen förväntar sig. Använd mlflow.pyfunc.load_model() för att läsa in en modell för att köra slutsatsdragning.