subtitles/fr/23_what-is-dynamic-padding.srt

1
00:00:05,270 --> 00:00:07,640
Qu'est-ce que le rembourrage dynamique ?

2
00:00:07,640 --> 00:00:12,620
Dans la vidéo « Regroupement des entrées », nous avons vu que pour pouvoir regrouper des entrées

3
00:00:12,620 --> 00:00:17,320
de différentes longueurs dans le même batch, nous devons ajouter des tokens de rembourrage à toutes les

4
00:00:17,320 --> 00:00:20,520
entrées courtes jusqu'à ce qu'elles aient toutes la même longueur.

5
00:00:20,520 --> 00:00:26,300
Ici par exemple, la phrase la plus longue est la troisième, et nous devons ajouter 5, 2 et

6
00:00:26,300 --> 00:00:32,509
7 tokens [PAD] aux autres pour avoir quatre phrases de même longueur.

7
00:00:32,509 --> 00:00:37,530
Lorsque vous traitez un jeu de données complet, il existe différentes stratégies de rembourrage que nous pouvons appliquer.

8
00:00:37,530 --> 00:00:41,870
La plus évidente consiste à remplir tous les éléments du jeu de données à la même longueur : la longueur

9
00:00:41,870 --> 00:00:44,129
de l'échantillon le plus long.

10
00:00:44,129 --> 00:00:48,450
Cela nous donnera alors des batchs qui ont tous la même forme déterminée par la longueur maximale de la séquence

11
00:00:48,450 --> 00:00:49,450
.

12
00:00:49,450 --> 00:00:54,039
L'inconvénient est que les batchs composés de phrases courtes auront beaucoup de tokens de rembourrage

13
00:00:54,039 --> 00:01:00,080
qui introduisent plus de calculs dans le modèle dont nous n'avons finalement pas besoin.

14
00:01:00,080 --> 00:01:05,320
Pour éviter cela, une autre stratégie consiste à remplir les éléments lorsque nous les regroupons,

15
00:01:05,320 --> 00:01:08,240
jusqu'à la phrase la plus longue à l'intérieur du batch.

16
00:01:08,240 --> 00:01:12,880
De cette façon, les batchs composés d'entrées courtes seront plus petits que le batch contenant

17
00:01:12,880 --> 00:01:15,600
la phrase la plus longue de l'jeu de données.

18
00:01:15,600 --> 00:01:19,090
Cela donnera une belle accélération sur CPU et GPU.

19
00:01:19,090 --> 00:01:23,130
L'inconvénient est que tous les batchs auront alors des formes différentes, ce qui ralentit l'entraînement

20
00:01:23,130 --> 00:01:24,790
sur d'autres accélérateurs comme les TPU.

21
00:01:24,790 --> 00:01:28,850
Voyons comment appliquer les deux stratégies en pratique.

22
00:01:28,850 --> 00:01:34,750
Nous avons en fait vu comment appliquer un rembourrage fixe dans la vidéo « Vue d'ensemble de Datasets », lorsque nous avons prétraité

23
00:01:34,750 --> 00:01:39,320
le jeu de données MRPC. Après avoir chargé le jeu de données et le tokenizer, nous avons appliqué la segmentation

24
00:01:39,320 --> 00:01:45,260
à tous les jeux de données avec rembourrage et tronquez pour que tous les échantillons de longueur 128.

25
00:01:45,260 --> 00:01:51,630
En conséquence, si nous passons ce jeu de données à un PyTorch `DataLoader`, nous obtenons des batchs de

26
00:01:51,630 --> 00:01:57,079
forme `batch_siez` (ici 16) par 128.

27
00:01:57,079 --> 00:02:01,950
Pour appliquer un rembourrage dynamique, nous devons reporter le rembourrage à la préparation du batch, nous supprimons donc

28
00:02:01,950 --> 00:02:04,789
cette partie de notre `tokenize_fonction`.

29
00:02:04,789 --> 00:02:08,569
Nous laissons toujours la partie troncature afin que les entrées qui sont plus grandes que la longueur maximale

30
00:02:08,569 --> 00:02:14,069
acceptée par le modèle (généralement 512) soient tronquées à cette longueur.

31
00:02:14,069 --> 00:02:17,629
Ensuite, nous remplissons nos échantillons dynamiquement en utilisant un assembleur de données.

32
00:02:17,629 --> 00:02:22,110
Ces classes de la bibliothèque Transformers sont chargées d'appliquer tout le

33
00:02:22,110 --> 00:02:27,970
traitement final nécessaire avant de former un batch. Ici `DataCollatorWithPadding` remplira les

34
00:02:27,970 --> 00:02:32,200
échantillons à la longueur maximale à l'intérieur du batch de phrases.

35
00:02:32,200 --> 00:02:36,790
Nous le transmettons au `DataLoader` de PyTorch en tant que fonction d'assemblement, puis observons que les batchs

36
00:02:36,790 --> 00:02:42,950
générés ont des longueurs différentes, bien en dessous des 128 d'avant.

37
00:02:42,950 --> 00:02:48,200
Le traitement par batchs dynamique sera presque toujours plus rapide sur CPU et GPU, vous devez donc l'appliquer si

38
00:02:48,200 --> 00:02:49,200
vous le pouvez.

39
00:02:49,200 --> 00:02:53,879
N'oubliez pas de revenir au rembourrage fixe si vous exécutez votre script d'entraînement sur TPU ou si vous avez

40
00:02:53,879 --> 00:03:00,599
besoin de batchs de formes fixes.