Tokenization : comment les LLM découpent le texte

Les modèles de langage ne lisent pas le texte comme nous. Là où un humain perçoit des mots, des phrases et des paragraphes, un LLM travaille avec des unités plus fondamentales appelées tokens. Cette étape de découpage, la tokenization, constitue la première transformation que subit tout texte avant d'être traité par un modèle. Elle influence directement les capacités du modèle, ses performances, et ce que vous payez à chaque requête API.

La tokenization peut sembler être un simple détail technique, une étape préliminaire qu'on pourrait ignorer pour se concentrer sur des sujets plus spectaculaires comme le fine-tuning ou le RAG. Pourtant, comprendre comment les LLM découpent le texte éclaire de nombreux comportements qui peuvent autrement paraître mystérieux : pourquoi certains mots sont mal orthographiés, pourquoi le modèle peine avec l'arithmétique simple, pourquoi votre facture API varie selon les langues utilisées.

Le choix de l'algorithme de tokenization, la taille du vocabulaire, et la façon dont différentes langues sont représentées ont des conséquences concrètes sur l'utilisation quotidienne des LLM. Un développeur qui optimise ses prompts, un responsable FinOps qui surveille les coûts, ou un ingénieur qui construit des applications multilingues ont tous intérêt à maîtriser ces fondamentaux.

Dans cet article, nous allons explorer ce qu'est réellement un token, comprendre les algorithmes qui décident où couper le texte, et analyser les implications pratiques de la tokenization sur les coûts et les performances de vos applications LLM.

Qu'est-ce qu'un token ?

Un token est l'unité de base que manipule un LLM. Ce n'est ni un caractère, ni un mot complet, mais quelque chose entre les deux. Selon le contexte, un token peut représenter un mot entier courant ("the", "est"), une partie de mot ("ing", "tion"), un caractère de ponctuation, ou même un espace. Cette granularité variable est au cœur du fonctionnement des tokenizers modernes.

Pour illustrer concrètement, prenons la phrase "Tokenization is fascinating" :

• Avec le tokenizer de GPT-4 : ["Token", "ization", " is", " fascinating"] → 4 tokens
• Le mot "Tokenization" est découpé en deux parties car il est moins fréquent que des mots simples
• L'espace avant "is" et "fascinating" est inclus dans le token lui-même

Cette logique de découpage repose sur une idée simple : les séquences de caractères fréquentes dans les données d'entraînement méritent leur propre token, tandis que les séquences rares sont décomposées en sous-unités plus petites. Le mot "the" apparaît des milliards de fois en anglais et obtient donc son propre token, alors qu'un terme technique rare sera découpé en plusieurs morceaux.

Le vocabulaire d'un tokenizer (l'ensemble de tous les tokens possibles) est fixé lors de l'entraînement du modèle. GPT-4 utilise environ 100 000 tokens différents, Claude et Llama ont des vocabulaires de taille comparable. Ce vocabulaire représente un compromis : trop petit, et le modèle doit utiliser beaucoup de tokens pour représenter du texte varié ; trop grand, et l'espace d'embedding devient difficile à apprendre efficacement.

Une fois le texte découpé en tokens, chaque token est converti en un vecteur numérique via une table d'embedding. C'est cette représentation vectorielle que le transformer traite réellement. Le processus complet ressemble à ceci :

Texte brut → Tokenization → Séquence de token IDs → Table d'embedding → Vecteurs
"Hello world" → ["Hello", " world"] → [9906, 1917] → [vecteur_9906, vecteur_1917]

Cette transformation est réversible : le modèle génère des token IDs en sortie, qui sont reconvertis en texte lisible. Mais certaines subtilités peuvent se perdre en chemin, notamment avec les espaces, la casse, ou les caractères spéciaux, ce qui explique certains comportements étranges des LLM.

Les algorithmes de tokenization

