Testowanie agentów AI na podstawie wyników: weryfikacja stanu zamiast polegania na odpowiedziach

Gdy agent AI odpowiada „Gotowe”, to zdanie stanowi stwierdzenie, a nie potwierdzenie. Ocena oparta wyłącznie na ostatniej wiadomości może błędnie uznać efekt halucynacji za pomyślne rozwiązanie. Ten przewodnik pokazuje, jak testować agenty wykorzystujące narzędzia pod kątem tego, co faktycznie zmieniło się w świecie: jak zdefiniować ukończenie zadania, jakie dowody sprawdzić, jak radzić sobie z przekroczeniem czasu i sytuacjami, gdy agent nie powinien nic robić, oraz jak mierzyć niezawodność zamiast przypadkowego sukcesu podczas demonstracji.

Przekonująca odpowiedź to nie dowód

Weźmy prostą prośbę skierowaną do asystenta planowania: przenieś spotkanie na czwartek po południu. Asystent odpowiada uprzejmie i bez wahania, że spotkanie odbywa się już o 15:00. Następnie otwieramy kalendarz, a wydarzenie znajduje się dokładnie w tym samym miejscu co wcześniej.

Różne warianty są równie prawdopodobne: wydarzenie przeniesione zostało na godzinę 15:00 w innym strefie czasowej, albo pojawiło się zupełnie nowe wydarzenie, podczas gdy oryginalne pozostało na miejscu, co daje użytkownikowi dwie opcje. Przykład jest wymyślony, ale problem testowania jest bardzo rzeczywisty – jeśli ocenia się tylko tekst wygenerowany przez agenta, wszystkie trzy niepowodzenia wyglądają identycznie jak sukces.

Korzystna perspektywa to ta: dla agenta odpowiedzią jest raport o wykonanej pracy, a raport może być błędny. Otaczający model system, jego „opaska”, decyduje o tym, czy może on w ogóle działać niezawodnie (ten aspekt omawiamy w tekście o tym, skąd pochodzi rzeczywiście niezawodne zachowanie agenta). Ocena to krok, który potwierdza, czy ten system rzeczywiście spełnił swoje zadanie.

Najpierw napisz umowę przyjęcia

"Przenieś moje spotkanie" brzmi błahe, dopóki nie spróbujesz sformułować kryteriów akceptacji dla tego zadania.

W przykładzie zastosowanym w tym tekście załóżmy, że użytkownik zidentyfikował jedno wydarzenie, określił datę i strefę czasową oraz zatwierdził aktualizację. Pożądany wynik to nie tylko istnienie jakiegoś spotkania o godzinie 15:00. Chodzi o to, aby to samo wydarzenie rozpoczynało się teraz o podanej godzinie, zachowywało swoją pierwotną długość i listę uczestników, a także aby żadne inne wydarzenie nie zostało zmienione. Jeśli prośba jest niejednoznaczna lub asystent nie ma uprawnień, właściwym zachowaniem jest zapytanie, a nie domyślanie się.

Te zasady odnoszą się do tego hipotetycznego produktu. Inny produkt może wysyłać powiadomienia, wymagać wyraźnej zgody lub traktować uczestników inaczej. Ważne jest to, aby umowa była spisana na piśmie. Bez niej jeden recenzent chwali asystenta za inicjatywę, podczas gdy inny zaznacza tę samą sesję jako nieuprawnioną zmianę, a wasze oceny stają się bezwartościowe.

Dlatego każdy przypadek oceny powinien określać:

• początkowy stan środowiska;
• prośbę użytkownika;
• działania, które agent może wykonać;
• warunki, które muszą być spełnione później; oraz
• elementy, które muszą pozostać niezmienione.

Ostatni punkt łatwo zapomnieć. Dobry test określa zarówno cel, jak i granice wokół niego.

Trzy perspektywy jednej sesji

Każdą rundę działania agenta można przeanalizować z trzech perspektyw, a każda z nich ujawnia inne błędy.

• Wynik: komunikat, który zobaczył użytkownik. Czy jest dokładny i pomocny, czy też przyjmuje niedokończoną pracę zamiast to ukrywać?
• Trajektoria: widoczna sekwencja wywołań narzędzi, wyników tych narzędzi, zatwierdzeń, ponownych prób i sprawdzeń. Czy agent wybrał właściwe zdarzenie, działał w ramach swoich uprawnień i odpowiednio zareagował, gdy narzędzie zawiodło?
• Skutek: rzeczywisty stan kalendarza po zakończeniu próby.

