Dans beaucoup de nos exemples, vous verrez des assembleurs de données apparaître encore et encore.
Ils sont utilisés à la fois dans les flux de travail PyTorch et TensorFlow, et peut-être même dans JAX, mais personne
ne sait vraiment ce qui se passe dans JAX.
Nous avons une équipe de recherche qui travaille là-dessus, alors peut-être qu'ils nous le diront bientôt.
Mais que sont les assembleurs de données ?
Les assembleurs de données rassemblent les données. Ce n'est pas très utile.
Plus précisément, ils rassemblent une liste d'échantillons dans un seul mini-batch de entraînement.
Pour certaines tâches, l'assembleur de données peut être très simple.
Par exemple, lorsque vous effectuez une classification de séquences, tout ce dont vous avez vraiment besoin de votre assembleur de données,
c'est qu'il rembourre vos échantillons à la même longueur et les concatène en un seul tenseur.
Mais pour d'autres flux de travail, les assembleurs de données peuvent être plus complexes car ils gèrent une partie du
prétraitement nécessaire à cette tâche particulière. Donc quand vous voulez utilisez un assembleur de données,
pour les utilisateurs de PyTorch, vous transmettez généralement le `DataCollator` à votre objet Trainer.
Dans TensorFlow, c'ets un peu différent. Le moyen le plus simple d'utiliser un assembleur de données consiste à le transmettre à la méthode `to_tf_dataset`
de votre jeu de données. Cela vous donne un `tf.dataset` que vous pouvez passer à `fit`.
Vous verrez ces approches utilisées dans les exemples et les notebooks tout au long de ce cours.
Notez que tous nos assembleurs prennent un argument `return_tensors` : vous pouvez le définir sur `"pt"` pour obtenir des
tenseurs PyTorch, `"tf"` pour obtenir des tenseurs TensorFlow ou `"np"` pour obtenir des tableaux Numpy.
Pour des raisons de compatibilité descendante, la valeur par défaut est `"pt"`, donc les utilisateurs de PyTorch n'ont même pas
besoin de définir cet argument la plupart du temps, et sont donc souvent totalement inconscients de l'existence de cette
option.
C'est une leçon précieuse sur la façon dont les bénéficiaires du privilège sont souvent les plus aveugles à son
existence.
Voyons maintenant quelques `DataCollators` spécifiques en action, mais rappelez-vous que si aucun d'
entre eux ne fait ce dont vous avez besoin, vous pouvez toujours écrire le vôtre ! Et ils sont souvent courts.
Tout d'abord, nous verrons les assembleurs de données de base.
Ce sont `DefaultDataCollator` et `DataCollatorWithPadding`.
Ce sont ceux que vous devez utiliser si vos étiquettes sont simples et si vos données ne
nécessitent aucun traitement spécial avant d'être prêtes pour l'entraînement.
Et notez que, comme les différents modèles ont des tokens de rembourrage différents, le collateur de données avec rembourrage aura besoin du tokenizer de votre modèle pour savoir comment rembourrer les séquences correctement.
Le collateur de données par défaut n'a pas besoin d'un tokenizer pour fonctionner mais il produira une erreur si toutes vos séquences ne sont pas de la même longueur.
Vous devez donc être conscient de cela.
Cependant, un grand nombre d'assembleurs de données autres que ceux de base sont généralement conçus pour accomplir une tâche spécifique.
Et donc je vais vous en montrer deux ici, ce sont `DataCollatorForTokenClassification` et `DataCollatorForSeq2Seq`.
Et la raison pour laquelle ces tâches nécessitent des assembleurs spéciaux est que leurs étiquettes sont de longueur variable.
Dans la classification de tokens, il y a une étiquette pour chaque token et donc la longueur des étiquettes est la longueur de la séquence.
Alors qu'en séquence à séquence, les étiquettes sont une séquence de tokens qui peuvent être de longueur variable et très différente de la longueur de la séquence d'entrée.
Dans ces deux cas, nous nous occupons de l'assemblage de ce batch en rembourrant également les étiquettes, comme vous pouvez le voir dans cet exemple.
So inputs and labels will need to be padded.
Si nous voulons réunir des échantillons de longueur variable dans le même mini-batch, c'est toujours le cas pour tous les assembleurs de données et c'est exactement ce que ces assembleurs de données feront pour nous dans le cadre de ces tâches particulières.
Il y a donc un dernier assembleur de données que je veux vous montrer dans cette conférence et c'est le `DataCollatorForLanguageModeling`.
C'est donc très important d'abord parce que les modèles de langage sont tellement fondamentaux pour tout ce que nous faisons en NLP de nos jours.
Ensuite parce qu'il possède deux modes qui font deux choses très différentes.
Vous choisissez donc le mode que vous voulez avec l'argument `mlm`. Mettez-le à `True` pour la modélisation du langage masqué et mettez-le à `False` pour la modélisation du langage causal.
Donc l'assemblage de données pour la modélisation du langage causal est en fait assez simple.
Le modèle fait juste des prédictions sur quel sera le prochain token et donc vos étiquettes sont plus ou moins juste une copie de vos entrées et l'assembleur va gérer cela et s'assurer que les entrées et les étiquettes sont rembourrées correctement.
Cependant, lorsque vous définissez mlm à `True`, vous obtenez un comportement très différent, différent de celui de tout autre assembleur de données.
Et c'est parce que mettre mlm à `True` signifie une modélisation du langage masqué et cela signifie que les étiquettes doivent être masquées.
Alors, à quoi cela ressemble-t-il ?
Rappelez-vous que dans la modélisation du langage masqué, le modèle ne prédit pas le mot suivant, au lieu de cela, nous masquons aléatoirement certains tokens et le modèle les prédit tous en même temps et essaie de remplir les blancs pour ces tokens masqués.
Mais le processus de masquage aléatoire est étonnamment complexe.
Si nous suivons le protocole de l'article original de BERT, nous devons remplacer certains tokens par un token masqué, d'autres tokens par un token aléatoire, puis nous gardons un troisième ensemble de tokens inchangé.
Ce n'est pas le moment d'entrer dans les détails de ce que nous faisons ou pourquoi nous le faisons.
Vous pouvez toujours vérifier l'article original de BERT si vous êtes curieux, il est bien écrit et facile à comprendre.
Ce qu'il faut savoir ici, c'est que la mise en œuvre de ce système par vous-même peut s'avérer très difficile et très complexe.
Mais l'assembleur de données pour la modélisation du langage le fera pour vous si vous mettez mlm à `True` et c'est un exemple de prétraitement plus complexe que certains de nos assembleurs de données font.
Et c'est tout.
Ceci couvre donc les assembleurs de données les plus couramment utilisés et les tâches pour lesquelles ils sont utilisés.
Nous espérons que vous savez maintenant quand utiliser les assembleurs de données et lequel choisir pour votre tâche spécifique.