Keď firma prvýkrát pristúpi k fine-tuningu vlastného jazykového modelu, zväčša sa sústredí na technickú stránku: aký model, aký framework, aká GPU. Dataset sa rieši neskôr — a práve tam najčastejšie vzniká problém. Videli sme projekty, kde sa do trénovania nainvestovalo niekoľko dní GPU času, aby výsledný model skončil v šuplíku. Nie preto, že metóda bola zlá, ale preto, že dáta neboli pripravené so zodpovedajúcou starostlivosťou.
Tento článok sa venuje konkrétne príprave datasetu: koľko príkladov reálne potrebujete, ako merať kvalitu, čo urobiť s duplicitami, ako nastaviť trénovací a evaluačný split a prečo existuje niečo ako dátová brána (data-sufficiency gate) predtým, než vôbec spustíte tréning.
Prečo je dataset dôležitejší ako metóda
Fine-tuning je v jadre jednoduchý: ukážte modelu, ako má odpovedať v konkrétnom kontexte, dostatočne veľa krát, aby si to zapamätal. Problém nastáva, keď to, čo mu ukazujete, nie je to, čo skutočne chcete — alebo keď to ukazujete príliš málo krát, alebo príliš veľa krát to isté.
Výskum v oblasti trénovania jazykových modelov opakovane ukázal, že kvalita má väčšiu váhu ako kvantita. Sada 1 000 starostlivo pripravených, rôznorodých a správnych príkladov dokáže produkovať lepší model ako 50 000 príkladov vytvorených narýchlo so systémovými chybami. To nie je intuitivné — väčšina technických tímov inštinktívne siahne po väčšom objeme.
Horšie ako nedostatočné dáta je ale zlá kvalita s dostatočným objemom. Model natrénovaný na chybných, skreslených alebo protirečivých príkladoch si ich zafixuje ako pravdu. A keďže fine-tuning zvyšuje konfidencia modelu v naučených vzoroch, výsledok je model, ktorý odpovedá sebavedomo na otázky, kde by mal zaváhať alebo povedať "neviem". V doménach ako právo, medicína alebo finančné poradenstvo je to závažný problém.
Rádové minimá: SFT, DPO a GRPO
Nie každý fine-tuning je rovnaký. Tri hlavné prístupy majú rôzne požiadavky na dáta:
SFT (Supervised Fine-Tuning) je základná metóda: model dostáva páry vstup–výstup a učí sa ich napodobovať. Funkčné výsledky sú dosiahnuteľné od zhruba 1 000 vysokokvalitných príkladov, ale na produkčné systémy sa typicky pracuje s 10 000 až 100 000 pármi. Dôležité je, aby pokrývali hlavné scenáre danej domény — nie len tie najčastejšie.
DPO (Direct Preference Optimization) vyžaduje preferenčné páry: ku každému vstupu máte "lepšiu" a "horšiu" odpoveď. Model sa učí, čomu dávate prednosť. Toto si vyžaduje buď anotáciu skutočnými ľuďmi, alebo spoľahlivé automatické hodnotenie. Odporúčané minimum sú zhruba 2 000 preferenčných párov s ľudsky overenými výsledkami. Pod touto hranicou je riziko, že model sa naučí artefakty anotačného procesu namiesto skutočných preferencií.
GRPO a verifikované odmeny sú vhodné pre úlohy s overiteľnými správnymi odpoveďami — matematika, kód, logika, formáty s definovanou schémou. Tu je minimum zhruba 1 000 hodnotených trajektórií, ale kľúčový predpoklad je, že odmena je skutočne objektívna a automaticky overiteľná. Ak odmenu definujete ručne a subjektívne, dostanete rovnaké problémy ako pri zlom DPO datasete.
Tieto čísla sú minimá pre základnú funkčnosť, nie záruky kvality. Pre produkčné nasadenie v regulovaných odvetviach (právo, medicína, farmácia) platí prísnejší štandard: kompletné pokrytie všetkých cieľových scenárov a jurisdikcií, nie len reprezentatívna vzorka.
Čo znamená kvalitný príklad
Predtým, než diskutujeme o objeme, treba si zadefinovať, čo vlastne chcete od jednotlivého príkladu.
Kvalitný SFT príklad má tieto vlastnosti:
- Správnosť: výstup je fakticky správny a zodpovedá kontextu vstupu
- Konzistencia: rovnaký vstup (alebo ekvivalentná formulácia) dostane rovnakú kategóriu odpovede
- Reprezentatívnosť: príklad pokrýva skutočný scenár, nie len umelý testovací prípad
- Jasnosť: model z príkladu jednoznačne pochopí, čo sa od neho čaká — bez ambiguity
- Primeraná dĺžka: nie zbytočne krátke (prázdne vzory) ani zbytočne dlhé (model sa stráca)
Typické problémy, ktoré vídame v praxi:
- Výstupy skopírované z existujúcich dokumentov bez editácie — obsahujú chyby z pôvodného zdroja
- Príklady generované LLM bez ľudskej kontroly — model sa učí halucinácie iného modelu
- Nekonzistentné formátovanie — raz JSON, raz Markdown, raz voľný text pre rovnaký typ úlohy
- Prekrývajúce sa vstupy s rozdielnymi výstupmi — model dostáva protirečivé signály
Formát datasetu a štruktúra súboru
Väčšina moderných frameworkov (Unsloth, Axolotl, LLaMA-Factory, TRL) akceptuje štandardné formáty. Najčastejšie používané sú:
Alpaca formát pre inštrukčné úlohy: každý príklad má polia instruction, input (voliteľné) a output. Jednoduchý, dobre podporovaný.
ShareGPT / konverzačný formát pre chat modely: príklady sú konverzácie so zoznamom správ, kde každá má rolu (system, user, assistant). Vhodnejší pre multi-turn scenáre.
JSONL (jeden JSON objekt na riadok) je preferovaný formát súboru pre väčšinu nástrojov — umožňuje streamované načítavanie veľkých datasetov bez načítania celého súboru do pamäte.
Pri príprave DPO datasetu pribúda jedno pole: typicky chosen a rejected (alebo ekvivalentné pomenovania podľa frameworku) pre každý vstupný prompt.
Deduplikácia — podceňovaný krok
Duplicitné alebo takmer duplicitné príklady sú jeden z najčastejších problémov v datasetoch zostavených automaticky alebo z firemnej dokumentácie. Efekt je dvojitý: model sa neúmerne naučí vzory obsiahnuté v duplikátoch (overfit na subset dát) a evaluácia sa skresľuje, ak sa duplicity dostanú do trénovacej aj testovacej sady.
Základné deduplikácie pracujú na exaktnej zhode (hash vstupného textu). Pokročilejšie prístupy používajú MinHash alebo embedding podobnosť pre detekciu sémantických duplikátov — teda príkladov, ktoré sú formulačne rôzne, ale obsahovo rovnaké.
Pre doménové datasety odporúčame aspoň tieto kroky:
- 1.Exaktná deduplikácia na základe hash výstupu
- 2.Kontrola, či rôzne formulácie toho istého vstupu vedú ku konzistentným výstupom
- 3.Odstránenie príkladov, kde vstup aj výstup sú kratšie ako zmysluplná spodná hranica (napr. príliš krátke odpovede)
Nástroje ako datasets knižnica z Hugging Face alebo datasketch (MinHash implementácia) pokrývajú tieto kroky bez nutnosti písania vlastného kódu.
Train/eval split: čísla a logika
Rozdelenie datasetu na trénovaciu a evaluačnú sadu je základ, no v praxi sa robia zbytočné chyby.
Štandardné rozdelenie 80 % tréning / 20 % evaluácia funguje, no pre malé datasety (pod ~5 000 príkladov) je vhodnejšie použiť 90/10 a evaluačnú sadu doplniť viacnásobnou krížovou validáciou alebo separátnym hold-out testovacím setom.
Zásadné pravidlo: žiadny príklad z evaluačnej sady nesmie byť v trénovacej sade — ani jeho sémantický duplikát. Ak robíte deduplikáciu, robte ju pred splitom, nie po ňom.
Pre doménové fine-tuning datasety odporúčame evaluačnú sadu zostaviť tak, aby obsahovala: - Reprezentatívnu vzorku hlavných scenárov (rovnaká distribúcia ako tréning) - Niekoľko zámerných edge cases a hraničných situácií - Príklady, kde správna odpoveď je "neviem" alebo "nedostatočné informácie" — ak to od modelu očakávate
Evaluačná sada slúži na dve veci: meranie výkonu počas trénovania (validation loss) a nezávislé hodnotenie po tréningu. Pre produkčné rozhodnutia je hodnotnejšia druhá funkcia — preto by mala byť evaluačná sada ľudsky overená a nie generovaná automaticky.
Súvisiaci článok o tom, ako merať výsledky po tréningu: Ako zmerať, či fine-tuning pomohol.
Syntetické dáta: prínosy a riziká
Pre väčšinu doménových projektov nestačí objem existujúcich ľudsky vytvorených dát. Riešením je rozšírenie datasetu pomocou syntetických dát — teda dát generovaných silnejším (frontier) modelom na základe ľudských seed príkladov.
Typický recept: 150–200 ľudsky napísaných, overených seed príkladov → generovanie 10 až 100-násobku cez teacher model (Claude Opus, GPT-4o alebo podobný frontier model) → ľudská revízia vzorky (aspoň 10–20 %) → filtrovanie podľa kvality.
Riziká syntetických dát:
- Model collapse: ak trénovací dataset pozostáva výhradne zo synteticky generovaných dát od jedného teacher modelu, fine-tuned model kopíruje jeho slabiny a "quirks". Dlhý chvost reálnych scenárov zostáva nepokrytý.
- Halucinácie teacher modelu: teacher model nie je neomylný — generuje faktické chyby, ktoré sa bez ľudskej kontroly dostanú do trénovania.
- Štýlové skreslenie: silný teacher model má výrazný štýl odpovede. Ak to nie je žiaduci štýl pre váš use case, treba to explicitne korigovať v promptu aj pri kontrole.
Práca so syntetickými dátami si vyžaduje viac discipline v kontrole kvality, nie menej. Viac o tejto téme: Syntetické dáta na fine-tuning.
Data-sufficiency gate: nespúšťajte tréning skôr, ako sú dáta pripravené
Jednou z chýb, ktorú vídame opakovane, je spúšťanie trénovania s datasettom, o ktorom vopred viete, že je neúplný — s tým, že "doplníme neskôr". Problém je, že neúplný fine-tuning môže byť aktívne škodlivý.
Model natrénovaný na datasete, ktorý pokrýva len časť domény, sa naučí odpovedať s vysokou istotou aj na otázky z nepokrytej časti. Nemá mechanizmus na rozpoznanie, že niečo "nevie" — vie len, čo naučil. Výsledok je horší ako base model, ktorý aspoň vie, že na doménu nie je špecializovaný.
Pred spustením trénovania odporúčame overiť:
- 1.Pokrytie hlavných scenárov: máte príklady pre každý kľúčový typ úlohy, ktorú model bude vykonávať?
- 2.Minimálny objem: spĺňate rádové minimá pre zvolenú metódu (SFT, DPO, GRPO)?
- 3.Kvalitná evaluačná sada: máte ľudsky overenú evaluačnú sadu, ktorá je oddelená od trénovacích dát?
- 4.Pre regulované odvetvia: pokrývate všetky cieľové jurisdikcie a scenáre — nie len reprezentatívnu vzorku?
Tento kontrolný zoznam nie je byrokracia — je to poistka pred tým, aby investícia do trénovania neskončila problémovým modelom. Viac o rozhodovaní medzi metódami: SFT, DPO, GRPO — ktorá metóda kedy.
Catastrophic forgetting: čo fine-tuning môže pokaziť
Fine-tuning na úzkom datasete má vedľajší efekt: model môže čiastočne zabudnúť schopnosti, ktoré mal pred tréningom. Tento jav — nazývaný catastrophic forgetting (katastrofické zabudnutie) — je overený výskumom a reálny v praxi.
LoRA a QLoRA tento problém zmierňujú, pretože pôvodné váhy modelu zostávajú zmrazené a adaptéry sú relatívne malé. Ale ani PEFT metódy ho úplne neodstraňujú — pri príliš agresívnom trénovaní (vysoký learning rate, veľký dataset s úzkou distribúciou) sa degradácia generálnych schopností prejaví.
Praktické dôsledky:
- Testujte nielen na doménovej evaluačnej sade, ale aj na všeobecných benchmarkoch (aspoň informatívne)
- Ak model po fine-tuningu zlyháva na úlohách, kde predtým fungoval, je to signál na úpravu trénovacej distribúcie alebo parametrov
- Pre produkčné nasadenie vždy porovnajte fine-tuned model s base modelom na rovnakom sete úloh — nie len na doménovom
Kontrolný zoznam pred prvým tréningom
Predtým, ako spustíte tréning, prejdite tento zoznam:
- 1.Dataset je v štandardnom formáte (Alpaca alebo ShareGPT JSONL)
- 2.Exaktná deduplikácia prebehla na celom datasete
- 3.Train/eval split je hotový pred akýmkoľvek iným spracovaním
- 4.Evaluačná sada neobsahuje sémantické duplicity z trénovacej sady
- 5.Aspoň 10 % datasetu prešlo ľudskou kontrolou kvality
- 6.Pokrytie scenárov je overené — žiadne kľúčové kategórie nie sú prázdne
- 7.Synteticky generované dáta sú označené a ich podiel v datasete je vedome volený
- 8.Pre DPO: každý preferenčný pár má definovaný dôvod, prečo je "chosen" lepší ako "rejected"
Tento zoznam nie je vyčerpávajúci, ale pokrýva najčastejšie zdroje problémov, ktoré vídame u klientov prichádzajúcich s prvým fine-tuningom.
Časté otázky
Koľko príkladov minimálne potrebujem na SFT?
Funkčné výsledky sú dosiahnuteľné od zhruba 1 000 vysokokvalitných príkladov — toto číslo vychádza z výskumu, ktorý ukázal, že starostlivo vybrané príklady môžu prekonať rádovo väčší, ale menej kvalitný dataset. Na produkčné systémy odporúčame aspoň 10 000 príkladov s overením pokrytia kľúčových scenárov. Pre regulované odvetvia platia prísnejšie kritériá.
Môžem dataset vygenerovať celý pomocou LLM?
Synteticky generovaný dataset môže tvoriť väčšinu objemu, ale nie celý dataset. Potrebujete ľudsky napísané a overené seed príklady (typicky 150–200 ako minimum) a ľudskú revíziu vzorky synteticky generovaných príkladov. Model trénovaný výhradne na výstupe jedného teacher LLM kopíruje jeho chyby a slabiny bez korekcie.
Ako rozdelím dataset na trénovaciu a testovaciu sadu?
Štandardné rozdelenie je 80 % tréning / 20 % evaluácia, pre malé datasety pod 5 000 príkladov skôr 90/10. Kľúčové pravidlo: deduplikáciu robte pred splitom, nie po ňom. Evaluačná sada nesmie obsahovať ani sémantické duplicity z trénovacej sady — inak meriate "schopnosť zapamätať si", nie "schopnosť generalizovať".
Čo ak mám málo doménových dát a nemôžem ich doplniť synteticky?
V takom prípade zvážte RAG namiesto fine-tuningu — RAG (Retrieval-Augmented Generation) nevyžaduje trénovacie dáta a funguje dobre pre scenáre, kde potrebujete prístup k znalostiam, nie zmenu štýlu alebo formátu odpovede. Fine-tuning je vhodnejší, keď meníte správanie modelu, nie jeho znalosti.
Prečo model po fine-tuningu odpovedá horšie ako pred ním?
Najčastejšie príčiny: zlá kvalita datasetu (chyby v príkladoch, nekonzistentný formát), nedostatočné pokrytie scenárov (model sa "naučil" len časť domény a na zvyšok extrapoluje nesprávne), alebo catastrophic forgetting pri príliš agresívnom trénovani. Podrobnejší pohľad: 7 dôvodov, prečo fine-tuning zlyhá.
*Príprava datasetu je miesto, kde sa rozhoduje o úspechu celého fine-tuningu — nie až pri voľbe metódy alebo GPU. Ak sa chystáte na prvý fine-tuning alebo ste s výsledkami predchádzajúceho pokusu nespokojní, radi vám pri MP Industrial Solutions pomôžeme posúdiť kvalitu a štruktúru dát ešte pred tým, ako spustíte tréning.*