Podejścia do testowania modeli Amazon SageMaker ML

Opublikowane ponownie przez Plato

Obserwuje: 0

Ten post został napisany wspólnie z Tobiasem Wenzelem, menedżerem ds. inżynierii oprogramowania dla platformy Intuit Machine Learning.

Wszyscy doceniamy znaczenie wysokiej jakości i niezawodnego modelu uczenia maszynowego (ML) podczas korzystania na przykład z autonomicznej jazdy lub interakcji z Alexą. Modele ML odgrywają również ważną rolę w mniej oczywisty sposób — są używane przez aplikacje biznesowe, opiekę zdrowotną, instytucje finansowe, amazon.com, TurboTax i inne.

Ponieważ aplikacje obsługujące ML stają się podstawą wielu firm, modele muszą działać z takim samym wigorem i dyscypliną, jak aplikacje. Ważnym aspektem MLOps jest dostarczanie nowej wersji wcześniej opracowanego modelu ML w środowisku produkcyjnym przy użyciu ustalonych praktyk DevOps, takich jak testowanie, wersjonowanie, ciągłe dostarczanie i monitorowanie.

Istnieje kilka nakazowy wytyczne dotyczące MLOps, a ten post zawiera przegląd procesu, który możesz śledzić i jakich narzędzi użyć do testowania. Opiera się to na współpracy między Intuit i AWS. Pracujemy razem nad wdrożeniem zaleceń wyjaśnionych w tym poście w praktyce i na dużą skalę. Celem Intuit jest stanie się an Platforma ekspercka oparta na sztucznej inteligencji jest silnie uzależniony od strategii zwiększania szybkości opracowywania początkowego modelu oraz testowania nowych wersji.

wymagania

Oto główne obszary do rozważenia podczas wdrażania nowych wersji modeli:

Wydajność dokładności modelu - To ważne aby śledzić metryk oceny modelu, takich jak dokładność, precyzja i przywołanie, i upewnij się, że obiektywne metryki pozostają względnie takie same lub poprawiają się wraz z nową wersją modelu. W większości przypadków wdrożenie nowej wersji modelu nie ma sensu, jeśli nie poprawi się środowisko użytkowników końcowych.
Testuj jakość danych – Dane w środowiskach nieprodukcyjnych, zarówno symulowane, jak i kopiowane w określonym czasie, powinny być reprezentatywne dla danych, które model otrzyma po pełnym wdrożeniu, pod względem ilości lub dystrybucji. Jeśli nie, Twoje procesy testowania nie będą reprezentatywne, a Twój model może zachowywać się inaczej w środowisku produkcyjnym.
Znaczenie i parzystość funkcji – Znaczenie funkcji w nowszej wersji modelu powinno być względnie porównywalne ze starszym modelem, chociaż mogą zostać wprowadzone nowe funkcje. Ma to na celu zapewnienie, że model nie będzie stronniczy.
Testowanie procesów biznesowych – Ważne jest, aby nowa wersja modelu mogła spełnić wymagane cele biznesowe w akceptowalnych parametrach. Na przykład jedną z metryk biznesowych może być to, że całkowite opóźnienie dla dowolnej usługi nie może przekraczać 100 milisekund lub koszt hostowania i ponownego szkolenia określonego modelu nie może przekraczać 10,000 XNUMX USD rocznie.
Koszty: – Prostym podejściem do testowania jest replikacja całego środowiska produkcyjnego jako środowiska testowego. Jest to powszechna praktyka w tworzeniu oprogramowania. Jednak takie podejście w przypadku modeli ML może nie zapewnić odpowiedniego zwrotu z inwestycji w zależności od rozmiaru danych i może mieć wpływ na model pod względem problemu biznesowego, który ma rozwiązać.
Bezpieczeństwo – Od środowisk testowych często oczekuje się danych przykładowych zamiast rzeczywistych danych klienta, w wyniku czego zasady obsługi danych i zgodności mogą być mniej rygorystyczne. Podobnie jak w przypadku kosztów, jeśli po prostu zduplikujesz środowisko produkcyjne do środowiska testowego, możesz wprowadzić ryzyko związane z bezpieczeństwem i zgodnością.
Skalowalność sklepu z funkcjami – Jeśli organizacja zdecyduje się nie tworzyć oddzielnego magazynu funkcji testowych z powodu kosztów lub bezpieczeństwa, testowanie modelu musi odbywać się w magazynie funkcji produkcyjnych, co może powodować problemy ze skalowalnością, ponieważ ruch jest podwojony w okresie testowania.
Wydajność modelu online – Oceny online różnią się od ocen offline i mogą być ważne w niektórych przypadkach, takich jak modele rekomendacji, ponieważ mierzą satysfakcję użytkownika w czasie rzeczywistym, a nie satysfakcję postrzeganą. Trudno jest symulować rzeczywiste wzorce ruchu w środowisku nieprodukcyjnym ze względu na sezonowość lub inne zachowania użytkowników, więc wydajność modelu online można wykonać tylko w środowisku produkcyjnym.
Wydajność operacyjna – Ponieważ modele stają się coraz większe i są coraz częściej wdrażane w sposób zdecentralizowany na innym sprzęcie, ważne jest, aby przetestować model pod kątem pożądanej wydajności operacyjnej, takiej jak opóźnienia, wskaźnik błędów i inne.

