Tokenizer Playground — trois familles en comparaison en direct

Pourquoi un Tokenizer Playground ?

Qui travaille avec des modèles de langage tombe tôt ou tard sur un nombre plus important que le nombre de mots : le nombre de tokens. Les tokens sont les unités dans lesquelles les modèles perçoivent le texte — généralement plus petites qu’un mot mais plus grandes qu’une lettre. Le Tokenizer Playground décompose votre texte en direct en exactement ces unités et affiche chaque token comme tile colorée avec token-ID, longueur en octets et offset d’octets.

Contrairement à un compteur de mots classique, un tokenizer éclaire aussi son propre algorithme. Trois familles sont représentées dans le playground : Byte-Pair-Encoding, WordPiece et Unigram. Ce sont les trois écoles dominantes d’où tous les tokenizers multilingues actuels dérivent.

Trois familles, trois stratégies — qu’est-ce qui les distingue ?

Famille BPE (Byte-Pair-Encoding) démarre chaque tokenisation aux caractères individuels. Puis les paires sont fusionnées selon un ordre de fréquence entraîné jusqu’à ce qu’aucune règle ne s’applique plus. Marque de fabrique : un espace devant chaque début de mot est conservé comme caractère spécial (Ġ dans l’affichage) — cela fait de « the » et « the » deux tokens différents. Cette famille est le choix le plus fréquent pour les modèles décodeur-only pour génération de texte. Source : Sennrich, Haddow, Birch 2016.

Famille WordPiece choisit depuis la gauche le plus long sous-mot du vocabulaire qui correspond. Les morceaux suivants à l’intérieur du même mot reçoivent le marqueur de continuation « ## » — ce qui devient play + ##ing. Met typiquement le texte en minuscules avant. On voit cette famille dans les modèles encodeurs bidirectionnels classiques pour classification et compréhension.

Famille Unigram (SentencePiece-style) traite la tokenisation comme problème d’optimisation. Chaque entrée du vocabulaire a une log-probabilité ; Viterbi trouve la segmentation à la somme totale la plus haute. Les débuts de mots portent un marqueur Unicode (▁). Cette famille est le choix standard des modèles encodeur-décodeur multilingues. Source : Kudo 2018.

Que me montre la heatmap multilingue ?

L’onglet heatmap prend un contenu identique — le pangram classique « le renard brun rapide saute par-dessus le chien paresseux » — et le traduit en six langues : anglais, allemand, français, espagnol, japonais et arabe. Pour chaque langue, le playground compte les mots (sur une frontière de mot Unicode) et les tokens (selon la famille choisie) et calcule le ratio tokens par mot. Au-delà de 2 cela devient cher ; au-delà de 4, la langue est structurellement désavantagée.

Le phénomène est bien documenté. Une étude de 2023 a montré que la même traduction dans 22 langues produit des différences de tokens de 1,5 à 14 fois — avec l’anglais toujours au moins coûteux. La heatmap dans le playground montre immédiatement cet effet : l’anglais atterrit typiquement à 1,0–1,3 tokens par mot, l’allemand à cause des composés à 1,5–2,0, le japonais à cause de l’ambiguïté des frontières de mots à 2,5 et plus.

Comment la trace algorithme montre-t-elle la tokenisation pas à pas ?

Une boîte noire est difficile à apprendre. C’est pourquoi l’onglet étapes d’algorithme montre le déroulement complet de la tokenisation sur votre input actuel. En BPE, l’input est d’abord décomposé en caractères individuels. Puis à chaque étape, la paire au plus haut rang de merge est fusionnée et le résultat intermédiaire est affiché. Vous voyez par ex. : « merge ‘t’ + ‘h’ → ‘th’ (règle #1) », puis « merge ‘th’ + ‘e’ → ‘the’ (règle #22) », puis « plus de merge possible — fini ».

En WordPiece chaque étape paraît différente. La trace montre le curseur gauche et le sous-mot match : « match ‘play’ (4 caractères) », puis « match ‘##ing’ (3 caractères) ». Si aucun sous-mot n’est trouvé, vient « pas de match en position N — [UNK] » et le passage finit. En Unigram la trace montre le Viterbi-backtrack.

Que signifie le token-ID à côté de chaque morceau ?

Chaque tokenizer a une table de mapping fixe : token-string → token-ID. L’ID est le nombre que le modèle reçoit réellement — la chaîne n’est que la forme lisible. Dans le playground, l’ID est affiché à côté de chaque tile. Token-ID = -1 signifie : ce morceau n’est pas inclus dans le vocabulaire-échantillon. Le tokenizer retombe alors sur caractères individuels, ce qui fait monter le nombre de tokens.

C’est exactement le comportement out-of-vocabulary des vrais tokenizers en pratique. Visible sur noms propres rares, termes techniques, insertions étrangères ou emoji.

À quoi sert la comparaison 3-familles ?

Dans l’onglet comparaison, votre input passe en parallèle par les trois familles. Directement au-dessus, trois compteurs de tokens et une valeur Δ — la différence avec la famille la plus efficace. C’est la réponse à une question récurrente en pratique : « Est-ce que j’économise des tokens si je change de famille ? » La réponse dépend de l’input. Le texte anglais clair est très similaire dans les trois. Le code source est nettement plus compact en BPE car les règles de merge apprennent les séquences de code fréquentes. Le texte CJK est plus efficace en Unigram (avec bon vocabulaire SentencePiece) car des tokens multi-caractères existent pour syllabes fréquentes.

Qu’est-ce qui n’est volontairement pas dans le playground ?

Trois fonctions sont hors scope. Premièrement : pas de calculateur de coûts en euros ou dollars — ils changent souvent et sont vendor-spécifiques. Deuxièmement : pas de chat-template builder. Différents modèles utilisent différentes conventions, et un template builder s’habitue trop vite à un modèle. Troisièmement : pas d’upload de vocabulaire — ce serait un risque de sécurité.

Ces lacunes sont voulues. Elles gardent le playground léger, rapide et vendor-neutre. Qui a besoin d’une estimation exacte des coûts de tokens pour un modèle donné utilise son tokenizer officiel.

Confidentialité et RGPD

Votre texte reste dans la mémoire du navigateur. Pas de serveur, pas de localStorage, pas de cookies, pas d’analytics, pas de requête réseau. Dans l’onglet réseau des DevTools, rien n’apparaît après le chargement de la page. Fermez l’onglet et tout est effacé.

Du point de vue RGPD, aucune donnée personnelle au sens de l’art. 4 n’est traitée car le traitement a lieu localement sur votre appareil. Même les prompts sensibles (extraits de code, notes personnelles, textes juridiques) restent dans l’onglet. Cette architecture rend le playground utilisable en environnements enterprise à compliance stricte.