Curation de Dataset

Cette skill suppose que finetuning-method-selection a déjà routé ici — l'étape suivante est la préparation des données, non le choix d'une méthode. Ce qui suit : sélection du format selon la méthode cible, la mécanique de template/packing derrière les défaillances d'entraînement les plus courantes et silencieuses, règles pour mélanger les données synthétiques sans effondrement, et la dataset card qui clôt la Phase 2 avant un lancement.

Input : exemples bruts (démonstrations, jugements de préférence ou prompts de tâche) plus une décision de routage depuis finetuning-method-selection. Output format : un dataset JSONL formaté, packed et validé, plus une dataset card complétée — l'artefact Phase 2 que /finetune vérifie avant de lancer l'entraînement.

Sélection du Format

Méthode	Shape	Lignes
SFT, single-turn	Instruct (`instruction`/`response` ou `prompt`/`completion`)	~1 000+ minimum
SFT, multi-turn	Conversation / ChatML liste `messages`	~1 000+ minimum
DPO / ORPO	Paire de préférence (`prompt`, `chosen`, `rejected`)	Dépendant de la méthode, voir `preference-optimization`
KTO	Non-appairée (`prompt`, `completion`, `label`)	Dépendant de la méthode, voir `preference-optimization`
GRPO / RLVR	Prompt uniquement (`prompt` + métadonnées verifier)	Dépendant de la méthode, voir `grpo-rlvr-training`

~1 000+ lignes est le minimum recommandé pour SFT, non une cible. En-dessous, une poignée d'exemples de faible qualité ou dupliqués peuvent dominer le gradient ; au-delà, qualité plutôt que quantité — un ensemble plus petit vérifié et dédupliqué bat un plus grand bruyant.
La shape ChatML, pour l'orientation ; les quatre autres formats plus une note de conversion ShareGPT vivent dans references/formats-and-templates.md :
```
{"messages": [
  {"role": "user", "content": "..."},
  {"role": "assistant", "content": "..."}
]}
```

Chat Templates et Loss Masking

Appliquez le chat template du modèle cible avant toute concaténation ou packing, jamais après — packer du texte brut et templater le blob packé ensuite corrompt les frontières de tour, plaçant les marqueurs de rôle au mauvais endroit par rapport à chaque exemple.

Entraînez uniquement sur les réponses assistant. Masquez la loss (-100 dans le tenseur labels) sur les tours système/utilisateur et les marqueurs de rôle du template lui-même — seuls les tokens de contenu de tour assistant contribuent à la loss.
Les désaccords template/tokenizer sont un mode de défaillance silencieuse majeur. Un modèle entraîné contre un chat template mais servi ou évalué avec un différent se dégrade sans erreur. Vérifiez que la même chaîne de template utilisée à l'entraînement est appliquée au moment de l'inférence et de l'eval.
Gardez le dataset en shape messages et laissez le trainer le templater et le masquer (assistant_only_loss=True dans TRL actuel) — pré-rendre dans un champ texte plat détruit les frontières de tour dont le masking a besoin. Sketch de code complet : references/formats-and-templates.md. Vérification avant entraînement — décoder uniquement les positions non-masquées ; attendez-vous à du texte assistant uniquement :
```
keep = batch["labels"][0] != -100
print(tokenizer.decode(batch["input_ids"][0][keep]))
```

Packing

Sans packing, 40–70% du calcul est dépensé en padding — des exemples de longueur variable batchés à une longueur de séquence fixe gaspillent l'écart entre la longueur de chaque exemple et le maximum du batch. Le packing concatène plusieurs exemples dans une séquence jusqu'à la longueur max, coupant la plupart de ce gaspillage.