Przewodnik Anthropic dotyczący oceny agentów dokonuje tego samego rozróżnienia pomiędzy transkrypcją a końcowym stanem środowiska i ostrzega przed ocenianiem każdego poprawnego rozwiązania według jednej stałej sekwencji kroków. Taka zrównoważoność jest godna przyjęcia – należy obserwować, jak zachowywał się agent, ale nie należy naciskać na wybraną przez siebie ścieżkę, chyba że kolejność działań jest rzeczywiście częścią umowy.

W praktyce dwa agenty mogą przeglądać kalendarz za pomocą różnych operacji i mimo to dojść do tego samego poprawnego wyniku; oba powinny przejść test. Z drugiej strony pominięcie obowiązkowej akceptacji stanowi niepowodzenie, nawet jeśli kalendarz ostatecznie wygląda poprawnie. Wynik decyduje o tym, czy zadanie zostało zrealizowane, granice określają, czy było dozwolone, a ślad wyjaśnia różnicę pomiędzy nimi.

Sprawdź świat za pośrednictwem niezależnego kanału

Aby sprawdzić test kalendarza, odczytaj zapisane wydarzenie za pośrednictwem upoważnionej interfejsu, który nie ma żadnego związku z odpowiedzią samego agenta. Agent nie może oceniać własnych zadań.

Porównaj pola, które faktycznie określają poprawność, z oczekiwanym stanem:

• stabilny identyfikator wydarzenia;
• godziny rozpoczęcia i zakończenia oraz strefa czasowa;
• lista uczestników;
• sąsiednie wydarzenia, które powinny pozostać bez zmian.

Unikaj porównywania na podstawie tytułu wydarzenia. Dwie spotkania mogą mieć ten sam nazwę, a zgodność tytułów może błędnie potwierdzić niewłaściwe wydarzenie.

To rozwiązanie istniało jeszcze przed dzisiejszymi frameworkami agentów. Narzędzie τ-bench ocenia rozmowy z wykorzystaniem narzędzi poprzez porównanie końcowego stanu bazy danych ze stanem celu opisanym adnotacjami, natomiast WebArena sprawdza, czy zadania zostały faktycznie ukończone w realistycznych środowiskach internetowych. Oba stanowią przykłady badań nad oceną tego, co się wydarzyło, a nie tego, co zostało powiedziane.

Dowiedz się, co naprawdę obiecuje sygnał sukcesu

Odpowiedź API o statusie sukcesu jest przydatnym dowodem, ale tylko wtedy, gdy wiemy, co gwarantuje. „Accepted” może oznaczać, że żądanie trafiło do kolejki, a nie zostało zrealizowane. Bannera sukcesu w przeglądarce może pojawić się przed zapisaniem odpowiedniej informacji.

Dla systemów asynchronicznych zdecyduj z góry, jak długo ma czekać weryfikator oraz jaki stan uznaje się za ustalony. Jeśli w ogóle nie możesz zaobserwować stanu, zapisz wynik jako nieweryfikowany. Nie zakładaj po cichu, że jest to wynik pozytywny, ani też nie przyjmuj przeciwnego założenia. Ta trzecia kategoria staje się kluczowa, gdy tylko żądania zaczynają wygasać.

Najtrudniejszy moment: tuż po wygaśnięciu terminu

Wygaśnięcie terminu nie mówi ci nic o tym, czy aktualizacja dotarła. Żądanie mogło zostać przerwane przed dotarciem do usługi kalendarza, albo mogło odnieść sukces, a jedynie odpowiedź zaginęła w drodze powrotnej.

Agent, który reaguje poprzez utworzenie nowego spotkania zastępczego, może pozostawić użytkownika z dwoma wydarzeniami. Dlatego zachowanie przywracające stan jest kluczowym przypadkiem testowym. Poprawna sekwencja przywracania wygląda następująco:

1. Poznaj ponownie docelowe wydarzenie.

Sprawdź, czy żądana zmiana została już wprowadzona.

Ponowić próbę tylko wtedy, gdy dowody oraz specyfikacja narzędzia pozwalają na bezpieczne jej powtórzenie.

Gdzie usługa to umożliwia, użyj mechanizmu idempotencji, aby powtórzone żądanie zostało rozpoznane jako ta sama operacja, a nie nowa.

