Dela via


Artefakter och modeller i MLflow

Den här artikeln beskriver MLflow-artefakter och MLflow-modeller och hur MLflow-modeller skiljer sig från andra artefakter. Artikeln förklarar också hur Azure Machine Learning använder egenskaperna för en MLflow-modell för att aktivera effektiva distributionsarbetsflöden.

Artefakter och modeller

I MLflow finns det några grundläggande skillnader mellan att logga enkla filartefakter och logga MLflow-modeller.

Artefakt

En artefakt är en fil som genereras och samlas in från ett experiments körning eller jobb. En artefakt kan vara en modell som serialiseras som en pickle-fil, vikten för en PyTorch- eller TensorFlow-modell eller en textfil som innehåller koefficienterna för en linjär regression. Vissa artefakter har inget att göra med själva modellen, utan innehåller körningskonfigurationer, förbearbetningsinformation eller exempeldata. Artefakter kan ha olika format.

I följande exempel loggas en filartefakt.

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

mlflow.log_artifact(filename)

Modell

En MLflow-modell är en artefakt där du gör starkare antaganden som ger ett tydligt kontrakt mellan de sparade filerna och vad de betyder. Men om du loggar modellens filer som artefakter måste du veta vad var och en av filerna betyder och hur du läser in dem för slutsatsdragning.

Du kan logga MLflow-modeller med hjälp av MLflow SDK, till exempel:

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

Loggning av MLflow-modeller i Azure Machine Learning har följande fördelar:

  • Du kan distribuera MLflow-modeller till realtids- eller batchslutpunkter utan att tillhandahålla ett bedömningsskript eller en miljö.
  • När du distribuerar MLflow-modeller genererar distributionerna automatiskt en swagger-fil, så att du kan använda testfunktionen i Azure Machine Learning-studio.
  • Du kan använda MLflow-modeller direkt som pipelineindata.
  • Du kan använda instrumentpanelen Ansvarsfull AI med MLflow-modeller.

MLmodel-formatet

För modeller som loggas som enkla artefaktfiler måste du veta vad modellverktyget avsåg för varje fil innan du kan läsa in modellen för slutsatsdragning. Men för MLflow-modeller läser du in modellen med MLmodel-formatet för att ange kontraktet mellan artefakterna och vad de representerar.

MLmodel-formatet lagrar tillgångar i en mapp som inte har något specifikt namngivningskrav. Bland tillgångarna finns en fil med namnet MLmodel som är den enda sanningskällan för hur du läser in och använder modellen.

Följande bild visar en MLflow-modellmapp med namnet credit_defaults_model i Azure Machine Learning-studio. Mappen innehåller MLmodel-filen och andra modellartefakter.

En skärmbild som visar tillgångar för en MLflow-exempelmodell, inklusive MLmodel-filen.

I följande exempel visas en MLmodel-fil för en modell för visuellt innehåll som tränats med fastai:

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 tillgängliga maskininlärningsramverk introducerade MLflow begreppet smak som ett sätt att tillhandahålla ett unikt kontrakt för alla maskininlärningsramverk. En smak anger vad du kan förvänta dig för en viss modell som skapats 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. Därför kan varje smak 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.

I följande exempel visas 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 MLflow-modellsignatur är en viktig del av modellspecifikationen 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 indatatyperna när data skickas till din modell. Mer information finns i Tillämpning av MLflow-signatur.

Signaturer anges vid den tidpunkt då modeller loggas och sparas i avsnittet i signature MLmodel-filen. Funktionen Autolog i MLflow gör automatiskt ett bästa försök att härleda signaturer. Du kan dock logga modeller 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:

  • Kolumnbaserade signaturer fungerar på tabelldata. För modeller med den här typen av signatur tillhandahåller pandas.DataFrame MLflow objekt som indata.
  • Tensor-baserade signaturer 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 numpy.ndarray med för namngivna tensorer.

I följande exempel visas avsnittet signature för 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 deras RGB-representation som osignerade heltal. Modellen matar ut batchar med förutsägelser som sannolikheter för två klasser.

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 en distribution av en MLflow-modell som har en tillgänglig signatur. Den här filen 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 filen conda.yaml . MLflow kan automatiskt identifiera beroenden, eller så kan du ange dem manuellt genom att anropa mlflow.<flavor>.log_model() metoden. Att anropa metoden kan vara användbart om de bibliotek som MLflow ingår i din miljö inte är de som du vill använda.

I följande conda.yaml-exempel visas en miljö för en modell som skapats med ramverket 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

Kommentar

En MLflow-miljö fungerar på modellnivå, men en Azure Machine Learning-miljö fungerar på arbetsytans nivå för registrerade miljöer eller på jobb-/distributionsnivå för anonyma miljöer. När du distribuerar MLflow-modeller skapar Azure Machine Learning modellmiljön och använder den för distribution. Du kan använda Azure Machine Learning CLI för att åsidosätta det här beteendet och distribuera MLflow-modeller till en specifik Azure Machine Learning-miljö.

Funktionen Predict (Förutsäga)

Alla MLflow-modeller innehåller en predict funktion som anropas när modellen distribueras med hjälp av en distribution utan kod. predict Vad funktionen returnerar, till exempel klasser, sannolikheter eller en prognos, beror på det ramverk eller den smak som används för träning. Dokumentationen för varje smak beskriver vad den returnerar.

Du kan anpassa predict funktionen för att ändra hur slutsatsdragningen körs. Du kan antingen logga modeller med ett annat beteende eller logga en anpassad modellsmak.

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

Du kan läsa in MLflow-modeller från följande platser:

  • 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 ger ett konsekvent sätt att läsa in dessa modeller oavsett plats.

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

  • Läs in samma objekt och typer som loggades. Du kan läsa in modeller med hjälp av MLflow SDK och hämta en instans av modellen med typer som tillhör träningsbiblioteket. En ONNX-modell (Open Neural Network Exchange) returnerar till exempel en 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 MLflow SDK och få en omslutning som har en garanterad predict funktion. Det spelar ingen roll vilken smak du använder, eftersom varje MLflow-modell har en predict funktion.

    MLflow garanterar att du kan anropa den här funktionen med hjälp av argument av typen pandas.DataFrame, numpy.ndarrayeller dict[string, numpyndarray], beroende på modellsignaturen. 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.