Monitorowanie eksperymentów z użyciem MLflow: Uspokajanie chaosu wersji modeli

Problem z model_v2_final_FINAL_v2.pkl

Każdy, kto pracował nad projektem maszynowego uczenia po jego pierwszych kilku tygodniach, napotkał folder, który wygląda mniej więcej tak: model_v1.pkl, model_v2_new.pkl, model_v2_final.pkl, model_v2_final_FINAL.pkl, model_v2_final_FINAL_v2.pkl. Każdy plik reprezentuje rzeczywistą rundę treningową, z rzeczywistymi parametrami hiperprzestrzeni i rzeczywistym wynikiem oceny za jego plecami, ale żaden z tego kontekstu nie przetrwa w nazwie pliku. Trzy tygodnie później nikt już nie pamięta, czy v2_final używał stawki uczenia 0.01 lub 0.001, czy był to model treningowy przed czy po poprawce danych, czy wynik F1 walidacyjny był na prawdę lepszy od v1. Informacje istniały w momencie treningu modelu. Ale nie były one zapisane nigdzie trwało.

To nie jest problem związany z dyscypliną, który można naprawić poprzez lepsze konwencje nazewnictwa. To strukturalny problem: projekt maszynowego uczenia może łatwo wygenerować dziesiątki rund treningowych w ciągu jednego tygodnia, każda z własną kombinacją parametrów hiperprzestrzeni, zestawu cech, naszyjnika losowego i wersji kodu. Ręczne zapisywanie wszystkiego na arkuszu kalkulacyjnym nie przetrwa kontaktu z terminem. Narzędzia monitorujące eksperymenty istnieją specjalnie, aby sprawić, że ten rejestracja była automatyczna, a nie opcjonalna, i MLflow jest najpopularniejszą wolno dostępną opcją do realizacji tego.

Co MLflow rejestruje

MLflow organizuje pracę w ramach eksperymentów, a każdy oddzielny bieg treningowy w ramach danego eksperymentu jest zapisywany jako bieg z trzema kategoriami informacji automatycznie dołączonymi, jak tylko dodamy kilka linii kodu do rejestrowania wokół pętli treningowej:

Każdy bieg automatycznie zapisuje rzeczy, których człowiekby zapomniał zaznaczyć: kommita Git, który był sprawdzony, dokładne czas startu i zakończenia, a często również wersje pakietów środowiska. Wynik to jest taki, że bieg z trzech miesięcy temu można ponownie utworzyć z pewnością — nie tylko „model osiągnął wynik 0,83 na F1”, ale także konkretnych parametrów, wersji kodu i danych, które wygenerowały ten wynik.

Porównywanie wykonywań zamiast przypominanie sobie z pamięci

Zapisanie pojedynczego wykonywania w izolacji jest przydatne do celów dokumentacyjnych, ale rzeczywiste korzyści pojawiają się, gdy porównujemy setki wykonywań ze sobą. Interfejs monitorowania MLflow przedstawia każde zapisane wykonywanie jako wiersz w tabeli, gdzie parametry i metryki są kolumnami sortowalnymi i filtrowalnymi, co pozwala na odpowiedź na pytanie typu: „Czy zwiększenie max_depth ponad 6 naprawdę pomogło, czy może tylko zwiększyło czas treningowy?”. Zamiast przewijania się przez stare komórki notebooków próbując przypomnieć sobie, co było spróbowane, można po prostu posortować tabelę wykonywań według tego parametru i porównać kolumnę metryk. Wykonywania można również narysować w stosunku do siebie bezpośrednio — diagramy rozrzutu metryki względem parametru, lub diagramy współkoordynowane pokazujące, jak kilka hiperparametrów poruszały się razem w najlepiej performujących wykonywaniach, co często jest szybszym sposobem na odkrycie, że pewna kombinacja learning rate i rozmiaru lotej zawsze daje lepszy wynik niż każda inna próba do tej pory.

To przekształca proces prób i błąd, który byłby niestrukturalny — spróbuj coś, podglądaj rezultat, połowicznie przypominaj sobie, czy było lepiej niż poprzednio — w coś bliższe do poszukiwania eksperymentalnego z ablem wyszukiwania. Ma również tajemniczy korzyści: ponieważ każde wykonywanie jest zapisane w tej samej formie niezależnie od tego, kto go uruchomił, MLflow sprawia, że techniki wyszukiwania hiperparametrów, takie jak grid search, random search i optimizacja Bayesowska, są bardziej przydatne w praktyce, ponieważ setki lub nawet tysiące wykonywań generowanych przez te metody byliby niemal niemożliwe do sprawdzenia ręcznie.

Rejestr modeli: od eksperymentu do kandydata na produkcję

Śledzenie pojedynczych wykonań rozwiązuje problem „które parametry wygenerowały ten model”. Drugi, powiązany problem to „który model jest rzeczywiście uruchomiony w produkcji, a jak się go zastąpić?”. Rejestr modeli MLflow porusza tę kwestię, umożliwiając przypisanie artefaktu modelu specyficznego wykonań do nazwanego i wersjonowanego modelu — na przykład rejestracja wyjścia wykonań jako wersję 4 detekcji fraude. Każda zarejestrowana wersja może nosić etykietę fazy, taką jak Staging lub Produkcja, a przewodzenie modelu z fazy Staging do Produkcji staje się świadomym i audytowalnym działaniem, a nie kopiowaniem pliku na serwerze. Ta rozróżnienie ma znaczenie większe niż może na pierwszy rzut oka wydawać. Bez rejestratora „model w produkcji” to jest taki plik, który obecnie znajduje się w określonym katalogu, bez śladu tego, co go zastąpiło ani kiedy to nastąpiło. Z rejestratorem ma się jasne i pytanowalne historie: wersja 3 była w produkcji przez sześć tygodni, a wersja 4 zastąpiła ją po pokazaniu ulepszenia F1 o 2 punkty w fazie Staging, a jeśli okazało się, że wersja 4 ma problem po wdrożeniu, cofnięcie do wersji 3 jest kwestią zmiany etykiety fazy zamiast próby odzyskania starego wykonywania treningowego ze pamięci.

Gdzie monitorowanie eksperymentów mieści się w szerszej pipeline ML

MLflow jest zamiernie skoncentrowane: śledzi eksperymenty i zarządza rejestracją modeli, a resztę, taką jak serwowanie, konteneryzację i orkestrację infrastruktury, deleguje do innych narzędzi. W typowej produkcji pipeline MLflow siedzi obok, a nie zamiast, warstwy serwerowej wykorzystującej coś takiego jak FastAPI, kontenera stworzonego za pomocą Docker oraz warstwy monitoringu, która nadzoruje przesunięcie danych po wdrożeniu modelu. Połączenie między tymi elementami jest bezpośrednie: modelowy artefakt, który FastAPI ładuje i serwuje, to dokładnie artefakt, który MLflow zalogował dla określonego, śladowalnego wykonywania. Obraz Docker, który pakietuje ten usługę, może odnosić się do exact wersji pakietów, które MLflow zanotowało obok niego. Nie żadne z tych narzędzi nie zastępuje dobrego rozsądku dotyczącego, który model należy wysłać — ale bez monitorowania eksperymentów, decyzja ta musi być podjęta na podstawie pamięci i rozproszonych nazw plików, a z nimi, decyzja może być podjęta na podstawie rzeczywistego porównywalnego rekordu tego, co było spróbowane i jak dobrze działało każde podejście.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Experiment Tracking with MLflow i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.