Jak měřit kvalitu odpovědí

Představ si, že dodavatel předvede vedení firmy nového AI asistenta pro zákaznickou podporu. Položí mu pět otázek, asistent pětkrát odpoví skvěle a všichni v místnosti kývou. O tři měsíce později chodí stížnosti: asistent slíbil zákazníkovi vrácení peněz, na které neměl nárok, a jinému odpověděl česky na slovenský dotaz. Ukázka nelhala. Jen nic nedokazovala.

Tahle lekce je o tom, jak z „připadá mi to dobré“ udělat něco, co se dá změřit, porovnat a hlídat. V oboru se tomu říká evaluace a je to podle mnoha praktiků nejdůležitější a nejvíc podceňovaná část celé AI aplikace. Navazuje na lekci Jak výstupy ověřovat: tam šlo o to, jak zkontrolovat jednu odpověď. Tady jde o to, jak posoudit tisíce odpovědí, které nikdo neuvidí předem.

Evaluace(evaluation, eval)

Systematické měření, jak dobře AI systém plní konkrétní úlohu: na předem připravené sadě vstupů se spustí, výstupy se ohodnotí podle jasných kritérií a výsledek se shrne do čísel, která jde porovnat mezi verzemi. Praktici často zkracují na „evaly“.

Proč ukázka není důkaz

Důvody jsou dva a oba už znáš z dřívějších lekcí.

První je náhoda. V lekci Předpověď dalšího slova sis vyzkoušel, že model každé další slovo losuje z pravděpodobností. Stejná otázka tedy může dostat pokaždé trochu jinou odpověď a občas i výrazně jinou. Pět dobrých odpovědí v ukázce neříká, jak často přijde ta špatná. Může to být jednou za sto, ale taky jednou za deset.

Druhý je dlouhý chvost vstupů. Kdo dělá ukázku, klade otázky, které ho napadnou, a ty bývají typické a slušně položené. Skuteční uživatelé píšou s překlepy, vkládají celé e-maily, ptají se na tři věci najednou, píšou slovensky, zkoušejí asistenta nachytat nebo se ptají na něco, co do jeho oboru vůbec nepatří. Takových neobvyklých vstupů je každý zvlášť málo, ale dohromady tvoří velkou část provozu.

Je tu i třetí, lidský důvod. Plynulý a sebejistý text působí kompetentně, i když je obsahově vedle (víc v lekci Halucinace). Když odpověď čteš jednu za druhou bez kritérií, hodnotíš hlavně dojem. A dojem je přesně ta věc, kterou jazykové modely umí vyrobit nejlépe.

Co je „dobrá odpověď“ právě pro tvoji úlohu

Než začneš cokoli měřit, musíš napsat, co vlastně chceš. Zní to samozřejmě, ale tady většina projektů selže: tým se shodne, že asistent má odpovídat „dobře“, a každý si pod tím představí něco jiného. Kvalita má u AI vždy několik rozměrů a pro každou úlohu váží jinak.

Rozměr	Otázka, kterou si klade hodnotitel	Kde na něm záleží nejvíc
Správnost	Je to věcně pravda?	Skoro všude
Věrnost zdrojům	Opírá se každé tvrzení o dodané podklady, nebo si model něco přidal?	Asistenti nad firemními dokumenty
Úplnost	Je tam všechno podstatné? Nechybí výjimka nebo podmínka?	Shrnutí, odpovědi na pravidla a nároky
Formát	Má výstup předepsaný tvar (délka, struktura, JSON)?	Výstup, který čte jiný systém
Tón	Odpovídá stylu firmy a situaci (omluva, věcnost, tykání či vykání)?	Texty pro zákazníky
Bezpečnost	Neprozradí důvěrné údaje, neporadí nic nebezpečného, nediskriminuje?	Všechno, co jde ven
Chování při odmítnutí	Odmítne, co odmítnout má, a neodmítá to, co odmítnout nemá?	Asistenti s omezeným oborem
Rychlost (latence, latency)	Za jak dlouho odpověď přijde?	Chat v reálném čase
Cena	Kolik stojí jedna odpověď a celý provoz za měsíc?	Velké objemy

Dvě věci z tabulky stojí za zdůraznění. Věrnost zdrojům není totéž co správnost. Odpověď může být pravdivá, ale nepocházet z firemní směrnice, kterou měl model použít (například cituje obecný zákoník práce místo vaší přísnější interní úpravy). U asistenta nad dokumenty je to chyba, i když fakticky sedí.

