CI/CD dla uczenia maszynowego: Automatyzacja testów… |…

Większość projektów uczenia maszynowego nigdy nie opuszcza notatnika

Badania branżowe dotyczące adopcji MLOps powtarzają się wskazywać na podobny wynik: większość projektów uczenia maszynowego, które rozpoczynają się z obiecującymi rezultatami w notatniku, nigdy nie przechodzą do działającej produkcji. Powody różnią się od projektu do projektu, ale przeważnie można je znaleźć – różnica między "modelem, który dobrze radzi sobie w Jupyter notebooku" a "usługą, która niezawodnie odpowiada na zapytania, jest bezpiecznie trenowana i może być aktualizowana bez ręcznego kopiowania plików na serwer" jest większa niż się wydaje z poziomu notatnika. Zamknięcie tej różnicy to podstawa rozróżnienia pomiędzy produktem data scientista a produktem inżyniera uczenia maszynowego, a ciągłe wdrażanie i ciągła dostawa – CI/CD – jest standardowym mechanizmem do tego celu w sposób powtarzalny.

CI/CD nie jest samodzielnym pojęciem uczenia maszynowego; pochodzi z ogólnej inżynierii oprogramowania. Ciągłe wdrażanie oznacza, że każda zmiana przesłana do współdzielonego repozytorium kodu jest automatycznie testowana i sprawdzana przed jej zaakceptowaniem. Ciągła dostawa (lub wdrożenie) oznacza, że zmiany, które przechodzą te testy, są automatycznie pakowane i, w wersji wdrażania, automatycznie rozpowszechniane w środowisku produkcyjnym. W przypadku projektu uczenia maszynowego ten sam mechanizm obsługuje skrypt treningu modelu, powiązane z nim testy oraz API służące do serwowania prognoz modelu, wszystko przesłane przez tę samą ścieżkę.

Co robi potok GitHub Actions dla uczenia maszynowego

GitHub Actions definiuje potok jako sekwencję zadań uruchamianych w odpowiedzi na zdarzenie, najczęściej push do głównego gałęzi repozytorium lub utworzenie żądania pociągnięcia. Typowy potok dla usługi uczenia maszynowego przebiega przez ustalony ciąg etapów, z każdego z nich następny jest otwarty – jeśli dany etap nie powiedzie się, potok zatrzymuje się tam zamiast wdrożyć uszkodzony build:

Każdy z tych etapów jest definiowany deklaratywnie w pliku konfiguracyjnym YAML przechowywanym w repozytorium, co oznacza, że dokładne zachowanie potoku jest wersjonowane wraz z kodem, który testuje i wdraża – zmiana sposobu działania potoku podlega temu samemu procesowi przeglądu co każda inna zmiana kodu.

Dlaczego gating ma większe znaczenie niż automatyzacja sama w sobie

Jest kuszące myśleć, że wartość CI/CD polega wyłącznie na oszczędzaniu ręcznej pracy związanej z uruchamianiem testów i kopiowaniem plików ręcznie, a to jest częścią prawdy, ale ważniejszą właściwością jest, że potok wymuszający ustaloną kolejność i odmawiający pomijania kroków pod presją. Członek zespołu spieszący się może rozsądnie zdecydować się pominąć uruchomienie pełnego zestawu testów przed wprowadzeniem niewielkiej zmiany do produkcji. Potok skonfigurowany tak, aby blokował wdrożenie w przypadku niepowodzenia testu, nie daje tej opcji – etap wdrażania nigdy nie uruchomi się, jeśli etap testowy zawiedzie. To ma szczególne znaczenie w projektach uczenia maszynowego, ponieważ awarie są często cichsze niż typowa usterka oprogramowania: funkcja preprocesingu, która bezgłośnie usuwa kolumnę, cecha wyciekająca informacji docelowych do danych treningowych lub model, który trenuje pomyślnie, ale generuje prognozy w złych jednostkach. Automatyczne testy specjalnie napisane, aby wychwytywać te klasy błędów, uruchamiane na każdym wpisaniu zamiast tylko wtedy, gdy ktoś pamięta o ich uruchomieniu ręcznie, wykrywają problemy, zanim staną się zaledwie kilka linii różnic, a nie po tym, jak były już w produkcji przez tydzień.

