subtitles/fr/47_inside-the-question-answering-pipeline-(pytorch).srt

1
00:00:04,130 --> 00:00:08,390
Jetons un coup d'œil à l'intérieur du pipeline de de réponse aux questions.

2
00:00:08,390 --> 00:00:12,630
Le pipeline de réponse aux questions peut extraire les réponses aux questions d'un contexte

3
00:00:12,630 --> 00:00:18,150
ou d'un passage de texte donné, comme cette partie du README du dépôt Transformers.

4
00:00:18,150 --> 00:00:22,440
Cela fonctionne aussi pour des contextes très longs, même si la réponse est à la toute fin, comme dans

5
00:00:22,440 --> 00:00:23,440
cet exemple.

6
00:00:23,440 --> 00:00:24,680
Dans cette vidéo, nous allons voir pourquoi !

7
00:00:24,680 --> 00:00:31,540
Le pipeline de réponse aux questions suit les mêmes étapes que les autres pipelines : la question

8
00:00:31,540 --> 00:00:36,380
et le contexte sont tokenisés sous la forme d'une paire de phrases, transmis au modèle, puis un post-traitement

9
00:00:36,380 --> 00:00:37,649
est appliqué.

10
00:00:37,649 --> 00:00:41,790
Les étapes de tokenisation et de modèle doivent être familières.

11
00:00:41,790 --> 00:00:47,020
Nous utilisons la classe automatique adaptée à la réponse aux questions au lieu de la classification de séquence,

12
00:00:47,020 --> 00:00:52,039
mais une différence clé avec la classification de texte est que notre modèle génère deux tenseurs nommés

13
00:00:52,039 --> 00:00:54,559
logits de début et logits de fin.

14
00:00:54,559 --> 00:00:55,559
Pourquoi donc?

15
00:00:55,559 --> 00:00:59,850
Eh bien, c'est ainsi que le modèle trouve la réponse à la question.

16
00:00:59,850 --> 00:01:02,270
Examinons d'abord les entrées du modèle.

17
00:01:02,270 --> 00:01:07,160
Il s'agit de chiffres associés à la tokenisation de la question suivis du contexte (avec

18
00:01:07,160 --> 00:01:10,710
les tokens spéciaux habituels [CLS] et [SEP]).

19
00:01:10,710 --> 00:01:13,310
La réponse fait partie de ces tokens.

20
00:01:13,310 --> 00:01:17,759
Nous demandons donc au modèle de prédire quel token commence la réponse et lequel termine la réponse.

21
00:01:17,759 --> 00:01:24,380
Pour nos deux sorties logit, les étiquettes théoriques sont les vecteurs rose et violet.

22
00:01:24,380 --> 00:01:28,360
Pour convertir ces logits en probabilités, nous devrons appliquer une SoftMax, comme dans le

23
00:01:28,360 --> 00:01:30,439
pipeline de classification de texte.

24
00:01:30,439 --> 00:01:35,070
Nous masquons simplement les tokens qui ne font pas partie du contexte avant de le faire, laissant

25
00:01:35,070 --> 00:01:41,009
le token [CLS] initial démasqué car nous l'utilisons pour prédire une réponse impossible.

26
00:01:41,009 --> 00:01:43,579
Voici à quoi cela ressemble en termes de code.

27
00:01:43,579 --> 00:01:47,729
On utilise un grand nombre négatif pour le masquage, puisque son exponentielle sera alors 0.

28
00:01:47,729 --> 00:01:53,610
Maintenant la probabilité pour chaque position de début et de fin correspondant à une réponse possible,

29
00:01:53,610 --> 00:01:57,600
on donne un score qui est le produit des probabilités de début et des probabilités de fin

30
00:01:57,600 --> 00:02:00,180
à ces positions.

31
00:02:00,180 --> 00:02:05,430
Bien entendu, un indice de début supérieur à un indice de fin correspond à une réponse impossible.

32
00:02:05,430 --> 00:02:08,940
Voici le code pour trouver le meilleur score pour une réponse possible.

33
00:02:08,940 --> 00:02:13,070
Une fois que nous avons les positions de début et de fin des tokens, nous utilisons l'association de décalage fournis

34
00:02:13,070 --> 00:02:18,270
par notre tokenizer pour trouver la plage de caractères dans le contexte initial et obtenir notre réponse !

35
00:02:18,270 --> 00:02:23,820
Désormais, lorsque le contexte est long, il peut être tronqué par le tokenizer.

36
00:02:23,820 --> 00:02:29,099
Cela pourrait entraîner une partie de la réponse, ou pire, la réponse entière, étant tronquée.

37
00:02:29,099 --> 00:02:33,319
Nous ne supprimons donc pas les tokens tronqués, mais construisons de nouvelles caractéristiques avec eux.

38
00:02:33,319 --> 00:02:39,320
Chacune de ces caractéristiques contient la question, puis un morceau de texte dans le contexte.

39
00:02:39,320 --> 00:02:43,760
Si nous prenons des morceaux de textes disjoints, nous pourrions nous retrouver avec la réponse divisée entre

40
00:02:43,760 --> 00:02:45,330
deux caractéristiques.

41
00:02:45,330 --> 00:02:49,709
Donc, à la place, nous prenons des morceaux de textes qui se chevauchent, pour nous assurer qu'au moins un des morceaux

42
00:02:49,709 --> 00:02:51,650
contiendra entièrement la réponse à la question.

43
00:02:51,650 --> 00:02:56,920
Les tokenizers font tout cela pour nous automatiquement avec l'option `return_overflowing_tokens`.

44
00:02:56,920 --> 00:03:02,069
L'argument `stride` contrôle le nombre de tokens qui se chevauchent.

45
00:03:02,069 --> 00:03:05,930
Voici comment notre très long contexte est tronqué en deux caractéristiques avec un certain chevauchement.

46
00:03:05,930 --> 00:03:10,051
En appliquant le même post-traitement que nous avons vu précédemment pour chaque caractéristique, nous obtenons la réponse

47
00:03:10,051 --> 00:03:20,349
avec un score pour chacun d'eux, et nous prenons la réponse avec le meilleur score comme solution finale.