Celem tego modelu dojrzałości jest ułatwienie wyjaśnienia zasad i praktyk dotyczących operacji Edukacja maszynowych (MLOps). Model dojrzałości przedstawia ciągłe ulepszanie tworzenia i działania środowiska aplikacji uczenia maszynowego na poziomie produkcyjnym. Można go użyć jako metryki do ustanowienia progresywnych wymagań niezbędnych do mierzenia dojrzałości środowiska produkcyjnego uczenia maszynowego i skojarzonych z nim procesów.
Model zaawansowania
Model dojrzałości MLOps pomaga wyjaśnić zasady i praktyki dotyczące operacji programowania (DevOps) niezbędne do pomyślnego uruchomienia środowiska MLOps. Ma to na celu zidentyfikowanie luk w próbie zaimplementowania takiego środowiska przez istniejącą organizację. Jest to również sposób pokazania, jak zwiększyć możliwości metodyki MLOps w przyrostach, a nie przeciążyć wymaganiami w pełni dojrzałym środowisku. Użyj go jako przewodnika, aby:
Szacowanie zakresu pracy dla nowych zakontraktowania.
Ustanów realistyczne kryteria sukcesu.
Zidentyfikuj możliwą dostawę, którą przekażesz na zakończenie zakontraktowania.
Podobnie jak w przypadku większości modeli dojrzałości model dojrzałości MLOps jakościowo ocenia osoby/kulturę, procesy/struktury i obiekty/technologie. W miarę wzrostu poziomu dojrzałości prawdopodobieństwo zwiększa się, że zdarzenia lub błędy będą prowadzić do poprawy jakości procesów programistycznych i produkcyjnych.
Model dojrzałości MLOps obejmuje pięć poziomów możliwości technicznych:
| Poziom |
opis |
Najważniejsze informacje |
Technologia |
| 0 |
Brak metodyki MLOps |
- Trudno zarządzać cyklem życia pełnego modelu uczenia maszynowego
- Zespoły są różne i wydania są bolesne
- Większość systemów istnieje jako "czarne skrzynki", niewiele opinii podczas/po wdrożeniu
|
- Ręczne kompilacje i wdrożenia
- Ręczne testowanie modelu i aplikacji
- Brak scentralizowanego śledzenia wydajności modelu
- Trenowanie modelu jest ręczne
|
| 1 |
Metodyka DevOps, ale bez metodyki MLOps |
- Wersje są mniej bolesne niż brak metodyki MLOps, ale polegają na zespole danych dla każdego nowego modelu
- Nadal ograniczone opinie na temat tego, jak dobrze działa model w środowisku produkcyjnym
- Trudne do śledzenia/odtwarzania wyników
|
- Automatyczne kompilacje
- Testy automatyczne dla kodu aplikacji
|
| 2 |
Zautomatyzowane trenowanie |
- Środowisko trenowania jest w pełni zarządzane i możliwe do śledzenia
- Łatwy do odtworzenia modelu
- Wersje są ręczne, ale niskie tarcie
|
- Trenowanie modelu zautomatyzowanego
- Scentralizowane śledzenie wydajności trenowania modelu
- Zarządzanie modelem
|
| 3 |
Wdrażanie modelu zautomatyzowanego |
- Wydania są niskie tarcie i automatyczne
- Pełna możliwość śledzenia z wdrożenia z powrotem do oryginalnych danych
- Całe środowisko zarządzane: trenowanie > środowiska produkcyjnego testowego >
|
- Zintegrowane testowanie A/B wydajności modelu na potrzeby wdrożenia
- Testy automatyczne dla całego kodu
- Scentralizowane śledzenie wydajności trenowania modelu
|
| 100 |
Pełne operacje zautomatyzowane MLOps |
- Pełny system zautomatyzowany i łatwo monitorowany
- Systemy produkcyjne dostarczają informacje na temat ulepszania i, w niektórych przypadkach, automatycznego ulepszania przy użyciu nowych modeli
- Zbliżanie się do systemu bez przestojów
|
- Zautomatyzowane trenowanie i testowanie modelu
- Pełne, scentralizowane metryki z wdrożonego modelu
|
Poniższe tabele identyfikują szczegółowe cechy tego poziomu dojrzałości procesów. Model będzie nadal ewoluował. Ta wersja została ostatnio zaktualizowana w styczniu 2020 r.
Poziom 0: brak metodyki MLOps
| Osoby |
Tworzenie modelu |
Wydanie modelu |
Integracja aplikacji |
- Analitycy danych: silosowane, a nie w regularnej komunikacji z większym zespołem
- Inżynierowie danych (jeśli istnieje): silosy, a nie w regularnej komunikacji z większym zespołem
- Inżynierowie oprogramowania: silosowane, odbierają model zdalnie od innych członków zespołu
|
- Dane zebrane ręcznie
- Obliczenia prawdopodobnie nie są zarządzane
- Eksperymenty nie są przewidywalnie śledzone
- Wynik końcowy może być pojedynczym plikiem modelu ręcznie przekazanym z danymi wejściowymi/wyjściowymi
|
- Proces ręczny
- Skrypt oceniania może zostać utworzony ręcznie po eksperymentach, a nie kontrolowany w wersji
- Wydanie obsługiwane przez samego analityka danych lub inżyniera danych
|
- W dużej mierze zależy od wiedzy analityka danych w celu zaimplementowania
- Wersje ręczne za każdym razem
|
Poziom 1. Metodyka DevOps nie ma metodyki MLOps
| Osoby |
Tworzenie modelu |
Wydanie modelu |
Integracja aplikacji |
- Analitycy danych: silosowane, a nie w regularnej komunikacji z większym zespołem
- Inżynierowie danych (jeśli istnieje): silosy, a nie w regularnej komunikacji z większym zespołem
- Inżynierowie oprogramowania: silosowane, odbierają model zdalnie od innych członków zespołu
|
- Potok danych automatycznie zbiera dane
- Środowisko obliczeniowe jest zarządzane lub nie jest zarządzane
- Eksperymenty nie są przewidywalnie śledzone
- Wynik końcowy może być pojedynczym plikiem modelu ręcznie przekazanym z danymi wejściowymi/wyjściowymi
|
- Proces ręczny
- Skrypt oceniania może zostać utworzony ręcznie po eksperymentach, prawdopodobnie kontrolowana wersja
- Jest przekazywany inżynierom oprogramowania
|
- Istnieją podstawowe testy integracji dla modelu
- W dużej mierze zależy od wiedzy analityka danych w celu zaimplementowania modelu
- Wersje automatyczne
- Kod aplikacji zawiera testy jednostkowe
|
Poziom 2. Zautomatyzowane trenowanie
| Osoby |
Tworzenie modelu |
Wydanie modelu |
Integracja aplikacji |
- Analitycy danych: praca bezpośrednio z inżynierami danych w celu przekonwertowania kodu eksperymentowania na powtarzalne skrypty/zadania
- Inżynierowie danych: praca z analitykami danych
- Inżynierowie oprogramowania: silosowane, odbierają model zdalnie od innych członków zespołu
|
- Potok danych automatycznie zbiera dane
- Zarządzane zasoby obliczeniowe
- Śledzone wyniki eksperymentu
- Zarówno kod trenowania, jak i modele wynikowe są kontrolowane w wersji
|
- Wydanie ręczne
- Skrypt oceniania jest w wersji kontrolowanej za pomocą testów
- Wydanie zarządzane przez zespół inżynierów oprogramowania
|
- Istnieją podstawowe testy integracji dla modelu
- W dużej mierze zależy od wiedzy analityka danych w celu zaimplementowania modelu
- Kod aplikacji zawiera testy jednostkowe
|
Poziom 3. Automatyczne wdrażanie modelu
| Osoby |
Tworzenie modelu |
Wydanie modelu |
Integracja aplikacji |
- Analitycy danych: praca bezpośrednio z inżynierami danych w celu przekonwertowania kodu eksperymentowania na powtarzalne skrypty/zadania
- Inżynierowie danych: praca z analitykami danych i inżynierami oprogramowania w celu zarządzania danymi wejściowymi/wyjściowymi
- Inżynierowie oprogramowania: praca z inżynierami danych w celu zautomatyzowania integracji modelu z kodem aplikacji
|
- Potok danych automatycznie zbiera dane
- Zarządzane zasoby obliczeniowe
- Śledzone wyniki eksperymentu
- Zarówno kod trenowania, jak i modele wynikowe są kontrolowane w wersji
|
- Automatyczne wydawanie
- Skrypt oceniania jest w wersji kontrolowanej za pomocą testów
- Wydawanie zarządzane przez potok ciągłego dostarczania (CI/CD)
|
- Testy jednostkowe i integracyjne dla każdej wersji modelu
- Mniej zależny od wiedzy analityka danych w celu zaimplementowania modelu
- Kod aplikacji ma testy jednostkowe/integracyjne
|
Poziom 4. Pełne ponowne trenowanie zautomatyzowane metodyki MLOps
| Osoby |
Tworzenie modelu |
Wydanie modelu |
Integracja aplikacji |
- Analitycy danych: praca bezpośrednio z inżynierami danych w celu przekonwertowania kodu eksperymentowania na powtarzalne skrypty/zadania. Praca z inżynierami oprogramowania w celu identyfikowania znaczników dla inżynierów danych
- Inżynierowie danych: praca z analitykami danych i inżynierami oprogramowania w celu zarządzania danymi wejściowymi/wyjściowymi
- Inżynierowie oprogramowania: praca z inżynierami danych w celu zautomatyzowania integracji modelu z kodem aplikacji. Implementowanie zbierania metryk po wdrożeniu
|
- Potok danych automatycznie zbiera dane
- Ponowne trenowanie wyzwalane automatycznie na podstawie metryk produkcyjnych
- Zarządzane zasoby obliczeniowe
- Śledzone wyniki eksperymentu
- Zarówno kod trenowania, jak i modele wynikowe są kontrolowane w wersji
|
- Automatyczne zwalnianie
- Skrypt oceniania jest kontrolowany przy użyciu testów
- Wydanie zarządzane przez ciągłą integrację i potok ciągłej integracji/ciągłego wdrażania
|
- Testy jednostkowe i integracyjne dla każdej wersji modelu
- Mniej zależny od wiedzy analityka danych w celu zaimplementowania modelu
- Kod aplikacji ma testy jednostkowe/integracyjne
|
Następne kroki