Plusieurs algorithmes ont été développés pour décider comment découper le texte en tokens. Les approches naïves (un token par mot, ou un token par caractère) présentent des limitations évidentes : la tokenization par mot explose le vocabulaire et gère mal les mots inconnus, tandis que la tokenization par caractère produit des séquences trop longues. Les algorithmes modernes cherchent un équilibre optimal.

Byte Pair Encoding (BPE)

L'algorithme BPE (Byte Pair Encoding) est le plus répandu dans les LLM actuels. Il a été adopté par GPT, Llama, et de nombreux autres modèles. Son fonctionnement repose sur une construction itérative du vocabulaire :

1. On commence avec un vocabulaire de base contenant tous les caractères individuels
2. On analyse un corpus de texte et on identifie la paire de tokens adjacents la plus fréquente
3. On fusionne cette paire en un nouveau token qu'on ajoute au vocabulaire
4. On répète jusqu'à atteindre la taille de vocabulaire souhaitée

Par exemple, si "th" apparaît très fréquemment dans le corpus, ces deux caractères seront fusionnés en un seul token "th". Puis si "the" est fréquent, on obtiendra un token "the". Ce processus bottom-up construit naturellement un vocabulaire adapté aux données d'entraînement.

L'avantage majeur de BPE est sa capacité à gérer n'importe quel texte : même un mot jamais vu sera décomposé en sous-unités présentes dans le vocabulaire. Il n'y a pas de token "inconnu" qui perdrait de l'information.

WordPiece et alternatives

WordPiece, utilisé par BERT et ses dérivés, fonctionne de manière similaire mais avec un critère de fusion différent. Au lieu de simplement compter les fréquences, il maximise la vraisemblance du corpus d'entraînement. En pratique, les résultats sont comparables à BPE.

SentencePiece, développé par Google, ajoute une particularité importante : il traite le texte comme une séquence brute de caractères, sans pré-tokenization par espaces. Cela le rend particulièrement adapté aux langues qui n'utilisent pas d'espaces entre les mots (chinois, japonais) ou aux applications multilingues.

Unigram, une autre approche, part d'un vocabulaire large et le réduit progressivement en supprimant les tokens qui contribuent le moins à la modélisation du corpus. Cette méthode top-down peut produire des vocabulaires légèrement différents de BPE.

En pratique, ces algorithmes produisent des résultats relativement similaires pour les langues bien représentées. Les différences deviennent plus significatives sur des textes atypiques ou des langues moins courantes dans les données d'entraînement.

À découvrir : notre formation LLM Engineering

Impact sur les coûts et les performances

La tokenization a des conséquences directes et mesurables sur l'utilisation des LLM en production. Comprendre ces impacts permet d'optimiser à la fois les coûts et la qualité des résultats.

L'équation économique

Les API de LLM facturent au token, tant en entrée qu'en sortie. Le nombre de tokens consommés détermine donc directement votre facture. Or, ce nombre varie significativement selon plusieurs facteurs :

La langue utilisée influence fortement l'efficacité de la tokenization. Les tokenizers sont généralement entraînés sur des corpus majoritairement anglophones. Un texte en anglais sera tokenisé plus efficacement (moins de tokens pour la même quantité d'information) qu'un texte en français, et encore moins efficacement qu'un texte en hindi ou en thaï.

Même phrase, tokenizers différents :
- "The cat is on the table" (anglais) : ~7 tokens
- "Le chat est sur la table" (français) : ~8 tokens  
- "แมวอยู่บนโต๊ะ" (thaï) : ~15 tokens

Cette disparité a des implications concrètes pour les applications multilingues. Un service de support client déployé mondialement paiera significativement plus pour traiter les requêtes dans certaines langues. Cette réalité doit être intégrée dans les projections de coûts.

Le type de contenu joue également un rôle important :

• Le code source est généralement bien tokenisé (mots-clés et patterns répétitifs)
• Les textes techniques avec beaucoup d'acronymes ou de termes spécialisés génèrent plus de tokens
• Les nombres sont souvent mal tokenisés (chaque chiffre ou groupe de chiffres devient un token séparé)
• Les URLs, chemins de fichiers et formats structurés consomment beaucoup de tokens

