Udostępnij za pośrednictwem

Testowanie dla metodyki DevOps usługi LUIS

  • Artykuł

Ważne

Usługa LUIS zostanie wycofana 1 października 2025 r. i od 1 kwietnia 2023 r. nie będzie można utworzyć nowych zasobów usługi LUIS. Zalecamy migrację aplikacji LUIS do interpretacji języka konwersacyjnego, aby korzystać z ciągłej pomocy technicznej i wielojęzycznych możliwości produktów.

Inżynierowie oprogramowania, którzy opracowują aplikację Usługi Language Understanding (LUIS), mogą stosować rozwiązania DevOps dotyczące kontroli źródła, zautomatyzowanych kompilacji, testowania i zarządzania wydaniami , postępując zgodnie z tymi wytycznymi.

W metodologiach tworzenia oprogramowania agile testowanie odgrywa integralną rolę w tworzeniu oprogramowania wysokiej jakości. Każda znacząca zmiana aplikacji LUIS powinna towarzyszyć testom zaprojektowanym w celu przetestowania nowych funkcji, które deweloper tworzy w aplikacji. Te testy są sprawdzane w repozytorium kodu źródłowego wraz ze .lu źródłem aplikacji LUIS. Implementacja zmiany jest zakończona po spełnieniu testów przez aplikację.

Testy są krytyczną częścią przepływów pracy ciągłej integracji/ciągłego wdrażania. Gdy zmiany w aplikacji usługi LUIS są proponowane w żądaniu ściągnięcia lub po scaleniu zmian z gałęzią główną, przepływy pracy ciągłej integracji powinny uruchamiać testy, aby sprawdzić, czy aktualizacje nie spowodowały żadnych regresji.

Jak wykonywać testy jednostkowe i testowanie wsadowe

Istnieją dwa różne rodzaje testów dla aplikacji usługi LUIS, które należy wykonać w przepływach pracy ciągłej integracji:

  • Testy jednostkowe — stosunkowo proste testy, które weryfikują kluczowe funkcje aplikacji LUIS. Test jednostkowy przechodzi, gdy oczekiwana intencja i oczekiwane jednostki są zwracane dla danej wypowiedzi testowej. Aby przebieg testu zakończył się pomyślnie, wszystkie testy jednostkowe muszą zostać zakończone pomyślnie.
    Ten rodzaj testowania jest podobny do testowania interakcyjnego, które można wykonać w portalu usługi LUIS.

  • Testy wsadowe — testowanie wsadowe to kompleksowy test dla bieżącego wytrenowanego modelu w celu pomiaru wydajności. W przeciwieństwie do testów jednostkowych testowanie wsadowe nie jest testem wsadowym| nie kończy się niepowodzeniem. Oczekiwania dotyczące testowania wsadowego nie polegają na tym, że każdy test zwróci oczekiwaną intencję i oczekiwane jednostki. Zamiast tego test wsadowy ułatwia wyświetlanie dokładności każdej intencji i jednostki w aplikacji oraz ułatwia porównywanie w miarę wprowadzania ulepszeń.
    Ten rodzaj testowania jest taki sam jak testowanie usługi Batch, które można wykonać interaktywnie w portalu usługi LUIS.

Możesz stosować testy jednostkowe od początku projektu. Testowanie wsadowe jest naprawdę wartością tylko po utworzeniu schematu aplikacji LUIS i nad ulepszeniem jego dokładności.

W przypadku testów jednostkowych i testów wsadowych upewnij się, że wypowiedzi testowe są oddzielone od wypowiedzi treningowych. Jeśli przetestujesz te same dane, które trenujesz, uzyskasz fałszywe wrażenie, że aplikacja działa dobrze, gdy po prostu przesiąknie do danych testowych. Testy muszą być niezauznane przez model, aby sprawdzić, jak dobrze jest uogólniać.

Pisanie testów

Podczas pisania zestawu testów dla każdego testu należy zdefiniować:

  • Testowanie wypowiedzi
  • Oczekiwana intencja
  • Oczekiwane jednostki.

Użyj składni pliku wsadowego usługi LUIS, aby zdefiniować grupę testów w pliku w formacie JSON. Na przykład:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

Niektóre narzędzia testowe, takie jak NLU. Metodyka DevOps obsługuje również pliki testowe w formacie LUDown.

Projektowanie testów jednostkowych

