Jak zmierzyć, że agent AI działa dobrze – golden set, LLM-as-judge i testy regresyjne

Prezentacja agenta ma wbudowaną wadę metodologiczną: pokazujący dobiera pytania. Nie ze złej woli – po prostu pamięta, które przypadki działały, i to je pokazuje. Zespół widzi dziesięć trafnych odpowiedzi i wyciąga wniosek o skuteczności całości, podczas gdy zobaczył próbkę dobraną wstecznie.

Skala zjawiska jest udokumentowana. Raport MIT Project NANDA z 2025 r. wskazał, że 95% pilotaży generatywnej AI nie przyniosło mierzalnego efektu w rachunku zysków i strat, przy jednoczesnym bardzo szerokim testowaniu narzędzi – ponad 80% organizacji coś uruchomiło, a wartość wyciągało około 5%. Autorzy nazwali tę różnicę podziałem między adopcją a transformacją.

Z perspektywy wdrożeniowej wniosek jest praktyczny: rzeczą, która oddziela te dwie grupy, nie jest lepszy model ani większy budżet, tylko istnienie sprzężenia zwrotnego. Zespół, który mierzy, poprawia. Zespół, który nie mierzy, po kilku miesiącach nie potrafi powiedzieć, czy jest lepiej niż na starcie – i wtedy budżet znika przy najbliższym przeglądzie.

Jest też druga, cichsza przyczyna, dla której warto mierzyć: bez liczby nie da się obronić projektu, który faktycznie działa. Kierownik, który mówi „ludzie są zadowoleni”, przegrywa z arkuszem oszczędności. Kierownik, który mówi „na zestawie 120 realnych spraw agent daje wynik gotowy do wysłania w 78% przypadków, wobec 41% na starcie”, nie musi niczego bronić.

Zestaw referencyjny to lista przypadków wejściowych wraz z prawidłowym wynikiem, zatwierdzonym przez osobę odpowiedzialną za proces. Nie przez zespół IT i nie przez dostawcę – przez tego, kto na co dzień odpowiada za jakość tej pracy.

Materiał bierze się z historii. Dla agenta obsługi klienta to zamknięte zgłoszenia z ostatniego kwartału. Dla agenta dokumentowego – dokumenty przetworzone ręcznie, wraz z tym, co z nich wyciągnięto. Dla agenta sprzedażowego – zapytania, na które ktoś już odpowiedział. Reguła jest prosta: jeżeli przypadku nie było w rzeczywistości, nie ma go w zestawie.

Dobór ma być celowo nierówny. Około 60% przypadków typowych – tych, które stanowią większość wolumenu. Około 25% trudnych, ale występujących regularnie: nietypowe sformułowania, niekompletne dane, dwie sprawy w jednym zgłoszeniu. I około 15% takich, w których prawidłową odpowiedzią jest odmowa albo przekazanie człowiekowi. Ta ostatnia grupa jest najczęściej pomijana i najbardziej diagnostyczna – agent, który nigdy nie mówi „nie wiem”, jest groźniejszy od agenta o niższej skuteczności.

Rozmiar: 50 przypadków wystarcza na start dla jednego wąskiego procesu, 150–200 daje stabilne wyniki dla agenta obsługującego szerszy zakres. Powyżej tego progu rośnie koszt utrzymania zestawu, a przyrost informacji maleje. Zestaw jest żywy – co kwartał dopisujecie do niego przypadki, na których agent zawiódł w produkcji, bo to są dokładnie te sytuacje, których nie umieliście przewidzieć.

Jedna uniwersalna miara skuteczności nie istnieje, bo różne agenty popełniają różnie kosztowne błędy. Agent, który w obsłudze klienta poda nieaktualny termin dostawy, powoduje inny problem niż agent, który w procesie dokumentowym odczyta zły numer konta.

Dla agenta odpowiadającego na pytania mierzy się trafność merytoryczną, umocowanie w źródle (czy odpowiedź da się wskazać w dokumencie) i odsetek prawidłowych odmów. Dla agenta przetwarzającego dokumenty – dokładność ekstrakcji per pole, odsetek dokumentów gotowych bez poprawki oraz, osobno, dokładność na polach krytycznych, gdzie błąd kosztuje najwięcej. Dla agenta wykonującego operacje – odsetek zadań zakończonych poprawnie bez interwencji i, najważniejsze, odsetek operacji błędnie wykonanych mimo braku sygnału o problemie.

Do każdego typu warto dołożyć jedną miarę wspólną: odsetek przypadków, w których agent poprawnie rozpoznał, że nie powinien działać sam. To jest miara, która najlepiej przekłada się na zaufanie zespołu, a jednocześnie prawie nigdy nie pojawia się w ofertach dostawców.

Metryki ustalcie przed pierwszym pomiarem i zapiszcie razem z progiem akceptacji. Próg jest decyzją biznesową, nie techniczną: dla asystenta podpowiadającego treść maila 85% może być w zupełności wystarczające, dla agenta zapisującego dane w systemie finansowym 99% bywa za mało.

