Des LLM qui voient chaque lettre inversent plus facilement les mots

L'expression « LMU München » compte 11 caractères, espace compris. Le modèle de langage qui fait tourner ChatGPT la reçoit en trois morceaux : « LM », « U » et « München ». Il ne voit pas directement les lettres isolées du mot « München ». Cette particularité explique toute une catégorie d'erreurs étranges : le comptage des lettres dans un mot, les corrections caractère par caractère, l'écriture à l'envers. D'après TechXplore, des chercheurs ont montré qu'un modèle adapté pour voir chaque lettre inverse plus facilement un mot.

Pourquoi le modèle ne voit pas les lettres

Avant de traiter un texte, un LLM le découpe en tokens : des mots entiers ou des fragments de mots. Cette étape s'appelle la tokenisation en sous-mots. Elle sert l'efficacité : la séquence est plus courte, donc moins coûteuse en calcul. Les mots fréquents deviennent un seul token, les mots rares sont assemblés à partir de plusieurs.

Cette économie a un prix. Pour le modèle, le token « München » reste un identifiant indivisible. Pour inverser ce mot, il doit savoir de quelles lettres il se compose, et il ne peut pas l'apprendre directement. Il doit reconstituer indirectement son savoir orthographique, à partir de textes d'entraînement où l'on épelle parfois les mots. Le résultat n'est pas fiable. Les modèles ont donc une compréhension limitée au niveau des caractères, et le matériau source le dit explicitement.

Que signifie « voir chaque lettre » ?

Le fragment de publication disponible ne décrit pas la conception de cette amélioration. Il ne donne pas non plus la taille des modèles, la précision ni les benchmarks : il n'y aura donc pas ici de chiffres d'amélioration. Le principe général ressort du titre : le modèle accède aux caractères individuels, et non plus seulement à des blocs déjà formés.

Dans l'industrie, on recourt généralement pour cela à des modèles au niveau du caractère ou de l'octet, ou l'on ajoute un niveau caractère au-dessus des tokens. Mais cette approche a aussi un coût : les séquences s'allongent. Or le coût de l'attention dans les transformeurs croît plus vite que la longueur de l'entrée. La question n'est donc pas de savoir si l'accès aux caractères aide. Il aide. La question est de savoir combien de calcul il faudra payer en échange.

Ce que l'on sait du matériau, en bref :

• Exemple de découpage : « LMU München » donne 3 tokens (« LM », « U », « München ») pour 11 caractères.
• Mécanisme du problème : la tokenisation en sous-mots cache au modèle les lettres individuelles.
• Tâche de test : l'écriture des mots à l'envers.
• Résultat : les modèles qui voient chaque lettre s'en sortent plus facilement.
• Non précisé dans le texte disponible : l'architecture, la taille des modèles, les métriques chiffrées.

Que faire côté développeurs

Tant que de tels modèles ne sont pas devenus la norme, mieux vaut ne pas confier aveuglément les opérations sur les caractères à un LLM dans vos produits. Vérification de codes et de numéros, anagrammes, translittération, comparaison caractère par caractère, correction de fautes de frappe dans les noms : un code classique fait tout cela de façon plus fiable. Dans ces scénarios, il vaut mieux appeler le modèle comme un orchestrateur qui délègue la tâche à un outil, et non comme un exécutant.

Il faut être particulièrement prudent avec les langues aux mots riches en morphologie. Les tokenizers allemand et russe découpent généralement plus finement que l'anglais, et les erreurs sur les caractères y apparaissent plus souvent. Si vous choisissez un modèle pour ce type de travail, testez-le sur vos propres données : inversez une dizaine de vos chaînes réelles et regardez le résultat.

Pour juger l'étude elle-même, mieux vaut attendre le texte complet, chiffres à l'appui. La piste semble raisonnable, mais la question principale reste ouverte : le gain en précision sur les caractères suffira-t-il à justifier la hausse du coût de calcul ?