subtitles/fr/49_what-is-normalization.srt

1
00:00:05,130 --> 00:00:11,060
Dans cette vidéo nous allons voir ensemble quel est le composant normalizer que l'on retrouve au

2
00:00:11,060 --> 00:00:12,240
début de chaque tokenizer.

3
00:00:12,240 --> 00:00:20,610
L'opération de normalisation consiste à appliquer une succession de règles de normalisation au

4
00:00:20,610 --> 00:00:21,960
texte brut.

5
00:00:21,960 --> 00:00:27,510
Nous choisissons des règles de normalisation pour supprimer le bruit dans le texte qui semble inutile pour l'apprentissage

6
00:00:27,510 --> 00:00:31,420
et l'utilisation de notre modèle de langage.

7
00:00:31,420 --> 00:00:40,790
Prenons une phrase très diversifiée avec différentes polices, caractères majuscules et minuscules, accents,

8
00:00:40,790 --> 00:00:48,490
ponctuation et espaces multiples, pour voir comment plusieurs tokenizers la normalisent.

9
00:00:48,490 --> 00:00:55,039
Le tokenizer du modèle FNet a transformé les lettres avec des variantes de police ou encerclées

10
00:00:55,039 --> 00:01:00,230
dans leur version de base et a supprimé les espaces multiples.

11
00:01:00,230 --> 00:01:07,090
Et maintenant si nous regardons la normalisation avec le tokenizer de Retribert, nous pouvons voir qu'il

12
00:01:07,090 --> 00:01:12,990
conserve les caractères avec plusieurs variantes de police et conserve les multiples espaces mais il supprime

13
00:01:12,990 --> 00:01:15,659
tous les accents.

14
00:01:15,659 --> 00:01:23,050
Et si nous continuons à tester la normalisation de nombreux autres tokenizers associés à des modèles

15
00:01:23,050 --> 00:01:34,079
que vous pouvez trouver sur le Hub, nous pouvons voir qu'ils proposent également d'autres normalisations.

16
00:01:34,079 --> 00:01:39,310
Avec les tokenizers rapides, il est très facile d'observer la normalisation choisie pour le

17
00:01:39,310 --> 00:01:42,500
tokenizer actuellement chargé.

18
00:01:42,500 --> 00:01:49,250
En effet, chaque instance d'un fast tokenizer a un tokenizer sous-jacent de la

19
00:01:49,250 --> 00:01:54,820
bibliothèque Tokenizers stocké dans l'attribut backend_tokenizer.

20
00:01:54,820 --> 00:02:01,070
Cet objet possède lui-même un attribut normalizer que nous pouvons utiliser grâce à la méthode `normalize_str`

21
00:02:01,070 --> 00:02:04,670
pour normaliser une chaîne.

22
00:02:04,670 --> 00:02:11,000
Il est donc très pratique que cette normalisation qui a été utilisée lors de l'apprentissage

23
00:02:11,000 --> 00:02:17,870
du tokenizer ait été sauvegardée et qu'elle s'applique automatiquement lorsque vous demandez à un tokenizer entraîné

24
00:02:17,870 --> 00:02:21,120
de tokeniser un texte.

25
00:02:21,120 --> 00:02:28,130
Par exemple, si nous n'avions pas inclus le tokenizer albert, nous aurions eu beaucoup de

26
00:02:28,130 --> 00:02:35,870
tokens inconnus en tokenisant cette phrase avec des accents et des majuscules.

27
00:02:35,870 --> 00:02:40,319
Ces transformations peuvent aussi être indétectables avec un simple « print ».

28
00:02:40,319 --> 00:02:46,069
En effet, gardez à l'esprit que pour un ordinateur, le texte n'est qu'une succession de 0 et de 1 et il

29
00:02:46,069 --> 00:02:51,230
arrive que des successions différentes de 0 et de 1 rendent le même caractère.

30
00:02:51,230 --> 00:02:57,459
Les 0 et les 1 vont par groupes de 8 pour entraîner un octet.

31
00:02:57,459 --> 00:03:04,490
L'ordinateur doit alors décoder cette séquence d'octets en une séquence de « points de code ».

32
00:03:04,490 --> 00:03:10,959
Dans notre exemple, les 2 octets sont transformés en un seul « point de code » par UTF-8.

33
00:03:10,959 --> 00:03:18,860
La norme unicode permet alors de trouver le caractère correspondant à ce « point de code » :

34
00:03:18,860 --> 00:03:22,140
la cédille c.

35
00:03:22,140 --> 00:03:28,060
Répétons la même opération avec cette nouvelle séquence composée de 3 octets, cette fois

36
00:03:28,060 --> 00:03:34,450
elle est transformée en 2 « point de code », ce  qui correspondent aussi au caractère c cédille !

37
00:03:34,450 --> 00:03:41,510
Il s'agit en fait de la composition de la lettre minuscule latine C unicode et de la cédille combinatoire.

38
00:03:41,510 --> 00:03:47,819
Mais c'est embêtant car ce qui nous apparaît comme un personnage unique n'est pas du tout

39
00:03:47,819 --> 00:03:52,379
la même chose pour l'ordinateur.

40
00:03:52,379 --> 00:04:02,269
Heureusement, il existe des normes de normalisation unicode connues sous le nom de NFC, NFD, NFKC et NFKD

41
00:04:02,269 --> 00:04:05,430
qui permettent d'effacer certaines de ces différences.

42
00:04:05,430 --> 00:04:10,019
Ces standards sont souvent utilisés par les tokenizers !

43
00:04:10,019 --> 00:04:15,239
Sur tous ces exemples précédents, même si les normalisations changeaient l'apparence du texte,

44
00:04:15,239 --> 00:04:21,229
elles ne changeaient pas le contenu : on pouvait toujours lire « Hello world, normalize this

45
00:04:21,229 --> 00:04:22,540
phrase ».

46
00:04:22,540 --> 00:04:30,120
Cependant, il faut être conscient que certaines normalisations peuvent être très néfastes si elles ne sont pas adaptées

47
00:04:30,120 --> 00:04:31,720
à leur corpus.

48
00:04:31,720 --> 00:04:37,360
Par exemple, si vous prenez la phrase française « un père indigné »

49
00:04:37,360 --> 00:04:45,660
et que vous la normalisez avec le tokenizer bert-base-uncase qui supprime les accents, la

50
00:04:45,660 --> 00:04:53,550
phrase devient « un père indigne ».

51
00:04:53,550 --> 00:04:58,699
Si vous regardez cette vidéo pour construire votre propre tokenizer, il n'y a pas de règles absolues pour

52
00:04:58,699 --> 00:05:04,580
choisir ou non une normalisation pour votre tout nouveau tokenizer mais je vous conseille de prendre le

53
00:05:04,580 --> 00:05:15,960
temps de les sélectionner afin qu'ils ne vous fassent pas perdre des informations importantes.