Przepływy pracy metodyki MLOps w usłudze Azure Databricks
W tym artykule opisano sposób użycia metodyki MLOps na platformie Databricks w celu optimize wydajności i długoterminowej wydajności systemów uczenia maszynowego. Zawiera on ogólne zalecenia dotyczące architektury MLOps i opisuje uogólniony przepływ pracy przy użyciu platformy Databricks, której można użyć jako modelu dla procesu programowania i produkcji uczenia maszynowego. Aby uzyskać informacje o modyfikacjach tego przepływu pracy dla aplikacji LLMOps, zobacz przepływy pracy LLMOps.
Aby uzyskać więcej informacji, zobacz The Big Book of MLOps (Książka big book of MLOps).
Co to jest MLOps?
Metodyka MLOps to set procesów i zautomatyzowanych kroków zarządzania kodem, danymi i modelami w celu poprawy wydajności, stabilności i długoterminowej wydajności systemów uczenia maszynowego. Łączy metodyki DevOps, DataOps i ModelOps.
Zasoby uczenia maszynowego, takie jak kod, dane i modele, są opracowywane na etapach, które przechodzą od wczesnych etapów programowania, które nie mają ścisłych ograniczeń dostępu i nie są rygorystycznie testowane przez etap testowania pośredniego do końcowego etapu produkcyjnego, który jest ściśle kontrolowany. Platforma Databricks umożliwia zarządzanie tymi zasobami na jednej platformie przy użyciu ujednoliconej kontroli dostępu. Aplikacje danych i aplikacje uczenia maszynowego można tworzyć na tej samej platformie, co zmniejsza ryzyko i opóźnienia związane z przenoszeniem danych.
Ogólne zalecenia dotyczące metodyki MLOps
Ta sekcja zawiera kilka ogólnych zaleceń dotyczących metodyki MLOps w usłudze Databricks z linkami, aby uzyskać więcej informacji.
Tworzenie oddzielnego środowiska dla każdego etapu
Środowisko wykonywania to miejsce, w where modele i dane są tworzone lub używane przez kod. Każde środowisko wykonywania składa się z wystąpień obliczeniowych, ich środowisk uruchomieniowych i bibliotek oraz zautomatyzowanych zadań.
Usługa Databricks zaleca tworzenie oddzielnych środowisk dla różnych etapów programowania kodu uczenia maszynowego i modelu z jasno zdefiniowanymi przejściami między etapami. Przepływ pracy opisany w tym artykule jest zgodny z tym procesem, używając nazw pospolitych etapów:
Inne konfiguracje mogą być również używane do spełnienia określonych potrzeb organizacji.
Kontrola dostępu i przechowywanie wersji
Kontrola dostępu i przechowywanie wersji są kluczowymi składnikami dowolnego procesu operacji oprogramowania. Usługa Databricks zaleca następujące kwestie:
- Użyj narzędzia Git do kontroli wersji. Potoki i kod powinny być przechowywane w usłudze Git na potrzeby kontroli wersji. Przeniesienie logiki uczenia maszynowego między etapami może być następnie interpretowane jako przenoszenie kodu z gałęzi programowania do gałęzi przejściowej do gałęzi wydania. Użyj folderów Git usługi Databricks, aby zintegrować się z dostawcą usługi Git oraz notesami sync notesami i kodem źródłowym z obszarami roboczymi usługi Databricks. Usługa Databricks udostępnia również dodatkowe narzędzia do integracji z usługą Git i kontroli wersji; zobacz Narzędzia programistyczne.
- Przechowuj dane w architekturze lakehouse przy użyciu Delta tables. Dane powinny być przechowywane w architekturze lakehouse na koncie chmury. Zarówno nieprzetworzone dane, jak i cecha tables powinny być przechowywane jako Delta tables z kontrolą dostępu, aby określić, kto może je odczytywać i modyfikować.
- Zarządzanie programowaniem modeli za pomocą platformy MLflow. Możesz użyć MLflow do śledzenia procesu tworzenia modelu i zapisywania migawek kodu, parametersmodelu, metryk i innych metadanych.
- Używanie modeli w środowisku Unity Catalog do zarządzania cyklem życia modelu. Używanie modeli w środowisku Unity Catalog do zarządzania przechowywaniem wersji modelu, zarządzaniem i stanem wdrożenia.
Wdrażanie kodu, a nie modeli
W większości sytuacji usługa Databricks zaleca, aby podczas procesu opracowywania uczenia maszynowego promować kod, a nie modele, z jednego środowiska do drugiego. Przeniesienie zasobów projektu w ten sposób gwarantuje, że cały kod w procesie programowania uczenia maszynowego przechodzi przez te same procesy przeglądu kodu i testowania integracji. Gwarantuje również, że wersja produkcyjna modelu zostanie wytrenowana na podstawie kodu produkcyjnego. Aby zapoznać się z bardziej szczegółowym omówieniem opcji i kompromisów, zobacz Wzorce wdrażania modelu.
Zalecany przepływ pracy metodyki MLOps
W poniższych sekcjach opisano typowy przepływ pracy metodyki MLOps obejmujący każdy z trzech etapów: programowanie, przemieszczanie i produkcja.
W tej sekcji użyto terminów "analityk danych" i "Inżynier uczenia maszynowego" jako archetypalnych personas; określone role i obowiązki w przepływie pracy metodyki MLOps będą się różnić w zależności od zespołów i organizacji.
Etap programowania
Celem etapu programowania jest eksperymentowanie. Naukowcy danych opracowują cechy i modele oraz przeprowadzają eksperymenty w celu optimize oceny wydajności modelu. Dane wyjściowe procesu programowania to kod potoku uczenia maszynowego, który może obejmować obliczenia funkcji, trenowanie modelu, wnioskowanie i monitorowanie.
Liczba kroków odpowiada liczbom pokazanym na diagramie.
1. Źródła danych
Środowisko deweloperskie jest reprezentowane przez dev catalog w Unity Catalog. Analitycy danych mają dostęp do odczytu i zapisu do dev catalog, gdy tworzą tymczasowe dane i cechę tables w obszarze roboczym deweloperskim. Modele utworzone na etapie rozwoju są rejestrowane w środowisku deweloperskim catalog.
W idealnym scenariuszu naukowcy danych pracujący w obszarze roboczym rozwoju mają również dostęp tylko do odczytu do danych produkcyjnych w prod catalog. Umożliwienie specjalistom ds. danych dostępu do odczytu danych produkcyjnych, wnioskowania tablesoraz metryki tables w środowisku produkcyjnym catalog, pozwala im na analizowanie bieżących przewidywań i wydajności modelu produkcyjnego. Analitycy danych powinni również mieć możliwość ładowania modeli produkcyjnych na potrzeby eksperymentowania i analizy.
Jeśli nie można grant dostępu tylko do odczytu do catalogprod, migawka danych produkcyjnych może zostać zapisana w catalog deweloperskich, aby umożliwić analitykom danych opracowywanie i ocenianie kodu projektu.
2. Eksploracyjna analiza danych (EDA)
Analitycy danych eksplorują i analizują dane w interaktywnym, iteracyjnym procesie przy użyciu notesów. Celem jest ocena, czy dostępne dane mają potencjał do rozwiązania problemu biznesowego. W tym kroku analityk danych rozpoczyna identyfikowanie kroków przygotowywania i cechowania danych na potrzeby trenowania modelu. Ten proces ad hoc zazwyczaj nie jest częścią potoku, który zostanie wdrożony w innych środowiskach wykonywania.
Rozwiązanie AutoML przyspiesza ten proces, generując modele bazowe dla zestawu danych. Rozwiązanie AutoML wykonuje i rejestruje set prób oraz udostępnia notes języka Python z kodem źródłowym dla każdego przebiegu wersji próbnej, dzięki czemu można przeglądać, odtwarzać i modyfikować kod. Rozwiązanie AutoML oblicza również statystyki podsumowania zestawu danych i zapisuje te informacje w notesie, który można przejrzeć.
3. Kod
Repozytorium kodu zawiera wszystkie potoki, moduły i inne pliki projektu dla projektu uczenia maszynowego. Analitycy danych tworzą nowe lub zaktualizowane potoki w gałęzi programowania ("dev") repozytorium projektu. Począwszy od EDA i początkowych faz projektu, analitycy danych powinni pracować w repozytorium, aby udostępnić kod i śledzić zmiany.
4. Trenowanie modelu (programowanie)
Naukowcy danych opracowują potok trenowania modelu w środowisku deweloperskim przy użyciu tables z deweloperskiego lub produkcyjnego catalogs.
Ten potok obejmuje 2 zadania:
Trenowanie i dostrajanie. Proces trenowania rejestruje model parameters, metryki i artefakty na serwerze śledzenia MLflow. Po przeszkoleniu i dostrojeniu hiperparametrów końcowy plik modelu jest rejestrowany na serwerze śledzenia w celu zapisania połączenia między modelem, danymi wejściowymi, na których został przeszkolony, a kodem użytym do generate.
Ocena Ocena jakości modelu przez testowanie danych przechowywanych. Wyniki tych testów są rejestrowane na serwerze śledzenia MLflow. Celem oceny jest ustalenie, czy nowo opracowany model działa lepiej niż bieżący model produkcyjny. W przypadku posiadania wystarczających uprawnień, każdy model produkcyjny zarejestrowany w prod catalog można załadować do obszaru roboczego rozwoju i porównać z nowo wytrenowanym modelem.
Jeśli wymagania dotyczące ładu w organizacji zawierają dodatkowe informacje o modelu, możesz zapisać go przy użyciu śledzenia platformy MLflow. Typowe artefakty to zwykłe opisy tekstu i interpretacje modeli, takie jak wykresy generowane przez algorytm SHAP. Określone wymagania dotyczące ładu mogą pochodzić od dyrektora ds. ładu danych lub osób biorących udział w projekcie biznesowym.
Dane wyjściowe potoku trenowania modelu to artefakt modelu uczenia maszynowego przechowywany na serwerze śledzenia MLflow dla środowiska deweloperskiego. Jeśli potok jest wykonywany w obszarze roboczym przejściowym lub produkcyjnym, artefakt modelu jest przechowywany na serwerze śledzenia MLflow dla tego obszaru roboczego.
Po zakończeniu trenowania modelu zarejestruj model w środowisku Unity Catalog. Skonfiguruj Set kod potoku, aby zarejestrować model w catalog odpowiadającym środowisku, w którym został wykonany potok modelu; w tym przykładzie dev catalog.
W przypadku zalecanej architektury wdrażasz wielozadaniowy przepływ pracy usługi Databricks, w którym pierwszym zadaniem jest potok trenowania modelu, a następnie zadania weryfikacji modelu i wdrażania modelu. Zadanie trenowania modelu zwraca identyfikator URI modelu, którego może używać zadanie weryfikacji modelu. Możesz użyć zadania values, aby przekazać ten identyfikator URI do modelu.
5. Weryfikowanie i wdrażanie modelu (programowanie)
Oprócz potoku trenowania modelu inne potoki, takie jak walidacja modelu i potoki wdrażania modelu, są opracowywane w środowisku projektowym.
Walidacja modelu. Rura walidacji modelu pobiera URI modelu z rury trenowania modelu, ładuje model z platformy Unity Catalogi uruchamia testy poprawności.
Sprawdzanie poprawności zależy od kontekstu. Mogą one obejmować podstawowe kontrole, takie jak potwierdzanie formatu i wymaganych metadanych, oraz bardziej złożone kontrole, które mogą być wymagane w przypadku wysoce regulowanych branż, takich jak wstępnie zdefiniowane kontrole zgodności i potwierdzanie wydajności modelu dla wybranych wycinków danych.
Podstawową funkcją potoku weryfikacji modelu jest określenie, czy model powinien przejść do kroku wdrażania. Jeśli model przejdzie testy przed wdrożeniem, można przypisać alias "Challenger" w środowisku Unity Catalog. Jeśli testy zakończą się niepowodzeniem, proces zakończy się. Przepływ pracy można skonfigurować tak, aby powiadamiał użytkowników o niepowodzeniu walidacji. Zobacz Dodawanie powiadomień dotyczących zadania.
Wdrażanie modelu. Proces wdrażania modelu zazwyczaj bezpośrednio promuje nowo wytrenowany model "Challenger" do statusu "Champion" przy użyciu aliasu update, lub ułatwia porównanie istniejącego modelu "Champion" a nowego modelu "Challenger". Ten potok może również set dowolną wymaganą infrastrukturę wnioskowania, taką jak punkty końcowe obsługujące model. Aby zapoznać się ze szczegółowym omówieniem kroków związanych z potokiem wdrażania modelu, zobacz Production (Produkcja).
6. Zatwierdzanie kodu
Po utworzeniu kodu na potrzeby trenowania, walidacji, wdrażania i innych potoków analityk danych lub inżynier uczenia maszynowego zatwierdza zmiany gałęzi deweloperów w kontroli źródła.
Etap przejściowy
Celem tego etapu jest przetestowanie kodu potoku uczenia maszynowego, aby upewnić się, że jest gotowy do produkcji. Cały kod potoku uczenia maszynowego jest testowany na tym etapie, w tym kod do trenowania modelu, a także potoki inżynierii cech, kod wnioskowania itd.
Inżynierowie uczenia maszynowego tworzą potok ciągłej integracji, aby zaimplementować testy jednostkowe i integracyjne uruchamiane na tym etapie. Dane wyjściowe procesu przejściowego to gałąź wydania, która wyzwala system ciągłej integracji/ciągłego wdrażania w celu rozpoczęcia etapu produkcji.
1. Dane
Środowisko przejściowe powinno mieć własne catalog w środowisku Unity Catalog do testowania potoków uczenia maszynowego i rejestrowania modeli w środowisku Unity Catalog. Ten catalog jest wyświetlany jako „etap” catalog na diagramie. Zasoby zapisane w tym catalog są zazwyczaj tymczasowe i przechowywane tylko do czasu ukończenia testowania. Środowisko programistyczne może również wymagać dostępu do przejściowego catalog na potrzeby debugowania.
2. Scal kod
Analitycy danych opracowują potok trenowania modelu w środowisku deweloperskim przy użyciu tables z catalogsprogramowania lub produkcji.
Żądanie ściągnięcia. Proces wdrażania rozpoczyna się po utworzeniu żądania ściągnięcia względem głównej gałęzi projektu w kontroli źródła.
Testy jednostkowe (CI). Żądanie ściągnięcia automatycznie kompiluje kod źródłowy i wyzwala testy jednostkowe. Jeśli testy jednostkowe nie powiedzą się, żądanie ściągnięcia zostanie odrzucone.
Testy jednostkowe są częścią procesu tworzenia oprogramowania i są stale wykonywane i dodawane do bazy kodu podczas opracowywania dowolnego kodu. Uruchamianie testów jednostkowych w ramach potoku ciągłej integracji gwarantuje, że zmiany wprowadzone w gałęzi dewelopera nie przerywają istniejących funkcji.
3. Testy integracji (CI)
Następnie proces ciągłej integracji uruchamia testy integracji. Testy integracji uruchamiają wszystkie potoki (w tym inżynierię cech, trenowanie modelu, wnioskowanie i monitorowanie), aby upewnić się, że działają prawidłowo. Środowisko przejściowe powinno być zgodne ze środowiskiem produkcyjnym tak ściśle, jak jest to uzasadnione.
Jeśli wdrażasz aplikację uczenia maszynowego z wnioskowaniem w czasie rzeczywistym, należy utworzyć i przetestować infrastrukturę obsługi w środowisku przejściowym. Obejmuje to wyzwolenie potoku wdrażania modelu, który tworzy punkt końcowy obsługujący w środowisku przejściowym i ładuje model.
Aby skrócić czas wymagany do uruchomienia testów integracji, niektóre kroki mogą odróżnić wierność testowania i szybkości lub kosztów. Jeśli na przykład modele są kosztowne lub czasochłonne do trenowania, możesz użyć małych podzbiorów danych lub uruchomić mniej iteracji trenowania. W przypadku obsługi modelu, w zależności od wymagań produkcyjnych, można przeprowadzić testowanie obciążeniowe na pełną skalę w testach integracji lub po prostu przetestować małe zadania wsadowe lub żądania do tymczasowego punktu końcowego.
4. Scalanie do gałęzi przejściowej
Jeśli wszystkie testy przejdą, nowy kod zostanie scalony z gałęzią główną projektu. Jeśli testy kończą się niepowodzeniem, system ciągłej integracji/ciągłego wdrażania powinien powiadamiać użytkowników i publikować wyniki w żądaniu ściągnięcia.
Można zaplanować okresowe testy integracji w gałęzi głównej. Jest to dobry pomysł, jeśli gałąź jest często aktualizowana z równoczesnymi żądaniami ściągnięcia od wielu użytkowników.
5. Tworzenie gałęzi wydania
Po pomyślnym zakończeniu testów CI oraz scalenia gałęzi deweloperskiej z gałęzią główną, inżynier uczenia maszynowego tworzy gałąź wydania, co uruchamia system CI/CD do update zadań produkcyjnych.
Etap produkcyjny
Inżynierowie ml posiadają środowisko produkcyjne where potoki uczenia maszynowego są wdrażane i wykonywane. Te potokowe procesy wyzwalają trenowanie modelu, walidowanie i wdrażanie nowych wersji modelu, publikowanie przewidywań do podrzędnych systemów tables lub aplikacji oraz monitorowanie całego procesu, aby uniknąć pogorszenia wydajności i niestabilności.
Analitycy danych zwykle nie mają dostępu do zapisu ani obliczeń w środowisku produkcyjnym. Jednak ważne jest, aby mieli wgląd w wyniki testów, dzienniki, artefakty modelu, stan potoku produkcyjnego i proces monitorowania tables. Ta widoczność pozwala im identyfikować i diagnozować problemy w środowisku produkcyjnym oraz porównywać wydajność nowych modeli z modelami obecnie w środowisku produkcyjnym. Możesz przyznać analitykom danych grant dostęp tylko do odczytu do zasobów w środowisku produkcyjnym catalog w tym celu.
Liczba kroków odpowiada liczbom pokazanym na diagramie.
1. Trenowanie modelu
Ten potok może być wyzwalany przez zmiany kodu lub przez automatyczne ponowne trenowanie zadań. W tym kroku tables z produkcji catalog są używane do wykonania następujących kroków.
Trenowanie i dostrajanie. Podczas procesu trenowania dzienniki są rejestrowane na serwerze śledzenia MLflow środowiska produkcyjnego. Te dzienniki obejmują metryki modelu, parameters, tagi i sam model. Jeśli używasz funkcji tables, model jest rejestrowany w usłudze MLflow przy użyciu klienta Feature Store Databricks, który pakuje model z informacjami wyszukiwania funkcji używanymi podczas wnioskowania.
Podczas opracowywania analitycy danych mogą testować wiele algorytmów i hiperparametrów. W kodzie szkoleniowym produkcyjnym często należy wziąć pod uwagę tylko opcje o najwyższej wydajności. Ograniczenie dostrajania w ten sposób pozwala zaoszczędzić czas i zmniejszyć wariancję przed dostrajaniem w zautomatyzowanym ponownym trenowaniu.
Jeśli analitycy danych mają dostęp tylko do odczytu do catalogprodukcyjnego, mogą być w stanie określić optymalną set hiperparametrów dla modelu. W takim przypadku potok trenowania modelu wdrożony w środowisku produkcyjnym można wykonać przy użyciu wybranego set hiperparametrów, zwykle zawartego w potoku jako plik konfiguracyjny.
Ocena Jakość modelu jest oceniana przez testowanie przechowywanych danych produkcyjnych. Wyniki tych testów są rejestrowane na serwerze śledzenia MLflow. W tym kroku są używane metryki oceny określone przez analityków danych na etapie programowania. Te metryki mogą obejmować kod niestandardowy.
Zarejestruj model. Po zakończeniu trenowania modelu artefakt modelu jest zapisywany jako zarejestrowana wersja modelu w określonej ścieżce modelu w środowisku produkcyjnym catalog w środowisku Unity Catalog. Zadanie trenowania modelu zwraca identyfikator URI modelu, którego może używać zadanie weryfikacji modelu. Możesz użyć zadania values, aby przekazać ten identyfikator URI do modelu.
2. Weryfikowanie modelu
Ten potok danych używa identyfikatora URI modelu z kroku 1 i ładuje model z Unity Catalog. Następnie wykonuje serię kontroli poprawności. Te testy zależą od organizacji i przypadku użycia oraz mogą zawierać takie elementy jak podstawowe weryfikacje formatu i metadanych, oceny wydajności dla wybranych wycinków danych oraz zgodność z wymaganiami organizacji, takimi jak sprawdzanie zgodności tagów lub dokumentacji.
Jeśli model pomyślnie przejdzie wszystkie testy poprawności, możesz przypisać alias "Challenger" do wersji modelu w środowisku Unity Catalog. Jeśli model nie przejdzie wszystkich testów sprawdzania poprawności, proces zakończy działanie i użytkownicy będą mogli zostać automatycznie powiadomieni. Tagi umożliwiają dodawanie atrybutów klucz-wartość w zależności od wyniku tych testów sprawdzania poprawności. Można na przykład utworzyć tag "model_validation_status" i set wartość na "OCZEKUJĄCE" podczas wykonywania testów, a następnie update go na "ZALICZONO" lub "NIEZALICZONO" po zakończeniu procesu.
Ponieważ model jest zarejestrowany w środowisku Unity Catalog, analitycy danych pracujący w środowisku deweloperskim mogą załadować tę wersję modelu z produkcyjnej catalog w celu zbadania, czy model zakończy się niepowodzeniem weryfikacji. Niezależnie od wyniku wyniki są rejestrowane w zarejestrowanym modelu w środowisku produkcyjnym catalog przy użyciu adnotacji do wersji modelu.
3. Wdrażanie modelu
Podobnie jak potok weryfikacji, potok wdrażania modelu zależy od organizacji i przypadku użycia. W tej sekcji założono, że przypisano nowo zweryfikowany model aliasu "Challenger" i że istniejący model produkcyjny został przypisany alias "Champion". Pierwszym krokiem przed wdrożeniem nowego modelu jest potwierdzenie, że działa co najmniej, jak również bieżący model produkcyjny.
Porównaj model "CHALLENGER" z modelem "CHAMPION". To porównanie można wykonać w trybie offline lub w trybie online. Porównanie w trybie offline ocenia oba modele względem danych przechowywanych set i śledzi wyniki przy użyciu serwera śledzenia MLflow. W przypadku obsługi modelu w czasie rzeczywistym warto wykonywać dłuższe porównania online, takie jak testy A/B lub stopniowe wdrażanie nowego modelu. Jeśli wersja modelu "Challenger" działa lepiej w porównaniu, zastępuje bieżący alias "Champion".
Funkcje serwowania modeli Mosaic AI i Monitorowanie Databricks Lakehouse umożliwiają automatyczne zbieranie i monitorowanie inferencji tables, które zawierają dane żądania i odpowiedzi dla punktu końcowego.
Jeśli nie ma istniejącego modelu "Champion", możesz porównać model "Challenger" z heurystyczną biznesową lub inną wartością progową jako punkt odniesienia.
Opisany tutaj proces jest w pełni zautomatyzowany. Jeśli wymagane są ręczne kroki zatwierdzania, możesz set tych, którzy korzystają z powiadomień przepływu pracy lub wywołań zwrotnych ciągłej integracji/ciągłego wdrażania z potoku wdrażania modelu.
Wdrażanie modelu. Potoki wnioskowania wsadowego lub przetwarzania strumieniowego mogą być set przygotowane do używania modelu z aliasem "Champion". W przypadku przypadków użycia w czasie rzeczywistym należy set infrastruktury w celu wdrożenia modelu jako punktu końcowego interfejsu API REST. Możesz utworzyć ten punkt końcowy i zarządzać nim przy użyciu usługi Mozaika AI Model Serving. Jeśli punkt końcowy jest już używany dla bieżącego modelu, możesz update punkt końcowy z nowym modelem. Obsługa modelu serwującego Mosaic AI wykonuje operację update bez przestoju, utrzymując działanie istniejącej konfiguracji do momentu, aż nowa będzie gotowa.
4. Obsługa modelu
Podczas konfigurowania punktu końcowego obsługi modelu należy określić nazwę modelu w Unity Catalog oraz wersję do obsługi. Jeśli wersja modelu została wytrenowana przy użyciu funkcji z tables w środowisku Unity Catalog, model przechowuje zależności dla funkcji oraz funkcjonalności. Usługa modelowa automatycznie używa tego grafu zależności do wyszukiwania funkcji z odpowiednich sklepów online w czasie wnioskowania. Takie podejście może również służyć do stosowania funkcji przetwarzania wstępnego danych lub do obliczania funkcji na żądanie podczas oceniania modelu.
Możesz utworzyć pojedynczy punkt końcowy z wieloma modelami i określić podział ruchu punktów końcowych między tymi modelami, umożliwiając przeprowadzanie porównań "Champion" online i "Challenger".
5. Wnioskowanie: wsadowe lub przesyłane strumieniowo
Potok wnioskowania odczytuje najnowsze dane z catalogprodukcyjnego , wykonuje funkcje do obliczania funkcji na żądanie, ładuje model "Champion", ocenia dane i zwraca przewidywania. Wnioskowanie wsadowe lub strumieniowe jest zazwyczaj najbardziej opłacalną opcją dla większej przepływności, większych przypadków użycia opóźnień. W przypadku scenariuszy where wymagane są przewidywania o niskim opóźnieniu, ale mogą być one obliczane w trybie offline; te wsadowe przewidywania można publikować w repozytorium par klucz-wartość online, takim jak DynamoDB lub Cosmos DB.
Zarejestrowany model w Unity Catalog jest przywoływany przez jego alias. Potok wnioskowania jest skonfigurowany do ładowania i stosowania wersji modelu "Champion". Jeśli wersja "Champion" zostanie zaktualizowana do nowej wersji modelu, potok wnioskowania automatycznie używa nowej wersji do następnego wykonania. W ten sposób krok wdrażania modelu jest oddzielony od potoków wnioskowania.
Zadania wsadowe zwykle publikują przewidywania do tables w produkcyjnej catalog, do plików płaskich lub za pośrednictwem połączenia JDBC. Prace strumieniowe zwykle publikują przewidywania do Unity Catalogtables lub do kolejek komunikatów, takich jak Apache Kafka.
6. Monitorowanie usługi Lakehouse
Monitorowanie usługi Lakehouse monitoruje właściwości statystyczne, takie jak dryf danych i wydajność modelu, dane wejściowe i przewidywania modelu. Alerty można tworzyć na podstawie tych metryk lub publikować je na pulpitach nawigacyjnych.
- Pozyskiwanie danych. Ten potok odczytuje dzienniki z wsadowego, przesyłania strumieniowego lub wnioskowania online.
- Sprawdź dokładność i dryf danych. Potok oblicza metryki dotyczące danych wejściowych, przewidywań modelu i wydajności infrastruktury. Analitycy danych określają metryki danych i modelu podczas opracowywania, a inżynierowie uczenia maszynowego określają metryki infrastruktury. Możesz również zdefiniować metryki niestandardowe za pomocą funkcji Monitorowania usługi Lakehouse.
- Publikowanie metryk i set alertów. Potok zapisuje dane w tables w produkcyjnej catalog na potrzeby analizy i raportowania. Należy skonfigurować te tables do odczytu ze środowiska deweloperskiego, aby analitycy danych mieli dostęp do analizy. Za pomocą usługi Databricks SQL można tworzyć pulpity nawigacyjne monitorowania w celu śledzenia wydajności modelu, a set zadania monitorowania lub narzędzia pulpitu nawigacyjnego w celu wystawienia powiadomienia, gdy metryka przekroczy określony próg.
- Wyzwalanie ponownego trenowania modelu. Gdy metryki monitorowania wskazują problemy z wydajnością lub zmiany danych wejściowych, analityk danych może wymagać opracowania nowej wersji modelu. Możesz set alerty SQL, aby powiadomić analityków danych, gdy tak się stanie.
7. Ponowne trenowanie
Ta architektura obsługuje automatyczne ponowne trenowanie przy użyciu tego samego potoku trenowania modelu powyżej. Usługa Databricks zaleca rozpoczęcie od zaplanowanego, okresowego ponownego trenowania i przechodzenia do wyzwalanego ponownego trenowania w razie potrzeby.
- Zaplanowane. Jeśli nowe dane są regularnie dostępne, możesz utworzyć zaplanowane zadanie uruchamiania kodu trenowania modelu na najnowszych dostępnych danych. Zobacz Automatyzowanie zadań za pomocą harmonogramów i wyzwalaczy
- Wyzwalane Jeśli potok monitorowania może identyfikować problemy z wydajnością modelu i wysyłać alerty, może również wyzwolić ponowne trenowanie. Jeśli na przykład rozkład danych przychodzących ulegnie znacznej zmianie lub jeśli wydajność modelu ulegnie pogorszeniu, automatyczne ponowne trenowanie i ponowne wdrażanie może zwiększyć wydajność modelu przy minimalnej interwencji człowieka. Można to osiągnąć za pomocą alertu SQL, aby sprawdzić, czy metryka jest nietypowa (na przykład sprawdzić dryf lub jakość modelu względem progu). Alert można skonfigurować tak, aby używał miejsca docelowego elementu webhook, co może następnie wyzwolić przepływ pracy trenowania.
Jeśli potok ponownego trenowania lub inne potoki wykazują problemy z wydajnością, analityk danych może wrócić do środowiska deweloperskiego, aby uzyskać dodatkowe eksperymenty, aby rozwiązać problemy.