Gdy firma po raz pierwszy podchodzi do fine-tuningu własnego modelu językowego, skupia się zazwyczaj na stronie technicznej: jaki model, jaki framework, jakie GPU. Dataset rozwiązuje się później — i właśnie tam najczęściej powstają problemy. Widzieliśmy projekty, w których w trenowanie zainwestowano kilka dni czasu GPU, a wynikowy model trafił do szuflady. Nie dlatego, że metoda była zła, lecz dlatego, że dane nie zostały przygotowane z należytą starannością.
Ten artykuł poświęcony jest konkretnie przygotowaniu datasetu: ile przykładów naprawdę potrzebujecie, jak mierzyć jakość, co robić z duplikatami, jak ustawić podział na zbiór treningowy i ewaluacyjny oraz dlaczego istnieje coś takiego jak brama wystarczalności danych (data-sufficiency gate) — zanim w ogóle uruchomicie trening.
Dlaczego dataset jest ważniejszy niż metoda
Fine-tuning jest w swojej istocie prosty: pokazujecie modelowi, jak ma odpowiadać w konkretnym kontekście, wystarczająco wiele razy, żeby to zapamiętał. Problem pojawia się, gdy to, co mu pokazujecie, nie jest tym, czego naprawdę chcecie — albo gdy pokazujecie to zbyt mało razy, albo zbyt wiele razy to samo.
Badania nad trenowaniem modeli językowych wielokrotnie potwierdzają, że jakość ma większą wagę niż ilość. Zestaw 1 000 starannie przygotowanych, zróżnicowanych i poprawnych przykładów może dać lepszy model niż 50 000 przykładów stworzonych naprędce z systemowymi błędami. To nie jest intuicyjne — większość zespołów technicznych instynktownie sięga po większy wolumen.
Gorsze niż niewystarczające dane jest jednak niska jakość przy dostatecznym wolumenie. Model wytrenowany na błędnych, stronniczych lub sprzecznych przykładach utrwali je sobie jako prawdę. A ponieważ fine-tuning zwiększa pewność modelu w wyuczonych wzorcach, efektem jest model, który pewnie odpowiada na pytania, przy których powinien zawahać się lub powiedzieć „nie wiem". W dziedzinach takich jak prawo, medycyna czy doradztwo finansowe to poważny problem.
Rzędy wielkości minimów: SFT, DPO i GRPO
Nie każdy fine-tuning jest taki sam. Trzy główne podejścia mają różne wymagania co do danych:
SFT (Supervised Fine-Tuning) to metoda podstawowa: model otrzymuje pary wejście–wyjście i uczy się je naśladować. Funkcjonalne wyniki są osiągalne od mniej więcej 1 000 wysokojakościowych przykładów, ale dla systemów produkcyjnych typowo pracuje się z 10 000–100 000 parami. Ważne, żeby pokrywały główne scenariusze danej domeny — nie tylko te najczęstsze.
DPO (Direct Preference Optimization) wymaga par preferencyjnych: do każdego wejścia macie odpowiedź „lepszą" i „gorszą". Model uczy się, czemu dajecie pierwszeństwo. Wymaga to albo adnotacji przez prawdziwych ludzi, albo wiarygodnej automatycznej oceny. Zalecane minimum to ok. 2 000 par preferencyjnych z ludzko zweryfikowanymi wynikami. Poniżej tej granicy istnieje ryzyko, że model nauczy się artefaktów procesu adnotacji zamiast rzeczywistych preferencji.
GRPO i weryfikowalne nagrody sprawdzają się przy zadaniach z weryfikowalnymi poprawnymi odpowiedziami — matematyka, kod, logika, formaty o zdefiniowanym schemacie. Tutaj minimum to ok. 1 000 ocenionych trajektorii, ale kluczowym warunkiem wstępnym jest to, że nagroda jest naprawdę obiektywna i automatycznie weryfikowalna. Jeśli nagrodę definiujecie ręcznie i subiektywnie, traficie na te same problemy co przy złym datasecie DPO.
Te liczby to minima dla podstawowej funkcjonalności, nie gwarancje jakości. Dla wdrożeń produkcyjnych w regulowanych branżach (prawo, medycyna, farmacja) obowiązuje surowszy standard: pełne pokrycie wszystkich docelowych scenariuszy i jurysdykcji — nie tylko reprezentatywna próbka.
Co oznacza jakościowy przykład
Zanim omówimy wolumen, trzeba zdefiniować, czego oczekujecie od pojedynczego przykładu.
Dobry przykład SFT ma następujące właściwości:
- Poprawność: wyjście jest merytorycznie poprawne i odpowiada kontekstowi wejścia
- Spójność: to samo wejście (lub równoważna jego formulacja) otrzymuje tę samą kategorię odpowiedzi
- Reprezentatywność: przykład pokrywa rzeczywisty scenariusz, nie tylko sztuczny przypadek testowy
- Klarowność: model z przykładu jednoznacznie rozumie, czego się od niego oczekuje — bez niejednoznaczności
- Właściwa długość: nie zbyt krótkie (puste wzorce) ani zbyt długie (model traci wątek)
Typowe problemy, które widzimy w praktyce:
- Wyjścia skopiowane z istniejących dokumentów bez edycji — zawierają błędy z oryginalnego źródła
- Przykłady generowane przez LLM bez ludzkiej kontroli — model uczy się halucynacji innego modelu
- Niespójne formatowanie — raz JSON, raz Markdown, raz wolny tekst dla tego samego typu zadania
- Nakładające się wejścia z różnymi wyjściami — model otrzymuje sprzeczne sygnały
Format datasetu i struktura pliku
Większość nowoczesnych frameworków (Unsloth, Axolotl, LLaMA-Factory, TRL) akceptuje standardowe formaty. Najczęściej używane to:
Format Alpaca dla zadań instruktażowych: każdy przykład ma pola instruction, input (opcjonalne) i output. Prosty, dobrze obsługiwany.
Format ShareGPT / konwersacyjny dla modeli chatowych: przykłady to konwersacje z listą wiadomości, z których każda ma rolę (system, user, assistant). Lepiej nadaje się do scenariuszy wieloturowych.
JSONL (jeden obiekt JSON na linię) to preferowany format pliku dla większości narzędzi — umożliwia strumieniowe wczytywanie dużych datasetów bez ładowania całego pliku do pamięci.
Przy przygotowaniu datasetu DPO dochodzi jedno pole: typowo chosen i rejected (lub równoważne nazwy według frameworka) dla każdego promptu wejściowego.
Deduplikacja — niedoceniany krok
Zduplikowane lub prawie identyczne przykłady to jeden z najczęstszych problemów w datasetach zestawianych automatycznie lub z firmowej dokumentacji. Efekt jest podwójny: model nieproporcjonalnie uczy się wzorców zawartych w duplikatach (overfitting na podzbiór danych), a ewaluacja ulega przekłamaniu, jeśli duplikaty trafią zarówno do zbioru treningowego, jak i testowego.
Podstawowa deduplikacja opiera się na dokładnym dopasowaniu (hash tekstu wejściowego). Bardziej zaawansowane podejścia używają MinHash lub podobieństwa embeddingów do wykrywania semantycznych duplikatów — czyli przykładów, które są sformułowane różnie, ale treściowo identyczne.
Dla domenowych datasetów zalecamy co najmniej następujące kroki:
- 1.Dokładna deduplikacja na podstawie hasha wyjścia
- 2.Sprawdzenie, czy różne sformułowania tego samego wejścia prowadzą do spójnych wyjść
- 3.Usunięcie przykładów, gdzie wejście i wyjście są krótsze niż sensowna dolna granica (np. zbyt krótkie odpowiedzi)
Narzędzia takie jak biblioteka datasets z Hugging Face lub datasketch (implementacja MinHash) obsługują te kroki bez potrzeby pisania własnego kodu.
Podział train/eval: liczby i logika
Podział datasetu na zbiór treningowy i ewaluacyjny to podstawa, jednak w praktyce popełnia się tu zbędne błędy.
Standardowy podział 80 % trening / 20 % ewaluacja działa, ale dla małych datasetów (poniżej ok. 5 000 przykładów) lepiej stosować 90/10 i uzupełniać zbiór ewaluacyjny wielokrotną walidacją krzyżową lub osobnym hold-out zestawem testowym.
Zasada nadrzędna: żaden przykład ze zbioru ewaluacyjnego nie może znajdować się w zbiorze treningowym — ani jego semantyczny duplikat. Jeśli robicie deduplikację, róbcie ją przed podziałem, nie po nim.
Dla domenowych datasetów fine-tuningu zalecamy, by zbiór ewaluacyjny zawierał: - Reprezentatywną próbkę głównych scenariuszy (taki sam rozkład jak trening) - Kilka celowych przypadków brzegowych i granicznych - Przykłady, w których prawidłowa odpowiedź to „nie wiem" lub „niewystarczające informacje" — jeśli tego oczekujecie od modelu
Zbiór ewaluacyjny służy dwóm celom: pomiarowi wydajności podczas treningu (validation loss) i niezależnej ocenie po treningu. Dla decyzji produkcyjnych ważniejsza jest ta druga funkcja — dlatego zbiór ewaluacyjny powinien być ludzko zweryfikowany, a nie generowany automatycznie.
Powiązany artykuł o tym, jak mierzyć wyniki po treningu: Jak zmierzyć, czy fine-tuning pomógł.
Dane syntetyczne: korzyści i ryzyka
W przypadku większości projektów domenowych wolumen istniejących danych stworzonych przez ludzi jest niewystarczający. Rozwiązaniem jest rozszerzenie datasetu za pomocą danych syntetycznych — czyli danych generowanych przez silniejszy (frontier) model na podstawie ludzkich przykładów seed.
Typowy przepis: 150–200 przykładów napisanych i zweryfikowanych przez ludzi → generowanie 10–100-krotności przez model nauczyciela (Claude Opus, GPT-4o lub podobny model frontier) → ludzka rewizja próbki (co najmniej 10–20 %) → filtrowanie według jakości.
Ryzyka danych syntetycznych:
- Model collapse: jeśli dataset treningowy składa się wyłącznie z danych syntetycznie generowanych przez jednego modelu nauczyciela, wyfine-tunowany model kopiuje jego słabości i „quirks". Długi ogon rzeczywistych scenariuszy pozostaje niepokryty.
- Halucynacje modelu nauczyciela: model nauczyciela nie jest nieomylny — generuje błędy merytoryczne, które bez ludzkiej kontroli trafiają do treningu.
- Stylowe przekłamanie: silny model nauczyciela ma wyraźny styl odpowiedzi. Jeśli nie jest to pożądany styl dla waszego use case'u, trzeba to explicite korygować zarówno w prompcie, jak i przy kontroli.
Praca z danymi syntetycznymi wymaga więcej dyscypliny w kontroli jakości, nie mniej. Więcej na ten temat: Dane syntetyczne do fine-tuningu.
Data-sufficiency gate: nie uruchamiajcie treningu, zanim dane nie są gotowe
Jednym z błędów, które widzimy wielokrotnie, jest uruchamianie treningu z datasetem, o którym z góry wiadomo, że jest niekompletny — z założeniem, że „uzupełnimy później". Problem w tym, że niekompletny fine-tuning może być aktywnie szkodliwy.
Model wytrenowany na datasecie pokrywającym tylko część domeny nauczy się odpowiadać z wysoką pewnością również na pytania z niepokrytej części. Nie ma mechanizmu rozpoznania, że czegoś „nie wie" — wie tylko to, czego się nauczył. Efekt jest gorszy niż model bazowy, który przynajmniej wie, że nie jest wyspecjalizowany w danej domenie.
Przed uruchomieniem treningu zalecamy weryfikację:
- 1.Pokrycie głównych scenariuszy: czy macie przykłady dla każdego kluczowego typu zadania, które model będzie wykonywał?
- 2.Minimalny wolumen: czy spełniacie rzędy wielkości minimów dla wybranej metody (SFT, DPO, GRPO)?
- 3.Jakościowy zbiór ewaluacyjny: czy macie ludzko zweryfikowany zbiór ewaluacyjny, który jest oddzielony od danych treningowych?
- 4.Dla regulowanych branż: czy pokrywacie wszystkie docelowe jurysdykcje i scenariusze — nie tylko reprezentatywną próbkę?
Ta lista kontrolna to nie biurokracja — to zabezpieczenie przed tym, żeby inwestycja w trening nie skończyła się problematycznym modelem. Więcej o wyborze między metodami: SFT, DPO, GRPO — która metoda kiedy.
Catastrophic forgetting: co fine-tuning może zepsuć
Fine-tuning na wąskim datasecie ma efekt uboczny: model może częściowo zapomnieć umiejętności, które miał przed treningiem. To zjawisko — nazywane catastrophic forgetting (katastrofalne zapominanie) — jest potwierdzone badaniami i realne w praktyce.
LoRA i QLoRA łagodzą ten problem, ponieważ oryginalne wagi modelu pozostają zamrożone, a adaptery są stosunkowo małe. Jednak nawet metody PEFT nie eliminują go całkowicie — przy zbyt agresywnym treningu (wysoki learning rate, duży dataset o wąskiej dystrybucji) degradacja ogólnych zdolności jest widoczna.
Praktyczne konsekwencje:
- Testujcie nie tylko na domenowym zbiorze ewaluacyjnym, ale też na ogólnych benchmarkach (przynajmniej informacyjnie)
- Jeśli model po fine-tuningu zawodzi na zadaniach, na których wcześniej działał, to sygnał do korekty dystrybucji treningowej lub parametrów
- Dla wdrożeń produkcyjnych zawsze porównujcie model fine-tuned z modelem bazowym na tym samym zestawie zadań — nie tylko domenowym
Lista kontrolna przed pierwszym treningiem
Zanim uruchomicie trening, przejdźcie przez tę listę:
- 1.Dataset jest w standardowym formacie (Alpaca lub ShareGPT JSONL)
- 2.Dokładna deduplikacja przebiegła na całym datasecie
- 3.Podział train/eval jest gotowy przed jakimkolwiek innym przetwarzaniem
- 4.Zbiór ewaluacyjny nie zawiera semantycznych duplikatów ze zbioru treningowego
- 5.Co najmniej 10 % datasetu przeszło ludzką kontrolę jakości
- 6.Pokrycie scenariuszy jest zweryfikowane — żadne kluczowe kategorie nie są puste
- 7.Syntetycznie generowane dane są oznaczone, a ich udział w datasecie jest świadomie dobrany
- 8.Dla DPO: każda para preferencyjna ma zdefiniowany powód, dlaczego „chosen" jest lepsze od „rejected"
Ta lista nie jest wyczerpująca, ale obejmuje najczęstsze źródła problemów, które widzimy u klientów przystępujących do pierwszego fine-tuningu.
Najczęstsze pytania
Ile przykładów minimum potrzebuję do SFT?
Funkcjonalne wyniki są osiągalne od ok. 1 000 wysokojakościowych przykładów — liczba ta wynika z badań, które pokazały, że starannie wybrane przykłady mogą przewyższyć dataset rzędy wielkości większy, ale mniej jakościowy. Dla systemów produkcyjnych zalecamy co najmniej 10 000 przykładów z weryfikacją pokrycia kluczowych scenariuszy. Dla regulowanych branż obowiązują surowsze kryteria.
Czy mogę wygenerować cały dataset za pomocą LLM?
Syntetycznie generowany dataset może stanowić większość wolumenu, ale nie cały dataset. Potrzebujecie przykładów seed napisanych i zweryfikowanych przez ludzi (typowo 150–200 jako minimum) oraz ludzkiej rewizji próbki syntetycznie generowanych przykładów. Model trenowany wyłącznie na wyjściu jednego LLM nauczyciela kopiuje jego błędy i słabości bez korekty.
Jak podzielić dataset na zbiór treningowy i testowy?
Standardowy podział to 80 % trening / 20 % ewaluacja; dla małych datasetów poniżej 5 000 przykładów raczej 90/10. Kluczowa zasada: deduplikację róbcie przed podziałem, nie po nim. Zbiór ewaluacyjny nie może zawierać nawet semantycznych duplikatów ze zbioru treningowego — inaczej mierzycie „zdolność do zapamiętywania", a nie „zdolność do generalizacji".
Co jeśli mam mało danych domenowych i nie mogę ich uzupełnić syntetycznie?
W takim przypadku rozważcie RAG zamiast fine-tuningu — RAG (Retrieval-Augmented Generation) nie wymaga danych treningowych i sprawdza się dobrze w scenariuszach, gdzie potrzebujecie dostępu do wiedzy, a nie zmiany stylu lub formatu odpowiedzi. Fine-tuning jest właściwszym wyborem, gdy zmieniacie zachowanie modelu, a nie jego wiedzę.
Dlaczego model po fine-tuningu odpowiada gorzej niż przed nim?
Najczęstsze przyczyny: zła jakość datasetu (błędy w przykładach, niespójny format), niewystarczające pokrycie scenariuszy (model „nauczył się" tylko części domeny, a na resztę ekstrapoluje błędnie), albo catastrophic forgetting przy zbyt agresywnym treningu. Szczegółowe omówienie: 7 powodów, dla których fine-tuning zawodzi.
*Przygotowanie datasetu to miejsce, w którym rozstrzyga się powodzenie całego fine-tuningu — nie dopiero przy wyborze metody czy GPU. Jeśli planujecie pierwszy fine-tuning lub jesteście niezadowoleni z wyników poprzedniej próby, w MP Industrial Solutions chętnie pomożemy ocenić jakość i strukturę danych zanim uruchomicie trening.*