Firma ubezpieczeniowa chce wytrenować model wykrywający fraudy. Ma sto tysięcy rekordów transakcyjnych. Z tego fraudów — trzysta. Klasyfikator trenowany na takim zbiorze nauczy się przewidywać „brak fraudu" w 99,7% przypadków i osiągnie wynik dokładności 99,7%, nie wykrywając niczego użytecznego. Problem nie leży w algorytmie. Leży w danych.
Dane syntetyczne są jedną z odpowiedzi na ten problem. Nie jedyną i nie zawsze właściwą, ale w 2026 roku stały się standardowym narzędziem w zestawie każdego zespołu budującego systemy AI dla firm. Poniżej opisuję, kiedy to narzędzie ma sens, jak je stosować bezpiecznie i gdzie leżą granice, których nie warto przekraczać.
Czym są dane syntetyczne i czym nie są
#Dane syntetyczne to dane wygenerowane przez model lub algorytm na podstawie wzorców wyuczonych z danych źródłowych. Kluczowe: nie są kopią ani anonimizowaną wersją danych oryginalnych. Są nową populacją rekordów, która naśladuje strukturę i rozkład oryginału.
Trzy klasy danych syntetycznych, które pojawiają się w projektach:
Dane tabelaryczne syntetyczne — wiersze tabeli przypominające realne transakcje, pacjentów, klientów lub zdarzenia, wygenerowane przez modele takie jak CTGAN, TVAE lub Gaussian Copula. Każdy wiersz jest nowy. Żaden nie odpowiada konkretnemu człowiekowi.
Teksty i dokumenty syntetyczne — treści wygenerowane przez LLM na podstawie schematów (np. syntetyczne faktury, maile reklamacyjne, raporty inspekcji) do trenowania i testowania systemów opartych na RAG lub ekstrakcji danych.
Obrazy i dane nieustrukturyzowane syntetyczne — zdjęcia, skany, nagrania wygenerowane przez modele generatywne, stosowane przy niedoborze danych w systemach wizji komputerowej lub OCR.
Dane syntetyczne nie są tym samym co dane anonimizowane. Anonimizacja usuwa lub maskuje PII z realnych rekordów. Dane syntetyczne w ogóle nie zawierają realnych rekordów jako źródła poszczególnych wierszy, choć model generujący je był trenowany na realnych danych. Ta różnica ma znaczenie prawne i architektoniczne.
Kiedy dane syntetyczne mają sens, a kiedy nie
#Nie każdy problem z danymi rozwiązuje synteza. Tabela poniżej zestawia sygnały, które sugerują syntetykę, z sygnałami, które powinny ją wykluczyć.
| Sygnał | Dane syntetyczne | Alternatywa |
|---|---|---|
| Klasy rzadkie (fraud, awaria, odmowa) poniżej 1% | Tak — augmentacja rzadkiej klasy | Over-sampling (SMOTE) dla prostszych przypadków |
| Dane zawierają PII i nie można ich udostępnić zewnętrznemu dostawcy | Tak — zamiast maskowania przy zachowaniu rozkładu | Lokalne self-hosting modelu treningowego |
| Dane z produkcji potrzebne w środowisku testowym | Tak — baza testowa bez ryzyka wycieku | Subset z pełną anonimizacją |
| Brakuje danych w ogóle (nowy produkt, nowy rynek) | Ostrożnie — model nie ma się na czym uczyć rozkładu | Pilot zbierania realnych danych, reguły eksperckie |
| System high-risk AI Act Załącznik III | Tak, ale z pełną dokumentacją toru treningowego | Dane realne z DPIA i legal basis |
| Model musi wykrywać subtelne wzorce behawioralne (np. fraud oparty na relacjach) | Nie — synteza gubi relacje wyższego rzędu | Dane realne, ewentualnie federated learning |
Kryterium decyzyjne: dane syntetyczne sprawdzają się przy problemach statystycznych (brak równowagi klas, brak danych środowiskowych, prywatność). Nie sprawdzają się przy problemach wymagających rzeczywistej zmienności wzorców, których model generujący nie widział w danych źródłowych.
Metody generowania danych tabelarycznych
#Przy danych tabelarycznych (najczęstszy przypadek w firmach) wybór metody zależy od złożoności zależności w danych.
Gaussian Copula modeluje zależności między kolumnami przez rozkład normalny wielowymiarowy. Szybka, interpretowalna, dobrze radzi sobie z prostymi korelacjami. Zawodzi przy danych silnie nieliniowych lub kategorycznych z rzadkimi kombinacjami.
CTGAN (Conditional Tabular GAN) uczy się rozkładów warunkowych przez sieć generatywno-adversaryjną. Lepsza przy danych z wieloma typami kolumn i nieliniowymi zależnościami. Wymaga więcej danych źródłowych do trenowania (orientacyjnie kilka tysięcy wierszy minimum) i jest trudniejsza do kalibracji.
TVAE (Tabular Variational Autoencoder) podobna do CTGAN, ale bazuje na autoenkoderze wariacyjnym. Często stabilniejsza w trenowaniu, gorsza przy bardzo rzadkich kombinacjach wartości.
Metody oparte na LLM — nowszy kierunek, w którym LLM generuje syntetyczne wiersze na podstawie opisu schematu i przykładów. Działa przy małych zbiorach (few-shot), jest wolniejszy i droższy przy milionach rekordów, ale daje wysoki realizm dla danych tekstowych lub mieszanych.
Wybór metody powinien być poprzedzony ewaluacją na zbiorze walidacyjnym: wytrenuj model docelowy raz na danych syntetycznych, raz na realnych, porównaj metryki. Różnica poniżej 5% na tym samym zbiorze testowym to dobry sygnał. Różnica powyżej 15% sugeruje, że synteza traci istotne wzorce.
Walidacja jakości danych syntetycznych
#Wygenerowanie danych to połowa pracy. Druga połowa to potwierdzenie, że są użyteczne i bezpieczne. Trzy wymiary walidacji:
Wierność statystyczna. Porównaj rozkłady każdej kolumny: mean, std, kwantyle, mode dla kategorycznych. Sprawdź macierz korelacji (Pearson dla numerycznych, Cramér's V dla kategorycznych) między danymi realnymi a syntetycznymi. Biblioteki takie jak sdmetrics lub ydata-profiling generują takie raporty automatycznie.
Użyteczność (Train on Synthetic, Test on Real — TSTR). Wytrenuj model na syntetycznych danych. Przetestuj na realnych. Porównaj z modelem treningowym na realnych danych (TRTR). Stosunek metryk TSTR/TRTR bliski 1,0 oznacza, że synteza zachowuje wzorce istotne dla modelu. Jeśli spada poniżej 0,85, wróć do parametrów generatora.
Prywatność (Privacy Metrics). Najważniejsze: Distance to Closest Record (DCR) i Nearest Neighbor Adversarial Accuracy (NNAA). DCR mierzy, jak blisko każdy syntetyczny rekord jest do swojego najbliższego odpowiednika w danych realnych. Rekordy zbyt bliskie oryginałom mogą naruszać prywatność przez atak membership inference — czyli wykrycie, że konkretna osoba była w zbiorze treningowym.
Observability procesu generowania jest tak samo ważna jak observability modelu produkcyjnego. Loguj parametry generatora, wersję danych źródłowych i wyniki metryk walidacyjnych przy każdym wygenerowaniu.
RODO i AI Act: co obowiązuje przy danych syntetycznych
#Dane syntetyczne nie są automatycznie poza zakresem RODO. Europejski Inspektor Ochrony Danych (EDPS) oraz Komitet (EDPB) wyjaśniają, że jeśli model generujący dane był trenowany na danych osobowych, a wygenerowane rekordy pozwalają na re-identyfikację (np. przez kombinację rzadkich cech), dane syntetyczne mogą nadal być danymi osobowymi w rozumieniu art. 4(1) RODO.
Wymagania zależą od oceny ryzyka re-identyfikacji:
Jeśli DCR i NNAA wskazują niskie ryzyko re-identyfikacji, a dane były generowane z agregatu (nie z konkretnych rekordów), standardowe podstawy prawne przetwarzania danych syntetycznych są analogiczne do danych zanonimizowanych.
Jeśli dane syntetyczne są generowane w kontekście systemu wysokiego ryzyka wg AI Act (np. system scoringu kredytowego, rekrutacyjny, medyczny), dokumentacja toru treningowego musi obejmować opis metody generowania, metryki prywatności i wynik DPIA. To wymóg Art. 10 AI Act dotyczący zarządzania danymi.
Praktyczna zasada: wygeneruj raport walidacyjny przed każdym użyciem danych syntetycznych w produkcji lub w systemach podlegających AI Act. Raport przechowuj razem z modelem. Przy human-oversight w systemach wysokiego ryzyka audytor musi mieć dostęp do historii danych treningowych, w tym syntetycznych.
Dane syntetyczne do testów i debugowania agentów AI
#Odrębnym zastosowaniem, które nie wymaga ani trenowania modeli, ani pełnej walidacji statystycznej, są dane syntetyczne do testów środowisk i agentów AI.
Agent obsługujący zamówienia musi być przetestowany na scenariuszach, które w produkcji zdarzają się rzadko: zamówienie z brakującym adresem, dwadzieścia pozycji w koszyku z tej samej kategorii, waluta inna niż PLN, data dostawy w przeszłości. Takich przypadków w danych produkcyjnych jest pięć na milion transakcji. W bazie testowej można je wygenerować w dowolnej liczbie.
Ten typ danych syntetycznych generuje się prostymi skryptami lub przez LLM z instrukcją tworzenia brzegowych przypadków testowych. Nie wymaga CTGAN ani TVAE. Wymaga dobrze opisanych przypadków brzegowych (edge cases), które zazwyczaj dokumentuje się w trakcie analizy wymagań.
Przy budowie guardrails dla agenta, dane syntetyczne do testów pozwalają na automatyczne testowanie regresyjne: każda zmiana w prompcie systemu lub w logice guardrails przechodzi przez zestaw syntetycznych scenariuszy testowych. To sam schemat co testy jednostkowe w inżynierii oprogramowania, ale zaadaptowany do niedeterministycznych systemów AI. Więcej o monitorowaniu jakości agentów opisuje artykuł monitoring jakości agenta AI.
Integracja z potokiem RAG i fine-tuningiem
#Dane syntetyczne wchodzą w dwa miejsca potoku AI: jako dane treningowe (fine-tuning) oraz jako dokumenty rozszerzające bazę wiedzy RAG.
Przy fine-tuningu syntetyczne pary pytanie-odpowiedź na bazie dokumentów firmowych pozwalają na specjalizację modelu bez wysyłania wrażliwych dokumentów do dostawcy zewnętrznego. Schemat: LLM lokalny generuje pytania i odpowiedzi z dokumentów (które masz prawo przetwarzać). Te pary syntetyczne są podstawą zestawu treningowego do fine-tuningu. Dokumenty oryginalne nigdy nie opuszczają środowiska. Kiedy ten wariant ma sens, a kiedy lepiej zostać przy samym RAG, opisuje artykuł kiedy fine-tuning ma sens.
Przy RAG dane syntetyczne uzupełniają bazę wiedzy o scenariusze, których realna dokumentacja nie obejmuje: przykładowe dialogi z klientem, przykładowe zapytania ofertowe, przykładowe raporty inspekcji. Daje to modelowi kontekst do bardziej trafnych odpowiedzi bez konieczności ujawniania realnych danych klientów.
Istotne ograniczenie: syntetyczne dokumenty do RAG muszą być wyraźnie oznaczone jako syntetyczne w metadanych wektora. Mieszanie danych syntetycznych z realnymi bez oznaczenia komplikuje audyt i utrudnia debugowanie halucynacji. Więcej o zarządzaniu bazą wiedzy RAG w artykule aktualizacja wiedzy RAG i wersjonowanie.
Wypróbuj na żywo
#FAQ
#Czy dane syntetyczne są zgodne z RODO z definicji?
#Nie. Dane syntetyczne mogą nadal być danymi osobowymi, jeśli model generujący był trenowany na danych osobowych i wygenerowane rekordy pozwalają na re-identyfikację konkretnych osób przez kombinację rzadkich cech. Ocena ryzyka re-identyfikacji przez metryki DCR i NNAA powinna poprzedzać każde użycie danych syntetycznych w systemach przetwarzających informacje o osobach fizycznych. Przy systemach wysokiego ryzyka wg AI Act wymagana jest pełna DPIA.
Ile danych źródłowych potrzeba do generowania danych syntetycznych?
#Zależy od metody. Gaussian Copula działa przy kilkuset wierszach i prostych zależnościach. CTGAN i TVAE potrzebują orientacyjnie kilku tysięcy wierszy dla stabilnego trenowania generatora, a przy wielu kolumnach kategorycznych z rzadkimi wartościami — więcej. Generowanie przez LLM (few-shot) działa przy kilkudziesięciu przykładach, ale jakość statystyczna jest niższa niż metod generatywnych. Przy bardzo małych zbiorach (poniżej 500 rekordów) dane syntetyczne mogą paradoksalnie nie poprawić modelu, bo generator nauczy się na szumie, nie na wzorcach.
Jak sprawdzić, że dane syntetyczne nie „wyciekają" oryginalnych rekordów?
#Oblicz Distance to Closest Record (DCR) dla każdego syntetycznego rekordu względem zbioru źródłowego. Jeśli median DCR jest bliski zeru, generator przepisuje oryginalne wiersze zamiast tworzyć nowe. Uzupełnij to testem Nearest Neighbor Adversarial Accuracy (NNAA): klasyfikator trenowany na próbie „prawdziwe vs. syntetyczne" powinien mieć dokładność bliską 0,5 (losowo), nie bliską 1,0 (umie rozróżnić). Biblioteka sdmetrics implementuje oba testy jako gotowe funkcje.
Czy dane syntetyczne zastąpią zbieranie danych realnych?
#Nie całkowicie. Dane syntetyczne są wartościowym narzędziem uzupełniającym, nie zastępczym. Model generujący syntezę uczy się wzorców z danych realnych — nie ma skąd wygenerować zjawisk, które w realnych danych nie istniały. Przy nowym produkcie bez historii, nowym rynku lub nowym typie zdarzenia dane syntetyczne nie zastąpią procesu zbierania danych pilotażowych. Właśnie dlatego przed każdym projektem AI warto ocenić stan danych przez narzędzie ocena gotowości i kalkulator ROI.
Jak wycenić projekt wdrożenia danych syntetycznych?
#Zakres pracy zależy od złożoności schematu danych, liczby kolumn z PII, wymaganego poziomu walidacji (statystyczna vs. TSTR vs. pełna prywatność) i tego, czy dane wejdą do systemu high-risk AI Act. Orientacyjny opis: projekty pilotażowe z ewaluacją metody na istniejącym zbiorze i wdrożeniem potoku syntezy to zakres kilku do kilkunastu tygodni pracy. Pełną wycenę przygotowujemy po analizie przez kalkulator ROI lub bezpośrednim kontakcie.