Jeśli po tym nadal nie wiadomo, jaki będzie wynik, właściwym krokiem może być zatrzymanie się i wyjaśnienie użytkownikowi tej niepewności. Jasne poinformowanie jest lepsze od sfabrykowanego sukcesu. Ten sam model występuje w zwykłym projektowaniu backendu; więcej informacji na temat strony serwera znajdziesz w artykule kluczy idempotencji dla endpointów POST w Node.js.

Oceniaj zarówno stan, jak i sformułowanie. Stwierdzenie „Nie mogłem potwierdzić aktualizacji” jest prawdziwe, nawet jeśli usługa wprowadza zmianę chwilę później. Z kolei „Nic nie zostało zmienione” to nieudokumentowane twierdzenie w dokładnie takiej samej sytuacji. Niepewność jest uzasadnionym rezultatem, który agent musi rozwiązać, a nie luką, którą powinien wypełnić pewnością siebie.

Dołącz oceniacza do pytania

Różne pytania wymagają różnych sędziów.

• Kod deterministyczny dla dokładnych faktów: identyfikatory, daty i godziny, zbiór dozwolonych zmian, liczba powtórzonych zdarzeń.
• Oceniacz oparty na modelu ze jasną rubryką dla jakości komunikacji: czy asystent odróżnił ukończoną pracę od próby jej wykonania oraz czy opisał kolejne kroki bez wymyślania szczegółów?

Przegląd przez człowieka w przypadkach niejednoznacznych oraz w celu okresowej weryfikacji, czy oceny automatyczne nadal są zgodne z oczekiwaniami zespołu produktowego.

Dokumentacja oceny LangSmith traktuje zasady kodu, przegląd przez człowieka oraz ocenę opartą na modelach jako odrębne opcje. Nie musisz korzystać z tej platformy, aby czerpać korzyści z ich rozdzielania.

Jeden antypatron zasługuje na szczególne wzmiankowanie: przekazywanie drugiemu modelowi pewnej siebie odpowiedzi agenta i pytanie, czy zadanie wygląda na ukończone pomyślnie. Sędzia da się przekonać tą samą pewnością siebie, która oszukała ciebie. Zamiast tego podaj sędziemu dowody, których faktycznie wymaga pytanie, i pozwól mu odpowiedzieć „niewystarczające dowody”.

Należy trzymać krytyczne awarie oddzielnie od ocen jakości. Nieuprawniona edycja kalendarza nie powinna być zrównoważona przyjemnym tonem i precyzyjnym sformułowaniem. Skuteczny jest zwięzły formularz ocen: poprawny wynik, przestrzeganie granic, prawdziwy raport, odpowiednia reakcja. Podaj obok niego opóźnienie i koszt, zamiast łączyć wszystko w jeden nieprzejrzysty numer.

Zawrzyj przypadki, w których właściwą odpowiedzią jest nic nie robić

Rozsądny zestaw początkowy dla asystenta kalendarza obejmuje:

• zwykłe przesunięcie terminu;
• dwa wydarzenia o tym samym tytule;
• prośbę bez informacji o strefie czasowej;
• odmowę uprawnień;
• przerwanie połączenia ze strony usługi kalendarza;
• aktualizację, która została już zastosowana przed uruchomieniem agenta;
• prośbę o przygotowanie propozycji zmiany bez jej faktycznego zastosowania.

Ostatni przypadek chroni przed subtelnymi uprzedzeniami. Jeśli każdy test nagradza wprowadzanie zmian z zewnątrz, w rezultacie wybieramy agenta, który działa zbyt pochopnie.

Przeprowadzaj testy, które modyfikują stan w izolowanych kontach testowych lub kontrolowanych środowiskach, oraz resetuj ustawienia pomiędzy niezależnymi próbami. Wynik z poprzedniej sesji nigdy nie powinien sprawiać wrażenia, że kolejna sesja zakończyła się pomyślnie.

Ta lista jest punktem wyjścia, a nie statystycznie wystarczającą próbą. Rozszerz ją na podstawie tego, o co faktycznie proszą twoi użytkownicy, gdzie leżą rzeczywiste ryzyka oraz jakie błędy występują w praktyce. Usuń dane osobowe z ustawień, które zamierzasz ponownie wykorzystać, oraz ogranicz dostęp do śladów zawierających dane prywatne.

Mierz spójność, a nie najlepszą demonstrację

Przeprowadź każdy przypadek więcej niż raz i zapisz każdą próbę, włączając czas wygaśnięcia oraz te, w których weryfikacja nie powiodła się.

