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ými metrikami sú task-success-rate, korektnosť trajektórie a tool-call, groundedness resp. miera halucinácií, latencia, náklady a miera HITL eskalácie. Meria sa offline voči eval datasetu a online v produkčnej prevádzke. Evaluácia je disciplína, ktorá rozhoduje o tom, či agent smie opustiť laboratórium — a od EU AI Act, ISO/IEC 42001 a očakávaní ohľadom modelového rizika zo strany BaFin a FINMA sa stala z výskumnej praxe compliance artefaktom.

Najdôležitejší poznatok na úvod: jedno samostatné číslo na leaderboarde už nie je dôkazom, že agent funguje. Princetonský tím za Holistic Agent Leaderboard (HAL) ukazuje, že 18 mesiacov pokroku v capability prinieslo len malé zlepšenia v spoľahlivosti, zatiaľ čo samotná presnosť stabilne rástla. Kto chce prevádzkovať agentov produkčne a v súlade s pravidlami, potrebuje viacrozmerný súbor metrík.

Rýchle odpovede:

• Task-success-rate je najdôležitejšou jednotlivou metrikou, ale nikdy nie je dostatočná — kvalita, korektnosť tool-call, náklady a spoľahlivosť k nej patria.
• Offline evaly (fixný dataset, LLM-as-Judge) poskytujú predbežnú evidenciu; online monitoring zachytáva drift a reálne chyby. Oboje je povinnosť.
• Agentové benchmarky dokladujú capability, nie vhodnosť pre váš use-case — dôkazom je vlastný, nemecky jazykový eval dataset.

Šesť rodín metrík pre AI agentov

Úplný eval program produkuje na každý release minimálne jedno číslo z každej relevantnej kategórie a vykresľuje napäťový trojuholník z nákladov, kvality a bezpečnosti na Pareto-fronte, namiesto toho, aby ho skolaboval do jedného skóre.

Dva body si zaslúžia zdôraznenie. Po prvé, miera eskalácie nie je čisto negatívnym signálom: dobre nastavená eskalácia na človeka je feature, nie defekt — rozhodujúce je, že agent odovzdáva tie správne prípady. Po druhé, spoľahlivosť je často dôležitejšia než presnosť. Agent, ktorý je úspešný na 90 %, ale vo zvyšných 10 % zlyháva nepredvídateľne, je v DACH produkčnej prevádzke často horší než agent s 80 % úspešnosťou a plánovateľným, recoverovateľným chybovým správaním. Sierra τ-bench ukazuje, že pass@k pri mnohých modeloch výrazne klesá až do k=8 — ten istý agent, tá istá úloha, materiálne odlišné výsledky naprieč behmi. Kto reportuje len single-seed beh, skrýva tento rozptyl. Minimálny štandard: priemer plus smerodajná chyba naprieč 3-5 behmi.

Offline evaly vs. online monitoring

Fundamentálnou dichotómiou disciplíny je offline versus online — a zrelé programy využívajú obe strany.

Offline evaluácia beží dávkovo voči fixnému, verzionovanému datasetu. Je deterministická, opakovateľná a poskytuje predbežnú evidenciu, ktorú EU AI Act čl. 15 vyžaduje pre vysokorizikové systémy: presnosť sa musí merať a deklarovať, nie aspiratívne tvrdiť. Offline evaly sú miestom pre LLM-as-Judge voči referenčným odpovediam a pre systematické prehrávanie známych edge-cases.

Online evaluácia hodnotí reálny produkčný traffic. Je mostom medzi „nasadili sme" a „vieme podľa čl. 72 doložiť, že systém naďalej pracuje v rámci tolerancií". Osvedčené deployment vzory:

