Jeśli budujesz lub rozwijasz agenta AI, oceniaj nie tylko jego końcową odpowiedź, lecz także to, czy realizuje cel użytkownika i poprawnie przechodzi kolejne etapy działania. Powtarzalny proces obejmuje scenariusze, ślady wykonania, różne rodzaje kontroli i testy regresji.
Jak połączyć etapy oceny agenta
Przygotuj opis użytkownika, jego celu, ograniczeń i warunków sukcesu. Potem sprawdź agenta w realistycznych sytuacjach, porównuj uruchomienia w stabilnych warunkach, a przypadki zauważone w produkcji przenoś do kolejnych testów. Taki proces Google opisuje w swoim przewodniku o ocenie agentów AI.
1. Zdefiniuj sukces przez ścieżkę użytkownika
Zapisz krytyczną ścieżkę użytkownika — konkretny cel wraz z ograniczeniami i warunkami, które pozwalają stwierdzić, czy został osiągnięty. Każdy ważny warunek zamień na osobny punkt oceny. W przykładzie Google analityk ma wskazać sporną transakcję, sprawdzić jej warunki w wewnętrznym rejestrze i przełożyć wewnętrzne identyfikatory na nazewnictwo używane przez brokera. To trzy osobne rzeczy do sprawdzenia, a nie jedna ocena brzmienia odpowiedzi.
Takie kryteria dają zespołowi wspólną definicję sukcesu, zanim zacznie porównywać wyniki kolejnych wersji agenta. Google proponuje ten sposób pracy w swoim przewodniku.
2. Przygotuj scenariusze i przejrzyj ślady
Zacznij od typowego przebiegu, a potem dodaj przypadki brzegowe: niepełne informacje, literówki, zmianę zdania lub nietypową prośbę. Zasymulowany użytkownik pozwala ćwiczyć takie sytuacje, zanim zespół zacznie wykorzystywać ślady z rzeczywistych interakcji.
Następnie przejrzyj ręcznie ślady wykonania — zapis kolejnych etapów pracy agenta. Sprawdź w nich prompty, pośrednie kroki rozumowania, argumenty przekazywane narzędziom i końcowe wyniki. Gdy znajdziesz powtarzający się błąd, zamień go w konkretną kontrolę, którą można uruchamiać ponownie. Google zaleca najpierw szukać wzorców w śladach, a dopiero potem automatyzować sprawdzanie wykrytych problemów.
3. Uczyń powtarzane uruchomienia porównywalnymi
Agent może inaczej przejść to samo zadanie w kolejnych uruchomieniach, a zmiana zewnętrznej usługi lub danych może dodatkowo utrudnić porównanie. Dlatego Braintrust zaleca wykonywanie wielu prób dla każdego zadania oraz kontrolowanie zależności — na przykład przez stuby usług lub dane zapisane w snapshotach. Jego przewodnik opisuje też sandboxy i wstrzykiwanie awarii, takich jak przekroczenia czasu, niepoprawne odpowiedzi czy brakujące pola.
W praktyce te zalecenia pomagają odróżnić zmienność zachowania agenta od zmian w otoczeniu testu. Braintrust nie podaje jednej uniwersalnej liczby prób. Szczegóły opisuje w swoim przewodniku po ocenie agentów.
4. Łącz różne kontrole i kalibruj sędziego LLM
Google wyróżnia cztery uzupełniające się rodzaje kontroli: testy jednostkowe, metryki deterministyczne, rubryki sędziego LLM i testy integracyjne. Test jednostkowy sprawdza pojedynczy element, metryka deterministyczna daje powtarzalny wynik według określonej reguły, a test integracyjny obejmuje współpracę elementów systemu. Sędzia LLM ocenia odpowiedź modelu na podstawie ustalonej rubryki.
Porównuj automatyczne oceny z przykładami przejrzanymi przez człowieka. Tam, gdzie to możliwe, stosuj pytania z odpowiedzią „tak” lub „nie” zamiast nieostrej skali punktowej. IBM Technology zwraca uwagę na trzy możliwe zniekształcenia oceny: preferowanie odpowiedzi ze względu na jej pozycję, premiowanie dłuższych wypowiedzi oraz skłonność modelu do faworyzowania odpowiedzi, które sam wygenerował. Aby sprawdzić stronniczość pozycyjną, zamień kolejność ocenianych odpowiedzi i zobacz, czy werdykt się zmieni. Ta próba dotyczy kolejności; nie rozstrzyga pozostałych rodzajów stronniczości.
5. Zachowaj stały punkt odniesienia i blokuj regresje
Porównując zmiany, używaj tego samego zestawu testowego i zmieniaj jedną rzecz naraz. W przeciwnym razie nie będzie jasne, czy zmienił się agent, czy test. Google proponuje bramkę CI/CD łączącą ogólny próg zaliczenia z blokadą w razie regresji wcześniej zaliczonych kluczowych metryk. Próg podany w przewodniku jest przykładem, nie uniwersalnym standardem.
Oceniaj także działanie operacyjne agenta: opóźnienia, zużycie tokenów, koszt API i liczbę wywołań narzędzi. Dzięki temu zespół widzi zarówno jakość odpowiedzi, jak i sposób, w jaki agent dochodzi do wyniku.
Kiedy człowiek i automatyczny oceniający wydają sprzeczne werdykty, uczestnicy jednej z dyskusji na Reddicie proponują zapisać rozstrzygnięcie i wersję reguły, doprecyzować kryterium oraz dodać podobne przypadki do testów regresji. To praktyczna sugestia uczestników dyskusji, a nie branżowy standard.
6. Wykorzystuj obserwacje z produkcji
Ocena nie kończy się na testach offline. Microsoft opisuje monitorowanie rzeczywistych interakcji i wykorzystywanie zaobserwowanych problemów do aktualizowania danych testowych offline. Google również zaleca dodawanie przeoczonych przypadków brzegowych do zestawu referencyjnego. W ten sposób nowe sytuacje napotkane przez użytkowników mogą stać się powtarzalnymi testami w kolejnych iteracjach.
Microsoft opisuje ten obieg w materiale o obserwowalności i ocenie agentów w produkcji.