τ-bench wprowadził miarę powtarzanych prób, pass^k, która sprawdza, czy agent odnosi sukces we wszystkich k próbach, a nie przynajmniej w jednej. Opublikowane wyniki modeli są historyczne i nie powinny być traktowane jako ranking aktualnych agentów, ale lekcja pozostaje: „może odnieść sukces” oraz „odnosi sukces w sposób niezawodny” to różne właściwości, a pojedyncza udana próba informuje jedynie o pierwszej z nich.

Pierwsza karta informacyjna produktu może śledzić:

• wskaźnik prawidłowego zakończenia;
• Liczbę nieuprawnionych działań;
• Twierdzenia o sukcesie bez podstaw;
• Odpowiednie eskalacje;
• Opóźnienia;
• Koszt za prawidłowe zakończenie.

Należy jasno określić mianownik. Czy liczy się prośby użytkowników, niezależne próby czy pojedyncze ponowne próby? Te same dane mogą dać zupełnie różne wskaźniki w zależności od wyboru.

Czytajcie liczby razem. Zmiana, która zwiększa stopień ukończenia zadań, ale jednocześnie powoduje więcej nieuprawnionych działań, nie stanowi czystego sukcesu. Podobnie jest z agentem, który unika wszelkich ryzyk, odrzucając każde przydatne zadanie. Porównujcie wersje dla tych samych przypadków przy tych samych budżetach i publikujcie informacje o liczbie przeprowadzonych przypadków oraz o tym, na jak dużo różniły się wyniki pomiędzy poszczególnymi próbami. Zaledwie kilka prób to zdecydowanie za mało, by uzasadnić dokładną wartość niezawodności w warunkach produkcyjnych.

Zmieniajcie każdą awarię w test regresji

Gdy jakiś przypadek się nie powiedzie, najpierw ustalcie, co tak naprawdę poszło nie tak: czy to agent, narzędzie, środowisko, czy system oceny. Nieprawidłowy test nie jest dowodem na błąd w modelu.

Następnie uchwycić minimalny przypadek możliwy do odtworzenia i zaznaczyć wersję wszystkiego, co może na niego wpłynąć: zadanie, oczekiwany stan, narzędzie oceny, konfigurację modelu, instrukcje oraz umowy dotyczące narzędzi. Gdy cokolwiek z tego się zmieni, ponownie uruchomić dotknięte przypadki. Ustalanie oczekiwanego stanu jest równie ważne jak ustalanie wersji modelu; nasz artykuł na temat ustalania wersji w zestawach do oceny LLM omawia to bardziej szczegółowo.

Testy offline oraz monitorowanie w czasie rzeczywistym odpowiadają na różne pytania. Starannie przygotowane testy przed wydaniem informują, czy zmiana jest bezpieczna do wdrożenia; ocena rzeczywistych interakcji pokazuje, co idzie nie tak w praktyce. Dokumentacja LangSmith opisuje oba te aspekty i zaleca wprowadzanie błędów z produkcji z powrotem do zestawu testowego.

Dla asystenta kalendarzowego taki cykl może rozpocząć się od zgłoszeń użytkowników dotyczących powtarzających się wydarzeń, dodać do zestawu przypadek braku odpowiedzi oraz upewnić się, że poprawka naprawcza przeszła testy przed szerszym wdrożeniem.

Główne wnioski

• Traktuj „Gotowe” jako coś, co należy zweryfikować, a nie jako dowód.
• Napisz umowę dostosowaną do konkretnego przypadku: stan początkowy, żądanie, dozwolone działania, wymagany stan końcowy oraz to, co nie może ulec zmianie.
• Oceń wynik, egzekwuj ustalone granice i wykorzystaj ślady działania do wyjaśnienia różnic.
• Zwaliduj dane za pomocą niezależnej, upoważnionej ścieżki odczytu i zachowaj status „niezweryfikowane” jako uczciwy wynik.
• Jasno przetestuj przypadki wygaśnięcia czasu oczekiwania, powtórzeń oraz braku działań – to właśnie w nich zawodzą najbardziej pewne agenty.
• Unikaj uwzględniania krytycznych błędów w średnich wynikach jakości i mierz niezawodność powtarzanych prób.

Zanim zaufasz jakiejkolwiek wiadomości o sukcesie, zapytaj, co się zmieniło, jakie ograniczenia obowiązywały i jakie dowody potwierdzają ten raport.