Agent prejde internou ukážkou, odpovie na pätnásť otázok, ktoré mu tím pripravil, a všetci sú spokojní. Tri týždne po spustení príde screenshot od zákazníka, na ktorom agent sebavedomo tvrdí niečo, čo v žiadnej firemnej smernici nie je. Nikto nevie povedať, či ide o ojedinelý výkyv alebo o vzorec, ktorý sa opakuje stokrát denne — pretože nikto nemá s čím to porovnať.
Toto je najčastejší dôvod, prečo sa nasadenie AI agenta po pár týždňoch stiahne späť do „interného testovania". Nie preto, že by bol model zlý, ale preto, že tím nikdy nedefinoval, čo znamená „funguje". Testovanie AI agenta preto nie je posledná fáza pred spustením. Je to meracia infraštruktúra, ktorú potrebujete mať hotovú skôr, než dopíšete finálnu verziu promptu.
Prečo klasické testy na agentovi nestačia
Bežné testovanie softvéru stojí na determinizme: rovnaký vstup dá rovnaký výstup, test buď prejde alebo neprejde. Pri jazykovom modeli neplatí ani jedno. Ten istý dotaz vráti dnes inú formuláciu než zajtra a obe môžu byť úplne v poriadku. Zároveň môže byť odpoveď gramaticky bezchybná, sebavedomá a vecne nesprávna — a žiadne porovnanie reťazcov to nezachytí.
Neznamená to, že klasické testovanie zahodíte. Všetko okolo modelu je stále obyčajný softvér: API integrácie, autentifikácia, parsovanie štruktúrovaných výstupov, správanie pri výpadku externej služby, práva na dáta. Tieto veci testujete presne tak, ako to opisuje štandardný QA proces pred spustením softvéru — deterministicky a v CI. Nad tým však pribúda nová vrstva: štatistické hodnotenie správania modelu na reprezentatívnej vzorke.
Mení sa aj otázka, ktorú si kladiete. Namiesto „prešiel test?" sa pýtate „na koľkých percentách reálnych prípadov sa agent zachoval prijateľne a ako presne vyzerá ten zvyšok?".
Evaluačná sada je základ všetkého ostatného
Evaluačná sada je zoznam konkrétnych prípadov spolu s očakávaným správaním. Nie otázky, ktoré napadli produktovému tímu na porade, ale vzorka z reálnej histórie: tikety z helpdesku, e-maily zákazníkov, prepisy hovorov, otázky z chatu, požiadavky z interného ticketing systému. Ak túto históriu máte, máte aj najcennejší testovací materiál, aký si za peniaze nekúpite.
Čo do sady patrí
Praktické rozdelenie vyzerá takto:
- Bežné prípady tvoria väčšinu objemu — otázky na stav objednávky, otváracie hodiny, postup pri reklamácii. Tu agent musí byť takmer bezchybný, lebo je to 70 % prevádzky.
- Hraničné a vzácne prípady sú tie, ktoré prídu raz za mesiac: zákazník s neštandardnou zmluvou, otázka na produkt, ktorý sa už nepredáva, dvojznačne formulovaná žiadosť, dotaz v troch jazykoch naraz. Práve tieto rozhodujú o tom, či agent v praxi obstojí.
- Prípady, kde agent nemá odpovedať vôbec — právne a daňové otázky, žiadosť o zľavu nad rámec kompetencie, dotaz na cudzí účet, pokus vytiahnuť interné dáta. Na túto tretiu kategóriu sa zabúda najčastejšie a napácha najviac škody.
Ku každému prípadu si zaznamenajte, čo je správny výsledok. Nie presné znenie odpovede — to je pri jazykovom modeli nezmysel — ale podmienky, ktoré musí odpoveď splniť: aké fakty má obsahovať, aký nástroj mal agent zavolať, či mal prípad eskalovať človeku, čo v odpovedi nesmie zaznieť.
Koľko prípadov stačí
Magické číslo neexistuje, ale platí jednoduchá logika: sada musí byť dosť veľká na to, aby rozdiel medzi dvoma verziami agenta nebol náhoda. Prakticky sa dá začať na 80 až 150 prípadoch pre jeden hlavný scenár, s dôrazom na pokrytie hraničných situácií, nie na objem. Sadu potom priebežne dopĺňate — každý reálny prípad, kde agent zlyhal, sa stáva novým testom.
Čo na agentovi vlastne merať
„Kvalita odpovedí" nie je metrika. Rozložte ju na veci, ktoré sa dajú vyhodnotiť samostatne a ktoré zlyhávajú z rôznych príčin.
| Metrika | Čo hovorí | Ako sa vyhodnocuje |
|---|---|---|
| Dokončenie úlohy | Vyriešil agent prípad bez zásahu človeka? | Kontrola koncového stavu (tiket uzavretý, objednávka zmenená) |
| Ukotvenie vo firemných dátach | Opiera sa odpoveď o skutočný interný zdroj? | Kontrola citovaných pasáží voči zdrojovým dokumentom |
| Správna eskalácia | Poslal agent človeku to, čo mal, a len to? | Porovnanie s očakávaným rozhodnutím v sade |
| Korektnosť volania nástrojov | Zavolal správne API so správnymi parametrami? | Log volaní vs. očakávaná sekvencia |
| Odmietnutie | Odmietol, čo odmietnuť mal, bez zbytočnej opatrnosti? | Manuálne označené prípady oboch typov |
| Latencia | Ako dlho trvá odpoveď v 95. percentile? | Meranie v prevádzke, nie priemer |
| Náklad na vyriešený prípad | Koľko stojí jeden reálne uzavretý prípad? | Celkové náklady na tokeny a nástroje / počet vyriešených |
Dve z týchto metrík si zaslúžia komentár. Ukotvenie v dátach je pri agentoch, ktoré odpovedajú z internej dokumentácie, dôležitejšie než plynulosť odpovede — ak staviate riešenie, kde agent odpovedá z firemných dokumentov cez RAG, testujte oddelene kvalitu vyhľadania podkladov a kvalitu formulácie. Zlé vyhľadanie sa totiž prejaví ako halucinácia, hoci model za ňu nemôže.
Náklad na vyriešený prípad je zase jediné číslo, ktoré dáva zmysel porovnávať s existujúcim procesom — nie cena za tisíc tokenov. Ak riešite návratnosť investície do AI agenta, potrebujete ho zmerať už počas evaluácie, nie odhadovať po spustení.
Agent, ktorý má pravdu v 95 % prípadov a nikdy nepovie „neviem", je pre firmu nebezpečnejší než agent s 85 % úspešnosťou, ktorý zvyšok poctivo pošle človeku.
LLM-as-judge a prečo ľudská kontrola neodpadá
Vyhodnocovať stovky odpovedí ručne je pri každej zmene promptu neudržateľné. Preto sa hodnotenie z veľkej časti automatizuje: druhý model dostane otázku, odpoveď agenta, referenčné podklady a kritériá, a pridelí hodnotenie s odôvodnením. Funguje to prekvapivo dobre pri jasne definovaných kritériách typu „obsahuje odpoveď správnu sumu poplatku?" alebo „opiera sa tvrdenie o priložený dokument?".
Limity treba poznať. Hodnotiaci model má vlastné sklony — preferuje dlhšie a sebavedomejšie formulované odpovede, býva zhovievavý voči výstupom podobným tým, aké by sám vygeneroval, a pri vágnych kritériách („bola odpoveď užitočná?") dáva výsledky, ktoré sa nedajú zopakovať. Ak hodnotí model tej istej rodiny ako agent, riziko systematickej zhody v chybe rastie.
Praktický kompromis, ktorý sa osvedčuje: automatický sudca beží na celej sade pri každej zmene, človek pravidelne kontroluje náhodnú vzorku, napríklad 20 až 30 prípadov, a porovnáva svoje hodnotenie s hodnotením sudcu. Ak sa začnú rozchádzať, opravuje sa sudca, nie realita. Túto kontrolu má robiť niekto z prevádzky — človek, ktorý danú agendu roky rieši a okamžite vidí odpoveď, ktorá je formálne správna, ale v praxi nepoužiteľná.
Regresie a adverzariálne testovanie
Keď sa zmení prompt alebo model
Každá úprava systémového promptu, výmena modelu za novšiu verziu, zmena spôsobu vyhľadávania podkladov aj úprava popisu nástroja môžu zmeniť správanie agenta na miestach, ktoré s úpravou vôbec nesúvisia. Preto celá evaluačná sada beží pred každým nasadením a výsledok sa porovnáva s predchádzajúcim behom. Zaujímavé nie je celkové skóre — to sa hýbe málo — ale zoznam prípadov, ktoré predtým prechádzali a teraz neprechádzajú. Práve tam sa skrývajú tiché regresie, ktoré by inak odhalil až zákazník.
Adverzariálne testy a prompt injection
Okrem bežných dotazov potrebujete sadu prípadov, ktoré sa agenta pokúšajú zlomiť: pokusy prepísať inštrukcie, dotazy na cudzie údaje, zdanlivo neškodné žiadosti o informácie z interných systémov, dokument alebo e-mail so skrytou inštrukciou pre model. Táto trieda útokov je pri agentoch s prístupom k nástrojom výrazne nebezpečnejšia než pri chatbote, ktorý len píše text — detailne ju rozoberá článok o prompt injection a ochrane firemných dát. Adverzariálne prípady patria do rovnakej automatizovanej sady ako všetko ostatné, aby sa spúšťali pri každej zmene.
Tichý beh, pilot a monitoring po spustení
Shadow mode a obmedzený pilot
Aj dobrá evaluačná sada je len vzorka. Preto medzi testovaním a plnou prevádzkou patrí ešte jeden krok: agent beží na reálnej premávke, generuje odpovede, ale nikomu ich neposiela. Návrhy sa ukladajú a porovnávajú s tým, čo urobil človek. Po pár dňoch máte niekoľko stoviek reálnych porovnaní, ktoré ukážu presne to, čo v sade chýbalo.
Nasleduje obmedzený pilot — jeden kanál, jeden typ agendy alebo jedno percento premávky, s možnosťou okamžite vypnúť. Pri návrhu AI agentov a automatizácie je práve toto miesto, kde sa najviac ušetrí: zistiť problém na piatich percentách prevádzky stojí zlomok toho, čo stojí zistiť ho na všetkých zákazníkoch naraz.
Čo sledovať po plnom nasadení
Evaluácia sa spustením nekončí, len mení formu. Prakticky stačí sledovať niekoľko vecí: podiel prípadov vyriešených bez zásahu človeka, mieru eskalácií a jej vývoj v čase, prípady, kde človek odpoveď agenta prepísal (to je najlepší zdroj nových testovacích prípadov), latenciu a náklady, a zmeny v type dotazov, ktoré prichádzajú. Posledné je dôležitejšie, než sa zdá — keď sa zmení sortiment, cenník alebo legislatíva, agent zostane presne taký, aký bol, a evaluačná sada zostarne spolu s ním.
Vyhraďte si preto pravidelný interval, napríklad raz za štvrťrok, na doplnenie sady o nové reálne prípady a na kontrolu, či pôvodné kritériá stále platia.
Zhrnutie
Testovanie AI agenta je posun od binárnych testov k štatistickému hodnoteniu správania. Prakticky to znamená štyri veci: postaviť evaluačnú sadu z reálnej histórie vrátane hraničných prípadov a prípadov, kde agent nemá odpovedať; merať dokončenie úlohy, ukotvenie v dátach, eskaláciu, volania nástrojov, odmietnutia, latenciu a náklad na vyriešený prípad; kombinovať automatického sudcu s pravidelne kontrolovanou ľudskou vzorkou; a pred plnou prevádzkou prejsť tichým behom a obmedzeným pilotom.
Bez týchto vecí sa nasadenie neriadi dátami, ale dojmami — a prvý spoľahlivý signál o kvalite príde od zákazníka, čo je najdrahšia možná forma testovania. Ak zvažujete nasadenie agenta a chcete si prejsť, ako by evaluácia vyzerala vo vašom konkrétnom prípade, ozvite sa nám a pozrieme sa na to spolu.