Inkling 2 Small a juré 316 fois, mais n’a pratiquement pas aidé à prédire les défaillances

Il arrive qu’un modèle tombe en panne d’une manière presque humaine : il se trompe plusieurs fois, déclare que « rien ne fonctionne », jure, puis continue à générer du texte. C’est précisément ce comportement que les chercheurs de Vals AI ont découvert dans les journaux internes d’Inkling 2 Small de Thinking Machines. Ce détail amusant se transforme rapidement en question d’ingénierie : des mots chargés d’émotion permettent-ils de savoir à l’avance que le modèle a perdu le fil de son raisonnement ?

Réponse courte : non. Les jurons sont visibles, mais ils constituent un mauvais signal de défaillance. Pour un développeur, il est plus utile de surveiller la répétition des phrases, la longueur de la génération, la consommation de tokens et l’absence de progression vers le résultat que le vocabulaire du modèle.

Ce que les journaux ont révélé

Les chercheurs ont examiné 2 655 exécutions sur 13 tests. Le mot « fuck » et ses variantes sont apparus dans 50 exécutions, pour un total de 316 occurrences. Sur ce nombre, 241 provenaient de seulement deux générations parties en boucle.

L’épisode le plus parlant s’est produit dans une tâche de calcul de la trajectoire d’un astéroïde. Au lieu d’une solution concise, le modèle a produit environ 500 000 caractères : il répétait les mêmes phrases et a employé un juron 158 fois. Ce n’est plus un problème de ton. Une telle réponse gaspille des ressources de calcul, augmente la latence et peut occuper le contexte de l’étape suivante d’un processus agentique.

Le phénomène était particulièrement fréquent dans ProgramBench : il s’est manifesté dans 20 exécutions sur 200. En général, le modèle jurait après sa propre erreur, lors d’une prétendue percée ou avant de renoncer à poursuivre ses tentatives. Le schéma est familier : la solution ne converge pas, le monologue interne devient plus abrupt, puis la génération s’interrompt ou entre dans une boucle.

Pourquoi c’est un mauvais détecteur d’erreur

À première vue, la corrélation paraît forte : 46 des 48 exécutions évaluées qui contenaient des jurons se sont soldées par un échec. Mais le taux global d’échec atteignait déjà environ 75 %. Plus important encore, 96 % de toutes les exécutions ayant échoué ne contenaient aucun juron.

Imaginons un service qui marque une réponse comme suspecte dès qu’un juron apparaît dans le journal interne. Il détectera effectivement quelques défaillances spectaculaires, mais laissera passer l’écrasante majorité des erreurs. C’est comme surveiller la surchauffe d’un serveur grâce à l’odeur du plastique : lorsqu’elle apparaît, c’est un signe grave, mais l’attendre pour assurer la surveillance revient à intervenir beaucoup trop tard.

Les jurons peuvent rester un indice diagnostique complémentaire, mais ils ne permettent pas de bâtir une protection fiable. Ils dépendent également de la langue, des données d’entraînement et des réglages du modèle. Après une mise à jour, cet indicateur peut disparaître alors que les boucles, elles, subsistent.

Ce que les développeurs doivent faire

En production, il faut des indicateurs directement liés à la défaillance. Limitez le nombre maximal de tokens et le temps d’exécution. Comptez les fragments répétés, surveillez l’augmentation brutale de la longueur de la réponse et interrompez la génération si, pendant plusieurs étapes consécutives, le modèle ne se rapproche pas d’un résultat vérifiable. Dans les systèmes agentiques, fixez une limite au nombre de tentatives et enregistrez la raison de l’arrêt séparément du texte de raisonnement.

Il est également utile de vérifier le résultat par un moyen externe : lancer des tests pour le code, valider les nombres, exiger une réponse structurée ou faire appel à un évaluateur distinct. Le journal interne peut aider à analyser un incident, mais il ne doit pas constituer l’unique source de vérité.

La conclusion pratique est simple : le vocabulaire inhabituel d’un modèle est un symptôme intéressant, pas une métrique fiable. Si un système peut produire 500 000 caractères de répétitions, il faut d’abord corriger le contrôle de la génération. Un dictionnaire de mots interdits n’est ici qu’un artifice cosmétique ; les limites, un détecteur de boucles et la vérification du résultat constituent la véritable protection.