Structurez votre dépôt

Pour héberger et partager votre jeu de données, créez un dépôt de jeu de données sur le Hugging Face Hub et téléversez vos fichiers de données.

Ce guide vous montre comment structurer votre dépôt de jeu de données lors de son téléversement. Un jeu de données doté d’une structure et d’un format de fichier pris en charge (.txt, .csv, .parquet, .jsonl, .mp3, .jpg, .zip, etc.) est chargé automatiquement avec load_dataset(), et un visualiseur de jeu de données sera disponible sur sa page de jeu de données sur le Hub.

Cas d'usage principal

La structure de jeu de données la plus simple comporte deux fichiers : train.csv et test.csv (cela fonctionne avec tout format de fichier pris en charge).

Votre dépôt contiendra également un fichier README.md, la fiche de jeu de données affichée sur la page de votre jeu de données.

my_dataset_repository/
├── README.md
├── train.csv
└── test.csv

Dans ce cas simple, vous obtiendrez un jeu de données avec deux sous-ensembles : train (contenant des exemples issus de train.csv) et test (contenant des exemples issus de test.csv).

Définissez vos splits et sous-ensembles dans un fichier YAML

Splits

Si vous avez plusieurs fichiers et souhaitez définir dans quelle partition chaque fichier doit être placé, vous pouvez utiliser le champ configs YAML en haut de votre README.md.

Par exemple, étant donné un dépôt comme celui-ci :

my_dataset_repository/
├── README.md
├── data.csv
└── holdout.csv

Vous pouvez définir vos partitions en ajoutant le champ configs dans le bloc YAML en haut de votre README.md :

---
configs:
- config_name: default
  data_files:
  - split: train
    path: "data.csv"
  - split: test
    path: "holdout.csv"
---

Vous pouvez sélectionner plusieurs fichiers par split en utilisant une liste de chemins :

my_dataset_repository/
├── README.md
├── data/
│   ├── abc.csv
│   └── def.csv
└── holdout/
    └── ghi.csv

---
configs:
- config_name: default
  data_files:
  - split: train
    path:
    - "data/abc.csv"
    - "data/def.csv"
  - split: test
    path: "holdout/ghi.csv"
---

Vous pouvez également utiliser des motifs glob pour lister automatiquement tous les fichiers dont vous avez besoin :

---
configs:
- config_name: default
  data_files:
  - split: train
    path: "data/*.csv"
  - split: test
    path: "holdout/*.csv"
---

Notez que le champ config_name est requis même si vous n'avez qu'une seule configuration.

Configurations

Votre jeu de données peut contenir plusieurs sous-ensembles de données que vous souhaitez pouvoir charger séparément. Dans ce cas, vous pouvez définir une liste de configurations dans le champ configs du fichier YAML :

my_dataset_repository/
├── README.md
├── main_data.csv
└── additional_data.csv

---
configs:
- config_name: main_data
  data_files: "main_data.csv"
- config_name: additional_data
  data_files: "additional_data.csv"
---

Chaque configuration est affichée séparément sur le Hugging Face Hub et peut être chargée en passant son nom comme second paramètre :

from datasets import load_dataset

main_data = load_dataset("my_dataset_repository", "main_data")
additional_data = load_dataset("my_dataset_repository", "additional_data")

Paramètres du constructeur

Non seulement data_files, mais d'autres paramètres spécifiques au builder peuvent être passés via YAML, permettant une plus grande flexibilité sur la manière de charger les données sans nécessiter de code personnalisé. Par exemple, définissez le séparateur à utiliser dans quelle configuration pour charger vos fichiers csv :

---
configs:
- config_name: tab
  data_files: "main_data.csv"
  sep: "\t"
- config_name: comma
  data_files: "additional_data.csv"
  sep: ","
---

Consultez la documentation des constructeurs spécifiques pour voir les paramètres de configuration dont ils disposent.

Vous pouvez définir une configuration par défaut en utilisant default: true, par exemple vous pouvez exécuter main_data = load_dataset("my_dataset_repository") si vous définissez

Copié

- config_name: main_data
  data_files: "main_data.csv"
  default: true

Détection automatique des splits

