Comment les LLM voient le texte : ce que mon système i18n m'a appris sur l'économie des tokens

Lorsque j’ai construit le système de traduction i18n de mon site, j’ai découvert que traduire un article de blog de 1 500 mots en anglais vers le coréen consommait 2,8 fois plus de tokens que la source anglaise. Le même contenu sémantique, le même sens, mais 2,8 fois le coût API. Le japonais atteignait 2,4x. Le chinois traditionnel 2,1x. L’espagnol 1,15x. L’économie des tokens du contenu multilingue m’a pris au dépourvu parce que je n’avais pas compris le fonctionnement des tokeniseurs.¹

TL;DR

La tokenisation convertit du texte lisible par l’humain en tokens numériques que les modèles de langage traitent. Après avoir traduit 27 articles de blog en 6 langues, je dispose de données de coût réelles : les scripts non latins consomment 2 à 3 fois plus de tokens par unité sémantique que l’anglais. Le visualiseur interactif ci-dessous vous permet de coller du texte dans n’importe quelle langue et de voir la décomposition en tokens. Comprendre la tokenisation m’a aidé à budgétiser mon pipeline de traduction avec précision, à optimiser mes prompts pour réduire les coûts de 35 %, et à déboguer un problème de formatage où les traductions coréennes perdaient la structure markdown parce que le tokeniseur découpait les marqueurs de notes de bas de page à travers les frontières de tokens.

Mes données de coût i18n par token

J’ai traduit 27 articles de blog en 6 langues en utilisant Claude. La qualité de traduction exigeait des modèles de niveau Opus (jamais de modèles moins coûteux — une leçon que j’ai apprise quand Haiku produisait des traductions qui ressemblaient à de la sortie machine). La consommation de tokens par langue m’a surpris :

Les langues à script latin (espagnol, allemand, français) sont restées dans les 20 % de l’anglais. Les langues CJK et Hangul ont bondi de 2 à 3x. La différence de coût se compose sur 27 articles × 6 langues = 162 traductions.²

Pourquoi cet écart existe

La plupart des tokeniseurs (BPE, utilisé à la fois par Claude et GPT-4) sont entraînés principalement sur du texte anglais. Les mots anglais ont des représentations de tokens optimisées parce que les données d’entraînement contiennent plus d’anglais que n’importe quelle autre langue. Les mots anglais courants (« the », « and », « is ») correspondent à des tokens uniques. Les blocs syllabiques coréens, les kanji japonais et les caractères chinois se divisent souvent en 2 à 3 tokens au niveau des octets parce que le tokeniseur les a rencontrés moins fréquemment pendant l’entraînement.³

L’effet est systématique, pas aléatoire. Chaque traduction coréenne coûte environ 2,8x l’équivalent anglais. Je peux budgétiser avec précision parce que le multiplicateur est constant.

Le bug de tokenisation

