Jak testovat AI agenta: tříúrovňový eval framework v praxi

Jak testovat AI agenta dřív, než ho pustíš k reálným zákazníkům? Většina týmů v roce 2026 odpoví „vůbec" — a draze za to platí. Nasadí agenta, který zní chytře, demo projde v pátek, a za dva týdny řeší 180 support ticketů na špatné odpovědi bez jediné stopy, co se vlastně pokazilo. Pokud používáš Claude Code, Cursor nebo vlastního agenta v n8n, potřebuješ jeden konkrétní systém: evaluace (evaly), které změří, jestli tvůj agent skutečně řeší úkol — ne jestli jen produkuje věrohodně znějící text.

V tomto návodu ti ukážu tříúrovňový eval framework, který dnes používají produkční týmy: od rychlých unit testů přes LLM-as-judge nad golden datasetem až po online monitoring reálného provozu. Každou úroveň můžeš nasadit postupně — a každá ti ušetří hodiny ladění záhadných produkčních chyb.

Proč běžné testování na AI agenty nestačí

Tradiční testování předpokládá deterministické vstupy a výstupy: stejný dotaz → stejná odpověď. AI agent tento předpoklad rozbije úplně. Nejenže generuje text — taky plánuje, volá nástroje, čte výsledky a rozhoduje, co udělá dál. Agent zákaznické podpory může dohledat objednávku, ověřit reklamační podmínky, spočítat částečný dobropis a nastavit odpověď. To je čtyřkrokový řetězec, kde selhání v jednom kroku kaskádově zničí zbytek.

Hodnotit agenta jen podle konečné odpovědi je jako opravovat písemku z matematiky tak, že se podíváš na výsledek a ne na postup.

Proto taky 40 % agentic AI projektů selže — týmy nemají zpětnou vazbu, jestli jejich agent vůbec funguje, dokud není pozdě. Konsultant Hamel Husain to shrnuje narovinu: „Neúspěšné produkty mají téměř vždy společnou příčinu — selhání vytvořit robustní evaluační systém." Týmy, které mají evaly zprovozněné, iterují podle Kunala Ganglaniho 5–10× rychleji než ty, které létají naslepo (zdroj: Evaluate AI Agents in Production: 3-Level Framework, 12. července 2026).

Důležité upozornění na začátek: benchmarky jako MMLU nebo HumanEval ti neřeknou vůbec nic o tom, jak se tvůj agent chová ve tvé konkrétní aplikaci. Model, který na MMLU skončí druhý, nemusí být o nic lepší v sumarizaci tvých právních dokumentů než model na šestém místě. Benchmark měří obecné schopnosti; tvůj úkol není obecný. Jediné, co tě zajímá, je: řeší můj agent úkoly, které mu reálně posílají moji uživatelé, a selhává způsoby, které mě stojí peníze?

1. úroveň: Asertivní unit testy (běží na každý commit)

První úroveň jsou rychlé, deterministické testy, které běží v milisekundách a chytí zjevné regresje dřív, než se k vůbec něčemu dostane LLM-as-judge. Inspiroval se tu tradičními unit testy — akorát přizpůsobenými chování agenta.

Pro AI agenty pokryj čtyři kategorie:

1. Výběr nástroje (tool selection). Daný záměr uživatele musí zavolat správný nástroj. „Zruš moji objednávku" má spustit API pro zrušení, ne kalkulačku dobropisu. Zní to triviálně, ale regresze ve výběru nástroje je podle Ganglaniho nejčastější selhání, když týmy přepínají na jiný model.
2. Formát výstupu. Vrací agent strukturované JSON pro další zpracování? Porušení formátu tiše rozbije celý downstream.
3. Guardraily. Odmítne agent věci, které nemá dělat? Pokud uživatel požádá tvého agenta podpory, ať napíše Python kód, má odmítnout.
4. Zachování kontextu. V vícekolové konverzaci si agent pamatuje, co uživatel řekl před třemi zprávami?

