Artefakty i modele w narzędziu MLflow

Artykuł
11/09/2024

W tym artykule opisano artefakty MLflow i modele MLflow oraz sposób, w jaki modele MLflow różnią się od innych artefaktów. W tym artykule wyjaśniono również, jak usługa Azure Machine Learning używa cech modelu MLflow do włączania usprawnionych przepływów pracy wdrażania.

Artefakty i modele

W rozwiązaniu MLflow istnieją pewne podstawowe różnice między rejestrowaniem prostych artefaktów plików a rejestrowaniem modeli MLflow.

Artefakt

Artefakt to dowolny plik wygenerowany i przechwycony z przebiegu lub zadania eksperymentu. Artefakt może być modelem serializowanym jako plik pickle, wagami modelu PyTorch lub TensorFlow albo plikiem tekstowym zawierającym współczynniki regresji liniowej. Niektóre artefakty nie mają nic wspólnego z samym modelem, ale zawierają konfiguracje uruchamiania, informacje wstępnego przetwarzania lub przykładowe dane. Artefakty mogą mieć różne formaty.

Poniższy przykład rejestruje artefakt pliku.

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

mlflow.log_artifact(filename)

Model

Model MLflow to artefakt, dla którego tworzysz silniejsze założenia, które zapewniają jasny kontrakt między zapisanymi plikami a tym, co oznaczają. Jeśli jednak pliki modelu są rejestrowane po prostu jako artefakty, musisz wiedzieć, co oznaczają poszczególne pliki i jak załadować je do wnioskowania.

Modele MLflow można rejestrować przy użyciu zestawu MLflow SDK, na przykład:

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

Rejestrowanie modeli MLflow w usłudze Azure Machine Learning ma następujące zalety:

Modele MLflow można wdrażać w punktach końcowych w czasie rzeczywistym lub wsadowym bez podawania skryptu oceniania lub środowiska.
Podczas wdrażania modeli MLflow wdrożenia automatycznie generują plik struktury Swagger, dzięki czemu można użyć funkcji Test w usłudze Azure Machine Learning Studio.
Modele MLflow można używać bezpośrednio jako danych wejściowych potoku.
Pulpit nawigacyjny odpowiedzialnej sztucznej inteligencji można używać z modelami MLflow.

Format MLmodel

W przypadku modeli zarejestrowanych jako proste pliki artefaktów należy wiedzieć, co konstruktor modelu przeznaczony dla każdego pliku przed załadowaniem modelu na potrzeby wnioskowania. Jednak w przypadku modeli MLflow model jest ładowany przy użyciu formatu MLmodel, aby określić kontrakt między artefaktami a tym, co reprezentują.

Format MLmodel przechowuje zasoby w folderze, który nie ma określonego wymagania dotyczącego nazewnictwa. Wśród zasobów znajduje się plik o nazwie MLmodel , który jest jednym źródłem prawdy na potrzeby ładowania i używania modelu.

Na poniższej ilustracji przedstawiono folder modelu MLflow o nazwie credit_defaults_model w usłudze Azure Machine Learning Studio. Folder zawiera plik MLmodel i inne artefakty modelu.

W poniższym przykładzie pokazano plik MLmodel dla modelu przetwarzania obrazów wyszkolony za pomocą fastaipolecenia :

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

Smaki modelu

Biorąc pod uwagę dużą liczbę dostępnych platform uczenia maszynowego, platforma MLflow wprowadziła koncepcję smaku jako sposób zapewnienia unikatowego kontraktu dla wszystkich struktur uczenia maszynowego. Smak wskazuje, czego można oczekiwać dla danego modelu utworzonego przy użyciu określonej platformy. Na przykład tensorFlow ma własny smak, który określa sposób utrwalania i ładowania modelu TensorFlow.

Ponieważ każdy wariant modelu wskazuje, jak utrwalać i ładować model dla danej platformy, format MLmodel nie wymusza pojedynczego mechanizmu serializacji, który musi obsługiwać wszystkie modele. W związku z tym każdy smak może używać metod zapewniających najlepszą wydajność lub najlepszą obsługę zgodnie z ich najlepszymi rozwiązaniami, bez naruszania zgodności ze standardem MLmodel.

Poniższy przykład przedstawia sekcję flavors fastai modelu.

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

Podpis modelu

Podpis modelu MLflow jest ważną częścią specyfikacji modelu, ponieważ służy jako kontrakt danych między modelem a serwerem, na którym działa model. Sygnatura modelu jest również ważna w przypadku analizowania i wymuszania typów danych wejściowych modelu w czasie wdrażania. Jeśli podpis jest dostępny, platforma MLflow wymusza typy danych wejściowych, gdy dane są przesyłane do modelu. Aby uzyskać więcej informacji, zobacz Wymuszanie podpisu MLflow.

