StateBench : évaluer le suivi d’état des IA
Découvrez comment StateBench mesure le suivi d’état des IA, pourquoi les modèles décrochent sur les longs documents et ce que cela implique en entreprise.
StateBench : les modèles d'IA savent-ils vraiment suivre une information qui change ?
Un modèle de langage peut retrouver une date dans un long document sans pour autant suivre correctement ce qui arrive à un objet, à une personne ou à une variable au fil des pages. Le problème ne tient pas seulement à la fenêtre de contexte. Il faut aussi prendre en compte les mises à jour successives, les combiner, puis en déduire l'état final sans en oublier une étape.
Cette distinction devient vite concrète : une IA relit un historique de support client, suit des modifications de code, ou résume une conversation où les responsabilités et les décisions bougent. Une petite erreur dans une réponse isolée peut se transformer, plus tard, en action mal exécutée.
StateBench, un benchmark présenté par Ai2, cherche justement à tester cette capacité. Il découpe la difficulté en plusieurs niveaux et compare des modèles aux architectures différentes, entraînés de façons variées. Voici ce que le benchmark évalue, ce qu'on peut en conclure, et comment s'en servir pour tester un système d'IA en entreprise.
Ce que mesure StateBench
StateBench évalue le suivi d'état sur de longues séquences : la capacité d'un modèle à garder une représentation cohérente d'entités et de leurs caractéristiques, même quand de nouvelles informations arrivent et changent les choses.
Prenons un scénario simple. Au début, un colis est dans l'entrepôt A. Puis il est transféré au dépôt B, avant d'être confié à un transporteur. Si on demande « où se trouve le colis ? », l'IA ne peut pas se contenter de relever le premier lieu cité ou la dernière phrase qui contient un nom de lieu. Elle doit comprendre quelle opération modifie l'état courant et appliquer les changements dans le bon ordre.
On retrouve exactement la même logique dans des tâches très différentes : interpréter des affectations dans du code, suivre les changements de rôle dans une conversation, déterminer à qui appartient un objet, ou reconstituer l'état d'un processus à partir d'événements. Dans tous ces cas, la réponse dépend de l'historique - pas d'une phrase prise isolément.
Pourquoi la longueur du contexte ne suffit pas
Avoir un contexte plus long aide à fournir plus de texte au modèle. Mais ça ne garantit pas qu'il saura raisonner correctement sur les dépendances contenues dans ce texte. Quand une mise à jour dépend d'une étape précédente, oublier une seule transition peut suffire à rendre le résultat final faux, même si tout le document était sous les yeux.
Du coup, il faut distinguer deux capacités qu'on confond souvent : retrouver une information dans un contexte long, et calculer l'état obtenu après une suite de changements. Un modèle peut être bon sur la première et se tromper sur la seconde.
StateBench construit des séquences d'affectations de variables, puis pose une question sur leur valeur finale. L'intérêt est de comparer des tâches de difficulté différente, tout en gardant des conditions proches : même nombre de variables et de valeurs, affectations placées aux mêmes endroits. Ce qui change, c'est surtout la nature des opérations.
Un test de capacité, pas une mesure complète d'un assistant
Le benchmark isole une compétence précise. Il ne remplace pas, à lui seul, l'évaluation d'un usage professionnel complet : qualité des données, consignes, recherche documentaire, outils, et validation humaine.
Et c'est justement ce côté « isolé » qui est utile : si un modèle perd le fil dans une séquence contrôlée, améliorer l'interface ou ajouter un moteur de recherche ne répare pas automatiquement le suivi des mises à jour. À l'inverse, réussir StateBench ne prouve pas qu'un assistant complet sera fiable en production. Le benchmark mesure une capacité particulière, pas une garantie opérationnelle.
Quatre niveaux de complexité du suivi d'état
StateBench distingue quatre niveaux, définis par les types de mises à jour autorisés. On peut les voir comme des opérations sur des variables. L'analogie parle bien aux développeurs, et elle décrit aussi des problèmes qu'on rencontre dans des documents et des processus du quotidien.
1. R-trivial : une valeur fixe
Dans R-trivial, une variable reçoit une valeur qui ne change jamais. Le modèle doit retrouver ce qui lui a été donné au départ. C'est proche d'une donnée stable, comme une date de naissance ou un numéro de dossier dans un exemple simplifié.
La tâche peut être longue si l'information est noyée dans beaucoup de texte, mais la logique de mise à jour reste simple : il n'y a rien à recalculer. La difficulté vient surtout de la récupération de la bonne valeur.
2. Aperiodic : la dernière affectation fait foi
Le niveau aperiodic autorise une réaffectation directe. Si une variable vaut d'abord 4 puis 2, l'état final est 2. En théorie, il suffit de repérer la dernière valeur attribuée.
Un thermostat illustre cette idée : si la consigne passe de 19 °C à 21 °C, c'est la consigne la plus récente qui compte. Les anciennes valeurs restent dans l'historique, mais elles ne sont pas nécessaires pour obtenir l'état actuel.
3. Soluble : chaque changement dépend du précédent
Le niveau soluble introduit des opérations qui s'appuient sur la valeur courante. Une instruction du type « x = x + 5 » ne peut pas être résolue en cherchant juste la dernière affectation : il faut d'abord connaître la valeur précédente, puis appliquer l'incrément.
Un score de jeu suit la même logique. Pour obtenir le total, il faut suivre les points gagnés ou perdus au fil du temps. S'il manque un événement, les calculs suivants peuvent tous partir de travers.
4. Général fini : une variable peut prendre la valeur d'une autre
Le niveau général fini ajoute des affectations par référence. Une variable peut prendre la valeur actuelle d'une autre, et des opérations comme l'échange de deux valeurs créent des dépendances entre plusieurs éléments.
Imaginez une balle cachée sous l'un de cinq gobelets. On échange ensuite les positions de manière répétée. Pour savoir où est la balle, il faut suivre chaque permutation dans l'ordre. Là aussi, une opération oubliée (ou mal appliquée) suffit à produire une mauvaise réponse finale.
Ces catégories ne sont pas seulement pédagogiques. Ai2 les relie à des distinctions théoriques issues de la théorie de Krohn-Rhodes : décomposer un suivi d'état en opérations élémentaires. Pour les équipes produit, le point concret est simple : deux tâches qui se ressemblent visuellement peuvent demander des capacités différentes. Retrouver la dernière consigne n'a rien à voir, en pratique, avec le recalcul d'un état à partir d'une chaîne de dépendances.
Ce que révèlent les tests sur les modèles
Le rapport compare d'abord des modèles préentraînés, puis des modèles entraînés directement sur les tâches du benchmark. L'objectif est de ne pas confondre ce que le préentraînement a appris au modèle et ce que son architecture semble pouvoir généraliser.
Les modèles préentraînés réussissent les cas simples, puis décrochent
Les auteurs évaluent notamment des modèles ouverts de 7 milliards de paramètres : Olmo 3 (basé sur un transformeur) et Olmo Hybrid (qui combine des couches récurrentes Gated DeltaNet avec cette approche). Ils testent aussi des modèles plus petits. D'après le rapport, ces modèles ont été entraînés sur des contextes jusqu'à 64 000 jetons, puis évalués sur des séquences plus longues.
Globalement, ils réussissent bien R-trivial. Sur aperiodic, les résultats baissent quand les séquences s'allongent. Sur général fini, ils restent proches du hasard. La présentation de la tâche joue aussi : certains modèles font mieux avec un format de type RULER, mais moins bien quand on présente le même problème sous forme de série de modifications de tableur.
Ce dernier point compte. Un score ne dépend pas uniquement de la capacité abstraite testée : la formulation, le format d'entrée et la façon de demander la réponse changent le résultat. Un benchmark utile devrait donc éviter de conclure « en général » à partir d'une seule manière de présenter les données.
Les modèles de pointe ne sont pas à l'abri
Selon le rapport, des modèles de pointe - Gemini 3.8 Flash, Claude Opus 5.5, GPT-6 Sol et GPT-6 Luna - réussissent R-trivial et aperiodic. En revanche, sur soluble et général fini, leur précision baisse fortement quand les séquences s'allongent. Pour les séquences générales finies les plus longues, elle tombe à 13 % ou moins, selon les résultats publiés.
Ce n'est pas une preuve que ces modèles seraient incapables de suivre une conversation ou de résumer un document. Mais ça montre quelque chose de net : augmenter la longueur de contexte ne suffit pas pour obtenir un suivi fiable des dépendances. Les tâches difficiles sont particulièrement sensibles : plusieurs étapes peuvent impacter la valeur finale, et une omission suffit à invalider la réponse.
Pour une entreprise, la conséquence est simple : il vaut mieux tester des cas d'usage réels que de se reposer uniquement sur une longueur de contexte « annoncée » ou sur un score global de benchmark. Et ces résultats dépendent aussi du format, de la difficulté, de la longueur, et de la version exacte des modèles évalués. Il faut donc lire ces scores comme un indicateur de limites possibles, pas comme un classement durable des fournisseurs.
Pourquoi l'architecture et l'entraînement comptent
Il reste une question centrale : est-ce que les modèles échouent parce que leur architecture ne peut pas gérer ce type de raisonnement, ou parce que leur préentraînement ne leur a pas appris à le faire ? Pour tester cette différence, Ai2 a entraîné plusieurs modèles de 275 millions de paramètres directement sur StateBench.
L'entraînement couvre des séquences contenant jusqu'à 256 affectations. Les modèles sont ensuite testés sur des séquences allant jusqu'à 64 000 affectations, soit 250 fois la longueur maximale vue pendant l'entraînement. Le protocole vise à mesurer la généralisation, pas juste la mémorisation de cas semblables.
Les architectures récurrentes généralisent davantage sur plusieurs niveaux
Dans cette expérience, les variantes Gated DeltaNet et les approches hybrides conservent des performances presque parfaites sur R-trivial, aperiodic et soluble, même sur les séquences les plus longues. Les transformeurs apprennent mieux les tâches simples, mais leur performance se dégrade avec la longueur.
Sur général fini, l'écart devient plus net. Les transformeurs évalués n'arrivent pas à apprendre correctement la tâche, même avec un entraînement direct. La variante Gated DeltaNet avec une mise à jour mémoire plus flexible généralise le plus loin : les résultats restent proches de la perfection jusqu'à environ dix fois la longueur maximale d'entraînement.
Ces observations sont intéressantes, mais elles restent liées au protocole étudié : l'architecture peut influer sur les formes de suivi d'état qu'un modèle arrive à apprendre et à prolonger. Elles ne prouvent ni qu'une architecture récurrente sera meilleure pour tous les usages, ni qu'elle donnera automatiquement une qualité supérieure dans un produit complet.
L'entraînement reste un facteur déterminant
Les modèles hybrides et Gated DeltaNet préentraînés ne reprennent pas exactement les mêmes résultats que leurs versions entraînées directement sur StateBench. Ça suggère que, pour ces architectures, le problème peut venir en partie de l'apprentissage et des données, pas seulement d'une limite « structurelle ».
Les transformeurs, eux, se comportent différemment : même entraînés directement, ils ne maîtrisent pas le niveau général fini. Les auteurs rapprochent ce résultat de limites théoriques connues pour certaines formes de suivi d'état à dépendances longues. Les architectures récurrentes et hybrides, qui portent une mémoire au fil de la séquence, pourraient gérer certaines de ces opérations plus naturellement.
Pour des équipes qui doivent choisir un modèle, la leçon n'est pas de remplacer mécaniquement une architecture par une autre. Il faut vérifier que la compétence testée est réellement critique, construire une évaluation représentative, puis mesurer les compromis : précision, latence, coût d'inférence, faisabilité de déploiement et facilité d'audit. Une meilleure performance sur StateBench aide, mais elle ne doit pas être le seul critère.
Ce que StateBench change pour les usages métier
StateBench est utile parce qu'il transforme une impression vague - « le modèle perd le fil » - en questions testables. Dans un projet, la première étape n'est pas de mesurer la taille du contexte. C'est de décrire les opérations qui font bouger l'état.
Cartographier les mises à jour avant de choisir un modèle
Pour un processus donné, listez les entités à suivre, les changements possibles, et les règles qui déterminent l'état final. Par exemple, dans un outil de gestion d'interventions : technicien, équipement, statut. On a une affectation initiale, un transfert, une mise à jour du statut, puis une clôture.
Ensuite, classez les opérations selon leur dépendance :
- Valeur immuable : récupérer une donnée qui ne change pas.
- Réaffectation directe : retenir le dernier statut ou la dernière consigne.
- Mise à jour cumulative : additionner, retirer ou modifier une valeur à partir de l'état courant.
- Dépendance entre entités : transférer une valeur, un objet ou une responsabilité entre entités.
Cette cartographie évite une erreur fréquente : tester un assistant sur des questions de repérage simples, puis le mettre en production sur un processus où les changements se conditionnent entre eux.
Construire un test qui ressemble au travail réel
Un test en entreprise devrait utiliser les formats réellement présents : courriels, tickets, tableaux, notes de réunion, journaux d'événements. Il faut aussi varier la longueur, le nombre d'entités, l'ordre des mises à jour et la présence d'informations sans rapport.
Une approche pragmatique peut tenir en quatre étapes :
- Définir l'état attendu après chaque séquence, avec une référence vérifiée (par une personne ou un système déterministe).
- Créer des cas par niveau de difficulté, depuis « retrouver le dernier changement » jusqu'aux dépendances entre plusieurs entités.
- Mesurer séparément les erreurs : valeur erronée, mise à jour oubliée, confusion entre entités, réponse non vérifiable.
- Tester la chaîne complète : recherche documentaire, outils, consignes, puis reprise par un opérateur.
Ce découpage rend visible la cause de l'échec : modèle, document mal structuré, recherche, ou orchestration. Et ça évite de résoudre le mauvais problème en empilant des couches.
Choisir une architecture selon le coût de l'erreur
Dans un assistant interne qui propose un résumé relu par un salarié, une erreur ponctuelle de suivi peut être acceptable si elle est détectable et corrigée. Dans un processus de paiement, de conformité ou d'affectation automatisée, la même erreur peut avoir des conséquences financières ou réglementaires.
Le bon niveau d'autonomie dépend donc de l'impact d'une mauvaise réponse. Quand l'état peut être calculé de manière déterministe, une architecture robuste consiste souvent à laisser le logiciel métier appliquer les règles et à utiliser le modèle pour interpréter le texte ou expliquer le résultat. Le modèle peut repérer les événements, mais un moteur explicite conserve l'état et contrôle les transitions. Résultat : on réduit la dépendance à une « mémoire implicite » du modèle.
Le but n'est pas de bannir l'IA des processus complexes. C'est de décider où elle apporte de la valeur, et où une règle déterministe, une validation humaine, ou un journal d'audit fait mieux.
StateBench pousse justement à examiner la frontière entre lecture, interprétation, et calcul d'état.
Limites et questions ouvertes
StateBench apporte une grille plus fine que les tests qui ne regardent que les cas les plus difficiles. Mais le benchmark ne tranche pas tout : il ne ferme pas le débat sur les architectures ni sur la fiabilité des modèles dans des situations réelles.
Les auteurs signalent notamment que la place exacte de certaines variantes de Gated DeltaNet dans la hiérarchie reste à clarifier. Une preuve présentée dans leurs travaux montre que la version à valeurs propres non négatives peut résoudre toutes les tâches aperiodic et certaines tâches périodiques, dans le cadre d'un calcul à précision fixe avec arrondi. La question de résoudre toutes les tâches solubles reste ouverte. La précision numérique et l'ajout de couches d'attention peuvent aussi modifier les résultats.
Autre limite : le benchmark suppose un nombre fixe de variables. Dans une conversation ou un dossier, de nouvelles personnes, de nouveaux objets et de nouvelles responsabilités apparaissent en cours de route. Le modèle doit alors, en plus de mettre à jour l'état, décider quelles nouvelles entités suivre et les distinguer de celles déjà présentes.
Enfin, une performance de laboratoire ne suffit pas à prouver la robustesse d'un système face à des données incomplètes, contradictoires ou mal formatées. Pour déployer, il faut compléter les tests contrôlés par des évaluations sur des données représentatives, encadrer les conséquences des erreurs et prévoir comment vérifier les réponses.
À retenir : StateBench ne dit pas qu'un modèle donné convient à tous les usages. Il explique pourquoi il faut tester séparément la récupération d'une valeur, l'application de mises à jour successives et le suivi des dépendances entre entités. Et plus l'erreur coûte cher, moins on devrait déléguer « par défaut » le calcul de l'état à une génération de texte.
Conclusion
StateBench met en évidence une différence souvent cachée par les scores globaux : retrouver une information dans un long document n'est pas la même chose que suivre l'évolution d'un état. Plus les changements s'accumulent, se calculent ou se conditionnent entre eux, plus la difficulté augmente.
Pour les entreprises, la démarche la plus utile consiste à cartographier les mises à jour du processus, tester chaque niveau de difficulté, puis choisir le degré d'autonomie en fonction du coût d'une erreur. Quand l'état peut être calculé explicitement, un moteur déterministe ou une validation humaine complète le modèle. C'est moins spectaculaire que la promesse d'un contexte illimité, mais souvent plus fiable en production.