Praktický start: napiš 10–20 unit testů pokrývajících nejčastější záměry. Trvá to den, ne sprint. A okamžitě ti řekne, jestli výměna modelu nebo změna promptu něco rozbila. Tyhle testy běž v CI na každý commit a blokuj merge, pokud nějaký asert selhá — žádné výjimky.

Poznámka z praxe: nudné Level 1 aserce (slug je platný, kategorie existuje, počet slov je v rozsahu) zachytí víc rozbitých publikací než jakákoliv suma chytrého LLM hodnocení. Je v těsném review workflow pro AI generovaný kód stejná poučka — levná deterministická vrátna před drahou soudcovskou.

2. úroveň: LLM-as-judge nad golden datasetem

Druhá úroveň řeší subtillní kvalitu, kterou by postřehl člověk, ale ne asert. Deleguje hodnocení na další LLM — tzv. LLM-as-judge — který skóruje výstupy tvého agenta podle rubriky v přirozeném jazyce. Místo kódování „je tato odpověď správně?" napíšeš rubriku: „Ohodnoť, zda tato odpověď podpory přesně řeší fakturační dotaz, používá profesionální tón a dává praktické další kroky."

Postav si golden dataset

Každá eval metoda potřebuje data. Většinou je bottleneckem dataset, ne metoda. Golden dataset je sada vstupů se známými správnými výstupy reprezentující úkoly, které tvá aplikace reálně řeší. Praktické mantinely podle Galtea (the complete guide for LLM evaluations in 2026, 15. července 2026):

• 50 příkladů detekuje velké regresze.
• 200 příkladů dává statistickou jistotu na menší rozdíly (změna kvality 3–5 %).
• Více než 500 má už klesající výnosy, pokud nemáš vysoce rozmanité podúkoly.

Kde vezmeš data, když ještě nemáš produkční provoz? Kombinuj tři zdroje: syntetické scénáře (20–30 ručně napsaných realistických ticketů), adversarial vstupy (zkus agenta rozbít — rozporuplné informace, prázdné vstupy, neočekávané jazyky) a persona testování (5–7 uživatelských person proženeš top workflow). Dohromady 50–100 stop dřív, než se dotkne prvního reálného uživatele. A jakmile máš provoz, přidávej každý týden reálné selhávající stopy — ty jsou nejvíc cenné.

Zkalibruj judge, než mu uvěříš

Tohle je krok, kde se většina eval setupů zhroutí. Předem napsaná rubrika je vždycky nějak špatně — zjistíš to až ve chvíli, kdy ji uvidíš selhávat na reálných příkladech. Správný postup:

1. Jeden doménový expert (ne komise!) ohodnotí 30–50 příkladů binárně pass/fail s krátkým zdůvodněním selhání.
2. Spusť LLM-as-judge na stejných příkladech se svou rubrikou.
3. Porovnej shodu. Pod 80 % → přepracuj rubriku a opakuj. Nad 85 % → judge můžeš začít věřit.
4. Cílová korelace (Pearson) mezi hodnotitelem a expertem: nad 0,7.

Binární pass/fail, ne škála 1–5. Likertovy škály produkují data s nízkou variancí — skóre se shlukují mezi 3,2 a 3,8, což je statisticky ekvivalentní hodu mincí. Vynuť hodnotitele k závazku. A měř precision a recall pro každou třídu, ne celkovou shodu — judge, který všechno ohodnotí „pass", dosáhne 90 % shody na datasetu, kde má 10 % případů selhat. Je k ničemu a řekne ti, že je na 90 % přesný.

Pozor na tři zkreslení hodnotitele

LLM-as-judge má známá selhání, která musíš řešit:

• Position bias: Zheng et al. ve své průlomové práci Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (2023) zjistili, že prohození pořadí dvou kandidátních odpovědí posunulo preferenci GPT-4 o více než 10 %, i když byly odpovědi identické.
• Verbosity bias: delší výstupy skórují lépe bez ohledu na obsah.
• Self-preference: judge z téhož modelového rodu upřednostňuje výstupy své rodiny.

Řešení: jury-of-judges (tři nezávislí judgeové, většinový verdikt) zkreslení snižuje, ale stojí 3× víc. Vyplatí se tam, kde tě falešné pozitivum v evalu zraní víc než falešné negativum v produkci.