Si aucun fichier YAML n’est fourni, 🤗 Datasets recherche certains motifs dans le dépôt de jeu de données afin d’inférer automatiquement les splits du jeu de données. Les motifs sont évalués dans un ordre précis, en commençant par le format de split de nom de fichier personnalisé et en traitant tous les fichiers comme un seul split si aucun motif n’est trouvé.

Nom du répertoire

Vos fichiers de données peuvent également être placés dans des répertoires distincts nommés train, test et validation, où chaque répertoire contient les fichiers de données correspondant à cette partition :

my_dataset_repository/
├── README.md
└── data/
    ├── train/
    │   └── bees.csv
    ├── test/
    │   └── more_bees.csv
    └── validation/
        └── even_more_bees.csv

Séparations de noms de fichiers

Si vous n’avez pas de splits non traditionnels, vous pouvez placer le nom du split n’importe où dans le fichier de données et il sera inféré automatiquement. La seule règle est que le nom du split doit être délimité par des caractères non alphanumériques, comme test-file.csv par exemple, plutôt que testfile.csv. Les délimiteurs pris en charge incluent les tirets bas, les tirets, les espaces, les points et les chiffres.

Par exemple, les noms de fichiers suivants sont tous acceptables :

• train split : train.csv, my_train_file.csv, train1.csv
• ensemble de validation : validation.csv, my_validation_file.csv, validation1.csv
• jeu de test : test.csv, my_test_file.csv, test1.csv

Voici un exemple où tous les fichiers sont placés dans un répertoire nommé data :

my_dataset_repository/
├── README.md
└── data/
    ├── train.csv
    ├── test.csv
    └── validation.csv

Séparation par nom de fichier personnalisé

Si les divisions de votre jeu de données ont des noms personnalisés qui ne sont pas train, test ou validation, vous pouvez nommer vos fichiers de données comme data/<split_name>-xxxxx-of-xxxxx.csv.

Voici un exemple avec trois splits, train, test et random :

my_dataset_repository/
├── README.md
└── data/
    ├── train-00000-of-00003.csv
    ├── train-00001-of-00003.csv
    ├── train-00002-of-00003.csv
    ├── test-00000-of-00001.csv
    ├── random-00000-of-00003.csv
    ├── random-00001-of-00003.csv
    └── random-00002-of-00003.csv

Division unique

Lorsque 🤗 Datasets ne trouve aucun des motifs ci-dessus, il considère tous les fichiers comme une seule partition d’entraînement. Si les partitions de votre jeu de données ne se chargent pas comme prévu, cela peut être dû à un motif incorrect.

Mots-clés de nom de séparation

Il existe plusieurs façons de nommer les partitions. Les partitions de validation sont parfois appelées « dev », et les partitions de test peuvent être désignées par « eval ». Ces autres noms de partitions sont également pris en charge, et les mots-clés suivants sont équivalents :

• train, entraînement
• validation, valide, val, dev
• test, testing, eval, evaluation

La structure ci-dessous est un dépôt valide :

my_dataset_repository/
├── README.md
└── data/
    ├── training.csv
    ├── eval.csv
    └── valid.csv

Plusieurs fichiers par split

Si l’une de vos partitions comprend plusieurs fichiers, 🤗 Datasets peut toujours inférer s’il s’agit de la partition d’entraînement, de validation ou de test à partir du nom du fichier. Par exemple, si vos partitions d’entraînement et de test s’étendent sur plusieurs fichiers :

my_dataset_repository/
├── README.md
├── train_0.csv
├── train_1.csv
├── train_2.csv
├── train_3.csv
├── test_0.csv
└── test_1.csv

Assurez-vous que tous les fichiers de votre ensemble train contiennent train dans leur nom (idem pour les ensembles de test et de validation). Même si vous ajoutez un préfixe ou un suffixe à train dans le nom du fichier (comme my_train_file_00001.csv par exemple), 🤗 Datasets peut toujours inférer le split approprié.

Pour plus de commodité, vous pouvez également placer vos fichiers de données dans différents répertoires. Dans ce cas, le nom de la partition est déduit du nom du répertoire.

my_dataset_repository/
├── README.md
└── data/
    ├── train/
    │   ├── shard_0.csv
    │   ├── shard_1.csv
    │   ├── shard_2.csv
    │   └── shard_3.csv
    └── test/
        ├── shard_0.csv
        └── shard_1.csv