Większość zespołów ML ma wielotorowe podejście do testowania modeli. W kolejnych sekcjach przedstawiamy sposoby sprostania tym wyzwaniom na różnych etapach testowania.

Testowanie modeli offline

Celem tej fazy testowania jest walidacja nowych wersji istniejącego modelu z punktu widzenia dokładności. Należy to robić w trybie offline, aby nie wpływać na żadne prognozy w systemie produkcyjnym, które obsługują prognozy w czasie rzeczywistym. Zapewniając, że nowy model działa lepiej w przypadku odpowiednich metryk oceny, test ten rozwiązuje wyzwanie 1 (dokładność modelu). Ponadto, przy użyciu odpowiedniego zestawu danych, testowanie może sprostać wyzwaniom 2 i 3 (jakość danych testowych, ważność funkcji i parzystość), z dodatkową korzyścią sprostania wyzwaniu 5 (koszt).

Ta faza jest wykonywana w środowisku pomostowym.

Należy przechwytywać ruch produkcyjny, którego można użyć do ponownego odtworzenia podczas testowania wstecznego w trybie offline. Lepiej jest używać wcześniejszego ruchu produkcyjnego zamiast danych syntetycznych. The Monitor modelu Amazon SageMaker funkcja przechwytywania danych umożliwia przechwytywanie ruchu produkcyjnego dla modeli hostowanych na Amazon Sage Maker. Pozwala to twórcom modeli testować swoje modele na danych z dni szczytu lub innych ważnych wydarzeń. Przechwycone dane są następnie odtwarzane z nową wersją modelu w sposób wsadowy za pomocą Transformacja wsadowa Sagemakera. Oznacza to, że przebieg transformacji wsadowej może w ciągu kilku godzin przetestować dane zebrane przez tygodnie lub miesiące. Może to znacznie przyspieszyć proces oceny modelu w porównaniu z uruchamianiem dwóch lub więcej wersji modelu w czasie rzeczywistym obok siebie i wysyłaniem zduplikowanych żądań prognozowania do każdego punktu końcowego. Oprócz szybszego znajdowania wydajniejszej wersji podejście to wykorzystuje również zasoby obliczeniowe przez krótszy czas, zmniejszając całkowity koszt.

Wyzwaniem przy takim podejściu do testowania jest to, że zestaw funkcji zmienia się z jednej wersji modelu na inną. W tym scenariuszu zalecamy utworzenie zestawu funkcji z nadzbiorem funkcji dla obu wersji, aby wszystkie funkcje można było odpytywać jednocześnie i rejestrować za pomocą przechwytywania danych. Każde wywołanie prognozowania może wtedy działać tylko na tych funkcjach, które są niezbędne dla bieżącej wersji modelu.

Jako dodatkowy bonus, integrując Amazon SageMaker Wyjaśnij w testowaniu modelu offline możesz sprawdzić nową wersję modelu pod kątem odchyleń, a także porównać atrybucję funkcji z poprzednią wersją modelu. Dzięki potokom można zaaranżować cały przepływ pracy w taki sposób, aby po szkoleniu przeprowadzić etap kontroli jakości w celu przeprowadzenia analizy metryk modelu i ważności funkcji. Te dane są przechowywane w Rejestr modeli SageMaker do porównania w kolejnym cyklu szkolenia.

