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, teda ten istý agent, tá istá úloha, no 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 Modenový 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 Deployment1-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 Gatesautomatické 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, pretože 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, teda 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.