Avant de commencer

N'explorez pas l'espace de travail dans un premier temps. L'étape « Apprendre » du workflow vous fournit tout ce dont vous avez besoin.

Objectif

Créer un ensemble de données synthétiques à l’aide de la bibliothèque Data Designer, correspondant à la description suivante :

$ARGUMENTS

Workflow

Utilisez le mode Autopilot si l'utilisateur laisse entendre qu'il ne souhaite pas répondre aux questions — par exemple, s'il dit quelque chose comme « faites preuve d'initiative », « c'est vous qui décidez », « faites des hypothèses raisonnables », « créez-le simplement », « surprenez-moi », etc. Sinon, utilisez le mode interactif (par défaut).

Lisez uniquement le fichier de workflow correspondant au mode sélectionné, puis suivez-le :

• Interactif → lire workflows/interactive.md
• Pilote automatique → lire workflows/autopilot.md

Règles

• Conservez toutes les colonnes dans la sortie par défaut. Les seules exceptions justifiant la suppression d’une colonne sont : (1) l’utilisateur le demande explicitement, ou (2) il s’agit d’une colonne auxiliaire qui existe uniquement pour dériver d’autres colonnes (par exemple, un objet « personne » échantillonné utilisé pour extraire le nom, la ville, etc.). En cas de doute, conservez la colonne.
• Ne suggérez pas et ne posez pas de questions concernant les ensembles de données de départ. N’en utilisez un que lorsque l’utilisateur fournit explicitement des données de départ ou demande de créer un ensemble à partir d’enregistrements existants. Lorsque vous utilisez un ensemble de données de départ, lisez references/seed-datasets.md.
• Lorsque le jeu de données nécessite des données sur des personnes (noms, données démographiques, adresses), lisez references/person-sampling.md.
• Si un script de jeu de données correspondant à la description du jeu de données existe déjà, demandez à l’utilisateur s’il souhaite le modifier ou en créer un nouveau.
• Pour les commandes et le contexte spécifiques à ce plugin de la plateforme NeMo (par exemple, l’obtention de configurations de modèles auprès de fournisseurs IGW ou de ModelConfig, l’installation ou la publication de locales Nemotron Personas, les pointeurs de ressources côté plateforme), consultez references/nemo-platform-plugin-additions.md.

Conseils d’utilisation et pièges courants

• Les colonnes d’échantillonnage et de validation nécessitent à la fois un type et des paramètres. Par exemple, sampler_type="category" avec params=dd.CategorySamplerParams(...).
• les modèles Jinja2 dans prompt, system_prompt, et expr champs : les colonnes de référence comportant {{ column_name }}, les champs imbriqués avec {{ column_name.field }}.
• **SamplerColumnConfig:** Prend params, et non sampler_params.
• accès aux notes des juges LLM : LLMJudgeColumnConfig produit un dictionnaire imbriqué où chaque nom de note correspond à {reasoning: str, score: int}. Pour obtenir la note numérique, utilisez l’ .score . Par exemple, pour une colonne de juge nommée quality et dont la note s’appelle correctness, utilisez {{ quality.correctness.score }}. La fonction {{ quality.correctness }} renvoie le dictionnaire complet, et non la note numérique.

Dépannage

• **nemo data-designer CLI introuvable :** Indiquez à l'utilisateur que nemo data-designer n’est pas installé dans cet environnement (nécessite Python >= 3.11). Demandez-lui si vous devez créer un environnement virtuel et l’installer, ou s’il préfère le faire lui-même. N’installez rien sans l’autorisation de l’utilisateur.
• Erreurs réseau pendant l’aperçu : un environnement sandbox peut bloquer les requêtes sortantes. Demandez à l’utilisateur l’autorisation de réessayer la commande avec le sandbox désactivé. En dernier recours uniquement, si la nouvelle tentative en dehors du sandbox échoue également, demandez à l’utilisateur d’exécuter la commande lui-même.

Modèle de sortie

Écrivez un fichier Python dans le répertoire courant contenant une load_config_builder() fonction renvoyant un DataDesignerConfigBuilder. Donnez au fichier un nom descriptif (par exemple, customer_reviews.py). Utilisez les métadonnées en ligne conformes à la PEP 723 pour les dépendances.

# /// script
# dependencies = [
#   "data-designer", # always required
#   "pydantic", # only if this script imports from pydantic
#   # add additional dependencies here
# ]
# ///
import data_designer.config as dd
from pydantic import BaseModel, Field


# Use Pydantic models when the output needs to conform to a specific schema
class MyStructuredOutput(BaseModel):
    field_one: str = Field(description="...")
    field_two: int = Field(description="...")


# Use custom generators when built-in column types aren't enough
@dd.custom_column_generator(
    required_columns=["col_a"],
    side_effect_columns=["extra_col"],
)
def generator_function(row: dict) -> dict:
    # add custom logic here that depends on "col_a" and update row in place
    row["name_in_custom_column_config"] = "custom value"
    row["extra_col"] = "extra value"
    return row


def load_config_builder() -> dd.DataDesignerConfigBuilder:
    config_builder = dd.DataDesignerConfigBuilder(
        # Declaring model configs programmatically here is the portable path:
        # it works for both local `run` and cluster `submit`, while the local
        # YAML registry alternative only works for `run`. The provider below
        # is a common default created during `nemo setup` — confirm it (or
        # discover others) with `nemo inference providers list`. See
        # references/nemo-platform-plugin-additions.md for the local-YAML alternative.
        model_configs=[
            dd.ModelConfig(
                alias="text",
                model="...",
                provider="default/nvidia-build",
                inference_parameters=dd.ChatCompletionInferenceParams(),
            ),
        ],
    )

    # Seed dataset (only if the user explicitly mentions a seed dataset path)
    # config_builder.with_seed_dataset(dd.LocalFileSeedSource(path="path/to/seed.parquet"))

    # config_builder.add_column(...)
    # config_builder.add_processor(...)

    return config_builder

N'incluez les modèles Pydantic, les générateurs personnalisés, les ensembles de données de départ et les dépendances supplémentaires que lorsque la tâche l'exige. Privilégiez l'inclusion model_configs lorsque le jeu de données utilise des colonnes LLM — le fait de le déclarer dans le script garantit la portabilité de la configuration entre les environnements locaux run et le cluster submit, alors que l'alternative du registre YAML local ne fonctionne que pour run.