Ręczna ocena dwustu przypadków po każdej zmianie jest nierealna, dlatego część oceny powierza się drugiemu modelowi, który porównuje odpowiedź agenta z wzorcem i wystawia werdykt. To działa – pod warunkiem, że wiecie, jak bardzo sędzia się myli.

Kalibracja polega na tym, że człowiek ocenia losowy podzbiór, na przykład czterdzieści przypadków, i porównujecie jego oceny z ocenami sędziego. Interesuje Was nie tylko zgodność ogólna, ale to, w którą stronę sędzia się przechyla. Typowe skrzywienia są dobrze rozpoznane: modele-sędziowie chętniej akceptują odpowiedzi dłuższe i pewniej sformułowane, gorzej radzą sobie z liczbami i datami, i mają skłonność do łagodniejszej oceny tekstów stylistycznie podobnych do własnych.

Stąd praktyczna zasada podziału pracy. Wszystko, co da się sprawdzić deterministycznie – kwoty, daty, numery dokumentów, identyfikatory, obecność wymaganego pola – sprawdzajcie kodem, nie modelem. Sędziemu zostawcie to, co wymaga oceny sensu: czy odpowiedź jest merytorycznie zgodna z wzorcem, czy ton jest odpowiedni, czy nie pominięto istotnego zastrzeżenia.

Warto też, żeby sędzia był innym modelem niż oceniany agent, i żeby oceniał według jawnej, zapisanej instrukcji z przykładami ocen dobrych i złych. Instrukcja sędziego jest artefaktem projektu tak samo jak zestaw referencyjny – podlega wersjonowaniu, bo jej zmiana zmienia wszystkie wyniki wstecz.

Najbardziej niedoceniane ryzyko w utrzymaniu agenta to zmiana, która nie pochodzi od Was. Dostawca modelu wypuszcza nową wersję, stara jest wygaszana, ktoś przełącza konfigurację – i zachowanie agenta zmienia się w sposób, którego nikt nie zaplanował. Zmiana bywa niewielka i nierównomierna: 95% przypadków działa identycznie, a 5% zaczyna wypadać inaczej.

Awaria byłaby łatwiejsza. Awarię ktoś zgłasza. Pogorszenie o kilka punktów procentowych objawia się tym, że zespół po cichu zaczyna sprawdzać wyniki dokładniej, potem sprawdzać wszystkie, a po kwartale przestaje korzystać. Nikt nie zakłada zgłoszenia, bo nie ma jednego zdarzenia, które można zgłosić.

Test regresyjny rozwiązuje to jednym mechanizmem: cały zestaw referencyjny uruchamiany automatycznie po każdej zmianie promptu, danych źródłowych, definicji narzędzi i wersji modelu, z porównaniem do poprzedniego wyniku i progiem alarmu przy spadku. Spadek poniżej progu blokuje wdrożenie zmiany – tak samo jak czerwony test blokuje wdrożenie kodu.

Do tego dwa nawyki, które kosztują niewiele, a ratują projekty. Po pierwsze: zapisujcie wersję modelu przy każdym wyniku, żeby dało się odtworzyć, na czym mierzyliście. Po drugie: przy zapowiedzianej zmianie wersji przez dostawcę uruchomcie zestaw na nowej wersji, zanim zostaniecie na nią przełączeni – wtedy migracja jest decyzją, a nie niespodzianką.

Zestaw referencyjny mierzy jakość w warunkach laboratoryjnych. Produkcja przynosi pytania, których w zestawie nie ma, więc potrzebna jest druga warstwa pomiaru – lekka, ale ciągła.

Minimum to trzy wskaźniki zbierane automatycznie: odsetek spraw zakończonych bez udziału człowieka, odsetek eskalacji oraz odsetek przypadków, w których człowiek poprawił wynik agenta przed użyciem. Ten ostatni jest najcenniejszy, bo poprawki są gotowym materiałem na rozbudowę zestawu referencyjnego – to najtańsze źródło wiedzy o tym, gdzie agent zawodzi naprawdę.

Do tego cotygodniowy przegląd wyrywkowy: dziesięć losowych spraw ocenionych przez człowieka. Dziesięć spraw to około kwadransa pracy tygodniowo, a wychwytuje dryf, którego automat nie widzi, bo automat porównuje do wzorca, a nie do zdrowego rozsądku.

Raport dla zarządu mieści się na jednej stronie i ma cztery pozycje: skuteczność na zestawie referencyjnym z porównaniem do poprzedniego kwartału i do stanu wyjściowego, wolumen obsłużony przez agenta, oszczędność czasu przeliczona na etaty lub złotówki oraz lista incydentów wraz z reakcją. Ostatnia pozycja jest ważniejsza, niż się wydaje – zarząd, który widzi zgłoszone i obsłużone incydenty, ufa liczbom bardziej niż zarząd, który widzi wyłącznie sukcesy.

Warto do tego dołożyć jedno zdanie o odpowiedzialności: kto przegląda wyniki i kto podejmuje decyzję o wycofaniu agenta, gdyby jakość spadła poniżej progu. Według badania Capgemini Research Institute spisany podział odpowiedzialności między pracownikiem a agentem ma zaledwie 48% organizacji – a jest to dokument, którego brak ujawnia się dokładnie w momencie, gdy jest najbardziej potrzebny.