Agent może napisać poprawną odpowiedź i jednocześnie źle wykonać zadanie. Dlatego testowanie agentów AI nie kończy się na porównaniu tekstu z oczekiwaną odpowiedzią. Trzeba sprawdzić trajektorię, użycie narzędzi i końcowy stan środowiska.
To jest najważniejsza różnica między evalem chatbota a evalem agenta.
Co to jest eval agenta AI?
Eval to powtarzalny test systemu AI. Dostarczamy zadanie, uruchamiamy agenta w kontrolowanych warunkach i oceniamy wynik według wcześniej zapisanych kryteriów.
Anthropic rozdziela kilka przydatnych pojęć:
- task to pojedynczy przypadek testowy z danymi i kryteriami sukcesu,
- trial to jedna próba wykonania tego zadania,
- grader ocenia wybrany aspekt wyniku,
- trace albo trajectory zapisuje odpowiedzi, wywołania narzędzi i wyniki pośrednie,
- outcome to faktyczny stan środowiska po zakończeniu próby.
Outcome jest ważniejszy niż deklaracja modelu. Agent rezerwacyjny może napisać „lot został zarezerwowany”, ale test powinien sprawdzić, czy rezerwacja istnieje w bazie i ma właściwe parametry.
Dlaczego zwykłe testy odpowiedzi nie wystarczą?
Agent działa przez wiele kroków. W każdym może:
- wybrać złe narzędzie,
- podać poprawne narzędzie z błędnymi parametrami,
- zignorować wynik,
- powtórzyć operację z efektem ubocznym,
- zatrzymać się zbyt wcześnie,
- dojść do dobrego wyniku przypadkiem, niebezpieczną drogą.
Jeśli oceniamy wyłącznie ostatni tekst, część tych błędów znika z obrazu.
W badaniu „When Agents Implement Systems” autorzy analizowali systemy tworzone przez agentów oraz defekty pomijane przez istniejące testy. To preprint, nie uniwersalny werdykt, ale dobrze pokazuje ograniczenie: zielony zestaw testów oznacza tylko tyle, że przeszły scenariusze, które potrafiliśmy opisać.
Zacznij od zestawu zadań
Pierwsza wersja evala nie potrzebuje setek przykładów. Lepiej wybrać 20–30 przypadków reprezentujących realne zachowania niż wygenerować tysiąc sztucznych promptów.
W zestawie powinny znaleźć się:
- typowe zadania,
- niejednoznaczne polecenia,
- brakujące dane,
- awarie narzędzi,
- próby wykonania niedozwolonej operacji,
- sytuacje, w których agent powinien poprosić o decyzję człowieka.
Każdy przypadek potrzebuje czytelnego warunku sukcesu. „Odpowiedź jest dobra” to za mało. Lepszy warunek brzmi: agent utworzył dokładnie jedno zadanie, przypisał je do właściwego projektu i nie zmienił żadnego innego rekordu.
Używaj kilku graderów
Jeden wynik procentowy potrafi ukryć prawdziwy problem. Warto rozdzielić co najmniej:
Grader deterministyczny
Sprawdza rzeczy, które można zweryfikować kodem: status procesu, wpis w bazie, format danych, liczbę zmian albo brak niedozwolonych wywołań.
Grader modelowy
Model-as-judge przydaje się przy jakości tekstu, trafności uzasadnienia albo zgodności z luźniejszym briefem. Powinien dostać jasną rubrykę i przykłady. Nie zastępuje asercji, gdy wynik da się sprawdzić bez modelu.
Grader trajektorii
Ocenia sposób dojścia do wyniku. Czy agent przeczytał źródło przed zmianą? Czy użył narzędzia zapisu dopiero po zatwierdzeniu? Czy po błędzie zmienił strategię, czy tylko powtórzył ten sam call?
Grader kosztu i czasu
Dwie wersje mogą osiągać podobny wynik, ale jedna zużywa pięć razy więcej tokenów i wykonuje kilkanaście zbędnych kroków. W produkcie to nie jest detal.
Uruchamiaj więcej niż jedną próbę
Modele nie są deterministyczne. Jeden sukces albo jedna porażka nie mówi wiele o stabilności.
Dla ważnych przypadków uruchom kilka prób i zapisuj:
- success rate,
- liczbę kroków,
- koszt,
- czas,
- częstotliwość eskalacji do człowieka,
- rodzaj błędów.
Jeśli wynik zmienia się mocno między próbami, średnia może być mniej ważna niż rozrzut.
Testuj skutki uboczne
Najbardziej niebezpieczne błędy często nie są widoczne w odpowiedzi. Agent utworzył poprawny dokument, ale przy okazji nadpisał istniejący. Wysłał wiadomość do właściwej osoby, tylko dwa razy.
Środowisko testowe powinno pozwalać na sprawdzenie diffu stanu przed i po wykonaniu. Przy narzędziach zapisujących przydają się:
- idempotency keys,
- tryb dry run,
- izolowana baza lub sandbox,
- lista dozwolonych operacji,
- pełny log wywołań.
Więcej o tej warstwie opisuję w artykule o środowisku agenta AI.
Evals przed produkcją i po wdrożeniu
Zestaw testów powinien działać przy każdej zmianie modelu, promptu, narzędzia albo pamięci. Nie chodzi o to, aby raz „zaliczyć benchmark”. Chodzi o wykrycie regresji.
Produkcja dostarcza kolejne przypadki. Błąd, który przeszedł do użytkownika, powinien trafić do zestawu jako nowy test. W ten sposób eval rośnie razem z rzeczywistym systemem, a nie z wyobrażeniem zespołu o tym, co może pójść źle.
Minimalny eval loop
Na start wystarczy:
- 20 realistycznych zadań,
- izolowane środowisko,
- deterministyczne sprawdzenie outcome,
- zapis pełnego trace,
- trzy próby dla krytycznych przypadków,
- raport różnic względem poprzedniej wersji.
Jeśli nie potrafimy zapisać warunku sukcesu, problem może nie być jeszcze gotowy na autonomię. Wtedy lepszym produktem jest agent proponujący wynik do zatwierdzenia niż agent samodzielnie wykonujący operację.
Źródła
Chcesz zbudować agenta AI, MVP albo aplikację?
Projektuję i buduję produkty z AI od pierwszej wersji do produkcji: MVP, aplikacje mobilne w React Native, web appy i agentów AI. Napisz, co chcesz zbudować, a odpowiem, od czego zacząć.