Testowanie agentów AI: przypadki, regresja i symulacja

Testowanie agentów AI to sposób, w jaki zespół obsługi udowadnia, że agent AI nadal zachowuje się prawidłowo, zanim zmiana dotrze do klientów. Przypadki testowe buduje się z prawdziwych rozwiązanych rozmów i dawnych błędów, uruchamia je ponownie przed każdą zmianą promptu, zasad, wiedzy lub modelu, symuluje trudnych klientów, sprawdza działania podjęte przez agenta i wdraża zmianę dopiero wtedy, gdy spełni spisany próg wydania.

W skrócie

• Agent, który podejmuje działania, potrzebuje testów tego, co zrobił (zlecony zwrot, przestrzegany limit, przekazana sprawa), a nie tylko tego, co powiedział.
• Najlepsze przypadki testowe pochodzą z własnych rozwiązanych rozmów i dawnych błędów.
• Cały zestaw regresyjny należy uruchomić ponownie przed każdą zmianą promptu, zasad, wiedzy, modelu lub narzędzi.
• Każdy przypadek krytyczny warto uruchomić kilka razy: agent, który przeszedł test raz, może nie przejść tego samego przypadku przy kolejnym uruchomieniu.
• Próg wydania trzeba spisać przed uruchomieniem testów, żeby nikt nie dyskutował o progach po zobaczeniu wyników.

Ten przewodnik to część dotycząca etapu przed wydaniem w naszym szerszym przewodniku po ewaluacji agentów AI.

Czym jest testowanie agentów AI i czym różni się od testowania chatbota?

Testowanie agentów AI sprawdza agenta, który rozumuje przez wiele tur i podejmuje działania w Państwa systemach, takie jak zlecanie zwrotów, zmiana zamówień czy aktualizacja kont. Testowanie chatbota sprawdza głównie odpowiedzi i przepływy rozmowy. Różnica tkwi w konsekwencjach: błędna odpowiedź chatbota wprowadza w błąd jednego klienta, a błędne działanie agenta zmienia prawdziwe rekordy.

Jeśli Państwa bot tylko odpowiada i przekazuje rozmowy, proszę zajrzeć do artykułu o testowaniu chatbota. Ten artykuł opisuje, co się zmienia, gdy agent może działać.

Najtrudniejsza jest spójność. W badaniu τ-bench, w którym model językowy odgrywa klienta, a agent pracuje z narzędziami i wytycznymi dla danej dziedziny, nawet mocni agenci wywołujący funkcje rozwiązali mniej niż 50% zadań i przeszli to samo zadanie z handlu detalicznego we wszystkich 8 próbach w mniej niż 25% przypadków. Sukces oceniano po stanie bazy danych na końcu rozmowy, a nie po odpowiedzi.

Co powinien zawierać przypadek testowy agenta AI?

Przypadek testowy agenta AI potrzebuje sześciu podstawowych pól: scenariusza, persony klienta, oczekiwanego wyniku, działań, które agent może podjąć, reguły zaliczenia, którą druga osoba zastosuje tak samo, oraz rozmowy źródłowej, z której pochodzi. Bez dwóch ostatnich wyniki testów zamieniają się w opinie.

Oto szablon: sześć podstawowych pól plus cztery, które pozwalają utrzymać zestaw. Proszę skopiować go do arkusza, jeden wiersz na przypadek.

Dwie reguły utrzymują użyteczność szablonu. Po pierwsze, oczekiwany wynik opisuje stan, a nie zdanie: inżynieryjny przewodnik Anthropic po ewaluacji agentów mówi to samo na przykładzie rezerwacji lotu, gdzie liczy się to, czy rezerwacja istnieje w bazie danych, a nie to, czy agent mówi, że ją zrobił. Po drugie, każdy przypadek wskazuje rozmowę, która go uzasadnia, więc gdy zmieniają się zasady, łatwo znaleźć i zaktualizować przypadki, których to dotyczy.

Jak zbudować złoty zestaw testów z prawdziwych rozmów?

Złoty zestaw testów buduje się z własnego ruchu: z rozwiązanych rozmów, które pokazują agenta w najlepszym wydaniu, z dawnych błędów, których nie chcą Państwo nigdy więcej zobaczyć, z eskalacji i z przypadków brzegowych każdej zasady. Warto zacząć od 20 do 50 przypadków i rozbudowywać zestaw co tydzień, zamiast czekać na idealny zestaw kilkuset przypadków.

