Po fine-tuningu máte nový model. Benchmark na trénovacej úlohe stúpol. Tím sa teší. Lenže keď nasadíte model do produkcie, zákazníci začnú hlásiť podivné odpovede v prípadoch, ktoré pred tréningom fungovali bezchybne. Čo sa stalo? Stala sa vec, ktorú vidíme opakovane: model bol evaluovaný len na tom, čo sme ho učili, nie na tom, čo sme mu náhodou odučili.
Eval fine-tunovaného modelu je iná disciplína než eval produkčného LLM systému. Neporovnávate, či váš RAG pipeline vracia správne chunks — porovnávate, čo konkrétna zmena váh urobila s modelom ako celkom. Tento článok pokrýva, ako na to systematicky: od task-specific eval setu cez porovnanie base vs. fine-tuned až po detekciu regresií na všeobecných schopnostiach.
Prečo "loss klesol" nestačí
Trénovacia strata (training loss) vám hovorí, ako dobre sa model prispôsobil trénovacím dátam. Nehovorí vám nič o tom, či sa správanie modelu v praxi zlepšilo. A rozhodne vám nehovorí, čo sa s modelom stalo mimo doménu, na ktorej ste trénovali.
V praxi vidíme tri časté omyly:
- Evaluovať len na trénovacích dátach — model memoroval vzory, nie sa naučil zovšeobecniť
- Testovať len cieľovú úlohu — ignorovať generálne schopnosti, ktoré fine-tuning mohol poškodiť
- Neporovnávať s base modelom — neviete, čo je prínos fine-tuningu a čo bola schopnosť base modelu
Katastrofické zabudnutie (catastrophic forgetting) je reálny jav, zdokumentovaný empiricky na viacerých rodách modelov. Fine-tuning na úzkych dátach môže degradovať schopnosti, ktoré model získal počas pretrainingu — logické uvažovanie, formátovanie, inštrukčné nasledovanie, znalosti mimo domény. PEFT metódy ako LoRA toto riziko zmierňujú, ale neodstraňujú ho.
Tri vrstvy eval frameworku
Solídny eval fine-tunovaného modelu stojí na troch vrstvách. Každá zachytáva iné riziko.
1. Task-specific eval set
Toto je váš primárny signal. Meria, či model zvládol to, na čo ste ho trénovali.
Kľúčová zásada: held-out test set. Časť označených dát, ktorú model nikdy nevidel počas trénovania, musí byť vyhradená výlučne pre záverečnú evalváciu. Ak použijete rovnaké dáta na tréning aj eval, meranie je bezcenné — model mohol memorovať, nie sa naučiť.
Praktický postup: 1. Pred tréningom rozdeľte dataset na tréning / validácia / test (napr. 80 / 10 / 10) 2. Validačná sada slúži na sledovanie počas trénovania (early stopping, hyperparameter tuning) 3. Test sada sa použije raz, až keď je tréning hotový — nie opakovane na ladenie
Na samotné meranie potrebujete evalváciu s definovanou správnou odpoveďou pre vašu úlohu. Formáty sú rôzne podľa typu tasku:
- Klasifikácia / routing — presnosť (accuracy), F1 skóre, confusion matrix
- Extrakcia entít / štruktúrovaný výstup — token-level F1, exact match, alebo custom parser
- Generatívne tasky — tu to komplikujete: BLEU/ROUGE majú nízku koreláciu s ľudskou kvalitou pre LLM; lepšie sú LLM-as-judge (frontier model hodnotí odpoveď), alebo vlastné rubrics
Pre väčšinu B2B doménových use casov odporúčame zostrojiť 100–500 otázok s referenčnými odpoveďami ručne, overenými domain expertom. Toto je váš zlatý standard. Množstvo nie je podstatné — podstatná je pokrytosť typov prípadov a edge cases, ktoré sú v praxi najdôležitejšie.
2. Porovnanie base vs. fine-tuned
Fine-tuned model evaluujte vždy v porovnaní s base modelom, nie len absolútne. Dôvod: potrebujete vedieť, čo fine-tuning skutočne pridal oproti tomu, čo ste dostali zadarmo.
Typická tabuľka výsledkov by mala obsahovať:
- Base model (bez fine-tuningu) na vašom task-specific teste
- Fine-tuned model na rovnakom teste
- Delta (zlepšenie alebo zhoršenie)
Ak fine-tuned model prekoná base model o marginálnych 2–3 %, kriticky zvážte, či stojí za náklady na údržbu. Ak je delta záporná, máte problém — buď s kvalitou dát, alebo s nastavením trénovania.
Porovnanie zároveň odhaľuje, kedy fine-tuning nie je riešenie. Videli sme prípady, kde base model s dobre nastaveným promptom (systémový prompt, few-shot príklady) dosiahol 90 % toho, čo fine-tuned model — za nulové náklady na tréning a bez rizika regresie. Pre tieto prípady sme klientom odporučili RAG vs fine-tuning rozhodovanie ako prvý krok pred tréningom.
3. Regresia na všeobecných schopnostiach
Toto je vrstva, ktorú väčšina tímov preskočí — a najčastejšie práve tu sa skryjú problémy, ktoré sa prejavia až v produkcii.
Fine-tuning na úzkej doméne môže poškodiť:
- Inštrukčné nasledovanie — model začne ignorovať časti promptu, meniť formát odpovede
- Odmietnutie odpovede na out-of-domain otázky — model sa snaží odpovedať doménovo aj na otázky, kde by mal povedať "neviem"
- Logické uvažovanie — výsledky na reasoning taskoch môžu klesnúť
- Jazykové schopnosti — ak ste trénovali na jednom jazyku, iné jazyky môžu degradovať
Na detekciu regresií používame kombináciu prístupov:
a) Štandardné benchmarky ako sanity check
lm-evaluation-harness od EleutherAI umožňuje spustiť model na štandardných benchmarkoch (MMLU a podobne). Neočakávajte, že fine-tuned model bude lepší na MMLU než base — to nie je cieľ. Sledujete, či výrazne neklesol (o viac ako niekoľko bodov je dôvod na preskúmanie).
b) Behavioral regression set
Vytvorte si vlastnú sadu príkladov, ktorá pokrýva schopnosti dôležité pre vašu aplikáciu, ale nesúvisí priamo s trénovacou doménou. Napríklad: - Formátovanie výstupu (JSON, Markdown, tabuľky) - Odmietnutie nezmyselných otázok - Inštrukčné nasledovanie (nasledovanie viacnásobných podmienok v prompte) - Faktická presnosť v oblastiach mimo doménu
Tento set môžete zostaviť raz a používať ho pri každom ďalšom kole fine-tuningu. Investícia sa vyplatí pri treťom a štvrtom kole, keď bez neho strácate prehľad.
c) Porovnanie distribúcie odpovedí
Pragmatický prístup: vezmite 200–500 reálnych vstupov z produkcie (alebo stagingu), spustite na nich base aj fine-tuned model a porovnajte distribúciu dĺžky odpovedí, frekvenciu odmietnutí, a — ak máte LLM-as-judge nastavený — distribúciu hodnotení. Štatistické odchýlky signalizujú problém skôr, než ho nahlásia používatelia.
Nastavenie held-out test setu: čo robíme zle
Held-out test set znie jednoducho, ale v praxi sa kazí na niekoľkých miestach.
Distribučná kontaminácia: Ak ste generovali trénovacie dáta synteticky (teacher model), a test set ste tiež vygenerovali rovnakým procesom, meriete len to, ako dobre model napodobňuje teachera — nie ako dobre rieši reálnu úlohu. Test set musí pochádzať z reálnych prípadov alebo byť overený domain expertom.
Dočasná separácia: Pre produkčné systémy s pravidelným fine-tuningom je kritické, aby test set bol časovo separovaný od trénovacej sady. Ak trénujete na dátach z Q1 a testujete na Q1 dátach (aj keď oddelená sada), môžete nevidieť distribučný posun, ktorý nastane v Q2. Ideálne je, aby test set pochádzal z iného časového okna ako tréning.
Veľkosť a reprezentatívnosť: Test set 50 príkladov je príliš malý na štatisticky spoľahlivé závery pre väčšinu úloh. Pre binárnu klasifikáciu potrebujete rádovo 300–500 príkladov, aby bol 95% interval spoľahlivosti dostatočne úzky na rozhodovanie. Pre generatívne tasky s LLM-as-judge sú použiteľné menšie sady, ale interpretujte s opatrnosťou.
Leakage cez augmentáciu: Ak ste na augmentáciu trénovacích dát používali parafrázy alebo variácie reálnych príkladov, overte, že žiadna variácia sa nedostala do test setu.
Praktický eval pipeline krok za krokom
Pre tímy, ktoré fine-tuning robia prvýkrát alebo len príležitostne, odporúčame tento minimalistický postup:
- 1.Pred tréningom: Vyhraďte test set (minimálne 10 % dát, nikdy ho nepoužite pri tréningu), zaznamenajte baseline skóre base modelu na task-specific eval aj na behavioral regression sete.
- 1.Počas trénovania: Sledujte validačnú stratu (val loss) — mala by klesať spolu s trénovacou stratou. Ak val loss stagnuje alebo stúpa, kým train loss klesá, pretrénujete model. Zastavte tréning a skúste menší počet epoch alebo väčší
rankadaptéra.
- 1.Po trénovaní: Spustite model na task-specific test sete. Porovnajte s base modelom. Spustite behavioral regression set. Porovnajte s base modelom.
- 1.Pred nasadením: LLM-as-judge na vzorke reálnych vstupov (ak máte). Manuálna revízia aspoň 20–30 konkrétnych prípadov — čísla klamú, čítanie odpovedí odhalí vzory, ktoré metriky nevideli.
Celý tento pipeline môžete orámovať nástrojmi ako lm-evaluation-harness, vlastným Python skriptom nad vLLM alebo Ollama, alebo cloud eval platformami. Pre väčšinu B2B projektov na mieru je vlastný skript postačujúci — nepreceňujte infraštruktúru, keď potrebujete iba spoľahlivú odpoveď na otázku "je model lepší".
Kedy je regresia príliš veľká na akceptovanie
Neexistuje univerzálna hranica. Závisí od use casu. Niekoľko orientačných pravidiel:
Task-specific zlepšenie musí prevážiť regresiu na všeobecných schopnostiach. Ak fine-tuning zlepšil doménovú presnosť o 15 bodov, ale inštrukčné nasledovanie kleslo o 20 %, výsledok je záporný — neformát odpovede robí model menej použiteľným aj v práve tej doméne, kde ste ho vylepšili.
Nulové zlepšenie na task-specific teste je dôvod zastaviť. Ak base model s few-shot promptom dosiahne rovnaké výsledky ako fine-tuned model, fine-tuning nebol potrebný. Toto vidíme u klientov častejšie, než by sa dalo čakať — podceňujú, čo zvládne dobrý prompt.
Výrazná regresia na odmietnutí out-of-domain otázok je vážny problém. Model, ktorý bol natrénovaný odpovedať na technické dotazy o konkrétnom produkte, nesmie začať halucináciami odpovedať aj na otázky, kde by správna odpoveď bola "toto neviem". Táto regresia je priame bezpečnostné riziko v regulovaných odvetviach. Súvisí s témou guardrails pre AI agentov, kde mechanizmus odmietnutia je prvou líniou obrany.
Kontinuálna evalvácia: keď fine-tuning opakujete
Doménové modely sa netunujú raz — ak to robíte správne, každé nové kolo dát prinesie nové kolo fine-tuningu. V tomto prípade je systematická evalvácia ešte dôležitejšia, pretože potrebujete sledovať trend cez iterácie, nie len absolútne čísla.
Odporúčame viesť jednoduchú evidenciu každého kola: - Dátum trénovania a verzia modelu (base + fine-tuned) - Veľkosť trénovacej sady a zdroj dát - Task-specific skóre (base / fine-tuned / delta) - Behavioral regression skóre - Poznámky o anomáliách alebo ručnej revízii
Táto evidencia je investíciou, ktorá sa vráti pri debugovaní regresie v produkčnom systéme. Bez nej sa stáva, že tím vie "niečo sa zmenilo po poslednom tréningu" — ale nevie čo, kedy, a prečo.
Pre tímy, ktoré plánujú pravidelný fine-tuning s cyklom kratším ako mesiac, sa oplatí uvažovať o automatizovanom eval pipeline — každý commit nového modelu spúšťa task-specific eval a regression set automaticky a výsledky loguje. Táto úroveň investície má zmysel pri produkčných systémoch, kde je model priamo vo flotile zákazníckych interakcií.
Časté otázky
Koľko príkladov potrebujem v test sete?
Pre väčšinu B2B doménových úloh odporúčame minimálne 100–300 ručne overených príkladov. Pod 100 je štatistická spoľahlivosť nízka — malý dataset sťažuje rozlíšenie skutočného zlepšenia od náhodného rozptylu. Pre binárnu klasifikáciu je 300–500 rozumná spodná hranica pre 95% interval spoľahlivosti. Pre generatívne tasky s LLM-as-judge môžete pracovať s menšou sadou, ale interpretujte s väčšou opatrnosťou.
Čo je LLM-as-judge a kedy ho použiť?
LLM-as-judge je technika, kde frontier model (napr. z rodiny Claude Sonnet alebo GPT) hodnotí odpovede fine-tunovaného modelu podľa definovaných kritérií — presnosť, relevancia, formát, tón. Je užitočný pre generatívne tasky, kde neexistuje jednoznačná "správna odpoveď". Nevýhody: pridáva náklady (API volania), a judge môže mať vlastné biasy (preferuje dlhšie odpovede, formálny štýl). Pre doménové B2B aplikácie odporúčame kombináciu: LLM-as-judge pre celkovú kvalitu + deterministické metriky (exact match, parser) pre kritické polia.
Ako odhaliť katastrofické zabudnutie bez komplexného benchmark setu?
Pragmatický postup: vezmite 50–100 reálnych promptov, ktoré model pred fine-tuningom zvládal správne, a overte, či ich zvláda aj po tréningu. Ak máte prístup k logom produkčného systému, pozrite sa na príklady s vysokým hodnotením používateľov — tieto sú dobrým zdrojom pre behavioral regression set. Kombinácia s rýchlym ručným prehliadnutím 20–30 odpovedí odhalí väčšinu problémov skôr, než sa dostanú k zákazníkovi.
Prečo val loss klesá, ale kvalita odpovedí sa nezlepšuje?
Klasický prípad overfittingu alebo distribučného nesúladu medzi tréningom a reálnym použitím. Validačná strata klesá, keď model lepšie fituuje na validačnú sadu — ale ak validačná sada nereflektuje reálne vstupy, táto strata je zlý proxy pre skutočnú kvalitu. Ďalšia príčina: príliš nízky learning rate alebo rank adaptéra, takže model sa naučil iba povrchné vzory. Skúste zvýšiť rank (napr. z 8 na 16 alebo 32) a overiť, či validačná sada je reprezentatívna. Súvisiaca téma: prečo fine-tuning zlyháva.
Kedy má zmysel opakovať fine-tuning namiesto RAG?
Fine-tuning opakujte, ak sa doména stabilizovala a máte konzistentný prísun nových označených príkladov z produkcie. Ak sa doménové znalosti menia rýchlo (nové produkty, zmenené regulácie), RAG je flexibilnejší — zmenu zapíšete do knowledge base, nie do váh modelu. Pre rozhodnutie o kombinácii oboch prístupov pozrite dataset na fine-tuning — koľko a akú kvalitu.
*Ak uvažujete o fine-tuningu vlastného modelu a nie ste si istí, ako nastaviť eval proces, radi sa pozrieme na váš konkrétny use case. V MP Industrial Solutions pomáhame firmám navrhnúť celý pipeline od dát cez tréning až po evalváciu — tak, aby ste pred nasadením do produkcie vedeli, čo model skutočne zvláda.*