# Recettes de données Unsloth Les Data Recipes d’Unsloth Studio vous permettent de téléverser des documents comme des PDF ou des fichiers CSV et de les transformer en jeux de données utilisables / synthétiques. Créez et modifiez des jeux de données visuellement via un flux de travail en graphe de nœuds. Ce guide vous aidera à prendre en main les bases avant de vous plonger dans Unsloth Data Recipes.

### Comment fonctionnent les Data Recipes Data Recipes suit le même parcours de base. Vous ouvrez la page des recettes, créez ou choisissez une recette, construisez le flux de travail dans l’éditeur, le validez, lancez un aperçu, puis exécutez le jeu de données complet une fois que le résultat vous semble correct. Ajoutez des données de départ et des blocs de génération, validez le flux de travail, prévisualisez un échantillon de sortie, puis lancez la génération complète du jeu de données. Unsloth Data Recipes est propulsé par **NVIDIA Nemo** [**Data Designer**](https://github.com/NVIDIA-NeMo/DataDesigner).

Exemple de génération d’un jeu de données et d’ajustement fin d’un modèle

À première vue, un flux de travail habituel devrait ressembler à ceci : 1. Ouvrez la page des recettes. 2. Créez une nouvelle recette ou ouvrez-en une existante. 3. Ajoutez des blocs pour définir le flux de travail de votre jeu de données. 4. Cliquez sur **Valider** pour détecter rapidement les problèmes de configuration. 5. Lancez un aperçu pour inspecter rapidement des lignes d’exemple. 6. Lancez la génération complète du jeu de données lorsque la recette est prête. 7. Consultez la progression et la sortie en direct dans le graphe ou dans la vue **Exécutions** pour plus de détails sur le mode. 8. Sélectionnez le jeu de données الناتant dans **Studio** et ajustez finement un modèle. ### Commencer La page des recettes est le point d’entrée principal. Les recettes sont stockées localement dans le navigateur, ce qui vous permet de reprendre plus tard votre travail enregistré. Depuis ici, vous pouvez créer une recette vide ou ouvrir une recette d’apprentissage guidée. {% hint style="info" %} Les recettes peuvent être exportées et importées, ce qui facilite le partage de flux de travail avec d’autres utilisateurs d’Unsloth :tada:. Si vous essayez de créer un schéma de jeu de données spécifique, demandez sur le Discord d’Unsloth. Quelqu’un a peut-être déjà une recette à partager. {% endhint %}

Si vous débutez avec le concept de flux de travail, les recettes d’apprentissage sont le moyen le plus rapide de voir comment les données de départ, les prompts, les expressions et les validateurs s’articulent dans un exemple fonctionnel. Si vous connaissez déjà la forme du jeu de données que vous voulez, commencer de zéro est généralement plus rapide. #### Choisissez un point de départ

Si vous voulez :	Commencez avec :
_{Construire rapidement un flux de travail personnalisé}	_{Commencer à vide}
_{Apprendre le produit à partir d’un exemple}	_{Commencer à partir d’une recette d’apprentissage}
_{Poursuivre le travail précédent}	_{Ouvrir une recette enregistrée}

### Ce que vous construisez dans l’éditeur L’éditeur est l’endroit où la recette prend forme. Vous ajoutez des blocs depuis la feuille de blocs, les configurez dans des boîtes de dialogue, les reliez sur le canevas, puis vous validez ou exécutez le flux de travail.

Exemple de création d’un flux de travail de description de produit

