Jak testować agenta AI: odpowiedź może być dobra, a zadanie niewykonane

Aby sprawdzić, czy agent AI wykonał zadanie, zdefiniuj oczekiwaną zmianę w systemie i odczytaj jego stan po zakończeniu próby. Osobno oceń odpowiedź dla użytkownika oraz przebieg użycia narzędzi. Komunikat „gotowe” może brzmieć poprawnie, choć żądana operacja nie została zapisana.

Opis ewaluacji Anthropic rozróżnia zapis przebiegu próby od jej wyniku, czyli końcowego stanu środowiska. W podanym tam przykładzie agent może oznajmić, że zarezerwował lot, podczas gdy w bazie nie ma rezerwacji. Ten sam materiał wskazuje na potrzebę wielu prób, ponieważ odpowiedzi modelu mogą się różnić.

Określ zmianę, którą da się sprawdzić

Zapisz kryterium sukcesu przed uruchomieniem agenta. Jeżeli zadaniem jest utworzenie rezerwacji w testowym systemie, sprawdź, czy po próbie istnieje właściwy wpis z wymaganymi parametrami. Samo wywołanie narzędzia nie wystarcza: mogło zakończyć się błędem albo zapisać inne dane, niż wynikało z polecenia.

Ustal też stan początkowy. Gdy rezerwacja istniała wcześniej, test oparty wyłącznie na jej obecności zaliczy próbę mimo braku działania agenta. Przywracaj więc znany stan przed każdym uruchomieniem i oceniaj zmianę względem niego. Sprawdź również skutki uboczne, które miałyby znaczenie dla użytkownika, takie jak drugi identyczny wpis lub modyfikacja niewłaściwej rezerwacji.

Odczyt wyniku powinien odbywać się poza rozmową z agentem, przez niezależny mechanizm testowy mający dostęp do stanu systemu. Dzięki temu ocena nie opiera się na deklaracji badanego programu. W przypadku zadania, którego wynikiem jest wyłącznie odpowiedź tekstowa, kryterium będzie inne; przy operacji zmieniającej dane punktem odniesienia pozostaje rzeczywista zmiana.

Zapisz minimalny przypadek testowy

Poniższy przypadek jest przykładem warunkowym: agent otrzymuje polecenie utworzenia jednej rezerwacji lotu w odizolowanym systemie testowym. Szablon można zastosować do innej automatyzacji, podstawiając jej własny stan początkowy i oczekiwany wynik.

• Zadanie: dokładne polecenie dla agenta oraz parametry rezerwacji, które ma zastosować.
• Stan początkowy: zestaw danych testowych i potwierdzenie, że żądana rezerwacja jeszcze nie istnieje.
• Kryteria sukcesu: właściwy wpis pojawia się po próbie, ma oczekiwane pola i nie powstaje duplikat.
• Powtórzenia: niezależne uruchomienia, każde po przywróceniu tego samego stanu.
• Oceny: osobny odczyt wyniku w systemie oraz ocena śladu wywołań narzędzi.
• Budżet: dopuszczalny koszt i czas wykonania zadania, ustalone przed porównaniem wersji.

Do zapisu próby dołącz wersję modelu, instrukcji i narzędzi. Zachowaj także wynik każdego kryterium oraz przyczynę niezaliczenia. Sama zbiorcza ocena nie pokaże, czy agent użył złych parametrów, narzędzie odmówiło zapisu, czy zawiódł mechanizm odczytujący wynik.

Oddziel ocenę wyniku od oceny przebiegu

W opisanym przykładzie ocenę wyniku można wykonać kodem: odczytać rezerwację i porównać jej pola z poleceniem. Odpowiedź dla użytkownika oceń osobno. Może być jasna i uprzejma, ale nie powinna potwierdzać rezerwacji, której nie ma; z drugiej strony zwięzły komunikat nie przekreśla poprawnie wykonanej operacji.

Swobodną wypowiedź można oceniać według jawnych kryteriów, na przykład tego, czy wiernie opisuje rezultat. Gdy reguły językowe są trudne do zapisania w kodzie, pomocna może być ocena modelowa i przegląd spornych przypadków przez człowieka. Ocena komunikatu nie zastępuje jednak sprawdzenia wpisu: dotyczy tego, co agent powiedział, a nie tego, co system zapisał.

Ślad próby pozwala ustalić, jakie narzędzie agent wybrał, jakie przekazał argumenty, co otrzymał w odpowiedzi i jak zareagował na błąd. Wskazówki OpenAI dotyczące ewaluacji zalecają rozpoczęcie diagnozy od pełnych śladów obejmujących wywołania modeli i narzędzi, zabezpieczenia oraz przekazania między agentami.

Ocena ścieżki powinna wychwycić zachowania istotne dla zadania: pominięcie zapisu, użycie niewłaściwego identyfikatora, zignorowanie błędu narzędzia lub ponowienie operacji powodujące duplikat. Nie trzeba wymagać jednej identycznej sekwencji wywołań, jeśli różne drogi mogą prowadzić do poprawnego stanu. Zbyt sztywna reguła uznałaby skuteczną próbę za porażkę.

Powtarzaj próby i mierz koszt całego zadania

Jedno powodzenie pokazuje, że agent potrafił wykonać zadanie w danej próbie; nie opisuje jeszcze powtarzalności. Uruchom przypadek wielokrotnie w przywracanym środowisku. Dla każdej próby zapisz stan końcowy, ocenę ścieżki, liczbę wywołań narzędzi, koszt oraz czas od rozpoczęcia do zakończenia.

Porównuj udział prób zakończonych poprawną zmianą, a obok niego koszt i opóźnienie. Szybka odpowiedź bez rezerwacji pozostaje niezaliczonym zadaniem. Długi ciąg ponowień może z kolei doprowadzić do właściwego wyniku, lecz przekroczyć limit przyjęty dla automatyzacji. Dlatego warto zachować oddzielne oznaczenia błędu wyniku i przekroczenia budżetu.

Budżet powinien odpowiadać temu, co wdrożenie rzeczywiście mierzy: opłatom za wywołania modelu i narzędzi oraz czasowi całej operacji. Określ jego granice przed testem, aby nie dopasowywać ich do otrzymanego rezultatu. Jeśli próby znacząco się różnią, zapis ścieżki pomoże wskazać etap odpowiedzialny za opóźnienie lub dodatkowy koszt.

Wykrywaj regresje na stałym zestawie zadań

Po zmianie modelu, instrukcji lub integracji uruchom te same przypadki dla nowej wersji i porównaj wyniki z wcześniejszą. Dokumentacja LangSmith opisuje testy regresyjne jako sprawdzanie, czy kolejne wersje zachowują skuteczność na przypadkach obsługiwanych wcześniej. Zachowuj zadania, które ujawniły błędy, i dodawaj nowe, gdy pojawi się odmienny sposób niepowodzenia.

Spadek wyniku zbiorczego warto rozpatrzyć przez konkretne niezaliczone próby. Awaria środowiska albo reguła odrzucająca poprawny rezultat może wyglądać jak regresja agenta. Dopiero powiązanie oceny ze stanem końcowym, śladem i przyczyną niezaliczenia pozwala odróżnić zmianę zachowania agenta od usterki samego testu.

Przeczytaj także:

• ChatGPT czy Claude do kodowania? Wynik zależy od rodzaju zadania