Lors de l’étape précédente, nous avons commencé à distinguer plusieurs éléments susceptibles d’intervenir entre votre demande et la réponse obtenue.

L’un d’entre eux reste encore largement une boîte noire :

LE MODÈLE

Nous écrivons des phrases.

Nous utilisons des mots.

Nous ajoutons de la ponctuation, des nombres, parfois des emojis, des noms propres ou des termes dans plusieurs langues.

Mais est-ce réellement sous cette forme que le modèle traite notre demande ?

Dans cette étape, nous allons suivre ce que devient le texte de votre demande lorsqu’il est transmis au modèle.

Nous chercherons à déterminer :

• comment le texte de votre demande est transformé avant d’être traité par le modèle ;
• si le modèle le découpe nécessairement comme nous le faisons ;
• ce que ces transformations nous permettent — ou non — de comprendre de son fonctionnement.

Mais, comme précédemment, nous ne commencerons pas par les définitions.

Observez cette phrase :

Pour vous, elle est composée de mots.

Vous pouvez les compter.

Vous pouvez identifier une phrase, des espaces, une ponctuation et un nom propre.

Imaginez maintenant que cette phrase soit envoyée à un modèle de langage.

Avant de poursuivre, représentez ce que vous pensez que le modèle reçoit réellement.

Ne cherchez pas la bonne réponse : indiquez aussi ce dont vous n’êtes pas certains.

Sans utiliser d’outil, travaillez sur cette phrase :

Il n’existe pas encore de réponse attendue à ce stade.

Vous venez d’observer le fonctionnement d’un tokenizer.

Dans les modèles de langage, le texte est généralement transformé en tokens, c’est-à-dire en unités déterminées par le système de tokenisation utilisé.

Un token peut correspondre, selon les cas et le tokenizer :

• à un mot entier ;
• à une partie de mot ;
• à un signe de ponctuation ;
• à un nombre ou une partie de celui-ci ;
• à un espace associé à une autre unité ;
• ou à d’autres séquences de caractères.

Et surtout :

le découpage n’est pas nécessairement identique d’un tokenizer à l’autre.

Nous n’allons donc pas apprendre :

comme une règle universelle.

Ce serait précisément le type de simplification que notre démarche cherche à éviter.

Vous allez maintenant concevoir votre propre série d’essais afin de mettre à l’épreuve votre représentation de la tokenisation.

Chaque essai doit avoir une raison d’exister.

Lorsque c’est possible, ne modifiez qu’un élément à la fois.

Avant chaque essai, notez ce que vous pensez observer.

Consignez uniquement les essais que votre groupe juge réellement informatifs.

Jusqu’à présent, vous avez observé un seul tokenizer.

Mais pouvons-nous supposer que tous les modèles découpent nécessairement le même texte de la même manière ?

Reprenez exactement la même phrase :

Identifiez des tokenizers associés à des modèles ou à des familles de modèles différents lorsque cette information et un outil permettant de les observer sont disponibles.

Utilisez en priorité un outil officiel ou un tokenizer publié ou documenté par l’organisation à l’origine du modèle.

Vous pouvez utiliser un comparateur multi-tokenizers pour explorer rapidement plusieurs découpages.

Un comparateur tiers constitue un outil d’exploration.

Le résultat qu’il affiche ne suffit pas, à lui seul, à établir que le modèle ou le service que vous utilisez actuellement emploie exactement ce tokenizer.

Lorsque cela est possible, vérifiez cette association dans une source officielle.

Complétez le tableau en distinguant ce que vous observez de ce que vos sources permettent réellement d’établir.

Confrontez maintenant votre représentation aux éléments suivants :

Un même texte peut être découpé différemment selon le tokenizer utilisé.

Plusieurs modèles peuvent utiliser des tokenizers différents.

Certains modèles peuvent également partager un même tokenizer ou une même famille de tokenisation.

Nous devons donc éviter de transformer l’observation réalisée avec un tokenizer particulier en règle applicable à tous les modèles.

De même, lorsque vous utilisez un service tel qu’un assistant conversationnel, ne confondez pas automatiquement :

L’étape précédente nous a appris à distinguer les composantes d’un système.

Cette distinction reste nécessaire ici.

Le tokenizer vous montre des morceaux de texte.

Mais le modèle ne manipule pas directement les mots tels que vous les voyez à l’écran.

À partir du tokenizer utilisé, les tokens sont associés à des identifiants numériques.

Lorsque l’outil utilisé le permet, affichez maintenant l’identifiant associé à chaque token.

Vous pouvez représenter cette étape ainsi :

TEXTE
  ↓
TOKENISATION
  ↓
TOKEN 1 | TOKEN 2 | TOKEN 3 | TOKEN 4...
  ↓
ID 1    | ID 2    | ID 3    | ID 4…

Ne cherchez pas encore à conclure : conservez plusieurs explications compatibles avec ce que vous observez.

L’identifiant permet de désigner une unité dans le vocabulaire utilisé par le tokenizer.

Le modèle associe ensuite ces unités à des représentations numériques apprises qui seront utilisées dans les traitements suivants. À ce stade, il n’est pas nécessaire d’en connaître précisément le fonctionnement mathématique.

Nous pouvons maintenant représenter le chemin parcouru par notre texte :

À ce stade, nous savons mieux comment le texte devient traitable par le modèle. Nous ne savons pas encore comment celui-ci produit la réponse.

Nous avons observé comment notre texte peut être découpé et transformé avant son traitement par le modèle.

Supposons maintenant que deux services semblent accepter des quantités de texte différentes.

La limite dépend-elle du modèle, du service, de l’interface ou d’un autre élément du système ?

Avant de rechercher la réponse, formulez votre représentation.

Les modèles disposent d’une capacité limitée concernant la quantité d’informations pouvant être prise en compte dans un contexte donné.

Cette limite est généralement exprimée en tokens.

On parle couramment de fenêtre de contexte.

Reprenez maintenant le modèle construit à l’étape précédente.

Vous aviez commencé à représenter :

À partir des observations et vérifications réalisées dans cette étape, nous pouvons maintenant établir que :

Le texte soumis à un modèle de langage est tokenisé avant son traitement par le modèle.

Un token ne correspond pas nécessairement à un mot.

La manière dont un texte est tokenisé dépend du tokenizer utilisé.

Un même texte peut donc produire des tokenisations différentes selon le tokenizer considéré.

Les tokens sont associés à des identifiants puis à des représentations numériques utilisées par le modèle.

La quantité d’informations pouvant être prise en compte dans un contexte donné est limitée et dépend notamment du modèle et du système considérés.

Et surtout :

Conservez :

• votre hypothèse initiale sur le traitement du texte ;
• vos découpages manuels et les critères utilisés pour les construire ;
• le découpage observé avec le premier tokenizer ;
• votre série d’essais et vos prédictions ;
• les résultats qui ont confirmé, fragilisé ou modifié votre représentation ;
• la comparaison entre les différents tokenizers ;
• les sources permettant d’associer un tokenizer à un modèle ou à une famille de modèles ;
• le niveau de certitude associé à ces informations ;
• les associations qui restent incertaines ;
• la relation token → identifiant → représentation numérique ;
• votre recherche sur la fenêtre de contexte, avec le modèle étudié, la source et la date de consultation ;
• votre schéma de l’étape 4 enrichi et les justifications de vos modifications.

Et surtout :