synthetic-data-generator: Tabellendaten synthetisch erzeugen, mit CTGAN und LLM

Welches Problem SDG löst und für wen es gedacht ist

Wer Tabellendaten aus einem Produktivsystem nicht weitergeben darf, braucht Ersatz, der die Spaltenstruktur, die Verteilungen und die Beziehungen zwischen Spalten erhält. Genau dort setzt SDG an. Das Repository beschreibt das Ziel als Generierung hochwertiger strukturierter Tabellendaten und nennt als Anwendungsfelder Datenweitergabe, Modelltraining und Debugging sowie Systementwicklung und Tests. Die Zielgruppe sind damit Dateningenieure und ML-Teams, die synthetische Daten selbst erzeugen wollen, statt sie einzukaufen.

Bemerkenswert ist, dass die README die rechtliche Wirkung ausdrücklich behauptet: Synthetische Daten enthielten keine sensiblen Informationen und seien deshalb von Regelwerken wie GDPR und ADPPA ausgenommen. Diese Aussage steht unkommentiert im Projekttext. Ob ein Datensatz als anonym gilt, hängt vom Verfahren und vom Einzelfall ab, nicht vom Werkzeugnamen. Wer SDG wegen dieses Satzes auswählt, sollte die Bewertung selbst treffen und nicht aus der README übernehmen.

Data Processor: Konvertierung vor und nach dem Modell

Der Data Processor ist die Schicht, die zwischen Rohdaten und Modell sitzt. Laut README übernimmt sie vier Aufgaben: Spalten wie Datetime vor dem Training in ein modellfreundliches Format bringen, damit sie nicht als diskrete Typen behandelt werden; die vom Modell erzeugten Werte zurück in das Originalformat wandeln; benutzerdefinierte Vor- und Nachverarbeitung für verschiedene Datentypen erlauben; und Nullwerte im Ausgangsdatensatz behandeln. Zusätzlich nennt die README ein Plug-in-System.

Das ist architektonisch der interessanteste Teil des Projekts, weil er das Problem adressiert, an dem einfache Generatoren scheitern. Ein GAN oder ein Copula-Modell arbeitet auf Zahlen. Eine Spalte mit Zeitstempeln oder ein Feld mit gemischten Typen wird ohne Vorverarbeitung zu einer großen Menge diskreter Kategorien, was das Training verlangsamt und die Qualität senkt. SDG zieht diese Umwandlung aus dem Modell heraus in eine eigene Komponente. Der Preis dafür ist ein zusätzlicher Konfigurationsschritt: Wer den Data Processor nicht passend bestückt, bekommt syntaktisch gültige, inhaltlich aber falsch skalierte Werte zurück.

Modelle: GaussianCopula, CTGAN und ein LLM-Pfad

SDG ist kein einzelnes Modell, sondern eine Sammlung. Die Release-Notes zur Version 0.2.4 vom Dezember 2024 und die News-Einträge nennen GaussianCopula als integriertes Modell im Data-Processor-System, daneben CTGAN, das laut README seit v0.1.0 vorhanden ist und mit einer Benchmark gegen SDV verglichen wurde. Für GaussianCopula berichtet die README von reduziertem Speicherverbrauch bei diskreten Daten, sodass Training mit tausenden kategorialen Werten auf einer Maschine mit 2C4G möglich sei. Das sind Projektangaben, keine unabhängig geprüften Messwerte.

Der LLM-Pfad ist konzeptionell anders. sdgx.models.LLM.single_table.gpt.SingleTableGPTModel soll laut README zwei Dinge können: synthetische Daten ohne Trainingsdaten allein aus Metadaten erzeugen, und Off-Table-Inference, also das Ableiten von Spalten, die im Ausgangsdatensatz nicht enthalten sind. Der zweite Punkt ist mit statistischen Verfahren nicht erreichbar, weil dort nur Beziehungen entstehen, die in den Trainingsdaten sichtbar sind. Ein LLM kann dagegen aus Weltwissen plausibel erscheinende Werte ergänzen. Ob diese Werte fachlich korrekt sind, garantiert das nicht.

Metadaten als Steuerungsschicht

Seit Februar 2024 unterstützt sdgx.data_models.metadata die Beschreibung einzelner und mehrerer Tabellen, mehrere Datentypen und automatische Typinferenz. Metadaten sind damit nicht nur Dokumentation, sondern Eingabe für die Generierung. Das erklärt, warum der LLM-Pfad ohne Trainingsdaten auskommen kann: Wenn Typen und Spaltenbeziehungen als Metadaten vorliegen, hat das Modell eine Beschreibung, aus der es Werte erzeugen kann.

Für den Alltag heißt das: Die Qualität der Metadaten bestimmt die Qualität der Ausgabe mit. Automatische Inferenz ist bequem, aber sie rät. Eine Spalte mit Postleitzahlen sieht numerisch aus und wird als Zahl behandelt, obwohl sie kategorial ist. Wer das nicht korrigiert, trainiert auf einer falschen Annahme. Die README nennt außerdem eine Funktion zur automatischen Erkennung von Spaltenbeziehungen mit der Möglichkeit, Beziehungen explizit vorzugeben. Das ist der Hebel, an dem sich Korrektheit am direktesten beeinflussen lässt.

Installation und erste Schritte

Das Paket wird als sdgx auf PyPI verteilt, die Dokumentation liegt auf readthedocs unter synthetic-data-generator. Die README verweist auf Colab-Notebooks für LLM-Datensynthese, Off-Table-Inference und für CTGAN mit großen Datenmengen. Die Paketversionen der letzten Releases lauten 0.2.2, 0.2.3 und 0.2.4.

