Ewaluacja agenta AI: testy, golden set i benchmarki przed produkcją

Firma zbudowała agenta obsługi klienta. Agent działa od tygodnia, liczba eskalacji do konsultantów spada. W trzecim tygodniu okazuje się, że agent wywoływał get_order_status z błędnym identyfikatorem zamówienia przez trzy dni, generując fałszywe „zamówienie w drodze" dla połowy zapytań. Nikt nie sprawdził trafności wywołań narzędzi przed wdrożeniem, bo metryki ograniczały się do latencji i liczby obsłużonych rozmów. To wycinek realnego wzorca, który pojawia się przy pierwszym wdrożeniu agentowym w firmach polskich i europejskich.

Ewaluacja agenta AI przed produkcją to odrębna dyscyplina od monitoringu bieżącego. Poniżej opisuję, jak ją zbudować krok po kroku.

Agent nie jest samym modelem językowym. Składa się z modelu, zestawu narzędzi (tool-use), pętli decyzyjnej i często bazy wiedzy RAG. Każdy z tych elementów może zawieść niezależnie od pozostałych. Guardrails mogą działać poprawnie, a agent wciąż wywołuje złe narzędzie z właściwymi uprawnieniami.

Ewaluacja RAG mierzy, czy model generuje odpowiedź wierną dokumentowi źródłowemu. Ewaluacja agenta mierzy trzy dodatkowe wymiary:

• Trafność decyzji o wyborze narzędzia — czy agent wywołał właściwe narzędzie dla danego zapytania?
• Poprawność parametrów wywołania — czy przekazał właściwe argumenty do narzędzia?
• Task success rate — czy wielokrokowe zadanie zakończyło się oczekiwanym wynikiem?

Te trzy wymiary można sprawdzić przed produkcją, ale tylko wtedy, gdy masz golden set z zakodowanymi oczekiwaniami dla każdego z nich.

Golden set to zbiór par: (zapytanie użytkownika, oczekiwane zachowanie agenta). Oczekiwane zachowanie może być różnego poziomu szczegółowości:

• Poziom odpowiedzi — oczekiwany tekst lub fragment do porównania semantycznego
• Poziom narzędzia — oczekiwane narzędzie, które agent powinien wywołać
• Poziom parametrów — oczekiwane argumenty wywołania (np. {"order_id": "{{order_id}}", "locale": "pl"})
• Poziom zadania — oczekiwany stan końcowy po wielokrokowej sekwencji

Dla agenta obsługi klienta pokrywającego statusy zamówień i politykę zwrotów, minimalny golden set to 200-300 przykładów. Podział orientacyjny: 40% pokrywa typowe zapytania (wysoka częstotliwość), 30% pokrywa edge case (wyjątki polityki, brak danych), 30% pokrywa zapytania spoza zakresu (agent powinien eskalować lub odmówić).

Pułapki przy budowaniu golden setu:

Nadreprezentacja przykładów z dokumentacji. Jeśli golden set pochodzi głównie z FAQ lub instrukcji, które model widział podczas fine-tuning lub w RAG, wyniki będą zawyżone względem produkcji. Uzupełnij go o prawdziwe anonimizowane zgłoszenia z poprzednich kanałów.

Brak przykładów błędów narzędzi. Golden set musi zawierać scenariusze, gdzie narzędzie zwraca błąd (timeout, brak rekordu, błędny format). Sprawdź, czy agent obsługuje je gracefully, a nie halucynuje wynik.

Pominięcie przykładów wielojęzycznych. Jeśli agent obsługuje klientów w kilku językach, każdy język potrzebuje osobnego pokrycia. Modele zachowują się różnie dla zapytań w języku mniejszościowym.

Poniższa tabela przedstawia wymiary ewaluacji agenta, rekomendowaną metodę pomiaru i minimalny próg przed dopuszczeniem do produkcji. Progi są punktem wyjścia, nie gwarancją — zależą od krytyczności procesu i ryzyka błędu w Twojej branży.

Trafność wyboru narzędzia poniżej 90% przed produkcją jest sygnałem do rewizji systemu promptu lub przykładów few-shot, nie do wdrożenia z nadzieją na poprawę. Agenci z błędnym tool-use wywołują realne skutki (operacje na danych, rezerwacje, płatności) i nie ma tam mechanizmu cofnięcia analogicznego do błędnej odpowiedzi tekstowej.

LLM-as-judge to metoda, w której drugi model ocenia jakość odpowiedzi pierwszego. Przyspiesza ocenę dużych wolumenów (1 000+ par dziennie), ale ma ograniczenia, które warto znać przed poleganiem na niej.

Kiedy działa dobrze:

• Ocena faithfulness (czy odpowiedź jest wierna dokumentowi źródłowemu) dla systemów RAG z wyraźnymi faktami
• Flagowanie oczywistych halucynacji i odpowiedzi całkowicie poza tematem
• Porównanie dwóch wersji agenta (A/B) na tym samym zestawie pytań

Kiedy zawodzi:

• Ocena poprawności parametrów narzędzi (wymaga deterministycznej walidacji schematu, nie oceny językowej)
• Zadania wymagające wiedzy domenowej, której model-sędzia nie posiada (prawo, medycyna, specyficzne polityki firmy)
• Wykrywanie systematycznych błędów własnego dostawcy (jeśli agent i sędzia używają tego samego bazowego modelu, sędzia może nie widzieć błędu)

Kalibracja jest obowiązkowa. Przed automatycznym użyciem LLM-as-judge oceń 50-100 par ręcznie, porównaj z wynikami sędziego i oblicz korelację Pearsona lub kappa Cohena. Korelacja poniżej 0,75 z oceną ludzką dyskwalifikuje sędziego dla danego wymiaru. Wzorzec kalibracji LLM-as-judge opisuje artykuł o ewaluacji jakości RAG.

