💬 NLP

Semantic Content Determines Algorithmic Performance

L'article introduit « WhatCounts », un benchmark atomique démontrant que les LLM de pointe échouent à implémenter des algorithmes véritablement invariants, car leurs performances sur des tâches de comptage simples varient de manière imprévisible de plus de 40 % en fonction du seul contenu sémantique des éléments comptés, révélant ainsi des biais cachés dépendants de l'entrée qui s'étendent au-delà de la simple complexité du raisonnement.

Auteurs originaux : Martiño Ríos-García, Nawaf Alampara, Kevin Maik Jablonka

Publié 2026-01-30

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Martiño Ríos-García, Nawaf Alampara, Kevin Maik Jablonka

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un robot assistant très intelligent. Vous lui demandez d'accomplir une tâche simple : « Compte combien d'éléments il y a dans cette liste. »

Dans le monde de l'informatique, un véritable « algorithme » (un ensemble d'instructions) est comme un robot aveugle et parfait. Si vous lui donnez une liste de 5 pommes, il en compte 5. Si vous lui donnez une liste de 5 cailloux, il en compte aussi 5. Le robot ne se soucie pas de ce qu'il compte ; il se soucie seulement de savoir combien de choses sont présentes. La signification des éléments ne devrait pas changer le résultat.

Cet article, intitulé « Semantic Content Determines Algorithmic Performance » (Le contenu sémantique détermine la performance algorithmique), révèle une vérité surprenante et légèrement embarrassante sur les modèles d'IA les plus avancés (les grands modèles de langage ou LLM) que nous possédons aujourd'hui : ils ne sont pas des robots aveugles parfaits. Ils sont en réalité très sensibles à ce qu'ils comptent.

Voici une décomposition de leurs conclusions en utilisant des analogies simples :

1. Le test « WhatCounts »

Les chercheurs ont créé un test extrêmement simple appelé WhatCounts.

La configuration : Ils ont donné à l'IA une liste d'éléments séparés par des barres verticales (comme |).
La règle : La liste ne contenait pas de pièges. Pas de doublons, pas de mots déroutants, pas de « distracteurs ». Juste une liste propre de 10 éléments.
La variable : Ils ont changé ce que l'IA comptait. Parfois, c'étaient 10 villes, parfois 10 produits chimiques, parfois 10 noms, et parfois 10 emojis.

Le résultat : La précision de l'IA oscillait radicalement selon le type d'élément.

Si la liste était composée de Villes, l'IA pouvait réussir 95 % du temps.
Si la liste était composée de Produits chimiques, cette même IA ne réussissait peut-être que 50 % du temps.
L'écart : Dans certains cas, la différence de précision dépassait les 40 %.

L'analogie : Imaginez un caissier qui est excellent pour compter les pommes, mais qui perd inexplicablement le compte lorsqu'on lui tend des oranges, alors que la tâche est exactement la même. Le caissier n'est pas mauvais en mathématiques ; il est simplement étrangement biaisé par le type de fruit.

2. Ce n'est pas un problème de « comptage »

Les chercheurs voulaient savoir pourquoi cela se produisait. Ils ont mené plusieurs expériences pour écarter les excuses courantes :

