W produkcyjnym systemie ML celem nie jest stworzenie i wdrożenie jednego modelu. Celem jest tworzenie automatycznych potoków do programowania, testowania i wdrażania modeli na przestrzeni czasu. Dlaczego? Wraz ze zmianami na świecie trendy w danych się przesuwają, przez co modele w środowisku produkcyjnym stają się nieaktualne. Modele zwykle wymagają ponownego trenowania przy użyciu aktualnych danych, aby w dłuższej perspektywie nadal obsługiwać wysokiej jakości prognozy. Innymi słowy, będziesz potrzebować sposobu zastępowania nieaktualnych modeli nowymi.
Bez potoków zastępowanie nieaktualnych modeli jest procesem podatnym na błędy. Na przykład, gdy model zacznie obsługiwać błędne prognozy, ktoś musi ręcznie zebrać i przetworzyć nowe dane, wytrenować nowy model, sprawdzić jego jakość, a potem go wdrożyć. Potoki systemów uczących się automatyzują wiele z tych powtarzających się procesów, dzięki czemu zarządzanie modelami oraz ich utrzymywanie są skuteczniejsze i bardziej niezawodne.
Tworzenie potoków
Potoki ML porządkują kroki tworzenia i wdrażania modeli w ramach dobrze zdefiniowanych zadań. Potoki mają jedną z 2 funkcji: dostarczanie prognoz lub aktualizowanie modelu.
Dostarczanie prognoz
Potok udostępniania generuje prognozy. Ujawnia on model w świecie rzeczywistym, dzięki czemu jest dostępny dla użytkowników. Jeśli na przykład użytkownik potrzebuje prognozy – jaka będzie jutro pogoda, ile minut zajmie podróż na lotnisko lub lista polecanych filmów – potok udostępniania odbiera i przetwarza dane użytkownika, tworzy prognozę, a następnie dostarcza je użytkownikowi.
Aktualizowanie modelu
Modele zwykle stają się przestarzałe niemal natychmiast po tym, jak trafią do produkcji. Zasadniczo szacują one na podstawie starych informacji. W zbiorach danych treningowych udokumentowaliśmy stan świata sprzed dnia, a w niektórych przypadkach nawet godzinę temu. Świat nie da się uniknąć: użytkownik obejrzał więcej filmów i potrzebuje nowej listy rekomendacji; upływ deszczu spowalniał ruch i wymagał aktualizacji szacunków dotyczących czasu dotarcia na miejsce; popularny trend sprawia, że sprzedawcy proszą o zaktualizowanie prognoz asortymentu dla określonych produktów.
Zwykle zespoły trenują nowe modele na długo, zanim model produkcyjny stanie się nieaktualny. W niektórych przypadkach zespoły codziennie trenują i wdrażają nowe modele w cyklu ciągłego trenowania i wdrażania. Trenowanie nowego modelu powinno nastąpić na długo, zanim model produkcyjny stanie się nieaktualny.
Te potoki współpracują ze sobą przy trenowaniu nowego modelu:
- Potok danych. Potok danych przetwarza dane użytkownika, aby tworzyć zbiory danych do trenowania i testowania.
- Potok trenowania. Potok trenowania trenuje modele przy użyciu nowych zbiorów danych do trenowania z potoku danych.
- Potok weryfikacji. Potok weryfikacji weryfikuje wytrenowany model, porównując go z modelem produkcyjnym przy użyciu testowych zbiorów danych wygenerowanych przez potok danych.
Rysunek 4 przedstawia dane wejściowe i wyjściowe każdego potoku ML.
Potoki ML
Rysunek 4. Potoki systemów uczących się automatyzują wiele procesów tworzenia i utrzymywania modeli. Każdy potok pokazuje dane wejściowe i wyjściowe.
Ogólnie oto jak potoki zachowują nowy model w środowisku produkcyjnym:
Najpierw model przechodzi do produkcji, a potok udostępniania rozpoczyna dostarczanie prognoz.
Potok danych od razu zaczyna gromadzić dane potrzebne do generowania nowych zbiorów danych do trenowania i testowania.
Potoki trenowania i walidacji trenują i weryfikujeją nowy model na podstawie harmonogramu lub aktywatora przy użyciu zbiorów danych wygenerowanych przez potok danych.
Gdy potok weryfikacji potwierdzi, że nowy model nie jest gorszy niż model produkcyjny, zostanie wdrożony nowy model.
Ten proces powtarza się w sposób ciągły.
Nieaktualność modelu i częstotliwość trenowania modelu
Prawie wszystkie modele stają się nieaktualne. Niektóre modele stają się nieaktualne niż inne. Na przykład modele, które polecają ubrania, zwykle szybko stają się nieaktualne, ponieważ preferencje konsumentów często się zmieniają. Z drugiej strony modele, które rozpoznają kwiaty, nigdy nie stają się nieaktualne. Cechy identyfikujące kwiat są takie same.
Większość modeli zaczyna zepsuć się natychmiast po wprowadzeniu do środowiska produkcyjnego. Musisz ustalić częstotliwość trenowania, która odzwierciedla charakter danych. Jeśli dane są dynamiczne, należy często trenować. Jeśli jest mniej dynamiczne, nie musisz tak często trenować.
Trenuj modele, zanim staną się nieaktualne. Wczesne trenowanie zapewnia bufor do rozwiązywania potencjalnych problemów, na przykład jeśli wystąpi błąd danych lub potoku trenowania albo niska jakość modelu.
Zalecaną sprawdzoną metodą jest codzienne trenowanie i wdrażanie nowych modeli. Potoki systemów uczących się do trenowania i walidacji często sprawdzają się najlepiej, gdy uruchamiają się codziennie.
Potok obsługi
Potok obsługi generuje i dostarcza prognozy na jeden z 2 sposobów: w trybie online lub offline.
Przewidywanie online. Prognozy online odbywają się w czasie rzeczywistym, zazwyczaj przez wysłanie żądania do serwera online i zwrócenie prognozy. Jeśli na przykład użytkownik potrzebuje prognozy, jego dane są wysyłane do modelu, a model zwraca prognozę. Na przykład Gmail klasyfikuje wiadomości przychodzące w czasie rzeczywistym, korzystając z prognoz online.
Prognozy offline. Prognozy offline są wstępnie obliczone i zapisywane w pamięci podręcznej. Aby udostępnić prognozę, aplikacja znajduje w bazie danych zapisaną w pamięci podręcznej i zwraca ją. Na przykład usługa oparta na subskrypcji może przewidywać współczynnik rezygnacji subskrybentów. Model przewiduje prawdopodobieństwo rezygnacji dla każdego subskrybenta i zapisuje to w pamięci podręcznej. Gdy aplikacja potrzebuje prognozy, aby np. zmotywować użytkowników, którzy mogą zrezygnować z aplikacji, sprawdza ona wstępnie obliczoną prognozę.
Rysunek 5 pokazuje generowanie i realizowanie prognoz online i offline.
Podpowiedzi online i offline
Rysunek 5. Prognozy online dostarczają prognoz w czasie rzeczywistym. Prognozy offline są przechowywane w pamięci podręcznej i sprawdzane podczas wyświetlania.
Przetwarzanie końcowe prognozy
Przewidywania są zwykle przetwarzane przed dostarczeniem. Prognozy mogą być na przykład przetwarzane w celu usunięcia toksycznych lub stronniczych treści. W wynikach klasyfikacji możemy zmieniać kolejność wyników zamiast wyświetlać nieprzetworzone dane wyjściowe modelu, np. aby zwiększyć wiarygodność treści, prezentować różnorodność wyników, degradować konkretne wyniki (np. clickbait) lub usuwać je z przyczyn prawnych.
Rysunek 6 przedstawia potok obsługi i typowe zadania związane z dostarczaniem prognoz.
Prognozy dotyczące przetwarzania
Rysunek 6. Działający potok obsługi ilustrujący typowe zadania związane z dostarczaniem prognoz.
Pamiętaj, że etap inżynierii funkcji odbywa się zwykle w ramach modelu, a nie jako oddzielny, samodzielny proces. Kod przetwarzania danych w potoku obsługi często jest prawie taki sam jak kod przetwarzania danych, którego potok używa do tworzenia zbiorów danych do trenowania i testowania.
Przechowywanie zasobów i metadanych
Potok udostępniania powinien obejmować repozytorium do logowania prognoz modeli oraz, jeśli to możliwe, danych podstawowych (ground truth).
Logowanie prognoz modelu umożliwia monitorowanie jego jakości. Dzięki agregowaniu prognoz możesz sprawdzać ogólną jakość modelu i sprawdzać, czy zaczyna on tracić jakość. Ogólnie prognozy modelu produkcyjnego powinny mieć taką samą średnią jak etykiety ze zbioru danych treningowych. Więcej informacji znajdziesz w artykule o odchyleniu prognoz.
Rejestrowanie danych podstawowych
W niektórych przypadkach dane ground truth staje się dostępne znacznie później. Jeśli na przykład aplikacja pogodowa przewiduje pogodę za 6 tygodni w przyszłości, dane podstawowe (czyli o rzeczywistości) nie będą dostępne przez 6 tygodni.
Jeśli to możliwe, zachęć użytkowników do zgłaszania podstawowych informacji przez dodanie do aplikacji mechanizmów przekazywania informacji zwrotnych. Gmail pośrednio rejestruje opinie użytkowników, gdy przenoszą pocztę ze skrzynki odbiorczej do folderu ze spamem. Ta funkcja działa jednak tylko wtedy, gdy użytkownik poprawnie kategoryzuje pocztę. Gdy użytkownicy zostawiają spam w skrzynce odbiorczej (ponieważ wiedzą, że to spam i nigdy go nie otwierają), dane treningowe stają się niedokładne. Taka wiadomość zostanie oznaczona jako „nie spam”, a zamiast „spam”. Innymi słowy, zawsze staraj się znajdować sposoby rejestrowania i rejestrowania danych podstawowych, ale pamiętaj o brakach w mechanizmach informacji zwrotnych.
Rysunek 7 przedstawia prognozy dostarczane do użytkownika i rejestrowane w repozytorium.
Prognozy dotyczące rejestrowania
Rysunek 7. Rejestruj prognozy, aby monitorować jakość modelu.
Potoki danych
Potoki danych generują zbiory danych do trenowania i testowania na podstawie danych z aplikacji. Potoki trenowania i walidacji używają następnie zbiorów danych do trenowania i weryfikowania nowych modeli.
Potok danych tworzy zbiory danych do trenowania i testowania z tymi samymi funkcjami i etykietami, które były wcześniej używane do trenowania modelu, ale z nowszymi informacjami. Na przykład aplikacja do map generuje zbiory danych treningowych i testowych dla milionów użytkowników na podstawie ostatnich podróży między punktami, a także inne istotne dane, takie jak prognoza pogody.
Aplikacja z rekomendacjami wideo generowałaby zbiory danych do trenowania i testowania obejmujące filmy kliknięte przez użytkownika z listy polecanych (wraz z tymi, które nie zostały kliknięte), a także inne istotne dane, np. historię oglądania.
Rysunek 8 przedstawia potok danych wykorzystujący dane aplikacji do generowania zbiorów danych do trenowania i testowania.
Potok danych
Rysunek 8. Potok danych przetwarza dane aplikacji, aby tworzyć zbiory danych na potrzeby potoków trenowania i walidacji.
Zbieranie i przetwarzanie danych
Zadania związane z gromadzeniem i przetwarzaniem danych w potokach danych prawdopodobnie będą się różnić od zadań wykonywanych w fazie eksperymentu (gdy stwierdzisz, że Twoje rozwiązanie jest możliwe):
Zbieranie danych: W trakcie eksperymentów zbieranie danych wymaga zwykle dostępu do zapisanych danych. W przypadku potoków danych zbieranie danych może wymagać wykrywania i uzyskiwania zgody na dostęp do danych logów strumieniowania.
Jeśli potrzebujesz danych oznaczonych etykietami przez człowieka (np. zdjęć medycznych), musisz również przeprowadzić proces ich zbierania i aktualizowania. Jeśli potrzebujesz danych oznaczonych etykietami przez człowieka, wejdź na stronę CrowdCompute.
Przetwarzanie danych. Podczas eksperymentów odpowiednie funkcje pochodziły ze pobierania, łączenia i próbkowania zbiorów danych objętych eksperymentem. W przypadku potoków danych wygenerowanie tych samych cech może wymagać zupełnie innych procesów. Pamiętaj jednak, aby zduplikować przekształcenia danych z fazy eksperymentu, stosując te same działania matematyczne do cech i etykiet.
Przechowywanie zasobów i metadanych
Będzie Ci potrzebny proces przechowywania i obsługi wersji zbiorów danych, a także zarządzania zbiorem danych do trenowania i testowania. Repozytoria kontrolowane wersji mają następujące korzyści:
Powtarzalność. Odtwarzanie i ustandaryzowanie środowisk treningowych modeli oraz porównywanie jakości prognoz w różnych modelach.
Zgodność z przepisami. Przestrzegaj przepisów w zakresie kontroli i przejrzystości.
Utrzymanie. Ustaw wartości, przez jakie dane mają być przechowywane.
Zarządzanie dostępem. Określ, kto może mieć dostęp do Twoich danych, korzystając ze szczegółowych uprawnień.
Integralność danych. Śledź i analizuj zmiany zachodzące w zbiorach danych na przestrzeni czasu, co ułatwia diagnozowanie problemów z danymi lub modelem.
Wykrywalność. Ułatw innym znajdowanie zbiorów danych i funkcji. Inne zespoły mogą następnie określić, czy będą one przydatne w tych zadaniach.
Dokumentowanie danych
Dobra dokumentacja pomoże innym zrozumieć kluczowe informacje o Twoich danych, takie jak typ, źródło, rozmiar i inne ważne metadane. W większości przypadków wystarczy dokument projektowy lub g3doc. Jeśli zamierzasz udostępniać lub publikować swoje dane, możesz uporządkować informacje za pomocą kart danych. Karty danych ułatwiają innym odkrywanie i interpretowanie zbiorów danych.
Potoki trenowania i walidacji
Potoki trenowania i walidacji tworzą nowe modele, które zastępują modele produkcyjne, zanim staną się nieaktualne. Dzięki ciągłym trenowaniu i sprawdzaniu nowych modeli zapewniamy, że najlepszy model będzie zawsze w środowisku produkcyjnym.
Potok trenowania generuje nowy model ze zbiorów danych treningowych, a następnie porównuje jakość nowego modelu z tym w środowisku produkcyjnym przy użyciu testowych zbiorów danych.
Rysunek 9 przedstawia potok trenowania z wykorzystaniem zbioru danych treningowych do trenowania nowego modelu.
Potok trenowania
Rysunek 9. Potok trenowania trenuje nowe modele przy użyciu najnowszego zbioru danych treningowych.
Po wytrenowaniu modelu potok weryfikacji używa testowych zbiorów danych do porównywania jakości modelu produkcyjnego z wytrenowanym modelem.
Jeśli wytrenowany model nie jest znacznie gorszy od modelu produkcyjnego, jest on zwykle wprowadzany do produkcji. Jeśli wytrenowany model jest gorszy, infrastruktura monitorowania powinna utworzyć alert. Wytrenowane modele o gorszej jakości prognoz mogą wskazywać na potencjalne problemy z danymi lub potokami weryfikacji. Dzięki temu zawsze jest w środowisku produkcyjnym najlepszy model wytrenowany z wykorzystaniem najnowszych danych.
Przechowywanie zasobów i metadanych
Modele i ich metadane powinny być przechowywane w repozytoriach z obsługą wersji, aby porządkować i śledzić wdrożenia modeli. Repozytoria modeli zapewniają te korzyści:
Śledzenie i ocena. Śledź modele w środowisku produkcyjnym i interpretuj ich wskaźniki jakości oraz oceny.
Proces udostępniania modelu. Z łatwością przeglądaj, zatwierdzaj, publikuj i wycofuj modele.
Powtarzalność i debugowanie. Odtwarzanie wyników modeli i skuteczniejsze debugowanie problemów przez śledzenie zbiorów danych i zależności modelu w różnych wdrożeniach.
Wykrywalność. Ułatw innym znalezienie modelu. Inne zespoły będą mogły ustalić, czy Twój model (lub jego części) sprawdzi się w poszczególnych celach.
Rysunek 10 przedstawia zweryfikowany model przechowywany w repozytorium modeli.
Pamięć modelu
Rysunek 10. Zweryfikowane modele są przechowywane w repozytorium modeli na potrzeby śledzenia i wykrywalności.
Za pomocą kart modelu możesz dokumentować i udostępniać kluczowe informacje o modelu, takie jak jego przeznaczenie, architektura, wymagania sprzętowe, wskaźniki oceny itp.
Wyzwania związane z tworzeniem potoków
Podczas tworzenia potoków możesz napotkać te problemy:
Jak uzyskać dostęp do potrzebnych danych Dostęp do danych może wymagać uzasadnienia. Możesz na przykład wyjaśnić, jak dane będą wykorzystywane i jak rozwiązywać problemy z informacjami umożliwiającymi identyfikację. Przygotuj się do zademonstrowania modelu koncepcyjnego, który pokaże, jak Twój model generuje lepsze prognozy na podstawie dostępu do określonych rodzajów danych.
Korzystanie z odpowiednich funkcji. W niektórych przypadkach funkcje wykorzystywane w fazie eksperymentu nie będą dostępne w danych w czasie rzeczywistym. Dlatego w ramach eksperymentów warto się upewnić, że będziesz w stanie korzystać z tych samych funkcji w wersji produkcyjnej.
Zrozumienie sposobu zbierania i przedstawiania danych. Ustalenie, w jaki sposób i kto to zgromadziło dane oraz w jaki sposób (wraz z innymi problemami) może wymagać czasu i wysiłku. Ważne jest dokładne zrozumienie danych. Do trenowania modelu, który może zostać wdrożony, nie używaj danych, do których nie masz pewności.
Zrozumienie zależności między nakładem pracy, kosztami i jakością modelu. Wprowadzanie nowej funkcji do potoku danych może wymagać dużo wysiłku. Ta dodatkowa funkcja może tylko nieco poprawić jakość modelu. W innych przypadkach dodanie nowej funkcji może być łatwe. Zasoby potrzebne do uzyskania i przechowywania funkcji mogą być jednak zbyt drogie.
Przetwarzanie. Jeśli potrzebujesz jednostek TPU do ponownego trenowania, uzyskanie wymaganego limitu może być trudne. Poza tym zarządzanie TPU jest skomplikowane. Na przykład niektóre części modelu lub danych mogą być specjalnie zaprojektowane pod kątem TPU przez rozdzielenie ich na kilka układów TPU.
Jak znaleźć odpowiedni złoty zbiór danych Jeśli dane często się zmieniają, uzyskanie złotych zbiorów danych ze spójnymi i dokładnymi etykietami może być trudne.
Wychwytywanie takich problemów podczas eksperymentów pozwala zaoszczędzić czas. Dzięki temu nie chcemy np. rozwijać najlepszych funkcji i modeli, aby przekonać się, że nadają się one do użytku w środowisku produkcyjnym. Dlatego jak najszybciej upewnij się, że Twoje rozwiązanie będzie działać w ramach ograniczeń środowiska produkcyjnego. Lepiej sprawdzić, czy rozwiązanie działa, niż wracać do fazy eksperymentu, ponieważ etap potoku wykrył problemy, których nie da się rozwiązać.