Testowanie i ocenianie obciążeń sztucznej inteligencji na platformie Azure
Celem testowania obciążeń sztucznej inteligencji jest zapewnienie jakości w przypadku wprowadzenia zmiany w systemie. Testowanie może sprawdzić, czy obciążenie spełnia określone cele i spełnia oczekiwania użytkowników. Zapobiega również regresjom jakości. Ten proces obejmuje przeprowadzanie testów w różnych obszarach funkcjonalnych i ocenę jakości funkcjonalności, obsługi obciążenia, przewidywalności i innych kryteriów na podstawie wymagań dotyczących obciążenia.
Wyniki testów zapewniają krytyczne punkty danych dla decyzji , takich jak to, czy składniki sztucznej inteligencji są gotowe do wydania i które jednostki SKU lub funkcje są odpowiednie. Ponadto testowanie może służyć jako system powiadomień dla niepowodzeń i pomaga wykrywać problemy w środowisku produkcyjnym za pomocą rutynowych lub syntetycznych testów.
Struktura Azure Well-Architected Framework przedstawia kompleksową metodologię testowania. Należy używać różnych typów testów na różnych etapach cyklu projektowania i różnych składników i przepływów systemowych. Bez tych testów wprowadzone zmiany mogą obniżyć jakość systemu. Na przykład drobne błędy kodu mogą stać się dużymi awariami systemu. Zachowanie systemu może stać się nieprzewidywalne lub spowodować stronniczy wynik ze względu na niedeterministyczny charakter systemów sztucznej inteligencji. Ponadto alokacja zasobów może być nieefektywna, a rzeczywiste dane użytkowników lub zasoby systemowe mogą być wykorzystywane, ponieważ te systemy są narażone na nadużycia.
Należy zaprojektować i opracować zasoby obciążeń z myślą o testach. Na przykład podczas przeprowadzania manipulowania danymi i zmieniania danych źródłowych na potrzeby inżynierii cech należy przestrzegać dobrych praktyk kodowania i upewnić się, że kod jest strukturą do obsługi testowania. Ta strategia obejmuje projektowanie kodu w celu ułatwienia efektywnego testowania jednostkowego i izolowania testów z funkcjonalności kodu i jego zależności. W tym przykładzie należy zaprojektować system, który może działać w środowisku testowym z wystarczająco reprezentatywnymi danymi testowymi pod względem ilości i podobieństwa.
Składniki obciążenia należy wdrożyć w środowisku produkcyjnym bezpiecznie. Częścią praktyk bezpiecznego wdrażania dowolnego obciążenia jest testowanie strategiczne, które pomaga zapewnić prawidłowe zachowanie przed użyciem systemu przez użytkowników lub dane. Testowanie strategiczne jest niezbędne podczas początkowego wdrażania i w miarę rozwoju systemu i przechodzenia zmian w kodzie lub infrastrukturze. Przed wdrożeniem zmian w środowisku produkcyjnym przetestuj wszystkie proponowane zmiany w kodzie i infrastrukturze związanej ze sztuczną inteligencją.
Ten artykuł koncentruje się na zastosowaniu tej metodologii do aspektów sztucznej inteligencji architektury. Sposób przeprowadzania tych testów nie jest w zakresie.
Zalecenia
Poniżej przedstawiono podsumowanie zaleceń przedstawionych w tym artykule.
| Zalecenie | opis |
|---|---|
| Zdefiniuj metryki sukcesu dla strategii testowania. | Podobnie jak w przypadku każdego innego typu testowania obciążenia, należy przechwycić i przeanalizować odpowiednie metryki dla danego testu, aby upewnić się, że test zapewnia przydatne szczegółowe informacje o obciążeniu sztucznej inteligencji. ▪ Definiowanie metryk powodzenia |
| Przeprowadź kompleksowe testowanie potoków pozyskiwania i przetwarzania danych w całym cyklu życia programowania. | Testy mogą weryfikować dane i pomóc w zapewnieniu, że proces manipulowania danymi działa zgodnie z oczekiwaniami. Uwzględnij testowanie na wczesnym etapie projektowania, aby zapewnić jakość danych i odpowiednią technologię oraz wybór rozmiaru. Twórz testy jednostkowe kodu niestandardowego podczas programowania i przeprowadzaj testy produkcyjne w czasie rzeczywistym, aby przechwytywać problemy i weryfikować funkcje. ▪ Testowanie pozyskiwania danych |
| Uruchom testy dla zadań szkoleniowych, aby upewnić się, że skrypty są wywoływane i działają zgodnie z oczekiwaniami. | Testowanie obciążenia i wydajności może zapewnić wgląd w wybór i ustalanie rozmiaru zasobów obliczeniowych, które są odpowiednie do uruchamiania zadań. Testy jednostkowe mogą weryfikować narzędzie kodu i przechwytywać regresje po zaktualizowaniu zależności. ▪ Testowanie przepływu pracy trenowania |
| Oceń i przetestuj model, aby uniknąć duplikowania w danych treningowych, ewaluacyjnych i testowych. | Aby zapewnić, że dane źródłowe nie są całkowicie używane do trenowania, należy zarezerwować unikatowe dane na potrzeby oceny modelu i testowania końcowego. Te podzestawy nie są uwzględniane w rzeczywistym procesie trenowania. ▪ Ocenianie i testowanie modelu |
| Przetestuj punkt końcowy wnioskowania. | Przeprowadź testowanie obciążenia w punkcie końcowym hostów serwera wnioskowania i wybierz jednostki SKU procesora GPU na podstawie tych wyników testu. W przypadku punktów końcowych hostowanych jako platforma (PaaS) przetestuj przepływność i potencjalne błędy. Te punkty końcowe są osiągalne, dlatego należy przeprowadzić odpowiednie testy zabezpieczeń, aby zapobiec sytuacjom z złamaniem systemu. ▪ Testowanie punktu końcowego wnioskowania |
| Przetestuj poprawność projektu indeksu, aby zapytania przyniosły odpowiednie wyniki. | Testowanie funkcjonalne i integracyjne pomaga upewnić się, że dane są dokładne, a testy schematu indeksu sprawdzają zgodność z poprzednimi wersjami. Należy przetestować kroki przetwarzania wstępnego pod kątem jakości. Testowanie obciążenia określa odpowiednie jednostki SKU dla zasobów, a mechanizmy zabezpieczeń chronią poufność danych. ▪ Testowanie danych uziemienia |
| Przetestuj koordynatora, aby zweryfikować jego funkcjonalność i zabezpieczenia. | Przeprowadzanie testów jednostkowych, funkcjonalnych, integracji i środowiska uruchomieniowego, w tym testowania trybu obciążenia i awarii w celu zapewnienia wydajności i niezawodności. Testy bezpieczeństwa zabezpieczeń i zawartości mają również kluczowe znaczenie dla ochrony systemu i danych. ▪ Testowanie orkiestratora |
| Testowanie rozkładu modelu. | Rozkład modelu jest nieuniknionym problemem, który ma wpływ na większość obciążeń sztucznej inteligencji. Testowanie dryfu danych i koncepcji może pomóc w wczesnym przechwyceniu rozkładu modelu i wyeliminowaniu problemu, zanim negatywnie wpłynie to na obciążenie. ▪ Zapobieganie rozpadowi modelu |
Definiowanie metryk powodzenia
Zalecamy użycie linii bazowej i pomiar mocy predykcyjnej modelu przy użyciu dobrze zdefiniowanych metryk. Oto kilka typowych metryk.
Dokładność reprezentuje stosunek poprawnie przewidywanych wystąpień do łącznej liczby wystąpień w zestawie danych testowych. Jest to powszechna miara ogólnej wydajności modelu.
Precyzja to stosunek prawdziwie dodatnich przewidywań do sumy wyników prawdziwie dodatnich i wyników fałszywie dodatnich. Jest to przydatne, gdy minimalizacja wyników fałszywie dodatnich jest ważna, na przykład w diagnozach medycznych.
Czułość mierzy stosunek wyników prawdziwie dodatnich do sumy wyników prawdziwie dodatnich i wyników fałszywie ujemnych. Jest to przydatne, gdy unikanie fałszywych wyników ujemnych lub brak odpowiednich przypadków ma krytyczne znaczenie.
Specyfika oblicza stosunek wartości prawdziwie ujemnych do sumy prawdziwie ujemnych i wyników fałszywie dodatnich. Jest to istotne w przypadku optymalizacji pod kątem dokładnych negatywnych przewidywań.
Uwaga
Podczas definiowania metryk sukcesu dla modeli regresji rozważ dodanie następujących metryk:
Średni błąd bezwzględny (MAE) mierzy średnią różnicę bezwzględną między przewidywanymi wartościami a rzeczywistymi wartościami. Oblicz ją, przyjmując średnią różnic bezwzględnych między każdą rzeczywistą wartością a odpowiadającą jej przewidywaną wartością. Funkcja MAE jest mniej wrażliwa na wartości odstające w porównaniu z msE i RMSE.
Błąd średniokwadratowy (MSE) mierzy średnią kwadratową różnicę między rzeczywistymi wartościami a przewidywanymi wartościami. Oblicz ją, przyjmując średnią różnic kwadratowych między każdą rzeczywistą wartością a odpowiadającą jej przewidywaną wartością. Program MSE karze większe błędy bardziej niż MAE, ponieważ błędy są kwadratowe.
Główny błąd średniokwadratowy (RMSE) jest pierwiastek kwadratowy MSE. Zapewnia ona miarę średniego błędu bezwzględnego między wartościami rzeczywistymi i przewidywanymi, ale w tych samych jednostkach co oryginalne dane. Usługa RMSE jest bardziej wrażliwa na wartości odstające w porównaniu z programem MAE, ponieważ tworzy kwadraty błędów przed uśrednianiem.
Testowanie pozyskiwania danych
Potoki danych, takie jak wyodrębnianie, przekształcanie i ładowanie (ETL) procesów, przenoszenie i manipulowanie danymi. Przetestuj część ETL obciążenia, aby upewnić się, że dane są pozyskiwane niezawodnie i że dane są wysokiej jakości i akceptowalne dla analizy i inżynierii cech. Upewnij się, że czyszczenie i przetwarzanie danych obejmuje testy, aby potwierdzić, że manipulowanie danymi działa zgodnie z oczekiwaniami.
Testy powinny być zintegrowane przez cały cykl życia, w tym etapy projektowania, programowania i produkcji.
Testowanie w celu ułatwienia wyborów projektowych
W przypadku zbierania wymagań dotyczących obciążenia kluczowym krokiem podejmowania decyzji jest wybranie konkretnej opcji technologii, która jest odpowiednia dla danego projektu.
Na podstawie wymagań ETL i kryteriów akceptacji przeprowadź eksploracyjne testy funkcjonalne, aby wybrać najbardziej odpowiedni produkt, jego jednostki SKU i funkcje, które wykonują zamierzone zadania. Weryfikacja koncepcji, weryfikacja technologii i weryfikacja testów możliwości są niezbędne do oceny, czy wybierasz odpowiednią technologię i czy jest ona odpowiednia.
W przypadku scenariuszy, w których sztuczna inteligencja jest dołączana do istniejącej architektury, przetestuj, jak dobrze nowa technologia może być zintegrowana z bieżącym systemem.
Początkowe wymagania dotyczące obciążenia mogą ulec zmianie. Załóżmy, że firma przewiduje wzrost, a system musi obsługiwać dwukrotnie zwykłe zapytania użytkowników. To oczekiwanie wymaga odpowiedniego planowania pojemności. Zalecamy proaktywne testowanie, aby zrozumieć, w jaki sposób system reaguje na dodatkowe dane i wprowadzić dostosowania oparte na danych do istniejących rozmiarów lub dokonywania nowych wyborów produktów. W przypadku testowania pojemności zalecamy połączenie testów funkcjonalnych z testami obciążeniowymi i testami wydajnościowymi oraz używanie syntetycznych do symulowania realistycznych warunków.
Testowanie w celu zapewnienia jakości kodu
Po dołączeniu kodu upewnij się, że przechodzi on przez testowanie jednostkowe i nie zostanie wydany, jeśli zakończy się niepowodzeniem. Na przykład często zdarza się, że kod niestandardowy jest uruchamiany w ramach pozyskiwania. Istnieje również kod używany do czyszczenia i przetwarzania danych. Uruchom testy jednostkowe, aby upewnić się, że kod działa zgodnie z jego projektem i że manipulowanie danymi działa zgodnie z oczekiwaniami.
Uruchamianie testów w ramach potoku ciągłej integracji i ciągłego dostarczania.
Testowanie w systemie na żywo
Testowanie funkcjonalne powinno zostać rozszerzone na system na żywo. Jeśli te testy kończą się niepowodzeniem, rozważ wyzwolenie alertów w celu zainicjowania natychmiastowych badań, jeśli to konieczne. Oto kilka przykładów:
Uruchom zaplanowane testy, aby sprawdzić, czy zebrano prawidłową ilość danych, jeśli dane są pozyskiwane zgodnie z ustalonym harmonogramem z oczekiwaną ilością.
Uruchom testy, które wykrywają problemy z danymi, takie jak brakujące wartości lub zduplikowane dane, i przeprowadzaj podstawowe kontrole integralności danych. Jeśli dane zawierają informacje czasowe, które wskazują jego świeżość, te testy mogą sprawdzić te informacje i potencjalnie uniemożliwić procesom podrzędnym korzystanie z nieaktualnych danych.
Sprawdź dostępność zależności zewnętrznych. Na przykład zadanie czyszczenia danych może wywołać inną usługę do wyodrębniania tabel lub przetwarzania wstępnego. Uruchom testy, aby upewnić się, że są dostępne, ponieważ ich niedostępność może mieć wpływ na proces ETL.
Innym sposobem testowania poprawności systemu ETL w środowisku produkcyjnym jest testowanie syntetyczne. Posiadanie znanych danych testowych dostępnych w środowisku produkcyjnym jest wysoce skuteczne. Można go użyć do zweryfikowania kompleksowego przetwarzania, porównując znany stan początkowy z oczekiwanym stanem końcowym dla tych danych. Na przykład dokument jest wymagany do przeprowadzenia analizy dokumentów i zawiera dane osobowe. Wstrzykiwanie syntetycznego dokumentu może przetestować, czy obciążenie wykonuje zadanie manipulowania danymi zgodnie z oczekiwaniami.
Ponadto poeksperymentuj, publikując różne środowiska, znane również jako testowanie A/B, aby nauczyć się z interakcji użytkownika przed pełnym zatwierdzeniem. Testowanie A/B pomaga zapobiegać regresji jakości.
Testowanie danych zebranych podczas pozyskiwania
W ramach procesu pozyskiwania z różnych źródeł danych uwzględnij testy w celu zweryfikowania, czy dane szkoleniowe są zgodne z oczekiwaniami.
Trenowanie modelu uczenia maszynowego z niekompletnymi lub uszkodzonymi danymi może być sprzeczne z produktem. Może to prowadzić do marnotrawstwa wysiłków i spowodować model, który nie dokona znaczących przewidywań. Potoki pozyskiwania i przetwarzania wstępnego danych obejmują testy jakości jako punkty kontrolne. Te testy mogą pomóc w sprawdzeniu, czy dane są zgodne z oczekiwaniami ustawionymi podczas analizy danych i inżynierii cech.
Poniższa lista zawiera kilka przykładowych przypadków testowych:
Testowanie pod kątem kompletności. Przetestuj oczekiwaną ilość danych treningowych, aby zweryfikować kompletność zestawu danych. Ten test zapewnia wystarczającą ilość danych do wytrenowania modelu.
Przetestuj pod kątem informacji krytycznych. Jeśli trenowanie jest oparte na znanych jednostkach, takich jak określone rekordy lub identyfikatory, przetestuj zestaw danych, aby upewnić się, że te jednostki są obecne. Ta walidacja gwarantuje, że nie brakuje informacji krytycznych.
Przetestuj nieistotne dane. Pozyskane dane nie powinny zawierać nieistotnych ani błędnych wpisów. Proces pozyskiwania danych powinien odfiltrować te dane.
Przetestuj pod kątem świeżości. Świeżość pozyskanych danych nie powinna mieć wpływu na moc predykcyjną modelu. Sprawdź, czy dane odzwierciedlają dość aktualne informacje i nie są nieaktualne z poprzednich przebiegów. Jeśli na przykład dane mają zawierać rekordy z ostatniego tygodnia, ale nie ma takich rekordów po zaimportowaniu danych, może to wskazywać na niepowodzenie importu lub problem z świeżością danych w systemie źródłowym.
Przeprowadzanie rutynowych testów
Istotnym problemem z pozyskiwaniem danych jest ilość danych i przepływności. Ciągła ocena podczas operacji jest niezbędna, aby zapobiec wąskim gardłom wydajności. Ta ciągła ocena powinna być częścią procesów operacyjnych, a nie tylko jednorazowego testu. Celem jest zapewnienie, że zespół ds. obciążeń nie przegapi celów poziomu usług.
Rozważ sytuację, w której monitorowanie wskazuje spadek wydajności. Aby wyeliminować takie warunki, przeszacuj i zoptymalizuj procesy ETL. Po wprowadzeniu zmian testy wydajności mogą pomóc w upewnieniu się, że modyfikacje spełniają wymaganą przepływność.
Uwaga
Testowanie i monitorowanie służy różnym celom. Przeprowadź testy w celu oceny potencjalnych zmian w systemie, zwykle przed wdrożeniem zmian. Ciągłe przeprowadzanie monitorowania w celu oceny ogólnej kondycji systemu.
Testowanie przepływu pracy trenowania
Trenowanie modelu przy użyciu kodu niestandardowego, takiego jak skrypty PyTorch, które wykonują rzeczywistą pracę szkoleniową. Te skrypty są uruchamiane na obliczeniach, takich jak w notesach lub zadaniach usługi Azure Machine Learning, które również wymagają zasobów pamięci i sieci. Zalecamy testowanie obciążenia w fazie projektowania w celu oceny potrzeb obliczeniowych i upewnienia się, że proponowane jednostki SKU są odpowiednie. Często potrzebujesz testowania ręcznego, aby określić najlepszą konfigurację, aby efektywnie uruchomić obciążenie w ramach limitu czasu.
Pisanie skryptów przy użyciu wyspecjalizowanych zestawów SDK, które obsługują większość zadań. Jednak ze względu na to, że skrypty są nadal kodem, należy zintegrować testowanie jednostkowe w ramach programowania. Te testy pomagają upewnić się, że podczas aktualizowania zależności nie występują żadne regresje. Jeśli testowanie jednostkowe nie jest możliwe, testowanie ręczne jest konieczne przed wdrożeniem nowego kodu, aby zapobiec regresji jakości.
Te skrypty są uruchamiane w ramach przepływu pracy, takiego jak usługa Azure Machine Learning Studio, która może zapewnić wgląd w czas i czas uruchomienia skryptu. Zalecamy jednak uruchomienie testów integracji, aby upewnić się, że te skrypty są wywoływane niezawodnie.
Ocenianie i testowanie modelu
Uwaga
Ewaluacja i testowanie modelu są często używane zamiennie, ale należy je uznać za oddzielne procesy korzystające z odrębnych zestawów danych. Ocena to działanie iteracyjne wykonywane w fazie opracowywania. Koncentruje się na eksperymentowaniu, aby znaleźć najlepszy model z odpowiednim poziomem dostrajania. Obejmuje ona dostosowywanie hiperparametrów, konfiguracji lub funkcji, a następnie ocenianie modelu na podstawie różnych metryk. Po zidentyfikowaniu najlepszego modelu przeprowadź testy podczas wdrażania.
Testowanie obejmuje weryfikowanie całego systemu, w tym dostosowanego modelu i składników innych niż sztuczna inteligencja, aby sprawdzić, czy działają prawidłowo, dobrze zintegrować i dostarczyć oczekiwane wyniki zgodnie ze standardami jakości. Oceń model w miejscu obok innych składników obciążenia. Proces obejmuje wysyłanie żądań do modelu, ocenianie odpowiedzi oraz podejmowanie decyzji o przejściu lub braku na podstawie danych testowych. Mimo że testowanie jest nienegocjowalne przed produkcją, zalecamy przeprowadzenie testów w środowisku produkcyjnym przy użyciu rzeczywistych danych i danych syntetycznych.
Używanie danych do oceny i testowania
Zazwyczaj istnieją trzy kluczowe zestawy danych podzielone na partycje z danych źródłowych: trenowanie, ewaluacja i testowanie.
Użyj zestawu danych trenowania, który jest zwykle największym podzbiorem, aby wytrenować model. Użyj innego zestawu danych do oceny, aby uściślić model za pomocą procesu iteracyjnego, oceniając różne permutacje. Po znalezieniu zadowalającej permutacji przetestuj ją względem testowego zestawu danych.
Wszystkie zestawy danych powinny zawierać dane wysokiej jakości, aby zminimalizować szum. Przypadki testowe dotyczące pozyskiwania danych i potoków przetwarzania wstępnego mogą służyć jako punkty kontrolne jakości. Brak przykładów może również przypisywać dane o niskiej jakości. Użyj syntetycznych danych, aby zrównoważyć i osiągnąć jednolitość w zestawie danych. Takie podejście jest przydatne w przypadku modeli szkoleniowych, takich jak modele wykrywania oszustw, w których rzeczywiste wystąpienia oszustw są rzadkie, co utrudnia uzyskanie wystarczającej mocy statystycznej dla niezawodnych przewidywań.
Aby uniknąć stronniczości w przewidywaniach, zachowaj różne zestawy danych. Nie należy używać danych treningowych do oceny i nie należy używać danych ewaluacyjnych do testowania. Zarezerwuj unikatowe dane na potrzeby oceny modelu i testowania końcowego.
Korzystanie z metryk oceny
Trenowanie modelu i wybieranie odpowiedniego dla środowiska produkcyjnego jest współzależności procesów. Najpierw musisz wybrać model, ale może ulec zmianie po eksperymentowaniu i ocenie.
Ocena modelu jest zgodna z pętlą eksperymentowania, która ocenia wiele permutacji modeli, parametrów i funkcji przy użyciu metryk. Te metryki zapewniają oceny naukowe, które należy iteracyjnie porównać w różnych wersjach i konfiguracjach, aby określić najlepszy model. Aby uzyskać więcej informacji, zobacz Metryki oceny.
Podobne podejście ma zastosowanie do generowania modeli sztucznej inteligencji. Mają procesy, które oceniają i kwantyfikują wyniki środowiska użytkownika na podstawie wydajności modelu. Na przykład uziemienie jest jedną z kluczowych metryk, które kwantyfikujące, jak dobrze model jest zgodny z danymi źródłowymi. Relevancy to kolejna ważna metryka wskazująca, jak ważna jest odpowiedź na zapytanie. Na przykład metryki można znaleźć w temacie Evaluation and monitoring metrics for generative AI (Metryki oceny i monitorowania dla generowania sztucznej inteligencji).
Ocenianie różnych typów modeli przy użyciu różnych metryk. Znaczenie każdej metryki może się różnić w zależności od scenariusza. Określanie priorytetów metryk na podstawie przypadku użycia. Na przykład sprawiedliwość ma kluczowe znaczenie w zakresie odpowiedzialnej sztucznej inteligencji. Pomimo dobrych testów modele mogą nadal wykazywać nieuczciwą stronniczość z powodu stronniczych danych źródłowych. Wyniki mogą być wysokie w trafności, ale niskie w sprawiedliwości. Integrowanie ocen sprawiedliwości z procesem w celu zapewnienia wyników bezstronnych.
Generowanie sztucznej inteligencji integruje się z kodem orkiestracji, logiką routingu i indeksem do generowania rozszerzonego pobierania (RAG), co komplikuje ocenę. Chociaż należy oceniać modele indywidualnie przy użyciu metryk, ważne jest również, aby ocenić inne składniki systemu.
Testowanie modelu
Dostrajanie jest zasadniczo testowane, ponieważ modyfikuje wstępnie wytrenowany model w celu zmiany jego zachowania. Wymaga to od punktu odniesienia, aby zrozumieć początkową wydajność modelu. Po dostrojeniu należy ponownie sprawdzić wydajność modelu, aby upewnić się, że spełnia ona standardy jakości. Rozważ następujące typowe metryki oceny:
Uziemienie odnosi się do dopasowania modelu do danych źródłowych. Model uziemiony generuje odpowiedzi zgodne z rzeczywistością.
Relevancy wskazuje, jak istotne jest odpowiedź na podane pytanie. Bardzo uziemiona odpowiedź może nie mieć trafności, jeśli nie rozwiąże pytania bezpośrednio.
Podobieństwo mierzy podobieństwo między tekstem danych źródłowych a wygenerowaną odpowiedzią. Czy model używał precyzyjnego sformułowania? Brak ładu redakcyjnego może obniżyć wynik podobieństwa.
Pobieranie wskazuje skuteczność zapytań indeksu. Oceń, jak dobrze pobrane dane indeksu są zgodne z pytaniem. Nieistotne dane z wyszukiwania indeksu obniżają ten wynik. Wyższe wyniki pobierania wskazują na niższą zmienność, ponieważ opierają się wyłącznie na zapytaniach indeksu.
Płynność odnosi się do użycia słownictwa. Jeśli model jest zgodny z przewodnikiem stylu i prezentuje zawartość w odpowiednim formacie, może być płynny, nawet jeśli brakuje uziemienia lub trafności.
Spójność ocenia, czy mowa modelu przepływa naturalnie i spójnie. Ocenia, czy rozmowa czuje się jak prawdziwa wymiana.
Testowanie hiperparametrów
Parametry modelu zależą od decyzji projektowych specyficznych dla aplikacji. W ramach projektu aplikacji wybierz model i parametry na podstawie przypadków użycia obciążenia. Proces testowania ma iteracyjną pętlę wewnętrzną, w której dane treningowe są porównywane z danymi testowym w celu sprawdzenia, czy model jest trenowany na zamierzonym zestawie danych. Ponadto parametry są dostrojone tak, aby model mógł przewidywać z akceptowalnym poziomem dokładności.
Kompromis. Pętla wewnętrzna obejmuje koszty obliczeniowe trenowania modelu i koszt oceny go za pomocą testów. Należy uwzględnić czas wymagany przez trenowanie i testowanie modelu w tej pętli. Spodziewaj się, że proces testowania będzie trwać dłużej niż proces trenowania. Możesz przeprowadzić wstępne testowanie na podzestawie danych treningowych, aby ocenić, czy model generuje rozsądne wyniki. Możesz stopniowo skalować w górę zestaw testów do pełnego zestawu danych.
Testowanie punktu końcowego wnioskowania
Punkt końcowy wnioskowania to interfejs API REST, który umożliwia dostęp do modeli do tworzenia przewidywań. Jest to interfejs, w którym wysyłasz dane w ramach żądania i otrzymujesz odpowiedź zawierającą wyniki z modelu. Punkt końcowy jest hostowany na obliczeniach, które mogą być paaS, takie jak Azure OpenAI Service lub serwer wnioskowania firmy innej niż Microsoft, taki jak NVIDIA Triton Inference Server, TorchServe i BentoML. W scenariuszach PaaS dostawca usług obsługuje testowanie w określonym zakresie. Jeśli jednak hostujesz punkt końcowy, traktuj go jak każdy inny interfejs API i dokładnie przetestuj go.
Mimo że testujesz model podczas trenowania i oceny, testowanie punktu końcowego wnioskowania obejmuje zapewnienie, że mechanizmy wokół tego modelu, takie jak przetwarzanie żądań, tworzenie odpowiedzi, skalowanie i koordynacja między wystąpieniami, działają prawidłowo. Utwórz kompleksowy plan testowania, który obejmuje przypadki użycia na podstawie wymagań. W tej sekcji opisano przykładowe przypadki testowe i typy testów do rozważenia.
Zagadnienia dotyczące testowania dla serwerów hostingu wnioskowania
Ważne jest, aby zrozumieć charakterystykę obciążenia zasobów obliczeniowych i zweryfikować wydajność poprzez testowanie obciążenia. Te akcje ułatwiają wybór technologii podczas projektowania lub optymalizowania architektury. Na przykład różne serwery wnioskowania mają różne cechy wydajności. Kod zużywa cykle procesora CPU i pamięć w miarę wzrostu liczby połączeń współbieżnych. Dowiedz się, jak kod i zasoby obliczeniowe działają w standardowych i szczytowych warunkach obciążenia. Testowanie obciążenia platformy Azure jest dobrym rozwiązaniem do testowania obciążenia i może generować duże obciążenie. Inne opcje typu open source, takie jak Apache JMeter, są również popularne. Rozważ wywołanie tych testów bezpośrednio ze środowiska. Na przykład usługa Machine Learning dobrze integruje się z testowaniem obciążenia.
Kolejną kluczową decyzją jest wybór możliwości procesora GPU. Wiele modeli wymaga procesorów GPU do efektywnego wnioskowania ze względu na ich projekt. Testowanie obciążenia pomaga zrozumieć limity wydajności jednostki SKU procesora GPU i zapobiega nadmiernej aprowizacji, które są istotnymi zagadnieniami finansowymi.
W przypadku platform hostingu innych niż PaaS zabezpieczenia mają kluczowe znaczenie, ponieważ interfejs API jest publicznie udostępniany. Ważne jest, aby upewnić się, że punkt końcowy nie jest wykorzystywany lub naruszony, co może zagrozić całemu systemowi. Uwzględnij ten punkt końcowy w ramach rutynowego testowania zabezpieczeń wraz z innymi publicznymi punktami końcowymi. Rozważ przeprowadzenie testów, takich jak testy penetracyjne, w systemie na żywo. Innym aspektem bezpieczeństwa jest bezpieczeństwo zawartości. Kod może wywoływać wyspecjalizowane interfejsy API, które wykrywają szkodliwą zawartość w ładunku żądania i odpowiedzi. Bezpieczeństwo zawartości usługi Azure AI można wywołać z testowania w celu ułatwienia testowania zawartości.
Aby zapoznać się z kluczowymi strategiami, zobacz Zalecenia dotyczące testowania zabezpieczeń.
Zagadnienia dotyczące testowania punktów końcowych wnioskowania paaS
Klient powinien oczekiwać błędów podczas wysyłania żądań do punktu końcowego wnioskowania w usłudze PaaS. Błędy mogą wystąpić z powodu przeciążenia systemu, braku odpowiedzi zaplecza i innych warunków błędu. Przeprowadź analizę trybu awarii w usłudze i przetestuj te potencjalne awarie. Analiza trybu awarii jest wymagana do projektowania i implementowania strategii ograniczania ryzyka w kodzie klienta. Na przykład interfejsy API usługi Azure OpenAI ograniczają żądania, zwracając kod odpowiedzi http 429 o błędzie. Klient powinien obsługiwać ten błąd przy użyciu mechanizmów ponawiania prób i wyłączników. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące przeprowadzania analizy trybu awarii.
Testowanie usług PaaS może pomóc w wyborze jednostek SKU usługi, ponieważ rozumiesz powiązane koszty, takie jak płatność zgodnie z rzeczywistym użyciem lub wstępnie aprowidowane zasoby obliczeniowe. Kalkulatory cen platformy Azure umożliwiają ocenę obciążeń, częstotliwości i użycia tokenów w celu określenia najlepszych opcji rozliczeń i obliczeń. Symulowanie obciążeń przy użyciu jednostek SKU o niskich kosztach i uzasadnianie opcji wysokiej klasy, takich jak aprowizowanie jednostek przepływności (PTU) dla usługi Azure OpenAI.
Testowanie obciążenia nie jest tak istotne w przypadku obliczeń z płatnością zgodnie z rzeczywistym użyciem, ponieważ z nieskończoną pojemnością nie występują problemy. Testowanie weryfikuje limity i limity przydziału. Nie zalecamy testowania obciążenia dla obliczeń z płatnością zgodnie z rzeczywistym użyciem, ponieważ jest to znaczący koszt finansowy. Jednak należy przeprowadzić test obciążeniowy, aby zweryfikować przepływność mierzoną w tokenach na minutę lub żądania na minutę. W przeciwieństwie do standardowych interfejsów API, które uwzględniają metryki, takie jak rozmiar żądania, to podejście ocenia obciążenia na podstawie tokenów w celu określenia użycia. Kluczem jest zrozumienie liczby aktywnych użytkowników i odpowiednie mierzenie przepływności. Aby uzyskać więcej informacji, zobacz Mierzenie przepływności.
Korzystanie z mechanizmów kontroli zabezpieczeń
Niezależnie od tego, czy używasz serwera wnioskowania, czy opcji PaaS, bezpieczeństwo jest Twoim zadaniem. W przypadku punktów końcowych interfejsu API kluczowe jest przetestowanie pod kątem mechanizmów kontroli bezpieczeństwa zabezpieczeń systemu i zdjęć zawartości. Upewnij się, że tych kontrolek nie można pominąć i działają zgodnie z oczekiwaniami. Na przykład wysłanie znanego zablokowanego elementu może pomóc w sprawdzeniu, czy mechanizmy kontroli zabezpieczeń są uruchomione i działają prawidłowo przed wdrożeniem. Rozważ uruchomienie tych testów zgodnie z potrzebami lub zintegrowanie ich z procesem wydania.
Ważne jest, aby sprawdzić, czy system może przypadkowo uwidocznić informacje, których nie powinien. Na przykład system nie powinien ujawniać danych osobowych w ładunku odpowiedzi. Ponadto przetestuj, aby upewnić się, że klient nie może uzyskać dostępu do punktów końcowych przeznaczonych dla innych tożsamości. Przeprowadź testy zabezpieczeń, aby sprawdzić, czy interfejs API z jego mechanizmami uwierzytelniania i autoryzacji nie wycieka poufnych informacji i utrzymuje właściwą segmentację użytkowników.
Testowanie danych uziemienia
Projekt danych wpływa na wydajność modelu generowania, a dane uziemienia są kluczowym składnikiem. Dane uziemienia zapewniają więcej kontekstu w celu zwiększenia istotności odpowiedzi. Jest indeksowany przed dotarciem do modelu. Ten indeks jest dostępny w czasie rzeczywistym, gdy użytkownik czeka na odpowiedź.
Przeprowadź kompleksowe testowanie i uwzględnij ten proces w ramach projektowania danych. Zaimplementuj proces testowania, który ocenia i kwantyfikuje wyniki środowiska klienta na podstawie wydajności, orkiestracji, indeksowania, przetwarzania wstępnego i danych źródłowych modelu. Monitorowanie i mierzenie iteracyjnych metryk jakości. Oto kilka zagadnień:
Dokładnie przetestuj przetwarzanie danych przy użyciu testów funkcjonalnych i integracyjnych. Sprawdź, czy dane są ładowane zgodnie z oczekiwaniami i czy wszystkie dane są obecne.
Przetestuj schemat indeksu pod kątem zgodności z poprzednimi wersjami. Należy przetestować wszelkie zmiany w dokumencie lub polu, aby upewnić się, że nowa wersja może nadal obsługiwać poprzednie wersje danych.
Przed zaindeksowaniem danych następuje przygotowanie w celu zmniejszenia szumu i stronniczość oraz umożliwienia wydajnego wykonywania zapytań. Ten proces obejmuje wstępne przetwarzanie, fragmentowanie i obliczanie osadzania, a każdy krok zapisuje dane w kontekście lub plikach w indeksie. Potok aranżacji, taki jak zestawy umiejętności udostępniane przez usługę Azure AI Search, przeprowadza te kroki. Należy przetestować kod aranżacji, aby upewnić się, że żadne kroki nie zostały pominięte, a przetworzone dane są wysokiej jakości.
Testy powinny sprawdzać stare dane, wartości syntetyczne, puste tabele, odświeżanie danych i przetwarzanie w najnowszej wersji. Jeśli wystąpią błędy testu, może być konieczne dostosowanie zapytania wyszukiwania i indeksu. Ten proces obejmuje dostosowywanie filtrów i innych omówionych wcześniej elementów. Testowanie należy traktować jako działanie iteracyjne.
Indeksy są złożone, a wydajność zapytań może się różnić w zależności od struktury indeksu, co wymaga oszacowania obciążenia. Prawidłowe testowanie obciążenia może pomóc w określeniu różnych jednostek SKU magazynu, zasobów obliczeniowych i innych zasobów, które są dostępne do obsługi wymagań.
Należy przetestować wszystkie mechanizmy kontroli zabezpieczeń. Na przykład dane mogą być podzielone na oddzielne dokumenty. Każda partycja ma kontrolę dostępu. Należy właściwie przetestować te mechanizmy kontroli, aby chronić poufność.
Testowanie orkiestratora
Kluczowym składnikiem aplikacji RAG jest centralny orkiestrator. Ten kod koordynuje różne zadania związane z początkowym pytaniem użytkownika. Zadania programu Orchestrator zwykle wymagają zrozumienia intencji użytkownika, połączenia z indeksem w celu wyszukania danych uziemienia i wywołania punktu końcowego wnioskowania. Jeśli agenci muszą wykonywać zadania, takie jak wywoływanie interfejsów API REST, ten kod obsługuje te zadania w kontekście.
Możesz opracować kod orkiestracji w dowolnym języku lub napisać go od podstaw. Zalecamy jednak korzystanie z technologii takich jak przepływ monitów w programie Azure AI Studio lub kierowanych grafach Acyklicznych (DAG) platformy Apache Airflow w celu przyspieszenia i uproszczenia procesu programowania. Przepływ monitów zapewnia środowisko czasu projektowania. Służy do modularyzacji zadań jako jednostek i łączenia danych wejściowych i wyjściowych każdej lekcji, ostatecznie tworząc kod aranżacji, który reprezentuje cały proces.
Izolowanie kodu orkiestracji. Utwórz ją oddzielnie i wdróż ją jako mikrousługę z punktem końcowym online i interfejsem API REST w celu uzyskania dostępu. Takie podejście zapewnia modułowość i łatwość wdrażania.
Z perspektywy testowania należy traktować ten kod jak każdy inny kod i przeprowadzać testy jednostkowe. Jednak ważniejszym aspektem jest jego funkcjonalność, taka jak logika routingu, którą można zweryfikować za pomocą testowania funkcjonalnego i integracji. Przetestuj inżynierię monitu, aby upewnić się, że kod może wykrywać intencję użytkownika i odpowiednio kierować wywołania. Istnieje kilka struktur i bibliotek do testowania, takich jak Scikit-learn, moduł torch.testing PyTorch, FairML na potrzeby testowania stronniczości i sprawiedliwości oraz Analiza modelu TensorFlow na potrzeby oceny modelu.
Ponadto przeprowadź testy środowiska uruchomieniowego, takie jak testowanie trybu awarii. Na przykład przetestuj potencjalne błędy związane z ograniczeniami tokenu.
Niektóre testy środowiska uruchomieniowego mogą pomóc w podjęciu decyzji. Uruchom testy obciążeniowe , aby zrozumieć, jak ten kod zachowuje się pod obciążeniem i użyj wyników planowania pojemności. Ponieważ ten kod jest umieszczony w kluczowym momencie architektury, w której musi dotrzeć do innych usług, może pomóc w zbieraniu danych telemetrycznych ze wszystkich tych wywołań. Te dane mogą zapewnić wgląd w ilość czasu poświęcanego na przetwarzanie lokalne w porównaniu z wywołaniami sieciowymi i określić zachowanie innych składników, takich jak potencjalne opóźnienie. Technologie takie jak przepływ monitów mają wbudowane funkcje telemetryczne ułatwiające ten proces. W przeciwnym razie uwzględnij dane telemetryczne w kodzie niestandardowym.
Uwaga
Testowanie tego kodu ma wpływ na koszty. Jeśli na przykład używasz usługi Azure OpenAI do hostowania punktu końcowego wnioskowania, testowanie obciążenia jest powszechną praktyką, która może pomóc w ustaleniu limitów systemu. Jednak opłaty za usługę Azure OpenAI są naliczane za każde wywołanie, co może sprawić, że rozbudowane testy obciążeniowe będą kosztowne. Jednym ze sposobów optymalizacji opłat jest użycie nieużywanych jednostek PTU usługi Azure OpenAI w środowisku testowym. Alternatywnie możesz symulować punkt końcowy wnioskowania.
Obawy dotyczące zabezpieczeń dotyczą zarówno kodu orkiestracji, jak i modelu. Obejmuje testowanie jailbreakingu, gdzie celem jest przerwanie zabezpieczeń modelu. Osoby atakujące nie wchodzą w bezpośrednią interakcję z modelem. Najpierw wchodzą w interakcje z kodem orkiestracji. Kod orkiestracji odbiera żądania użytkownika i analizuje je. Jeśli kod orkiestracji odbiera złośliwe żądanie, może przekazać to żądanie do modelu i potencjalnie naruszyć bezpieczeństwo modelu.
Bezpieczeństwo zawartości jest kolejnym ważnym aspektem. W aplikacji chatbot kod orkiestracji odbiera tekst czatu. W kodzie rozważ wywołanie usługi bezpieczeństwa zawartości. Wyślij zarówno monit użytkownika, jak i kontekst uziemienia do analizy i uzyskaj ocenę ryzyka. Prompt Shields to ujednolicony interfejs API, który analizuje duże dane wejściowe modelu językowego i wykrywa ataki typu monit użytkownika i ataki dokumentów, które są dwoma typowymi typami niepożądanych danych wejściowych.
Kontrola zabezpieczeń i uwierzytelnianie mają kluczowe znaczenie dla punktu końcowego RESTful. Musisz zarządzać uwierzytelnianiem i zapewnić dokładne testowanie.
Zapobieganie rozpadowi modelu
Typowym problemem dla wszystkich modeli jest pewien stopień pogorszenia w czasie. Zmiany, które są wewnętrzne i zewnętrzne dla obciążenia, ostatecznie powodują obniżenie jakości modelu i jego danych wyjściowych. Rozkład modelu występuje na dwa sposoby:
Dryf danych występuje po zmianie danych wejściowych. Nowe dane wejściowe sprawiają, że wytrenowany model jest nieaktualny. Na przykład może istnieć model, który przewiduje wzorce głosowania określonego obszaru geograficznego, na przykład okręgu. Jeśli dzielnica zostanie ponownie wyrysowana, a dane demograficzne populacji tego okręgu zmienią się, model musi zostać zaktualizowany, aby uwzględnić zmiany.
Dryf koncepcji występuje, gdy warunki zewnętrzne dla obciążenia i modelu zmieniają się w taki sposób, że dane wyjściowe modelu nie są już zgodne z rzeczywistością. Na przykład może istnieć model prognozy sprzedaży dla produktu technologicznego. Jeśli konkurent nieoczekiwanie wprowadza bardziej zaawansowany konkurencyjny produkt, który zwraca znaczną uwagę opinii publicznej, musisz zaktualizować model w zależności od tego, jak zmieniają się trendy konsumentów.
Jeśli to możliwe, użyj zautomatyzowanego testowania, aby wykryć i ocenić rozkład modelu w cyklu życia modelu. Jeśli model przewiduje wartości dyskretne, możesz utworzyć testy, aby ocenić przewidywania względem tych wartości w czasie i zmierzyć odchylenie między oczekiwanymi i rzeczywistymi wynikami. Uzupełnij to testowanie, aby wykrywać dryf w czasie, porównując statystyki podsumowania i metryki odległości.
Innym typowym podejściem do identyfikowania rozkładu modelu jest opinia użytkowników. Przykładem opinii użytkowników jest mechanizm odpowiedzi kciuk w górę lub kciuk w dół. Śledzenie pozytywnych i negatywnych opinii w miarę upływu czasu i tworzenie alertu w przypadku osiągnięcia negatywnego progu opinii może pomóc w zbadaniu jakości modelu.
Niezależnie od sygnałów używanych do identyfikowania rozpadu modelu, zespół operacyjny, który jest powiadamiany o potencjalnym rozpadzie, musi zaangażować analityka danych do badania sygnału i określić, czy rozkład się dzieje, a także główną przyczynę.
Implementowanie narzędzi
Moduł zbierający dane usługi Azure Machine Learning umożliwia rejestrowanie danych wejściowych i wyjściowych w czasie rzeczywistym z modeli wdrożonych w zarządzanych punktach końcowych online lub punktach końcowych online platformy Kubernetes. Usługa Machine Learning przechowuje zarejestrowane dane wnioskowania w usłudze Azure Blob Storage. Następnie możesz użyć tych danych do monitorowania, debugowania lub inspekcji modelu, co zapewnia wgląd w wydajność wdrożonych modeli. Jeśli wdrożysz model poza usługą Machine Learning lub w punkcie końcowym usługi Machine Learning wsadowym, nie możesz korzystać z modułu zbierającego dane i nie trzeba wykonywać operacji innego procesu zbierania danych.
Monitorowanie modelu uczenia maszynowego służy do implementowania monitorowania. Usługa Machine Learning uzyskuje sygnały monitorowania, wykonując obliczenia statystyczne na strumieniowych danych wnioskowania produkcyjnego i danych referencyjnych. Dane referencyjne mogą być danymi historycznymi trenowania, danymi walidacji lub danymi prawdy podstawowej. Z drugiej strony dane wnioskowania produkcyjnego odnoszą się do danych wejściowych i wyjściowych modelu zebranych w środowisku produkcyjnym.
- Zobacz Monitorowanie modelu uczenia maszynowego, aby dowiedzieć się więcej na temat możliwości monitorowania usługi Machine Learning oraz metryk , które przechwytuje i analizuje.
- Zobacz najlepsze rozwiązania, aby uzyskać więcej zaleceń dotyczących monitorowania.