Qu’est-ce qu’un token ?

L’essentiel

Pourquoi ne pas donner directement le texte au modèle ?

Un ordinateur reçoit du texte encodé sous forme de nombres, mais un modèle de langage à tokens ne travaille généralement pas directement avec les lettres visibles. Une étape d’encodage transforme d’abord le texte en une séquence d’identifiants issus d’un vocabulaire fini.

Le modèle utilise ensuite ces identifiants pour rechercher des représentations numériques apprises. À la sortie, l’opération inverse permet de convertir les tokens générés en texte affichable.

Cette séparation évite de créer une entrée différente pour chaque phrase possible. Elle impose toutefois un choix : quelles unités faut-il placer dans le vocabulaire ?

Du texte aux identifiants

Une chaîne de traitement courante comporte plusieurs opérations :

1. Recevoir le texte exact. Les espaces, accents, retours à la ligne, majuscules et emoji font partie de l’entrée.
2. Appliquer éventuellement une normalisation. Certains systèmes transforment certaines variantes Unicode ou espaces ; d’autres préservent davantage le texte.
3. Segmenter selon un vocabulaire et des règles. Le tokenizer cherche une suite d’unités capables de représenter le texte.
4. Associer un identifiant à chaque unité. La sortie de l’encodeur est une séquence d’entiers.
5. Ajouter éventuellement des tokens spéciaux. Certaines architectures utilisent des marqueurs de début, de fin, de séparation ou de rôle.

Toutes ces étapes ne sont pas identiques dans tous les systèmes. Le mot « tokenizer » désigne souvent l’ensemble de cette chaîne, même lorsque plusieurs opérations internes sont distinguées.

Un token n’est ni forcément un mot, ni forcément un caractère

Prenons le texte imprévisible.

Un tokenizer pourrait le représenter comme :

• imprévisible ;
• im + prévisible ;
• im + pré + visible ;
• une suite plus fine de caractères ou d’octets.

Ces exemples illustrent des possibilités, pas la sortie garantie d’un tokenizer réel. Pour connaître le véritable découpage, il faut exécuter le tokenizer exact, dans la bonne version, avec son vocabulaire et sa normalisation.

Un caractère visible n’est pas non plus toujours une unité simple. Un emoji peut combiner plusieurs points de code Unicode ; ces points de code deviennent plusieurs octets en UTF-8. Un tokenizer peut conserver la séquence entière, la fragmenter ou retomber sur des unités plus petites.

Pourquoi utiliser des sous-mots ?

Un vocabulaire contenant seulement des mots entiers rencontre vite des mots rares, des noms propres, des conjugaisons, des fautes ou des mots nouveaux. À l’autre extrême, un système fondé uniquement sur de très petites unités peut représenter presque tout, mais produit des séquences longues.

Les unités de sous-mot cherchent un compromis :

• conserver certaines unités fréquentes sous une forme compacte ;
• décomposer les formes rares en fragments réutilisables ;
• maintenir un vocabulaire de taille finie ;
• représenter des textes qui n’étaient pas présents tels quels lors de la construction du vocabulaire.

Des familles de méthodes comme BPE, WordPiece ou le modèle unigramme ne prennent pas exactement les mêmes décisions. Même deux tokenizers d’une même famille peuvent différer selon leurs données et leurs réglages.

Analogie : une boîte de pièces

Ce que cette analogie simplifie

Laboratoire : comparer deux tokenisations

Choisissez une phrase, un mot long, un emoji ou une ligne de code. Vérifiez que les deux profils reconstruisent le même texte, puis affichez les identifiants. Observez surtout ce qui change : les frontières et la longueur de la séquence.

Quelles conséquences pratiques ?

Pour un modèle qui utilise des tokens, le découpage influence la longueur de la séquence traitée. Cela peut avoir plusieurs effets :

• fenêtre de contexte : un texte plus fragmenté occupe davantage de positions dans une limite exprimée en tokens ;
• calcul et latence : des séquences plus longues demandent généralement davantage de traitement, avec des détails qui dépendent de l’architecture ;
• coût d’un service : certaines offres facturent selon un nombre de tokens, mais leurs règles et tokenizers doivent être vérifiés séparément ;
• langues et domaines : un vocabulaire peut être compact pour certains textes et beaucoup plus fragmenté pour d’autres langues, écritures ou types de contenu ;
• apprentissage : les frontières choisies modifient les unités sur lesquelles le modèle apprend des représentations.

Un faible nombre de tokens ne suffit pourtant pas à déclarer un tokenizer « meilleur ». La couverture, la qualité du modèle, les données, la robustesse, la vitesse et la tâche comptent aussi. Des études comparatives montrent que des métriques simples comme le nombre moyen de tokens ne prédisent pas toujours à elles seules la performance finale.

Trois nuances importantes

1. Les tokens ne sont pas des concepts stockés dans des cases. Le sens dépend de représentations apprises et du contexte, pas seulement du fragment visible.
2. Les espaces peuvent être intégrés aux unités. Dans certaines interfaces de visualisation, un marqueur spécial représente un espace au début d’un token.
3. Tous les modèles de texte n’emploient pas des sous-mots classiques. Des architectures expérimentales ou spécialisées opèrent à l’échelle des octets, des caractères ou de segments appris autrement.

Présentation

La présentation résume le passage du texte aux identifiants et les compromis entre taille du vocabulaire et longueur des séquences.

Vérifiez votre compréhension

Le quiz distingue les propriétés générales d’un tokenizer des exemples préparés dans cette leçon.

Trois idées à retenir

Concepts liés

• Vocabulaire
• Identifiant de token
• Sous-mot
• Octet
• Normalisation
• Contexte

Sources principales

Les sources ci-dessous couvrent plusieurs familles de tokenisation et leurs compromis. Elles ont été vérifiées le 27 juillet 2026. Les exemples interactifs de cette page ne reproduisent les sorties d’aucun article ou tokenizer cité.