Ewaluacja agentów AI: od evals do niezawodnej produkcji
Jak oceniać autonomicznych agentów, którym można zaufać — LLM-as-a-judge zrobione dobrze, metryki, które się liczą, i bramki jakości w CI/CD chroniące przed regresją.
Definicja
Ewaluacja agentów (evals) to systematyczny pomiar jakości agenta względem zdefiniowanych kryteriów — sukcesu zadania, użycia narzędzi, wierności, kosztu i opóźnienia. Łączy automatyczne ocenianie, często z sędzią LLM, oraz przegląd człowieka, prowadzone jako powtarzalna bramka, a nie jednorazowy test.
Demo dowodzi, że agent potrafi zadziałać raz. Ewaluacja dowodzi, że działa niezawodnie, i robi to dalej, gdy model, prompty i narzędzia zmieniają się pod spodem. Bez evals każdy deploy to zgadywanie.
Dlaczego agentów trudno ocenić?
Tradycyjny test sprawdza ustalone wyjście. Agenci są niedeterministyczni i otwarci: akceptowalnych odpowiedzi jest wiele, ścieżka się zmienia, a „poprawne“ znaczy często wierne, użyteczne i bezpieczne, a nie identyczne co do znaku. Ewaluacja przesuwa się więc z asercji ku ocenianiu — punktowaniu wyjść względem kryteriów, na skalę.
LLM-as-a-judge zrobione dobrze
Praktyczny sposób oceniania na skalę to LLM-as-a-judge: model ocenia lub porównuje wyjścia. Jest tani i szybki — i myli się, gdy pominiesz kalibrację. Sędziowie noszą przewidywalne biasy:
- Bias pozycji (kolejność opcji)30%
- Bias rozwlekłości (dłuższe = lepsze)28%
- Samowywyższanie (preferuje własny styl)24%
- Sygnały formatu / autorytetu18%
Kalibracja nie jest opcjonalna. Oznacz 100–200 przykładów ręcznie, odpal na nich sędziego i zmierz zgodność — celuj w kappę Cohena powyżej około 0,6. Losuj kolejność opcji, by zabić bias pozycji, i używaj rubryk zamiast mglistego „oceń 1–10“.
| Bias sędziego | Na czym polega | Jak złagodzić |
|---|---|---|
| Bias pozycji | Preferuje opcję pierwszą lub ostatnią | Losuj kolejność; uśredniaj po zamianach |
| Bias rozwlekłości | Wyżej ocenia dłuższe odpowiedzi | Oceniaj względem rubryki, nie długości |
| Samowywyższanie | Woli własny styl lub model | Użyj innego sędziego; sprawdzaj wyrywkowo z ludźmi |
| Sygnały formatu | Daje się zwieść pewnemu formatowaniu | Oceniaj treść; usuń stylizację |
Metryki, które się liczą
- Wskaźnik ukończenia zadań — czy agent skończył robotę?
- Wierność / wskaźnik halucynacji — czy wyjście jest ugruntowane?
- Trafność wyboru narzędzi — czy wybrał i wywołał właściwe narzędzia?
- Koszt i opóźnienie na zadanie — czy jest przystępny i dość szybki?
Śledź je na stałym zbiorze testowym, by zmiana wyniku znaczyła zmianę agenta, a nie danych.
Evals należą do CI/CD
Najwięcej daje potraktowanie wyselekcjonowanego zbioru przypadków jako golden dataset i odpalanie go przy każdej zmianie. Poprawka promptu, która podnosi jeden przypadek, potrafi zatopić pięć innych; łapie to tylko zestaw regresyjny. Ustaw progi — ukończenie, wierność — i niech build pada, gdy spadną. To eval-driven development: zmieniasz agenta względem mierzalnej poprzeczki, nie przeczucia.
Pętla na start
- Zbuduj mały golden set z realnych, zróżnicowanych przypadków.
- Oceniaj skalibrowanym sędzią plus wyrywkowy przegląd człowieka.
- Bramkuj deploye wskaźnikiem ukończenia i wiernością.
- Powiększaj zbiór za każdym razem, gdy znajdziesz nową awarię na produkcji.
Niezawodni agenci to agenci ewaluowani. Niezawodność, którą tu udowodnisz, uwiarygadnia też nadzór człowieka i ład. Pojęcia definiujemy w słowniku.
Najczęstsze pytania
Czy LLM może wiarygodnie oceniać innego LLM?
Tak, ale dopiero po skalibrowaniu względem osądu człowieka, a nieskalibrowany sędzia jest gorszy niż bezużyteczny, bo mierzy własne preferencje, wyglądając autorytatywnie. Praktyczna procedura to ręcznie oznaczyć reprezentatywny zbiór 100–200 przykładów, odpalić na nim sędziego i zmierzyć zgodność z etykietami człowieka — kappa Cohena powyżej około 0,6 to rozsądna poprzeczka, zanim zaufasz sędziemu w czymkolwiek, co bramkuje deploy. Ma to znaczenie, bo sędziowie noszą dobrze udokumentowane, przewidywalne biasy: preferują opcję pokazaną pierwszą lub ostatnią, wyżej oceniają dłuższe odpowiedzi niezależnie od jakości, wolą własny styl i dają się zwieść pewnemu siebie formatowaniu. Kalibracja plus kilka odruchów obronnych — losowanie kolejności opcji, ocenianie względem jawnej rubryki zamiast mglistego polecenia oceny od jednego do dziesięciu i okresowe sprawdzanie wobec świeżych etykiet człowieka — zamieniają sędziego z obciążenia w szybki, tani scorer. Samego sędziego traktuj jako coś, co ewaluujesz, nie jako prawdę objawioną, którą zakładasz.
Jaka jest najużyteczniejsza pojedyncza metryka agenta?
Wskaźnik ukończenia zadań mierzony względem stałego zbioru testowego, bo odpowiada na pytanie, które naprawdę przesądza o użyteczności agenta — czy kończy robotę, end-to-end — a większość innych metryk to dopracowania, gdy już umiesz na nie odpowiedzieć. Część o stałym zbiorze daje mu zęby: punktowany względem tych samych wyselekcjonowanych przypadków za każdym razem, spadek wskaźnika ukończenia znaczy, że agent się zmienił, a nie że dzisiejszy ruch był trudniejszy, i to właśnie zamienia cichą regresję w widoczną. To też metryka, która przetrwa podmianę modelu albo zmianę promptu jako stabilny punkt odniesienia, więc poznasz, czy zmiana pomogła, czy po cichu zepsuła klasę zadań. Mimo to samo ukończenie potrafi zmylić, gdy porażki są ciche i szkodliwe, więc połącz je z wiernością, a tam gdzie agent działa — z tym, czy porażki są łapane. Zacznij od wskaźnika ukończenia jako nagłówka, potem dodaj resztę jako obsadę wspierającą.
Jak evals wpinają się w CI/CD?
Potraktuj wyselekcjonowany zbiór reprezentatywnych przypadków jako golden dataset i odpalaj go automatycznie przy każdej zmianie modelu, promptów lub narzędzi, dokładnie jak uruchamiasz testy jednostkowe na kodzie. Ustaw jawne progi — minimalny wskaźnik ukończenia, maksymalny wskaźnik halucynacji — i niech build pada, gdy zmiana przepchnie metrykę poza nie, by regresja była zablokowana przed wysyłką, a nie odkryta przez użytkowników. To właśnie ludzie mają na myśli, mówiąc eval-driven development: zmieniasz agenta względem mierzalnej poprzeczki, nie subiektywnego wrażenia, że chyba jest lepiej. Kluczowa dyscyplina to fakt, że poprawka promptu podnosząca jeden przypadek rutynowo pogarsza kilka innych, a tę wymianę łapie tylko zestaw regresyjny prowadzony jako bramka. Trzymaj golden set dość małym, by odpalał się przy każdym commicie, lecz dość reprezentatywnym, by był znaczący, i powiększaj go za każdym razem, gdy produkcja ujawni nowy tryb awarii, tak by zestaw rósł w siłę dokładnie tam, gdzie agent okazał się słaby.
Jak duży powinien być golden set do evals?
Na start mniejszy, niż większość zespołów sądzi, a właściwy rozmiar wyznacza pokrycie i stabilność, nie surowa liczba. Zacznij od kilkudziesięciu do dwustu przypadków dobranych tak, by objęły realny rozkład pracy — częste szczęśliwe ścieżki, ważne skrajne przypadki i konkretne porażki, które już widziałeś — bo mały zbiór pokrywający sposoby, w jakie agent faktycznie zawodzi, jest znacznie użyteczniejszy niż wielki zbiór bliskich duplikatów. Praktyczny test to stabilność statystyczna: jeśli ponowne odpalenie tego samego agenta na zbiorze daje za każdym razem mocno inny wynik, zbiór jest za mały lub za zaszumiony, by na nim bramkować; jeśli wynik jest stabilny, a prawdziwa regresja go rusza, robi swoje. Trzymaj go dość małym, by odpalał się przy każdej zmianie bez spowalniania zespołu, i powiększaj rozmyślnie, dodając przypadek za każdym razem, gdy produkcja ujawni nowy tryb awarii, tak by zestaw kumulował wartość w czasie. Jakość i pokrycie przypadków biją samą ilość, a wyselekcjonowane kilkaset dobrze dobranych przykładów przebije tysiące nadmiarowych.