NeMo Data Designer: synthetische Datensätze mit Samplern, LLM-Spalten und Validatoren

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

Ein einzelner LLM-Prompt liefert Text, aber keine kontrollierte Verteilung. Genau dort setzt das Projekt an: Das README beschreibt als Ziel, synthetische Datensätze zu erzeugen, die über einfaches Prompting hinausgehen, mit diversen statistischen Verteilungen, sinnvollen Korrelationen zwischen Feldern und geprüften Ausgaben. Die Zielgruppe sind damit nicht Anwender, die ein paar Beispielsätze brauchen, sondern Teams, die Datensätze für Training oder Evaluation bauen und dabei festlegen wollen, welche Spalte wodurch entsteht. Das README nennt als Einsatzfelder Text, strukturierte Daten und Bilder, multimodale Abläufe mit Bild-, Audio- und Videokontext sowie die Anbindung an externe Werkzeuge über lokale oder entfernte MCP-Server. Wer eine Datenquelle hat und sie augmentieren will, findet dafür den Seed-Pfad; wer bei null anfängt, nutzt Sampler. Beides läuft über dasselbe Spaltenmodell, was der eigentliche Verkaufsargument ist: Der Datensatz ist eine deklarative Konfiguration, kein imperatives Skript.

Das Spaltenmodell: Sampler zuerst, LLM-Spalten danach

Die Architektur ist im Quick-Start-Beispiel sichtbar. Zuerst entsteht ein DataDesignerConfigBuilder, dann werden Spalten angehängt. Eine SamplerColumnConfig mit sampler_type=dd.SamplerType.CATEGORY und CategorySamplerParams(values=[...]) erzeugt eine kategoriale Spalte, hier product_category mit vier Werten. Darauf folgt eine LLMTextColumnConfig mit name, model_alias und prompt, wobei der Prompt die vorherige Spalte über die Syntax {{ product_category }} referenziert. Das ist der Kern des Datenflusses: Spalten werden in Reihenfolge ausgewertet, spätere Spalten sehen die Werte früherer. Das README nennt das dependency-aware generation, also abhängigkeitsbewusste Erzeugung. Wer Korrelationen zwischen Feldern braucht, muss sie nicht nachträglich in die Daten hineinrechnen, sondern baut sie über die Reihenfolge und die Referenzen auf. Der Preis dafür ist, dass die Konfiguration wächst: Jede zusätzliche Abhängigkeit ist eine zusätzliche Spalte mit eigenen Parametern, und die Reihenfolge im Builder ist keine Formalität, sondern bestimmt, welche Werte zur Verfügung stehen.

Validierung, Bewertung und Erweiterungspunkte

Generierte Daten sind erst dann brauchbar, wenn jemand prüft, ob sie den Anforderungen entsprechen. Das README listet dafür Python-, SQL- und Custom-Validatoren sowie LLM-Richter (LLM judges). Diese Prüfungen laufen innerhalb desselben Spaltenmodells, nicht in einem separaten Nachbearbeitungsschritt. Für Erweiterungen nennt das README Plugins für eigene Spaltentypen, Seed-Reader und Prozessoren. Das ist der Punkt, an dem das Projekt über ein Konfigurationsformat hinausgeht: Wer eine Datenquelle anbinden will, die nicht als Datei vorliegt, schreibt einen Seed-Reader, statt die Daten vorher zu exportieren. Eine Einschränkung ist an dieser Stelle ehrlich zu benennen. Das README beschreibt die Validatoren als Konzept und verlinkt die Dokumentation, nennt aber weder Standardfehlerraten noch das Verhalten, wenn ein Validator eine Zeile ablehnt: ob verworfen, wiederholt oder markiert wird, lässt sich aus dem vorliegenden Material nicht ableiten. Wer auf Ablehnungen angewiesen ist, muss das in der verlinkten Validatoren-Dokumentation nachlesen, bevor er einen großen Lauf startet.

Installation und Modellkonfiguration über die CLI

