Tokens et tokenisation — comment les LLM lisent le texte

En bref

Quand vous envoyez un message à un modèle de langage, celui-ci ne reçoit pas du texte. Il reçoit une séquence de nombres entiers — des identifiants. Chaque entier correspond à un token : une unité de texte découpée par un algorithme avant même que le modèle ne commence à traiter quoi que ce soit.

Un token n’est pas un mot. Ce n’est pas non plus un caractère. C’est quelque chose entre les deux : un fragment de mot, un mot entier, parfois une ponctuation ou un espace. Tout ce que le modèle sait du langage humain, il l’a appris à travers ce prisme. La tokenisation est donc la première couche — invisible mais fondamentale — entre le texte et le modèle.

Explication

Qu’est-ce qu’un token, concrètement ?

Prenons le mot “tokenisation”. Selon le tokenizer utilisé, ce mot peut être découpé en deux ou trois fragments : token, isation — ou token, isa, tion. Chaque fragment est un token. Un identifiant entier lui est associé dans le vocabulaire du modèle.

En anglais, la règle empirique souvent citée est : 1 mot ≈ 1,5 token. En français, ce ratio est légèrement moins favorable. Pour des langues comme le japonais, l’arabe ou l’ukrainien, il peut atteindre 3 à 5 tokens par mot — avec des conséquences directes sur les coûts et les limites de traitement (voir section suivante).

Le modèle ne reçoit jamais le texte brut. Il reçoit uniquement la séquence des identifiants entiers correspondant aux tokens. Le décodage en texte lisible n’a lieu qu’à la sortie.

L’algorithme BPE — comment le vocabulaire est construit

La technique dominante dans les grands modèles de langage est le Byte Pair Encoding (BPE), ou l’une de ses variantes. L’idée est simple : construire un vocabulaire de sous-mots à partir de fréquences statistiques sur un corpus d’entraînement.

L’algorithme procède en quatre étapes :

1. Initialisation : le vocabulaire de départ contient tous les caractères individuels du corpus (ou tous les bytes, dans la variante byte-level BPE).
2. Comptage : on identifie la paire de tokens adjacents la plus fréquente dans le corpus.
3. Fusion : cette paire est fusionnée en un nouveau token, ajouté au vocabulaire.
4. Répétition : on répète les étapes 2 et 3 jusqu’à atteindre la taille de vocabulaire cible (par exemple 100 000 tokens).

Le résultat est un vocabulaire qui encode les fragments les plus courants de la langue. Les mots fréquents (“the”, “les”, “de”) deviennent souvent des tokens uniques. Les mots rares sont décomposés en sous-parties reconnaissables.

L’avantage sur une tokenisation par mots entiers : les mots inconnus ne sont plus bloquants. Au lieu d’être remplacés par un marqueur [UNK] (inconnu), ils sont décomposés en parties connues. L’avantage sur la tokenisation caractère par caractère : les séquences sont beaucoup plus courtes, ce qui réduit mécaniquement la taille des contextes à traiter.

Tous les tokenizers ne se ressemblent pas

Les modèles n’utilisent pas le même tokenizer, et ce choix a des implications pratiques :

La différence entre tiktoken (utilisé par OpenAI) et SentencePiece (utilisé par Meta pour Llama) tient au niveau de découpage initial : tiktoken encode d’abord le texte en bytes UTF-8 puis fusionne des bytes ; SentencePiece travaille directement au niveau des points de code Unicode. Le résultat visible : pour un même texte, le nombre de tokens produits peut différer d’un modèle à l’autre.

Un vocabulaire plus grand tend à produire des séquences plus courtes (moins de tokens par texte), mais nécessite un embedding plus volumineux et un entraînement plus long. Un vocabulaire plus petit est plus compact mais découpe plus finement — et donc moins efficacement les mots rares.

Exemples concrets

Le coût se calcule en tokens, pas en mots

Les APIs de modèles de langage facturent à la consommation, par token — à l’entrée (le prompt) et à la sortie (la réponse). Un texte de 1 000 mots en anglais représente environ 1 300 à 1 500 tokens. Le même volume de texte en français sera légèrement plus long en tokens ; en arabe ou en japonais, il peut atteindre 3 000 à 5 000 tokens.

