ITBench-AA : les modèles d’IA de pointe restent sous les 50 % sur un nouveau benchmark d’incidents Kubernetes

Résumé

Artificial Analysis et IBM lancent ITBench-AA, première déclinaison agentique du benchmark ITBench dédiée aux tâches de Site Reliability Engineering. Sur 59 incidents Kubernetes, aucun modèle de pointe ne dépasse 47 % de précision moyenne, révélant la difficulté des diagnostics racine en environnement IT d’entreprise.

Les faits

Artificial Analysis et IBM Software Innovation Lab lancent ITBench-AA, un nouveau benchmark conçu pour évaluer les modèles d’IA sur des tâches agentiques d’entreprise, en commençant par le Site Reliability Engineering (SRE). Ce premier volet, ITBench-AA SRE, évalue les modèles sur des tâches de réponse à incidents Kubernetes où ils doivent diagnostiquer des systèmes à partir de journaux, de traces, de métriques et de la topologie applicative, puis identifier les entités racines responsables de l’incident. L’ensemble repose sur le jeu de données ITBench développé par IBM, qui capitalise sur une expertise approfondie des opérations IT d’entreprise. Les résultats montrent que tous les modèles de pointe restent sous les 50 % de score moyen sur ITBench-AA SRE. Claude Opus 4.7 (Adaptive Reasoning, Max Effort) atteint 47 %, suivi de GPT-5.5 (xhigh) à 46 % et de Qwen3.7 Max à 42 %. L’équipe souligne qu’« ITBench-AA SRE est l’un des benchmarks agentiques les moins saturés » de leur suite, les modèles obtenant des scores nettement plus élevés sur Terminal-Bench. Les trajectoires varient fortement : GPT-5.5 (xhigh) tourne en moyenne à 31 échanges par tâche pour 46 %, quand Gemini 3.1 Pro Preview grimpe à 83 échanges pour seulement 30 %, ce qui montre que des investigations plus longues ne se traduisent pas mécaniquement par une meilleure précision. Les modèles à poids ouverts affichent eux aussi des performances contrastées. GLM-5.1 (Reasoning) conduit ce groupe à 40 %, au niveau de Gemini 3.5 Flash (high), tandis que DeepSeek V4 Pro (Reasoning, Max Effort) atteint 38 % et Gemma 4 31B (Reasoning) 37 %, tous devant Gemini 3.1 Pro Preview à 30 %. Au total, ITBench-AA SRE comprend 59 tâches de SRE, dont 40 tâches publiques et 19 nouvelles tâches tenues à part. Chaque tâche fournit un instantané d’incident Kubernetes avec alertes, événements, traces, métriques, journaux et topologie, et le modèle doit identifier le « minimal set of independent root-cause Kubernetes entities » responsable de l’incident. Les défaillances couvrent des modes d’échec classiques du SRE comme des incidents d’infrastructure, de service, d’application ou injectés par chaos engineering, incluant par exemple l’épuisement de quotas de ressources, des échecs de déploiement, l’épuisement de pools de connexions ou des partitions réseau. L’évaluation repose sur un harnais agentique open source, Stirrup, qui donne aux modèles un accès shell à un système de fichiers isolé contenant les journaux et instantanés pertinents, avec une limite de 100 tours par tâche et trois répétitions par tâche. Les modèles soumettent une liste d’entités racines (Deployments, Services, Pods, etc.), comparée à un ensemble de causes racines fourni par IBM. Le scoring utilise la précision moyenne à rappel complet : si une cause racine est manquée, le score est 0 pour cette répétition ; si toutes les causes sont trouvées, le score est égal à la précision (vrais positifs / (vrais positifs + faux positifs)). Le score mis en avant est la moyenne sur 59 tâches multipliées par trois répétitions, avec Stirrup maintenu constant pour permettre une comparaison rigoureuse entre modèles. Un exemple de tâche publique illustre la difficulté : l’agent observe des pannes côté utilisateur sur le frontend, explore l’instantané via des commandes shell, utilise les alertes pour circonscrire la fenêtre d’incident, puis les traces et journaux pour cibler le trafic frontend. La topologie permet de localiser les services affectés et les manifestes Kubernetes révèlent une NetworkPolicy qui bloque le frontend. Le diagnostic réussi identifie comme entité racine « otel-demo/NetworkPolicy/frontend-block-all-ports ». ITBench-AA est construit en partenariat avec IBM sur la base de leur benchmark ITBench, et les auteurs renvoient vers l’article de recherche sur arXiv, le dépôt GitHub ITBench, le tableau de classement ITBench-AA et le dépôt Hugging Face de l’ensemble de données SRE.

Pourquoi c’est important

ITBench-AA marque une étape clé dans l’évaluation des agents d’IA appliqués aux opérations IT d’entreprise. Le fait que tous les modèles de pointe restent sous les 50 % sur des incidents Kubernetes réalistes montre que la résolution autonome de pannes complexes demeure un défi majeur pour l’IA, malgré ses performances impressionnantes sur d’autres benchmarks. En s’appuyant sur un jeu de données industriel développé par IBM et sur un harnais agentique standardisé, ce benchmark fournit un cadre reproductible pour comparer modèles fermés et modèles à poids ouverts sur des tâches critiques comme le SRE. L’extension annoncée vers les opérations financières (FinOps) et les missions de responsables de la sécurité (CISO) laisse entrevoir une future batterie de tests couvrant l’ensemble des fonctions IT d’entreprise, avec un impact direct sur l’adoption de l’IA agentique dans les environnements de production.

Questions fréquentes

Qu’est-ce qu’ITBench-AA ?

ITBench-AA est un benchmark développé par Artificial Analysis et IBM pour évaluer les modèles d’IA sur des tâches agentiques d’entreprise, en commençant par la réponse à incidents Kubernetes en Site Reliability Engineering.

Quels scores obtiennent les modèles de pointe sur ITBench-AA SRE ?

Claude Opus 4.7 atteint 47 %, GPT-5.5 (xhigh) 46 % et Qwen3.7 Max 42 %, et tous les modèles de pointe restent en dessous de 50 % sur ce benchmark.

Combien de tâches comprend ITBench-AA SRE ?

Le benchmark ITBench-AA SRE regroupe 59 tâches de SRE au total, dont 40 tâches publiques et 19 nouvelles tâches tenues à part.

Comment est calculé le score sur ITBench-AA SRE ?

Le score utilise la précision moyenne à rappel complet : si une cause racine est manquée, le score est 0, sinon il est égal à la précision, puis moyenné sur 59 tâches et trois répétitions.

Quel type d’incidents Kubernetes sont modélisés ?

Les incidents couvrent des défaillances d’infrastructure, de services, d’applications et des incidents injectés, comme l’épuisement de quotas de ressources, des échecs de déploiement, l’épuisement de pools de connexions et des partitions réseau.

Source

Auteur

Rédaction spécialisée dans la veille et l'analyse de l'actualité de l'intelligence artificielle, des puces IA, des robots, des agents IA et de la recherche.