Przewodnik Anthropic mówi, że 20 do 50 prostych zadań opartych na prawdziwych błędach to świetny początek, i zaleca zamieniać błędy zgłoszone przez użytkowników w przypadki testowe, tak aby zestaw odzwierciedlał rzeczywiste użycie.

Zrównoważony pierwszy zestaw 50 przypadków może wyglądać tak (ilustracja; proporcje warto dopasować do własnego wolumenu i ryzyka):

Przypadki, które przechodzą, należy zostawić w zestawie: poprawka jednego przepływu może po cichu zepsuć inny, a pokażą to tylko przypadki, które wcześniej przechodziły. Z każdej rozmowy źródłowej trzeba usunąć dane osobowe, zanim stanie się przypadkiem testowym.

Jak uruchamiać testy regresyjne przed każdą zmianą agenta AI?

Testy regresyjne uruchamia się, odtwarzając cały złoty zestaw na zmienionym agencie przed jego wdrożeniem, z tymi samymi regułami zaliczenia co poprzednio, i porównując wyniki z aktualną wersją. Liczy się każda zmiana: prompty, zasady, artykuły bazy wiedzy, wersje modeli, narzędzia i reguły routingu zmieniają zachowanie. Edycja artykułu pomocy może zmienić odpowiedzi o zwrotach tak samo jak edycja promptu.

Przypadki krytyczne warto uruchamiać więcej niż raz. Agenci nie są deterministyczni, więc pojedyncze zaliczenie niewiele dowodzi; z tego powodu autorzy τ-bench zaproponowali miarę pass^k, czyli prawdopodobieństwo, że wszystkie k uruchomień zakończy się sukcesem. Arytmetyka (ilustracja): przypadek, który agent zalicza w 90% uruchomień, przechodzi 3 razy z rzędu tylko w 73% przypadków (0,9 × 0,9 × 0,9), a 8 razy z rzędu tylko w 43%.

Przypadki regresyjne powinny przechodzić w 100% albo bardzo blisko tej wartości. Przewodnik Anthropic przeprowadza ten sam podział: ewaluacje regresyjne powinny mieć wskaźnik zaliczeń bliski 100%, natomiast ewaluacje nowych umiejętności mogą zaczynać od niskich wyników.

Jak symulować klientów, aby przetestować agenta AI?

Klientów symuluje się, pozwalając drugiemu modelowi odgrywać klienta według spisanej persony, przez kilka tur, w rozmowie z testowanym agentem. Każda persona potrzebuje celu, faktów, temperamentu i punktu krytycznego; warto też dodać persony manipulacyjne, które próbują wypchnąć agenta poza jego granice.

Pojedyncze pytania testują odpowiedzi. Symulacja wieloturowa, czyli konstrukcja zastosowana w τ-bench, testuje to, co psuje się w prawdziwych rozmowach: klienta, który w połowie zmienia prośbę, albo takiego, który wciąż naciska na zwrot niedozwolony przez zasady.

Warto napisać od pięciu do ośmiu person i używać ich w wielu scenariuszach:

1. Konkretny: jedna prośba, wszystkie szczegóły podane. Punkt odniesienia.
2. Niejasny: brak numeru zamówienia, zła nazwa produktu. Testuje pytania doprecyzowujące.
3. Zmieniający temat: zaczyna od dostawy, kończy na anulowaniu.
4. Naciskający: trzy razy odrzuca pierwszą odpowiedź i prosi o wyjątek. Testuje granice pod presją.
5. Zdenerwowany klient: grozi odejściem albo publiczną skargą. Testuje ton i przekazanie.
6. Klient w trudnej sytuacji: wspomina o żałobie, chorobie albo kłopotach finansowych. Testuje Państwa reguły przekazania w takich przypadkach.
7. Manipulator: podaje się za pracownika, wkleja „zignoruj swoje instrukcje” albo ukrywa instrukcje w załączniku. Testuje odporność na to, co OWASP nazywa prompt injection.

