Každý, kto nasadil LLM aplikáciu do produkcie, vie ako to vyzerá: demo funguje skvelo, stakeholders sú nadšení, prvé odpovede vyzerajú presvedčivo. A potom príde zákazník s otázkou, ktorú ste netestovali, a model odpovie so sebavedomím znalca niečo, čo je jednoducho nepravda. Alebo po aktualizácii promptu zistíte, že edge case, ktorý predtým fungoval, prestál fungovať. Neviete kedy. Neviete prečo.
Problém nie je v modeli. Problém je v absencii merania. Tento článok je o tom, ako postaviť eval infraštruktúru, ktorá vám povie — s číslami, nie s pocitom — či je vaša LLM aplikácia lepšia alebo horšia než včera.
Prečo "vyzerá to dobre" nie je metrika
V tradičnom softvéri máte unit testy, integračné testy, CI pipeline. Pred každým merge viete, či niečo prestalo fungovať. LLM výstupy sú probabilistické — ten istý vstup môže dať mierne odlišný výstup, a nesprávna odpoveď nevyvolá výnimku. Zlyhanie je tiché.
Tímy bez eval procesu spoliehajú na troch ľudí, ktorí raz za čas kliknú cez aplikáciu a povedia "zdá sa OK". Toto funguje do prvých 200 používateľov. Potom sa use-case space rozšíri, modely sa menia, prompty sa upravujú — a nikto nevie, čo sa práve pokazilo.
Eval (evaluácia) je systematické meranie kvality LLM výstupov oproti definovaným kritériám. Nie raz, ale ako kontinuálny proces: pred deployom, po každej zmene promptu, po každom upgrade modelu, pravidelne v produkcii.
Tri typy evalov — kde každý patrí
Pred tým, ako prejdeme k nástrojom, je dôležité rozlíšiť tri rôzne kontexty, kde eval prebieha:
Offline eval — spúšťate pred deployom na fixnom datasete. Odpoveď dostanete rýchlo, reprodukovateľne. Vhodné pre regresné testy v CI/CD.
Online eval — beží v produkcii na reálnych dopytoch, zvyčajne na vzorke. Odhalí distribučný posun: reálni používatelia sa správajú inak než testovacie scenáre.
Fine-tuning eval — špecifický prípad, kde meriate, či dotrénovaný model je lepší než base model na target taskoch. Opisuje ho samostatný článok (Ako zmerať, či fine-tuning pomohol). Sem nepatrí.
RAG eval — meria faithfulness (odpovedal model podľa toho, čo mal k dispozícii?), answer relevancy a context recall. Štandardom je RAGAS framework, popísaný v článku Ako evaluovať RAG (RAGAS). Sem tiež nepatrí.
Tento článok sa zameriava na offline aj online eval pre produkčnú LLM aplikáciu — chatbot, copilot, agent.
Ako postaviť eval set z reálnych prípadov
Najčastejšia chyba: eval set vytvorí AI inžinier pri víkendovom brainstorme. Výsledok pokrýva to, čo si myslí, že sú edge cases — nie to, čo reálni používatelia skutočne pýtajú.
Správny postup:
- 1.Zbierajte reálne logy od prvého dňa. Každý dopytu a každú odpoveď logujte (s anonymizáciou PII). Toto je váš zlatý fond.
- 2.Identifikujte zlyhania. Prvých 200–500 reálnych interakcií ručne prejdite. Kde model odpovedal zle? Kde odmietol odpovedať, hoci mal? Kde bol zbytočne vágny?
- 3.Kategorizujte zlyhania podľa typu. Príklady kategórií: halucinácia faktu, nesprávne odmietnutie, nesprávny formát odpovede, relevantná ale neúplná odpoveď, bezpečnostná obídenie.
- 4.Z každej kategórie vyberte reprezentatívne prípady. Minimálna zlatá vzorka (golden set): 100–300 príkladov so správnou odpoveďou alebo kritériom hodnotenia. Pre produkčný systém: 500–1 000+ prípadov.
- 5.Každý príklad opatrite ground truth alebo rubric. Pre jednoduché prípady: referenčná odpoveď alebo expected output. Pre komplexné prípady: rubric (súbor kritérií, ktoré odpoveď musí spĺňať).
Zlatý set nie je statický. Každý mesiac pridajte nové zlyhania z produkcie. Starý set, ktorý neaktualizujete, prestane odrážať reálne správanie používateľov.
Metriky — presné, keď máte referenciu
Pre jednoznačné úlohy (extrakcia, klasifikácia, štruktúrovaný výstup) fungujú deterministické metriky:
- Exact match — výstup buď sedí s referenciou, alebo nie. Vhodné pre extrakciu entít, klasifikáciu tried, JSON schému.
- F1 skóre — meria prekrytie tokenov medzi výstupom a referenciou. Vhodné kde máte viac správnych formulácií.
- BLEU / ROUGE — štandardné pre preklad a sumarizáciu. V praxi málo používané pre všeobecné LLM aplikácie, lepšie pre špecifické NLP tasky.
Tieto metriky sú rýchle, lacné, deterministické. Ale zlyhávajú pre väčšinu produkčných use-casov, kde "správna odpoveď" môže mať desiatky formulácií.
LLM-as-judge — sila a limity
Pre otvorené úlohy — kde referenčná odpoveď neexistuje alebo je príliš variabilná — nastupuje LLM-as-judge: iný LLM (väčší alebo rovnako silný) hodnotí výstup podľa rubric.
Prečo to funguje? GPT-4 trieda modelov dosahuje asi 85 % zhodu s human reviewermi, čo je vyššia konzistencia než typická human-human zhoda (okolo 81 %) na rovnakých úlohách. Pri 500–5 000× nižších nákladoch než ľudská anotácia.
Ale LLM-as-judge má päť zdokumentovaných biasov, ktoré musíte aktívne kompenzovať:
1. Position bias — judge preferuje odpoveď, ktorá je v poradí prvá (alebo posledná). Riešenie: vždy porovnávajte s otočeným poradím (A vs B → potom B vs A) a použite väčšinový hlas.
2. Verbosity bias — dlhšia odpoveď pôsobí presvedčivejšie, aj keď je menej presná. Priama dôsledok toho, ako boli modely trénované na human feedback. Riešenie: v rubric explicitne penalizujte zbytočnú dĺžku.
3. Self-preference bias — model preferuje vlastné výstupy. Claude v1 vykazoval asi 25 % vyšší win rate pre vlastné odpovede pri self-hodnotení; GPT-4 okolo 10 %. Riešenie: nikdy nepoužívajte rovnaký model ako producenta aj judge-a.
4. Format bias — odpovede s markdown, bullet pointmi alebo peknou štruktúrou dostávajú vyššie skóre. Riešenie: rubric hodnotí obsah, nie prezentáciu.
5. Calibration drift — pri dlhých batched evaluáciách sa judge stáva buď príliš benevolentným, alebo príliš prísnym. Riešenie: do batch vždy vložte niekoľko kalibračných príkladov so známym skóre a sledujte drift.
Praktická odporúčaná štruktúra LLM-as-judge volania:
- Systémový prompt: rola judge-a, zoznam hodnotiacich dimenzií, číselná škála (napr. 1–5 per dimenzia)
- User prompt: kontext otázky, odpoveď na hodnotenie, rubric s definíciami každého skóre
- Few-shot príklady: 3–5 dobre hodnotených a 3–5 zle hodnotených príkladov (zvyšujú konzistenciu z okolo 65 % na okolo 77 %)
Zhoda judge-a s human reviewermi: ak meriate a dosahujete 75 %+, máte využiteľný signál. Pod 65 % produkuje judge viac šumu než informácie — je čas prestavať rubric.
G-Eval a DAG hodnotenie
Moderné eval frameworky ako DeepEval implementujú prístupy, ktoré idú ďalej než jednoduchý "daj skóre 1-5":
G-Eval — judge najskôr vygeneruje hodnotiacu procedúru (chain-of-thought kroky) a potom podľa nej skóruje. Znižuje arbitrárnosť hodnotenia.
DAG scoring — rozkladá hodnotenie do stromu podmienok. Namiesto "je to dobré?" prechádza: "je to fakticky správne?" → ak áno: "je to úplné?" → ak áno: "je to bezpečné?". Každý uzol môže byť iná metrika alebo LLM-as-judge call.
Pre produkčné systémy odporúčame kombináciu: deterministické metriky pre to, čo sa dá merať objektívne, plus LLM-as-judge pre dimenzie ako koherencia, tón, úplnosť.
Regresné testy v CI pred každým release
Tu je praktický workflow, ktorý odporúčame klientom:
- 1.Golden set v repozitári — eval dataset je súčasťou kódu, verzionovaný v gite vedľa promptov.
- 2.Eval CI krok — pred každým merge do main spustite eval pipeline. Ak súhrnné skóre klesne o viac než definovaný prah (napr. 3 percentuálne body), merge je zablokovaný.
- 3.Regression-specific testy — ku každému zisteného zlyhaniu z produkcie pridajte test-case. Raz zistená chyba sa nesmie ticho vrátiť.
- 4.Separate eval environment — eval pipeline nevolá ten istý model/endpoint ako produkcia. Izolácia zabraňuje tomu, aby eval ovplyvnil produkčné logy.
- 5.Výsledky viditeľné — nie len pass/fail. Každý PR obsahuje eval diff: ktoré metriky sa zlepšili, ktoré klesli, o koľko.
DeepEval je de facto štandard pre CI/CD gating — integruje sa ako pytest plugin, export do JUnit XML pre CI, threshold-based gating. Pre stakeholder dashboardy a production traceability dopĺňa ho Braintrust.
Online eval — čo unikne offline testom
Offline eval vám povie, či vaša aplikácia funguje na príkladoch, ktoré poznáte. Nepoví vám, či reálni používatelia narazia na niečo nové.
Online eval typicky beží na 5–10 % produkčných dopytov (sampling kvôli cene). Hľadáte:
- Distribučný posun — používatelia pýtajú veci, ktoré nie sú v golden sete. Sledujte kategórie, kde judge konzistentne skóruje nízko.
- Anomálie — odpovede, ktoré sú neočakávane krátke alebo dlhé, majú nízku konzistenciu pri opakovanom spustení alebo obsahujú bezpečnostné vzory.
- Latencia vs. kvalita trade-off — rýchlejší model môže byť horší v konkrétnych kategóriách.
Online eval dáta sa pravidelne zlievajú späť do golden setu. Cyklus: produkcia → zlyhania → golden set → CI testy → deploy.
Odlíšenie od fine-tuning eval a RAG eval
Ľudia tieto tri typy evalov často miešajú:
Fine-tuning eval — meria, či dotrénovaný model robí to, na čo bol dotrénovaný. Porovnáva base model vs. fine-tuned model na task-specific datasete. Nepatrí do CI pipeline produkčnej aplikácie — je to jednorazový (alebo per-run) experiment pred registráciou modelu. Viac v článku Ako zmerať, či fine-tuning pomohol.
RAG eval (RAGAS) — meria RAG pipeline: faithfulness (cituje model len to, čo mal v kontexte?), answer relevancy, context precision a recall. Nástroj RAGAS poskytuje 8 špecifických metrík. Toto je vrstva navyše — hodnotíte retrieval aj generation oddelene. Viac v Ako evaluovať RAG (RAGAS).
Produkčný LLM eval (tento článok) — meria end-to-end kvalitu pre používateľa. Nezaujíma vás, či model správne citoval dokument; zaujíma vás, či odpoveď bola užitočná, bezpečná a v súlade s biznis kritériami.
EU AI Act a eval ako právna povinnosť
Od 2. augusta 2026 platí plná aplikovateľnosť EU AI Act. Pre firmy, ktoré nasadzujú LLM systémy v high-risk kategóriách (zdravotníctvo, kritická infraštruktúra, HR, vzdelávanie), sa eval dokumentácia stáva právnou povinnosťou.
Konkrétne: pre high-risk systémy vyžaduje AI Act zdokumentovaný a kontinuálny risk management vrátane testovania a validácie, sledovania hallucination rates, bias patterns a prompt injection rizika. Pokuty za najzávažnejšie porušenia dosahujú až 35 miliónov eur alebo 7 % globálneho ročného obratu.
Praktická implikácia: ak eval robíte ad hoc v Notion dokumente, nespĺňate požiadavku. Potrebujete audit trail — verzia promptu, verzia modelu, dátum eval behu, výsledky, kto schválil deploy. Presné technické požiadavky na formát dokumentácie zatiaľ nie sú štandardizované na úrovni implementing acts, ale smer je jasný: bez traceability nie je compliance.
Časté otázky
Ako veľký golden set potrebujem na začiatok?
Pre prvé nasadenie stačí 100–200 príkladov zo skutočných interakcií. Dôležitejšia než veľkosť je reprezentatívnosť — pokrytie hlavných kategórií zlyhania, nie len "typických" dopytov. S rastúcim objemom produkcie golden set rastie organicky: každý mesiac pridáte desiatky nových prípadov zo zlyhaní.
Môžem používať ten istý model ako producenta aj LLM judge-a?
Nie. Self-preference bias je dobre zdokumentovaný — modely konzistentne hodnotia vlastné výstupy lepšie než alternatívy. Ak produkujete výstupy Claudom, hodnoťte ich GPT-4 triedou a naopak. Pre open-weight stack: produkcia na Llama, judge na Qwen alebo DeepSeek.
Koľko stojí LLM-as-judge v produkcii?
Závisí od modelu a objemu. Orientačne: pri 1 000 dopytoch denne a sampling rate 10 % robíte 100 judge volaní za deň. S frontier modelom (vstup 2–5 USD, výstup 12–25 USD za milión tokenov) sú náklady pri typickom krátkom judge prompte rádovo jednotky dolárov za deň. Oveľa menej než ekvivalentná ľudská anotácia.
Čo robiť, keď LLM judge nie je konzistentný?
Prvý krok: pridajte few-shot príklady do judge promptu — 3–5 dobre a 3–5 zle hodnotených prípadov s vysvetlením. Konzistencia by mala narásť. Ak nie, problém je v rubric: kritériá sú príliš vágne alebo sa navzájom prekrývajú. Prepíšte ich na konkrétne, merateľné podmienky. Cieľ: zhoda judge-a s human reviewermi nad 75 %.
Môžem eval plne automatizovať bez ľudskej kontroly?
Pre väčšinu use-casov áno, ale s výnimkou. Pre high-stakes systémy (medicína, právo, financie) by mal byť minimálne mesačný ručný review vzorky výstupov. LLM judge má slepé miesta — predovšetkým pre subtilné faktické chyby v odborných oblastiach, kde mu chýba doménová znalosť. Automatizácia znižuje objem práce, ale nenahradí expertné posúdenie pre kritické rozhodnutia.
*Ak si nie ste istí, kde vaša LLM aplikácia skutočne zlyháva — a väčšina tímov si tým nie je istá — prvý krok je jednoduchý: pozrite sa do logov a nájdite päť najhorších odpovedí za posledný mesiac. Z toho sa začína každý dobrý eval program. Radi vám pomôžeme nastaviť celý proces — od golden setu cez CI gating až po produkčný monitoring.*