Zamiana modelu bazowego (np. przejście na nowszą wersję) lub zmiana promptu systemowego to najczęstsze przyczyny nieoczekiwanych regresji w agentach produkcyjnych. Dostawcy modeli nie gwarantują identycznego zachowania między wersjami.

Testy regresji to uruchomienie golden setu na nowej wersji i porównanie wyników z baselineowym snapsotem. Trzy kroki, żeby działało w praktyce:

1. Zamroź baseline — po przejściu ewaluacji przed produkcją zapisz wyniki (faithfulness score, tool accuracy, task success rate) jako artefakt wersji. To jest Twój punkt porównania przy każdej zmianie.

2. Automatyzuj uruchomienie golden setu — wpnij test regresyjny w pipeline CI/CD lub uruchamiaj ręcznie przed każdym awansem wersji. Dla agentów produkcyjnych tygodniowe uruchomienie na podstawowym zestawie (50-100 par) to minimum.

3. Definiuj progi degradacji — nie każde pogorszenie o 1 punkt procentowy wymaga blokady. Ustal progi: spadek faithfulness o więcej niż 3 pkt procentowe lub tool accuracy poniżej progu PASS blokuje awans. Dryft między kolejnymi testami a nie jednorazowy wynik to sygnał do audytu.

Wzorzec wykrywania dryftu jakości w czasie opisuje artykuł o monitoringu agenta AI. Wpływ zmiany promptu na jakość omawia artykuł o prompt engineeringu dla firm.

Agent może halucynować nie tylko w tekście odpowiedzi, ale w parametrach wywołania narzędzia. Przykład: agent wywołuje create_refund(order_id="ORD-12345") dla zamówienia, które nie istnieje w systemie, bo wyinterpretował ID z treści rozmowy, a nie z prawdziwego rekordu.

Obrona przed tym typem błędu wymaga walidacji po stronie narzędzia (nie tylko po stronie agenta):

• Narzędzie zwraca błąd 404 lub kod błędu, gdy rekord nie istnieje
• Agent ma instrukcję w prompcie systemowym: „Jeśli narzędzie zwróci błąd, nie próbuj ponownie z innymi parametrami. Eskaluj do człowieka."
• Złożone structured-output z walidacją JSON Schema przed przekazaniem do narzędzia

Artykuł o audycie bezpieczeństwa asystenta AI omawia pełen zakres testów bezpieczeństwa przed produkcją, w tym testy injection i nadmiernych uprawnień narzędzi.

Opisz agenta, którego chcesz przetestować przed produkcją, a model wskaże strukturę golden setu, metryki dla Twojego zakresu i progi PASS dopasowane do ryzyka procesu (playground: PII maskowane, zero retencji):

Dla agenta o wąskim zakresie (2-3 narzędzia, jeden proces) minimum to 150-200 par. Dla agentów wielozadaniowych (5+ narzędzi, kilka procesów) optymalny zakres to 400-600 par. Poniżej 150 par pokrycie edge case'ów jest zbyt niskie, żeby wyniki miały wartość predykcyjną. Ważniejszy jest skład zestawu niż jego rozmiar: 30% przykładów spoza zakresu i 30% edge case'ów jest konieczne, by golden set wykrywał realne problemy, a nie tylko potwierdzał działanie happy path.

Nie. Bez kalibracji nie wiadomo, czy sędzia mierzy to samo co człowiek. W projektach, które opierały się na niekalibrowanym LLM-as-judge, oceny były zawyżone o 8-15 punktów procentowych względem ocen domenowych ekspertów. Kalibracja wymaga 50-100 par ocenionych ręcznie i porównania z wynikami sędziego. Jeśli korelacja Pearsona wynosi poniżej 0,75, zmień model-sędziego lub zmień metodę pomiaru dla tego wymiaru.

Najpierw wyizoluj, na którym kroku wielokrokowej sekwencji następuje błąd: trafność wyboru narzędzia, poprawność parametrów czy interpretacja wyniku narzędzia. Jeśli trafność wyboru narzędzia jest stabilna, a parametry się pogorszyły, problem leży w sposób, w jaki nowy model ekstrahuje dane ze struktury rozmowy. Rozwiązaniem jest zazwyczaj dodanie few-shot przykładów do promptu lub bardziej rygorystyczna walidacja structured-output przed wywołaniem. Artykuł o dlaczego projekty AI zawodzą opisuje systemowe przyczyny regresji po zmianie konfiguracji.

Bez historycznych zgłoszeń golden set budujesz z trzech źródeł: (1) dokumentacja procesu i FAQ produktu, (2) wywiady z konsultantami obsługi klienta o typowych i trudnych zapytaniach, (3) dane syntetyczne generowane z opisu procesu. Dane syntetyczne wymagają weryfikacji przez eksperta domenowego przed włączeniem do golden setu, bo LLM generuje przykłady z własnych priorów, które mogą nie odpowiadać realnemu rozkładowi zapytań. Blueprint agenta pomaga zdefiniować zakres narzędzi i scenariusze, które muszą być pokryte.

Tygodniowo dla wdrożeń z wolumenem powyżej 500 zapytań dziennie, co dwa tygodnie dla mniejszych. Obowiązkowo przed każdą zmianą: modelu bazowego, promptu systemowego, zestawu narzędzi i bazy wiedzy RAG. Automatyczne uruchomienie golden setu w CI/CD przy każdym pull requeście zmieniającym konfigurację agenta jest standardem dla systemów produkcyjnych. Wzorzec monitoringu ciągłego opisuje artykuł o monitoringu jakości agenta AI.