Fine-tuning je jedným z najviac skloňovaných pojmov v každom AI roadmap dokumente. „Natrénujeme vlastný model, ktorý bude rozumieť našej doméne." V teórii elegantné. V praxi sme videli, ako sa rovnaký projekt rozpadol na siedmich rôznych miestach — a každý krát z iného dôvodu. Tento článok nie je o tom, ako fine-tuning urobiť — je o tom, prečo väčšina pokusov nedosiahne produkciu, a ako sa týmto pasciam vyhnúť skôr, než minú čas a rozpočet.
Ak ešte len zvažujete, či vôbec siahnuť po fine-tuningu alebo skôr po RAG, prečítajte si najprv RAG vs fine-tuning — rozhodovanie. Príčiny zlyhania, ktoré opisujeme nižšie, totiž začínajú práve tam.
---
1. Málo dát — alebo dáta nízkej kvality
Toto je najčastejší dôvod zlyhania. Tím zozbiera čo má k dispozícii — pár stoviek interných dokumentov, export z CRM, zopár exportovaných e-mailov — a spustí tréning. Výsledok je model, ktorý s vysokou istotou odpovedá zle: horšie ako základný model, ktorý aspoň vie povedať „neviem".
Výskum ukázal (LIMA a ďalšie práce), že relatívne malý počet vysoko kvalitných príkladov — rádovo tisíc — dokáže produkovať lepší model ako desiatky tisíc nekvalitných. Kvantita bez kvality je v tomto prípade aktívne škodlivá.
Praktická mierka:
- SFT (supervised fine-tuning): minimum ~1 000 kvalitných otázka–odpoveď alebo task-completion párov, s pokrytím hlavných tém vašej domény. Produkčné systémy sú typicky na 10 000–100 000 príkladoch.
- DPO (preference tuning): ~2 000 preferenčných párov s winner/loser, overených človekom.
- GRPO (RL-based tuning): ~1 000 scorovaných trajektórií s overiteľnými odmenami.
Okrem počtu záleží na pokrytí — ak vaša KB (knowledge base) nemá dostatok príkladov z konkrétnej poddomény, model bude v tejto oblasti halucinátor. Pred spustením tréningu preto odporúčame urobiť topic coverage audit: vypíšte hlavné kategórie otázok, ktoré bude model riešiť, a skontrolujte, či máte dostatočnú vzorku v každej z nich.
---
2. Overfitting — model vie len to, čo videl
Keď je dataset príliš malý alebo príliš úzky a model sa na ňom trénuje príliš dlho, nastáva overfitting. Model exceluje na tréningových príkladoch, ale pri akejkoľvek odchýlke — mierne inak formulovaná otázka, iný kontext, nezvyklý vstup — úplne zlyháva alebo halucinuje.
Znaky overfittingu v praxi:
- Model doslova cituje tréningové vzorky namiesto toho, aby generalizoval.
- Na tréningových dátach vysoké skóre, na nových príkladoch výrazne nižšie.
- Model odmieta odpovedať na otázky mimo distribúcie tréningových dát namiesto toho, aby priznal neistotu.
Technické opatrenia: monitorujte validation loss počas trénovania a zastavte keď začne stúpať (early stopping). Sledujte eval metriky na hold-out sete, nie iba na tréningových dátach. Pre malé datasety je regularizácia a nižšie rank pri LoRA adaptéroch (napr. rank=8 namiesto rank=64) vhodnejšie nastavenie.
---
3. Catastrophic forgetting — model zabudne, čo vedel
Fine-tuning na úzkych doménových dátach môže degradovať generálne schopnosti modelu — schopnosť rozoberať, sumarizovať, uvažovať v angličtine alebo v iných jazykoch, základnú logiku. Tento jav sa nazýva catastrophic forgetting (katastrofické zabudnutie) a je dobre zdokumentovaný.
V praxi to vyzerá takto: fine-tuningom na interných technických dokumentoch dosiahnete, že model výborne odpovedá na otázky z vašej oblasti — ale prestane fungovať pri generálnych úlohách, ktoré predtým zvládal bez problémov. Zákazníci, ktorí tento jav nepoznajú, ho interpretujú ako „model sa pokazil".
Čo zmierňuje, ale neodstraňuje problém:
- LoRA / QLoRA — adaptéry menia len malý počet parametrov, pôvodné váhy zostávajú zamrznuté. Toto je najúčinnejší praktický spôsob ako obmedziť forgetting.
- Merging — fine-tuned model sa zmerguje so základným modelom pomocou nástrojov ako
mergekit(SLERP, TIES). Výsledok balansuje doménovú znalosť a generálne schopnosti. - Diverzifikácia datasetu — zahrnutie general-purpose príkladov do tréningového datasetu spolu s doménovými.
Pre regulované odvetvia (lekárstvo, právo, farmácia) je forgetting obzvlášť kritický — model, ktorý zabudol logiku a bezpečnostné vzory, môže produkovať obsahovo pôsobiace, ale fakticky nesprávne výstupy.
---
4. Zlá voľba metódy — full fine-tuning tam, kde stačí LoRA, alebo naopak
Tímy, ktoré začínajú s fine-tuningom, majú tendenciu ísť buď do extrému (plné fine-tuning, ktoré si vyžaduje obrovské GPU zdroje), alebo naopak zvoliť najúspornejšiu variantu bez premýšľania o trade-offoch.
Orientačný prehľad VRAM nárokov pre 7B model:
- Plné fine-tuning (BF16): ~70–120 GB — vyžaduje multi-GPU server
- LoRA (16-bit): ~15 GB — A100 alebo jedna RTX 4090 (24 GB VRAM)
- QLoRA (4-bit): ~5 GB — zmestí sa na RTX 3090 s 24 GB VRAM
LoRA dosahuje typicky ~90–95 % kvality plného fine-tuningu pri 10–20× nižšej pamäťovej náročnosti. Pre väčšinu doménových use-casov je toto dostatočné — siahnuť po plnom fine-tuningu bez jasného zdôvodnenia je plytvanie zdrojmi.
Na druhej strane existujú prípady, kde LoRA nestačí: keď sa mení tokenizér, keď ide o jazyky s veľmi odlišnou morfológiou od tréningových dát, alebo pri hlbokom „continued pretraining" (budovaní doménovej znalosti z neoznačených textov). Výber metódy by mal vychádzať z konkrétneho cieľa, nie z toho, čo sa náhodou spustilo prvé. Podrobnejší prehľad nájdete v článku LoRA vs QLoRA vs full fine-tuning.
---
5. Fine-tuning namiesto RAG — nesprávny nástroj pre nesprávnu úlohu
Toto je možno najdrahší omyl, s ktorým sa stretávame. Tím chce, aby model „vedel" o ich produktoch, dokumentoch, interných procesoch. Fine-tuning sa javí ako prirodzená odpoveď. Spustia ho, dáta nalejú do tréningu, a o niekoľko týždňov zistia, že model stále halucinuje fakty — pretože fine-tuning nespoľahlivo pridáva fakty do modelu.
Fine-tuning je vhodný nástroj pre:
- Zmenu formátu a štýlu odpovedí (napr. vždy vrátiť JSON s konkrétnou schémou).
- Zmenu správania (napr. model má vždy odmietnuť určité typy požiadaviek, alebo má dodržiavať konkrétny komunikačný tón).
- Prispôsobenie špecializovanej domény, kde base model nemá dostatok tréningových dát (napr. úzky priemyselný žargón, proprietárne formáty).
RAG (Retrieval-Augmented Generation — vyhľadávaním obohatená generácia) je správny nástroj pre:
- Prístup k aktuálnym alebo meniacim sa informáciám.
- Zodpovedanie otázok na základe konkrétnych dokumentov.
- Sledovateľnosť odpovede k zdroju (citácia, grounding).
V praxi: ak váš cieľ je „model má vedieť odpovedať na otázky z nášho katalógu produktov" — to je RAG use-case, nie fine-tuning. Fine-tuning by ste nasadili, ak chcete, aby model používal váš špecifický formát odpovede alebo terminológiu z odvetvia.
---
6. Žiadny eval — nevieme, či sme niečo vyhrali alebo prehrali
Prekvapivo bežný scenár: tím fine-tuning spustí, model sa natrénuje, pôsobí „lepšie" na pár manuálne testovaných príkladoch, a ide do produkcie. O mesiac neskôr prídu sťažnosti na regresiu — model prestáva fungovať na prípadoch, ktoré predtým riešil bez problémov.
Bez systematickej evalvácie (hodnotenia kvality modelu) nevieme:
- 1.Či fine-tuning vôbec pomohol — porovnanie s base modelom.
- 2.Či sme nespôsobili regresiu — výkonnosť na predtým funkčných prípadoch.
- 3.Kde presne model zlyháva — v akých kategóriách otázok.
Minimálny eval framework pred nasadením do produkcie obsahuje:
- Hold-out test set — ~10–20 % dát, ktoré neboli v tréningovej ani validačnej sade. Meriate na nich po natrénovaní.
- Baseline porovnanie — rovnaké otázky na base modeli aj na fine-tuned verzi. Regression = ak fine-tuned model skóruje nižšie na prípadoch, kde base model fungoval.
- Task-specific metriky — nie iba perplexita (technická metrika strojového učenia), ale metriky relevantné pre váš use-case: presnosť extrakcií, správnosť formátu, quality rating od doménového experta.
Podrobnejšie o nastavení evalvácie: Ako zmerať, či fine-tuning pomohol.
---
7. Nereálne očakávania — fine-tuning nie je zázrak
Posledná, ale v mnohých ohľadoch najdôležitejšia príčina. Fine-tuning sa v interných prezentáciách často predáva ako riešenie, ktoré z generického LLM spraví experta na vašu oblasť. V praxi je to jemnejšie:
- Fine-tuned 4B–8B model môže prekonať generický 70B+ model na úzko definovanom tasku — ale iba ak je task skutočne úzko definovaný, dáta sú kvalitné a eval to potvrdzuje.
- Fine-tuning nezlepšuje reasoning — ak base model nevie riešiť určitý typ logických úloh, fine-tuning na doménových dátach to nezmení. Na reasoning sú vhodné metódy ako GRPO s verifikovateľnými odmenami. Viac v článku SFT, DPO, GRPO — ktorá metóda kedy.
- Fine-tuning nie je jednorazový projekt — dáta sa menia, model starne, regresie pribúdajú. Bez infraštruktúry na opakovateľné tréning-eval-deploy cykly sa projekt postupne rozpadá.
- Halucinácie ostávajú — fine-tuning ich môže znížiť v špecifickej doméne, ale neodstraňuje ich. Guardrails, RAG grounding a human-in-the-loop sú stále potrebné tam, kde na správnosti záleží.
Tímy, ktoré tieto limity poznajú pred začatím projektu, končia s použiteľnými modelmi. Tímy, ktoré sa dozvedia o limitoch po šiestich mesiacoch vývoja, zvyčajne projekt zastavia.
---
Súhrn: checklist pred spustením projektu
Pred tým, ako sa rozhodnete spustiť fine-tuning projekt, odporúčame si prejsť týchto sedem otázok:
- 1.Máte dostatočný dataset? — počet príkladov, pokrytie tém, overená kvalita.
- 2.Je fine-tuning správny nástroj? — alebo by RAG alebo prompt engineering stačilo?
- 3.Máte nastavený eval? — hold-out set, baseline, task-specific metriky.
- 4.Máte GPU infraštruktúru? — alebo realistický plán cloud trénovania s odhadom nákladov.
- 5.Ste pripravení na iteráciu? — jeden fine-tuning run nestačí, pipeline musí byť opakovateľný.
- 6.Máte doménového experta v slučke? — kto overí, že model odpovedá správne, nie iba plynulo.
- 7.Máte plán na forgetting a regresie? — monitoring, rollback, eval po každom novom trénovacím behu.
Ak niektorá z týchto otázok nemá jasnú odpoveď, projekt nie je pripravený na spustenie — iba na prípravu.
---
Časté otázky
Prečo môj fine-tuned model odpovedá horšie ako základný model?
Najčastejšia príčina je overfitting na malom alebo nekvalitnom datasete. Model sa naučí „vzory" z tréningových dát, ale generalizácia na nové vstupy zlyhá. Riešenie: zvýšiť kvalitu dát, použiť early stopping, znížiť rank LoRA adaptéra, alebo celý project prehodnotiť z pohľadu RAG vs fine-tuning.
Koľko príkladov naozaj potrebujem na fine-tuning?
Pre SFT je funkčný výsledok možný od ~1 000 vysoko kvalitných príkladov, ale produkčné systémy sú typicky na 10 000–100 000. Dôležitejšia ako kvantita je pokrytie — ak chýba dostatočná vzorka v kľúčových kategóriách, model bude v týchto oblastiach nespoľahlivý bez ohľadu na celkový počet príkladov.
Je fine-tuning vhodný na aktualizáciu znalostí modelu (nové produkty, ceny, záznamy)?
Nie. Fine-tuning nespoľahlivo ukladá fakty — model môže naznačovať informácie z tréningu, ale aj halucináciami ich zmiešava. Pre znalosti, ktoré sa menia alebo musia byť overiteľné, je správny nástroj RAG s aktuálnou databázou dokumentov.
Môže malý fine-tuned model prekonať veľký generický model?
Áno — za konkrétnych podmienok. Fine-tuned 4B–8B model môže na úzko definovanom tasku prekonať generický 70B+ model, ak je task dobre ohraničený, dataset kvalitný a eval to potvrdí. Na širokých, generálnych úlohách väčší model zvyčajne vyhráva.
Čo je catastrophic forgetting a ako mu predísť?
Catastrophic forgetting je jav, pri ktorom fine-tuning na úzkych dátach degraduje generálne schopnosti modelu — jazyky, logiku, uvažovanie. Najúčinnejšie opatrenie je LoRA alebo QLoRA, ktoré menia len malý počet parametrov a zachovávajú pôvodné váhy. Doplnkovo pomáha merging fine-tuned modelu so základným cez nástroj mergekit.
---
*MP Industrial Solutions pomáha firmám rozlíšiť, kedy fine-tuning skutočne dáva zmysel a kedy existuje jednoduchšia a lacnejšia cesta. Ak zvažujete doménovú adaptáciu LLM, radi posúdime váš use-case — od datasetu po infraštruktúru a eval.*