Proč nestačí finální odpověď?
Představme si AI agenta zákaznické podpory, jehož úkolem je zpracovat refundaci.
Na konci správně odpoví:
„Vaše refundace byla úspěšně zpracována.“
To ale automaticky neznamená, že agent pracoval správně.
Možná použil špatnou databázi, provedl několik zbytečných API požadavků nebo refundaci zpracoval přesto, že na ni zákazník neměl nárok.
Proto je důležité hodnotit také trajektorii – jednotlivé kroky, které agent při řešení úkolu provedl. Google a další platformy tento přístup stále více využívají, protože správného výsledku lze někdy dosáhnout i navzdory chybnému procesu.
Co bychom měli měřit?
1. Dosáhl agent správného výsledku?
Základní otázka zní:
Dokázal agent úkol úspěšně dokončit?
U coding agenta můžeme spustit testy. U rezervačního agenta můžeme zkontrolovat, zda byla rezervace vytvořena se správnými údaji.
Task success je ale pouze první metrika.
2. Použil správné nástroje?
Pokud agent pracuje s databázemi, API nebo externími nástroji, měli bychom sledovat:
- Vybral správný nástroj?
- Použil správné argumenty?
- Nepoužil nástroj zbytečně?
- Dokázal reagovat na chybu nástroje?
Agent tak může dojít ke správnému výsledku, ale až po deseti zbytečných API voláních.
3. Byla jeho cesta k výsledku efektivní?
Dva agenti mohou mít stejnou úspěšnost 90 %.
První vyřeší úkol ve třech krocích.
Druhý provede 25 API volání, dvakrát načte stejná data, udělá chybu, opraví ji a nakonec dosáhne správného výsledku.
V produkci jsou tito dva agenti velmi odlišní.
Proto má smysl sledovat trajectory quality – například počet kroků, tool calls, chyb nebo zbytečných opakování.
4. Je konzistentní?
AI agent nemusí stejný úkol vyřešit pokaždé úplně stejným způsobem.
Pokud ho otestujeme desetkrát a devětkrát uspěje, máme úspěšnost 90 %. U některých systémů ale může být právě ten jeden neúspěšný pokus výrazně závažnější než ostatní.
Proto je potřeba testy opakovat a sledovat také reliability, consistency a robustness.
5. Co udělá, když selže?
Ještě důležitější otázka než „Jak často agent selhává?“ může být:
„Co udělá, když selže?“
API může být dočasně nedostupné. Uživatel může zadat neúplné informace. Dva zdroje mohou obsahovat protichůdná data.
Dobrý agent by v takové situaci neměl jednoduše pokračovat a vymyslet si odpověď.
Měl by si vyžádat chybějící informace, použít bezpečný fallback nebo předat úkol člověku.
Nezapomínejme na bezpečnost
Čím více oprávnění agent má, tím důležitější je testovat také jeho bezpečnostní chování.
Agent, který pouze odpovídá na otázky, představuje jiné riziko než agent, který může měnit databázi, posílat e-maily nebo provádět finanční operace.
Evaluace proto může zahrnovat také:
- prompt injection,
- neoprávněné akce,
- únik citlivých dat,
- překročení oprávnění,
- nesprávné používání nástrojů,
- rizikové edge cases.
A kolik nás agent stojí?
Úspěšnost není jediný faktor, na kterém záleží.
Představme si dva agenty:
Agent A
90% úspěšnost
3 sekundy na úkol
0,03 $ za úkol
Agent B
94% úspěšnost
25 sekund na úkol
0,80 $ za úkol
Vyšší úspěšnost automaticky neznamená, že druhý agent je lepší volbou.
Proto se vyplatí sledovat také:
- latenci,
- využití tokenů,
- počet tool calls,
- náklady na úkol,
- míru chyb,
- počet předání úkolu člověku.
Konkrétní metriky samozřejmě závisí na produktu.
Jak vytvořit vlastní eval?
Nemusíte začínat stovkami testů.
Praktičtější je vytvořit menší dataset přibližně 20–50 reálných úloh a postupně ho rozšiřovat o nové scénáře a známé chyby.
1. Definujte, co znamená úspěch
Ne:
„Agent by měl být užitečný.“
Ale:
„Agent musí vyřešit požadavek, použít správný nástroj, vyhnout se neoprávněným akcím a v případě chybějících informací se doptat.“
2. Testujte reálné situace
Dataset by měl obsahovat:
- běžné případy,
- edge cases,
- neúplná zadání,
- neplatné vstupy,
- situace, ve kterých agent už dříve selhal.
Právě tyto scénáře často odhalí problémy, které jednoduchý happy-path test neukáže.
3. Použijte správný grader
U jednoznačných výsledků může stačit code-based test.
U otevřenějších odpovědí může být užitečný přístup LLM-as-a-judge.
U subjektivních nebo citlivých případů zůstává důležité lidské hodnocení.
LLM grader ale nelze automaticky považovat za objektivní pravdu. Jeho výsledky je potřeba kalibrovat a pravidelně porovnávat s lidským hodnocením.
Sledujte trace, ne pouze výsledek
Jedním z nejdůležitějších konceptů při evaluaci agentů je trace – záznam celého procesu, který za daným úkolem stojí.
Když agent selže, trace nám může ukázat proč.
Místo:
„Agent odpověděl špatně.“
můžeme zjistit:
„Agent použil špatný nástroj.“
Nebo:
„Získal správná data, ale špatně je interpretoval.“
Nebo:
„API vrátilo chybu, ale agent pokračoval s neověřenými informacemi.“
Díky tomu můžeme následně upravit prompt, routing, nástroje nebo guardrails.
Největší chyba? Testovat pouze happy path
Agent pro rezervaci letenek může bez problémů zvládnout:
„Najdi mi let z Bratislavy do Londýna v pátek.“
Reálný uživatel ale spíš řekne:
„Chci letět v pátek, ale ne před 18:00, nechci přestupovat a chci se vrátit v neděli.“
A potom:
„Vlastně můžu odletět i v sobotu.“
Právě multi-turn konverzace, změny požadavků, neúplné informace a chyby nástrojů dělají agenty výrazně náročnější na testování než klasické AI aplikace.
Evaluace jako součást vývoje
Evaluace má největší hodnotu tehdy, když se stane součástí vývojového procesu.
Agent v1 → eval suite → úprava → nový test → nový model → eval suite → production monitoring
Pokud nová verze zvýší success rate, ale zároveň zdvojnásobí náklady, víme o tom.
Pokud poskytuje lepší odpovědi, ale zhorší bezpečnostní metriky, víme o tom.
A pokud nový model sníží počet tool calls, ale začne dělat více chyb u edge cases, víme to také.
Evals tak přestávají být jednorázovým QA testem a stávají se součástí kontinuálního vývoje.
Závěr
AI agent není dobrý jen proto, že dokáže úkol občas úspěšně dokončit.
Potřebujeme vědět:
- Jak často uspěje?
- Jak dobře používá své nástroje?
- Jak konzistentně se chová?
- Jak reaguje na chyby?
- Je bezpečný?
- Kolik stojí?
- Dokážeme zjistit, proč selhal?
Nejdůležitější otázka proto není:
„Funguje náš AI agent?“
Ale:
„Dokážeme změřit, jak dobře funguje – a poznat, když se začne zhoršovat?“
Právě to odlišuje AI agenta, který vypadá působivě v demu, od systému připraveného na reálné použití.