Zyski:
- Umiejętność rozpoznawania specjalnych wyzwań związanych z uczeniem maszynowym związanych z trio i pakietem kod-dane-model oraz prezentowania modelu online lub wsadowo, zgodnie z potrzebami biznesowymi.
- Możliwość wdrożenia wzorców wdrażania stopniowego i wycofywania (w tle, kanarek, A/B, wycofywanie) i dodawania przetestowanego planu wycofywania do każdego wdrożenia
- Możliwość śledzenia powiązania dane-kod-metryka modelu wprowadzonego do produkcji za pomocą CI/CD kontrolowanego progiem oceny i rejestru modelu
Uzyskanie modelu osiągającego w notebooku dokładność na poziomie 95% to dopiero połowa sukcesu. Druga połowa – często najtrudniejsza – to udostępnienie tego modelu prawdziwym użytkownikom w sposób niezawodny, skalowalny i łatwy w utrzymaniu. MLOps (Machine Learning Operations: dyscyplina polegająca na wprowadzaniu, obsłudze i utrzymywaniu modeli ML w środowisku produkcyjnym) łączy praktyki DevOps w zakresie inżynierii oprogramowania z unikalnymi wyzwaniami ML. W tym rozdziale opisujemy etapy przeniesienia modelu do produkcji oraz to, jak sztuczna inteligencja pomaga w tym procesie.
Dlaczego ML różni się od zwykłego oprogramowania?
W zwykłym oprogramowaniu zachowanie jest zapisane w kodzie; Jeśli kod się nie zmieni, zachowanie się nie zmieni. W ML zachowanie zależy zarówno od kodu, danych, jak i modelu. Te trzy wymiary stwarzają dodatkowe wyzwania związane z MLOps:
- Dryf danych: dane w środowisku produkcyjnym z biegiem czasu oddalają się od danych w procesie uczenia; model staje się przestarzały.
- Musisz stworzyć wersję trzech rzeczy: kodu, danych i modelu — wszystkich trzech.
- Cicha awaria: model może zawieść bez awarii, bez powodowania błędów, po prostu poprzez tworzenie błędnych prognoz. Złapanie tego wymaga monitorowania.
Dlatego istnieje duża różnica pomiędzy „modelem działającym” a „modelem gotowym do produkcji”.
Modelowe pakowanie i prezentacja
Pierwszym krokiem we wprowadzeniu modelu do produkcji jest spakowanie go: pliku modelu, niezbędnych bibliotek, kodu przetwarzania wstępnego i informacji o wersji razem w odtwarzalną całość. Konteneryzacja (np. Docker: umieszczenie aplikacji w izolowanym pudełku ze wszystkimi jej zależnościami) jest tutaj standardem; Eliminuje problem „działał na moim komputerze”.
Dwa podstawowe wzorce obsługi modelu:
- Online/w czasie rzeczywistym (online): Model opiera się na interfejsie API i zwraca natychmiastową prognozę dla każdego przychodzącego żądania. Niskie opóźnienie jest krytyczne.
- Batch: Model okresowo przetwarza duże zbiory danych (np. generuje oceny dla wszystkich klientów w nocy). Opóźnienie nie ma znaczenia, ważna jest wydajność.
To, który z nich jest właściwy, zależy od potrzeb biznesowych: natychmiastowa rekomendacja online, miesięczna ocena ryzyka partiami.
Wskazówka: „W czasie rzeczywistym” to koszt, a nie wartość domyślna. Partia jest znacznie tańsza i prostsza, jeśli wynik zostanie wykorzystany w ciągu kilku godzin. Czy naprawdę potrzebujesz natychmiastowej odpowiedzi? Najpierw o to zapytaj.
Bezpieczne strategie dystrybucji
Otwarcie nowego modelu bezpośrednio na cały ruch jest ryzykowne; Jeśli coś jest nie tak, dotyczy to wszystkich. Bezpieczne wzorce dystrybucji:
- Wdrożenie w tle: nowy model odbiera ruch produkcyjny, ale jego przewidywania nie są wyświetlane użytkownikowi, a jedynie rejestrowane. Porównuje się go ze starym modelem, aby sprawdzić, czy jest bezpieczny w rzeczywistych danych.
- Wdrożenie w Canary: nowy model jest najpierw wdrażany dla niewielkiego odsetka ruchu (np. 5%); Jeśli nie ma problemu, zwiększa się go stopniowo.
- Testy A/B: Prawdziwemu użytkownikowi prezentowane są równolegle dwa modele i porównywane są wskaźniki biznesowe (konwersje, kliknięcia).
- Rollback: Możliwość szybkiego powrotu do starej wersji, jeśli nowy model okaże się zły. Każde wdrożenie powinno mieć plan wycofywania zmian.
Przestroga: wdrożenie bez planu wycofywania zmian nie jest zakończone. Możliwość powrotu do starej wersji w ciągu kilku minut chroni użytkownika, gdy nowy model zachowuje się nieoczekiwanie w produkcji. Przetestuj to przed wdrożeniem.
Słabe podejście / Silne podejście
Słabe: „Model wypadł dobrze w testach, uruchomiliśmy go, udostępniliśmy go wszystkim”.
Güçlü: „Konteneryzowaliśmy model, oznaczyliśmy go jako wersję. Najpierw uruchomiliśmy go w trybie cienia z ruchem produkcyjnym na 3 dni, porównując przewidywania ze starym modelem — odchylenie było akceptowalne. Następnie otworzyliśmy go z 5% canary, monitorowaliśmy wskaźniki przepustowości i opóźnienia. Gdy nie było żadnych problemów, stopniowo zwiększaliśmy je do 100%. Wcześniej przetestowaliśmy polecenie wycofywania.”
Różnica: zdecydowane podejście jest stopniowe, mierzone i odwracalne. Ryzyko jest ograniczone na każdym kroku.
CI/CD i automatyzacja
CI/CD (ciągła integracja/ciągłe wdrażanie: potok automatycznego testowania i publikowania zmian w kodzie) w ML obejmuje nie tylko kod, ale także etapy danych i modelu. Dobry potok ML CI/CD: uruchamia testy w przypadku zmiany kodu, sprawdza poprawność danych, ponownie szkoli model (jeśli to konieczne), sprawdza progi oceny i przyspiesza wdrażanie tylko wtedy, gdy progi zostaną utrzymane. Zasada „szkolenie jest automatyczne, wdrażanie oparte na progach” zapobiega cichemu przedostawaniu się złego modelu do produkcji.
Sztuczna inteligencja jest bardzo pomocna przy konfigurowaniu tych potoków: pisaniu wersji roboczych plików konfiguracyjnych (YAML), przypadków testowych, skryptów wdrożeniowych. Ale Ty określasz progi dystrybucji (niezależnie od tego, jaka metryka przekracza opublikowaną wartość) i zasady wycofywania; są to decyzje związane z ryzykiem biznesowym.
Infrastruktura odtwarzalności
Aby odtworzyć zachowanie modelu w środowisku produkcyjnym, należy skorzystać z rejestru modeli: rejestru przechowującego, który model został przeszkolony, przy użyciu jakich danych i kodu oraz jakie metryki otrzymał. Dla każdego modelu produkcyjnego powinno być możliwe śledzenie: wersji danych szkoleniowych, wersji kodu (git commit), hiperparametrów, wyników oceny i daty wdrożenia. Gdy pojawi się problem, powinieneś być w stanie odpowiedzieć na pytanie „który model wygenerował tę prognozę i na podstawie jakich danych?” w ciągu kilku minut. Pogłębimy to w części 11.
trzy mini etui
Przypadek 1 – Problem wykryty przez rozkład cienia. Model rekomendacyjny pobił w testach stary. Stwierdzono, że uruchomienie go z ruchem produkcyjnym w trybie cienia dało bardzo słabe rekomendacje dla określonego segmentu użytkowników (nowych użytkowników) — dane testowe były niedostatecznie reprezentatywne dla tego segmentu. Model został naprawiony i nigdy nie był wyświetlany użytkownikowi. Jeśli zostałby otwarty bezpośrednio, nowe doświadczenie użytkownika zostałoby zakłócone.
Przypadek 2 – Nieodwołalna dystrybucja. Zespół wdrożył nowy model cenowy dla całego ruchu, bez planów wycofywania zmian. Modelka niespodziewanie wyceniła niektóre produkty bardzo tanio. Powrót do starej wersji trwał godzinami, ponieważ proces nie był jeszcze gotowy. Nastąpiła poważna utrata dochodów. Następnie do każdego wdrożenia dodano obowiązkowe testy wycofywania zmian.
Przypadek 3 – Cichy dryf danych. Schemat oszustwa pojawiał się miesiącami bez żadnych błędów. Jednak taktyka oszustów uległa zmianie (dryf danych), a pamięć modelu po cichu spadła. Nikt tego nie zauważył, bo nie było monitoringu. Po utworzeniu panelu monitorującego dystrybucję prognoz dryf stał się widoczny wcześnie. Monitoringiem zajmiemy się w bloku 8.
Szablony do kopiowania
Napisz projekt planu wdrożenia dla tego modelu. Model: [co robi], użycie: [online czy wsadowo?] Powinno obejmować: 1) Pakowanie (kontener, wersjonowanie) 2) Strategię wdrażania przyrostowego (shadow/canary/A-B) i dlaczego3) Metryki do śledzenia (biznesowe + techniczne + opóźnienie) 4) Plan wycofywania zmian i sposób testowania 5) Progi wdrożenia (które metryki powinny przekraczać jaką wartość)
Sprawdź potok ML CI/CD:1) Czy sprawdzanie poprawności danych jest w toku?2) Czy wdrożenie może być kontynuowane bez utrzymywania progu oceny (czy nie powinno)?3) Czy wycofywanie zmian jest automatyczne?4) Czy dane+kod+metryki są śledzone w rejestrze modelu? Konfiguracja Pline: [config]
Pomóż mi zdecydować, czy dla tego modelu odpowiednia jest prezentacja online czy wsadowa. Jak długo będzie używany wynik: [natychmiastowa / minuta / godzina / dzień] Oczekiwana liczba żądań: [liczba] Czy istnieje ograniczenie opóźnienia: [ms] Który poleciłbyś pod względem kosztów i złożoności i dlaczego?
Napisz procedurę wycofywania dla tego modelu. - Jaki wskaźnik/próg powoduje słabą wydajność? - Jakie są etapy wycofywania? - Jak długo powinno trwać wycofywanie (docelowo)? - Jak przetestować tę procedurę przed rozpoczęciem produkcji?
Tabela wzorów prezentacji
kryterium
Online (w czasie rzeczywistym)
Partia
opóźnienie
Krytyczny (ms)
nieistotne
Użycie
Wymagana natychmiastowa reakcja
Wynik okresowy
Koszt
wysoki
niski
złożoność
wysoki
niski
przykład
Rekomendacja na żywo, oszustwo
Miesięczna ocena ryzyka
Typowe błędy
- Rozpowszechniaj bez planu odbioru. Zły model uderza w całego użytkownika.
- Otwarcie bezpośrednio na 100% ruchu. Ogranicz ryzyko dzięki rozłożonej dystrybucji.
- Nie ustanowienie monitoringu. Model generuje błędy po cichu, bez błędu.
- Redundantna prezentacja w czasie rzeczywistym. Chociaż grupowanie wsadowe jest wystarczające, koszty i złożoność rosną.
- Nie łączenie wersji kodu danych modelu. Nie można odtworzyć problemu.
- Zwolnienie automatyczne bez progu dystrybucji. Zły model wkrada się po cichu.
Podsumowując
Przeniesienie modelu do produkcji jest innym i często trudniejszym zadaniem inżynierskim niż jego szkolenie. ML wymaga dodatkowej dyscypliny, ponieważ zależy od tria kod-dane-model: pakowania i wersjonowania, wzorca dostarczania (online/wsadowo) odpowiadającego potrzebom biznesowym, stopniowego i odwracalnego wdrażania, CI/CD kontrolowanego progiem i rejestracji modelu. Sztuczna inteligencja jest potężną pomocą w generowaniu kodu i konfiguracji tej infrastruktury; ale progi dystrybucji, zasady wycofania i decyzje dotyczące ryzyka należą do Ciebie. Dystrybucja bez planu wycofywania zmian nie jest kompletna.
Zadanie aplikacji
Konteneryzuj (Docker) model i oznacz go jako wersję. Zdecyduj, czy będziesz oferować online, czy wsadowo, w zależności od potrzeb biznesowych i napisz uzasadnienie. Udokumentuj plan etapowego wdrażania (w tle lub kanarek) i sprawdzoną procedurę wycofywania. Pamiętaj, aby zapisać wersję danych, zatwierdzenie kodu i wyniki oceny w rejestrze modelu.
lista kontrolna
- [ ] Model jest spakowany i wersjonowany (pojemnik + etykieta).
- [ ] Wzór prezentacji (online/wsadowy) został wybrany w zależności od potrzeb biznesowych.
- [ ] Wdrożono strategię etapowego wdrażania (cień/kanarek).
- [ ] Napisano i przetestowano procedurę wycofywania zmian.
- [ ] CI/CD nie przyspiesza wdrożenia przed osiągnięciem progu oceny.
- [ ] Rejestr modelu przechowuje łącze dane+kod+metryka.