{% columns %} {% column %} L’éditeur comporte რამდენიმე éléments essentiels : * L’en-tête de la recette, où vous renommez la recette et basculez entre **Éditeur** et **Exécutions** * Le canevas, où le graphe de la recette est affiché * La feuille de blocs, où vous ajoutez de nouveaux blocs * Les boîtes de dialogue de configuration, où vous définissez les prompts, les références, les alias de modèle, les validateurs et les paramètres de départ. * Le panneau flottant **Exécuter** et **Valider** contrôles * need to add more here {% endcolumn %} {% column %} Les blocs les plus courants dans les recettes sont : * **Données de départ** pour les données d’entrée provenant de Hugging Face, de fichiers locaux structurés (ou de documents non structurés découpés en lignes. * **LLM + Modèles** pour les fournisseurs, les configurations de modèle, les blocs de génération LLM et les profils d’outils partagés. * **Expression** pour les transformations basées sur Jinja2 qui ne nécessitent pas d’appel à un LLM. * **Validateurs** pour filtrer le mauvais code généré avec des linters intégrés pour Python, SQL et JavaScript/TypeScript. * **Échantillonneurs** pour des colonnes déterministes telles que les catégories et sous-catégories. {% endcolumn %} {% endcolumns %} ### Comment fonctionnent les références La plupart des blocs qui produisent des données (à quelques exceptions près) deviennent une référence pour les blocs ultérieurs. C’est l’une des idées principales derrière Data Recipes. Vous créez une valeur une fois, puis vous la réutilisez dans les prompts, les expressions, les sorties structurées et les étapes de validation. {% hint style="info" %} Les expressions Jinja vous aident à travailler avec des valeurs qui existent déjà dans la recette. Vous pouvez faire référence à des champs imbriqués comme `{{customer.first_name}}` , combiner des valeurs comme `{{customer.first_name}} {{customer.last_name}}` et ajouter une logique conditionnelle avec des modèles tels que `{% if condition %}...{% endif %}` {% endhint %}

Exemple de références affichées dans l’éditeur

Par exemple : * Un bloc de catégorie nommé `domaine` peut être référencé comme `{{ domain }}` * une colonne de données de départ peut être utilisée directement dans un prompt LLM, les colonnes de vos données de départ (par ex. colonnes d’un jeu de données HF, csv) * une sortie LLM structurée peut exposer des champs pour des prompts ultérieurs * un bloc d’expression peut combiner des valeurs précédentes sans appel supplémentaire au modèle ### Que se passe-t-il ensuite ? Les exécutions d’aperçu servent à itérer rapidement. Elles renvoient des lignes d’échantillon et une analyse dans l’éditeur afin que vous puissiez inspecter les données générées avant de lancer une exécution complète. Les exécutions complètes créent un artefact de jeu de données local persistant. Cette sortie apparaît ensuite dans le sélecteur de jeux de données locaux de Studio, où vous pouvez la réinspecter et l’utiliser pour l’ajustement fin. En option, vous pouvez publier votre jeu de données dans votre dépôt Hugging Face. ### Blocs de construction essentiels {% columns %} {% column %}

{% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} #### La configuration du modèle est divisée en deux couches utilisables : * **Fournisseur de modèle** définit le point de terminaison et l’authentification * **Configuration du modèle** définit le nom du modèle et les paramètres d’inférence Cette configuration fonctionne avec des fournisseurs hébergés, des points de terminaison auto-hébergés, `vLLM` , `llama.cpp` , ou toute API compatible OpenAI que vous exécutez en dehors de Studio. {% hint style="info" %} Les recettes ne sont pas limitées à un seul modèle. Vous pouvez ajouter plusieurs **Fournisseurs de modèles** et **blocs de configuration de modèle** puis utiliser différents modèles pour différentes étapes, par exemple un pour le code et un autre pour les tâches de texte général. {% endhint %} Après la configuration du modèle, vous pouvez utiliser quatre types de blocs LLM : | Bloc | Sortie | Idéal pour | | ------------- | --------------------- | -------------------------------------------------------------------------- | | Texte LLM | Texte libre | Instructions, explications, conversations et descriptions | | LLM structuré | JSON | Sortie nécessitant des champs fixes et une structure prévisible | | Code LLM | Code | Python, SQL, TypeScript et autres tâches de génération de code | | LLM juge | Évaluation avec score | Notation des sorties avec un ou plusieurs scores définis par l’utilisateur | #### Profils d’outils {% columns %} {% column %} Les blocs de profil d’outil définissent un accès partagé aux outils basés sur MCP pour un ou plusieurs blocs LLM. Utilisez-les lorsqu’une étape de génération nécessite des outils, par exemple pour consulter la documentation d’un code via `Context7`. L’image de gauche montre Context7 MCP ajouté et configuré dans la boîte de dialogue du bloc Profil d’outil : {% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} #### Validateurs {% columns %} {% column %} Le bloc Validateur cible principalement les blocs de code LLM en faisant passer les sorties de code générées par un linter et une validation de syntaxe ; cela vous aide à conserver le code erroné ou invalide hors du jeu de données final en le filtrant. Les options intégrées couvrent la validation Python, SQL et JavaScript/TypeScript. {% endcolumn %} {% column %}

{% endcolumn %} {% endcolumns %} ### Valider, prévisualiser et exécuter Une fois le flux de travail de la recette en place, l’étape suivante est l’exécution. Le schéma recommandé est : valider d’abord, prévisualiser pour obtenir un retour rapide et inspecter les données générées dans la vue des exécutions, puis exécuter le jeu de données complet lorsque vous estimez que la sortie correspond à votre plan. Utilisez les contrôles d’exécution dans cet ordre : {% stepper %} {% step %} #### Valider Cliquez sur **Valider** pour détecter les problèmes de configuration. {% endstep %} {% step %} #### Aperçu Lancez un aperçu pour inspecter les lignes d’échantillon et l’analyse {% endstep %} {% step %} #### Affiner Affinez les prompts, les références, les paramètres de départ ou les validateurs. Itérez jusqu’à ce que les données générées vous conviennent {% endstep %} {% step %} #### Lancer la génération complète du jeu de données {% endstep %} {% endstepper %}