Testy jednostkowe powinny być przeznaczone do testowania podstawowych funkcji aplikacji LUIS. W każdej iteracji lub przebiegu tworzenia aplikacji należy napisać wystarczającą liczbę testów, aby sprawdzić, czy kluczowe funkcje implementowane w iteracji działają prawidłowo.

W każdym teście jednostkowym dla danej wypowiedzi testowej można wykonywać następujące czynności:

  • Przetestuj, czy zwracana jest prawidłowa intencja
  • Przetestuj, czy zwracane są jednostki "klucz" — te, które mają kluczowe znaczenie dla twojego rozwiązania.
  • Przetestuj , czy wynik przewidywania dla intencji i jednostek przekracza zdefiniowany próg. Możesz na przykład zdecydować, że należy wziąć pod uwagę, że test przeszedł tylko wtedy, gdy wynik przewidywania dla intencji i dla jednostek kluczowych przekracza 0,75.

W testach jednostkowych dobrym pomysłem jest przetestowanie, czy kluczowe jednostki zostały zwrócone w odpowiedzi przewidywania, ale zignorować wszystkie wyniki fałszywie dodatnie. Wyniki fałszywie dodatnie to jednostki znalezione w odpowiedzi przewidywania, ale które nie są zdefiniowane w oczekiwanych wynikach testu. Ignorując wyniki fałszywie dodatnie, sprawia, że tworzenie testów jednostkowych jest mniej uciążliwe, a jednocześnie pozwala skoncentrować się na testowaniu, że dane, które są kluczem do rozwiązania, są zwracane w odpowiedzi przewidywania.

Napiwek

NlU . Narzędzie DevOps obsługuje wszystkie potrzeby testowe usługi LUIS. Polecenie compare używane w trybie testu jednostkowego potwierdzi, że wszystkie testy kończą się powodzeniem i zignoruje wyniki fałszywie dodatnie dla jednostek, które nie są oznaczone w oczekiwanych wynikach.

Projektowanie testów wsadowych

Zestawy testów wsadowych powinny zawierać dużą liczbę przypadków testowych przeznaczonych do testowania we wszystkich intencjach i wszystkich jednostkach w aplikacji usługi LUIS. Aby uzyskać informacje na temat definiowania zestawu testów wsadowych, zobacz Testowanie wsadowe w portalu usługi LUIS.

Uruchamianie testów

Portal usługi LUIS oferuje funkcje ułatwiające testowanie interakcyjne:

  • Testowanie interakcyjne umożliwia przesłanie przykładowej wypowiedzi i uzyskanie odpowiedzi na rozpoznane intencje i jednostki usługi LUIS. Sprawdzisz powodzenie testu przez inspekcję wizualną.

  • Testowanie wsadowe używa pliku testowego wsadowego jako danych wejściowych w celu zweryfikowania aktywnej wytrenowanego wersji w celu pomiaru dokładności przewidywania. Test wsadowy pomaga wyświetlić dokładność każdej intencji i jednostki w aktywnej wersji, wyświetlając wyniki na wykresie.

Uruchamianie testów w zautomatyzowanym przepływie pracy kompilacji

Funkcje testowania interakcyjnego w portalu usługi LUIS są przydatne, ale w przypadku metodyki DevOps zautomatyzowane testowanie wykonywane w przepływie pracy ciągłej integracji/ciągłego wdrażania ma pewne wymagania:

  • Narzędzia testowe muszą być uruchamiane w kroku przepływu pracy na serwerze kompilacji. Oznacza to, że narzędzia muszą być uruchamiane w wierszu polecenia.
  • Narzędzia testowe muszą być w stanie wykonać grupę testów względem punktu końcowego i automatycznie zweryfikować oczekiwane wyniki względem rzeczywistych wyników.
  • Jeśli testy kończą się niepowodzeniem, narzędzia testowe muszą zwrócić kod stanu, aby zatrzymać przepływ pracy i "zakończyć kompilację niepowodzeniem".

Usługa LUIS nie oferuje narzędzia wiersza polecenia ani interfejsu API wysokiego poziomu, który oferuje te funkcje. Zalecamy użycie nlu . Narzędzie DevOps do uruchamiania testów i weryfikowania wyników zarówno w wierszu polecenia, jak i podczas testowania automatycznego w przepływie pracy ciągłej integracji/ciągłego wdrażania.

