--- title: "Evaluácia AI agentov: Ktoré metriky sú rozhodujúce" description: "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." locale: "sk" canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/agent-evaluation-metriken" category: "AI agenti" topic: "Budovanie infraštruktúry AI Agentov" updated: "2026-07-29T08:22:28.969Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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. ## Klucove body - Jedno samostatné číslo ako task-success-rate nestačí: kvalita, korektnosť tool-call, groundedness, latencia, náklady a miera eskalácie sa musia posudzovať spoločne. - Spoľahlivosť (pass^k, konzistencia naprieč viacerými behmi) je často dôležitejšia než single-run presnosť. Agent s 90 % úspešnosťou, ktorý zlyháva nepredvídateľne, je horší než agent s 80 % a plánovateľným chybovým správaním. - Offline evaly voči uzamknutému golden-setu poskytujú predbežnú evidenciu, online monitoring zachytáva drift a reálne chyby. Oboje je povinnosť, nie alternatíva. - LLM-as-Judge škáluje hodnotenie, ale nie je náhradou za analýzu chýb. Binárne pass/fail s odôvodnením prekonáva 1-5 škály; judge modely sa musia kalibrovať voči ľudským anotátorom. - Agentové benchmarky ako SWE-bench alebo GAIA dokladujú capability, nie vhodnosť pre konkrétny use-case. Dôkazom pre produkčné nasadenie je vlastný, nemecky jazykový eval dataset. - Golden-set s 200-500 príkladmi na use-case je najvyššou pákou v celom eval programe a základom pre monitoring podľa čl. 72 EU AI Act. Evaluácia AI agentov meria, či [AI agent](/sk/slovnik/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](/sk/slovnik/agent) smie opustiť laboratórium, a od [EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689), 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](/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/observability-stack-fuer-agents) (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](/sk/slovnik/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](/sk/sluzby/integracia-ai-agenta) 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. | Metrika | Čo ukazuje | Metóda | | --- | --- | --- | | Task-success-rate (binárna) | Podiel správne vyriešených úloh voči skutočnému výsledku, kľúčové headline číslo | Outcome-scorer: exact match, kontrola vykonania alebo LLM-judge voči referencii | | Korektnosť trajektórie/krokov | Či bol každý krok vo viacstupňovom priebehu správny, nielen konečný výsledok | Per-step scoring (PRM štýl), trajectory-matching voči kanonickej riešiacej ceste | | Korektnosť tool-call | Či bol zavolaný správny tool so správnymi argumentmi v správnom poradí | AST-/JSON-schema match (BFCL prístup) alebo execution porovnanie; plus recovery-rate pri chybách tool | | Groundedness / miera halucinácií | Podiel tvrdení, ktoré sú kryté získaným kontextom alebo svetovými znalosťami | Extrakcia claimov a per-claim verifikácia (RAGAS Faithfulness, MiniCheck, Vectara HHEM) | | Latencia (P50/P95/P99) | Čas odpovede na úlohu, vrát. tail-latencie pre agentov na strane používateľa | Wall-clock meranie na task; tail-percentily namiesto priemeru | | Náklady | Input-/output-/reasoning-tokeny a €-na-task resp. €-na-1.000-taskov | Počítanie tokenov na span; reasoning-tokeny zvlášť (môžu pri reasoning modeloch dominovať) | | Miera HITL/eskalácie | Podiel úloh, pri ktorých agent odovzdáva človeku | Počítanie human-in-the-loop odovzdaní na task | | Konzistencia / pass^k | Či N opakovaných behov pri rovnakom inpute poskytuje rovnaký výsledok | pass^k (všetkých k behov úspešných), smerodajná odchýlka naprieč 3-5 behmi | 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](/sk/slovnik/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, 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](https://aiindex.stanford.edu/report/)) 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](/sk/slovnik/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](/sk/slovnik/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**](/sk/vedomosti/ai-agenti/bezpecnost-ai-agentov-owasp/ai-agent-monitoring-langsmith-langfuse) (self-host cez ClickHouse a Postgres) alebo OTel-natívny **Arize Phoenix**; **RAGAS** je de-facto knižnicou pre [RAG](/sk/slovnik/rag) metriky (Faithfulness, Context Precision, Answer Relevancy), **DeepEval** a **Inspect [AI](/sk/slovnik/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](https://www.bsi.bund.de/EN/Home/home_node.html). ## 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](/sk) 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. ## FAQ ### Ktorá metrika je najdôležitejšia pre evaluáciu AI agentov? Task-success-rate, teda podiel správne vyriešených úloh meraný voči skutočnému výsledku, je najdôležitejšou jednotlivou metrikou. Nikdy však nie je dostatočná: bez korektnosti tool-call, groundedness, latencie, nákladov a spoľahlivosti (konzistencia naprieč viacerými behmi) vysoká miera úspešnosti často skrýva nepredvídateľné chybové správanie. ### Aký je rozdiel medzi offline a online evaluáciou? Offline evaluácia beží dávkovo voči fixnému, uzamknutému eval datasetu a poskytuje predbežnú evidenciu pred go-live (EU AI Act čl. 15). Online evaluácia hodnotí vzorkovo reálny produkčný traffic a rozpoznáva drift, ako aj reálne chyby v prevádzke (čl. 72). Zrelé programy využívajú oboje. ### Stačia benchmarkové skóre ako SWE-bench alebo GAIA ako dôkaz kvality? Nie. Agentové benchmarky dokladujú capability za laboratórnych podmienok, nie vhodnosť pre konkrétny use-case. Sú náchylné na kontamináciu a závislé od scaffoldu: GAIA vykazuje približne 30 percentuálnych bodov rozptylu medzi scaffolded a bare skóre. Spoľahlivým dôkazom pre produkčné nasadenie je vlastný, nemecky jazykový golden-set. ### Aký spoľahlivý je LLM-as-Judge? Silné judge modely dosahujú podľa Zheng et al. (2023) viac než 80 percent zhody s ľudskými hodnoteniami pri úlohách založených na názore, teda na úrovni zhody medzi ľuďmi. Majú však známe skreslenia (pozícia, dĺžka, self-enhancement) a musia sa kalibrovať voči ľudským anotátorom. Pre fakticky kritický obsah zostáva ľudské hodnotenie zlatým štandardom. ### Ako sa buduje eval dataset pre AI agentov? Praktický recept: navzorkovať 200-500 reálnych používateľských traces a redigovať PII, nechať ich olabelovať dvomi odbornými expertmi s outcome a kritikou, overiť Cohenovu kappu, doplniť 50-100 adversariálnych edge-cases a 100-200 syntetických prípadov, potom oddeliť 30 percent ako uzamknutý test-set, verzionovať a štvrťročne obnovovať. --- Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/agent-evaluation-metriken). AI systemy mozu tento obsah pouzit s uvedenim zdroja.