Une phrase. Une seule phrase sans rapport avec le problème posé. Ça suffit pour faire s'effondrer les performances d'un LLM de 65% sur des maths de CM2. Apple l'a mesuré, peer-reviewed, publié à ICLR 2025. Le paper s'appelle GSM-Symbolic (Mirzadeh et al., arxiv 2410.05229), et ce qu'il documente est plus gênant qu'une simple régression de benchmark.
Ce que le benchmark a vraiment fait
GSM-Symbolic teste si le "raisonnement" des modèles est stable face au bruit.
Le protocole : prendre des problèmes de maths élémentaires (niveau GSM8K), régénérer les mêmes problèmes avec des noms et des chiffres différents mais une logique identique, puis ajouter une phrase non pertinente quelque part dans l'énoncé. Quelque chose du style "Marie a aussi un chien qui s'appelle Rex" dans un problème de calcul de pommes.
Le résultat est systématique. Les modèles ne filtrent pas la phrase parasite. Ils l'intègrent comme une opération. À chaque fois.
Pattern matching, pas raisonnement
Un raisonneur identifie les données pertinentes, ignore le reste, construit une chaîne logique. Un pattern matcher cherche des structures familières dans l'input et génère la continuation la plus probable.
Sur GSM8K en conditions normales, les deux approches donnent des résultats proches. Le benchmark standard ne les distingue pas. GSM-Symbolic les distingue en ajoutant du bruit structuré : les performances s'effondrent parce que le modèle n'a jamais appris à ignorer une information, il a appris à en faire quelque chose.
C'est exactement ce que tu observes quand tu debugges un agent en prod qui part dans des directions absurdes. Il n'a pas "mal compris". Il a pattern-matché sur quelque chose dans ton contexte que tu n'avais pas prévu de rendre saillant.
On avait creusé comment les LLMs se font manipuler par des inputs malveillants il y a quelques semaines. GSM-Symbolic documente la même vulnérabilité fondamentale, sans adversaire. Le bruit suffit.
Ce que ça change si tu builds des agents
Si ton pipeline fait du raisonnement ou du calcul, tu as probablement un problème que tu ne vois pas encore.
Le cas classique : un agent qui extrait des données d'un document, fait des calculs dessus, renvoie un résultat. En test, le document est propre. En prod, il contient des notes de bas de page, des métadonnées, des champs vides avec des libellés qui ressemblent à des chiffres. La phrase parasite de GSM-Symbolic, c'est exactement ça.
Trois réflexes concrets à partir de là.
Ajoute des phrases parasites dans tes prompts de test. Mesure l'amplitude de la dégradation sur ton cas d'usage précis, parce que le modèle ne filtrera probablement pas.
Si ton agent doit faire un calcul, donne-lui uniquement les données nécessaires à ce calcul : pas le document entier, pas les métadonnées. La fenêtre de contexte n'est pas un avantage si elle introduit du bruit que le modèle va traiter comme du signal.
Un agent qui fait "extraire + calculer + décider" dans un seul prompt est fragile par construction. Sépare les étapes, valide les intermédiaires.
Pour le raisonnement formel pur, les architectures spécialisées jouent un jeu différent. Leanstral montre ce que donne un modèle de 6B paramètres entraîné spécifiquement pour la preuve formelle en Lean4.
Ce qui reste ouvert
GSM-Symbolic documente le phénomène sur les modèles disponibles fin 2024. Les versions actuelles de GPT-4o, Claude 3.7, Gemini 2.5 sont probablement un peu plus robustes. Probablement un peu, parce que l'architecture de base n'a pas changé.
Le débat que ce paper relance touche à ce que "raisonnement" veut dire pour un LLM, une question qui descend plus bas que la performance sur un benchmark. Ce qui est établi : le bruit dans le contexte est un vecteur de dégradation réel, mesurable et sous-estimé. GSM-Symbolic te donne un protocole pour le quantifier sur ton cas d'usage.
Le paper complet de Mirzadeh et al., protocole, résultats, analyse des patterns de défaillance.
