Le texte népalais « pesait » trois fois plus que l'anglais — le tokeniseur n'a jamais totalement résolu le problème

Pourquoi le texte népalais coûte-t-il autant de tokens

Une équipe de chercheurs a compris pourquoi des modèles de langage comme Llama-3 et Qwen3 traitent le texte népalais de manière aussi dispendieuse — et a tenté de corriger le problème. Il s'avère que le défaut ne se situe pas dans le vocabulaire du modèle, mais dans la toute première étape, la plus discrète, du traitement du texte : la pré-segmentation en fragments, qui intervient avant même que le tokeniseur ne commence à assembler les tokens.

Les tokeniseurs de type GPT-2, sur lesquels sont construits Llama-3 et Qwen3, découpent le texte à l'aide d'une expression régulière avant la tokenisation proprement dite. Cette expression ne considère comme « mot » qu'une séquence de lettres Unicode. Le problème, c'est que le népalais utilise l'écriture devanagari, où les voyelles ne sont pas représentées par des lettres distinctes mais par des signes spéciaux placés au-dessus ou au-dessous de la lettre principale — les fameux signes combinants. Dans Unicode, ces signes ne sont formellement pas considérés comme des « lettres », si bien que l'expression régulière découpe littéralement un mot népalais à chaque signe vocalique.

Résultat : là où un anglophone ne dépense qu'un seul token, le même contenu en népalais nécessite, sur les mêmes modèles, 2 à 3 fois plus de tokens pour transmettre la même quantité de sens. Les auteurs ont mesuré ce phénomène sur le corpus parallèle FLORES-200 (les mêmes phrases dans différentes langues) — le tokeniseur de Qwen3 consomme sensiblement plus de tokens pour une phrase népalaise que pour sa traduction anglaise, et le tokeniseur utilisé par Phi-4, OLMo-2 et Granite-4.1 fait encore pire.

Pour les utilisateurs, ce n'est pas une mesure abstraite. Plus de tokens pour le même sens signifie une requête plus coûteuse, une réponse plus lente et moins de contenu utile pouvant tenir dans la fenêtre de contexte du modèle.

Pourquoi le simple « bricolage » du vocabulaire ne suffit pas

La méthode standard pour apprendre à un modèle déjà entraîné à mieux gérer une nouvelle langue est l'extension de vocabulaire par fusion (merge-based vocabulary extension) : on ajoute au vocabulaire de nouveaux tokens fusionnés, que le modèle apprend à partir du texte de la nouvelle langue. Le problème, c'est que la segmentation par expression régulière intervient avant toute fusion — et si un mot a déjà été découpé en fragments au niveau des signes vocaliques, aucune quantité de nouvelles fusions ne pourra recoller les morceaux séparés par cette coupure. Les auteurs démontrent qu'une telle approche possède un « plafond » mathématique d'économie, qui ne dépend que de l'expression régulière, et non de la taille du vocabulaire.

Ils ont vérifié cela sur des versions réellement publiées : ils ont trouvé dix extensions de vocabulaire publiées précédemment pour six écritures différentes (pour Llama-3, Llama-3.1, Qwen2.5 et Qwen3) — et les dix se sont heurtées à leur plafond respectif, en en extrayant au moins 98 % de l'économie possible. Autrement dit, les développeurs de ces modèles avaient déjà fait tout ce qui était réalisable par les méthodes standard — poursuivre dans cette voie pour le vocabulaire n'a plus de sens.

Les auteurs ont également testé une échappatoire : il est possible d'enregistrer des chaînes népalaises comme des « tokens ajoutés », qui ne passent pas du tout par l'expression régulière. Cela permet effectivement de dépasser le plafond, mais cela brise les frontières entre les mots — un cinquième de ces tokens se met alors à matcher en plein milieu d'un mot, ce qui nuit à la cohérence de la segmentation.

Ce qu'a apporté la « réparation » de l'expression régulière

Les chercheurs ont réécrit l'expression régulière elle-même pour que les signes vocaliques du devanagari soient considérés comme faisant partie du mot, et non comme des caractères séparés. Propriété importante de leur correction : ils ont démontré mathématiquement que pour tout texte sans signes combinants ni caractères devanagari (c'est-à-dire pour l'anglais et le code), la tokenisation reste absolument identique à l'ancienne — aucun token ne change.

Avec la nouvelle expression régulière et 32 000 nouvelles paires fusionnées, le texte népalais nécessite désormais presque autant de tokens que l'anglais — soit 54 % de tokens en moins que l'extension de vocabulaire classique.

Mais lors du réentraînement réel des modèles Llama-3.2-1B et Qwen3-0.6B sur un mélange de textes népalais et anglais, le résultat s'est révélé inattendu : à budget égal, le tokeniseur original « non corrigé » a affiché une meilleure qualité de prédiction du texte népalais (mesurée en bits par octet) que les versions corrigée et classiquement étendue. C'était pourtant l'hypothèse principale des auteurs — et elle ne s'est pas confirmée.

À nombre d'étapes d'entraînement égal (et non en octets), le tokeniseur corrigé s'est révélé meilleur sur Qwen, mais moins bon sur Llama — le gain s'avère donc incohérent d'un modèle à l'autre. L'augmentation de la vitesse d'entraînement sur Qwen a amélioré les résultats des trois variantes, sans changer leur ordre relatif.

Ce que cela signifie en pratique

Pour les ingénieurs qui réentraînent des modèles ouverts pour des langues utilisant des signes combinants (pas seulement le népalais, mais aussi, par exemple, le thaï, l'arabe ou le bengali), la conclusion est double. D'une part, l'économie de tokens est réelle et confirmée mathématiquement — le tokeniseur corrigé consomme honnêtement 54 % de tokens en moins pour le même texte népalais, sans toucher à l'anglais ni au code. D'autre part, moins de tokens ne signifie pas automatiquement un meilleur modèle : les auteurs montrent explicitement que, dans leurs tests, l'ancien tokeniseur « non corrigé » reste supérieur en qualité à budget de calcul égal.

Une question reste ouverte, que les auteurs n'ont honnêtement pas vérifiée : l'économie de tokens apporte-t-elle, en pratique, un gain de vitesse et de coût pour la génération de texte, même si la qualité est légèrement inférieure. Le code, les tokeniseurs entraînés et le plan d'analyse ont été publiés en open source sur GitHub et Hugging Face.