Samotné získanie odpovede od modelu AI ešte neznamená, že systém funguje správne. V prípade klasického softvéru často vieme jednoznačne overiť, či funkcia vrátila očakávaný výsledok. V systémoch AI môže byť odpoveď plynulá, logická a presvedčivá, a predsa obsahovať chyby.
Preto sa s rozvojom AI objavuje nový inžiniersky problém: ako systematicky merať kvalitu systému, ktorého odpovede nie sú vždy identické?
To je práve oblasť AI evaluation, teda evaluácie systémov umelej inteligencie.
A je oveľa širšia než len kontrola, či chatbot „odpovedá dobre“.
Test klasického softvéru a test AI nie je to isté
Predstavme si jednoduchú funkciu v aplikácii.
Používateľ zadá: 2 + 2
Systém by mal vrátiť: 4
Ak vráti 5, máme jednoznačnú chybu.
Môžeme pripraviť test: expect(calculate("2 + 2")).toBe(4)
a pri každom spustení dostaneme jasný výsledok: test prejde alebo neprejde.
V systémoch AI vyzerá situácia inak.
Používateľ sa môže opýtať: „Napíš krátku odpoveď pre zákazníka, ktorý sa pýta na termín dodania objednávky.”
Systém môže vygenerovať niekoľko rôznych odpovedí. Všetky môžu byť jazykovo správne. Všetky môžu znieť profesionálne. Jedna však môže obsahovať nepravdivý termín, druhá môže byť príliš dlhá, tretia môže vynechať dôležitú informáciu a štvrtá môže byť ideálna.
Nestačí teda skontrolovať, či bola odpoveď technicky vygenerovaná.
Treba skontrolovať, či spĺňa stanovené kritériá kvality.
Prvý problém: dobrá odpoveď nie je vždy pravdivá
To je jedna z najcharakteristickejších čŕt generatívnej AI.
Model môže vygenerovať odpoveď, ktorá znie veľmi presvedčivo, ale nemá oporu v zdrojových dátach.
V prípade systému využívajúceho RAG je problém ešte zaujímavejší. Systém môže dostať otázku, vyhľadať niekoľko častí dokumentácie a následne vygenerovať odpoveď.
Vtedy treba skontrolovať aspoň tri veci:
- Našli sa správne informácie? Vyhľadávací mechanizmus stiahol časti, ktoré skutočne súvisia s otázkou?
- Používa odpoveď nájdené informácie? Model nepridal niečo, čo v zdrojoch nebolo?
- Odpovedá odpoveď skutočne na otázku? Môže sa totiž stať, že retrieval funguje správne, ale konečná odpoveď je slabá.
Práve preto evaluácia RAG rozdeľuje okrem iného také aspekty, ako sú relevantnosť získaného kontextu, úplnosť vyhľadávania, správnosť odpovede a jej zhoda so zdrojmi.
To je dôležitá zmena v myslení o testovaní.
Netestujeme už len: otázka → odpoveď
ale celý reťazec: otázka → vyhľadávanie → kontext → model → odpoveď
Môže byť dobrý model a zlý AI systém
To je ďalšia vec, na ktorú sa ľahko zabúda.
Firma si môže vybrať veľmi dobrý jazykový model a napriek tomu vytvoriť slabý AI produkt.
Prečo? Lebo kvalita konečného systému nezávisí len od modelu.
Záleží aj na:
- kvalite dát,
- spôsobe prípravy kontextu,
- prome,
- spôsobe vyhľadávania informácií,
- parametroch modelu,
- nástrojoch sprístupnených AI,
- logike aplikácie,
- pamäti,
- spôsobe spracovania chýb,
- bezpečnostných opatreniach,
- spôsobe hodnotenia odpovedí.
To znamená, že otázka: „Ktorý model je najlepší?”
je často menej užitočná než: „Ktorý model najlepšie funguje v našom konkrétnom prípade použitia?”
Model, ktorý skvele zvláda generovanie marketingového obsahu, nemusí byť najlepším riešením na klasifikáciu dokumentov, analýzu dát či obsluhu obchodných procesov.
Preto by sa porovnávanie modelov malo robiť na reálnych úlohách, ktoré má systém vykonávať.
Najprv treba vytvoriť vlastný súbor testov
Nedá sa zmysluplne hodnotiť AI systém, ak nevieme, čo od neho očakávame.
Preto je jedným z najdôležitejších prvkov evaluácie príprava testovacieho datasetu, teda súboru reálnych alebo reprezentatívnych prípadov.
Napríklad firma buduje AI pre oddelenie zákazníckej podpory.
Namiesto ručnej kontroly jednej odpovede po každej zmene promptu možno pripraviť niekoľko stoviek prípadov:
- jednoduché otázky,
- nejasné otázky,
- otázky obsahujúce nesprávne predpoklady,
- otázky vyžadujúce vyhľadanie dokumentu,
- otázky týkajúce sa výnimiek,
- otázky týkajúce sa reklamácií,
- otázky vyžadujúce odmietnutie,
- otázky obsahujúce údaje, ktoré by AI nemala prezradiť.
Každú zmenu systému potom možno spustiť na tom istom súbore.
A práve tu AI začína pripomínať klasický softvér.
Už netestujeme jednu odpoveď. Testujeme správanie systému na celom súbore prípadov.
Prompt sa dá tiež testovať
Prompt sa často vníma ako text, ktorý niekto raz napísal a nechal v produkcii.
V skutočnosti môže byť súčasťou logiky aplikácie.
Zmena jednej vety môže spôsobiť:
- zlepšenie odpovedí v jednom scenári,
- zhoršenie odpovedí v inom,
- väčšiu tendenciu odmietať,
- väčší počet halucinácií,
- dlhšie odpovede,
- vyššie náklady,
- väčšiu spotrebu tokenov.
Preto by sa prompt mal chápať podobne ako kód.
Ak meníme prompt, oplatí sa vedieť:
- čo sa zlepšilo?
- čo sa zhoršilo?
- objavila sa regresia?
Aj preto má čoraz väčší význam automatická evaluácia, a nie manuálne hodnotenie niekoľkých ukážkových odpovedí.
AI môže prejsť test a stále byť zlým produktom
Predpokladajme, že sme pripravili 100 testovacích prípadov.
Systém odpovedal správne na 95. Výsledok vyzerá skvele. Ale čo ak sa päť nesprávnych odpovedí týka kritických situácií?
Ak chatbot odpovedá na otázky o otváracích hodinách, päť chýb môže byť problém.
Ak AI pomáha zamestnancovi analyzovať finančné, medicínske alebo právne dokumenty, význam týchto chýb môže byť úplne iný.
Preto samotný priemer nestačí.
Potrebujeme aj váženie prípadov.
Môžeme uznať, že:
- bežná otázka má váhu 1,
- závažná chyba má váhu 5,
- chyba zabezpečenia má váhu 10,
- zverejnenie dôvernej informácie má váhu 100.
Potom systém nedostane „95 percent”. Dostaneme oveľa užitočnejší obraz rizika.
Nie všetko sa dá zmerať jedným číslom
To je jeden z najdôležitejších problémov evaluácie AI.
Môžeme mať viacero metrík:
- Accuracy - či je odpoveď správna?
- Relevance - či odpovedá na otázku?
- Faithfulness / groundedness - či vychádza z poskytnutých zdrojov?
- Context precision - či sú vyhľadané úryvky relevantné?
- Context recall - či systém našiel potrebné informácie?
- Safety - či nevykonáva nežiaduce akcie?
- Latency - ako dlho používateľ čaká?
- Cost - koľko stojí vykonanie úlohy?
RAG môže mať teda veľmi dobrú kvalitu odpovedí, ale zároveň čerpať obrovské množstvo kontextu a generovať neprijateľné náklady.
Iný systém môže byť veľmi lacný a rýchly, ale robiť priveľa chýb.
Neexistuje teda jedno univerzálne číslo, ktoré určuje, či je AI „dobrá”. Kvalitu treba definovať v kontexte konkrétneho použitia.
A čo hodnotenie AI inou AI?
Tu sa objavuje ďalší zaujímavý mechanizmus.
Jedným zo spôsobov automatizácie evaluácie je využitie modelu ako sudcu, teda LLM-as-a-judge.
Napríklad:
Model A generuje odpoveď.
Model B dostane otázku, odpoveď a stanovené kritériá.
Následne hodnotí:
- správnosť,
- súlad s inštrukciou,
- úplnosť,
- štýl,
- bezpečnosť.
Moderné evaluačné nástroje umožňujú tiež spájať takéto hodnotenie s klasickými porovnaniami textu, vlastnými skriptami či gradermi založenými na konkrétnych pravidlách.
To enormne zvyšuje mierku testovania. Ale neznamená to, že človek prestáva byť potrebný. Hodnotiaci model sa tiež môže mýliť. Preto v systémoch s väčším biznisovým významom sa oplatí spájať automatické evaluácie s periodickým odborným hodnotením.
Najväčší problém: regresia
Predstavme si systém, ktorý funguje veľmi dobre. Tím vymení model za novší. Nová verzia je rýchlejšia a lacnejšia. Zdá sa teda, že všetko ide správnym smerom.
Po nasadení sa však ukáže, že:
- odpovede sú menej presné,
- model častejšie odmieta odpoveď,
- horšie využíva dokumentáciu,
- inak interpretuje inštrukcie,
- v niektorých scenároch začína poskytovať nesprávne informácie.
To je práve AI regression.
V klasickom softvéri poznáme regresiu už roky. Aj v AI ju musíme odhaľovať, ale problém je zložitejší, pretože správanie systému sa môže zmeniť bez klasickej „chyby”. Preto by sa každá väčšia zmena mala porovnávať s predchádzajúcou verziou.
Model.
Prompt.
Embedding.
Retriever.
Dokumentácia.
Logika agenta.
Parametre.
Každý z týchto prvkov môže ovplyvniť výsledok.
Agenta nestačí hodnotiť len podľa jeho konečnej odpovede
Ešte ťažšie je to v prípade AI agentov.
Klasický chatbot môže vykonať jednu úlohu: otázka → odpoveď.
Agent môže fungovať úplne inak: cieľ → plán → nástroj → výsledok → ďalší krok → rozhodnutie → akcia → odpoveď.
Ak agent cieľ nedosiahol, chceme vedieť nielen to, že prehral.
Chceme vedieť: kde spravil chybu?
- Zle pochopil úlohu?
- Vybral nesprávny nástroj?
- Odovzdal zlý parameter?
- Stiahol nesprávne dáta?
- Prijal zlé rozhodnutie po získaní výsledku?
- Vykonal príliš veľa krokov?
- Zastavil sa príliš skoro?
Vo výskume evaluácie agentov sa čoraz častejšie analyzuje nielen konečný výsledok, ale aj priebeh činnosti, používanie nástrojov, plánovanie, pamäť, spoľahlivosť a bezpečnosť.
To znamená, že budúcnosť testovania AI bude do veľkej miery spojená s analýzou traceov, teda úplného priebehu fungovania systému.
AI potrebuje niečo podobné ako CI/CD
Ak je AI súčasťou produktu, nemožno ju testovať len pred prvým nasadením.
Systém sa bude meniť.
Zmení sa model.
Zmení sa prompt.
Zmení sa znalostná báza.
Zmení sa spôsob vyhľadávania.
Zmení sa konfigurácia.
Preto by sa evaluácia mala stať súčasťou procesu vývoja.
Schéma môže vyzerať nasledovne: zmena → testy → evaluácia → porovnanie s predchádzajúcou verziou → rozhodnutie o nasadení
Ak nová verzia zlepší kvalitu v jednej oblasti, ale prekročí stanovený prah chýb v inej, nasadenie môže byť zastavené.
Je to veľmi podobná filozofia ako pri klasickom CI/CD, ale kritériá sú iné.
V prípade AI aplikácií môžeme súčasne kontrolovať kvalitu odpovedí, správnosť, bezpečnosť, náklady a latenciu. Objavujú sa už výskumné riešenia, ktoré spájajú evaluáciu s observability a kvalitativnými bránami v procese nasadzovania systémov LLM/RAG.
Dá sa teda AI testovať rovnako ako klasický softvér?
Áno, ale len čiastočne.
Klasický prístup je stále potrebný.
Testujeme:
- API,
- integrácie,
- oprávnenia,
- validáciu dát,
- chyby,
- timeouty,
- bezpečnosť,
- výkonnosť,
- logiku aplikácie.
Ale tým nemôžeme skončiť.
Prichádza druhá vrstva: evaluácia správania AI.
- Je odpoveď správna?
- Je v súlade so zdrojmi?
- Drží sa model inštrukcií?
- Správa sa systém správne v neočakávaných situáciách?
- Vyberá agent správne nástroje?
- Nezhoršila nová verzia kvalitu?
- Zostávajú náklady na fungovanie prijateľné?
- Získava používateľ skutočne hodnotu?
To už nie je klasický unit test.
Najlepší test AI nie je vždy laboratórny test
Je tu ešte jeden veľmi dôležitý prvok.
Systém môže výborne dopadnúť na pripravenom testovacom súbore, a napriek tomu mať problémy v reálnom svete. Preto sa oplatí sledovať aj skutočné interakcie. Nie preto, aby bol každý používateľ testerom. Ide o to, aby sa systém dal priebežne zlepšovať na základe reálnych prípadov:
- kde používatelia opravujú AI,
- kde žiadajú zopakovanie odpovede,
- kde prerušujú rozhovor,
- kde eskalujú prípad na človeka,
- kde agent nedosahuje cieľ,
- kde sa objavujú netypické otázky.
Takto vzniká nepretržitá slučka evaluácie: používateľ → činnosť AI → výsledok → analýza → nový testovací prípad → ďalšia verzia systému
Je to úplne iný model vývoja než jednorazové „nasadili sme AI a funguje“.
AI by sa nemala hodnotiť otázkou „funguje?“
To je príliš málo.
Lepšie otázky znejú:
- Ako často funguje správne?
- V akých situáciách sa mýli?
- Aké vážne sú tieto chyby?
- Je nová verzia lepšia než predchádzajúca?
- Je systém dostatočne bezpečný?
- Sú odpovede založené na správnych údajoch?
- Koľko stojí dosiahnutie konkrétneho výsledku?
Až takáto sada otázok umožňuje hovoriť o zrelom AI systéme.
Najdôležitejšia zmena v myslení
V softvérovom vývoji dlhé roky platilo jednoduché pravidlo: kód by mal fungovať.
V AI systémoch ho treba rozšíriť: systém by mal fungovať dobre, predvídateľne a merateľne.
Je to obrovský rozdiel. Lebo AI nie je funkcia, ktorá vždy vracia ten istý výsledok. Je to pravdepodobnostný systém, ktorého správanie závisí od modelu, údajov, kontextu, inštrukcií a celej architektúry okolo neho.
Preto sa profesionálne nasadenie AI nekončí v momente, keď model začne odpovedať.
Vtedy sa práve začína otázka: odkiaľ vieme, že mu môžeme dôverovať?
A práve na túto otázku by mala odpovedať dobre navrhnutá evaluácia.
V budúcnosti sa testovanie AI systémov pravdepodobne stane rovnako prirodzenou súčasťou vývojového procesu ako jednotkové testy, integračné testy či monitoring. Nie preto, že AI je „zo svojej podstaty nebezpečná“. Jednoducho preto, že systém, ktorého výsledok nie je vždy deterministický, vyžaduje iný spôsob merania kvality.
A čím viac AI prechádza od generovania textu k obsluhe reálnych procesov, práci s dátami, RAG a vykonávaniu úkonov cez agentov, tým dôležitejšia sa stáva nielen otázka „vie to AI spraviť?“, ale aj: „vieme dokázať, že to robí dostatočne dobre?“
