Evaluace

„Vypadá to dobře“ není měřítko. Bez evaluace nepoznáš, jestli nová verze promptu pomohla, jestli ti výměna modelu něco nerozbila a jestli aplikace funguje i na vstupech, které tě nenapadly. Je to zdaleka nejpřehlíženější část práce s LLM a přitom je to jediné, co odděluje demo od produktu.

Základ: testovací sada

Začni tím nejjednodušším, co funguje: tabulka reálných vstupů a očekávaných výstupů.

vstup                                   očekávané
"Kde je moje objednávka 4821?"          kategorie=doprava, potřebuje_lidsky=ne
"Chci vrátit peníze, jste podvodníci"   kategorie=reklamace, potřebuje_lidsky=ano
""                                      kategorie=nezname
"asdfgh"                                kategorie=nezname

Dvacet až padesát položek stačí na to, abys poznal, že se něco zlepšilo nebo rozbilo. Do sady patří i ošklivé vstupy: prázdný text, cizí jazyk, nesmysl, pokus o manipulaci, velmi dlouhý vstup.

💡 Sbírej sadu z produkce. Každý případ, kdy si někdo stěžoval, patří do testů, přesně tak vzniká sada, která má cenu.

Jak vyhodnocovat

Podle typu úlohy:

Retrieval měř zvlášť od generování. Když RAG odpovídá špatně, chceš vědět, jestli selhalo hledání, nebo model.

LLM jako porotce

Volný text nejde porovnat na shodu, tak se používá druhý model jako hodnotitel. Funguje to překvapivě dobře, ale jen když mu dáš konkrétní kritéria místo „ohodnoť kvalitu 1–10“:

Ohodnoť odpověď podle podkladů. Vrať JSON:
{
  "vychazi_z_podkladu": true/false,     // netvrdí nic, co v podkladech není?
  "odpovida_na_otazku": true/false,
  "uvadi_zdroj": true/false,
  "problem": "stručně, když něco selhalo"
}

Na co dát pozor:

• Hodnoť jednu věc po druhé, ne všechno naráz.
• Nenech model hodnotit vlastní odpověď ve stejném volání, má sklon si přisvědčit.
• Ověř si porotce na dvaceti ručně ohodnocených případech. Pokud se s tebou neshodne, nemá cenu mu věřit ani ve zbytku.

📐 Perplexity, MMLU, pass@k a Elo a proč se jim nedá věřit, rozebírá perplexity a benchmarky.

Jak velká musí být testovací sada

Tohle je otázka, kterou skoro nikdo nepoloží, a přitom rozhoduje o tom, jestli tvoje čísla něco znamenají. Když máš dvacet případů a projde jich sedmnáct, máš úspěšnost 85 %. Jenže interval spolehlivosti je zhruba od 62 % do 97 %. To znamená, že změna z 85 % na 80 % ti neřekne vůbec nic.

Praktický důsledek: se sadou o padesáti případech nemá smysl ladit prompt na jednotky procent, protože ta čísla jsou šum. Buď si postav větší sadu, nebo přijmi, že hledáš jen velké rozdíly.

Trik, který pomáhá: porovnávej párově. Místo „starý prompt 82 %, nový 85 %“ se dívej jen na případy, kde se ty dvě verze liší. Když jich je pět a nový vyhrál ve čtyřech, víš víc než z celkových procent, a navíc si ty případy můžeš přečíst.

Když neexistuje jediná správná odpověď

U shrnování, psaní a poradenství není co porovnávat na shodu. Máš tři možnosti, v pořadí podle spolehlivosti:

1. Rozlož to na ověřitelné podotázky. Místo „je to shrnutí dobré“ se ptej „obsahuje datum splatnosti“, „obsahuje částku“, „neobsahuje nic, co v originále není“. Z měkkého úsudku se stane sada tvrdých kontrol.
2. Porovnávej dvě verze, nehodnoť jednu. Modelu jako porotci jde mnohem líp říct „A je lepší než B“ než dát absolutní známku, protože nemusí kalibrovat stupnici.
3. Nech hodnotit člověka na vzorku a porotce zkalibruj proti němu.

Ke třetímu bodu jedna věc, která se přeskakuje: porotce se musí ověřit. Vezmi padesát případů, ohodnoť je ručně, a spočítej, jak často se s tebou model shodne. Když je shoda pod osmdesát procent, tvoje automatická evaluace měří spíš vkus porotce než kvalitu produktu.

Co sledovat v produkci

Evaluace nekončí před nasazením:

• Podíl fallbacků: jak často model neodpoví nebo neprojde validace.
• Úspěšnost nástrojů: kolik volání skončilo chybou.
• Spotřeba tokenů a cena na dotaz: utíká ti to nahoru?
• Latence p95: ne průměr, ten ti tu bolest schová.
• Zpětná vazba uživatelů: palec nahoru/dolů u odpovědi je nejlevnější zdroj testovacích dat.

Regresní past

Modely se mění pod rukama: poskytovatel vydá novou verzi a chování se posune, aniž bys cokoli udělal. Proto:

1. Připni si verzi modelu, když to jde.
2. Před přechodem na novou verzi projeď sadu.
3. Verzuj prompty stejně jako kód a zaznamenávej, která verze promptu vygenerovala kterou odpověď.

Cvičení

1. Na sadě 20 případů projde 17, tedy 85 %. Po úpravě promptu projde 18, tedy 90 %. Můžeš tvrdit, že je nová verze lepší?
2. Model jako porotce dává tvé aplikaci konzistentně 4,5 z 5. Co si ověříš dřív, než tomu uvěříš?

Shrnutí

• Bez testovací sady se hádáš s dojmem; dvacet až padesát reálných případů stačí.
• Klasifikaci měř přesnou shodou, volný text kritérii přes model-porotce.
• U RAG měř zvlášť vyhledávání a zvlášť odpověď.
• Modely se mění, připínej verze, verzuj prompty a před upgradem projeď sadu.