Prečo nestačí finálna odpoveď?
Predstavme si zákazníckeho AI agenta, ktorý má vybaviť refundáciu.
Na konci správne odpovie:
„Refundácia bola úspešne spracovaná.“
To ešte nemusí znamenať, že fungoval správne.
Možno použil nesprávnu databázu, urobil niekoľko zbytočných API požiadaviek alebo refundáciu vykonal napriek tomu, že zákazník nespĺňal podmienky.
Preto je dôležité hodnotiť aj trajektóriu – teda jednotlivé kroky, ktoré agent počas riešenia úlohy urobil. Google aj ďalšie platformy dnes pracujú s týmto prístupom, pretože správny výsledok môže vzniknúť aj napriek chybnému procesu.
Čo by sme mali pri AI agentovi merať?
1. Dosiahol správny výsledok?
Základná otázka:
Dokázal agent splniť úlohu?
Pri coding agentovi môžeme spustiť testy. Pri rezervačnom agentovi skontrolujeme, či vytvoril rezerváciu so správnymi údajmi.
Task success je však iba prvá metrika.
2. Použil správne nástroje?
Ak agent pracuje s databázou, API alebo externými nástrojmi, sledujeme:
- vybral správny nástroj?
- použil správne argumenty?
- nepoužil nástroj zbytočne?
- dokázal reagovať na chybu?
Agent môže napríklad dosiahnuť správny výsledok, ale až po desiatich zbytočných API calloch.
3. Bola jeho cesta k výsledku efektívna?
Dva agenty môžu mať 90 % success rate.
Prvý vyrieši úlohu tromi krokmi.
Druhý urobí 25 API callov, dvakrát načíta rovnaké dáta, spraví chybu, opraví ju a až potom dosiahne výsledok.
V produkcii medzi nimi existuje veľký rozdiel.
Preto má zmysel sledovať trajectory quality, počet krokov, tool calls, chýb alebo zbytočných opakovaní.
4. Je konzistentný?
AI agent nemusí rovnakú úlohu vyriešiť zakaždým rovnakým spôsobom.
Ak ju desaťkrát otestujeme a deväťkrát zvládne správne, máme 90 % success rate. Pri niektorých systémoch však môže byť jeden chybný pokus výrazne závažnejší než ostatné.
Preto treba testy opakovať a sledovať aj reliability, consistency a robustness.
5. Čo urobí, keď zlyhá?
Možno ešte dôležitejšia otázka ako „Ako často agent zlyhá?“ je:
„Čo urobí, keď zlyhá?“
API môže byť nedostupné. Používateľ môže zadať neúplné informácie. Dva zdroje môžu obsahovať konfliktné údaje.
Dobrý agent by v takej situácii nemal jednoducho pokračovať a vymyslieť si odpoveď.
Mal by vedieť požiadať o chýbajúce informácie, skúsiť bezpečný fallback alebo úlohu odovzdať človeku.
Nezabúdajme na bezpečnosť
Čím viac oprávnení agent má, tým dôležitejšie je testovať jeho bezpečnostné správanie.
Agent, ktorý iba odpovedá na otázky, má iné riziko ako agent, ktorý môže meniť databázu, posielať e-maily alebo vykonávať finančné operácie.
Eval preto môže zahŕňať aj:
- prompt injection,
- neoprávnené akcie,
- únik citlivých údajov,
- prekročenie oprávnení,
- nesprávne používanie nástrojov,
- rizikové edge cases.
A koľko nás agent stojí?
Úspešnosť nie je jediná vec, ktorá rozhoduje.
Predstavme si:
Agent A
90 % úspešnosť
3 sekundy na úlohu
$0,03 za úlohu
Agent B
94 % úspešnosť
25 sekúnd na úlohu
$0,80 za úlohu
Vyššia úspešnosť automaticky neznamená, že druhý agent je vhodnejší.
Preto sledujeme aj:
- latency,
- token usage,
- počet tool calls,
- cost per task,
- failure rate,
- počet eskalácií na človeka.
Správne metriky závisia od konkrétneho produktu.
Ako vytvoriť vlastný eval?
Nemusíte začínať stovkami testov.
Praktickejší prístup je vytvoriť menší dataset približne 20–50 reálnych úloh a postupne ho rozširovať o nové prípady a zlyhania.
1. Definujte úspech
Nie:
„Agent má byť užitočný.“
Ale:
„Agent musí vyriešiť požiadavku, použiť správny nástroj, nevykonať neoprávnenú akciu a pri chýbajúcich údajoch si ich vypýtať.“
2. Testujte realitu
Dataset by mal obsahovať:
- bežné prípady,
- edge cases,
- neúplné zadania,
- chybné vstupy,
- situácie, v ktorých agent už v minulosti zlyhal.
Práve tieto situácie často odhalia problémy, ktoré jednoduchý happy-path test neukáže.
3. Použite správny grader
Pri jednoznačných výsledkoch môžeme použiť klasický code-based test.
Pri otvorenejších odpovediach môže pomôcť LLM-as-a-judge.
Pri subjektívnych alebo citlivých prípadoch je stále dôležité ľudské hodnotenie.
LLM grader však nemožno automaticky považovať za objektívnu pravdu. Jeho výsledky treba kalibrovať a pravidelne porovnávať s ľudským hodnotením.
Sledujte trace, nie iba výsledok
Jednou z najdôležitejších vecí pri agentoch je sledovanie trace – záznamu celého priebehu jednej úlohy.
Ak agent zlyhá, trace nám môže ukázať prečo.
Namiesto:
„Agent odpovedal nesprávne.“
môžeme zistiť:
„Agent použil nesprávny nástroj.“
alebo:
„Dostal správne dáta, ale nesprávne ich interpretoval.“
alebo:
„API vrátilo chybu a agent pokračoval s neoverenými údajmi.“
To umožňuje následne upraviť prompt, routing, nástroje alebo guardrails.
Najväčšia chyba? Testovať iba happy path
Agent na rezerváciu leteniek môže bez problémov zvládnuť:
„Nájdi mi let z Bratislavy do Londýna v piatok.“
Realita však vyzerá skôr takto:
„Chcem letieť v piatok, ale nemôžem pred 18:00, nechcem prestupovať a chcem sa vrátiť v nedeľu.“
A potom:
„Vlastne môžem odletieť aj v sobotu.“
Práve multi-turn situácie, zmeny požiadaviek, neúplné informácie a chyby nástrojov robia agentov náročnejšími na testovanie než klasické AI aplikácie.
Evaluácia ako súčasť vývoja
Najväčšiu hodnotu má evaluácia vtedy, keď sa stane súčasťou vývojového procesu.
Agent v1 → eval suite → úprava → nový test → nový model → eval suite → production monitoring
Ak nová verzia zvýši success rate, ale zdvojnásobí cenu, vieme to.
Ak zlepší odpovede, ale zhorší bezpečnostné metriky, vieme to.
Ak nový model zníži počet tool calls, ale začne robiť viac chýb pri edge cases, vieme to tiež.
Evals tak prestávajú byť jednorazovým QA testom a stávajú sa súčasťou kontinuálneho vývoja.
Záver
AI agent nie je dobrý iba preto, že dokáže niekedy splniť úlohu.
Potrebujeme vedieť:
- Ako často ju splní?
- Ako dobre používa nástroje?
- Ako konzistentne sa správa?
- Ako reaguje na chyby?
- Je bezpečný?
- Koľko stojí?
- Vieme zistiť, prečo zlyhal?
Najdôležitejšia otázka preto nie je:
„Funguje náš AI agent?“
Ale:
„Vieme zmerať, ako dobre funguje – a vieme si všimnúť, keď sa začne zhoršovať?“
Práve to odlišuje AI agenta, ktorý vyzerá dobre v deme, od systému, ktorý je pripravený na reálne používanie.