ThinkingBox évalue les agents IA sur les résultats de bases de données et la fiabilité répétée

4 octobre 2026 – Les chercheurs de Microsoft ont publié ThinkingBox sur Hugging Face, introduisant une nouvelle façon d’évaluer les agents de grands modèles de langage (LLM) qui interagissent avec des outils externes. Contrairement aux benchmarks précédents qui récompensent une réponse en langage naturel correcte ou un appel d’outil syntaxiquement valide, ThinkingBox mesure l’état final du backend et les effets secondaires après qu’un agent a exécuté un flux de travail métier. Le benchmark comprend 507 processus métier distincts et étatful – tels que la saisie de commande, la mise à jour d’inventaire ou la modification d’un enregistrement client – chacun exécuté 20 fois dans des sessions d’outils Microsoft Copilot (MCP) isolées. En se concentrant sur les résultats réels de la base de données, la suite vise à faire apparaître les problèmes de fiabilité qui ne se manifestent qu’après une utilisation répétée en conditions réelles.

Comment fonctionne ThinkingBox

Chacun des 507 flux de travail est codé comme une séquence d’appels d’outils qui manipulent une base de données relationnelle. Le benchmark exécute une isolation complète de l’environnement d’outils MCP pour chaque essai, garantissant qu’aucune contamination entre exécutions ne masque les erreurs. Après que l’agent a terminé une exécution, ThinkingBox inspecte l’instantané final de la base de données et le compare à une spécification de vérité terrain qui énumère les lignes attendues, les valeurs de colonnes et les effets secondaires tels que les journaux d’audit. Le barème de notation ne tient pas compte d’un résumé textuel fluide produit par l’agent ; il enregistre uniquement si l’état du backend correspond à la spécification, si des changements non intentionnels sont survenus, et si un outil a signalé une erreur.

L’évaluation a couvert 12 agents LLM publiquement disponibles, allant de modèles open‑source à des offres commerciales. Au total, l’expérience a généré 121 680 essais valides – le produit de 507 flux de travail, 20 répétitions et 12 modèles. Parmi ceux‑ci, 79 853 tentatives ont échoué à l’étape de vérification exécutable, ce qui signifie que l’agent n’a pas émis l’appel d’outil requis ou a produit un appel qui n’a pas pu être analysé. Notamment, 67,24 % de ces tentatives échouées se sont tout de même terminées sans erreur d’outil finale, ayant invoqué au moins un outil modifiant l’état avant de s’arrêter. Ce schéma met en évidence un décalage entre le succès apparent d’un agent et les incohérences cachées qui subsistent dans la base de données.

Principaux résultats

Lorsque un essai échoue la vérification exécutable, le benchmark enregistre trois catégories de déviation. Des valeurs de champ incorrectes apparaissent dans 77,61 % des tentatives échouées, indiquant que les agents écrivent souvent des données erronées même lorsqu’un appel d’outil réussit. Des effets non intentionnels – actions qui modifient des parties de la base de données non spécifiées par le flux de travail – ont été observés dans 43,30 % des échecs, tandis que des effets manquants – changements attendus qui ne se sont jamais matérialisés – sont survenus dans 25,36 % des cas. Les pourcentages se chevauchent car une même exécution peut présenter plusieurs types d’erreur simultanément. Ces chiffres démontrent qu’une majorité d’échecs pilotés par des outils laissent la base de données dans un état incohérent ou partiellement correct.

Les performances varient largement selon les modèles. Claude Opus 5.5 a obtenu le meilleur score pass@1, réussissant 67,16 % des 121 680 essais dès la première tentative. Kimi‑K3 a affiché un profil différent : il a résolu 93,89 % des tâches au moins une fois sur les 20 répétitions, mais seulement 13,41 % des exécutions ont réussi à chaque répétition. Ce contraste souligne l’importance de mesurer la fiabilité sur des exécutions répétées plutôt que sur un seul meilleur cas. Les modèles restants se situent entre ces extrêmes, beaucoup affichant des taux pass@1 inférieurs à 50 % et une variabilité substantielle entre les répétitions.

Limites du benchmark

ThinkingBox est délibérément limité à un ensemble sélectionné de flux de travail métier, et les auteurs insistent sur le fait que les chiffres ne représentent pas chaque scénario de production qu’une entreprise pourrait rencontrer. Le benchmark isole chaque essai dans une session MCP neuve, ce qui élimine l’influence de l’accumulation d’état à long terme, du cache ou des dépendances inter‑flux qui existent dans les systèmes en direct. De plus, l’évaluation se concentre sur les résultats des bases de données relationnelles ; les agents qui interagissent avec des services non‑SQL, des systèmes de fichiers ou des API externes ne sont pas couverts. Enfin, la métrique considère toute déviation par rapport à la spécification de vérité terrain comme un échec, même lorsque la déviation pourrait être inoffensive dans un contexte métier spécifique.

• 79 853 tentatives ont échoué aux vérifications exécutables sur 121 680 essais totaux.
• 67,24 % des tentatives échouées se sont terminées proprement sans erreur d’outil finale.
• 77,61 % des échecs ont signalé des valeurs de champ incorrectes dans la base de données.
• 43,30 % des échecs ont produit des effets secondaires non intentionnels.
• 25,36 % des échecs ont omis les effets attendus.
• Claude Opus 5.5 a mené le classement pass@1 avec 67,16 % de succès.
• Kimi‑K3 a résolu 93,89 % des tâches au moins une fois mais seulement 13,41 % dans toutes les 20 exécutions.

Les implications pratiques sont immédiates pour les développeurs qui construisent des automatisations pilotées par IA. En révélant la fréquence à laquelle les agents écrivent silencieusement des données erronées ou omettent des mises à jour requises, ThinkingBox encourage un passage du questionnement « l’appel d’outil réussit‑il ? » à « la base de données se retrouve‑t‑elle correcte ? ». Les équipes peuvent désormais utiliser le benchmark pour prioriser les tests de robustesse, ajouter des transactions compensatoires ou repenser les prompts afin d’imposer un comportement idempotent. Les données offrent également aux fournisseurs un objectif concret : améliorer la répétabilité entre les exécutions, et pas seulement atteindre un taux de réussite élevé en un seul essai. À mesure que les entreprises adoptent des agents LLM pour des tâches critiques de back‑office, la capacité à certifier que les données sous‑jacentes restent fiables devient un différenciateur concurrentiel.

À l’avenir, Microsoft et la communauté de recherche plus large prévoient d’étendre ThinkingBox avec des catégories de flux de travail supplémentaires, un suivi des effets secondaires plus riche et une intégration aux pipelines d’intégration continue. Le benchmark est déjà disponible sur Hugging Face, permettant à quiconque d’exécuter les mêmes 507 flux de travail contre leurs propres agents et de comparer les résultats aux repères publiés. En rendant l’évaluation axée sur les résultats ouverte et reproductible, ThinkingBox est destiné à changer la façon dont l’industrie mesure la fiabilité des agents IA, en déplaçant la conversation de la simple correction superficielle vers la question plus profonde de savoir si la base de données – source ultime de vérité – reflète le résultat métier attendu.