Agent projde interní ukázkou, odpoví na patnáct otázek, které mu tým připravil, a všichni jsou spokojeni. Tři týdny po spuštění přijde screenshot od zákazníka, na kterém agent sebevědomě tvrdí něco, co v žádné firemní směrnici není. Nikdo neumí říct, jestli jde o ojedinělý výkyv nebo o vzorec, který se opakuje stokrát denně — protože nikdo nemá s čím to porovnat.
Tohle je nejčastější důvod, proč se nasazení AI agenta po pár týdnech stáhne zpět do „interního testování". Ne proto, že by byl model špatný, ale proto, že tým nikdy nedefinoval, co znamená „funguje". Testování AI agenta proto není poslední fáze před spuštěním. Je to měřicí infrastruktura, kterou potřebujete mít hotovou dřív, než dopíšete finální verzi promptu.
Proč klasické testy na agentovi nestačí
Běžné testování softwaru stojí na determinismu: stejný vstup dá stejný výstup, test buď projde nebo neprojde. U jazykového modelu neplatí ani jedno. Tentýž dotaz vrátí dnes jinou formulaci než zítra a obě mohou být zcela v pořádku. Zároveň může být odpověď gramaticky bezchybná, sebevědomá a věcně nesprávná — a žádné porovnání řetězců to nezachytí.
Neznamená to, že klasické testování zahodíte. Všechno kolem modelu je pořád obyčejný software: API integrace, autentizace, parsování strukturovaných výstupů, chování při výpadku externí služby, práva na data. Tyto věci testujete přesně tak, jak to popisuje standardní QA proces před spuštěním softwaru — deterministicky a v CI. Nad tím ale přibývá nová vrstva: statistické hodnocení chování modelu na reprezentativním vzorku.
Mění se i otázka, kterou si kladete. Místo „prošel test?" se ptáte „na kolika procentech reálných případů se agent zachoval přijatelně a jak přesně vypadá ten zbytek?".
Evaluační sada je základ všeho ostatního
Evaluační sada je seznam konkrétních případů spolu s očekávaným chováním. Ne otázky, které napadly produktovému týmu na poradě, ale vzorek z reálné historie: tikety z helpdesku, e-maily zákazníků, přepisy hovorů, otázky z chatu, požadavky z interního ticketing systému. Pokud tuhle historii máte, máte i nejcennější testovací materiál, jaký si za peníze nekoupíte.
Co do sady patří
Praktické rozdělení vypadá takto:
- Běžné případy tvoří většinu objemu — dotazy na stav objednávky, otevírací dobu, postup při reklamaci. Tady musí být agent téměř bezchybný, protože je to 70 % provozu.
- Hraniční a vzácné případy jsou ty, které přijdou jednou za měsíc: zákazník s nestandardní smlouvou, otázka na produkt, který se už neprodává, dvojznačně formulovaná žádost, dotaz ve třech jazycích najednou. Právě tyto rozhodují o tom, jestli agent v praxi obstojí.
- Případy, kde agent nemá odpovídat vůbec — právní a daňové otázky, žádost o slevu nad rámec kompetence, dotaz na cizí účet, pokus vytáhnout interní data. Na tuhle třetí kategorii se zapomíná nejčastěji a napáchá nejvíc škody.
Ke každému případu si zaznamenejte, co je správný výsledek. Ne přesné znění odpovědi — to je u jazykového modelu nesmysl — ale podmínky, které musí odpověď splnit: jaká fakta má obsahovat, jaký nástroj měl agent zavolat, jestli měl případ eskalovat člověku a co v odpovědi zaznít nesmí.
Kolik případů stačí
Magické číslo neexistuje, ale platí jednoduchá logika: sada musí být dost velká na to, aby rozdíl mezi dvěma verzemi agenta nebyl náhoda. Prakticky se dá začít na 80 až 150 případech pro jeden hlavní scénář, s důrazem na pokrytí hraničních situací, ne na objem. Sadu pak průběžně doplňujete — každý reálný případ, kde agent selhal, se stává novým testem.
Co na agentovi vlastně měřit
„Kvalita odpovědí" není metrika. Rozložte ji na věci, které se dají vyhodnotit samostatně a které selhávají z různých příčin.
| Metrika | Co říká | Jak se vyhodnocuje |
|---|---|---|
| Dokončení úkolu | Vyřešil agent případ bez zásahu člověka? | Kontrola koncového stavu (tiket uzavřen, objednávka změněna) |
| Ukotvení ve firemních datech | Opírá se odpověď o skutečný interní zdroj? | Kontrola citovaných pasáží proti zdrojovým dokumentům |
| Správná eskalace | Poslal agent člověku to, co měl, a jen to? | Porovnání s očekávaným rozhodnutím v sadě |
| Korektnost volání nástrojů | Zavolal správné API se správnými parametry? | Log volání vs. očekávaná sekvence |
| Odmítnutí | Odmítl, co odmítnout měl, bez zbytečné opatrnosti? | Ručně označené případy obou typů |
| Latence | Jak dlouho trvá odpověď v 95. percentilu? | Měření v provozu, ne průměr |
| Náklad na vyřešený případ | Kolik stojí jeden reálně uzavřený případ? | Celkové náklady na tokeny a nástroje / počet vyřešených |
Dvě z těchto metrik si zaslouží komentář. Ukotvení v datech je u agentů, kteří odpovídají z interní dokumentace, důležitější než plynulost odpovědi — pokud stavíte řešení, kde agent odpovídá z firemních dokumentů přes RAG, testujte odděleně kvalitu vyhledání podkladů a kvalitu formulace. Špatné vyhledání se totiž projeví jako halucinace, přestože model za ni nemůže.
Náklad na vyřešený případ je zase jediné číslo, které dává smysl porovnávat se stávajícím procesem — ne cena za tisíc tokenů. Pokud řešíte návratnost investice do AI agenta, potřebujete ho změřit už během evaluace, ne odhadovat po spuštění.
Agent, který má pravdu v 95 % případů a nikdy neřekne „nevím", je pro firmu nebezpečnější než agent s 85% úspěšností, který zbytek poctivě pošle člověku.
LLM-as-judge a proč lidská kontrola neodpadá
Vyhodnocovat stovky odpovědí ručně je při každé změně promptu neudržitelné. Proto se hodnocení z velké části automatizuje: druhý model dostane otázku, odpověď agenta, referenční podklady a kritéria, a přidělí hodnocení s odůvodněním. Funguje to překvapivě dobře u jasně definovaných kritérií typu „obsahuje odpověď správnou částku poplatku?" nebo „opírá se tvrzení o přiložený dokument?".
Limity je potřeba znát. Hodnoticí model má vlastní sklony — preferuje delší a sebevědoměji formulované odpovědi, bývá shovívavý k výstupům podobným těm, jaké by sám vygeneroval, a u vágních kritérií („byla odpověď užitečná?") dává výsledky, které se nedají zopakovat. Pokud hodnotí model téže rodiny jako agent, riziko systematické shody v chybě roste.
Praktický kompromis, který se osvědčuje: automatický soudce běží na celé sadě při každé změně, člověk pravidelně kontroluje náhodný vzorek, například 20 až 30 případů, a porovnává své hodnocení s hodnocením soudce. Když se začnou rozcházet, opravuje se soudce, ne realita. Tuhle kontrolu má dělat někdo z provozu — člověk, který danou agendu roky řeší a okamžitě vidí odpověď, která je formálně správná, ale v praxi nepoužitelná.
Regrese a adverzariální testování
Když se změní prompt nebo model
Každá úprava systémového promptu, výměna modelu za novější verzi, změna způsobu vyhledávání podkladů i úprava popisu nástroje mohou změnit chování agenta na místech, která s úpravou vůbec nesouvisejí. Proto celá evaluační sada běží před každým nasazením a výsledek se porovnává s předchozím během. Zajímavé není celkové skóre — to se hýbe málo — ale seznam případů, které dřív procházely a teď neprocházejí. Právě tam se skrývají tiché regrese, které by jinak odhalil až zákazník.
Adverzariální testy a prompt injection
Kromě běžných dotazů potřebujete sadu případů, které se agenta pokoušejí zlomit: pokusy přepsat instrukce, dotazy na cizí údaje, zdánlivě neškodné žádosti o informace z interních systémů, dokument nebo e-mail se skrytou instrukcí pro model. Tahle třída útoků je u agentů s přístupem k nástrojům výrazně nebezpečnější než u chatbota, který jen píše text — detailně ji rozebírá článek o prompt injection a ochraně firemních dat. Adverzariální případy patří do stejné automatizované sady jako všechno ostatní, aby se spouštěly při každé změně.
Tichý běh, pilot a monitoring po spuštění
Shadow mode a omezený pilot
I dobrá evaluační sada je jen vzorek. Proto mezi testování a plný provoz patří ještě jeden krok: agent běží na reálném provozu, generuje odpovědi, ale nikomu je neposílá. Návrhy se ukládají a porovnávají s tím, co udělal člověk. Po pár dnech máte několik stovek reálných porovnání, která ukážou přesně to, co v sadě chybělo.
Následuje omezený pilot — jeden kanál, jeden typ agendy nebo jedno procento provozu, s možností okamžitě vypnout. Při návrhu AI agentů a automatizace je právě tohle místo, kde se nejvíc ušetří: zjistit problém na pěti procentech provozu stojí zlomek toho, co stojí zjistit ho na všech zákaznících naráz.
Co sledovat po plném nasazení
Evaluace spuštěním nekončí, jen mění formu. Prakticky stačí sledovat několik věcí: podíl případů vyřešených bez zásahu člověka, míru eskalací a její vývoj v čase, případy, kde člověk odpověď agenta přepsal (to je nejlepší zdroj nových testovacích případů), latenci a náklady, a změny v typu dotazů, které přicházejí. Poslední je důležitější, než se zdá — když se změní sortiment, ceník nebo legislativa, agent zůstane přesně takový, jaký byl, a evaluační sada zestárne spolu s ním.
Vyhraďte si proto pravidelný interval, například jednou za čtvrtletí, na doplnění sady o nové reálné případy a na kontrolu, jestli původní kritéria stále platí.
Shrnutí
Testování AI agenta je posun od binárních testů ke statistickému hodnocení chování. Prakticky to znamená čtyři věci: postavit evaluační sadu z reálné historie včetně hraničních případů a případů, kde agent nemá odpovídat; měřit dokončení úkolu, ukotvení v datech, eskalaci, volání nástrojů, odmítnutí, latenci a náklad na vyřešený případ; kombinovat automatického soudce s pravidelně kontrolovaným lidským vzorkem; a před plným provozem projít tichým během a omezeným pilotem.
Bez těchto věcí se nasazení neřídí daty, ale dojmy — a první spolehlivý signál o kvalitě přijde od zákazníka, což je nejdražší možná forma testování. Pokud zvažujete nasazení agenta a chcete si projít, jak by evaluace vypadala ve vašem konkrétním případě, ozvěte se nám a podíváme se na to společně.