Każdy zespół, który zaczyna z fine-tuningiem, napotyka tę samą ścianę: realne, dobrze zaannotowane przykłady są w cenie. Ręczne tworzenie nowych próbek jest drogie i powolne. Prawie nieuchronnie pada pytanie — a co, gdybyśmy dane wygenerowali modelem?
To legitymna technika. Stosują ją zarówno zespoły badawcze, jak i systemy produkcyjne. Ma jednak precyzyjne warunki, w których działa, oraz równie precyzyjne warunki, w których po cichu psuje model, który właśnie dostrajają Państwo. Ten artykuł rozkłada jedno i drugie — bez zbędnego optymizmu.
Czym właściwie są dane syntetyczne (i czym nie są)
Syntetyczne dane treningowe do fine-tuningu to przykłady wejście–wyjście generowane automatycznie, nie rejestrowane z rzeczywistego ludzkiego zachowania. W praktyce oznacza to jedną z trzech rzeczy:
- Generowanie przez model nauczyciela (teacher model) — silniejszy model (np. frontier API) otrzymuje instrukcję i generuje przykłady dla słabszego modelu docelowego. Bywa to nieprecyzyjnie nazywane destylacją, choć nie jest nią w pierwotnym sensie.
- Augmentacja istniejących danych — istniejące przykłady są parafrazowane, przeformatowane lub rozszerzane; zachowuje się treść semantyczną, zmienia się forma.
- Self-play i scenariusze syntetyczne — model generuje dane sam dla siebie (lub pełniąc jednocześnie rolę nauczyciela i ucznia), typowo dla reasoning lub konwersacyjnego fine-tuningu.
Ważne: dane syntetyczne nie zastępują continued pretraining na surowych tekstach domenowych. Continued pretraining buduje fundament wiedzy poprzez teksty bez etykiet. Dane syntetyczne dla SFT (supervised fine-tuning) uczą model formatu i zachowania, nie wiedzy. Te dwie warstwy uzupełniają się, ale nie zastępują wzajemnie.
Kiedy dane syntetyczne naprawdę pomagają
Nie każdy przypadek użycia dysponuje dostateczną ilością realnych danych. Oto sytuacje, w których dane syntetyczne wnoszą realną wartość:
1. Mają Państwo silny seed set, ale jest on mały. Badania pokazują, że model wytrenowany na tysiącu przykładów wysokiej jakości przewyższy model wytrenowany na stu tysiącach przykładów przeciętnych. Jeśli dysponują Państwo 150–200 realnymi, dobrze opracowanymi przykładami, można je rozszerzyć 10–50 razy przez model nauczyciela — zachowując pożądaną dystrybucję. Sprawdza się to dobrze przy zadaniach strukturalnych z weryfikowalnymi wynikami: ekstrakcja encji, klasyfikacja, transformacja formatów.
2. Pokrywają Państwo długi ogon. Realne dane mają pewną dystrybucję — niektóre przypadki są częste, inne rzadkie. Model wytrenowany wyłącznie na realnych danych może słabo radzić sobie z przypadkami brzegowymi, które w historii pojawiały się zbyt rzadko. Model nauczyciela potrafi celowo pokryć te edge case'y.
3. Chcą Państwo przenieść reasoning z większego modelu. To zasadniczy princip podejścia destylacyjnego, który spopularyzował DeepSeek — łańcuch rozumowania (chain-of-thought) z modelu frontier jest używany jako sygnał treningowy dla mniejszego modelu. Mniejszy model nie nauczy się „wiedzieć" tego samego, ale nauczy się *rozumować* podobnie. Wyniki są udokumentowane: modele o rozmiarze 7B–8B wytrenowane na syntetycznym zbiorze danych chain-of-thought mogą na wąskich zadaniach reasoning przewyższać wielokrotnie większy model generalistyczny.
4. Potrzebują Państwo augmentacji danych dla bezpieczeństwa w przypadkach brzegowych. Red-teaming i generowanie przykładów adversarialnych — gdzie chcą Państwo pokazać modelowi, czego *nie powinien* robić — to kolejny uzasadniony przypadek użycia syntetyki. Realne przykłady awarii są rzadkie; syntetyczny nauczyciel potrafi je generować systematycznie.
Zob. też: Dataset do fine-tuningu — ile i jakiej jakości — ilościowe rekomendacje dotyczące wielkości zbioru danych.
Główne ryzyka: kiedy zatrują model
Dane syntetyczne niosą trzy kategorie ryzyk, z których każde może po cichu degradować model.
Ryzyko 1: Propagacja błędów nauczyciela
Model nauczyciela nie jest nieomylny. Ma własne wzorce halucynacji, martwe pola, preferencje formułowania. Gdy wygeneruje tysiąc przykładów i wytrenują Państwo na nich model docelowy, model docelowy nie nauczy się tylko pożądanej dystrybucji — nauczy się też quirks nauczyciela. W małej dawce jest to tolerowalne. Przy dużych syntetycznych zbiorach danych bez filtrowania produkuje model, który pewnie powtarza błędy, których Państwo sami nie potrafią zidentyfikować (bo są to błędy modelu, nie człowieka).
Przykład z praktyki: klient z obszaru dokumentacji technicznej miał model nauczyciela, który konsekwentnie używał starej nazwy handlowej dla pewnego rodzaju komponentu elektrycznego. Tysiąc wygenerowanych przykładów później model docelowy był subtelnie, lecz konsekwentnie biased w kierunku tej samej przestarzałej nomenklatury — mimo że w danych seed taki wzorzec nie występował.
Ryzyko 2: Model collapse
To technicznie najbardziej poważne ryzyko i aktywny obszar badań. Model collapse następuje, gdy model trenowany na danych syntetycznych z tego samego modelu (lub podobnych modeli) stopniowo traci zmienność i konwerguje do wąskiej dystrybucji wyjść. Wyjścia są płynne, formalnie poprawne — ale model przestał pokrywać zakres realnych wejść.
Intuicja: jeśli nauczyciel generuje dane, które są zdystrybucjonalizowaną odpowiedzią tego samego modelu (lub jego poprzednika), każda iteracja treningu wzmacnia centralne wzorce i osłabia brzegi. Po kilku cyklach model dobrze odpowiada na przeciętne wejścia i przestaje radzić sobie z niecodzienny formułowaniami, przypadkami brzegowymi czy danymi spoza dystrybucji treningowej.
W systemach produkcyjnych objawia się to tak: model „działa" na testach (testy pokrywają typowe przypadki), ale w produkcji klienci skarżą się, że czasem dostają generyczną lub bezsensowną odpowiedź — właśnie na pytaniach brzegowych.
Ochrona: nigdy nie trenować wyłącznie na syntetyce. Dane z ludzkiego seed setu muszą stanowić co najmniej ~20–30 % zbioru danych i muszą pokrywać różnorodność wejść — nie tylko przeciętne przypadki. Systematyczna ewaluacja na wejściach out-of-distribution przed wdrożeniem jest obowiązkowa.
Ryzyko 3: Ograniczenia licencyjne i ToS
To ryzyko jest mniej techniczne, ale dla zastosowań B2B kluczowe. Większość modeli frontier (Claude, GPT, Gemini) ma w warunkach świadczenia usług eksplicytne ograniczenia dotyczące generowania danych treningowych dla modeli konkurencyjnych. Konkretne sformułowania różnią się i ulegają zmianom — zawsze czytać aktualne ToS danego dostawcy.
W praktyce: jeśli używają Państwo komercyjnego API jako model nauczyciela i planują komeryjnie dystrybuować lub wdrażać model docelowy dla klientów, muszą Państwo mieć wyjaśnioną podstawę prawną. W przypadku wewnętrznego wdrożenia na własnej infrastrukturze sytuacja jest inna, ale nie automatycznie przejrzysta.
Bezpieczna ścieżka: modele open-weight (Qwen, Mistral i inne z licencją Apache 2.0 lub MIT) typowo dopuszczają generowanie danych syntetycznych — ale każdy model ma własne warunki, zawsze należy je weryfikować przed wdrożeniem. Jeśli zależy Państwu na komercyjnie czystym potoku syntetycznym bez prawnych znaków zapytania, zarówno model nauczyciela, jak i model ucznia powinny pochodzić z rodzin z permisywnymi licencjami.
Generowanie przez model nauczyciela — praktyczny przebieg
Zakładamy, że dysponują Państwo 100–200 wysokiej jakości przykładami seed i chcą je rozszerzyć.
1. Seed set jest fundamentem — nie można go skrócić. Te 150 przykładów musi pokrywać dystrybucję, którą Państwo chcą. Jeśli seed set pokrywa tylko jedną trzecią przestrzeni przypadków użycia, syntetycznie rozszerzony zbiór danych będzie pokrywał tę samą jedną trzecią — tylko większy.
2. Inżynieria promptów dla nauczyciela. Nauczyciel musi otrzymać eksplicytne instrukcje dotyczące formatu, stylu, domeny oraz tego, czemu chcą Państwo *zapobiec*. Nieokreślony prompt = nieokreślone dane. Dobry prompt dla nauczyciela zawiera: przykładowe pary wejście–wyjście z seed setu, wymagany format odpowiedzi, terminologię domenową, którą chcą Państwo preferować, oraz przykłady negatywne (czego unikać).
3. Generować więcej, niż potrzeba — i filtrować. Generować 3–5× więcej przykładów, niż planują Państwo użyć. Następnie filtrować: - Automatyczna kontrola formatu (poprawny JSON, poprawna struktura) - Deduplikacja oparta na embeddingach (zbyt podobne przykłady nic nie wnoszą) - Skoring relewantności — albo przez inny model jako sędzia (model-as-judge), albo przez automatyczne walidatory, jeśli mają Państwo weryfikowalne wyjścia - Próbkowa kontrola ludzka co najmniej 5–10 % wygenerowanych przykładów
4. Mieszać z realnymi danymi. Finalny zbiór danych powinien zawierać dane seed (100 %) + dane syntetyczne (10–50× więcej, po filtracji). Zachowywać identyfikator źródła w metadanych zbioru — docenią to Państwo przy debugowaniu.
5. Ewaluować na holdout secie złożonym z realnych danych. To jest krytyczne. Zestaw ewaluacyjny nie może zawierać syntetycznych przykładów. Jeśli model nie jest oceniany na podstawie prawdziwej ludzkiej oceny, nigdy nie wiadomo, czy syntetyka nie wprowadziła driftu.
Więcej o ewaluacji: Jak zmierzyć, czy fine-tuning pomógł.
Dane syntetyczne vs destylacja modelu — ważna różnica
Te pojęcia są w praktyce mieszane, ale nie są tożsame.
Destylacja modelu w pierwotnym sensie to trenowanie mniejszego modelu tak, by naśladował dystrybucję wyjść większego. Obejmuje porównywanie dystrybucji przez dywergencję KL, dostęp do logitów nauczyciela i całe spektrum technik knowledge distillation z literatury naukowej.
Generowanie danych syntetycznych przez model nauczyciela to bardziej pragmatyczne podejście: model nauczyciela generuje tekstowe przykłady wejście–wyjście, a te są używane jako zwykły zbiór danych SFT. Nie używa się logitów nauczyciela, nie oblicza się podobieństw dystrybucji — tylko generuje się przykłady. Wyniki są gorsze niż pełna destylacja, ale wykonalne bez dostępu do wnętrza modelu i bez specjalistycznych frameworków.
W praktyce większość „destylacji" w projektach komercyjnych odbywa się właśnie przez drugie podejście — bo dostęp do logitów modelu frontier nie jest dostępny przez standardowe API. Wyniki są mimo to udokumentowane: zob. destylowane modele DeepSeek-R1, które przeniosły zdolności reasoning do modeli 1.5B–8B przez syntetyczne dane chain-of-thought.
Głębsze spojrzenie na samą destylację jako technikę: Destylacja modelu.
Augmentacja vs generowanie — kiedy które
Augmentacja istniejących przykładów (przeformatowanie, parafraza, zmiana stylu) jest bezpieczniejszym podejściem niż czyste generowanie — zachowuje fakty z seed setu i zmienia tylko formę. Jest odpowiednia, gdy:
- Dane seed są faktycznie wiarygodne (np. dokumentacja techniczna, Państwa wewnętrzne procesy)
- Chcą Państwo nauczyć model reagować na różne sposoby formułowania tego samego pytania
- Nie ma powodu wprowadzać nowych faktów spoza seed setu
Czyste generowanie (model nauczyciela tworzy zupełnie nowe przykłady) jest silniejsze, ale bardziej ryzykowne — nauczyciel może wprowadzić fakty, których seed set nie zawiera, i można tego nie wychwycić bez kontroli ludzkiej.
Podejście kombinowane: augmentacja dla ~60 % syntetycznego zbioru danych, czyste generowanie dla ~40 % (dla pokrycia scenariuszy long-tail) — z wyższym poziomem kontroli ludzkiej przy generowanych przykładach.
Kiedy nie stosować syntetyki
Istnieją sytuacje, w których dane syntetyczne nie tylko nie pomogą, ale aktywnie zaszkodzą:
Fakty i dokładne wartości liczbowe. Jeśli fine-tuning ma nauczyć model konkretnych numerów produktów, cen, parametrów technicznych — model nauczyciela je wymyśli. To klasyczne środowisko dla halucynacji. Dla wiedzy faktograficznej właściwą techniką jest RAG lub continued pretraining na zweryfikowanych tekstach, nie SFT na syntetyce.
Domeny regulowane bez walidacji eksperckiej. W kontekstach prawnych, medycznych lub finansowych syntetycznie wygenerowane przykłady mogą zawierać błędy merytoryczne, które prawdziwy ekspert rozpoznaje bez trudu, ale które wytrenowany model będzie replikował z pełną pewnością. Bez eksperckiego przeglądu każdego wygenerowanego przykładu — nie stosować tu syntetyki.
Gdy nie mają Państwo żadnych danych seed. Syntetyka bez zbioru seed to generowanie od zera — dostają Państwo dystrybucję odzwierciedlającą nauczyciela, nie Państwa domenę. Przed generowaniem muszą Państwo dysponować co najmniej małą, realną, dobrze zaannotowaną podstawą.
Informacje wrażliwe na czas. Model nauczyciela ma knowledge cutoff. Syntetyczne przykłady dotyczące bieżących wydarzeń, najnowszego prawodawstwa lub aktualnego rynku będą przestarzałe, a Państwo się o tym nie dowiedzą bez systematycznego pipeline'u fact-check.
Filtracja i quality gates — konkretne kroki
Filtracja to miejsce, w którym rozstrzyga się, czy syntetyczny zbiór danych pomoże czy zaszkodzi. Minimalny quality gate:
- 1.Walidacja formatu — automatyczna, 100 % przykładów. Wyeliminować przykłady z niepoprawnym formatem, brakującymi polami, niepoprawnymi wartościami.
- 2.Deduplikacja — wyszukiwanie podobieństwa oparte na embeddingach; przykłady z cosine similarity > 0.92 względem istniejących przykładów odrzucić (lub wybrać jeden reprezentatywny).
- 3.Skoring relewantności — jeśli mają Państwo weryfikowalne wyjścia (kod, JSON, SQL), uruchomić sprawdzenie składniowe. Jeśli nie, użyć model-as-judge z eksplicytną rubryką; nie ogólnego promptu „czy to jest dobre?".
- 4.Analiza dystrybucji — porównać rozkład tematów, długości i formatów syntetycznego zbioru vs seed setu. Wyraźne odchylenia sygnalizują drift.
- 5.Próbkowa kontrola ludzka — co najmniej 5 % przykładów z rotującym kryterium (nie oceniać zawsze tych samych typów). Skupić się na: faktach, tonie, przypadkach brzegowych.
Więcej kontekstu o tym, dlaczego jakość danych decyduje bardziej niż ilość: 7 powodów, dla których fine-tuning w praktyce zawodzi.
Najczęstsze pytania
Ile syntetycznych przykładów można dodać do realnych danych bez ryzyka?
Nie istnieje stały stosunek obowiązujący we wszystkich przypadkach. Praktyczny punkt orientacyjny: syntetyczne przykłady nie powinny stanowić więcej niż 70–80 % całego zbioru danych, jeśli nie dysponują Państwo silną filtracją i kontrolą ludzką. Przy wyższym udziale ryzyko model collapse rośnie. Dane seed muszą być zawsze obecne i muszą pokrywać całą dystrybucję przestrzeni przypadków użycia — nie tylko typowe przypadki.
Czy mogę używać ChatGPT / Claude do generowania danych treningowych dla mojego modelu?
Zależy od zastosowania. W przypadku wewnętrznego wdrożenia firmowego (model działa na Państwa infrastrukturze, nie jest dystrybuowany komercyjnie) sytuacja jest inna niż w przypadku produktu komercyjnego. Zawsze czytać aktualne ToS konkretnego dostawcy — sformułowania się zmieniają. Dla komercyjnie czystego potoku rekomendujemy modele open-weight nauczyciela (Llama, Qwen, Mistral) z permisywną licencją.
Czy generowanie przez model nauczyciela to to samo co destylacja modelu?
Nie. Destylacja w pierwotnym sensie operuje na logitach (dystrybucji prawdopodobieństw) nauczyciela. Generowanie danych syntetycznych przez API nauczyciela to bardziej pragmatyczny wariant — uzyskują Państwo przykłady tekstowe, nie sygnał dystrybucyjny. Wyniki są słabsze niż w przypadku pełnej destylacji, ale wykonalne bez dostępu do wnętrza modelu. W projektach komercyjnych ten wariant jest powszechniejszy właśnie ze względu na dostępność.
Co jeśli model nauczyciela generuje merytorycznie błędne przykłady?
To standardowy problem i główny argument za ludzką kontrolą próbki. Model nauczyciela halucinuje — rzadziej niż małe modele, ale nie zerowo. Rozwiązanie: zadania weryfikowalne (kod, JSON, SQL) sprawdzać automatycznie; fakty w tekście niestrukturalnym wymagają przeglądu ludzkiego. Jeśli nie mają Państwo mocy przerobowych na przegląd ludzki, ograniczyć syntetykę do augmentacji istniejących zweryfikowanych przykładów — nie do generowania nowych faktów.
Czy dane syntetyczne pomogą, jeśli model nie wie nic o mojej domenie?
Rzadko kiedy. Syntetyka potrafi rozszerzyć i zdywersyfikować istniejący seed set — nie jest w stanie zastąpić fundamentu wiedzy domenowej. Jeśli model nie ma żadnej podstawy domenowej, właściwą ścieżką jest continued pretraining na tekstach domenowych (instrukcjach, normach, dokumentach wewnętrznych), a dopiero potem SFT — syntetyczny lub realny.
*MP Industrial Solutions podejmuje te decyzje na co dzień dla klientów z produkcji, energetyki i logistyki. Jeśli zastanawiają się Państwo, jaka kombinacja realnych i syntetycznych danych ma sens dla Państwa konkretnego modelu i przypadku użycia — chętnie to wspólnie przeanalizujemy.*