Podpisy są wskazywane w czasie rejestrowania modeli i są utrwalane w signature sekcji pliku MLmodel . Funkcja autologowania w usłudze MLflow automatycznie dokłada wszelkich starań, aby wywnioskować podpisy. Można jednak rejestrować modele ręcznie, jeśli wnioskowane podpisy nie są tymi, których potrzebujesz. Aby uzyskać więcej informacji, zobacz Jak rejestrować modele z podpisami.

Istnieją dwa typy podpisów:

Podpisy oparte na kolumnach działają na danych tabelarycznych. W przypadku modeli o tym typie podpisu platforma MLflow dostarcza pandas.DataFrame obiekty jako dane wejściowe.
Sygnatury oparte na tensorach działają z tablicami nwymiarowymi lub tensorami. W przypadku modeli z tym podpisem biblioteka MLflow dostarcza numpy.ndarray jako dane wejściowe lub słownik numpy.ndarray dla nazwanych tensorów.

W poniższym przykładzie przedstawiono sekcję signature dla modelu przetwarzania obrazów wytrenowanego za pomocą fastaipolecenia . Ten model otrzymuje partię obrazów reprezentowanych jako tensory kształtu (300, 300, 3) z ich reprezentacją RGB jako niepodpisane liczby całkowite. Model generuje partie przewidywań jako prawdopodobieństwa dla dwóch klas.

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

Napiwek

Usługa Azure Machine Learning generuje plik swagger dla wdrożenia modelu MLflow, który ma dostępny podpis. Ten plik ułatwia testowanie wdrożeń przy użyciu usługi Azure Machine Learning Studio.

Środowisko modelu

Wymagania dotyczące uruchamiania modelu są określone w pliku conda.yaml . Narzędzie MLflow może automatycznie wykrywać zależności lub ręcznie wskazać je, wywołując metodę mlflow.<flavor>.log_model() . Wywoływanie metody może być przydatne, jeśli biblioteki, które MLflow zawarte w danym środowisku nie są bibliotekami, których zamierzasz użyć.

Poniższy przykład conda.yaml przedstawia środowisko dla modelu utworzonego za pomocą platformyfastai:

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

Uwaga

Środowisko MLflow działa na poziomie modelu, ale środowisko usługi Azure Machine Learning działa na poziomie obszaru roboczego dla zarejestrowanych środowisk lub poziomu zadań/wdrożeń dla środowisk anonimowych. Podczas wdrażania modeli MLflow usługa Azure Machine Learning kompiluje środowisko modelu i używa go do wdrożenia. Za pomocą interfejsu wiersza polecenia usługi Azure Machine Learning można zastąpić to zachowanie i wdrożyć modele MLflow w określonym środowisku usługi Azure Machine Learning.

Predict, funkcja

Wszystkie modele MLflow zawierają predict funkcję, która jest wywoływana podczas wdrażania modelu przy użyciu wdrożenia bez kodu. predict To, co funkcja zwraca, na przykład klasy, prawdopodobieństwa lub prognozę, zależy od struktury lub smaku używanego do trenowania. W dokumentacji każdego smaku opisano, co zwraca.

Funkcję można dostosować predict , aby zmienić sposób wykonywania wnioskowania. Modele rejestrowania można rejestrować przy użyciu innego zachowania lub rejestrować niestandardowy smak modelu.

Przepływy pracy służące do ładowania modeli MLflow

Modele MLflow można załadować z następujących lokalizacji:

Bezpośrednio z przebiegu, w którym zarejestrowano modele
Z systemu plików, w którym są zapisywane modele
Z rejestru modeli, w którym są rejestrowane modele

Rozwiązanie MLflow zapewnia spójny sposób ładowania tych modeli niezależnie od lokalizacji.

Istnieją dwa przepływy pracy służące do ładowania modeli:

Załaduj ponownie ten sam obiekt i typy, które zostały zarejestrowane. Modele można ładować przy użyciu zestawu MLflow SDK i uzyskiwać wystąpienie modelu z typami należącymi do biblioteki szkoleniowej. Na przykład model Open Neural Network Exchange (ONNX) zwraca ModelProtowartość , a model drzewa decyzyjnego wyszkolony za pomocą scikit-learn funkcji zwraca DecisionTreeClassifier obiekt. Użyj polecenia mlflow.<flavor>.load_model() , aby załadować z powrotem ten sam obiekt modelu i typy, które zostały zarejestrowane.
Załaduj model do uruchamiania wnioskowania. Modele można ładować przy użyciu zestawu SDK platformy MLflow i uzyskać otokę z gwarantowaną predict funkcją. Nie ma znaczenia, którego smaku używasz, ponieważ każdy model MLflow ma predict funkcję.

MLflow gwarantuje, że można wywołać tę funkcję przy użyciu argumentów typu pandas.DataFrame, numpy.ndarraylub dict[string, numpyndarray], w zależności od podpisu modelu. MLflow obsługuje konwersję typu na typ wejściowy, którego oczekuje model. Użyj mlflow.pyfunc.load_model() polecenia , aby załadować model do uruchamiania wnioskowania.

Udostępnij za pośrednictwem

Artefakty i modele w narzędziu MLflow