Der Einstieg ist ein pip-Aufruf: pip install data-designer. Alternativ der Quellweg über git clone des Repositories, cd DataDesigner und make install. Danach braucht das Werkzeug Zugang zu einem Modell. Das README nennt drei Standardanbieter, NVIDIA Build API, OpenAI und OpenRouter, und die zugehörigen Umgebungsvariablen NVIDIA_API_KEY, OPENAI_API_KEY und OPENROUTER_API_KEY. Der Quick Start setzt model_alias="nvidia-text", ohne zu erklären, woher dieser Alias kommt. Genau dafür existiert die CLI: data-designer config providers konfiguriert Anbieter, data-designer config models legt Modellkonfigurationen an, data-designer config list zeigt die aktuellen Einstellungen. Wer den Quick Start wörtlich übernimmt und den Alias nicht vorher angelegt hat, läuft in einen Konfigurationsfehler, nicht in einen Fehler des generierten Codes. Vor dem ersten Lauf lohnt deshalb data-designer config list, um zu sehen, welche Aliase die eigene Installation tatsächlich kennt. Der Vorschaulauf selbst ist im Beispiel ein Aufruf von data_designer.preview(config_builder=config_builder) mit anschließendem preview.display_sample_record().

Telemetrie, Konfiguration und der Preis der Bequemlichkeit

Data Designer sendet standardmäßig Telemetrie. Das README begründet das damit, zu sehen, welche Modelle für synthetische Datengenerierung am häufigsten genutzt werden, und veröffentlicht die aggregierten Zahlen. Abschalten lässt sich das über NEMO_TELEMETRY_ENABLED=false. Für Umgebungen mit strengen Vorgaben zur Datenabgabe ist das kein Nebensatz, sondern eine Voraussetzung, die vor dem ersten Lauf gesetzt sein muss, nicht danach. Dazu kommt ein Hinweis, den das README selbst gibt: Das Projekt lädt bei der Installation weitere Open-Source-Pakete von Drittanbietern nach, deren Lizenzbedingungen vor der Nutzung zu prüfen sind. Data Designer selbst steht unter Apache-2.0, was die Weitergabe und kommerzielle Nutzung des Frameworks erlaubt. Diese Lizenz erstreckt sich aber nicht automatisch auf die nachgeladenen Abhängigkeiten oder auf die über Provider abgerufenen Modellausgaben. Wer den Datensatz später veröffentlicht, muss die Bedingungen beider Ebenen getrennt betrachten. Das ist keine Rechtsberatung, sondern der Hinweis, den das README an dieser Stelle platziert.

Der Agent-Skill und die Frage, wer das Schema entwirft

