Pourquoi les LLM ne savent pas compter les lettres, les mots… et parfois même les tokens

Le test le plus connu sur les LLM est presque comique.

Ce n’est pas une démo impressionnante. Ce n’est pas une question de physique théorique. Ce n’est même pas un problème difficile.

C’est souvent un truc du genre : combien y a-t-il de r dans strawberry ?

La réponse est simple : 3.

Et pourtant, des modèles capables de résumer des rapports, écrire du code ou expliquer des sujets compliqués se sont longtemps trompés sur ce genre de question.

À première vue, ça ressemble à une absurdité. En réalité, c’est l’un des meilleurs moyens de comprendre ce qu’un LLM fait vraiment.

Parce que non, la vraie explication n’est pas juste : “il voit des tokens au lieu de voir des lettres”.

C’est une partie de l’histoire. Pas toute l’histoire.

Et c’est justement là que le sujet devient intéressant.

La réponse courte

Si on veut être honnête, les LLM comptent mal pour plusieurs raisons à la fois.

D’abord, ils ne représentent pas le texte comme nous. Un mot n’est pas forcément traité comme une suite claire de lettres, mais comme une ou plusieurs unités statistiques qu’on appelle des tokens.

Ensuite, compter n’a rien d’un simple réflexe linguistique. C’est une petite procédure exacte. Il faut découper correctement, garder le fil, incrémenter sans se tromper et sortir le bon total à la fin.

Le problème, c’est qu’un LLM n’a pas été conçu d’abord pour ça. Son métier, c’est de prédire la suite la plus plausible dans du langage. Pas de jouer le rôle d’un compteur parfait.

Et les travaux récents ajoutent une nuance encore plus intéressante : dans certains cas, le modèle semble avoir une partie de la bonne information en interne… puis se trompe quand il faut la faire sortir proprement.

Donc oui, la tokenisation joue un rôle. Surtout pour les lettres.

Mais si on s’arrête là, on rate le vrai sujet.

Ce qu’un LLM “voit” vraiment

Quand nous lisons un mot, nous voyons naturellement des lettres.

strawberry, pour nous, c’est une suite explicite de caractères. Si on veut compter les r, on peut presque les pointer du doigt un par un.

Un LLM, lui, n’aborde pas le texte comme ça.

Avant même qu’il “réfléchisse”, le texte passe par une étape de tokenisation. En gros, on le découpe en morceaux statistiques. Ces morceaux peuvent être un mot entier, une partie de mot, un espace, une ponctuation, parfois autre chose encore.

C’est très efficace pour traiter le langage à grande échelle. C’est même une partie de la raison pour laquelle les LLM marchent aussi bien.

Mais ça crée un décalage.

Nous, on voit une chaîne de lettres. Le modèle, lui, reçoit plutôt une chaîne d’unités optimisées pour modéliser le langage.

Et ce décalage suffit déjà à compliquer le comptage des lettres.

Pas à l’expliquer entièrement. Juste à le compliquer sérieusement.

Pourquoi compter nous paraît trivial

Le vrai piège vient de là.

Compter paraît simple parce que, pour nous, c’est presque automatique. On regarde, on avance, on garde un total, et terminé.

Mais si on prend deux secondes pour y penser, compter est en fait une opération très stricte.

Il faut :

• choisir la bonne unité
• ne rien oublier
• ne pas compter deux fois
• garder un état intermédiaire fiable
• produire un résultat exact à la fin

Autrement dit, compter ressemble beaucoup plus à un mini algorithme qu’à une simple intuition.

Et c’est là que la différence entre un humain, un programme classique et un LLM devient importante.

Un programme déterministe peut compter parfaitement s’il a les bonnes règles.

Un humain sait souvent le faire facilement sur de petits cas.

Un LLM, lui, produit une réponse à partir de régularités apprises dans le langage. Il peut être très bon, parfois bluffant, mais ça ne lui donne pas automatiquement une mécanique interne de comptage exact.

C’est toute la nuance.

On confond souvent intelligence linguistique et fiabilité algorithmique.

Ce n’est pas la même chose.

Pourquoi les lettres posent un problème particulier

Les lettres sont le cas le plus frappant, parce que c’est celui qui heurte le plus notre intuition.

Pour nous, un mot est composé de lettres. Donc compter les lettres semble être le test le plus basique du monde.

Pour un LLM, ce n’est pas forcément le bon niveau de lecture.

Les lettres sont souvent enfouies dans des tokens plus gros. Le modèle doit donc reconstruire, d’une certaine manière, la structure fine du mot. Et là, ça se complique.

C’est pour ça que strawberry est devenu un cas emblématique. Ce n’est pas juste une blague internet. C’est un exemple parfait d’une tâche qui paraît minuscule à un humain, mais qui force le modèle à travailler à un niveau qui n’est pas son niveau naturel.

Et plus le mot s’allonge, plus la lettre apparaît plusieurs fois, plus la difficulté monte.

C’est important, parce que ça montre déjà que le problème ne se résume pas à “il n’a pas vu la bonne lettre”. Très souvent, il a bien repéré ce qu’on lui demande. Ce qu’il rate, c’est l’opération de comptage elle-même.

Mais alors pourquoi les LLM ratent aussi le comptage des mots ?

C’est la bonne objection.

Parce que si on disait simplement : “les LLM sont mauvais pour les lettres parce qu’ils ne voient pas les lettres”, on n’expliquerait pas pourquoi ils se trompent aussi parfois sur le nombre de mots dans une phrase.

Et c’est exactement pour ça que l’explication “c’est juste les tokens” est trop courte.

Compter des mots est souvent un peu plus facile que compter des lettres, parce que la segmentation est plus visible. Il y a des espaces. Il y a des blocs plus apparents. On peut demander au modèle de lister les mots avant de donner le total.

Mais même là, il reste le cœur du problème : il faut compter proprement.

Et ça veut dire :

• segmenter correctement
• garder le bon nombre en mémoire
• ne pas dériver en route
• restituer un total exact

En d’autres termes, les mots enlèvent une partie du problème de granularité. Ils n’enlèvent pas le problème du comptage exact.

C’est pour ça qu’on observe encore des erreurs. Moins absurdes visuellement que strawberry, peut-être. Mais conceptuellement, elles racontent la même chose.

Et les tokens alors ? Un LLM peut-il au moins compter ses propres tokens ?

Ici, il faut distinguer deux choses.

Première chose : le système autour du modèle peut compter les tokens exactement. Avec un tokenizer externe, on peut prendre une phrase et savoir précisément combien de tokens elle contient.

Deuxième chose : le modèle lui-même est-il capable de répondre de façon fiable à la question “combien de tokens y a-t-il ici ?”

Pas vraiment, en tout cas pas de manière native et robuste.

Pourquoi ? Parce que le tokenizer agit avant le modèle. Il prépare l’entrée, mais ça ne veut pas dire que le modèle possède ensuite une capacité explicite, stable et accessible pour compter ces unités exactement.

Voir une séquence tokenisée n’est pas la même chose que savoir la dénombrer sans erreur.

Et ça, on le retrouve aussi dans un autre domaine : le contrôle de longueur. Les chercheurs ont montré que les LLM dépassent ou ratent souvent un nombre exact de mots ou de tokens demandés, sauf si on leur ajoute un guidage particulier, comme un décompte explicite pendant la génération.

Là encore, le message est simple : le problème n’est pas seulement “qu’est-ce que le modèle voit ?” Le problème, c’est aussi “est-ce qu’il sait compter exactement ce qu’il voit ?”

Pourquoi la vraie réponse est plus profonde que “c’est la tokenisation”

La meilleure façon de le dire aujourd’hui, c’est que le problème est multicouche.

Il y a d’abord un problème de représentation. Pour les lettres surtout, la granularité de départ est mauvaise.

