Z artefaktów do modeli w MLflow
W poniższym artykule wyjaśniono różnice między artefaktem MLflow i modelem MLflow oraz sposób przejścia z jednego do drugiego. Wyjaśniono również, w jaki sposób usługa Azure Machine Learning korzysta z koncepcji modelu MLflow w celu umożliwienia usprawnionych przepływów pracy wdrażania.
Jaka jest różnica między artefaktem a modelem?
Jeśli nie znasz biblioteki MLflow, możesz nie pamiętać o różnicy między artefaktami rejestrowania lub plikami a rejestrowaniem modeli MLflow. Istnieją pewne podstawowe różnice między nimi:
Artefakt
Artefakt to dowolny plik wygenerowany (i przechwycony) z przebiegu lub zadania eksperymentu. Artefakt może reprezentować model serializowany jako plik pickle, wagi modelu PyTorch lub TensorFlow, a nawet plik tekstowy zawierający współczynniki regresji liniowej. Niektóre artefakty mogą również nie mieć nic wspólnego z samym modelem; zamiast tego mogą zawierać konfiguracje umożliwiające uruchamianie modelu lub wstępne przetwarzanie informacji lub przykładowe dane itd. Artefakty mogą być dostępne w różnych formatach.
Być może masz już artefakty rejestrowania:
filename = 'model.pkl'
with open(filename, 'wb') as f:
pickle.dump(model, f)
mlflow.log_artifact(filename)
Model
Model w usłudze MLflow jest również artefaktem. Jednak wprowadzamy silniejsze założenia dotyczące tego typu artefaktu. Takie założenia zapewniają wyraźną umowę między zapisanymi plikami a tym, co oznaczają. Podczas rejestrowania modeli jako artefaktów (prostych plików) musisz wiedzieć, co konstruktor modelu ma dla każdego z tych plików, aby wiedzieć, jak załadować model na potrzeby wnioskowania. Wręcz przeciwnie, modele MLflow można załadować przy użyciu kontraktu określonego w formacie MLmodel.
W usłudze Azure Machine Learning modele rejestrowania mają następujące zalety:
- Można je wdrożyć w punktach końcowych w czasie rzeczywistym lub wsadowym bez podawania skryptu oceniania lub środowiska.
- Podczas wdrażania modeli wdrożenia automatycznie mają wygenerowany program Swagger, a funkcja testowa może być używana w usłudze Azure Machine Learning Studio.
- Modele można używać bezpośrednio jako danych wejściowych potoku.
- Pulpit nawigacyjny odpowiedzialnej sztucznej inteligencji można używać ze swoimi modelami.
Modele można rejestrować przy użyciu zestawu MLflow SDK:
import mlflow
mlflow.sklearn.log_model(sklearn_estimator, "classifier")
Format MLmodel
Platforma MLflow przyjmuje format MLmodel jako sposób tworzenia kontraktu między artefaktami a tym, co reprezentują. Format MLmodel przechowuje zasoby w folderze. Wśród tych zasobów znajduje się plik o nazwie MLmodel
. Ten plik jest pojedynczym źródłem prawdy o tym, jak można załadować i użyć modelu.
Poniższy zrzut ekranu przedstawia folder przykładowego modelu MLflow w usłudze Azure Machine Learning Studio. Model jest umieszczany w folderze o nazwie credit_defaults_model
. Nie ma określonego wymagania dotyczącego nazewnictwa tego folderu. Folder zawiera MLmodel
plik między innymi artefaktami modelu.
Poniższy kod to przykładowy wygląd MLmodel
pliku dla modelu przetwarzania obrazów wytrenowanego za pomocą fastai
polecenia:
Model ML
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, MLflow wprowadził koncepcję smaku jako sposób zapewnienia unikatowego kontraktu na pracę we wszystkich strukturach uczenia maszynowego. Smak wskazuje, czego można oczekiwać dla danego modelu utworzonego przy użyciu określonej platformy. Na przykład tensorFlow ma swój 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. Ta decyzja pozwala każdemu smakowi 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 kod jest przykładem flavors
sekcji modelu fastai
.
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 w usłudze 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 podczas rejestrowania modeli i są utrwalane w signature
sekcji MLmodel
pliku. Funkcja autologu w usłudze MLflow automatycznie wywnioskuje podpisy w najlepszy sposób. Może jednak być konieczne ręczne rejestrowanie modeli, 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:
- Podpis oparty na kolumnach: ten podpis działa na danych tabelarycznych. W przypadku modeli o tym typie podpisu platforma MLflow dostarcza
pandas.DataFrame
obiekty jako dane wejściowe. - Sygnatura oparta na tensorach: ten podpis działa z tablicami nwymiarowymi lub tensorami. W przypadku modeli z tym podpisem platforma MLflow dostarcza
numpy.ndarray
jako dane wejściowe (lub słowniknumpy.ndarray
w przypadku nazwanych tensorów).
Poniższy przykład odpowiada modelowi przetwarzania obrazów wytrenowanego za pomocą fastai
polecenia . Ten model otrzymuje partię obrazów reprezentowanych jako tensory kształtu (300, 300, 3)
z reprezentacją RGB (liczba całkowita bez znaku). Model generuje partie przewidywań (prawdopodobieństwa) dla dwóch klas.
Model ML
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 z dostępnym podpisem. Ułatwia to testowanie wdrożeń przy użyciu usługi Azure Machine Learning Studio.
Środowisko modelu
Wymagania dotyczące uruchamiania modelu są określone w conda.yaml
pliku . Narzędzie MLflow może automatycznie wykrywać zależności lub ręcznie wskazać je, wywołując metodę mlflow.<flavor>.log_model()
. Ten ostatni może być przydatny, jeśli biblioteki zawarte w twoim środowisku nie są tymi, które mają być używane.
Poniższy kod to przykład środowiska używanego dla modelu utworzonego za pomocą platformy 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
Uwaga
Jaka jest różnica między środowiskiem MLflow a środowiskiem usługi Azure Machine Learning?
Środowisko MLflow działa na poziomie modelu, ale środowisko usługi Azure Machine Learning działa na poziomie obszaru roboczego (w przypadku zarejestrowanych środowisk) lub zadań/wdrożeń (w przypadku środowisk anonimowych). Podczas wdrażania modeli MLflow w usłudze Azure Machine Learning środowisko modelu jest kompilowane i używane do wdrożenia. Alternatywnie można zastąpić to zachowanie za pomocą interfejsu wiersza polecenia usługi Azure Machine Learning w wersji 2 i wdrożyć modele MLflow przy użyciu określonego środowiska usługi Azure Machine Learning.
Predict, funkcja
Wszystkie modele MLflow zawierają predict
funkcję. Ta funkcja jest wywoływana, gdy model jest wdrażany przy użyciu środowiska wdrażania bez kodu. Zwracana predict
funkcja (na przykład klasy, prawdopodobieństwa lub prognoza) zależy od struktury (czyli smaku) używanej do trenowania. Zapoznaj się z dokumentacją każdego smaku, aby dowiedzieć się, co zwracają.
W takich samych przypadkach może być konieczne dostosowanie tej predict
funkcji w celu zmiany sposobu wykonywania wnioskowania. W takich przypadkach należy rejestrować modele o innym zachowaniu w metodzie predict lub rejestrować smak modelu niestandardowego.
Przepływy pracy służące do ładowania modeli MLflow
Modele utworzone jako modele MLflow można ładować z kilku lokalizacji, w tym:
- 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 dostępne do ładowania modeli:
Załaduj ponownie ten sam obiekt i typy, które zostały zarejestrowane: modele można załadować przy użyciu zestawu MLflow SDK i uzyskać wystąpienie modelu z typami należącymi do biblioteki szkoleniowej. Na przykład model ONNX zwraca model drzewa decyzyjnego
ModelProto
wytrenowany za pomocą biblioteki scikit-learn zwracaDecisionTreeClassifier
obiekt. Użyj poleceniamlflow.<flavor>.load_model()
, aby załadować z powrotem ten sam obiekt modelu i typy, które zostały zarejestrowane.Załaduj z powrotem model do uruchamiania wnioskowania: modele można załadować przy użyciu zestawu MLflow SDK i uzyskać otokę, w której platforma MLflow gwarantuje, że będzie
predict
istnieć funkcja. Nie ma znaczenia, którego smaku używasz, każdy model MLflow mapredict
funkcję. Ponadto MLflow gwarantuje, że ta funkcja może być wywoływana przy użyciu argumentów typupandas.DataFrame
,numpy.ndarray
lubdict[string, numpyndarray]
(w zależności od podpisu modelu). MLflow obsługuje konwersję typu na typ wejściowy, którego oczekuje model. Użyjmlflow.pyfunc.load_model()
polecenia , aby załadować model do uruchamiania wnioskowania.