A odmítání má dvě strany. Asistent, který odmítne každou trochu citlivou otázku, je bezpečný a k ničemu. Měříš tedy obojí: kolikrát odpověděl, i když neměl, a kolikrát odmítl, i když odpovědět měl.

Rychlost a cenu nepodceňuj jen proto, že nejsou „o kvalitě textu“. Nejlepší model, který odpovídá dvacet sekund, může být pro chat na webu horší volba než o něco slabší model, který odpoví za dvě. O tom, jak cenu a výběr modelu vyvažovat, je lekce Náklady a volba modelu.

Různé úlohy, různá měřítka

Způsob měření závisí hlavně na tom, jak „uzavřená“ je správná odpověď. Čím jednoznačnější, tím víc jde měřit automaticky a levně.

Třídění: přesnost, preciznost a záchyt

Klasifikace(classification)

Úloha, kde model zařazuje vstup do jedné z předem daných kategorií: e-mail je, nebo není reklamace; dotaz patří oddělení A, B nebo C; recenze je kladná, nebo záporná.

U klasifikace znáš pro každý testovací vstup správnou kategorii, takže výsledek jde spočítat. Nejjednodušší číslo je přesnost (accuracy): kolik procent zařazení bylo správně. Má ale zrádnou slabinu, kterou nejlíp ukáže příklad.

Firma testuje model, který má z příchozí pošty vytáhnout reklamace. V testovacím vzorku je 1 000 e-mailů, z toho 100 skutečných reklamací. Model označil jako reklamaci 90 e-mailů. Výsledek ve čtyřech políčkách:

	Model řekl „reklamace“	Model řekl „není reklamace“
Opravdu je reklamace (100)	70 správně chycených	30 přehlédnutých
Opravdu není reklamace (900)	20 planých poplachů	880 správně propuštěných

• Přesnost: správně bylo 70 + 880 = 950 z 1 000, tedy 95 %. Zní to výborně.
• Preciznost (precision): ze 90 e-mailů, které model označil, bylo opravdu reklamací 70, tedy asi 78 %. Zhruba každý pátý poplach je planý.
• Záchyt (recall, česky se říká i úplnost nebo senzitivita): ze 100 skutečných reklamací model našel 70, tedy 70 %. Každá třetí reklamace propadla.

A teď ta past: model, který by neoznačil nic, by měl přesnost 90 % (900 správně propuštěných z 1 000). Tedy jen o pět bodů hůř, a přitom by byl úplně k ničemu.

Tabulce se odborně říká matice záměn (confusion matrix) a vyplatí se ji chtít vidět vždycky, když ti někdo hlásí „přesnost 95 %“. Kdykoli je hledaná věc vzácná (reklamace, podvod, stížnost na šikanu), samotná přesnost klame.

Která chyba je horší, je byznysové rozhodnutí, ne technické. U reklamací je přehlédnutá reklamace dražší (zákazník čeká, lhůta běží) než planý poplach (kolega e-mail otevře a přeřadí), takže budeš hlídat hlavně záchyt. U automatického blokování plateb kvůli podezření z podvodu bývá naopak drahý planý poplach, protože naštve poctivého zákazníka. Obě čísla se obvykle přetahují: když model nastavíš citlivěji, chytí víc, ale i víc planě poplaší.

Do hloubkyF1 a proč jedno číslo nestačí+

Protože preciznost a záchyt jdou proti sobě, používá se často i jejich kombinace zvaná F1 skóre. Je to takzvaný harmonický průměr obou čísel, který je nízký, kdykoli je nízké kterékoli z nich. V našem příkladu: 2 × 0,78 × 0,70 / (0,78 + 0,70) ≈ 0,74. Model, který neoznačí nic, má záchyt 0, a tedy i F1 rovno 0, takže ho tohle číslo neošálí.

F1 je praktické pro rychlé srovnání verzí, ale schovává, která chyba převažuje. Pro rozhodnutí o provozu si proto vždy nech ukázat celou matici záměn a čísla přepočti na peníze nebo čas: „30 přehlédnutých reklamací měsíčně, každá znamená riziko zmeškané lhůty“ řekne vedení víc než „F1 = 0,74“.