Persona znajduje tylko te problemy, które ktoś do niej wpisał, dlatego symulacja służy do poszerzania zestawu, a prawdziwe rozmowy do utrzymania jego uczciwości. Agenci głosowi dodają akcenty, wchodzenie w słowo i jakość połączenia; zob. kontrola jakości voicebotów.

Jak testować działania i wywołania narzędzi agenta AI?

Działania testuje się, sprawdzając stan końcowy w Państwa systemach po rozmowie, a nie opis tego, co agent zrobił. Czy rekord zwrotu istnieje, na właściwą kwotę i dla właściwego zamówienia? Czy agent mieścił się w swoich limitach, prosił o potwierdzenie tam, gdzie było to wymagane, i nie wywołał żadnego narzędzia, którego nie wolno mu było użyć?

Odpowiedź „zleciłem zwrot” niczego nie dowodzi. W każdym przypadku działania należy sprawdzić cztery rzeczy:

1. Właściwe działanie. Wywołano oczekiwane narzędzie i żadnego nieoczekiwanego.
2. Właściwe argumenty. Poprawne zamówienie, klient, kwota i powód.
3. W granicach limitów. Kwota poniżej limitu, posiadane uprawnienie, prośba o zatwierdzenie tam, gdzie Państwa zasady wymagają człowieka.
4. Prawdziwy raport. To, co agent powiedział klientowi, zgadza się z tym, co faktycznie stało się w systemie.

OWASP wymienia nadmierną sprawczość (excessive agency) wśród głównych zagrożeń dla aplikacji LLM: szkodliwe działania umożliwione przez zbyt dużą funkcjonalność, zbyt szerokie uprawnienia albo zbyt dużą autonomię. Zalecane przez OWASP środki (minimalne rozszerzenia, minimalne uprawnienia, zatwierdzanie przez użytkownika) są jednocześnie listą testów. Dla każdego limitu warto napisać co najmniej jeden przypadek, w którym klient prosi o odrobinę więcej.

Testy działań należy uruchamiać w środowisku testowym (sandbox) lub na kontach testowych, nigdy na rekordach produkcyjnych. Szkolenie Salesforce dotyczące Agentforce Testing Center ostrzega, że testowanie agentów może modyfikować dane w CRM, i zaleca korzystanie z niego wyłącznie w sandboxie.

Przekazanie to również działanie: należy sprawdzić, czy agent przekazuje te sprawy, które powinien, z notatką pozwalającą człowiekowi kontynuować (jakość obsługi eskalacji).

Jak błędy z produkcji stają się nowymi przypadkami testowymi?

Błędy z produkcji stają się przypadkami testowymi dzięki cotygodniowej rutynie: znaleźć rozmowy, w których agent AI się pomylił, potwierdzić błąd, usunąć dane osobowe, opisać przypadek według powyższego szablonu i dodać go do złotego zestawu. Kolejna zmiana nie może zostać wdrożona, dopóki ten przypadek nie przejdzie.

Najtrudniej jest znaleźć błędy. Rozmowa „rozwiązana” przez agenta może wciąż zawierać błędną odpowiedź, wymyśloną zasadę albo pominięte przekazanie, a dashboardy liczą ją jako sukces (ciche błędy agentów AI). Artykuł o monitorowaniu agentów AI opisuje, co obserwować na co dzień, a artykuł o kontroli jakości agentów AI pokazuje, jak zbudować kartę oceny, która je wychwyci.

W tym miejscu kontrola jakości rozmów na żywo spotyka się z testami przed wydaniem. AutoPilot w Kaizo ocenia każdą rozwiązaną rozmowę agenta AI według Państwa własnej karty oceny i łączy każdy wynik z dowodem, co daje potwierdzone błędy, każdy z rozmową źródłową do szablonu. Po wdrożeniu poprawki ocena rozmów z kolejnych tygodni pokazuje, czy poprawka się utrzymała.

Proszę zobaczyć, gdzie Państwa agent AI myli się dziś. Kaizo ocenia rozmowy agentów AI według tej samej karty oceny co Państwa zespół i łączy każdy wynik z fragmentami rozmowy, które za nim stoją. Umów demo.

