1
00:00:05,520 --> 00:00:09,360
Dans cette vidéo, nous examinons le traitement des données nécessaire pour entraîner

2
00:00:09,360 --> 00:00:15,920
des modèles de langage causal. La modélisation du langage causal consiste à prédire le token suivant en fonction

3
00:00:15,920 --> 00:00:20,880
du token précédent. Un autre terme pour la modélisation du langage causal est la modélisation autorégressive.

4
00:00:21,760 --> 00:00:26,560
Dans l'exemple que vous voyez ici, le token suivant pourrait par exemple être « NLP »

5
00:00:26,560 --> 00:00:33,280
ou « apprentissage automatique ». Un exemple populaire de modèle de langage causal est la famille de modèles GPT.

6
00:00:35,680 --> 00:00:40,400
Pour entraîner des modèles tels que GPT-2, nous commençons généralement avec un grand corpus de fichiers texte.

7
00:00:41,280 --> 00:00:45,760
Ces fichiers peuvent être des pages Web extraites d'Internet, telles que le jeu de données Common Crawl,

8
00:00:45,760 --> 00:00:51,920
ou des fichiers Python de GitHub, comme vous pouvez le voir ici. Dans un premier temps, nous devons tokeniser

9
00:00:51,920 --> 00:00:57,520
ces fichiers afin de pouvoir les donner au modèle. Ici, nous montrons les textes tokenisés sous forme de barres de

10
00:00:57,520 --> 00:01:06,000
illustrant qu'ils y en a des longs et des courts. Ceci est trian commun lorsque l'on travail avec du texte.

11
00:01:06,000 --> 00:01:07,440
Cependant les transformers ont une

12
00:01:07,440 --> 00:01:12,960
longueur de contexte limitée et, selon la source de données, il est possible que les textes tokenisés

13
00:01:12,960 --> 00:01:18,640
soient beaucoup plus longs que cette longueur de contexte. Dans ce cas, nous pourrions simplement tronquer la séquence

14
00:01:18,640 --> 00:01:24,160
à la longueur du contexte, mais cela signifierait que nous perdons tout après la longueur du contexte.

15
00:01:25,360 --> 00:01:30,960
À l'aide de `return_overflowing_tokens`, nous pouvons utiliser le tokenizer pour créer des morceaux

16
00:01:30,960 --> 00:01:36,960
chacun étant de la taille de la longueur du contexte. Parfois, il peut arriver que le dernier morceau soit

17
00:01:36,960 --> 00:01:41,440
trop court s'il n'y a pas assez de tokens pour le remplir. Dans ce cas, nous aimerions le supprimer.

18
00:01:43,440 --> 00:01:48,800
Avec le mot-clé `return_length`, nous obtenons également la longueur de chaque bloc du tokenizer.

19
00:01:51,760 --> 00:01:57,280
Cette fonction affiche toutes les étapes nécessaires pour préparer le jeu de données. D'abord, nous tokenisons le

20
00:01:57,280 --> 00:02:03,520
jeu de données avec les indicateurs que je viens de mentionner. Ensuite, nous parcourons chaque morceau et si sa longueur correspond à

21
00:02:03,520 --> 00:02:08,960
la longueur du contexte, nous l'ajoutons aux entrées que nous renvoyons. Nous pouvons appliquer cette fonction à l'ensemble du jeu de

22
00:02:08,960 --> 00:02:17,520
données et nous nous assurons d'utiliser des batchs et de supprimer les colonnes existantes. Nous devons supprimer des colonnes

23
00:02:17,520 --> 00:02:23,280
car nous pouvons créer plusieurs échantillons par texte et les formes du jeu de données ne correspondraient pas dans ce cas.

24
00:02:26,960 --> 00:02:32,400
Si la longueur du contexte est similaire à celle des fichiers, cette approche ne fonctionne plus aussi bien.

25
00:02:33,520 --> 00:02:39,440
Dans cet exemple, les échantillons 1 et 2 sont plus courts que la taille du contexte et seraient ignorés avec

26
00:02:39,440 --> 00:02:46,400
l'approche précédente. Dans ce cas, il est préférable de commencer par segmenter chaque échantillon sans troncature

27
00:02:46,400 --> 00:02:52,000
puis de concaténer les échantillons segmentés avec un token de fin de chaîne, ou « EOS », entre les deux.

28
00:02:53,840 --> 00:02:57,440
Enfin, nous pouvons fragmenter cette longue séquence avec la longueur du contexte

29
00:02:57,440 --> 00:03:05,840
et nous ne perdons aucune séquence car elles sont trop courtes. Jusqu'à présent, nous n'avons parlé que

30
00:03:05,840 --> 00:03:10,720
des entrées pour la modélisation du langage causal, mais pas des étiquettes nécessaires à l'entraînement supervisée.

31
00:03:11,600 --> 00:03:16,480
Lorsque nous effectuons une modélisation du langage causal, nous n'avons pas besoin d'étiquettes supplémentaires pour les séquences d'entrée

32
00:03:16,480 --> 00:03:22,080
car les séquences d'entrée elles-mêmes sont les étiquettes. Dans cet exemple, lorsque nous transmettons

33
00:03:22,080 --> 00:03:26,560
le token « Trans » au prochain token que nous voulons que le modèle prédise est « formers ».

34
00:03:27,280 --> 00:03:33,360
À l'étape suivante, nous donnons « Trans » et « formers » au modèle et l'étiquette que nous voulons prédire est « are ».

35
00:03:35,280 --> 00:03:42,400
Ce schéma se poursuit et, comme vous pouvez le voir, la séquence d'entrée est l'étiquette qui vient d'être décalée d'une unité.

36
00:03:43,440 --> 00:03:48,000
Étant donné que le modèle n'effectue une prédiction qu'après le premier token, le premier élément

37
00:03:48,000 --> 00:03:54,480
de la séquence d'entrée, dans ce cas « Trans », n'est pas utilisé comme étiquette. De même, nous n'avons pas

38
00:03:54,480 --> 00:04:00,400
d'étiquette pour le dernier token de la séquence puisqu'il n'y a pas de token après la fin de la séquence.

39
00:04:03,920 --> 00:04:09,200
Voyons ce que nous devons faire pour créer les étiquettes pour la modélisation du langage causal dans le code. Si

40
00:04:10,160 --> 00:04:15,600
nous voulons calculer la perte sur un batch, nous pouvons simplement transmettre les `input_ids` en tant qu'étiquettes et tout le

41
00:04:15,600 --> 00:04:19,432
décalage est géré dans le modèle en interne. 

42
00:04:19,432 --> 00:04:21,600
Donc vous voyez qu'il n'y a pas de magie

43
00:04:21,600 --> 00:04:27,840
impliquée dans le traitement des données pour la modélisation du langage causal et ne nécessite que quelques étapes simples !