Lors de mon premier lot de traductions coréennes, les articles traduits ont perdu tout leur formatage markdown : les références de notes de bas de page ([^1]) ont disparu, les blocs de code ont perdu leurs balises de langage, et les marqueurs de titre (##) se sont fondus dans le corps du texte.

Le diagnostic a pris une heure. La cause racine : mon prompt de traduction disait « Traduisez cet article de blog en coréen » sans spécifier la préservation du formatage. Le tokeniseur découpait la syntaxe markdown à travers les frontières de tokens différemment en contexte coréen qu’en contexte anglais. Le modèle traitait [^1] comme du contenu traduisible plutôt que comme du balisage structurel.

La correction : j’ai ajouté des contraintes explicites à mon prompt de traduction :

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

Chaque contrainte a éliminé un mode de défaillance. La liste de contraintes est devenue plus longue que l’instruction de traduction — un schéma que je décris dans mon framework de prompt engineering OODA.⁴

Ce que sont les tokens

Des caractères aux tokens

Une approche naïve du traitement de texte traiterait chaque caractère comme une unité d’entrée. « Hello world » devient 11 caractères. Le traitement au niveau des caractères capture chaque détail mais produit des séquences extrêmement longues : un document de 1 000 mots devient environ 5 000 caractères.⁵

Le traitement au niveau des mots réduit la longueur des séquences mais échoue sur les mots inconnus. Un vocabulaire de 50 000 entrées au niveau des mots ne peut pas traiter « unfathomability » à moins que ce mot exact ne soit apparu dans l’entraînement.

La tokenisation en sous-mots trouve un compromis. Les mots courants (« the », « and ») restent des tokens uniques. Les mots rares se divisent en sous-unités. « Unfathomability » se divise en [« un », « fath », « om », « ability »], où chaque partie apparaît suffisamment fréquemment pour avoir une représentation entraînée.

Byte-Pair Encoding (BPE)

Le BPE, utilisé par Claude et GPT-4, commence avec des octets individuels et fusionne itérativement les paires adjacentes les plus fréquentes :⁶

1. Commencer avec les caractères individuels : [l, o, w, e, r]
2. Paire la plus fréquente : (l, o) → fusion en [lo, w, e, r]
3. Paire la plus fréquente : (e, r) → fusion en [lo, w, er]
4. Paire la plus fréquente : (lo, w) → fusion en [low, er]
5. Paire la plus fréquente : (low, er) → fusion en [lower]

Le vocabulaire final contient tous les octets originaux plus chaque token fusionné, généralement entre 50 000 et 100 000 entrées. Les mots anglais dominent les tokens fusionnés parce que l’anglais domine les données d’entraînement.

Comment j’ai optimisé mes prompts

Après avoir découvert l’écart de coût en tokens, j’ai optimisé mon pipeline de traduction pour réduire les coûts de 35 % :

Optimisation 1 : regrouper par famille linguistique

Les langues à script latin (espagnol, français, allemand) partagent des similitudes structurelles. Je regroupe le prompt de traduction pour produire les trois dans un seul appel API lorsque l’article source est suffisamment court pour tenir dans la fenêtre de contexte avec les trois sorties. Le contexte partagé (la source anglaise) est payé une seule fois au lieu de trois.⁷

Optimisation 2 : déduplication des contraintes

Mon prompt de traduction original répétait les contraintes pour chaque langue. La version optimisée définit les contraintes une seule fois et les applique à toutes les sorties :

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

La section de contraintes consomme des tokens une seule fois. L’alternative (répéter les contraintes par langue) en consomme 3x.

Optimisation 3 : instructions concises

Mon prompt original utilisait 340 tokens d’instructions. Après optimisation : 180 tokens. La réduction de 47 % se compose sur 162 traductions.

Les langues CJK bénéficient moins de l’optimisation des prompts parce que les tokens de sortie (la traduction elle-même) dominent le coût. La sortie est intrinsèquement plus longue en termes de tokens, quelle que soit la concision des instructions.⁸

Applications pratiques

Estimer les coûts

Une heuristique approximative pour le texte anglais : 1 token correspond à environ 0,75 mot, soit environ 4 caractères. Un document de 1 000 mots consomme environ 1 333 tokens. Appliquez le multiplicateur linguistique de mon tableau ci-dessus pour le contenu non anglais.⁹

Tokenisation du code

Le code se tokenise différemment de la prose. Les mots-clés courants (def, return, if) correspondent à des tokens uniques. Les noms de variables se divisent en fonction de leur fréquence :

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

Des conventions de nommage cohérentes réduisent le nombre de tokens. Mon infrastructure de hooks utilise la convention verb-noun.sh (git-safety-guardian, recursion-guard, blog-quality-gate). Le schéma cohérent aide le tokeniseur à prédire et fusionner les sous-mots courants efficacement.

Déboguer un comportement inattendu

Lorsqu’un modèle produit une sortie inattendue, la tokenisation peut expliquer pourquoi. Mon bug de formatage coréen s’est produit parce que le tokeniseur découpait [^1] différemment en contexte coréen qu’en contexte anglais. Comprendre le schéma de découpage a mené directement à la correction (contraintes de préservation explicites).

Points clés à retenir

Pour les ingénieurs utilisant des API de LLM : - Mesurez les coûts en tokens par langue avant de vous engager dans un support multilingue ; les langues CJK coûtent 2 à 3 fois plus par unité sémantique que l’anglais - Optimisez les instructions des prompts (formulation concise, contraintes dédupliquées) pour une réduction de coût de 30 à 50 % sur les pipelines de traduction à haut volume - Testez la tokenisation des termes spécifiques au domaine et de la syntaxe markdown avant le déploiement en production ; des découpages inattendus causent des bugs de formatage

Pour les chefs de produit budgétisant des fonctionnalités IA : - Le support des langues non anglaises coûte 1,5 à 3 fois plus par appel API que l’anglais ; budgétisez les fonctionnalités IA multilingues en utilisant le multiplicateur linguistique, et non une estimation forfaitaire par langue - Les limites de fenêtre de contexte affectent les langues CJK de manière disproportionnée ; une fenêtre de 200K tokens contient 40 % de contenu coréen en moins que de contenu anglais

Références