Test stagéra (intern test)

Než automatizuješ jakýkoliv LLM-as-judge, dej rubriku někomu, kdo projekt nezná — kolegovi z jiného týmu, kamarádovi. Dej mu 10 stop a ať je ohodnotí pass/fail jen podle rubriky. Pokud se jeho verdikty shodují s tvými na 80 %+, je rubrika dost specifická. Pokud ne, je ambivalentní a LLM judge bude produkovat nespolehlivá skóre.

A ještě jedno varování: nepoužívej BLEU nebo ROUGE pro výstupy agenta. Tyto metriky měří překryv textu na úrovni tokenů a kompletně minou sémantickou správnost. Agent může perfektní odpověď přeformulovat jinými slovy a na ROUGE skórovat 0,2, přestože je zcela správně.

3. úroveň: Jak testovat AI agenta v produkci (online evaluace)

Třetí úroveň dělá z evalů kontinuální systém. Místo testování před deplojem hodnotíš v produkci — vzorkuješ reálné uživatelské interakce a pouštíš na ně LLM-as-judge asynchronně.

Nesnaž se hodnotit každou stopu (to je drahé a pomalé). Vzorkuj 5–10 % reálného provozu, hodnoť asynchronně a upozorňuj, když kvalita klesne pod práh. Tohle je jediná vrstva, která chytí změny, které se stanou tobě — provider ti potichu upraví váhy modelu bez změny verze API (OpenAI to s GPT-4 Turbo dělalo opakovaně v letech 2023–2024), nebo se distribuce vstupů posune, když objevíš nový segment uživatelů. Žádná offline eval to neukáže.

Zpětná vazba, která to dělá silným: selhávající produkční stopy přidávej do offline datasetu. Vytvoř pro daný režim selhání cíleného evaluátora, ověř opravu proti rozšířenému datasetu, nasaď. Tvoje regresní sada tak roste organicky z reálných selhání, ne z vymyšlených scénářů. Vedle toho sleduj drift — pokud vstupní dotazy začnou být embeddovací vzdáleností výrazně jiné než tvůj golden dataset, je to časný signál dřív, než spadne skóre.

CI/CD gating: propoj evaly s deplojem

Evaly jsou k ničemu, když se nespouštějí automaticky při každé změně. Konkrétní pattern:

Na každý pull request: spusť Level 1 unit testy (10–30 sekund). Blokuj merge, pokud selže asert.

Při merge do main (před deplojem): spusť Level 2 eval suite nad golden datasetem (50–200 stop). Porovnej pass rate s baseline posledního úspěšného deploje. Pokud regresze přesáhne 3 %, blokuj deploy. Zaznamenávej výsledky pro sledování trendů.

Po deployi (kontinuálně): aktivuj Level 3 online evaluaci na 5–10 % vzorkování. Alertuj, pokud klouzavé 24hodinové skóre klesne pod práh.

Checklist při výměně modelu (např. přechod na novější Claude nebo snížení závislosti na jednom providerovi): spusť celý Level 1 suite → zastav při selhání → spusť Level 2 judge nad golden datasetem → porovnej skóre → pokud pass rate neklesl o víc než 3 %, nasaď na 10 % provozu → monitoruj 48–72 hodin → při stabilních skóre rampuj na 100 %. Tvůj health check už není HTTP 200, ale míra dokončení úkolu.

Co měřit (a co tě klame)

Severní hvězda je task completion rate — podíl interakcí, kdy agent plně vyřešil požadavek bez eskalace na člověka. Všechno ostatní je podpůrný důkaz. K tomu: correctness (faktická správnost u informací získávaných výpočtem/retrieve), grounding (drží se RAG agent získaných dokumentů, nebo halucinuje — viz Claude RAG v praxi) a tool selection accuracy.

