Skip to main content
LLMтокенизацияprompt engineering

Pourquoi les LLM ne savent pas compter les lettres

Les LLM se trompent souvent en comptant les lettres non par bêtise, mais à cause de la tokenisation : le modèle voit des tokens, pas des caractères individuels. Pour les entreprises, comprendre cela est vital en implémentation d'IA, car les tâches nécessitant une précision au niveau des symboles doivent être directement confiées au code ou à des outils externes.

Contexte technique

Je vois régulièrement le même 'test de la fraise' : combien de lettres dans un mot, combien de 'r', pourquoi le modèle raconte n'importe quoi. Et oui, pour le prompt engineering c'est un test utile, non pas de l'intelligence du modèle, mais de la compréhension de son architecture et de la manière dont vous construisez l'automatisation IA autour de lui.

Le problème est très terre-à-terre : un LLM ne lit pas un mot comme une séquence de caractères. Il reçoit des jetons (tokens), généralement des morceaux de mots assemblés par un tokenizer comme BPE. Pour lui, 'strawberry' n'a pas à exister comme s-t-r-a-w-b-e-r-r-y. Souvent, c'est 1 à 2 tokens avec une structure interne déjà 'empaquetée'.

Dans ces cas-là, je freine immédiatement les équipes qui veulent mesurer l'intelligence du modèle avec des tâches quotidiennes. Compter les lettres, les positions des caractères, les masques précis, les opérations simples sur les chaînes sans outil cassent souvent même les grands modèles. Ce n'est pas un bug du style 'l'entraînement n'a pas été assez poussé', mais une limitation fondamentale de la représentation du texte.

Il y a une nuance : parfois le modèle répond mieux en anglais, parfois moins bien, mais le fond ne change pas. La langue influence la tokenisation, elle ne l'annule pas. Si une tâche exige une précision au niveau des caractères, demander au modèle de 'réfléchir encore' est presque toujours pire que de lui demander d'écrire et d'exécuter un court script.

C'est là que commence une véritable intégration IA : je ne force pas le LLM à compter ce qu'un interpréteur devrait compter. Je donne au modèle le rôle d'orchestrateur. Qu'il génère du Python, du SQL ou du JS, et que l'environnement d'exécution fasse l'opération précise.

Ce que cela change pour les entreprises et l'automatisation

La conclusion pratique est simple : ne faites pas transiter les opérations sur les chaînes, l'arithmétique et les opérations vérifiables directement par la réponse du modèle. Sinon, vous obtiendrez un joli texte avec du hasard dedans.

Les équipes qui gagnent sont celles qui construisent des solutions d'IA pour les entreprises comme un combo 'LLM + outils', et non comme un chat magique. Celles qui essaient de fourrer à la fois le raisonnement et l'exécution précise dans un seul prompt perdent.

Je vois constamment ce schéma chez les clients lors de l'analyse de courriels, de contrats, de catalogues et de logs de support. Dès que l'on externalise les étapes précises dans du code, la qualité grimpe en flèche et le coût des erreurs chute. Si vous avez une histoire similaire et que vous avez besoin non pas d'un énième chatbot, mais d'une automatisation IA cohérente, chez Nahornyi AI Lab nous pouvons construire une telle boucle pour votre processus sans magie superflue et avec une vraie vérifiabilité des résultats.

Nous avons analysé précédemment comment les proxys LLM et les couches d'abstraction aident à réduire le vendor lock-in, et pourquoi les modérateurs marquent souvent à tort les articles techniques comme du contenu généré par l'IA. C'est un autre exemple de la façon dont les modèles linguistiques peuvent mal interpréter le texte, de la même manière que la tokenisation les empêche de compter les lettres.

Partager cet article