Samotné získání odpovědi od modelu AI ještě neznamená, že systém funguje správně. V případě klasického softwaru můžeme často jednoznačně zkontrolovat, zda funkce vrátila očekávaný výsledek. V systémech AI může být odpověď plynulá, logická a přesvědčivá, a přesto obsahovat chyby.
Proto se s rozvojem AI objevuje nový inženýrský problém: jak systematicky měřit kvalitu systému, jehož odpovědi nejsou vždy totožné?
Právě to je oblast AI evaluation, tedy evaluace systémů umělé inteligence.
A je mnohem širší než ověření, zda chatbot „odpovídá dobře“.
Test klasického softwaru a test AI není totéž
Představme si jednoduchou funkci v aplikaci.
Uživatel zadá: 2 + 2
Systém by měl vrátit: 4
Pokud vrátí 5, máme jednoznačnou chybu.
Můžeme připravit test: expect(calculate("2 + 2")).toBe(4)
a pokaždé dostaneme jasný výsledek: test projde, nebo neprojde.
V systémech AI vypadá situace jinak.
Uživatel se může zeptat: „Napiš krátkou odpověď pro zákazníka, který se ptá na termín dodání objednávky.“
Systém může vygenerovat několik různých odpovědí. Všechny mohou být jazykově správné. Všechny mohou znít profesionálně. Jedna však může obsahovat nepravdivý termín, druhá může být příliš dlouhá, třetí může vynechat důležitou informaci a čtvrtá může být ideální.
Nestačí tedy zkontrolovat, zda je odpověď technicky vygenerována.
Je třeba ověřit, zda splňuje stanovená kritéria kvality.
První problém: dobrá odpověď není vždy pravdivá
To je jedna z nejcharakterističtějších vlastností generativní AI.
Model může vygenerovat odpověď, která zní velmi přesvědčivě, ale nemá oporu v zdrojových datech.
V případě systému využívajícího RAG je problém ještě zajímavější. Systém může obdržet otázku, vyhledat několik úryvků dokumentace a následně vygenerovat odpověď.
Pak je třeba ověřit alespoň tři věci:
- Byly nalezeny správné informace? Našel vyhledávací mechanismus úryvky skutečně související s otázkou?
- Využívá odpověď nalezené informace? Nedoplnil model něco, co ve zdrojích nebylo?
- Odpovídá odpověď skutečně na otázku? Je totiž možné mít správně fungující retrieval, ale mizernou finální odpověď.
Právě proto evaluace RAG mimo jiné rozděluje aspekty jako relevance načteného kontextu, úplnost vyhledávání, správnost odpovědi a její soulad se zdroji.
To je důležitá změna v uvažování o testování.
Netestujeme už jen: otázka → odpověď
ale celý řetězec: otázka → vyhledávání → kontext → model → odpověď
Je možné mít dobrý model a špatný AI systém
To je další věc, na kterou se snadno zapomíná.
Firma si může vybrat velmi dobrý jazykový model a přesto vytvořit slabý AI produkt.
Proč? Protože kvalita výsledného systému nezávisí jen na modelu.
Důležité jsou také:
- kvalita dat,
- způsob přípravy kontextu,
- prompt,
- způsob vyhledávání informací,
- parametry modelu,
- nástroje zpřístupněné AI,
- logika aplikace,
- paměť,
- způsob zpracování chyb,
- zabezpečení,
- způsob hodnocení odpovědí.
To znamená, že otázka: „Který model je nejlepší?”
je často méně užitečná než: „Který model se nejlépe osvědčuje v našem konkrétním případě použití?”
Model, který skvěle zvládá generování marketingových textů, nemusí být nejlepší volbou pro klasifikaci dokumentů, analýzu dat nebo obsluhu obchodních procesů.
Proto by porovnávání modelů mělo probíhat na reálných úkolech, které má systém vykonávat.
Nejprve je třeba vytvořit vlastní sadu testů
Nemá smysl rozumně hodnotit AI systém, pokud nevíme, co od něj očekáváme.
Proto je jedním z nejdůležitějších prvků evaluace příprava testovacího datasetu, tedy sady reálných nebo reprezentativních případů.
Například firma buduje AI pro zákaznickou podporu.
Místo ruční kontroly jedné odpovědi po každé změně promptu lze připravit několik stovek případů:
- jednoduché otázky,
- nejasné otázky,
- otázky obsahující chybné předpoklady,
- otázky vyžadující vyhledání dokumentu,
- otázky týkající se výjimek,
- otázky týkající se reklamací,
- otázky vyžadující odmítnutí,
- otázky obsahující data, která by AI neměla zveřejnit.
Každou změnu systému lze poté spustit na stejné sadě.
A právě zde AI začíná připomínat klasický software.
Netestujeme už jednu odpověď. Testujeme chování systému na celé sadě případů.
Prompt lze také testovat
Prompt bývá často vnímán jako text, který někdo jednou napsal a nechal ho v produkci.
Ve skutečnosti může být součástí logiky aplikace.
Změna jedné věty může způsobit:
- zlepšení odpovědi v jednom scénáři,
- zhoršení odpovědi v jiném,
- větší sklon k odmítání,
- větší počet halucinací,
- delší odpovědi,
- vyšší náklady,
- větší spotřebu tokenů.
Proto by měl být prompt považován podobně jako kód.
Pokud prompt měníme, je dobré vědět:
- co se zlepšilo?
- co se zhoršilo?
- objevila se regrese?
Právě proto nabývá stále většího významu automatická evaluace, a ne ruční hodnocení několika ukázkových odpovědí.
AI může projít testem a přesto být špatným produktem
Předpokládejme, že jsme připravili 100 testovacích případů.
Systém odpověděl správně na 95. Výsledek vypadá skvěle. Ale co když se těch pět chybných odpovědí týká kritických situací?
Pokud chatbot odpovídá na otázky o otevírací době, pět chyb může být problém.
Pokud AI pomáhá zaměstnanci analyzovat finanční, zdravotní nebo právní dokumenty, význam těchto chyb může být úplně jiný.
Proto samotný průměr nestačí.
Potřebujeme také vážení případů.
Můžeme si určit, že:
- běžná otázka má váhu 1,
- důležitá chyba má váhu 5,
- bezpečnostní chyba má váhu 10,
- prozrazení důvěrné informace má váhu 100.
Pak systém nedostane „95 procent“. Dostaneme mnohem užitečnější obraz rizika.
Ne všechno lze změřit jedním číslem
To je jeden z nejdůležitějších problémů hodnocení AI.
Můžeme mít několik metrik:
- Accuracy - zda je odpověď správná?
- Relevance - zda odpovídá na otázku?
- Faithfulness / groundedness - zda vychází z poskytnutých zdrojů?
- Context precision - zda jsou vyhledané úryvky relevantní?
- Context recall - zda systém našel potřebné informace?
- Safety - neprovádí nežádoucí akce?
- Latency - jak dlouho uživatel čeká?
- Cost - kolik provedení úkolu stojí?
RAG může mít velmi dobrou kvalitu odpovědí, ale zároveň načítat obrovské množství kontextu a generovat nepřijatelný náklad.
Jiný systém může být velmi levný a rychlý, ale dělat příliš mnoho chyb.
Neexistuje tedy jedno univerzální číslo, které určuje, zda je AI „dobrá“. Kvalitu je třeba definovat v kontextu konkrétního použití.
A co hodnocení AI jinou AI?
Zde se objevuje další zajímavý mechanismus.
Jedním ze způsobů automatizace evaluace je využití modelu jako rozhodčího, tedy LLM-as-a-judge.
Například:
Model A generuje odpověď.
Model B dostane otázku, odpověď a stanovená kritéria.
Poté hodnotí:
- správnost,
- soulad s instrukcí,
- úplnost,
- styl,
- bezpečnost.
Současné evaluační nástroje umožňují také kombinovat takové hodnocení s klasickými porovnáními textu, vlastními skripty nebo hodnotiteli založenými na konkrétních pravidlech.
To enormně zvyšuje škálu testování. To ale neznamená, že člověk přestává být potřeba. I hodnoticí model se může mýlit. Proto se v systémech s větším obchodním významem vyplatí kombinovat automatické evaluace s periodickým expertním hodnocením.
Největší problém: regrese
Představme si systém, který funguje velmi dobře. Tým nasadí novější model. Nová verze je rychlejší a levnější. Zdá se tedy, že vše jde správným směrem.
Po nasazení se ale ukáže, že:
- odpovědi jsou méně přesné,
- model častěji odmítá odpověď,
- hůře používá dokumentaci,
- jinak interpretuje instrukce,
- v některých scénářích začíná uvádět nesprávné informace.
To je právě AI regression.
V klasickém software známe regresi už léta. V AI ji také musíme odhalovat, ale problém je složitější, protože se chování systému může změnit bez klasické „chyby“. Proto by každá větší změna měla být porovnána s předchozí verzí.
Model.
Prompt.
Embedding.
Retriever.
Dokumentace.
Logika agenta.
Parametry.
Každá z těchto složek může ovlivnit výsledek.
Agenta nestačí hodnotit jen podle jeho finální odpovědi
Ještě obtížnější je to v případě AI agentů.
Klasický chatbot může vykonat jeden úkol: otázka → odpověď.
Agent může fungovat úplně jinak: cíl → plán → nástroj → výsledek → další krok → rozhodnutí → akce → odpověď.
Pokud agent cíle nedosáhl, chceme vědět nejen to, že prohrál.
Chceme vědět: kde udělal chybu?
- Špatně pochopil zadání?
- Zvolil špatný nástroj?
- Předal nesprávný parametr?
- Načetl nesprávná data?
- Udělal špatné rozhodnutí po získání výsledku?
- Provedl příliš mnoho kroků?
- Zastavil se příliš brzy?
Ve výzkumu hodnocení agentů se stále častěji analyzuje právě nejen konečný výsledek, ale také průběh činnosti, používání nástrojů, plánování, paměť, spolehlivost a bezpečnost.
To znamená, že budoucnost testování AI bude z velké části spojena s analýzou traceů, tedy úplného průběhu činnosti systému.
AI potřebuje něco podobného jako CI/CD
Pokud je AI součástí produktu, nelze ji testovat jen před prvním nasazením.
Systém se bude měnit.
Změní se model.
Změní se prompt.
Změní se báze znalostí.
Změní se způsob vyhledávání.
Změní se konfigurace.
Proto by evaluace měla vstoupit do procesu vývoje.
Schéma může vypadat následovně: změna → testy → evaluace → porovnání s předchozí verzí → rozhodnutí o nasazení
Pokud nová verze zlepší kvalitu v jedné oblasti, ale překročí stanovený práh chyb v jiné, nasazení může být zastaveno.
Je to velmi podobná filozofie jako u klasického CI/CD, ale kritéria jsou jiná.
V případě AI aplikací můžeme současně kontrolovat kvalitu odpovědí, správnost, bezpečnost, náklady i zpoždění. Už se objevují výzkumná řešení, která spojují evaluaci s observability a quality gates v procesu nasazování systémů LLM/RAG.
Lze tedy AI testovat stejně jako klasický software?
Ano, ale jen částečně.
Klasický přístup je stále potřebný.
Testujeme:
- API,
- integrace,
- oprávnění,
- validaci dat,
- chyby,
- timeouty,
- bezpečnost,
- výkon,
- logiku aplikace.
Ale tím nemůžeme skončit.
Přidává se druhá vrstva: evaluace chování AI.
- Je odpověď správná?
- Je v souladu se zdroji?
- Drží se model instrukcí?
- Chová se systém správně v neočekávaných situacích?
- Volí agent správné nástroje?
- Nezhoršila nová verze kvalitu?
- Zůstávají provozní náklady přijatelné?
- Získává uživatel skutečně hodnotu?
To už není klasický unit test.
Nejlepší test AI není vždy laboratorní test
Ještě je tu jeden velmi důležitý prvek.
Systém může na připraveném testovacím souboru dosahovat skvělých výsledků, a přesto mít v reálném světě problémy. Proto se vyplatí sledovat i skutečné interakce. Ne proto, aby byl každý uživatel testerem. Jde o to, aby bylo možné systém průběžně zlepšovat na základě reálných případů:
- kde uživatelé AI opravují,
- kde žádají o zopakování odpovědi,
- kde přerušují konverzaci,
- kde eskalují záležitost na člověka,
- kde agent nedosahuje cíle,
- kde se objevují neobvyklé otázky.
Takto vzniká průběžná smyčka evaluace: uživatel → akce AI → výsledek → analýza → nový testovací případ → další verze systému
To je zcela jiný model vývoje než jednorázové „nasadili jsme AI a funguje to“.
AI by se neměla hodnotit otázkou „funguje to?“
To je příliš málo.
Lepší otázky zní:
- Jak často funguje správně?
- V jakých situacích se mýlí?
- Jak závažné jsou tyto chyby?
- Je nová verze lepší než předchozí?
- Je systém dostatečně bezpečný?
- Jsou odpovědi založené na správných datech?
- Kolik stojí dosažení konkrétního výsledku?
Teprve taková sada otázek umožňuje mluvit o zralém systému AI.
Nejdůležitější změna v myšlení
Po léta v softwarovém vývoji platilo jednoduché pravidlo: kód by měl fungovat.
V systémech AI je třeba ho rozšířit: systém by měl fungovat dobře, předvídatelně a měřitelně.
To je obrovský rozdíl. Protože AI není funkce, která vždy vrací stejný výsledek. Je to pravděpodobnostní systém, jehož chování závisí na modelu, datech, kontextu, instrukcích a celé architektuře kolem něj.
Proto profesionální nasazení AI nekončí v momentě, kdy model začne odpovídat.
Teprve tehdy začíná otázka: odkud víme, že mu můžeme důvěřovat?
A právě na tuto otázku by měla odpovídat dobře navržená evaluace.
V budoucnu se testování systémů AI pravděpodobně stane stejně přirozenou součástí vývojového procesu jako unit testy, integrační testy nebo monitoring. Ne proto, že je AI „ze své podstaty nebezpečná“. Prostě proto, že systém, jehož výsledek není vždy deterministický, vyžaduje jiný způsob měření kvality.
A čím více AI přechází od generování textu k obsluze skutečných procesů, práci s daty, RAG a vykonávání akcí prostřednictvím agentů, tím důležitější je nejen otázka „dokáže to AI udělat?“, ale také: „dokážeme prokázat, že to dělá dostatečně dobře?“