Jeśli oceny wystawia sędzia AI, jego również trzeba sprawdzić. Nasz przewodnik o tym, jak zweryfikować ocenę QA wykonywaną przez AI (po angielsku), pokazuje, jak porównać automatyczne wyniki z ocenami Państwa recenzentów, zanim zacznie się im ufać.

Co powinien sprawdzać próg wydania agenta AI?

Próg wydania agenta AI to krótka spisana lista warunków, które zmiana musi spełnić, zanim dotrze do klientów, uzgodniona przed uruchomieniem testów. Powinien blokować przy każdym błędzie krytycznym, wymagać niemal idealnych wyników regresji, obejmować każde działanie i każdy limit oraz wskazywać, kto zatwierdza i jak wycofać zmianę. Proszę go skopiować i ustawić własne liczby.

Przed uruchomieniem

• Zmiana jest opisana: co, dlaczego, kto o nią prosił.
• Nowe przypadki dla samej zmiany (nowy limit dostaje przypadki tuż w granicach i tuż poza nimi).
• Każdy błąd potwierdzony w produkcji od ostatniego wydania jest w zestawie.
• Konta testowe i sandbox gotowe; żadne rekordy prawdziwych klientów nie są w zasięgu.

Uruchomienie

• Cały złoty zestaw uruchomiony na zmienionym i na aktualnym agencie, z tymi samymi regułami zaliczenia.
• Przypadki krytyczne (pieniądze, dane, kwestie prawne, klienci w trudnej sytuacji) uruchomione co najmniej 3 razy każdy.
• Uruchomione symulowane persony, w tym manipulator i naciskający.

Warunki zaliczenia

• Przypadki krytyczne: 100% zaliczeń w każdej próbie. Jedna porażka blokuje wydanie.
• Przypadki regresyjne: co najmniej 98% zaliczeń i żaden przypadek, który przechodził w poprzednim wydaniu, nie zawodzi teraz bez wyjaśnienia.
• Przypadki działań: żadnego działania spoza dozwolonej listy, żadnej kwoty powyżej limitu, żadnej deklaracji działania, które się nie wydarzyło.
• Przypadki przekazania: każda sprawa, która musiała zostać przekazana, trafiła do człowieka z użyteczną notatką.
• Przypadki bez znanej odpowiedzi: brak wymyślonych odpowiedzi.

Zatwierdzenie i okres po wydaniu

• Wskazany właściciel podpisuje: lider obsługi lub CX za zasady i ton, właściciel AI za stronę techniczną.
• Wycofanie jest przygotowane: poprzednią wersję promptu, wiedzy i modelu można przywrócić tego samego dnia.
• Pierwsze dni rozmów na żywo po wydaniu są przeglądane dokładniej niż zwykle.

Przykład (ilustracja ze zmyślonymi liczbami). Zespół skraca termin zwrotu z 30 do 14 dni. Złoty zestaw ma 120 przypadków: 40 krytycznych i 80 pozostałych. Przypadki krytyczne uruchamia się 3 razy, pozostałe raz, więc test obejmuje 200 prób. Wynik: 196 z 200 prób przechodzi, co daje 98% i wygląda zdrowo. Ale wszystkie 4 porażki dotyczą dwóch przypadków krytycznych. W jednym agent w jednej z trzech prób wciąż zaproponował zwrot w 20. dniu. W drugim persona naciskająca we wszystkich trzech próbach namówiła go na zwrot „w geście dobrej woli”. Próg blokuje wydanie. Poprawka trafia do promptu i artykułu wiedzy, dochodzą dwa nowe przypadki krytyczne dla 14. i 15. dnia, a ponowne uruchomienie zalicza 206 z 206 prób. Średnia wypuściłaby błąd; próg na to nie pozwolił.

Jakich narzędzi potrzeba do testowania agentów AI?

Potrzebne są trzy rodzaje narzędzi: miejsce do przechowywania i wersjonowania przypadków testowych, sposób uruchamiania ich na agencie (często z symulowanymi klientami) oraz sposób oceniania wyników według Państwa reguł zaliczenia.