Możliwości testowania, które są dostępne w portalu usługi LUIS, nie wymagają opublikowanego punktu końcowego i są częścią możliwości tworzenia usługi LUIS. Podczas implementowania testowania w zautomatyzowanym przepływie pracy kompilacji należy opublikować wersję aplikacji LUIS, która ma zostać przetestowana w punkcie końcowym, tak aby narzędzia testowe, takie jak NLU. Metodyka DevOps może wysyłać żądania przewidywania w ramach testowania.

Napiwek

  • Jeśli wdrażasz własne rozwiązanie do testowania i piszesz kod służący do wysyłania wypowiedzi testowych do punktu końcowego, pamiętaj, że jeśli używasz klucza tworzenia usługi LUIS, dozwolona szybkość transakcji jest ograniczona do 5TPS. Ogranicz szybkość wysyłania lub zamiast tego użyj klucza przewidywania.
  • Podczas wysyłania zapytań testowych do punktu końcowego należy pamiętać o użyciu log=false w ciągu zapytania żądania przewidywania. Gwarantuje to, że wypowiedzi testowe nie są rejestrowane przez usługę LUIS i znajdują się na liście przeglądów wypowiedzi punktów końcowych prezentowanych przez funkcję uczenia aktywnego usługi LUIS i w związku z tym przypadkowo zostaną dodane do wypowiedzi szkoleniowych aplikacji.

Uruchamianie testów jednostkowych w wierszu polecenia i przepływach pracy ciągłej integracji/ciągłego wdrażania

Możesz użyć nlu . Pakiet DevOps do uruchamiania testów w wierszu polecenia:

  • Użyj nlu. Polecenie testowe DevOps umożliwiające przesyłanie testów z pliku testowego do punktu końcowego i przechwytywanie rzeczywistych wyników przewidywania w pliku.
  • Użyj nlu. Polecenie porównania metodyki DevOps umożliwia porównanie rzeczywistych wyników z oczekiwanymi wynikami zdefiniowanymi w pliku testu wejściowego. Polecenie compare generuje dane wyjściowe testu NUnit, a gdy jest używany w trybie testu jednostkowego przy użyciu --unit-test flagi, potwierdzi, że wszystkie testy przechodzą pomyślnie.

Uruchamianie testów usługi Batch w wierszu polecenia i przepływach pracy ciągłej integracji/ciągłego wdrażania

Możesz również użyć nlu. Pakiet DevOps do uruchamiania testów wsadowych w wierszu polecenia.

  • Użyj nlu. Polecenie testowe DevOps umożliwiające przesyłanie testów z pliku testowego do punktu końcowego i przechwytywanie rzeczywistych wyników przewidywania w pliku, tak samo jak w przypadku testów jednostkowych.
  • Użyj nlu. DevOps compare command in Performance test mode to measure the performance the performance of your app (Porównanie polecenia metodyki DevOps w trybie testu wydajności wydajności wydajności) w celu mierzenia wydajności aplikacji, na przykład wyników z najnowszego zatwierdzenia do wersji głównej lub bieżącej wersji. W trybie testu wydajnościowego compare polecenie generuje dane wyjściowe testu NUnit i wyniki testu wsadowego w formacie JSON.

Trenowanie niedeterministyczne usługi LUIS i wpływ na testowanie

Gdy usługa LUIS szkoli model, taki jak intencja, potrzebuje zarówno pozytywnych danych — oznaczonych etykietami wypowiedzi treningowych, które zostały dostarczone do trenowania aplikacji dla modelu — i danych negatywnych — danych, które nie są prawidłowymi przykładami użycia tego modelu. Podczas trenowania usługa LUIS tworzy negatywne dane jednego modelu ze wszystkich pozytywnych danych dostarczonych dla innych modeli, ale w niektórych przypadkach, które mogą powodować nierównowagę danych. Aby uniknąć tej nierównowagi, usługa LUIS próbkuje podzbiór negatywnych danych w sposób niedeterministyczny, aby zoptymalizować pod kątem lepszego zestawu treningowego o zrównoważonym stanie, poprawić wydajność modelu i krótszy czas trenowania.

Wynikiem tego niedeterministycznego trenowania jest to, że możesz uzyskać nieco inną odpowiedź przewidywania między różnymi sesjami treningowymi, zwykle w przypadku intencji i/lub jednostek, w których wynik przewidywania nie jest wysoki.

Jeśli chcesz wyłączyć trenowanie niedeterministyczne dla tych wersji aplikacji usługi LUIS, które tworzysz na potrzeby testowania, użyj interfejsu API ustawień wersji z UseAllTrainingData ustawieniem ustawionym na true.

Następne kroki