MLOps: od modelu
do systemu produkcyjnego
MLOps to praktyka niezawodnego wdrażania modeli uczenia maszynowego do eksploatacji i utrzymywania ich tam. Faza 06 procesu data science: wdrożenie, monitoring, ponowny trening.
Od prototypu do produkcji
Wdrożenie jest procesem ciągłym. Zapewniamy niezawodne, łatwe w utrzymaniu działanie.
Infrastruktura
Wdrożenie produkcyjne, skalowalne i wysoce dostępne.
Monitoring
Ciągłe monitorowanie z automatycznymi alertami.
Ciągłe doskonalenie
Procesy aktualizacji modelu wraz ze zmieniającymi się wymaganiami.
Dashboard monitoringu produkcji
MLOps: definicja, różnica wobec DevOps i trzy poziomy dojrzałości
MLOps (machine learning operations) to praktyka przekształcania wytrenowanego modelu w system, który na co dzień wspiera decyzje: wersjonowany, automatycznie testowany, zintegrowany z aplikacją biznesową, stale monitorowany i w razie potrzeby ponownie trenowany. MLOps przenosi praktyki dostarczania oprogramowania (DevOps) na modele, których zachowanie zależy nie tylko od kodu, lecz od danych.
Model tworzy wartość dopiero wtedy, gdy aktywnie wspiera decyzje na produkcji. W odróżnieniu od aplikacji model zachowuje się jutro inaczej, gdy tylko zmienią się dane, które widzi: nowi klienci albo wymieniona maszyna. Dlatego odpowiedzialność za model zaczyna się w dniu uruchomienia, zamiast tam się kończyć.
MLOps i DevOps w porównaniu
| Pytanie | DevOps (oprogramowanie) | MLOps (modele) |
|---|---|---|
| Co jest wersjonowane | kod | kod, dane i stan modelu |
| Co jest testowane | działanie kodu | działanie kodu, poprawność danych wejściowych i jakość modelu |
| Co dzieje się po dostarczeniu | eksploatacja i usuwanie błędów | eksploatacja, nadzór nad dryfem i uregulowany ponowny trening |
| Kiedy wydanie jest gotowe | gdy testy przechodzą | gdy testy przechodzą i nowy model pokonuje dotychczasowy stan |
Trzy poziomy dojrzałości, w języku średnich firm
Ręczny
Data scientist trenuje model na swoim komputerze, przekazuje plik, ktoś go wbudowuje. Każdy ponowny trening to praca ręczna. Czy dzisiejszy stan odpowiada temu sprzed trzech miesięcy, nikt nie wie na pewno.
Częściowo zautomatyzowany
Trening, test i udostępnienie działają jako powtarzalna ścieżka, którą uruchamia człowiek. Każdy stan modelu jest wersjonowany i odtwarzalny, monitoring zgłasza nieprawidłowości, ponowny trening pozostaje świadomą decyzją.
W pełni zautomatyzowany
System sam trenuje, sprawdza i wymienia modele, gdy tylko ustalone progi zostaną przekroczone. Sensowne przy wielu modelach i szybko zmieniających się danych; wymaga pokrycia testami i zespołu operacyjnego, które trzeba najpierw zbudować.
Wdrożenie ML: sześć kroków od push kodu do produkcji
Wdrożenie ML, czyli uruchomienie modelu, przebiega u nas według ścieżki z diagramu wyżej na tej stronie, a specjaliści nazywają ją potokiem MLOps. Dla Państwa liczy się to, że każdy krok jest możliwy do prześledzenia i powtarzalny.
- Push kodu: Zmiana w kodzie, konfiguracji albo danych treningowych trafia do repozytorium i uruchamia ścieżkę. Nic nie dociera na produkcję z pominięciem tego wejścia, także żadna szybka poprawka w piątkowe popołudnie.
- Testy i walidacja: Automatyczne testy sprawdzają kod, kontrole danych sprawdzają dane wejściowe, a nowo wytrenowany model staje do porównania z aktualnym stanem produkcyjnym. Jeśli przegra, ścieżka kończy się tutaj.
- Budowa kontenera: Model, środowisko uruchomieniowe i zależności są pakowane w kontener, który działa tak samo na każdym serwerze. Zdanie „u mnie działało” traci podstawę.
- Staging: Kontener działa w kopii środowiska produkcyjnego z prawdziwymi interfejsami i formatami danych. Tu ujawniają się błędy, których nie widzi żaden automatyczny test: zła strefa czasowa, przemianowane pole, kolumna z ERP, która nagle jest pusta.
- Canary: Mała część ruchu albo pojedyncza lokalizacja dostaje nowy model, reszta zostaje przy starym. Jeśli wyniki odbiegają, rollback cofa zmianę, zanim bieżąca działalność coś zauważy.
- Produkcja: Model przejmuje pełną eksploatację, wersjonowany i z udokumentowanym stanem; od teraz przejmuje monitoring, a każda kolejna zmiana znów przechodzi przez krok 1.
Cztery formy udostępnienia, po jednym przypadku użycia
Batch scoring
Model liczy raz na noc dla wszystkich rekordów, na przykład prognozę zapotrzebowania dla każdego artykułu. Zwykle najtańsza forma, bo żadna usługa nie musi działać przez całą dobę.
Interfejs (API)
Usługa odpowiada na żądanie. W module predictive maintenance wskazówka, która instalacja może ulec awarii za ile dni i jakie okno konserwacyjne jest zalecane, trafia automatycznie do systemu utrzymania ruchu; dane z czujników pochodzą wyłącznie w trybie odczytu z systemu sterowania.
Wbudowany w system dziedzinowy
Rekomendacja pojawia się tam, gdzie zapada decyzja: w ERP albo na tablicy planowania. W module modowym do sterowania przecenami model dostarcza najpierw propozycje, które sprawdza category management; dopiero po jednym lub dwóch zwalidowanych sezonach rośnie stopień automatyzacji.
W przeglądarce lub na urządzeniu
Małe modele działają bezpośrednio u użytkownika, a dane nie opuszczają urządzenia. Nasz eksperyment z modelem perkusyjnym pokazuje tę formę: 397,4 kilobajta wag modelu, predykcja działa w całości w przeglądarce, bez wysyłania.
Monitoring modeli: data drift, concept drift i droga do ponownego treningu
Model rzadko zawodzi z komunikatem o błędzie. Po cichu robi się gorszy. Monitoring modeli mierzy, jak szybko spada jakość, zanim strata dotrze do decyzji.
Dwa rodzaje dryfu
Data drift oznacza: dane wejściowe wyglądają inaczej niż w treningu. Po wymianie maszyny nowy czujnik dostarcza inne wartości wibracji, chociaż instalacja jest sprawna. Model nigdy nie widział takich wartości i zgłasza ryzyko, którego nie ma.
Concept drift oznacza: dane wyglądają tak samo, ale zależność za nimi się zmieniła. Przy zmianie sezonu w modzie te same jeansy reagują na ten sam rabat inaczej niż jeszcze wiosną; model cenowy, który nauczył się zależności z poprzedniego sezonu, rekomenduje za wcześnie albo za dużo.
Model drift to zbiorcze pojęcie dla skutku obu rodzajów: jakość predykcji spada. Przyczyna rozstrzyga o odpowiedzi: przy data drift często wystarcza korekta ścieżki danych, przy concept drift pomaga tylko nowy trening na aktualnych danych.
Jakie sygnały są monitorowane
- Rozkład danych wejściowych dla każdej cechy, porównany ze stanem treningowym.
- Rozkład predykcji: jeśli model nagle zgłasza dziesięć razy więcej instalacji jako krytyczne niż w poprzednim tygodniu, zwykle coś jest nie tak z danymi.
- Wskaźniki techniczne: czas odpowiedzi, przepustowość, odsetek błędów, dostępność.
- Jakość predykcji, gdy tylko dostępne są wartości rzeczywiste: dopiero gdy instalacja uległa awarii albo właśnie nie, widać, czy ostrzeżenie było trafne. To porównanie z wartościami rzeczywistymi jest najważniejszym wskaźnikiem i najwolniejszym.
Dashboard na diagramie pokazuje budowę: czas odpowiedzi średnio 42 milisekundy, 12 400 predykcji, dostępność 99,97 procent, ostatni ponowny trening trzy dni temu. Te wartości są ilustracją, a nie obietnicą dla Państwa systemu. To, które wartości się liczą, ustala Państwa porozumienie operacyjne.
Kiedy trenuje się ponownie i ile to kosztuje
Ponowny trening jest uruchamiany, gdy zostaje przekroczony wcześniej ustalony próg: rozkład cechy wędruje poza ustaloną miarę albo zmierzona jakość spada poniżej granicy, którą model zaliczył w walidacji. Próg jest ustalony przed eksploatacją, nie po. Tak ponowny trening pozostaje sprawdzoną decyzją zamiast reakcją na ostatni zły miesiąc.
Czas obliczeń rzadko jest przy tym pozycją kosztową; model perkusyjny z naszego eksperymentu trenował 70 przebiegów (epok) w 12,3 sekundy na CPU. Drogie są kroki wokół treningu: zebranie wartości rzeczywistych, sprawdzenie nowego modelu względem starego, zatwierdzenie i udokumentowanie zmiany. Kto budżetuje ponowny trening, budżetuje ludzi i czas oczekiwania, nie rdzenie obliczeniowe.
MLOps w średnich firmach: chmura, on-premises czy jedno i drugie
Pytanie o miejsce eksploatacji rozstrzygają trzy kryteria, w tej kolejności. Czy dane mogą opuścić firmę: ochrona danych i umowy z klientami? Jak wygląda profil obciążenia: nocny przebieg, godziny pracy biura czy całą dobę? I jaki zespół operacyjny już istnieje?
Dla trzeciego pytania policzyliśmy, i to na najdroższym przypadku, eksploatacji modeli językowych na GPU. W naszej analizie kosztów ze 110 datowanych, publicznych źródeł cen serwer startowy we własnej firmie kosztuje 829 euro amortyzacji miesięcznie, udział personelu w eksploatacji 3 924 euro, prąd 121 euro. Człowiek kosztuje ponad czterokrotność maszyny. Model o wielkości kilkuset kilobajtów nie jest problemem infrastrukturalnym, jak pokazuje eksperyment; zadania ludzi pozostają te same: nadzorować, ponownie trenować, zatwierdzać.
W naszym rachunku wynajęta chmura UE była w każdym scenariuszu bazowym tańsza niż własny sprzęt. On-premises jest mimo to właściwym wyborem, gdy schodzą się cztery warunki: przetwarzanie musi fizycznie pozostać w firmie, obciążenie jest wysokie i stałe, zespół operacyjny już istnieje, a jakość swobodnie dostępnych modeli wystarcza dla przypadku użycia. Nawet w tym najlepszym dla własnego sprzętu przypadku pozostała różnica około 4 700 euro miesięcznie wobec GPU w chmurze UE. Ta różnica jest ceną za to, że sprzęt stoi we własnym budynku: opłacone wymaganie, nie program oszczędnościowy.
Trzecia odpowiedź łączy obie: trening tam, gdzie leżą dane, a gotowy model jako kontener tam, gdzie jest potrzebny; kontener z kroku 3 umożliwia tę zmianę miejsca bez dotykania modelu.
O narzędziach tylko tyle: dla poziomów dojrzałości 1 i 2 wystarczają otwarte narzędzia do wersjonowania, śledzenia eksperymentów, kontenerów i dostarczania; platforma MLOps z licencją staje się tematem dopiero wtedy, gdy wiele modeli i kilka zespołów dzieli tę samą ścieżkę.
Pełny rachunek z krzywymi progu rentowności i wrażliwością: Suwerenna AI, uczciwie policzona: ile naprawdę kosztuje on-premises.Przekazanie operacji: kto opiekuje się modelem po projekcie
Model, którym nikt się nie opiekuje, jest po roku ryzykiem z dashboardem. Dlatego przekazanie jest u nas osobnym krokiem projektu z trzema rezultatami.
Dokumentacja
Co model robi, jakich danych potrzebuje, jakie wskaźniki zaliczył, jakie założenia obowiązują. Odtwarzalna aż do stanu danych, stanu kodu i ziarna generatora liczb losowych.
Runbook
Co robi Państwa zespół, gdy przychodzi ostrzeżenie: kroki sprawdzania, osoby kontaktowe, rollback, decyzja o ponownym treningu. Runbook to instrukcja postępowania na wypadek awarii, nie podręcznik.
Szkolenie
Ludzie, którzy jutro będą pracować z predykcjami, rozumieją, co model potrafi i gdzie milczy. Ostrzeżenie, którego nikt nie umie umiejscowić, jest ignorowane.
Celem przekazania jest to, by model wraz z dokumentacją i runbookiem przejął własny zespół Państwa firmy.
Co obejmują wdrożenie, monitoring i eksploatacja jako usługa, opisuje strona doradztwo MLOps: wdrożenie, monitoring i eksploatacja jako usługa.Nasze podejście
Uruchomienie produkcyjne
Przygotowanie do użycia produkcyjnego z interfejsami i kontrolami jakości.
Automatyczne wydanie
Możliwy do prześledzenia proces wdrożenia z testami i opcjami wycofania.
Monitoring & alerting
Wczesne wykrywanie zmian w wydajności modelu i jakości danych.
Przekazanie operacji
Transfer wiedzy, dokumentacja i ustanowienie procesów dla Państwa zespołu.
Typowe rezultaty
Najczęstsze pytania o MLOps
Czym jest MLOps?
MLOps to skrót od machine learning operations: praktyki niezawodnego wdrażania wytrenowanego modelu do eksploatacji i utrzymywania go tam. Należą do niej wersjonowanie kodu, danych i modelu, automatyczne testy, udostępnienie jako usługa albo przebieg wsadowy, monitoring dryfu i uregulowany ponowny trening. Bez MLOps model pozostaje prototypem z datą ważności.
Czym różni się MLOps od DevOps?
DevOps dostarcza oprogramowanie, którego zachowanie zależy wyłącznie od kodu. MLOps dostarcza modele, których zachowanie zależy dodatkowo od danych. Dlatego MLOps wersjonuje także dane i stany modeli, testuje obok kodu poprawność danych wejściowych i nadzoruje po dostarczeniu, czy zmieniły się dane albo wyuczona zależność.
Co oznacza wdrożenie ML?
Wdrożenie ML (machine learning deployment) to uruchomienie modelu: sprawdzony stan modelu jest pakowany w kontener, testowany w środowisku testowym z prawdziwymi interfejsami, najpierw przydzielany części eksploatacji, a potem w pełni udostępniany. Formy udostępnienia to nocny przebieg wsadowy, interfejs, wbudowanie w system dziedzinowy albo działanie bezpośrednio w przeglądarce.
Czym jest model drift i jak go rozpoznać?
Model drift oznacza, że jakość predykcji modelu spada w eksploatacji. Przyczyną jest data drift (dane wejściowe się zmieniają, na przykład po wymianie maszyny) albo concept drift (zmienia się zależność, na przykład przy zmianie sezonu). Dryf rozpoznaje się przez porównanie rozkładów danych ze stanem treningowym oraz, gdy tylko dostępne są wartości rzeczywiste, przez zmierzoną jakość.
Jak często trzeba ponownie trenować model uczenia maszynowego?
Tak często, jak wymagają tego dane, a nie według kalendarza. Ponownie trenuje się, gdy zostaje przekroczony wcześniej ustalony próg: rozkład danych wędruje albo zmierzona jakość spada poniżej granicy z walidacji. Model przecen da się ocenić dopiero po końcu sezonu; moduł liczy się z jednym do dwóch sezonów. Drogie są sprawdzenie i zatwierdzenie, nie czas obliczeń.
Czy potrzebujemy platformy MLOps, czy wystarczą narzędzia open source?
Dla poziomów dojrzałości 1 i 2 wystarczają otwarte narzędzia: wersjonowanie, śledzenie eksperymentów, kontenery i ścieżka dostarczania, jakie Państwa IT zna z oprogramowania. Licencjonowana platforma MLOps opłaca się, gdy wiele modeli i kilka zespołów dzieli tę samą ścieżkę. Decydujące jest dopasowanie do istniejącego IT Państwa firmy, a nie długość listy funkcji.
Czy model AI można eksploatować on-premises?
Tak. Model, ponowny trening i monitoring da się w całości eksploatować we własnym centrum danych. Tańsza była w naszej analizie kosztów w każdym scenariuszu bazowym wynajęta chmura UE; własna eksploatacja to opłacone wymaganie. Ma sens, gdy dane nie mogą opuszczać firmy, obciążenie jest wysokie i stałe, a zespół operacyjny istnieje. Największą pozycją jest personel, nie prąd.
Dowody na temat wdrożenia, monitoringu i kosztów
Suwerenna AI, uczciwie policzona: ile naprawdę kosztuje on-premises Predictive maintenance w eksploatacji Moduł optymalizacji przecen dla mody Eksperyment: aplikacja webowa z modelem w przeglądarcePorozmawiajmy o Państwa projekcie
Każdy projekt jest wyjątkowy. Prosimy opowiedzieć o Państwa wyzwaniu.
Zarezerwuj bezpłatną rozmowę wstępną