Náklady a latence jsou reálné, ale sekundární: cost per resolution (celkové API výdaje dělené úspěšně dokončenými úkoly — ne cena za request), tokens per task a P95 latence (P50 tě klame, protože vícekrokové exekuce mají dlouhý chvost). Pro model-per-job: rychlý levný model (např. Claude Haiku) na high-volume Level 3 online hodnocení a silnější model na detailní Level 2 offline analýzu — na ceně i kvalitě to bije jediný model všude, uvádí Ganglani (rozdíl ceny mezi rychlým a frontier hodnotitelem je 10–20×).

A co tě aktivně klame: sledovat latenci, tokeny a počet volání nástrojů bez task completion rate vytváří falešnou jistotu. Tým se pochlubil dashboardem: P50 latence 1,2 s, 100 % uptime, 50 000 stop denně. Krásné grafy. Ale neměli tušení, jaký podíl těch 50 000 interakcí skutečně vyřešil problém uživatele. Dashboard měřil aktivitu, ne kvalitu. Falešně klamou taky délka odpovědi (delší ≠ lepší), počet nástrojů (více ≠ nápomocnější) a počet kol (méně kol neznamená rychlejší vyřešení — může znamenat, že agent vzdal).

Časté otázky

Kolik příkladů potřebuje golden dataset?

Startuj s 50 — to odhalí velké regresze. K statistické jistotě na menších změnách (3–5 % kvality) míř k 200. Více než 500 má klesající výnosy, pokud nemáš hodně rozmanité podúkoly, které potřebují samostatné pokrytí.

Můžu prostě použít BLEU nebo ROUGE?

Pro strukturované výstupy (klasifikace, extrakce) ano. Pro otevřené výstupy agenta rozhodně ne — měří překryv tokenů a minou sémantickou správnost. LLM-as-judge hodnotí význam, ne tokeny, a proto je pro agenty vhodnější.

Jak poznám, že můžu LLM-as-judge věřit?

Až ho zkalibruješ. Dej 30–50 příkladů binárně ohodnotit doménovému expertovi, spusť judge se stejnými daty a hledej shodu nad 85 % (nebo Pearsonovu korelaci nad 0,7). Bez kalibrace jsou skóre z předpřipravených rubrik spolehlivě chybná.

Co dělat, když ještě nemám produkční provoz?

Vygeneruj data: 20–30 ručně napsaných syntetických scénářů, adversarial vstupy, které se snaží agenta rozbít, a 5–7 uživatelských person proženeš top workflow. Dohromady 50–100 stop dřív, než přijde první reálný uživatel — a to stačí na smysluplný Level 2 eval.

Kdy použít unit testy a kdy LLM-as-judge?

Vždycky oboje, v tomto pořadí. Unit testy (Level 1) jsou rychlá deterministická vrátna, která chytí zjevné regresze za milisekundy. LLM-as-judge (Level 2) pak chytí subtillní kvalitu. Kdo přeskočí Level 1 a začne rovnou u Level 2, platí si drahým, pomalým hodnocením za práci, kterou by odvedl 5ms asert.

Závěr: začněte tím nejboringejším krokem

Týmy, které vyhrají závod o AI agenty v roce 2026, nemají nejvychytanější modely ani nejkomplexnější architekturu — mají nejtěsnější eval smyčku. Každá změna modelu, každá úprava promptu, každý nový nástroj se otestuje proti golden datasetu, ohodnotí zkalibrovaným LLM-as-judge a monitoruje v produkci s automatickým alerty.

Začni pragmatically. Když přijde na to, jak testovat AI agenta dlouhodobě a spolehlivě, platí jednoduché pořadí: deset unit testů. Padesát golden stop. Zkalibrovaný judge proti lidským labelům. Gating deployů. Týdenní review stop. Framework není komplikovaný — těžké je dělat to konzistentně, každý týden, i když tlak shipovat nové funkce je nekonečný. Ta disciplína je rozdíl mezi agentem-demem a agentem-produktem. A pokud buduješ více agentů najednou, platí to samé pro každého zvlášť — orchestrátor bez evalů je jen drahý způsob, jak selhat ve větším měřítku.

První krok dnes? Otevři svého agenta a napiš prvních deset unit testů. Všechno ostatní si z toho přirozeně vyroste.