Wdrażanie modeli Machine Learning w środowisku produkcyjnym to duże wyzwanie, wymagające często niemniejszych wysiłków niż samo wytrenowanie modelu.
W tym wpisie omówię jeden z kilku kluczowych aspektów, o który trzeba zadbać, a którym jest logowanie wszystich koniecznych informacji po wdrożeniu modelu.
Kiedy jesteśmy na etapie eksperymentów laboratoryjnych (tzw. offline), zwykle nie zastanawiamy się nad tym, by odkładać na dysku różne wyliczenia i dane. Wszak mamy nasz zbiór danych, z których korzystamy, a końcowe metryki pozwalają nam wybrać odpowiedni model. W razie potrzeby jesteśmy w stanie odtworzyć eksperyment i doliczyć coś, jeśli o tym zapomnieliśmy.
Sytuacja jest diametralnie różna, gdy model działa online, tzn. gdy dane spływają na bieżąco, model wylicza swoje predycje (a być może jest dotrenowywany co pewien czas) i na ich podstawie wykonywane są pewne akcje. Jeśli przegapimy przechwycenie jakiejś informacji, to nie tylko utrudnimy sobie analizy wyników, ale w krytycznych sytuacjach nie będziemy w stanie dowiedzieć się, co się dzieje, a także nie będziemy mogli odtworzyć eksperymentu i wyciągnąć wniosków.
Spójrzmy, jak typowo wygląda przebieg informacji w modelu ML:
W na etapie eksperymentów offline zwykle mamy odłożone na dysku to, co zaznaczyłem na zielono (czasem ze względu np. na długi czas obliczeń odkładamy więcej informacji, ale nie jest to standardem).
Może zastanawiasz się, które elementy powinniśmy zapisywać po wdrożeniu modelu?
Jedyna sensowna odpowiedź to… wszystkie!
Dlaczego? Ponieważ każda strzałka na rysunku zakłada wykonanie jakichś operacji, obliczeń. Jeśli teraz to, co obserwujesz, czyli metryki modelu lub akcje, jakie model wykonał, są błędne, to przyczyna może tkwić w każdym z poprzednich etapów. Może model otrzymał słabej jakości dane? Może model miał wiele etapów i zawódł jeden z nich? Poniżej omówię po kolei każdy krok.
- Surowe dane – czyli to, co zbieramy z różnych źródeł i co służy do budowy modelu.
Musimy gromadzić te oryginalne informacje zanim wykonamy na nich jakiekolwiek działania. Często już na tym etapie dane są jakoś skrzywione, brakujące, czy zaszumione i to tutaj leży przyczyna pogarszającego się działania modelu.
- Dane przetworzone
Czyli to, co jest efektem np. usuwania duplikatów, poprawiania danych błędnych czy brakujących (tzw. preprocessing).
- Cechy dla modelu
Na podstawie danych często wyliczamy dla modelu dodatkowe reprezentacje, takie jak one-hot encoding, zanurzenia (embeddingi), czy jakieś relacje lub agregaty. Musimy wiedzieć, co dokładnie było wejściem modelu, aby być w stanie powiedzieć, dlaczego model zwrócił takie, a nie inne predykcje.
- Model ML
Pamiętaj, że Twój model może dynamicznie się zmieniać – może cyklicznie do dotrenowujesz, może wgrywasz coraz nowe, lepsze wersje. Musisz zawsze mieć informację, która wersja modelu była użyta w konkretnym przypadku.
- Stany pośrednie modelu.
Wyobraź sobie, że Twój model to ensemblacja sieci neuronowej, lasu losowego i regresji logistycznej. Ostateczny wynik to średnia arytmetyczna tych trzech predykcji. Jeśli ten łączny model będzie słabo działał – będziesz potrzebować ustalić, czy słabo działa jeden z kompontentów, czy kilka z nich. Podobnie jest, jeśli model ma skomplikowaną, wieloetapową architekturę. Im więcej stanów pośrednich będzie zapisywane, tym łatwiej będzie ustalić potencjalne problemy.
- Predykcje modelu
Często jest tak, że model przewiduje wiele rzeczy, a do ostatecznej decyzji trafia tylko część informacji. Tak jest na przykład często w modelach do klasyfikacji, które zwracają prawdopodobieństwo każdej klasy. Ale ostateczna decyzja to najpopularniejsza klasa. W tej sytuacji potrzebujesz zapisywać prawdopodobieństwa każdej z klas, a nie tylko ostateczny wynik, żeby zobaczyć w szczegółach, jak model działał. Podobnie jest w systemach rekomendacyjnych, które mimo że zwracają tylko część najlepiej dopasowanych produktów, czy treści, oceniają więcej z nich. Warto wówczas trzymać wszystkie oceny.
- Metryki
Dzięki nim możesz na bieżąco monitorować działanie modelu i reagować, gdy się pogorszy.
- Akcje
Wyniki modelu działającego online zazwyczaj prowadzą do konkretnych akcji, jak np. wyświetlenie odpowiedniej informacji, zapisanie czegoś, czy rekomendacja. Potrzebujesz wiedzieć, czy to, co zwrócił model, zostało prawidłowo zinterpretowane i czy ta akcja faktycznie została wykonana.
Czy zapisywanie tych wszystkich informacji to już wszystko? Niestety nie. Aby mieć pełen obraz działania modelu potrzebujesz jeszcze zapisywać dwie kategorie zdarzeń.
- Informacje systemowe
Tutaj logujemy takie informacje jak status odpowiedzi modelu, zwrócone ostrzeżenia czy błędy, a także czas działania, wykorzystana pamięć czy obciążenie infrastruktury obliczeniowej (np. pamięć GPU).
- “Meta”-informacje
Warto mieć dodatkowy dokument, gdzie będziesz zapisywać np. planowany zakres eksperymentu, czy założenia. A także wszelkie dodatkowe zdarzenia, które mogą wpłynąć na interpretację wyników (np. wyjątkowe dni, zdarzenia w gospodarce, czy w społeczeństwie, zjawiska klimatyczne itp.).
Do gromadzenia wymienionych przeze mnie informacji zwykle będziemy potrzebować trzech miejsc: bazy danych, plików na logi systemowe (te dwa miejsca powinny być uzupełniane automatycznie) oraz jednego dokumentu do ręcznego wpisywania meta-informacji.
Może się zdarzyć, że szczegółowe gromadzenie wszystkich informacji nie będzie możliwe dla naszych zasobów (np. ze względu na limity miejsca). Wówczas trzeba próbować rozwiązań, np. w postaci automatycznego usuwania starszych informacji lub agregowania ich po pewnym czasie. W ostateczności możemy nie logować jakiegoś etapu, jednak zawsze rezygnacja z tego musi być całkowicie świadoma.
W zależności teraz, w jaki sposób wygląda nasze wdrożenie, to implementacja logowania będzie zupełnie różna. Przykładowy stos technologiczny, gdy robimy wdrożenie całkowicie ręcznie (bez pośrednictwa np. systemów do serwowania predykcji takich jak Nvidia Triton), może to być SQLite do budowy bazy danych, moduł logging do danych systemowych i Google Docs do wpisywania meta-informacji.
Mam nadzieję, że ten wpis zachęcił Cię do świadomego podchodzenia do logowania danych na produkcji. Pamiętaj, że bez tego będzie Ci trudno ulepszać Twój model, odtwarzać eksperymenty czy reagować na problemy.