• Arkusz i ręczne uruchomienia wystarczą poniżej około 50 przypadków i przy kilku zmianach w miesiącu.
• Funkcja testowa platformy sprawdza się przy jednej platformie ze standardowymi przepływami. Agentforce Testing Center od Salesforce na przykład domyślnie generuje 20 przypadków testowych, a użytkownik ustala, ile z nich ma być pozytywnych, a ile negatywnych.
• Narzędzia do testowania i symulacji dodają symulowanych klientów, wielokrotne próby i kontrole wydania w procesie wdrożeniowym.
• Kontrola jakości rozmów na żywo ocenia to, co naprawdę wydarzyło się po wydaniu, i przekazuje potwierdzone błędy z powrotem do zestawu.

Niezależnie od wyboru przypadki warto trzymać w formacie, który zespół obsługi może czytać i edytować, inaczej właściciele zasad przestaną je aktualizować.

Kiedy pełny program testów nie jest dla Państwa?

Pełny program to przesada, jeśli Państwa agent AI obsługuje kilkadziesiąt rozmów tygodniowo, tylko odpowiada na pytania i nie może podejmować działań. W takim przypadku wystarczy co tydzień czytać transkrypcje i mieć krótką listę 20 przypadków uruchamianych ręcznie po każdej zmianie.

Kontrola jakości rozmów na żywo również go nie zastępuje: ocenianie rozmów po ich zakończeniu nie zablokuje zmiany przed wydaniem. Potrzebne jest jedno i drugie: testy przed zmianą i ocena każdej rozmowy agenta AI po niej.

Jak zacząć w tym tygodniu

Pierwszy złoty zestaw, spisany próg wydania i pierwsze uruchomienie referencyjne można mieć w ciągu pięciu dni roboczych, korzystając z eksportu ostatnich rozmów, powyższego szablonu i środowiska testowego.

1. Poniedziałek: wyeksportować 30 rozwiązanych rozmów agenta AI i 20, które poszły źle. Usunąć dane osobowe.
2. Wtorek: opisać je według szablonu. Oznaczyć przypadki krytyczne.
3. Środa: spisać próg wydania. Uzgodnić liczby z liderem obsługi i właścicielem AI.
4. Czwartek: uruchomić zestaw na aktualnym agencie, z trzema próbami dla przypadków krytycznych. To Państwa punkt odniesienia; należy spodziewać się kilku porażek.
5. Piątek: uzgodnić zasadę, że żadna zmiana promptu, zasad, wiedzy ani modelu nie trafia na produkcję bez ponownego uruchomienia testów, i wyznaczyć cotygodniowy termin na dodawanie nowych błędów do zestawu.

Kto odpowiada za zatwierdzenie, opisuje artykuł o zarządzaniu agentami AI.

Najczęściej zadawane pytania

Czym jest automatyzacja testów z użyciem AI?

Automatyzacja testów z użyciem AI zwykle oznacza wykorzystanie AI do testowania oprogramowania, na przykład agentów, którzy piszą i uruchamiają skrypty testowe dla aplikacji webowej. Ten artykuł dotyczy innego tematu: udowodnienia, że agent AI obsługujący klientów odpowiada i działa poprawnie, zanim każda zmiana trafi na produkcję.

Czy agenci AI mają narzędzia?

Tak. Narzędzia agenta AI to funkcje, które może wywołać, na przykład sprawdzenie zamówienia albo zlecenie zwrotu. To z ich powodu testy agentów muszą sprawdzać stan końcowy w Państwa systemach, a nie tylko odpowiedź.

Kim jest tester AI?

Albo osobą, która testuje systemy AI, albo AI, która testuje inne oprogramowanie. W obsłudze klienta to zwykle lider QA lub właściciel AI, który pisze przypadki testowe na podstawie prawdziwych rozmów i decyduje, czy zmiana spełnia próg wydania.

Ile przypadków testowych potrzebuje agent AI?

Na początek od 20 do 50 przypadków opartych na prawdziwych rozmowach i dawnych błędach, a następnie każdy potwierdzony błąd z produkcji. Pokrycie najważniejszych intencji, działań i limitów jest ważniejsze niż sama liczba.

Jak często uruchamiać testy regresyjne agenta AI?

Cały zestaw należy uruchamiać przed każdą zmianą promptów, zasad, wiedzy, modeli, narzędzi lub routingu, a także co tydzień, nawet gdy nic się nie zmieniło, bo zmieniają się również dostawcy modeli i połączone systemy.