Connaître le ratio mots/tokens du modèle que l’on utilise est donc une compétence directement économique. Le tokenizer de GPT-4 (cl100k_base) est accessible et testable publiquement via des outils en ligne — ce qui permet d’estimer précisément le coût d’un appel API avant de l’exécuter.

Les langues non-latines sont pénalisées à deux niveaux

La pénalité pour les langues peu représentées dans les données d’entraînement est double. D’abord, les tokens sont plus nombreux par mot : un mot ukrainien qui s’écrit en 6 caractères peut consommer 4 tokens là où son équivalent anglais n’en consomme qu’un. Ensuite, le modèle a été exposé à moins d’exemples dans cette langue, ce qui dégrade aussi la qualité de compréhension et de génération.

Une étude publiée dans Frontiers in Artificial Intelligence (2025) documente cette inefficacité pour l’ukrainien : l’encodage est significativement moins efficace que pour l’anglais, avec un impact direct sur la longueur effective de la fenêtre de contexte disponible pour cette langue.

Les nombres posent un problème spécifique

La tokenisation des nombres entiers n’est pas systématique en BPE. Le nombre “1234” peut être découpé en “12” et “34”, ou en “1”, “234”, ou encore en “1234” comme token unique — selon le vocabulaire et les fréquences vues à l’entraînement. Cette irrégularité n’est pas anodine : des recherches ont montré que l’ordre de tokenisation (gauche-droite ou droite-gauche) influence les performances arithmétiques du modèle sur des additions multi-chiffres. Ce n’est pas un bug intentionnel — c’est une limite inhérente à l’approche statistique du BPE sur des symboles numériques.

Un exemple pour ancrer l’intuition

La phrase “Les LLM ne lisent pas des mots.” sera tokenisée différemment selon le modèle. Dans cl100k_base (GPT-4), on peut s’attendre à quelque chose comme : ["Les", " LLM", " ne", " lisent", " pas", " des", " mots", "."] — soit 8 tokens pour 7 mots. Le token ” lisent” inclut l’espace précédent, ce qui est caractéristique du byte-level BPE. Dans un tokenizer SentencePiece, le découpage peut différer légèrement. Ces différences sont invisibles à l’utilisateur mais influencent la façon dont le modèle “voit” le texte.

Ce qu’il faut retenir

• Un LLM ne traite pas du texte brut mais une séquence d’entiers correspondant à des tokens — fragments de mots, mots entiers, ou caractères.
• L’algorithme dominant, le BPE, construit le vocabulaire en fusionnant itérativement les paires les plus fréquentes dans un corpus. Il permet de gérer les mots inconnus sans marqueur [UNK].
• Les tokenizers diffèrent entre modèles : vocabulaire, taille, implémentation. Un même texte ne produit pas le même nombre de tokens d’un modèle à l’autre.
• Les langues non-latines consomment davantage de tokens que l’anglais — parfois 3 à 5 fois plus par mot — ce qui augmente les coûts et réduit l’espace de contexte effectif.
• La facturation API est au token, pas au mot. Comprendre ce ratio est une compétence pratique pour maîtriser ses coûts.
• La tokenisation des nombres est irrégulière en BPE, ce qui peut affecter les performances sur des tâches arithmétiques.

Sources

• DataAnnotation — Context Windows Explained : définition des tokens et ratio mots/tokens.
• Hugging Face — Byte-Pair Encoding tokenization : description pas-à-pas de l’algorithme BPE.
• Sebastian Raschka — How does tokenization work? : explication de BPE par un chercheur ML.
• Hugging Face — Tokenization algorithms : comparaison BPE, WordPiece, SentencePiece, tiktoken.
• Rohan Paul — Balancing Vocabulary Size in Modern LLMs : tableaux comparatifs des vocabulaires GPT, Claude, Llama.
• Frontiers in AI — Tokenization efficiency for Ukrainian : étude empirique sur l’inefficacité des tokenizers pour les langues non-latines.
• arxiv.org — Tokenization and arithmetic performance : impact de l’ordre de tokenisation sur les performances arithmétiques.
• Let’s Data Science — How LLM Tokenization Actually Works : panorama général sur les enjeux pratiques de la tokenisation.