Il y a ensuite un problème de procédure. Compter, ce n’est pas juste reconnaître. Il faut accumuler proprement.

Il y a aussi un problème de généralisation. Un modèle peut réussir sur des cas courts ou familiers, puis se dégrader dès que la longueur augmente ou que la structure change un peu.

Et enfin, il y a peut-être un problème de sortie. Certaines recherches récentes suggèrent que la bonne information peut parfois être présente à l’intérieur du modèle, puis mal utilisée au moment de produire la réponse finale.

C’est ça qui rend le sujet passionnant.

Pendant longtemps, beaucoup de discussions sur internet donnaient l’impression qu’on avait déjà la réponse : “ils voient des tokens, fin de l’histoire”.

En réalité, non.

On comprend mieux qu’avant pourquoi ils se trompent. Mais on ne peut pas réduire ça à une seule cause propre et élégante.

Ce que les papiers récents montrent vraiment

Les travaux récents racontent globalement la même histoire, avec quelques nuances importantes.

D’un côté, ils confirment que la tokenisation joue un vrai rôle. Quand on force une décomposition caractère par caractère, les performances montent souvent. Donc oui, la façon dont le texte entre dans le modèle compte énormément.

Mais de l’autre côté, ces mêmes travaux montrent que ce n’est pas suffisant pour expliquer toutes les erreurs.

La longueur du mot compte. Le nombre de répétitions compte. La structure de la tâche compte. Et sur certaines expériences, les propriétés de tokenisation sont moins prédictives qu’on l’imaginait.

Autrement dit, la tokenisation gêne clairement. Mais le cœur du problème touche aussi aux limites du modèle sur les tâches de comptage exact.

Et c’est encore plus visible dès qu’on sort du cas des lettres. Si le modèle se trompe aussi sur des mots, sur des longueurs exactes, ou sur d’autres formes de décompte, alors on est obligé de reconnaître que la cause est plus générale.

Ce que ça change en pratique

Cette histoire n’est pas juste théorique.

Elle change la manière dont il faut utiliser les LLM.

Si vous avez besoin d’un comptage fiable, surtout dans un contexte produit ou métier, le bon réflexe n’est pas de demander au modèle une réponse directe et de la croire sur parole.

Le bon réflexe, c’est soit :

• de lui faire expliciter les étapes
• de lui faire lister ce qu’il compte
• de lui faire vérifier son propre résultat
• ou, mieux encore, de déléguer le comptage à un outil déterministe

C’est une vraie leçon d’architecture.

Un bon système à base de LLM ne suppose pas que le modèle doit être excellent sur tout. Il utilise le modèle là où il est fort, et il confie les opérations exactes à des outils qui, eux, ne dérivent pas.

C’est aussi pour ça que le cas strawberry est utile.

Pas parce qu’il ridiculise les LLM.

Parce qu’il rappelle qu’un modèle peut être brillant dans certains usages, et structurellement fragile dans d’autres.

Conclusion

Le cas strawberry a fait rire beaucoup de monde. C’est normal.

Mais si on le prend au sérieux, il dit quelque chose de beaucoup plus important qu’un simple “gotcha” viral.

Il nous rappelle qu’un LLM ne lit pas comme un humain. Qu’il ne compte pas comme un programme. Et qu’il ne faut pas confondre production de langage convaincante et exactitude algorithmique.

La mauvaise explication, c’est : “les LLM sont nuls pour compter.”

L’explication un peu meilleure, c’est : “la tokenisation complique beaucoup le comptage des lettres.”

Mais l’explication la plus juste aujourd’hui, c’est celle-ci :

Les LLM comptent mal parce que le comptage exact demande la bonne granularité de représentation, une mémoire de travail discrète, une accumulation fiable, une bonne généralisation et une sortie correcte. Or les modèles de langage standards ne sont naturellement parfaits sur aucun de ces points.

Et c’est précisément pour ça qu’ils peuvent être impressionnants sur des tâches très complexes… tout en restant fragiles sur un comptage qui paraît évident à un humain.