Quand un modèle de langage comme Llama 3 ou GPT-4 lit la phrase "Le prix du café est de 3,45 €", il ne la voit pas comme vous. Il la découpe en morceaux, appelés tokens. Ce processus, appelé tokenization, n’est pas une simple étape de prétraitement. C’est la première et la plus importante décision que vous prenez avant même d’entraîner votre modèle. Un mauvais choix de tokenizer peut réduire la précision de votre modèle de jusqu’à 15 %, gaspiller 30 % de sa capacité, ou même le rendre incapable de comprendre les nombres.
Comment un tokenizer fonctionne vraiment
Un tokenizer ne se contente pas de couper les mots. Il décompose le texte en unités plus petites, souvent des sous-mots ou des caractères. Par exemple, la phrase "université" peut être divisée en "uni" + "versité". Pourquoi ? Parce que les modèles ne comprennent pas les mots comme nous. Ils travaillent avec des nombres. Chaque token est associé à un nombre unique dans un dictionnaire appelé vocabulaire. Plus ce vocabulaire est grand, plus le modèle peut reconnaître de mots rares. Mais plus il est grand, plus il consomme de mémoire.
Les trois principales méthodes de tokenization sont le BPE, le WordPiece et l’Unigram. Elles ne fonctionnent pas de la même manière. Le BPE (Byte Pair Encoding), utilisé par GPT-4, commence avec des caractères individuels et fusionne les paires les plus fréquentes. Si "th" et "e" apparaissent souvent ensemble, il les fusionne en un seul token. Le WordPiece, utilisé par BERT, fait l’inverse : il part d’un grand vocabulaire et choisit les tokens qui maximisent la probabilité de la phrase. L’Unigram, lui, part aussi d’un grand vocabulaire, mais il retire les tokens qui apportent le moins d’information. Cela le rend plus efficace pour réduire la longueur des séquences.
La taille du vocabulaire : plus grand n’est pas toujours mieux
Beaucoup pensent qu’un vocabulaire de 128 000 tokens est automatiquement meilleur qu’un vocabulaire de 3 000. Ce n’est pas vrai. C’est un compromis. Un petit vocabulaire (3 000 tokens) réduit la mémoire utilisée par le modèle de 60 %. Mais il oblige le modèle à découper chaque mot en beaucoup plus de tokens. Une phrase qui tient en 10 tokens avec un grand vocabulaire peut en nécessiter 14 avec un petit. Cela ralentit l’entraînement et augmente le risque de perdre du contexte.
À l’inverse, un vocabulaire de 128 000 tokens (comme dans Llama 3) réduit la longueur des séquences de 30 à 45 %. Cela permet de traiter plus de texte en parallèle. Mais il faut 75 à 90 % plus de mémoire pour stocker les embeddings. Pour les modèles de code, où chaque fonction peut avoir un nom unique, un vocabulaire plus grand est essentiel. Pour les applications simples, comme la classification de texte, un vocabulaire de 25 000 suffit largement.
Une étude publiée en novembre 2024 sur arXiv a montré que pour la prédiction de signatures de fonctions, les modèles avec un vocabulaire de 35 000 tokens étaient 7 à 12 % plus précis que ceux avec 3 000. Pourquoi ? Parce qu’ils avaient moins de tokens "hors vocabulaire" (OOV). Quand un mot n’est pas dans le vocabulaire, le modèle le découpe en morceaux aléatoires. Il ne comprend plus rien.
Les différences entre BPE, WordPiece et Unigram
Chaque méthode a ses forces et ses faiblesses. Voici ce que les chercheurs ont observé dans des tests rigoureux sur des modèles comme Llama 3.2 et BERT :
| Tokenzier | Efficacité de compression | Précision sur tâches complexes | Coût computationnel | Meilleur pour |
|---|---|---|---|---|
| BPE | Moyenne | Moyenne | Moyen | Applications générales, code |
| WordPiece | Bas | Élevée | Élevé | Analyse fine, langage naturel |
| Unigram | Élevée | Moyenne | Bas | Code binaire, données compactes |
Le BPE est le plus utilisé : 63 % des modèles commerciaux l’emploient. Il est fiable, bien compris, et fonctionne bien sur la plupart des données. Le WordPiece, utilisé par BERT, excelle dans les tâches où chaque détail compte - comme la compréhension de questions ou l’extraction d’entités. Il garde plus de finesse dans les mots rares. Mais il génère plus de tokens, ce qui ralentit tout.
L’Unigram, lui, est le plus efficace en compression. Dans les jeux de données de code assembleur, il réduit la longueur des séquences de 12 à 18 % par rapport au BPE. Cela signifie que vous pouvez traiter 22 % plus de lignes de code par batch. Pour les modèles qui analysent des fichiers binaires ou des logs de serveurs, c’est un avantage majeur.
Les problèmes cachés : les nombres et les langues
Un tokenizer standard ne sait pas traiter les nombres. Il voit "12345" comme cinq caractères : "1", "2", "3", "4", "5". Il ne comprend pas que c’est un nombre. Cela cause des erreurs. Une étude a montré qu’un modèle de finance mal tokenisé avait une erreur de 12,7 % sur les valeurs monétaires. Pourquoi ? Parce que "100" et "1000" sont traités comme des séquences totalement différentes. Le modèle ne voit pas de relation entre eux.
Sur GitHub, plus de 63 % des discussions sur les tokenizeurs concernent les nombres. Des équipes ont résolu ce problème en créant des tokens personnalisés pour les nombres : "
Comment choisir le bon tokenizer pour votre projet
Vous n’avez pas besoin de devenir un expert en tokenization. Voici comment prendre une bonne décision :
- Identifiez votre type de données : texte classique ? code ? chiffres ? langues rares ?
- Choisissez la méthode : BPE pour une solution générale, Unigram pour du code ou des données compactes, WordPiece pour une analyse fine du langage naturel.
- Testez la taille du vocabulaire : commencez avec 25 000. Si votre modèle a trop de tokens "hors vocabulaire", montez à 35 000 ou 50 000. Si la mémoire est un problème, descendez à 15 000.
- Prétraitez vos données : nettoyez les espaces, normalisez les nombres, séparez les symboles monétaires. Cela peut augmenter la cohérence du vocabulaire de 5 à 8 %.
- Utilisez Hugging Face : leur bibliothèque de tokenizeurs est la plus documentée et la plus testée. Évitez les implémentations personnalisées sauf si vous avez un besoin spécifique.
Une équipe chez Nebius a constaté que passer de 32 000 à 64 000 tokens a amélioré la précision de leur modèle de code de 9 %. Mais ça a doublé la mémoire nécessaire. Ils ont dû réduire la taille des batchs. Ce n’était pas une bonne affaire. La clé, c’est l’équilibre.
Le futur : des tokenizeurs intelligents
Les chercheurs ne s’arrêtent pas là. Des équipes comme celles de Google DeepMind travaillent sur des tokenizeurs qui traitent les nombres comme des expressions mathématiques : "
À terme, les tokenizeurs ne seront plus des outils fixes. Ils deviendront des composants dynamiques, ajustés à chaque tâche. Mais pour l’instant, le BPE reste le standard. L’Unigram gagne du terrain dans les applications de code. Et les modèles comme Llama 3, avec leur vocabulaire de 128 000 tokens, montrent que la tendance va vers plus de granularité, pas moins.
Les erreurs à éviter
- Ne pas tester plusieurs tailles de vocabulaire. 3 000 n’est pas un choix par défaut.
- Utiliser le même tokenizer pour du texte et du code. Ce sont deux langages différents.
- Ignorer les nombres. Ils ne sont pas des "mots". Ils méritent une attention spéciale.
- Ne pas prétraiter vos données. Des espaces inutiles ou des guillemets mal gérés peuvent créer des tokens inutiles.
- Croire que "plus de tokens = meilleur modèle". C’est souvent l’inverse.
Quel tokenizer est le meilleur pour un modèle de code ?
Pour le code, l’Unigram ou un BPE avec un vocabulaire large (80 000+ tokens) sont les meilleurs choix. L’Unigram réduit la longueur des séquences de 12 à 18 %, ce qui permet de traiter plus de code en parallèle. Llama 3 et Mistral utilisent des variantes de BPE optimisées pour le code. Évitez WordPiece ici : il crée trop de tokens pour les noms de fonctions.
Pourquoi les modèles échouent-ils sur les nombres ?
Parce que les tokenizeurs standards traitent chaque chiffre comme un caractère séparé. "100" devient trois tokens : "1", "0", "0". "1000" devient quatre tokens. Le modèle ne voit pas qu’il s’agit de la même grandeur, juste plus grande. Cela le rend incapable de faire des comparaisons ou des calculs. Des solutions personnalisées, comme encadrer les nombres avec
Faut-il toujours utiliser un vocabulaire de 128 000 tokens ?
Non. Llama 3 utilise 128 000 tokens pour gérer des langues multiples, du code et des termes techniques. Mais pour un modèle de chat simple en français, 30 000 suffisent. Un vocabulaire trop grand augmente la mémoire, ralentit l’entraînement, et peut introduire du bruit. Le but n’est pas d’avoir le plus grand vocabulaire, mais le plus efficace pour votre données.
Comment savoir si mon tokenizer est mal adapté ?
Regardez trois signes : 1) Votre modèle a beaucoup de tokens "[UNK]" (inconnus). 2) La longueur des séquences est très élevée (plus de 200 tokens pour une phrase courte). 3) Votre modèle échoue sur des tâches simples comme la compréhension de chiffres ou de noms propres. Si vous voyez ça, testez un vocabulaire plus grand ou un autre type de tokenizer.
Le tokenizer affecte-t-il la vitesse d’inférence ?
Oui, et de deux façons. D’abord, un vocabulaire plus grand signifie plus de calculs pour la recherche des tokens. Ensuite, une longueur de séquence plus élevée (due à un mauvais tokenizer) oblige le modèle à traiter plus de tokens à chaque étape. Cela ralentit l’inférence. Un tokenizer efficace peut réduire le temps de réponse de 15 à 25 %.