Le packing change la sémantique du batch. Une séquence packée peut contenir plusieurs exemples originaux, donc les "étapes par époque" et tout planning de LR basé sur le compte d'exemples changent une fois le packing activé — recalculez les jalons du planning par rapport au compte de séquences packées.
OBLIGATOIRE : décoder et inspecter manuellement 5–10 séquences packées avant d'escalader à une exécution complète. Confirmez que les frontières d'exemples se trouvent où attendu, les marqueurs de template sont intacts par sous-exemple, et le masque de loss est toujours assistant-only dans chaque séquence packée. Non optionnel — les bugs de packing sont silencieux (la courbe de loss a l'air normale) et ne remontent à la surface qu'à l'eval, des heures plus tard :
```
for seq in packed_dataset.select(range(10)):
    print(tokenizer.decode(seq["input_ids"]))
```

Règles de Données Synthétiques

Conservez ≥25% de données réelles comme garde contre l'effondrement. L'entraînement sur une part croissante de données générées par le modèle sans plancher de données réelles provoque un effondrement de qualité mesurable au fil des générations — 25% réel est le minimum qui tient la ligne. Les lignes de replay de domaine général comptent vers ce plancher — « réel » signifie « non généré pour cette tâche de cet étudiant », non « créé par humain ». Un dataset entièrement synthétique par construction peut atteindre le plancher ≥25% par le seul replay (voir la recette Replay-Mix Construction dans references/synthetic-data.md) ; déclarez quelles lignes comptent comme « réelles » dans la dataset card plutôt que de laisser le plancher structurellement inaccessible.
Magpie et rejection sampling sont les chevaux de trait. Magpie extrait les prompts du prior du template du modèle ; rejection sampling génère plusieurs candidats par prompt et ne garde que ceux qu'un filtre approuve. Les deux battent la génération naïve simple.
La génération ciblée et aware-étudiant bat la génération statique de 1,3–2x en efficacité d'échantillon — viser les modes de défaillance réels de l'étudiant atteint une barre de qualité avec moins d'exemples filtrés.
Les taux d'acceptation typiques après filtrage sont 10–30%. Planifiez le volume en accord — une cible de 10 000 lignes à 15% d'acceptation a besoin ~65 000+ générations brutes.
Classement de méthode de génération, entonnoir de filtre, construction de replay-mix et pattern de distillation : references/synthetic-data.md.

La Dataset Card

Chaque dataset qui atteint l'entraînement reçoit une card — l'artefact Phase 2 obligatoire que /finetune vérifie avant de lancer. La card n'est pas de la documentation libre ; elle DOIT porter ces champs :

Provenance — d'où vient chaque ligne (source(s) réelle(s), méthode(s) synthétique(s), ou les deux), traçable vers la sortie de trace-to-training-data.
Counts — total de lignes, et lignes par split (train/eval/held-out) si split.
Ratio synthétique/réel — le ratio mesuré, vérifié contre le plancher ≥25% réel ci-dessus.
Méthode de dedup — exact-match, sémantique (seuil d'embedding), ou les deux ; voir l'entonnoir de filtre dans references/synthetic-data.md.
Template utilisé — la chaîne/identifiant exact du chat template, gardé cohérent à travers l'inférence et l'eval — c'est ce qui lie une exécution eval-harness-first au checkpoint.
Packing config — si le packing a été utilisé, longueur de séquence max, et confirmation que l'inspection manuelle 5–10-séquences ci-dessus a été effectuée.

Un dataset manquant l'un de ces six champs n'est pas prêt pour /finetune — la card est une porte, non un résumé écrit après coup.

Checklist Phase 2 Exit

Avant de passer à /finetune, confirmez :

Le format correspond à la méthode (tableau ci-dessus).
Template appliqué avant concaténation.
Loss masquée sur les tours assistant uniquement.
5–10 séquences packées décodées et lues.
≥25% de données réelles dans le mélange final.
Dataset card complète — les six champs.

Références

references/formats-and-templates.md — exemples JSONL par format, code de masking TRL actuel, et la note de conversion ShareGPT.
references/synthetic-data.md — classement de méthode de génération, entonnoir de filtre, construction de replay-mix, et pattern de distillation teacher→student.

Skills connexes : finetuning-method-selection route ici ; lora-qlora-recipes, vision-sft, et preference-optimization consomment les datasets que cette skill produit ; trace-to-training-data est la source de provenance pour les datasets de graded-trajectory ; eval-harness-first note le checkpoint résultant.

dataset-curation