• Shadow Mode — nový systém beží paralelne s rovnakými inputmi, jeho outputy sa však neprehrávajú, ale logujú a porovnávajú. De-facto štandard pred každým vysokorizikovým rolloutom.
• Canary Deployment — 1-5 % traffic-u na nový systém, ďalší rollout závislý od real-time metrík. Dôležité: gate metriky musia obsahovať eval skóre, nielen latenciu a chybovosť.
• Eval Gates — automatické prahové hodnoty, ktoré zastavujú rollout (napr. „zastaviť promotion, ak faithfulness v 4-hodinovom okne klesne pod 0,85").

Keďže LLM-judge modely na každom trace sú prohibitívne drahé, vzorkuje sa. Zmysluplná východisková konfigurácia pre stredné podniky: 1-5 % stratifikované náhodné vzorkovanie plus 100 % anomáliami riadené vzorkovanie (dlhé sessions, mnoho retries, explicitná negatívna spätná väzba). Lacné heuristiky (PII-check, kontrola formátu, rozpoznanie refusal) bežia synchrónne inline; drahé judge evaly asynchrónne na vzorke. Tento sync/async split je najdôležitejšou nákladovou pákou — bez neho môže eval réžia prevýšiť inferenčné náklady 2- až 5-násobne.

Online by sa malo navyše ukotviť na reálnom správaní používateľov, nielen na judge skóre: copy-paste rate, edit-after-paste, retry-rate a miera abandonu sú pomalé, ale skutočne pravdivé signály. V DACH je miera kliknutí na palec-hore/dole kultúrne nižšia než v USA, čo tlmí výpovednú hodnotu explicitných spätnoväzbových signálov.

LLM-as-Judge: užitočné, ale nie je to samochod

Kanonická referencia (Zheng et al., 2023) ukazuje, že silné judge modely dosahujú viac než 80 % zhody s kontrolovanými ľudskými hodnoteniami — rovnakú úroveň ako zhoda medzi ľuďmi. To však platí pre úlohy založené na názore; pre fakticky kritický nemecky jazykový obsah (právo, medicína, financie) zostáva ľudské zlato štandardom.

Praktické usmernenia z praxe:

• Binárne namiesto Likertovej škály. Pass/fail s vyformulovanou kritikou prekonáva 1-5 škály, pretože hranica 3-versus-4 je naprieč judge modelmi a behmi nestabilná.
• Mitigovať známe skreslenia. Position-bias prehadzovaním a spriemerovaním oboch poradí; verbosity-bias kontrolou dĺžky; self-enhancement-bias judge modelmi z inej modelovej rodiny alebo judge ensemblom.
• Kalibrovať. Zhodu judge-versus-človek reportovať ako Cohenovu kappu alebo Krippendorffovu alfu, predtým než sa judge produkčne dôverí.
• Obmedziť náklady. Pravidlo: rozpočtovať 10-30 % inferenčných nákladov na evaluáciu; s reasoning judge modelmi to môže vystúpiť nad 50 %. Vzor: reasoning judge modely pre validačný set, lacné špecializované judge modely (napríklad MiniCheck-podobné modely) pre produkčné vzorkovanie.

Rozhodujúce: LLM-as-Judge nie je náhradou za analýzu chýb. Konsenzus praktikov znie, že 60-80 % eval réžie by malo naďalej smerovať do prezerania dát, hľadania chybových režimov a ich prekladu do pass/fail assertov.

Takto sa budujú eval dataset a eval loop

Spoľahlivý golden-set má zdokumentovaný pôvod, labeling rubric, inter-annotator agreement a explicitné pokrytie reálnych use-cases. Praktický recept:

1. Navzorkovať 200-500 reálnych používateľských traces; redigovať PII podľa DSGVO čl. 32.
2. Dvaja odborní experti olabelujú každý trace s outcome plus kritikou; vypočítať Cohenovu kappu, vyriešiť konflikty.
3. Doplniť 50-100 expertmi napísaných adversariálnych edge-cases na hraniciach policy.
4. Pridať 100-200 syntetických prípadov naprieč zdokumentovanými dimenziami (features × scenáre × persony).
5. Oddeliť 30 % ako uzamknutý test-set, ktorý sa nikdy nepoužíva na tuning; 70 % pre iteráciu.
6. Verzionovať, zdokumentovať dataset-card, štvrťročne obnovovať.

Pre DACH stredne podnikový pilot potrebuje 500-položkový golden-set iniciálne približne 3-6 týždňov expertného času a potom asi týždeň na štvrťrok. To je najvyššia páka v celom eval programe.

Kontinuálny eval loop spája oba svety: používateľská požiadavka → beh agenta → emisia trace-span (OpenTelemetry) → vzorkovacia vrstva → eval vrstva (LLM-judge modely plus heuristiky plus small-model judge modely) → eval store → dashboard → alert pri prelomení prahu → spätná väzba do golden-setu. Zrelé programy z toho robia CI/CD gate: každý pull request, ktorý mení prompt, voľbu modelu, retrieval konfiguráciu alebo definíciu tool, triggeruje eval suite; merge zlyhá, ak pass-rate klesne pod prah. Aj zmena verzie modelu zo strany poskytovateľa by mala spustiť automatický re-eval, predtým než smie nový model do produkčného routingu. Uzamknutý golden-set by sa mal voči live systému re-evaluovať minimálne týždenne, pri produkčne kritických agentoch denne, aby sa modelová/promptová regresia oddelila od čistého driftu prostredia.

Pre DSGVO konformnú dátovú rezidenciu sa hodia self-hostovateľné nástroje ako nemecky založený Langfuse (self-host cez ClickHouse a Postgres) alebo OTel-natívny Arize Phoenix; RAGAS je de-facto knižnicou pre RAG metriky (Faithfulness, Context Precision, Answer Relevancy), DeepEval a Inspect AI pokrývajú CI/CD-blízke a bezpečnostne relevantné evaly. (Stav 2026; trh s eval toolingom sa práve konsoliduje cez M&A ako Cisco/Galileo.)

Vymedzenie voči modelovým benchmarkom

Častou a nákladnou myšlienkovou chybou je zamieňať benchmarkové skóre s dôkazom vhodnosti. Model-card eval je marketingový resp. výskumný artefakt poskytovateľa: snímka capability naprieč verejnými benchmarkmi. Compliance eval je regulačný artefakt prevádzkovateľa: predbežné plus priebežné meranie voči skutočnému use-case, datasetu a rizikovému profilu — so zdokumentovanou metodikou, verzionovanými scorermi a audit-trailom. To sú odlišné artefakty s odlišnými adresátmi a väčšina regulátorov neakceptuje model-card ako náhradu.

Tri dôvody, prečo benchmarkové skóre poskytujú len kontext:

• Kontaminácia. Každý benchmark, ktorého dataset existoval verejne pred rokom 2024, je pravdepodobne v tréningových dátach. Príklad: Claude Opus 4.5 dosahuje 80,9 % na SWE-bench Verified, ale len 45,9 % na kontaminácii odolnom SWE-bench Pro — ten istý model, tá istá rodina úloh, 35 bodov rozdielu (stav 2026).
• Závislosť od scaffoldu. „Líder GAIA leaderboardu" je bez uvedenia scaffoldu bezvýznamný: medzi scaffolded (Princeton HAL s Claude Sonnet 4.5: 74,6 %) a bare skóre leží približne 30 percentuálnych bodov.
• Reward-hacking. Práca UC-Berkeley-RDI (apríl 2026) ukázala, že automatizovaný scanning agent dokázal nahackovať všetkých osem veľkých agentových benchmarkov na takmer dokonalé skóre bez toho, aby vyriešil čo i len jednu úlohu.

Obhájiteľná pozícia pre DACH compliance dossier: citovať viacero benchmarkov naprieč rodinami, reportovať náklady a rozptyl, doplniť o zákaznícky privátne golden-sety a písomne uznať limity. Anglické agentové benchmarky (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) sú vhodné na capability baselining; samotným dôkazom zostáva nemecky jazykový eval dataset, ideálne namapovaný na kritériové katalógy BSI.

Pre agentúry a B2B rozhodovateľov

Kto plánuje alebo prevádzkuje AI agentov pre DACH zákazníkov, mal by evaluáciu chápať nie ako následný test, ale ako priebežnú disciplínu: nemecky jazykový golden-set ako základ, offline gates pred go-live, online monitoring s detekciou driftu potom — a súbor metrík, ktorý berie spoľahlivosť a náklady rovnako vážne ako holú mieru úspešnosti. Práve tento eval základ je zároveň predpokladom pre spoľahlivý monitoring podľa čl. 72 EU AI Act. Blck Alpaca podporuje agentúry a B2B firmy z Viedne pri budovaní takéhoto eval programu — od golden-setu cez výber nástrojov až po audit-odolné compliance dossier. Ozvite sa nám, ak majú vaši agenti ísť do produkcie merateľne a v súlade s pravidlami.