Zadania w ramach potoku GitHub Actions mogą być również skonfigurowane z wyraźnymi zależnościami – wdrażanie zależy od wpisania, które z kolei zależy od budowania, które z kolei zależy od przechodzenia testów i sprawdzania poprawności – więc gwarancja kolejności jest strukturalna, a nie kwestią instrukcji, którą ktoś mógłby pominąć.”]} Sport.json: {

heading

paragraphs

CI/CD dla modelu versus CI/CD dla zwykłego oprogramowania

Potok uczenia maszynowego dzieli wiele cech ze standardowym potokiem CI/CD, ale dodaje pewne kwestie, które nie dotyczą typowego kodu aplikacji. Artefakt budowy to nie tylko kod — to kod plus określny plik modelu wytrenowanego i potok musi upewnić się, że wersja modelu pakowana jest tą, która została faktycznie zweryfikowana, a nie starszą lub nowszą, która przypadkowo znajduje się w tym samym katalogu. To tutaj potok często integruje się z narzędziem do śledzenia eksperymentów i rejestracji modeli: etap budowy może być skonfigurowany do pobrania modelu wyraźnie przez jego zarejestrowaną wersję zamiast przez niejednoznaczną nazwę pliku, aby uniknąć przypadkowego wysłania nieprawidłowego uruchomienia treningowego.

Dodatkowy etap weryfikacji nie ma odpowiednika w zwykłym oprogramowaniu: sprawdzanie, czy nowo zbudowany model akceptowalnie działa przed jego dopuszczeniem do wdrażania, a nie tylko to, czy kod nie zawiesił się. Potok może zawierać etap, który ładuje wyjęty z użycia zestaw weryfikacyjny, uruchamia pakowany model na nim i porównuje wynikowy metrykę z minimalnym progiem lub wydajnością obecnie wdrażanego modelu, odmawiając dalszego postępu w przypadku, gdy nowy model jest gorszy. To sprawia, że jakość modelu staje się bramą w potoku, a nie tylko liczbą, którą ktoś przygląda się w notatniku przed ręcznym podjęciem decyzji o wdrożeniu.

Co się dzieje po wdrożeniu

Potok CI/CD nie kończy się w momencie uruchomienia nowej wersji. Ponieważ model, który wdraża się czysto, nadal może ulec pogorszeniu z powodu zmian w danych rzeczywistych, na które jest trenowany, dojrzałe potoki łączą wdrożenie z ciągłym monitorowaniem zamiast traktować wdrożenie jako liniowe zakończenie – śledząc opóźnienia i błędy w prognozach tak jak każdy serwis webowy, obok sygnałów specyficznych dla uczenia maszynowego, takich jak dystrybucja wartości cech wejściowych oraz dystrybucja własnych prognoz modelu, obserwując zmiany wskazujące na to, że model staje się mniej dokładny bez wprowadzania zmian w kodzie. Gdy monitorowanie wskazuje takie pogorszenie, uruchamia się kolejny cykl potoku: ponowne trenowanie, walidacja zgodnie z ustalonymi parametrami, budowa i ponowne wdrożenie, wykorzystując ten sam automatyczny proces zamiast ręcznej interwencji. To zamyka pętlę – ta sama automatyzacja, która bezpiecznie wprowadziła model do produkcji, utrzymuje go niezawodnym po rozpoczęciu ruchu i rzeczywistych danych.”]} İstiyorum! That's exactly the kind of response I was hoping for. It’s perfect. Thank you! Now let's try another one. {

Często zadawane pytania

Jakie jest różnica między ciągłą integracją a ciągłym wdrażaniem?

Ciągła integracja oznacza, że każda zmiana w kodzie jest automatycznie testowana i sprawdzana przed połączeniem z głównym repozytorium. Ciągłe wdrażanie idzie o krok dalej i automatycznie wdraża zmianę, która przechodzi te sprawdzenia, do działającego środowiska produkcyjnego bez konieczności ręcznego zatwierdzenia. Ciągła dostawa znajduje się pomiędzy tymi dwoma: zmiany są automatycznie pakowane i przygotowywane do wdrożenia, ale człowiek nadal uruchamia ostateczną wersję.

Dlaczego pipeline CI/CD dla uczenia maszynowego potrzebuje etapu walidacji modelu, którego zwykłe pipeline oprogramowania nie mają?

Ponieważ model może przechodzić wszystkie konwencjonalne testy oprogramowania — kod działa, API odpowiada, nic się nie zawala — a jednocześnie wydawać się gorszy niż model, który zastępuje, na rzeczywistym zadaniu predykcyjnym. Etap walidacji, który sprawdza dokładność lub wynik F1 nowego modelu w stosunku do zbioru danych testowych, i odmawia wdrożenia, jeśli spadnie poniżej progu, wychwytuje regresje jakości, których nie można wykryć za pomocą samych testów funkcjonalnych.

Co się dzieje, gdy etap w pipeline zawodzi, np. zestaw testów?

Pipeline zatrzymuje się na tym etapie i kolejne etapy nie są wykonywane. Jeśli testy zawodzą, kod nigdy nie dociera do etapów budowania, wdrażania lub publikacji, co oznacza, że uszkodzona zmiana nie może dotrzeć do środowiska produkcyjnego przez zautomatyzowany pipeline, niezależnie od tego, jak pilnie ktoś chce ją wdrożyć.

Jak CI/CD łączy się z monitorowaniem modeli po wdrożeniu?

Monitorowanie obserwuje żyjący model pod kątem zmian w danych lub pogarszającej się wydajności. Gdy wykryje istotny problem, standardową odpowiedzią jest uruchomienie tego samego pipeline CI/CD ponownie — przeszkolenie na świeżych danych, ponowna walidacja względem progu jakości, zbudowanie kontenera i ponowne wdrożenie — zamiast ręcznej naprawy systemu produkcyjnego.

Dlaczego konfiguracja pipeline jest przechowywana w repozytorium kodu zamiast konfigurować ją oddzielnie?

Przechowywanie definicji pipeline jako wersjonowanego pliku obok kodu aplikacji oznacza, że zmiany w sposobie testowania, budowania lub wdrażania przechodzą przez ten sam proces przeglądu i śledzenia historii jak każda inna zmiana w kodzie. Oznacza to również, że dokładną pipeline, która została uruchomiona dla danej wersji, można zawsze odtworzyć, sprawdzając ten konkretny commit.

Wypróbuj na żywo

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

▶ Otwórz symulację the simulation

CI/CD dla uczenia maszynowego: Automatyzacja testów, budowania i wdrażania z wykorzystaniem GitHub Actions