Implications sur les performances du modèle

Au-delà des coûts, la tokenization affecte directement ce que le modèle peut faire et comment il le fait.

La fenêtre de contexte est mesurée en tokens, pas en mots ou en caractères. Un modèle avec une limite de 128K tokens peut traiter beaucoup plus de texte anglais que de texte dans une langue moins efficacement tokenisée. Pour les systèmes RAG, cette réalité influence la quantité de contexte récupéré qu'on peut effectivement injecter dans le prompt.

Le raisonnement arithmétique est notoirement difficile pour les LLM, et la tokenization en est partiellement responsable. Le nombre "123456" peut être tokenisé en ["123", "456"] ou ["12", "345", "6"], ce qui rend les opérations mathématiques contre-intuitives pour le modèle. Il ne "voit" pas le nombre comme une entité unique mais comme une séquence de fragments.

Les erreurs d'orthographe et de casse trouvent aussi leur origine dans la tokenization. Si le modèle a appris "cannot" comme un seul token mais génère ["can", "not"] dans un contexte particulier, il peut produire "can not" avec un espace. De même, un mot rare sera décomposé en sous-parties qui peuvent être recombinées différemment lors de la génération.

Stratégies d'optimisation

Plusieurs leviers permettent de minimiser l'impact de la tokenization sur vos applications :

• Optimiser les system prompts : chaque mot compte, privilégier des formulations concises
• Compresser le contexte : résumer l'historique de conversation plutôt que de le conserver intégralement
• Choisir le bon modèle : les modèles récents ont souvent des tokenizers plus efficaces
• Pré-traiter les données : normaliser les formats, supprimer les éléments non essentiels avant injection dans le prompt
• Monitorer la consommation : identifier les patterns qui génèrent des pics de tokens

Pour les applications critiques en termes de coûts, des outils permettent d'estimer le nombre de tokens avant l'appel API. La bibliothèque tiktoken d'OpenAI ou les tokenizers de Hugging Face peuvent être utilisés pour prévoir et optimiser la consommation.

import tiktoken

# Estimer les tokens avant l'appel API
encoder = tiktoken.encoding_for_model("gpt-4")
tokens = encoder.encode("Votre texte ici")
print(f"Nombre de tokens : {len(tokens)}")

Les frameworks comme LangChain intègrent des fonctionnalités de comptage de tokens qui facilitent le monitoring et l'optimisation dans les pipelines de production.

À lire : découvrez notre formation LLM Engineering

Conclusion

La tokenization est bien plus qu'un détail d'implémentation : c'est une étape fondamentale qui conditionne ce que les LLM peuvent comprendre et produire. Le découpage du texte en tokens détermine comment l'information est représentée, combien de contexte peut être traité, et ce que vous payez à chaque interaction avec un modèle.

Comprendre les mécanismes de la tokenization éclaire de nombreux comportements des LLM qui peuvent autrement sembler arbitraires. Les difficultés avec l'arithmétique, les variations de coût selon les langues, les erreurs occasionnelles d'orthographe trouvent leur origine dans cette première transformation du texte. Cette compréhension permet d'anticiper les limitations et d'adapter ses stratégies en conséquence.

Pour les équipes qui déploient des LLM en production, les implications pratiques sont significatives. L'optimisation des coûts passe par une attention au nombre de tokens consommés, particulièrement pour les applications à fort volume ou multilingues. La qualité des résultats peut être améliorée en structurant les inputs de manière à faciliter le travail du tokenizer. Et la conception d'applications doit tenir compte des limites de contexte réelles, qui dépendent de l'efficacité de tokenization du contenu traité.

La tokenization continuera d'évoluer avec les prochaines générations de modèles. Des approches alternatives comme les modèles byte-level ou les tokenizers adaptatifs font l'objet de recherches actives. Mais les principes fondamentaux resteront les mêmes : transformer du texte brut en représentations numériques que les réseaux de neurones peuvent traiter, avec tous les compromis que cette transformation implique.