U víc než dvou kategorií (třeba směrování na pět oddělení) se matice rozroste na 5 × 5 a ukáže, které kategorie si model plete mezi sebou. To bývá nejcennější informace pro úpravu promptu.

Vytahování údajů: shoda po polích

Když model z faktury vytahuje dodavatele, IČO, datum splatnosti a částku (viz lekce Strukturovaný výstup), hodnotí se každé pole zvlášť. U každého testovacího dokumentu znáš správné hodnoty a porovnáváš: sedí IČO přesně? Sedí částka na haléř? Výsledek je pak tabulka typu „IČO 99 % správně, datum splatnosti 91 %, částka 97 %“.

Takový rozpad je mnohem užitečnější než jedno souhrnné číslo, protože ukáže, kde přesně model chybuje. Před porovnáním je potřeba sjednotit drobnosti, které chybou nejsou: mezery, velikost písmen, formát data („1. 3. 2026“ i „2026-03-01“ je totéž). A je potřeba rozhodnout, co je „vážná“ chyba: překlep v názvu firmy je jiná váha než o řád špatná částka.

Volný text: hodnoticí rubriky

Na shrnutí schůzky, odpověď zákazníkovi nebo vysvětlení pravidla neexistuje jedna správná odpověď. Dvě úplně jinak napsané odpovědi můžou být obě výborné. Tady se hodnotí podle rubriky.

Rubrika(rubric)

Hodnoticí arch: seznam konkrétních kritérií, podle kterých se odpověď posuzuje, ideálně každé s odpovědí ano/ne. Například „uvádí správnou lhůtu“, „nic si nepřidává mimo podklady“, „nabízí další krok“, „vyká“.

Dobrá rubrika vypadá jako kontrolní seznam, ne jako známkování od jedné do pěti. U stupnice se dva hodnotitelé těžko shodnou, jestli je odpověď „trojka“, nebo „čtyřka“, a z výsledku „průměr 3,8“ se nedá poznat, co opravit. Odpověď ano/ne na konkrétní otázku je jednoznačnější a rovnou říká, kde je problém. Kdo podle rubriky hodnotí (lidé, nebo jiný model), je téma příští lekce Testovací sady a hodnocení modelem.

Před spuštěním a v provozu

Evaluace probíhá ve dvou fázích, které se doplňují.

Offline evaluace (před vydáním) znamená, že systém spustíš na připravené testovací sadě, kde víš, co je správně. Je opakovatelná, nikoho neohrozí a dá se pustit kdykoli. Její slabina: měří jen to, na co sis vzpomněl při sestavování sady.

Online evaluace (v provozu) měří, jak systém funguje na skutečných uživatelích. Typické zdroje:

• zpětná vazba uživatelů: palec nahoru a dolů, „pomohlo vám to?“, ale i nepřímé signály, například jestli zákazník po odpovědi asistenta stejně volal na linku nebo jestli agent podpory navrženou odpověď odeslal beze změny, upravil, nebo zahodil;
• namátková kontrola: odborník pravidelně projde vzorek skutečných konverzací podle stejné rubriky jako offline;
• A/B test: část uživatelů dostane novou verzi, část starou, a porovnáš výsledky na tom, na čem firmě záleží (vyřešené požadavky, spokojenost, čas).

Pozor, zpětná vazba uživatelů je zkreslená: hodnotí jen malá část lidí, častěji ti naštvaní, a palec nahoru neříká, jestli byla odpověď pravdivá, jen jestli se líbila. Je to užitečný signál, ne měřítko správnosti. Online sledování podrobně probírá lekce Monitoring.

Obě fáze tvoří kruh: co najdeš v provozu (nový typ dotazu, nový druh chyby), přidáš do offline sady, aby se to příště chytilo ještě před vydáním.

Evaly jako testy, které se pouštějí pořád

Programátoři znají automatické testy: při každé změně kódu se spustí stovky kontrol a když něco, co dřív fungovalo, přestane fungovat, víš to hned. Evaly jsou totéž pro AI. A potřebuješ je ze stejného důvodu: u AI se věci rozbíjejí nenápadně.

Kvalita se může změnit, když:

• upravíš prompt. Přidáš větu, aby asistent lépe řešil reklamace, a on přitom začne hůř odpovídat na dotazy k dopravě. Bez evalu se to dozvíš od zákazníků.
• změníš model. Nový model bývá v průměru lepší, ale „v průměru“ neznamená „na tvé úloze“. Může jinak formátovat, být upovídanější nebo jinak odmítat.
• dodavatel změní model pod tebou. Výrobci staré modely postupně vyřazují a máš přejít na nový, a ve spotřebitelských aplikacích se model mění bez tvého přičinění. Výzkumníci ze Stanfordu a Berkeley v roce 2023 porovnali verze GPT-4 z března a června a zjistili, že se chování „téhož“ modelu za tři měsíce výrazně změnilo: v jedné úloze (poznat, jestli je číslo prvočíslo) klesla úspěšnost z 84 % na 51 %, jinde se naopak zlepšila.
• změní se data. Firma vydá nový ceník nebo směrnici, asistent nad dokumenty dostane jiné podklady a odpovídá jinak.

Regrese(regression)

Zhoršení něčeho, co dřív fungovalo, jako vedlejší účinek změny. U AI je typická: oprava jednoho problému tiše rozbije jiný.

Z toho plyne pravidlo, které by mělo platit v každé firmě s AI v provozu: žádná změna promptu, modelu ani podkladů nejde do provozu bez toho, aby prošla evaluací. Výsledek se porovná s předchozí verzí, a když se něco zhorší, je to vidět dřív, než to uvidí zákazník.

Do hloubkyProč se stejný test vyplatí pustit víckrát+

Protože model odpovídá s prvkem náhody, i stejná verze dá při dvou bězích na téže sadě trochu jiné výsledky. Když ti eval ukáže, že nová verze má 91 % a stará 89 %, nemusí to nic znamenat, může jít o šum.

Praktické postupy: u důležitých srovnání pusť sadu víckrát a dívej se, jak moc výsledky kolísají. Rozdíl menší než to kolísání neber vážně. Čím menší sada, tím větší šum: u dvaceti příkladů znamená jeden příklad pět procentních bodů. A vedle souhrnného čísla vždy čti konkrétní případy, které se změnily z „prošlo“ na „neprošlo“. Často je jich jen pár a rovnou ukážou, co se rozbilo.

U úloh, kde potřebuješ co nejstálejší výstup (klasifikace, extrakce), se navíc obvykle nastavuje nízká teplota, aby se náhoda omezila. Úplně zmizet ale nemusí.

Co si odnést do praxe

Když ve firmě rozhoduješ o AI projektu, ptej se na evaluaci dřív než na model. Jaká kritéria jste si stanovili? Na jaké sadě jste měřili a kolik v ní bylo neobvyklých případů? Jak vypadala matice záměn? Co se stane, až dodavatel model vymění? Dodavatel nebo tým, který na tyhle otázky nemá odpověď, ti zatím předvádí zkušební jízdu, ne technickou kontrolu.

Co si odnést

• Pár povedených odpovědí v ukázce nic nedokazuje: model odpovídá s prvkem náhody a skuteční uživatelé posílají mnohem pestřejší vstupy.
• Kvalita má víc rozměrů (správnost, věrnost zdrojům, úplnost, formát, tón, bezpečnost, odmítání, rychlost, cena). Pro svou úlohu je sepiš jako konkrétní, měřitelná kritéria.
• U třídění nestačí přesnost. Chtěj vidět matici záměn, preciznost a záchyt a rozhodni, která chyba je pro firmu dražší.
• Vytahování údajů se hodnotí pole po poli, volný text podle rubriky s otázkami ano/ne.
• Offline evaluace před vydáním a online sledování v provozu se doplňují; co najdeš v provozu, přidej do testovací sady.
• Evaly spouštěj při každé změně promptu, modelu nebo podkladů, jinak regrese uvidí jako první zákazníci.

Zdroje a další čtení

• Anthropic: Define success criteria and build evaluations – jak stanovit měřitelná kritéria a postavit evaluaci, od přesné shody po hodnocení modelem.
• Google: Classification – Accuracy, recall, precision – srozumitelné vysvětlení přesnosti, preciznosti a záchytu s příklady (anglicky).
• Chen, Zaharia, Zou: How is ChatGPT's behavior changing over time? (arXiv, 2023) – studie o tom, jak se chování „téhož“ modelu změnilo během tří měsíců.
• Hamel Husain: Your AI Product Needs Evals – praktický pohled na tři úrovně evaluace od automatických kontrol po A/B testy.