NeMo Data Designer : générer des jeux de données synthétiques à colonnes dépendantes
🎨 NeMo Data Designer: Generate high-quality synthetic data from scratch or from seed data.
En bref
- De quoi s’agit-il ?
- NVIDIA publie sous Apache-2.0 un cadre Python où chaque colonne d'un dataset synthétique peut dépendre des précédentes, avec validateurs et serveurs MCP. Voici le mécanisme, les commandes, et les cas où l'outil n'est pas le bon choix.
- À qui s’adresse-t-il ?
- Adoptez Data Designer si votre besoin est un dataset tabulaire où les champs doivent se répondre entre eux, avec des validateurs exécutables et une reprise sur incident en cours de run. Passez votre chemin si vous voulez surtout un pipeline texte vers texte : la couche de colonnes, de fournisseurs et de validateurs devient alors de la plomberie à maintenir pour rien.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un dataset synthétique n'est pas une liste de prompts
Un LLM interrogé ligne par ligne produit des enregistrements plausibles mais indépendants. Or un dataset exploitable a souvent des champs qui doivent se tenir : une catégorie de produit qui reste cohérente avec le texte d'avis généré, une distribution démographique qui ne s'effondre pas sur trois valeurs, une colonne dérivée qui n'invente pas un identifiant absent ailleurs. Faire respecter ces contraintes à la main, c'est du post-traitement en Python au-dessus d'une boucle d'appels.
Data Designer attaque ce point précis. Le README présente l'objectif comme dépasser le simple prompting LLM, en citant les distributions statistiques, les corrélations entre champs et les sorties validées. Le public visé est l'ingénieur qui doit produire un corpus d'entraînement ou d'évaluation reproductible, pas l'utilisateur qui veut une démo de génération de texte. La bibliothèque est en Python, publiée sous Apache-2.0, et la documentation annonce un support de Python 3.10 à 3.14.
Une colonne, une dépendance : la mécanique du config builder
L'unité de travail est la colonne, ajoutée à un DataDesignerConfigBuilder. L'exemple du README ajoute d'abord une colonne product_category via un SamplerColumnConfig de type CATEGORY, avec une liste de valeurs explicites dans CategorySamplerParams. Ensuite seulement vient une colonne review, un LLMTextColumnConfig dont le prompt contient {{ product_category }}.
C'est là que réside tout l'intérêt : la seconde colonne ne peut pas être générée avant la première, et le gabarit de prompt reçoit la valeur déjà tirée. Le graphe de dépendances se construit donc par l'ordre d'ajout, pas par une déclaration séparée. Le README mentionne aussi une génération sensible aux dépendances et un contrôle des relations entre champs, ce qui suggère que le mécanisme s'étend au-delà de ce seul exemple, mais la page ne détaille pas la résolution du graphe. Pour connaître les règles exactes de portée des variables, il faut aller lire la page Column Types de la documentation.
Le même README liste des capacités que je ne peux pas vérifier ici : workflows multimodaux avec contexte image, audio et vidéo, connexion à des serveurs MCP locaux ou distants avec capture des traces d'interaction, extension par plugins pour des colonnes, lecteurs de graines et processeurs. Ces éléments sont annoncés, pas démontrés dans le matériel fourni.
Installation et configuration des fournisseurs
L'installation tient en une commande : pip install data-designer. Le README signale dans une note que le projet télécharge et installe d'autres logiciels open source tiers, et invite à examiner leurs licences avant usage. C'est une remarque à prendre au sérieux : la licence Apache-2.0 couvre Data Designer, pas la chaîne d'outils que l'installation entraîne.
Pour l'exécution depuis les sources, le chemin est git clone du dépôt, cd DataDesigner, puis make install. Les clés d'API se placent dans des variables d'environnement, avec trois fournisseurs par défaut cités : NVIDIA_API_KEY pour NVIDIA Build, OPENAI_API_KEY pour OpenAI, OPENROUTER_API_KEY pour OpenRouter.
La configuration des modèles passe par une CLI dédiée, avec trois sous-commandes documentées : data-designer config providers, data-designer config models et data-designer config list. Cette séparation entre fournisseur et modèle explique pourquoi l'exemple utilise un alias, nvidia-text, plutôt qu'un nom de modèle en dur : la colonne référence un alias, et c'est la configuration qui décide ce qu'il y a derrière. Un changement de modèle ne touche donc pas le code de génération. En contrepartie, un alias non résolu ne se voit qu'à l'exécution, et la page d'accueil ne documente pas le schéma des fichiers de configuration eux-mêmes.
Valider plutôt qu'espérer
Le README annonce des validateurs en Python, en SQL, des validateurs personnalisés et des juges LLM, et renvoie à une page dédiée. C'est la partie la plus intéressante du projet et aussi la moins montrée : aucun exemple de validateur n'apparaît dans le matériel fourni. On sait que le mécanisme existe, on ne sait pas à quoi ressemble une règle, ni comment une ligne rejetée est traitée (re-tirée, marquée, exclue).
Un juge LLM comme validateur mérite d'être manié avec prudence. Il ajoute un appel de modèle par ligne et par règle, ce qui double facilement le coût d'un run, et il introduit une variance que les validateurs Python ou SQL n'ont pas. Le mélange des deux familles dans un même pipeline est cohérent sur le papier : les règles déterministes filtrent, le juge tranche sur les cas qualitatifs. Encore faut-il que l'ordre d'évaluation soit documenté.
Le README mentionne également la prévisualisation, la reprise et le suivi des runs, du petit essai au gros lot. La reprise est le point qui compte en pratique : sur des milliers de lignes générées par API, une coupure réseau au deux tiers du travail rend la relance complète inacceptable.
Télémétrie activée par défaut
Le README indique que la bibliothèque collecte de la télémétrie, décrit l'usage comme une agrégation des modèles les plus utilisés pour la génération de données synthétiques, et précise que ces données seront partagées avec la communauté. La désactivation se fait avec NEMO_TELEMETRY_ENABLED=false.
Le point à retenir est le défaut : il faut une action explicite pour ne rien envoyer. Dans un contexte où les prompts contiennent des données client ou des schémas internes, la question n'est pas de savoir si l'agrégat est anonyme, mais si l'envoi a lieu. Le README affirme que les données ne servent pas à suivre le comportement individuel d'un utilisateur ; je n'ai pas de moyen de le vérifier depuis le matériel fourni, et je ne peux donc que rapporter la formulation.
Un second point, indépendant de la vie privée : la variable d'environnement s'ajoute à la liste de celles qu'un déploiement doit poser. Un pipeline qui tourne dans un conteneur sans configuration explicite enverra de la télémétrie par défaut, et personne ne le remarquera.
Ce que le dépôt ne dit pas
La documentation renvoie à une page Person Sampling pour l'échantillonnage de données de personnes avec attributs démographiques. C'est une fonctionnalité sensible : produire des profils synthétiques crédibles suppose des choix sur les distributions et sur les corrélations entre attributs, et ces choix ne sont pas visibles dans le README. Il faut lire la page avant de s'appuyer dessus.
Le dépôt publie aussi un skill pour agents de codage, installable avec npx skills add NVIDIA-NeMo/DataDesigner, et annoncé comme testé avec Claude Code et Codex. L'idée est qu'un agent conçoive le schéma, la validation et la génération à partir d'une description en langage naturel. C'est séduisant et c'est aussi le chemin le plus court vers un schéma que personne ne comprend, avec des alias de modèles et des validateurs générés qu'il faudra relire.
Enfin, la documentation elle-même a une histoire : les sources de prose vivent sous fern/, les notebooks de tutoriel sont générés depuis docs/notebook_source/*.py, et une archive MkDocs reste disponible pour les versions 0.5.7 et antérieures. Autrement dit, un tutoriel trouvé en ligne peut décrire une API qui n'existe plus. La branche main et la version v0.9.2 sont les seules références à jour.
L'alternative : un script de génération écrit à la main
Le concurrent réel n'est pas un autre outil de données synthétiques, c'est le script Python que beaucoup d'équipes écrivent déjà : une boucle, un client API, un dictionnaire de champs, quelques appels de validation. La différence n'est pas la qualité du texte produit, elle est dans ce que le script ne fait pas. Un script maison n'a pas de graphe de dépendances entre colonnes, pas de reprise après interruption, pas de CLI de configuration des modèles, et chaque nouvelle contrainte se traduit par du code supplémentaire.
L'arbitrage dépend donc de la forme du besoin. Si vos données sont essentiellement du texte produit à partir d'un prompt, avec peu de champs structurés autour, le script reste plus court à écrire et plus facile à modifier. Si vous avez cinq colonnes corrélées, des validateurs à faire tourner sur chaque ligne et des runs longs qui doivent survivre à une coupure, le cadre apporte ce que le script n'a pas.
Il existe une troisième voie, plus proche de Data Designer sur le plan conceptuel : décrire le schéma dans un format déclaratif et laisser un orchestrateur gérer l'exécution. Là encore, la différence se joue sur les validateurs et la reprise, pas sur la génération.
Conclusion éditoriale
Adoptez Data Designer si votre besoin est un dataset tabulaire où les champs doivent se répondre entre eux, avec des validateurs exécutables et une reprise sur incident en cours de run. Passez votre chemin si vous voulez surtout un pipeline texte vers texte : la couche de colonnes, de fournisseurs et de validateurs devient alors de la plomberie à maintenir pour rien. Avant d'écrire votre schéma, lancez data-designer config providers puis data-designer config list et vérifiez que l'alias de modèle utilisé dans vos LLMTextColumnConfig correspond bien à une configuration résolue ; c'est la cause d'erreur la plus probable au premier essai.
Notes de la communauté