Für den Einstieg ist der Weg über die Notebooks der ehrlichste, weil dort die vollständigen Aufrufe inklusive Metadatenaufbau und Data Processor sichtbar sind. Aus der README allein lässt sich kein vollständiges Codebeispiel rekonstruieren; die Modellklassen sind über den Namensraum sdgx.models erreichbar, etwa sdgx.models.LLM.single_table.gpt.SingleTableGPTModel, und die Metadaten über sdgx.data_models.metadata. Wer die genauen Parameter sucht, ist auf die API-Dokumentation angewiesen. Diese Lücke ist ein realistischer Einstiegshinweis: Das Projekt dokumentiert seine Konzepte in der README, die Aufrufe aber in der separaten Dokumentation und in den Notebooks.

Wo SDG an Grenzen stößt

Die wichtigste Einschränkung steht implizit in der Struktur des Projekts: Es gibt mehrere Modelle mit unterschiedlichen Fähigkeiten, und die README beschreibt Speicherverhalten nur für zwei davon. Für den LLM-Pfad nennt sie keine Speicher- oder Kostengrenzen. Wer ein LLM zur Tabellengenerierung einsetzt, bezahlt pro Aufruf oder bindet eigene Rechenleistung, und die Erzeugung eines großen Datensatzes skaliert nicht so wie ein einmal trainiertes GAN. Für zehntausende Zeilen ist das ein anderer Kostenrahmen als für ein paar hundert.

Zweitens ist die rechtliche Aussage in der README zu stark vereinfacht. Synthetische Daten können Trainingsdaten reproduzieren, besonders bei seltenen Kombinationen und kleinen Ausgangsdatensätzen. Das Projekt liefert nach der hier vorliegenden Materialbasis keine Beschreibung eines Prüfverfahrens für diesen Fall. Wer personenbezogene Daten ersetzt, braucht einen eigenen Test auf Reidentifikation und sollte sich nicht auf den Satz aus der README stützen.

Drittens: SDG ist kein Werkzeug für unstrukturierte Daten. Bilder, Freitext ohne Tabellenbezug oder Zeitreihen mit variabler Länge liegen außerhalb des beschriebenen Umfangs. Der Name ist breiter als die Fähigkeit.

Alternative: SDV und der Unterschied im Ansatz

Der naheliegende Vergleich ist SDV, und die README selbst stellt ihn her: Die CTGAN-Benchmark von v0.1.0 vergleicht SDG gegen SDV und berichtet geringeren Speicherverbrauch sowie ein Vermeiden von Abstürzen während des Trainings. Das ist eine Projektangabe aus dem Repository, kein unabhängiger Test.

Der Unterschied liegt weniger im Modell als in der Klammer darum. SDV positioniert sich als Werkzeugkasten, in dem Metadaten, Transformer und Synthesizer eng aufeinander abgestimmt sind, mit einer etablierten API für einzelne und mehrere Tabellen. SDG setzt einen eigenen Data Processor davor und öffnet die Modellwahl zusätzlich in Richtung LLM, was SDV in dieser Form nicht beschreibt. Wer Beziehungen zwischen mehreren Tabellen sauber abbilden will, findet in SDV die reifere Erzählung. Wer einen LLM-Pfad für Off-Table-Inference braucht oder Speicher auf kleiner Hardware sparen muss, hat in SDG ein Argument. Beides gleichzeitig zu erwarten, wäre eine Fehlannahme über den Reifegrad.

Wartung, Versionen und Lizenz

Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im August 2026, die letzte Veröffentlichung 0.2.4 stammt vom Dezember 2024. Zwischen den Releases 0.2.2, 0.2.3 und 0.2.4 lagen jeweils nur wenige Wochen, danach folgt eine längere Pause bis zum aktuellen Stand. Wer SDG produktiv einsetzt, sollte die Release-Kadenz im Blick behalten und nicht damit rechnen, dass Breaking Changes früh angekündigt werden.

Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an Dateien kenntlich gemacht werden. Für den Patentabschnitt enthält Apache-2.0 eine ausdrückliche Gewährung. Das ist keine Rechtsberatung; wer SDG in ein Produkt einbettet, sollte die Hinweispflichten mit der eigenen Rechtsabteilung klären.

Als Upgrade-Aufwand bleibt vor allem die Modellvielfalt: Wer von GaussianCopula auf CTGAN oder auf den LLM-Pfad wechselt, tauscht nicht nur eine Klasse aus, sondern ändert die Anforderungen an Datenmenge, Rechenzeit und Metadatenqualität. Diese Kopplung sollte man vor der Modellwahl bedenken, nicht danach.

Redaktionelles Fazit

SDG passt zu Teams, die tabellarische Trainings- oder Testdaten brauchen und dafür Python-Code statt einer gehosteten Plattform akzeptieren. Wer nur schnell eine CSV mit synthetischen Werten will, ist mit einem einzelnen Generator aus scikit-learn oder Faker besser bedient, weil SDG Metadaten, Data Processor und Modellwahl als eigene Konzepte verlangt. Vor dem ersten produktiven Lauf sollte man klären, ob die Dokumentation das gewünschte Modell bereits als stabil führt, und einen Trainingslauf auf der eigenen Datenbreite fahren, weil der README Speicherverbrauch nur für GaussianCopula und CTGAN konkret beschreibt.

Offizielle Quellen

1. hitsz-ids/synthetic-data-generator on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases