AI agent evaluation: które metryki się liczą
Ewaluacja agentów AI mierzy, czy agent AI niezawodnie wykonuje zamierzone zadanie. Kluczowe metryki to wskaźnik sukcesu zadań, poprawność trajektorii i wywołań narzędzi, ugruntowanie (groundedness) lub odsetek halucynacji, latencja, koszty oraz wskaźnik eskalacji HITL. Pomiar odbywa się offline na zbiorze ewaluacyjnym i online w środowisku produkcyjnym.
W skrócie
- Jedna liczba, taka jak wskaźnik sukcesu zadań, nie wystarczy: jakość, poprawność użycia narzędzi, ugruntowanie, latencję, koszty i wskaźnik eskalacji trzeba analizować łącznie.
- Niezawodność (pass^k, spójność w wielu przebiegach) jest często ważniejsza niż dokładność pojedynczego przebiegu. Agent ze skutecznością 90%, który zawodzi w nieprzewidywalny sposób, jest gorszy niż agent z wynikiem 80% i przewidywalnym zachowaniem w razie błędów.
- Ewaluacje offline na zamrożonym zbiorze referencyjnym (golden set) dostarczają dowodów przed wdrożeniem, a monitoring online wychwytuje dryf i rzeczywiste błędy. Potrzebne są oba podejścia i jedno nie zastępuje drugiego.
- LLM-as-Judge pozwala skalować ocenę, ale nie zastępuje analizy błędów. Binarna ocena pass/fail z uzasadnieniem wypada lepiej niż skale 1-5; sędziów LLM trzeba kalibrować względem ludzkich anotatorów.
- Benchmarki agentów, takie jak SWE-bench czy GAIA, potwierdzają możliwości, a nie przydatność do konkretnego przypadku użycia. Dowodem gotowości do wdrożenia produkcyjnego jest własny zbiór ewaluacyjny w Twoim języku.
- Zbiór referencyjny liczący 200-500 przykładów na przypadek użycia to największa dźwignia w całym programie ewaluacji, a w przypadku systemów AI wysokiego ryzyka podstawa monitorowania po wprowadzeniu do obrotu, które dostawca prowadzi zgodnie z art. 72 AI Act.
Ewaluacja agentów AI mierzy, czy agent AI niezawodnie wykonuje zamierzone zadanie. Kluczowe metryki to wskaźnik sukcesu zadań, poprawność trajektorii i wywołań narzędzi, ugruntowanie (groundedness) lub odsetek halucynacji, latencja, koszty oraz wskaźnik eskalacji HITL. Pomiar odbywa się offline na zbiorze ewaluacyjnym i online w środowisku produkcyjnym. Ewaluacja to dyscyplina, która decyduje, czy agent może opuścić laboratorium, a za sprawą unijnego AI Act, normy ISO/IEC 42001 i oczekiwań BaFin oraz FINMA dotyczących ryzyka modeli z praktyki badawczej stała się artefaktem compliance.
Najważniejszy wniosek na początek: pojedynczy wskaźnik w rankingu nie jest już dowodem, że agent działa. Zespół z Princeton stojący za Holistic Agent Leaderboard (HAL) pokazuje, że 18 miesięcy postępu w możliwościach przyniosło jedynie niewielką poprawę niezawodności, podczas gdy sama dokładność stale rosła. Jeśli chcesz używać agentów produkcyjnie i zgodnie z przepisami, potrzebujesz wielowymiarowego zestawu metryk.
Szybkie odpowiedzi:
- Wskaźnik sukcesu zadań to najważniejszy pojedynczy wskaźnik, ale nigdy nie wystarcza: liczą się też jakość, poprawność użycia narzędzi, koszty i niezawodność.
- Ewaluacje offline (stały zbiór danych, LLM-as-Judge) dostarczają dowodów przed wdrożeniem; monitoring online wychwytuje dryf i rzeczywiste błędy. Potrzebne są oba podejścia.
- Benchmarki agentów potwierdzają możliwości, a nie przydatność do Twojego przypadku użycia: dowodem jest własny zbiór ewaluacyjny w Twoim języku.
Sześć rodzin metryk dla agentów AI
Kompletny program ewaluacji generuje przy każdym wydaniu co najmniej jedną liczbę z każdej istotnej kategorii i przedstawia trójkąt napięć między kosztami, jakością i bezpieczeństwem na froncie Pareto, zamiast sprowadzać go do jednego wyniku.
Metryka | Co pokazuje | Metoda |
|---|---|---|
Wskaźnik sukcesu zadań (binarny) | Odsetek zadań rozwiązanych poprawnie według faktycznego wyniku, główna liczba w każdym podsumowaniu | Scorer wyniku: exact match, weryfikacja przez wykonanie lub sędzia LLM względem odpowiedzi referencyjnej |
Poprawność trajektorii / kroków | Czy każdy krok wieloetapowego procesu był poprawny, a nie tylko wynik końcowy | Ocena każdego kroku (w stylu PRM), dopasowanie trajektorii do kanonicznej ścieżki rozwiązania |
Poprawność wywołań narzędzi | Czy wywołano właściwe narzędzie z poprawnymi argumentami i we właściwej kolejności | Dopasowanie AST/schematu JSON (podejście BFCL) lub porównanie wyników wykonania; do tego wskaźnik odzyskiwania po błędach narzędzi |
Ugruntowanie (groundedness) / odsetek halucynacji | Odsetek twierdzeń pokrytych przez pobrany kontekst lub wiedzę ogólną | Ekstrakcja twierdzeń i weryfikacja każdego z nich (RAGAS Faithfulness, MiniCheck, Vectara HHEM) |
Latencja (P50/P95/P99) | Czas odpowiedzi na zadanie, w tym latencja ogona (tail latency) w agentach obsługujących użytkowników | Pomiar czasu rzeczywistego (wall-clock) na zadanie; percentyle ogona zamiast średniej |
Koszty | Tokeny wejściowe, wyjściowe i rozumowania oraz € na zadanie lub € na 1000 zadań | Liczenie tokenów na span; tokeny rozumowania osobno (w modelach rozumujących mogą dominować) |
Wskaźnik HITL / eskalacji | Odsetek zadań, w których agent przekazuje sprawę człowiekowi | Liczba przekazań human-in-the-loop na zadanie |
Spójność / pass^k | Czy N powtórzonych przebiegów z tym samym wejściem daje ten sam wynik | pass^k (wszystkie k przebiegów udane), odchylenie standardowe z 3-5 przebiegów |
Dwie kwestie zasługują na wyróżnienie. Po pierwsze, wskaźnik eskalacji nie jest sygnałem wyłącznie negatywnym: dobrze dostrojona eskalacja do człowieka to funkcja, a nie defekt; kluczowe jest, by agent przekazywał właściwe przypadki. Po drugie, niezawodność jest często ważniejsza niż dokładność. Agent, który odnosi sukces w 90% przypadków, ale w pozostałych 10% zawodzi w nieprzewidywalny sposób, w środowisku produkcyjnym często wypada gorzej niż agent ze skutecznością 80%, którego błędy są przewidywalne i możliwe do opanowania. τ-bench firmy Sierra pokazuje, że pass^k (wszystkie k przebiegów udane) w wielu modelach wyraźnie spada aż do k=8: ten sam agent, to samo zadanie, istotnie różne wyniki w kolejnych przebiegach. Kto raportuje tylko jeden przebieg z jednym seedem, ukrywa tę wariancję. Minimalny standard: średnia plus błąd standardowy z 3-5 przebiegów.
Ewaluacje offline a monitoring online
Fundamentalna dychotomia tej dyscypliny to offline kontra online, a dojrzałe programy korzystają z obu stron.
Ewaluacja offline działa wsadowo na stałym, wersjonowanym zbiorze danych. Jest deterministyczna, powtarzalna i dostarcza dowodów przed wdrożeniem, których art. 15 AI Act wymaga dla systemów wysokiego ryzyka: dokładność trzeba zmierzyć i zadeklarować, a nie przedstawiać jako aspirację. Ewaluacje offline to miejsce na LLM-as-Judge z odpowiedziami referencyjnymi i na systematyczne sprawdzanie znanych przypadków brzegowych.
Ewaluacja online ocenia rzeczywisty ruch produkcyjny. To pomost między „wdrożyliśmy” a „możemy wykazać, że system nadal działa w granicach tolerancji”. W przypadku systemów AI wysokiego ryzyka art. 72 AI Act wymaga od dostawcy właśnie takiego bieżącego nadzoru po wprowadzeniu systemu do obrotu (post-market monitoring). Sprawdzone wzorce wdrożeniowe:
- Shadow mode: nowy system działa równolegle na tych samych danych wejściowych, ale jego odpowiedzi nie trafiają do użytkowników, tylko są logowane i porównywane. To standard de facto przed każdym wdrożeniem wysokiego ryzyka.
- Canary deployment: 1-5% ruchu trafia do nowego systemu, a dalszy rollout zależy od metryk w czasie rzeczywistym. Ważne: metryki bramkujące muszą obejmować wyniki ewaluacji, a nie tylko latencję i odsetek błędów.
- Eval gates: automatyczne progi, które zatrzymują rollout (np. „wstrzymaj promocję, jeśli faithfulness spadnie poniżej 0,85 w 4-godzinnym oknie”).
Ponieważ uruchamianie sędziów LLM na każdym śladzie jest zaporowo drogie, stosuje się próbkowanie. Rozsądna konfiguracja startowa dla MŚP: 1-5% stratyfikowanego próbkowania losowego plus 100% próbkowania wyzwalanego anomaliami (długie sesje, wiele ponowień, jawny negatywny feedback). Tanie heurystyki (kontrola PII, sprawdzenie formatu, wykrywanie odmów) działają synchronicznie, inline; drogie ewaluacje z udziałem sędziów działają asynchronicznie na próbce. Ten podział sync/async to najważniejsza dźwignia kosztowa: bez niego koszt ewaluacji może 2- do 5-krotnie przewyższyć koszty inferencji.
Ewaluację online warto też zakotwiczyć w rzeczywistym zachowaniu użytkowników, a nie tylko w ocenach sędziów: odsetek kopiowania i wklejania, edycje po wklejeniu, odsetek ponowień i odsetek porzuceń to powolne, ale wiarygodne sygnały ground truth. W regionie DACH (Niemcy, Austria, Szwajcaria) odsetek kliknięć kciuka w górę lub w dół jest kulturowo niższy niż w USA, co osłabia wartość informacyjną jawnych sygnałów feedbacku.
LLM-as-Judge: przydatny, ale nie działa sam
Kanoniczne źródło (Zheng et al., 2023) pokazuje, że silne modele-sędziowie osiągają ponad 80% zgodności z kontrolowanymi ocenami ludzi, czyli ten sam poziom co zgodność między ludźmi. Dotyczy to jednak zadań opartych na opiniach; w przypadku treści w Twoim języku, w których liczy się poprawność faktów (prawo, medycyna, finanse), standardem pozostają referencyjne oceny ludzi.
Wskazówki z praktyki:
- Binarnie zamiast skali Likerta. Pass/fail z rozpisaną krytyką wypada lepiej niż skale 1-5, bo granica między 3 a 4 jest niestabilna u różnych sędziów i w różnych przebiegach.
- Ograniczaj znane zniekształcenia. Bias pozycji: zamieniaj kolejność i uśredniaj obie wersje; bias rozwlekłości: kontroluj długość; bias faworyzowania własnych odpowiedzi: używaj sędziów z innej rodziny modeli albo zespołu sędziów.
- Kalibruj. Raportuj zgodność sędziego z ludźmi jako kappę Cohena lub alfę Krippendorffa, zanim zaufasz sędziemu w produkcji.
- Ograniczaj koszty. Praktyczna reguła: przeznacz na ewaluację 10-30% kosztów inferencji; przy sędziach rozumujących może to wzrosnąć do ponad 50%. Wzorzec: sędziowie rozumujący dla zbioru walidacyjnego, tani wyspecjalizowani sędziowie (np. modele w stylu MiniCheck) do próbkowania produkcyjnego.
Kluczowe: LLM-as-Judge nie zastępuje analizy błędów. Wśród praktyków panuje zgoda, że 60-80% wysiłku ewaluacyjnego powinno nadal przypadać na przeglądanie danych, znajdowanie trybów awarii i przekładanie ich na asercje pass/fail.
Jak zbudować zbiór ewaluacyjny i pętlę ewaluacji
Solidny zbiór referencyjny ma udokumentowane pochodzenie, rubrykę oznaczania, zgodność między anotatorami i wyraźne pokrycie rzeczywistych przypadków użycia. Praktyczny przepis:
- Wybierz próbkę 200-500 rzeczywistych śladów użytkowników; zamaskuj PII zgodnie z art. 32 RODO.
- Dwóch ekspertów dziedzinowych oznacza każdy ślad wynikiem i krytyką; oblicz kappę Cohena, rozstrzygnij konflikty.
- Dodaj 50-100 adwersaryjnych przypadków brzegowych na granicach polityk, napisanych przez ekspertów.
- Dodaj 100-200 przypadków syntetycznych według udokumentowanych wymiarów (funkcje × scenariusze × persony).
- Wydziel 30% jako zamrożony zbiór testowy, którego nigdy nie używasz do strojenia; 70% do iteracji.
- Wersjonuj, dokumentuj dataset card, odświeżaj co kwartał.
W pilotażu w MŚP zbiór referencyjny liczący 500 pozycji wymaga na start około 3-6 tygodni pracy ekspertów, a potem mniej więcej tygodnia na kwartał. To największa dźwignia w całym programie ewaluacji.
Ciągła pętla ewaluacji łączy oba światy: zapytanie użytkownika → przebieg agenta → emisja spanów śladu (OpenTelemetry) → warstwa próbkowania → warstwa ewaluacji (sędziowie LLM plus heurystyki plus sędziowie oparci na małych modelach) → magazyn ewaluacji → dashboard → alert po przekroczeniu progu → informacja zwrotna do zbioru referencyjnego. Dojrzałe programy robią z tego bramkę CI/CD: każdy pull request, który zmienia prompt, wybór modelu, konfigurację retrievalu lub definicję narzędzi, uruchamia zestaw ewaluacji; merge się nie powiedzie, jeśli pass rate spadnie poniżej progu. Również zmiana wersji modelu po stronie dostawcy powinna automatycznie wywołać ponowną ewaluację, zanim nowy model trafi do routingu produkcyjnego. Zamrożony zbiór referencyjny warto ponownie ewaluować na działającym systemie co najmniej raz w tygodniu, a w przypadku agentów krytycznych dla produkcji codziennie, aby oddzielić regresję modelu lub promptu od zwykłego dryfu otoczenia.
Na potrzeby rezydencji danych zgodnej z RODO sprawdzają się narzędzia do samodzielnego hostowania, takie jak założony w Niemczech Langfuse (self-hosting na ClickHouse i Postgres) lub natywnie oparty na OTel Arize Phoenix; RAGAS to biblioteka de facto standardowa dla metryk RAG (Faithfulness, Context Precision, Answer Relevancy), a DeepEval i Inspect AI obejmują ewaluacje bliskie CI/CD i istotne dla bezpieczeństwa. (Stan na 2026 rok; rynek narzędzi ewaluacyjnych właśnie konsoliduje się poprzez transakcje M&A, takie jak Cisco/Galileo.)
Czym ewaluacja różni się od benchmarków modeli
Częstym i kosztownym błędem myślowym jest mylenie wyników benchmarków z dowodem przydatności. Ewaluacja z model card to marketingowy lub badawczy artefakt dostawcy modelu: migawka możliwości na publicznych benchmarkach. Ewaluacja compliance to regulacyjny artefakt firmy, która rozwija lub wdraża agenta: pomiar przed wdrożeniem i na bieżąco względem rzeczywistego przypadku użycia, zbioru danych i profilu ryzyka, z udokumentowaną metodyką, wersjonowanymi scorerami i ścieżką audytu. To różne artefakty dla różnych odbiorców, a większość regulatorów nie akceptuje model card jako zamiennika.
Trzy powody, dla których wyniki benchmarków dają jedynie kontekst:
- Kontaminacja. Każdy benchmark, którego zbiór danych był publicznie dostępny przed 2024 rokiem, najprawdopodobniej znalazł się w danych treningowych. Przykład: według Anthropic Claude Opus 4.5 osiąga 80,9% w SWE-bench Verified, podzbiorze wyselekcjonowanym w 2024 roku z opublikowanego w 2023 roku SWE-bench. Na bardziej odpornym na kontaminację SWE-bench Pro uzyskuje natomiast 45,9% w publicznym rankingu Scale AI (stan na październik 2026). Różnica nie wynika wyłącznie z kontaminacji: SWE-bench Pro jest też z założenia trudniejszy (rozwiązania referencyjne zmieniają średnio 107 linii kodu w 4,1 pliku), a obie wartości pochodzą z różnych konfiguracji pomiarowych (deklaracja producenta kontra ranking). Pokazuje ona jednak, jak mocno wyniki zależą od konstrukcji benchmarku i możliwej kontaminacji.
- Zależność od scaffoldu. „Lider rankingu GAIA” nic nie znaczy bez podania scaffoldu: między wynikami ze scaffoldem (Princeton HAL z Claude Sonnet 4.5: 74,6%) a wynikami bez niego (bare) jest około 30 punktów procentowych różnicy.
- Reward hacking. Praca UC Berkeley RDI (kwiecień 2026) wykazała, że zautomatyzowany agent skanujący potrafił zhakować wszystkie osiem dużych benchmarków agentowych do niemal perfekcyjnych wyników, nie rozwiązując żadnego zadania.
Stanowisko, którego da się bronić w dossier compliance: cytuj kilka benchmarków z różnych rodzin, raportuj koszty i wariancję, uzupełniaj je prywatnymi zbiorami referencyjnymi klienta i pisemnie przyznawaj ich ograniczenia. Anglojęzyczne benchmarki agentów (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) nadają się do ustalenia bazowego poziomu możliwości; właściwym dowodem pozostaje zbiór ewaluacyjny w Twoim języku, najlepiej zmapowany na katalogi kryteriów BSI.
Dla agencji i decydentów B2B
Jeśli planujesz lub utrzymujesz agentów AI dla klientów w Europie, traktuj ewaluację nie jako test na końcu, lecz jako ciągłą dyscyplinę: zbiór referencyjny w języku Twoich klientów jako fundament, bramki offline przed uruchomieniem produkcyjnym, monitoring online z wykrywaniem dryfu po nim, do tego zestaw metryk, który traktuje niezawodność i koszty równie poważnie jak samą skuteczność. W przypadku systemów AI wysokiego ryzyka ten fundament ewaluacyjny jest zarazem podstawą monitorowania po wprowadzeniu do obrotu. Art. 15 i art. 72 AI Act zobowiązują jednak wyłącznie dostawców takich systemów. Dla większości agentów marketingowych porządny program ewaluacji to dobra praktyka, a nie obowiązek prawny. Blck Alpaca z Wiednia pomaga agencjom i firmom B2B wdrożyć taki program ewaluacji, od zbioru referencyjnego przez wybór narzędzi po dossier compliance gotowe na audyt. Odezwij się, jeśli Twoi agenci mają wejść do produkcji w sposób mierzalny i zgodny z przepisami.
Otwiera czat z przygotowanym promptem.
Najczęściej zadawane pytania
Jaka jest najważniejsza metryka w ewaluacji agentów AI?
Czym różni się ewaluacja offline od ewaluacji online?
Czy wyniki benchmarków takich jak SWE-bench lub GAIA wystarczą jako dowód jakości?
Na ile wiarygodny jest LLM-as-Judge?
Jak zbudować zbiór ewaluacyjny dla agentów AI?
Chcesz zgłębić temat?
Otrzymuj nowe analizy prosto na swoją skrzynkę albo zobacz, jak wykorzystujemy tę wiedzę w firmach.