Evaluácia AI agentov: ktoré metriky sú rozhodujúce
Evaluácia AI agentov meria, či AI agent spoľahlivo rieši zamýšľanú úlohu. Kľúčové metriky sú miera úspešnosti úloh (task success rate), správnosť trajektórie a volaní nástrojov, groundedness, resp. miera halucinácií, latencia, náklady a miera eskalácie na človeka (HITL). Meria sa offline na evaluačnom datasete a online v produkčnej prevádzke.
Na prvý pohľad
- Jedno číslo, ako je miera úspešnosti úloh, nestačí: kvalitu, správnosť volaní nástrojov, groundedness, latenciu, náklady a mieru eskalácie treba posudzovať spoločne.
- Spoľahlivosť (pass^k, konzistencia vo viacerých behoch) je často dôležitejšia než presnosť pri jednom behu. Agent s 90 % úspešnosťou, ktorý zlyháva nepredvídateľne, je horší než agent s 80 % a predvídateľným chybovým správaním.
- Offline evaluácie na uzamknutom golden sete prinášajú dôkazy pred nasadením, online monitoring zachytí drift a reálne chyby. Oboje je potrebné a navzájom sa nenahrádzajú.
- LLM-as-Judge škáluje hodnotenie, no nenahrádza analýzu chýb. Binárne pass/fail s odôvodnením funguje lepšie než škály 1-5; hodnotiace modely treba kalibrovať voči ľudským anotátorom.
- Agentové benchmarky ako SWE-bench alebo GAIA dokazujú schopnosti, nie vhodnosť pre konkrétny prípad použitia. Dôkazom pre produkčné nasadenie je vlastný evaluačný dataset v jazyku tvojich používateľov, pri DACH zákazníkoch v nemčine.
- Golden set s 200-500 príkladmi na prípad použitia má najväčší dosah v celom evaluačnom programe a pri vysokorizikových systémoch AI je základom monitorovania po uvedení na trh, ktoré poskytovateľovi ukladá čl. 72 AI Act.
Evaluácia AI agentov meria, či AI agent spoľahlivo rieši zamýšľanú úlohu. Kľúčové metriky sú miera úspešnosti úloh (task success rate), správnosť trajektórie a volaní nástrojov, groundedness, resp. miera halucinácií, latencia, náklady a miera eskalácie na človeka (HITL). Meria sa offline na evaluačnom datasete a online v produkčnej prevádzke. Evaluácia je disciplína, ktorá rozhoduje o tom, či agent smie opustiť laboratórium. Odkedy existujú AI Act, norma ISO/IEC 42001 a očakávania BaFin a FINMA v oblasti modelového rizika, stala sa z výskumnej praxe compliance artefaktom.
Najdôležitejší poznatok na úvod: jedno číslo v rebríčku už nedokazuje, že agent funguje. Tím z Princetonu, ktorý stojí za Holistic Agent Leaderboard (HAL), ukazuje, že 18 mesiacov pokroku v schopnostiach prinieslo len malé zlepšenie spoľahlivosti, zatiaľ čo samotná presnosť stabilne rástla. Kto chce prevádzkovať agentov produkčne a v súlade s predpismi, potrebuje viacrozmernú sadu metrík.
Rýchle odpovede:
- Miera úspešnosti úloh je najdôležitejšia samostatná metrika, no nikdy nestačí: treba sledovať aj kvalitu, správnosť volaní nástrojov, náklady a spoľahlivosť.
- Offline evaluácie (pevný dataset, LLM-as-Judge) prinášajú dôkazy pred nasadením; online monitoring zachytí drift a reálne chyby. Oboje je potrebné.
- Agentové benchmarky dokazujú schopnosti, nie vhodnosť pre tvoj prípad použitia: dôkazom je vlastný evaluačný dataset v jazyku tvojich používateľov, pri DACH zákazníkoch v nemčine.
Šesť rodín metrík pre AI agentov
Úplný evaluačný program vyprodukuje pri každom vydaní aspoň jedno číslo z každej relevantnej kategórie a trojuholník napätia medzi nákladmi, kvalitou a bezpečnosťou vynesie na Paretovu hranicu, namiesto toho, aby ho zredukoval na jedno skóre.
Metrika | Čo ukazuje | Metóda |
|---|---|---|
Miera úspešnosti úloh (binárna) | Podiel správne vyriešených úloh podľa skutočného výsledku, ústredný ukazovateľ | Hodnotenie výsledku (outcome scorer): presná zhoda (exact match), kontrola vykonaním alebo LLM-as-Judge voči referencii |
Správnosť trajektórie/krokov | Či bol správny každý krok viacstupňového postupu, nielen konečný výsledok | Hodnotenie po krokoch (v štýle PRM), porovnanie trajektórie s kanonickou cestou riešenia |
Správnosť volaní nástrojov | Či agent zavolal správny nástroj so správnymi argumentmi v správnom poradí | Zhoda AST/JSON schémy (prístup BFCL) alebo porovnanie výsledkov vykonania; plus miera zotavenia pri chybách nástrojov |
Groundedness / miera halucinácií | Podiel tvrdení, ktoré pokrýva získaný kontext alebo znalosti o svete | Extrakcia tvrdení a overenie každého tvrdenia zvlášť (RAGAS Faithfulness, MiniCheck, Vectara HHEM) |
Latencia (P50/P95/P99) | Čas odozvy na úlohu vrátane chvostovej latencie pri agentoch, ktoré priamo obsluhujú používateľov | Meranie reálneho času (wall clock) na úlohu; percentily chvosta namiesto priemeru |
Náklady | Vstupné, výstupné a reasoning tokeny a € na úlohu, resp. € na 1 000 úloh | Počítanie tokenov na span; reasoning tokeny zvlášť (pri reasoning modeloch môžu dominovať) |
Miera HITL/eskalácie | Podiel úloh, pri ktorých agent odovzdá prácu človeku | Počítanie odovzdaní človeku (human in the loop) na úlohu |
Konzistencia / pass^k | Či N opakovaných behov s rovnakým vstupom prinesie rovnaký výsledok | pass^k (všetkých k behov úspešných), smerodajná odchýlka z 3 až 5 behov |
Dva body si zaslúžia zdôraznenie. Po prvé, miera eskalácie nie je čisto negatívny signál: dobre nastavená eskalácia na človeka je žiaduca funkcia, nie chyba; rozhodujúce je, aby agent odovzdával správne prípady. Po druhé, spoľahlivosť je často dôležitejšia než presnosť. Agent, ktorý uspeje v 90 % prípadov, no vo zvyšných 10 % zlyháva nepredvídateľne, je v produkčnej prevádzke v DACH často horší než agent s 80 % úspešnosťou a predvídateľným chybovým správaním, z ktorého sa dá zotaviť. τ-bench od spoločnosti Sierra ukazuje, že pass^k (všetkých k behov úspešných) pri mnohých modeloch do k=8 výrazne klesá: ten istý agent, tá istá úloha, a predsa citeľne odlišné výsledky v jednotlivých behoch. Kto uvádza len jeden beh s jedným seedom, tento rozptyl skrýva. Minimálny štandard: priemer plus štandardná chyba z 3 až 5 behov.
Offline evaluácie vs. online monitoring
Základná dichotómia tejto disciplíny je offline verzus online a zrelé programy využívajú obe strany.
Offline evaluácia beží dávkovo na pevnom, verzionovanom datasete. Je deterministická, opakovateľná a prináša dôkazy pred nasadením, ktoré čl. 15 AI Act vyžaduje pri vysokorizikových systémoch: presnosť sa musí merať a deklarovať, nie len proklamovať ako cieľ. Offline evaluácie sú miestom pre LLM-as-Judge voči referenčným odpovediam a pre systematické prechádzanie známych okrajových prípadov.
Online evaluácia hodnotí reálnu produkčnú prevádzku. Je mostom medzi „nasadili sme“ a „vieme preukázať, že systém naďalej pracuje v rámci tolerancií“. Pri vysokorizikových systémoch AI vyžaduje čl. 72 AI Act od poskytovateľa práve takéto priebežné sledovanie po uvedení na trh (post-market monitoring). Osvedčené vzory nasadenia:
- Shadow Mode: nový systém beží paralelne s rovnakými vstupmi, jeho výstupy sa však používateľom nezobrazujú, ale logujú a porovnávajú. De facto štandard pred každým vysokorizikovým nasadením.
- Canary Deployment: 1-5 % prevádzky ide na nový systém, ďalšie nasadzovanie závisí od metrík v reálnom čase. Dôležité: metriky na bráne musia obsahovať evaluačné skóre, nielen latenciu a chybovosť.
- Eval Gates: automatické prahové hodnoty, ktoré zastavia nasadzovanie (napr. „zastav postup do ďalšej fázy nasadenia, ak faithfulness v 4-hodinovom okne klesne pod 0,85“).
Keďže hodnotiace LLM modely sú pri každom zázname (trace) neúmerne drahé, vzorkuje sa. Rozumná východisková konfigurácia pre stredné podniky: 1-5 % stratifikované náhodné vzorkovanie plus 100 % vzorkovanie riadené anomáliami (dlhé relácie, veľa opakovaní, explicitná negatívna spätná väzba). Lacné heuristiky (kontrola osobných údajov, kontrola formátu, rozpoznanie odmietnutí) bežia synchrónne priamo v toku; drahé evaluácie hodnotiacimi modelmi asynchrónne na vzorke. Toto rozdelenie na synchrónnu a asynchrónnu časť je najdôležitejšia páka na náklady: bez neho môžu náklady na evaluáciu prevýšiť náklady na inferenciu 2- až 5-násobne.
Online evaluácia by sa mala navyše opierať o reálne správanie používateľov, nielen o skóre hodnotiacich modelov: miera kopírovania, úpravy po vložení, miera opakovaní a miera predčasného ukončenia sú pomalé, ale spoľahlivé ground-truth signály. V DACH je miera kliknutí na palec hore/dole z kultúrnych dôvodov nižšia než v USA, čo oslabuje výpovednú hodnotu explicitných signálov spätnej väzby.
LLM-as-Judge: užitočné, ale nefunguje samo od seba
Kanonická referencia (Zheng et al., 2023) ukazuje, že silné hodnotiace modely dosahujú viac než 80 % zhody s kontrolovanými ľudskými hodnoteniami, teda rovnakú úroveň ako zhoda medzi ľuďmi navzájom. Platí to však pre úlohy založené na názore; pri obsahu v nemčine, kde rozhoduje faktická správnosť (právo, medicína, financie), zostáva štandardom ľudské hodnotenie.
Praktické odporúčania z praxe:
- Binárne namiesto Likertovej škály. Pass/fail s vypísanou kritikou funguje lepšie než škály 1-5, pretože hranica medzi 3 a 4 je medzi hodnotiacimi modelmi aj medzi behmi nestabilná.
- Zmierniť známe skreslenia. Pozičné skreslenie zámenou poradia a spriemerovaním oboch poradí; skreslenie v prospech dlhších odpovedí (verbosity bias) kontrolou dĺžky; skreslenie v prospech vlastných výstupov (self-enhancement bias) hodnotiacimi modelmi z inej modelovej rodiny alebo súborom viacerých hodnotiacich modelov.
- Kalibrovať. Zhodu hodnotiaceho modelu s človekom uvádzať ako Cohenovu kappu alebo Krippendorffovu alfu skôr, než sa hodnotiacemu modelu v produkcii začne dôverovať.
- Obmedziť náklady. Orientačné pravidlo: na evaluáciu vyčleniť 10-30 % nákladov na inferenciu; s reasoning hodnotiacimi modelmi to môže stúpnuť nad 50 %. Vzor: reasoning hodnotiace modely pre validačnú sadu, lacné špecializované hodnotiace modely (napríklad modely typu MiniCheck) pre vzorkovanie v produkcii.
Rozhodujúce je, že LLM-as-Judge nenahrádza analýzu chýb. Ľudia z praxe sa zhodujú, že 60-80 % úsilia na evaluáciu by malo aj naďalej ísť do prezerania dát, hľadania typov zlyhaní a ich prekladu do pass/fail kontrol.
Ako vybudovať evaluačný dataset a evaluačnú slučku
Spoľahlivý golden set má zdokumentovaný pôvod, rubriku na označovanie, zhodu medzi anotátormi a výslovné pokrytie reálnych prípadov použitia. Praktický recept:
- Navzorkovať 200-500 reálnych používateľských záznamov (traces); anonymizovať osobné údaje (PII) podľa čl. 32 GDPR.
- Dvaja odborníci označia každý záznam výsledkom a kritikou; vypočítať Cohenovu kappu, vyriešiť nezhody.
- Doplniť 50-100 adverzariálnych okrajových prípadov (edge cases) napísaných expertmi, ktoré testujú hranice pravidiel.
- Pridať 100-200 syntetických prípadov naprieč zdokumentovanými dimenziami (funkcie × scenáre × persony).
- Oddeliť 30 % ako uzamknutú testovaciu sadu, ktorá sa nikdy nepoužije na ladenie; 70 % na iterácie.
- Verzionovať, zdokumentovať dataset card, štvrťročne aktualizovať.
Pri pilote v stredne veľkej firme v DACH potrebuje golden set s 500 položkami na začiatku približne 3-6 týždňov času expertov a potom asi týždeň za štvrťrok. To má najväčší dosah v celom evaluačnom programe.
Priebežná evaluačná slučka spája oba svety: požiadavka používateľa → beh agenta → emitovanie trace spanov (OpenTelemetry) → vrstva vzorkovania → evaluačná vrstva (hodnotiace LLM modely plus heuristiky plus malé hodnotiace modely) → úložisko evaluácií → dashboard → alert pri prekročení prahu → spätná väzba do golden setu. Zrelé programy z toho robia CI/CD bránu: každý pull request, ktorý mení prompt, výber modelu, konfiguráciu retrievalu alebo definíciu nástroja, spustí sadu evaluačných testov; merge zlyhá, ak úspešnosť (pass rate) klesne pod prah. Aj zmena verzie modelu u poskytovateľa by mala spustiť automatickú opätovnú evaluáciu skôr, než sa nový model dostane do produkčného routingu. Uzamknutý golden set by sa mal voči živému systému znova vyhodnocovať aspoň raz týždenne, pri produkčne kritických agentoch denne, aby sa regresia modelu alebo promptu dala oddeliť od čistého driftu prostredia.
Pre rezidenciu dát v súlade s GDPR sa hodia nástroje, ktoré si môžeš hostovať sám, napríklad Langfuse založený v Nemecku (self-hosting s využitím ClickHouse a Postgres) alebo Arize Phoenix postavený natívne na OTel; RAGAS je de facto štandardná knižnica pre RAG metriky (Faithfulness, Context Precision, Answer Relevancy), DeepEval a Inspect AI pokrývajú evaluácie blízke CI/CD a evaluácie relevantné pre bezpečnosť. (Stav 2026; trh s nástrojmi na evaluáciu sa práve konsoliduje prostredníctvom akvizícií, napríklad Cisco/Galileo.)
Vymedzenie voči benchmarkom modelov
Častou a drahou chybou v uvažovaní je zamieňať benchmarkové skóre s dôkazom vhodnosti. Model-card eval je marketingový, resp. výskumný artefakt poskytovateľa modelu: snímka schopností na verejných benchmarkoch. Compliance eval je regulačný artefakt firmy, ktorá agenta vyvíja alebo nasadzuje: meranie pred nasadením aj priebežne voči skutočnému prípadu použitia, datasetu a rizikovému profilu, so zdokumentovanou metodikou, verzionovanými hodnotiacimi nástrojmi (scorers) a auditnou stopou. Ide o rôzne artefakty s rôznymi adresátmi a väčšina regulátorov model card ako náhradu neakceptuje.
Tri dôvody, prečo benchmarkové skóre poskytujú len kontext:
- Kontaminácia. Každý benchmark, ktorého dataset bol verejne dostupný pred rokom 2024, je pravdepodobne v tréningových dátach. Príklad: Claude Opus 4.5 dosahuje podľa spoločnosti Anthropic 80,9 % na SWE-bench Verified, podmnožine vybranej v roku 2024 zo SWE-bench zverejneného v roku 2023. Na SWE-bench Pro, ktorý je voči kontaminácii odolnejší, dosahuje vo verejnom rebríčku Scale AI naopak 45,9 % (stav k októbru 2026). Rozdiel nespôsobuje iba kontaminácia: SWE-bench Pro je aj konštrukčne ťažší (referenčné riešenia menia v priemere 107 riadkov kódu v 4,1 súboroch) a obe hodnoty pochádzajú z rôznych meracích postupov (údaj výrobcu verzus rebríček). Ukazuje však, ako silno skóre závisí od dizajnu benchmarku a od možnej kontaminácie.
- Závislosť od scaffoldu. „Líder rebríčka GAIA“ je bez uvedenia scaffoldu bezvýznamný údaj: medzi skóre so scaffoldom (Princeton HAL s Claude Sonnet 4.5: 74,6 %) a bez neho je rozdiel približne 30 percentuálnych bodov.
- Reward hacking. Práca UC Berkeley RDI (apríl 2026) ukázala, že automatizovaný skenovací agent dokázal všetkých osem veľkých agentových benchmarkov nahackovať na takmer dokonalé skóre bez toho, aby vyriešil jedinú úlohu.
Obhájiteľná pozícia pre compliance dokumentáciu v DACH: citovať viacero benchmarkov z rôznych rodín, uvádzať náklady a rozptyl, doplniť ich o privátne golden sety zákazníka a písomne priznať limity. Anglické agentové benchmarky (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) sa hodia na určenie základnej úrovne schopností; skutočným dôkazom zostáva nemeckojazyčný evaluačný dataset, ideálne namapovaný na katalógy kritérií BSI.
Pre agentúry a vedenie B2B firiem
Kto plánuje alebo prevádzkuje AI agentov pre zákazníkov z DACH, mal by evaluáciu chápať ako priebežnú disciplínu, nie ako dodatočný test: nemeckojazyčný golden set ako základ, offline brány pred spustením, potom online monitoring s detekciou driftu a k tomu sada metrík, ktorá berie spoľahlivosť a náklady rovnako vážne ako holú mieru úspešnosti. Pri vysokorizikových systémoch AI je tento evaluačný základ zároveň podkladom pre monitorovanie po uvedení na trh. Čl. 15 a čl. 72 AI Act však zaväzujú len poskytovateľov takýchto systémov. Pre väčšinu marketingových agentov je dôsledný evaluačný program osvedčená prax, nie zákonná povinnosť. Blck Alpaca z Viedne pomáha agentúram a B2B firmám takýto evaluačný program nastaviť, od golden setu cez výber nástrojov až po compliance dokumentáciu, ktorá obstojí pri audite. Ozvi sa nám, ak majú tvoji agenti ísť do produkcie merateľne a v súlade s pravidlami.
Otvorí chat s pripraveným promptom.
Často kladené otázky
Ktorá metrika je pri evaluácii AI agentov najdôležitejšia?
Aký je rozdiel medzi offline a online evaluáciou?
Stačia benchmarkové skóre ako SWE-bench alebo GAIA ako dôkaz kvality?
Aký spoľahlivý je LLM-as-Judge?
Ako vybudovať evaluačný dataset pre AI agentov?
Ísť hlbšie?
Získajte nové analýzy priamo do schránky, alebo sa pozrite, ako tieto poznatky nasadzujeme pre firmy.