Est-ce parce que certains mots sont plus longs ? (Nombre de tokens)
- Test : Ils se sont assurés que chaque liste avait exactement le même nombre de « tokens » (mots informatiques), même si les éléments étaient différents.
- Résultat : Le biais persistait. Ce n'était pas une question de longueur.
Est-ce parce que l'IA ne voit pas où un élément se termine et où le suivant commence ? (Identification)
- Test : Ils ont demandé à l'IA d'entourer simplement chaque élément par des balises XML (comme <item>Ville</item>) au lieu de les compter.
- Résultat : L'IA était excellente pour identifier les éléments. Elle savait exactement où les villes et les produits chimiques commençaient et s'arrêtaient. Le problème n'était pas de voir les éléments ; c'était de les compter.
Est-ce parce que l'IA doit « réfléchir davantage » ? (Raisonnement)
- Test : Ils ont forcé l'IA à utiliser plus d'« effort de raisonnement » (pensez à l'approche étape par étape).
- Résultat : Étonnamment, faire réfléchir l'IA davantage n'a pas réglé le problème. En fait, pour les modèles les plus intelligents, faire réfléchir davantage l'IA élargissait parfois même l'écart entre les éléments « faciles » et les éléments « difficiles ».

3. La nature « instable » du biais

Les chercheurs ont également examiné la manière dont ces modèles sont entraînés. Ils ont découvert que le biais est imprévisible.

Si vous prenez deux modèles presque identiques mais entraînés sur des données légèrement différentes, l'un peut être excellent pour compter les produits chimiques mais mauvais pour compter les noms.
L'autre peut être exactement l'inverse.
L'analogie : C'est comme deux étudiants qui ont étudié le même manuel. L'étudiant A est excellent pour résoudre des problèmes de mathématiques sur les « pommes », mais échoue sur les « oranges ». L'étudiant B est l'inverse. Vous ne pouvez pas prédire quel étudiant échouera simplement en regardant sa note générale ; cela dépend entièrement du sujet spécifique.

4. Pourquoi cela importe (Le problème de l'« Agent »)

L'article montre que ce n'est pas seulement un jeu de culture générale. Ces modèles sont de plus en plus utilisés comme des « agents » qui accomplissent des tâches pour nous, comme exécuter du code ou gérer des bases de données.

Le scénario : Imaginez un agent d'IA qui doit compter des articles dans une liste pour envoyer un colis. Il utilise un outil Python (une calculatrice) pour l'aider.
L'échec : Même lorsque l'IA dispose d'une calculatrice pour l'aider à compter, elle est toujours confuse si les articles sont des « Produits chimiques » plutôt que des « Villes ».
La conséquence : Si un système repose sur l'IA pour compter les articles correctement afin de prendre une décision (comme « Avons-nous assez d'ingrédients ? »), le système pourrait échouer simplement parce que la signification des mots a changé, et non parce que les mathématiques étaient difficiles.

La grande conclusion

L'article conclut que les LLM n'« implémentent » pas réellement des algorithmes.

Véritable algorithme : Une règle qui fonctionne de la même manière, peu importe ce que vous y injectez. (Comme un distributeur automatique : insérez une pièce, obtenez un soda. Peu importe que la pièce soit un euro ou un dollar ; la machine compte simplement la valeur).
Comportement des LLM : Ils approximent des algorithmes. Ils font de l'association de formes (pattern-matching). Ils ont appris que « compter des villes » ressemble généralement d'une certaine manière dans leurs données d'entraînement, et que « compter des produits chimiques » ressemble à autre chose. Ils ne suivent pas une règle rigide ; ils devinent en fonction de la « saveur » des mots.

En bref : Si vous demandez à un humain de compter 10 choses, il en compte 10. Si vous demandez à une IA de haut niveau de compter 10 choses, la réponse peut dépendre de si ces choses sont des « emojis » ou des « produits chimiques ». L'IA n'est pas une calculatrice ; c'est un très bon devineur qui se laisse déstabiliser par la signification des mots.

Résumé technique : Le contenu sémantique détermine la performance algorithmique

Énoncé du problème

L'article aborde une question fondamentale concernant la nature des grands modèles de langage (LLM) : implémentent-ils des algorithmes, ou ne font-ils que les approximer ? Un algorithme, par définition, devrait être invariant au contenu sémantique de ses arguments ; compter dix éléments devrait produire le même résultat que les éléments soient des villes, des produits chimiques, des noms ou des emojis. Cependant, des travaux antérieurs ont établi que la performance des LLM est sensible à la formulation du prompt, à la longueur de la liste et aux artefacts de tokenisation. Les auteurs postulent que si les LLM implémentent réellement des algorithmes, leurs erreurs devraient refléter des limitations générales (ex: fenêtres de contexte) plutôt qu'une dépendance systématique à ce qui est compté. Si la performance varie en fonction de la classe sémantique, le modèle est probablement en train de faire de l'appariement de formes (pattern-matching) plutôt que d'exécuter une procédure généralisable. Cette fragilité est critique car les LLM sont de plus en plus déployés dans des pipelines de production où des opérateurs primitifs (comme le comptage) servent de briques de base pour des agents et des flux de travail complexes.

Méthodologie : WhatCounts

Pour isoler l'invariance sémantique des autres facteurs de confusion, les auteurs introduisent WhatCounts, un benchmark atomique conçu pour tester la performance de comptage de manière isolée.

Design expérimental : Le benchmark présente aux LLM des listes délimitées et non ambiguës contenant des éléments valides et non dupliqués appartenant à une seule classe sémantique. La tâche consiste strictement à compter les éléments.
Classes sémantiques : Six classes distinctes ont été évaluées : adresses, produits chimiques, villes, noms complets de personnes, numéros de téléphone et emojis.
Contrôles : L'étude contrôle rigoureusement :
- Longueur de la liste : Variation des comptes sur des plages spécifiques (ex: 7–17, 85–115) pour éviter les biais d'arrondi.
- Tokenisation : Garantie que les listes ont des nombres de tokens identiques entre les classes pour exclure les effets de longueur de token.
- Formatage : Utilisation d'un séparateur constant (le pipe |) et test de la mention explicite du séparateur.
- Raisonnement : Test avec et sans Chaîne de Pensée (CoT) et variation des niveaux d'effort de raisonnement.
Études d'ablation : Les auteurs ont réalisé des ablations spécifiques pour distinguer l'identification (segmentation des éléments) de l'agrégation (comptage des éléments) :
- Test d'identification : On demande aux modèles d'entourer les éléments de balises XML plutôt que de les compter.
- Test d'agrégation : On demande aux modèles de compter des éléments déjà entourés de balises XML.
- Mélange de tokens (Token Shuffling) : Les tokens au sein de chaque élément sont mélangés pour corrompre le sens sémantique tout en préservant les statistiques de tokens.
Modèles évalués : Quatre modèles de pointe ont été testés : o3 (OpenAI), Claude-sonnet-4 (Anthropic), DeepSeek-V3 et Kimi-K2 (Moonshot AI). De plus, des variantes affinées de Tulu2-13B entraînées sur différents jeux de données (StackExchange, Nectar, HH-RLHF) utilisant DPO et PPO ont été évaluées pour étudier l'impact de l'entraînement.

Résultats clés

1. Variance sémantique significative

Les LLM de pointe présentent une variation de précision de plus de 40 % selon la seule classe sémantique des éléments comptés, malgré un formatage et des longueurs de liste identiques.

Écart Sémantique ( $\Delta_{sem}$ ) : Défini comme la différence entre la précision maximale et minimale à travers les classes sémantiques pour un modèle donné.
Résultat contre-intuitif : Les modèles présentant la précision moyenne la plus élevée (ex: o3) ont souvent présenté les écarts sémantiques les plus importants, suggérant que les modèles les plus puissants ne sont pas nécessairement plus robustes à la fragilité sémantique.

2. Exclusion des explications de surface

Les auteurs ont systématiquement écarté d'autres explications pour cette variance :

Nombre de tokens : Le contrôle du nombre de tokens n'a pas éliminé l'écart ; dans certains cas, fixer le nombre de tokens a augmenté l'écart sémantique.
Reconnaissance de structure : Mentionner explicitement le séparateur ou entourer les éléments de balises XML n'a pas supprimé la variance. Les modèles pouvaient identifier et entourer les éléments avec succès (haute précision) mais échouaient à les compter avec précision, indiquant que la défaillance réside dans l'agrégation, et non dans l'identification.
Effort de raisonnement : Augmenter l'effort de raisonnement (ex: dans o3) n'a pas amélioré la précision du comptage et, dans certains cas, a augmenté l'écart sémantique.
Mélange de tokens (Token Shuffling) : Le mélange des tokens au sein des éléments (détruisant le sens sémantique) a considérablement modifié les performances, suggérant que les modèles s'appuient sur la distribution sémantique des tokens plutôt que sur un comptage purement structurel.

3. Instabilité et impact de l'entraînement

Changements imprévisibles : L'affinage (fine-tuning) des modèles sur des jeux de données non liés (ex: StackExchange vs Nectar) a provoqué des déplacements imprévisibles des classes sémantiques qui réussissaient ou échouaient. Cela indique que la fragilité est une propriété des poids appris plutôt que de l'architecture.
Échec agentique : Dans un environnement agentique où les modèles utilisaient un outil d'exécution Python pour compter les éléments, l'écart sémantique a persisté et s'est même accentué par rapport aux modèles de base. Cela démontre que la fragilité se propage aux scénarios d'utilisation d'outils, sapant la fiabilité des hypothèses de "programmation par prompt".

Contributions clés

Benchmark WhatCounts : Un benchmark atomique minimal isolant l'invariance sémantique dans le comptage, exempt des confusions telles que l'ambiguïté de la tokenisation ou le raisonnement multi-étapes.
Dépendance sémantique des algorithmes : Preuve empirique que la précision du comptage varie de plus de 40 % selon les classes sémantiques dans des conditions identiques, prouvant que les LLM n'implémentent pas d'algorithmes invariants mais des approximations dépendantes des arguments.
Modes de défaillance instables : Démonstration que les biais sémantiques changent de manière imprévisible avec l'affinage sur des données non liées, confirmant que l'écart est piloté par les poids du modèle.
Risque en aval : Preuve que la fragilité sémantique des opérateurs primitifs compromet la fiabilité en production, comme le montre l'utilisation d'agents où l'usage d'outils ne pallie pas l'erreur.

Signification et affirmations

L'article conclut que les LLM n'implémentent pas d'algorithmes ; ils les approchent, et l'approximation est dépendante des arguments. Cela remet en question l'hypothèse sous-jacente à la "programmation par prompt" selon laquelle un algorithme prompté se comporterait comme un algorithme traditionnel (indifférent à la classe sémantique de ses arguments).

Les auteurs soutiennent que si même le plus simple des primitives (le comptage) porte des dépendances cachées sur le sens de l'entrée, alors toute "fonction" de LLM (tri, recherche, extraction) peut porter des dépendances similaires. Cela a des implications profondes pour la fiabilité des pipelines agentiques, où des échements conditionnés par le contenu dans les opérateurs de bas niveau peuvent se propager en une fragilité du système global. Ce travail suggère que les évaluations actuelles surestiment peut-être la robustesse en omettant de prendre en compte la variance des classes sémantiques, et que les futurs benchmarks doivent isoler cet axe pour évaluer correctement les capacités des modèles.