Testy integracyjne i wydajnościowe

Testy integracyjne są potrzebne do walidacji kompleksowych procesów biznesowych zarówno z perspektywy funkcjonalnej, jak i wykonawczej. W ramach tego procesu należy przetestować cały potok, w tym pobieranie i obliczanie funkcji w magazynie funkcji oraz uruchamianie aplikacji ML. Należy to zrobić za pomocą różnych ładunków, aby uwzględnić różne scenariusze i żądania oraz osiągnąć wysoki poziom pokrycia wszystkich możliwych uruchomień kodu. Odpowiada to wyzwaniom 4 i 9 (testowanie procesów biznesowych i wydajność operacyjna), aby zapewnić, że żaden z procesów biznesowych nie zostanie przerwany w nowej wersji modelu.

Testy te należy przeprowadzić w środowisku przejściowym.

Zarówno testowanie integracyjne, jak i testowanie wydajności muszą być wdrażane przez poszczególne zespoły przy użyciu potoku MLOps. Do testów integracyjnych zalecamy wypróbowaną i przetestowaną metodę utrzymywania funkcjonalnie równoważnego środowiska przedprodukcyjnego i testowania z kilkoma różnymi ładunkami. Przepływ pracy testowania można zautomatyzować, jak pokazano na ten warsztat. Do testowania wydajności możesz użyć Polecający wnioskowanie Amazon SageMaker, który stanowi doskonały punkt wyjścia do określenia typu wystąpienia i liczby używanych wystąpień. W tym celu musisz użyć narzędzia do generowania obciążenia, takiego jak projekty open-source perfsizemaker i perfrozmiar którą opracował Intuit. Perfsizesagemaker umożliwia automatyczne testowanie konfiguracji punktów końcowych modelu przy różnych obciążeniach, czasach odpowiedzi i szczytowych wymaganiach dotyczących transakcji na sekundę. Generuje szczegółowe wyniki testów, które porównują różne wersje modeli. Perfsize to narzędzie towarzyszące, które wypróbowuje różne konfiguracje, biorąc pod uwagę tylko szczytowe transakcje na sekundę i oczekiwany czas odpowiedzi.

Testy A / B

W wielu przypadkach, w których wymagana jest reakcja użytkownika na natychmiastowe dane wyjściowe modelu, na przykład w aplikacjach e-commerce, ocena funkcjonalna modelu w trybie offline nie jest wystarczająca. W tych scenariuszach musisz przetestować modele A/B w środowisku produkcyjnym przed podjęciem decyzji o aktualizacji modeli. Testy A/B również wiążą się z ryzykiem, ponieważ mogą mieć rzeczywisty wpływ na klienta. Ta metoda testowania służy jako ostateczna walidacja wydajności ML, czyli lekka kontrola poprawności technicznej. Ta metoda odnosi się również do wyzwań 8 i 9 (wydajność modelu online i doskonałość operacyjna).

Testy A/B powinny być wykonywane w środowisku produkcyjnym.

Dzięki SageMaker możesz łatwo przeprowadzić testy A/B na modelach ML, uruchamiając wiele wariantów produkcyjnych w punkcie końcowym. Ruch można kierować w przyrostach do nowej wersji, aby zmniejszyć ryzyko, że źle zachowujący się model może mieć w środowisku produkcyjnym. Jeśli wyniki testu A/B wyglądają dobrze, ruch jest kierowany do nowej wersji, ostatecznie przejmując 100% ruchu. Do przejścia z modelu A do B zalecamy stosowanie poręczy wdrażania. Aby uzyskać pełniejszą dyskusję na temat testowania A/B przy użyciu Amazon Personalizuj modele jako przykład, patrz Korzystanie z testów A / B do pomiaru skuteczności rekomendacji generowanych przez Amazon Personalize.

Testowanie modeli online

