1
00:00:05,360 --> 00:00:07,920
Jetons un coup d'œil à l'intérieur du pipeline de réponse aux questions.

2
00:00:09,600 --> 00:00:13,520
Le pipeline de réponse aux questions peut extraire les réponses aux questions à

3
00:00:13,520 --> 00:00:17,840
partir d'un contexte ou d'un passage de texte donné, comme cette partie du README du dépôt Transformers.

4
00:00:19,040 --> 00:00:23,680
Cela fonctionne aussi pour les contextes très longs, même si la réponse se trouve à la toute fin, comme dans cet exemple.

5
00:00:24,480 --> 00:00:25,840
Dans cette vidéo, nous allons voir pourquoi !

6
00:00:27,600 --> 00:00:32,720
Le pipeline de réponse aux questions suit les mêmes étapes que les autres pipelines : la question et le

7
00:00:32,720 --> 00:00:38,160
contexte sont tokenisés sous la forme d'une paire de phrases, transmis au modèle, puis un post-traitement est appliqué.

8
00:00:39,280 --> 00:00:44,160
Les étapes de tokenisation et de modèle doivent être familières. Nous utilisons la classe automatique adaptée à la

9
00:00:44,160 --> 00:00:48,240
réponse aux questions au lieu de la classification de séquence, mais une différence clé

10
00:00:48,240 --> 00:00:53,680
avec la classification de texte est que notre modèle génère deux tenseurs nommés logits de début et

11
00:00:53,680 --> 00:00:58,640
logits de fin. Pourquoi donc? C'est ainsi que le modèle trouve la réponse à la question.

12
00:00:59,920 --> 00:01:04,880
Examinons d'abord les entrées du modèle. Il s'agit de numéros associés à la tokenisation de la

13
00:01:04,880 --> 00:01:12,160
question suivis du contexte (avec les tokens spéciaux [CLS] et [SEP] habituels). La réponse fait partie

14
00:01:12,160 --> 00:01:17,920
de ces tokens. Nous demandons donc au modèle de prédire quel token commence la réponse et lequel termine la

15
00:01:17,920 --> 00:01:25,040
réponse. Pour nos deux sorties logit, les libellés théoriques sont les vecteurs rose et violet. Pour convertir

16
00:01:25,040 --> 00:01:29,520
ces logits en probabilités, nous devrons appliquer une SoftMax, comme dans le pipeline de classification de texte

17
00:01:29,520 --> 00:01:36,240
Nous masquons simplement les tokens qui ne font pas partie du contexte avant de le faire, en laissant le

18
00:01:36,240 --> 00:01:43,200
token [CLS] initial démasqué car nous l'utilisons pour prédire une réponse impossible. Voici à quoi cela ressemble en

19
00:01:43,200 --> 00:01:49,200
termes de code. Nous utilisons un grand nombre négatif pour le masquage, puisque son exponentielle sera alors 0.

20
00:01:50,480 --> 00:01:54,640
Maintenant la probabilité pour chaque position de début et de fin correspondant à une réponse possible,

21
00:01:55,520 --> 00:02:00,000
nous donnons un score qui est le produit des probabilités de début et des probabilités de fin à ces

22
00:02:00,000 --> 00:02:06,000
positions. Bien entendu, un indice de début supérieur à un indice de fin correspond à une réponse impossible.

23
00:02:07,360 --> 00:02:12,080
Voici le code permettant de trouver le meilleur score pour une réponse possible. Une fois que nous avons les positions de début et de

24
00:02:12,080 --> 00:02:17,040
fin des tokens, nous utilisons l'association de décalage fournis par notre générateur de tokens pour trouver la

25
00:02:17,040 --> 00:02:23,520
plage de caractères dans le contexte initial et obtenir notre réponse ! Désormais, lorsque le contexte est long,

26
00:02:23,520 --> 00:02:29,440
il peut être tronqué par le tokenizer. Cela peut entraîner la troncature d'une partie de la réponse, ou pire, de la

27
00:02:29,440 --> 00:02:34,800
totalité de la réponse. Nous ne supprimons donc pas les tokens tronqués, mais créons de nouvelles caractéristiques

28
00:02:34,800 --> 00:02:42,080
avec eux. Chacune de ces caractéristiques contient la question, puis un morceau de texte dans le contexte. Si

29
00:02:42,080 --> 00:02:47,280
nous prenons des morceaux de textes disjoints, nous pourrions nous retrouver avec la réponse divisée entre deux caractéristiques.

30
00:02:48,560 --> 00:02:51,840
Donc, à la place, nous prenons des morceaux de textes qui se chevauchent,

31
00:02:51,840 --> 00:02:55,520
pour nous assurer qu'au moins l'un des morceaux contiendra entièrement la réponse à la question.

32
00:02:56,720 --> 00:03:00,880
Les tokenizers font tout cela pour nous automatiquement avec l'option `return_overflowing_tokens`.

33
00:03:01,680 --> 00:03:04,320
L'argument `stride` contrôle le nombre de tokens qui se chevauchent.

34
00:03:05,680 --> 00:03:10,160
Voici comment notre très long contexte est tronqué en deux caractéristiques avec un certain chevauchement.

35
00:03:10,960 --> 00:03:15,520
En appliquant le même post-traitement que nous avons vu avant pour chaque caractéristique, nous obtenons la réponse

36
00:03:15,520 --> 00:03:27,600
avec un score pour chacune d'elles, et nous prenons la réponse avec le meilleur score comme solution finale.