Tokenisation : définition, algorithmes BPE et exemples

La tokenisation est l'étape qui transforme une chaîne de caractères en une liste d'entiers qu'un modèle de langage peut traiter. Elle découpe le texte en tokens, cherche chacun dans un vocabulaire fixe et le remplace par son identifiant. À la sortie du modèle, l'opération inverse, le décodage, reconvertit les identifiants générés en texte lisible.

Historiquement, le traitement automatique du langage découpait le texte en mots. Cette approche bute sur deux problèmes : le vocabulaire explose avec les flexions, les noms propres et les fautes de frappe, et tout mot absent du dictionnaire devient un symbole « inconnu ». À l'inverse, un découpage caractère par caractère ne laisse rien d'inconnu mais produit des séquences très longues, coûteuses à traiter pour un Transformer. Les tokenizers en sous-mots, popularisés en traduction automatique au milieu des années 2010, puis par BERT et GPT-2, ont résolu ce dilemme : les mots fréquents restent entiers, les mots rares sont décomposés en morceaux connus.

Le tokenizer est entraîné une fois, sur un large corpus, avant le modèle lui-même. Son vocabulaire est ensuite figé : chaque identifiant correspond à une ligne de la matrice d'embeddings du modèle. C'est pourquoi tokenizer et poids sont indissociables, et pourquoi deux LLM différents découpent rarement un même texte de la même façon.

À retenir : la tokenisation est un dictionnaire appris qui détermine comment le modèle « voit » le texte. Elle influence la longueur des séquences, le coût des requêtes et certaines capacités du modèle.

Trois familles d'algorithmes se partagent les LLM actuels. Elles diffèrent surtout par la manière de construire le vocabulaire.

BPE (Byte Pair Encoding)

Le BPE vient de la compression de données, où il a été décrit par Philip Gage en 1994. Sennrich et ses coauteurs l'ont adapté à la traduction automatique en 2016. L'algorithme part d'un vocabulaire réduit aux caractères, compte les paires de symboles adjacents dans le corpus, fusionne la plus fréquente en un nouveau symbole, puis recommence jusqu'à atteindre la taille de vocabulaire visée. Pour tokeniser un nouveau texte, il rejoue les fusions apprises dans le même ordre.

GPT-2 a introduit une variante byte-level : le vocabulaire de départ n'est plus l'ensemble des caractères mais les 256 octets possibles. N'importe quelle chaîne UTF-8, emoji ou idéogramme compris, peut donc être encodée sans token inconnu. C'est l'approche de la plupart des LLM génératifs actuels, dont ceux d'OpenAI via la bibliothèque tiktoken.

WordPiece

Conçu chez Google au début des années 2010 et rendu célèbre par BERT, WordPiece procède aussi par fusions successives. Mais au lieu de retenir la paire la plus fréquente, il choisit celle qui augmente le plus la vraisemblance du corpus, ce qui favorise les paires dont les éléments apparaissent rarement séparément. À l'usage, il découpe chaque mot en cherchant le plus long préfixe présent dans le vocabulaire. Les fragments de continuation sont marqués par le préfixe ## : « tokenisation » peut ainsi devenir token, ##isation.

Unigram et SentencePiece

L'algorithme Unigram, proposé par Taku Kudo en 2018, suit le chemin inverse. Il part d'un très grand vocabulaire candidat et retire progressivement les tokens dont la suppression dégrade le moins la vraisemblance du corpus. Il peut proposer plusieurs découpages possibles d'un même mot, une propriété exploitée pour rendre les modèles plus robustes.

SentencePiece n'est pas un algorithme mais une bibliothèque de Google, publiée la même année, qui implémente BPE et Unigram. Sa particularité : elle traite le texte brut comme un flux, espaces compris (représentés par le symbole ▁), sans pré-découpage dépendant de la langue. Elle convient donc aussi aux langues qui ne séparent pas les mots par des espaces, comme le japonais ou le chinois. Des modèles comme T5 ou les premières générations de Llama l'ont utilisée.

BPE, WordPiece, Unigram : quelles différences ?

La bibliothèque tiktoken donne accès aux encodages des modèles d'OpenAI. L'encodage o200k_base est celui des modèles de la génération GPT-4o.

import tiktoken

enc = tiktoken.get_encoding("o200k_base")

texte = "La tokenisation découpe le texte en sous-mots."
ids = enc.encode(texte)

print(len(ids), "tokens :", ids)
# Chaque token est une suite d'octets : un caractère accentué peut être réparti sur deux tokens
print([enc.decode_single_token_bytes(i) for i in ids])
print(enc.decode(ids) == texte)  # True : le décodage est exact

Pour un modèle ouvert, on charge son tokenizer depuis le Hub de Hugging Face avec AutoTokenizer. Comparer deux familles de tokenizers sur la même phrase est très parlant :

from transformers import AutoTokenizer

texte = "La tokenisation découpe le texte en sous-mots."

for nom in ["google-bert/bert-base-multilingual-cased", "Qwen/Qwen2.5-0.5B-Instruct"]:
    tok = AutoTokenizer.from_pretrained(nom)
    encoded = tok(texte)
    print(nom)
    print("  tokens :", tok.convert_ids_to_tokens(encoded["input_ids"]))
    print("  nombre :", len(encoded["input_ids"]))

Le tokenizer WordPiece de BERT affiche des fragments préfixés par ## et encadre la phrase des tokens spéciaux [CLS] et [SEP]. Le tokenizer BPE byte-level de Qwen représente l'espace qui précède un mot par le caractère Ġ, une convention héritée de GPT-2. Les deux reconstituent pourtant exactement le texte au décodage.

Le vocabulaire d'un tokenizer reflète son corpus d'entraînement. Tout ce qui y est rare est découpé plus finement, avec des conséquences concrètes.

• Les langues : l'anglais, majoritaire dans les corpus, est le mieux compressé. Le français demande en général un peu plus de tokens pour un même contenu, et les langues à alphabet non latin peu représentées peuvent en demander plusieurs fois plus. Des travaux de recherche ont montré que cet écart se traduit par des coûts et des latences inégaux selon la langue de l'utilisateur. Les vocabulaires plus vastes et plus multilingues des modèles récents atténuent le phénomène.
• Les nombres : selon le tokenizer, un nombre est découpé chiffre par chiffre ou par groupes de plusieurs chiffres, parfois de façon irrégulière. « 1234 » et « 12345 » ne sont alors pas alignés de la même manière, ce qui complique l'apprentissage de l'arithmétique. Certains tokenizers imposent un découpage régulier des chiffres précisément pour cette raison.
• Le code : indentation, accolades et noms de variables pèsent lourd. Les premiers tokenizers gaspillaient un token par espace d'indentation ; les tokenizers récents disposent de tokens pour les suites d'espaces et pour les mots-clés courants des langages de programmation.
• La casse et les espaces : « Paris », « paris » et « Paris » précédé d'une espace correspondent souvent à des tokens différents. Une variation de mise en forme peut ainsi modifier le nombre de tokens, et parfois la réponse du modèle.

Ces effets expliquent des faiblesses connues des LLM, comme la difficulté à épeler un mot, à inverser une chaîne de caractères ou à compter des lettres. Notre article Tokenization : comment les LLM découpent le texte en donne de nombreux exemples. Pour le volet économique (fenêtre de contexte, facturation au token), voir la fiche Token.