W tym scenariuszu nowa wersja modelu znacznie różni się od tej, która już obsługuje ruch na żywo w środowisku produkcyjnym, więc podejście do testowania offline nie jest już odpowiednie do określania skuteczności nowej wersji modelu. Najważniejszym powodem tego jest zmiana funkcji wymaganych do wygenerowania prognozy, tak aby nie można było użyć wcześniej zarejestrowanych transakcji do testowania modelu. W tym scenariuszu zalecamy korzystanie z wdrożeń w tle. Wdrożenia cienia oferują możliwość wdrożenia cienia (lub challenger) model obok produkcji (lub mistrz) model, który obecnie obsługuje prognozy. Pozwala to ocenić, jak model cienia działa w ruchu produkcyjnym. Prognozy modelu cienia nie są obsługiwane do aplikacji żądającej; są rejestrowane do oceny w trybie offline. Dzięki podejściu cienia do testowania rozwiązujemy wyzwania 4, 5, 6 i 7 (testowanie procesów biznesowych, koszty, bezpieczeństwo i skalowalność magazynu funkcji).

Testowanie modelu online powinno odbywać się w środowiskach pomostowych lub produkcyjnych.

Ta metoda testowania nowych wersji modeli powinna być stosowana w ostateczności, jeśli nie można zastosować wszystkich innych metod. Zalecamy to jako ostateczność, ponieważ dupleksowanie wywołań do wielu modeli generuje dodatkowe obciążenie wszystkich usług podrzędnych w produkcji, co może prowadzić do wąskich gardeł wydajności, a także zwiększonych kosztów produkcji. Najbardziej oczywisty wpływ ma to na warstwę obsługi funkcji. W przypadku przypadków użycia, które współużytkują funkcje ze wspólnej puli danych fizycznych, musimy być w stanie symulować wiele przypadków użycia jednocześnie uzyskujących dostęp do tej samej tabeli danych, aby zapewnić brak rywalizacji o zasoby przed przejściem do środowiska produkcyjnego. W miarę możliwości należy unikać zduplikowanych zapytań do magazynu funkcji, a funkcje potrzebne dla obu wersji modelu należy ponownie wykorzystać do drugiego wnioskowania. Sklepy z funkcjami na podstawie Amazon DynamoDB, tak jak ten, który zbudował Intuit, może zaimplementować Akcelerator Amazon DynamoDB(DAX) do buforowania i unikania dublowania operacji we/wy w bazie danych. Te i inne opcje buforowania mogą złagodzić wyzwanie 7 (skalowalność sklepu z funkcjami).

Aby sprostać wyzwaniu 5 (koszt), a także 7, proponujemy użycie wdrożeń w tle do próbkowania ruchu przychodzącego. Daje to właścicielom modeli kolejną warstwę kontroli, aby zminimalizować wpływ na systemy produkcyjne.

Wdrożenie w tle powinno być dołączone do Monitor modelu ofert podobnie jak zwykłe wdrożenia produkcyjne w celu obserwowania ulepszeń wersji challenger.

Wnioski

Ten post ilustruje bloki konstrukcyjne do tworzenia kompleksowego zestawu procesów i narzędzi do rozwiązywania różnych problemów związanych z testowaniem modeli. Chociaż każda organizacja jest wyjątkowa, powinno to pomóc w rozpoczęciu i zawęzić rozważania podczas wdrażania własnej strategii testowania.

O autorach

Tobiasz Wenzel jest kierownikiem ds. inżynierii oprogramowania w platformie Intuit Machine Learning w Mountain View w Kalifornii. Pracuje nad platformą od jej powstania w 2016 roku i pomagał zaprojektować i zbudować ją od podstaw. W swojej pracy skupił się na doskonałości operacyjnej platformy i przeniesieniu jej z sukcesem w sezonowej działalności Intuit. Ponadto pasjonuje go ciągłe poszerzanie platformy o najnowsze technologie.

Shivanshu Upadhyay jest głównym architektem rozwiązań w grupie AWS Business Development and Strategic Industries. W tej roli pomaga najbardziej zaawansowanym użytkownikom AWS przekształcić ich branżę, efektywnie wykorzystując dane i sztuczną inteligencję.

Alana Tana jest starszym menedżerem produktu w firmie SageMaker, kierując pracami nad wnioskowaniem na dużych modelach. Pasjonuje go zastosowanie uczenia maszynowego w obszarze analityki. Poza pracą lubi przebywać na świeżym powietrzu.