Das Repository liefert einen Skill für Coding-Agenten mit, installierbar über npx skills add NVIDIA-NeMo/DataDesigner. Laut README ist er mit Claude Code und Codex getestet, und nach der Installation übernimmt der Agent Schemaentwurf, Validierung und Generierung, sobald man den gewünschten Datensatz beschreibt. Das verschiebt die Arbeit: Statt Spalten und Parameter von Hand zu schreiben, beschreibt man das Ergebnis. Der Skill ist damit ein Eingeständnis, dass die Konfiguration selbst Arbeit ist. Für einen schnellen Prototyp ist das hilfreich. Für einen Datensatz, dessen Verteilung später reproduzierbar sein muss, bleibt die vom Agenten erzeugte Konfiguration ein Artefakt, das man lesen, prüfen und versionieren sollte, sonst ist die Reproduzierbarkeit an einen Prompt gebunden, den niemand mehr kennt. Das README weist außerdem darauf hin, dass Beiträge zum Repository agentenunterstützte Abläufe vorsehen und die Dokumentationsprosa unter fern/ bearbeitet wird, während Tutorial-Notebooks aus docs/notebook_source/*.py generiert werden. Wer Dokumentation korrigieren will, muss also die Quelle ändern, nicht das erzeugte Notebook.

Wann Data Designer das falsche Werkzeug ist

Die Grenze liegt beim Umfang der Kontrolle, die man tatsächlich braucht. Wer eine Handvoll Beispiele für einen Prompt-Test erzeugt, zahlt hier für Struktur, die er nicht nutzt: Provider-Konfiguration über die CLI, Modell-Aliase, Spaltenreihenfolge, Validatoren. Ein direkter SDK-Aufruf an den Anbieter ist in diesem Fall kürzer. Ein zweiter Fall sind Teams, die ihre Daten bereits fertig vorliegen haben und nur filtern oder umbenennen wollen. Data Designer ist auf Erzeugung ausgelegt, nicht auf Transformation bestehender Korpora. Drittens die Frage der Reproduzierbarkeit: Das README nennt Preview, Resume und Monitoring für Läufe von kleinen Experimenten bis zu großen Jobs, beschreibt aber nicht, wie ein Lauf bei gleicher Konfiguration deterministisch wiederholt werden kann. Da die Erzeugung über externe Modell-APIs läuft, ist die Ausgabe ohnehin nicht bitgleich. Wer exakte Wiederholbarkeit braucht, muss das über Versionierung der Konfiguration und der Modellversionen lösen, nicht über das Framework. Ein echter Alternativweg ist, die Generierung direkt gegen die Provider-SDKs zu schreiben und Validierung mit einer Bibliothek wie Great Expectations oder pandera nachzuschalten. Der Unterschied liegt im Ansatz: Dort orchestriert man selbst und hat volle Kontrolle über jeden Aufruf, hier deklariert man Spalten und überlässt die Ausführung dem Framework. Der zweite Weg ist schneller zum ersten Datensatz, der erste schneller zu einem Ablauf, den man vollständig versteht.

Pflegeaufwand und Versionierung

Zwischen v0.9.0 am 10. August 2026 und v0.9.2 am 3. September 2026 liegen drei Releases in rund vier Wochen. Diese Kadenz bedeutet, dass die API noch in Bewegung ist und Konfigurationsdetails sich zwischen Minor-Versionen ändern können. Wer Data Designer produktiv einsetzt, sollte die Version pinnen und die Release Notes vor jedem Sprung lesen, statt dem main-Branch zu folgen. Der letzte Push liegt auf demselben Datum wie das jüngste Release, das Repository ist nicht archiviert. Für die Dokumentation gilt eine Besonderheit, die den Pflegeaufwand erhöht: Die Prosa liegt unter fern/, die Notebooks werden aus docs/notebook_source/*.py generiert, und das alte MkDocs-Archiv bleibt nur für Releases 0.5.7 und älter auf GitHub Pages verfügbar. Wer ältere Anleitungen findet, arbeitet möglicherweise mit dem Legacy-Stand. Ein Upgrade ist damit nicht nur ein pip-Aufruf, sondern eine Prüfung, ob die eigene Konfiguration noch zu den aktuellen Spalten- und Provider-Definitionen passt.

Redaktionelles Fazit

Data Designer passt zu Teams, die reproduzierbare Trainings- oder Evaluationsdaten mit nachvollziehbaren Feldabhängigkeiten brauchen und bereit sind, Modell-Aliase und Provider über die CLI zu pflegen. Wer nur einmalig ein paar hundert Beispiele per Prompt erzeugen will, sollte bei einem Skript mit direktem SDK-Aufruf bleiben, weil Schema, Validatoren und Konfigurationsdateien hier mehr Aufwand als Nutzen bedeuten. Vor dem ersten produktiven Lauf ist zu prüfen, welche Provider und Modell-Aliase die eigene Installation kennt (data-designer config list), ob NEMO_TELEMETRY_ENABLED=false gesetzt werden muss und welche Lizenzbedingungen die beim Install mitgeladenen Fremdpakete mitbringen.

Offizielle Quellen

1. License: Apache-2.0
2. NVIDIA-NeMo/DataDesigner on GitHub
3. Project website
4. README
5. Releases