Projektowanie systemów uczenia maszynowego to projektowanie pełnej ścieżki od danych do decyzji. Model ma znaczenie, ale równie dużo waży system wokół niego. To właśnie ten aspekt początkowo umyka wielu osobom.
Zaczynam od prostego spojrzenia na sprawę. System uczenia maszynowego składa się z kilku elementów: pobierania danych, trenowania, ewaluacji, wdrożenia i monitorowania. Jeśli któreś z tych ogniwa jest słabe, cały system może zawieść cicho. Model może nadal generować wyjście, ale to wyjście może już nie pasować do rzeczywistości.
Dlatego projektowanie systemu to nie tylko wybór algorytmu. Chodzi o ustalenie, skąd pochodzą dane, jak są czyszczone, jak budowane są cechy, jak model jest trenowany i jak wykorzystuje się wyniki po wdrożeniu. W praktyce ciężka praca leży często w potoku danych, a nie w samym modelu. Kod może być poprawny, podczas gdy dane są błędne. Ma to miejsce częściej, niż ludzie chcą przyznać.
Pierwszą prawdziwą decyzją projektową jest sam problem. Muszę wiedzieć, co model ma przewidywać, jak często ma działać i co oznacza dobry wynik. Model wykrywania oszustw, ranker wyników wyszukiwania i tagger obrazów wymagają różnych formatów danych i innych kompromisów. Jeśli cel jest niejasny, system też będzie niejasny.
Następnie dochodzi do danych. To element, który brzmi prosto, okazuje się jednak wcale taki nie jest. Dane treningowe są użyteczne tylko wtedy, gdy odpowiadają typowi danych, jakie model napotka później. Jeśli dane w środowisku produkcyjnym ulegną zmianie, model może oddalić się od rzeczywistości. Tę zmianę często nazywa się dryfem danych. Oznacza to, że dane wejściowe w produkcji przestają przypominać te użyte do trenowania.
Traktuję dryf jako normalne ryzyko, a nie rzadką awarię. Dane się zmieniają. Użytkownicy się zmieniają. Produkty się zmieniają. Czujniki się zmieniają. System, który nigdy tego nie sprawdza, jest ślepy. Dobre projektowanie obejmuje zbiór referencyjny, zbiór bieżący i sposób ich porównywania. Jeśli dane w produkcji zaczną wyglądać inaczej, zespół musi o tym wiedzieć zanim model zrobi zbyt wiele złych prognoz.
To właśnie na etapie monitorowania systemy uczenia maszynowego stają się prawdziwymi systemami. Dbam tu o coś więcej niż tylko dokładność. Chcę obserwować opóźnienia, błędy, jakość danych wejściowych, wzorce predykcji oraz – jeśli to możliwe – jakość modelu po pojawieniu się etykiet. Niektóre awarie objawiają się szybko. Inne potrzebują czasu. Model może wyglądać świetnie pierwszego dnia, a powoli pogarszać swoje wyniki przez tygodnie.
To też moment, w którym wiele zespołów natrafia na twardy limit. W świecie rzeczywistym etykiety często spóźniają się lub wcale nie pojawiają. Trudno więc od razu stwierdzić, czy model się myli. System musi więc pilnować wskaźników zastępczych. Obserwuje dryf wejścia, dryf wyjścia, problemy ze schematem i luki w danych. To nie są idealne sygnały, ale często jedyne wczesne ostrzeżenia.
Traktuję wdrożenie jak umowę. Gdy model trafi do produkcji, przestaje być wynikiem z notatnika. Staje się częścią działającego serwisu. Oznacza to, że liczy się wersjonowanie. Liczą się wersje danych. Liczy się kod cech. Liczą się artefakty modelu. Jeśli żadnego z tych elementów nie śledzimy, debugowanie zamienia się w zgadywanie.
Śledzenie eksperymentów to też część projektowania, nawet jeśli przypomina narzędzie laboratoryjne. Pomaga odpowiedzieć na podstawowe pytanie: co się zmieniło? Bez tego trudno rozstrzygnąć, czy model stał się lepszy dzięki lepszej cechie, lepszemu podziałowi danych, czy po prostu szczęściu. Systemy uczenia maszynowego wymagają tu większej dyscypliny niż wiele tradycyjnych systemów oprogramowania, ponieważ proces trenowania nie zawsze da się powtórzyć w tak uporządkowany sposób.
Jest jeden szczery limit, którego mam ciągle na uwadze. Żadne projektowanie nie usuwa niepewności z uczenia maszynowego. Model uczy się wzorców na podstawie danych historycznych, a przyszłość nie jest zobowiązana do ich powtarzania. Nawet ostrożnie zaprojektowany system może zawieść, gdy świat się zmienia, etykiety są obarczone szumem, albo sam cel został sformułowany zbyt luźno. To nie jest błąd jednego narzędzia. To fakt charakterystyczny dla tej dziedziny.
Dlatego mówiąc o projektowaniu systemów uczenia maszynowego, mam na myśli projektowanie na pełne życie modelu. Nie tylko dzień trenowania. Nie tylko dzień premiery. Przydatny system to taki, który nadal działa, gdy dane nieco się zmienią. To jest prawdziwa praca, a zwykle mniej efektowna niż prezentacja na slajdach.
To również rodzaj pracy, którą staram się utrzymać w perspektywie w The Model Log: jedno praktyczne zagadnienie sztucznej inteligencji, jeden działający przykład i jeden szczery wgląd w to, co naprawdę działa.
