Résumé Technique : InfraBench

Énoncé du Problème

La gestion des infrastructures informatiques modernes est devenue de plus en plus complexe en raison de l'augmentation de l'échelle et de la complexité, s'étendant d'environnements hétérogènes allant des clusters sur site aux interactions avec le cloud. Bien que les récentes avancées des agents IA offrent une solution potentielle pour automatiser ces tâches, les benchmarks existants ne parviennent pas à capturer l'ensemble du spectre de la gestion d'infrastructure. Les évaluations actuelles sont souvent limitées à des scénarios simples (par exemple, des conteneurs sur un seul nœud), manquent de couverture sur l'intégralité du cycle de vie opérationnel (du déploiement au déclassement) et omettent fréquemment les évaluations de risques. Par conséquent, il reste difficile de savoir si les agents IA peuvent gérer de manière fiable la complexité, la variabilité et le potentiel de défaillances en cascade (rayon d'impact ou blast radius) de l'infrastructure réelle.

Méthodologie

Les auteurs introduisent InfraBench, une suite de benchmarks conçue pour évaluer les agents IA à travers des tâches d'infrastructure réalistes. La méthodologie repose sur quatre objectifs de conception fondamentaux :

1. Full-Stack (Pleine pile) : Couvrant quatre couches d'infrastructure : L1 Matériel (BMC/IPMI), L2 Systèmes Locaux (OS, conteneurs), L3 Systèmes Distribués (Ceph, Slurm) et L4 Applications Utilisateurs.
2. Full-Lifecycle (Cycle de vie complet) : Évaluant les tâches à travers les phases de déploiement, d'exécution, de maintenance et de déclassement.
3. Risk-Aware (Sensible au risque) : Évaluant les risques opérationnels et les effets secondaires comme des signaux de premier rang, et non seulement la complétion de la tâche.
4. Réaliste et Extensible : Utilisant un banc d'essai (CloudLab Wisconsin) avec des clusters de serveurs physiques (bare-metal) et de machines virtuelles pour garantir une haute fidélité.

Architecture du Système

InfraBench opère via quatre composants :

• Spécification de la Tâche : Définit les instructions visibles par l'agent et les contextes d'évaluation cachés (failles, oracles, politiques de cycle de vie).
• Exécuteur : Instancie les tâches sur des backends fidèles (Docker, clusters de VM, bare-metal) et gère la fenêtre opérationnelle.
• Évaluateur : Évalue les agents via un Vérificateur de Cycle de Vie Complet (portes d'évaluation Immédiate, en Vie, de Redémarrage/Durabilité, et de Déclassement) et un Moniteur de Risques. Le Moniteur de Risques utilise un juge LLM pour classifier les trajectoires d'actions par rapport à une taxonomie de danger (ex: opérations destructives sur le système de fichiers, contournement de privilèges).
• Métriques : Utilise un vérificateur spécifique à la tâche renvoyant une récompense $R \in [0, 1]$. Les métriques clés incluent :
  • Score Effectif Moyen : Score moyen sur l'ensemble des tâches.
  • Attempt Pass@$\tau$ : La fraction des tentatives individuelles (sur trois par tâche) qui respectent un seuil (ex: parfait ou substantiellement résolu).
  • Best-of-N@$\tau$ : La fraction des tâches où la meilleure des trois tentatives réussit.

Configuration Expérimentale

L'étude a évalué 15 configurations agent-modèle à travers cinq interfaces en ligne de commande (CLI) d'agents de codage (Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI) couplées à neuf fournisseurs de modèles différents. Le benchmark se compose de 12 tâches de base dérivées de rapports d'incidents de production, de traqueurs de problèmes open-source, de documentations cloud et de prototypes de recherche. Chaque configuration a exécuté chaque tâche trois fois sur des environnements fraîchement provisionnés pour garantir l'indépendance.

Résultats Clés

Performance Globale

Même les configurations d'agents les plus fortes n'ont pas réussi à obtenir des scores complets sur toutes les tâches.

• Scores Effectifs Moyens : Varient de 39,9 % à 87,7 %.
• Écart de Fiabilité : La répétition des tâches trois fois a révélé que les meilleures configurations ne réussissent qu'une fraction de leurs tentatives. Par exemple, la configuration la plus performante (Grok 4.5) a obtenu un score moyen de 84,3 % mais n'a réussi que 72,7 % des tentatives individuelles (Pass@1).
• Classement : La configuration de tête (Claude Code + Fable 5) a obtenu 87,7 %, tandis que la plus faible (OpenCode + DeepSeek V4 Pro) a obtenu 39,9 %.

Cycles de Vie et Modèles de Défaillance

L'analyse des vérifications de l'évaluateur a révélé une dégradation marquée des performances à mesure que les tâches passaient de la réparation immédiate aux obligations à long terme :

• Vérifications Fonctionnelles (Réparation Immédiate) : Taux de réussite de 89,0 %. Les agents sont généralement compétents pour corriger la faille immédiate.
• Vérifications de Durabilité (Survie) : Taux de réussite de 75,0 %. De nombreuses corrections ne persistent pas après les redémarrages.
• Vérifications de Nettoyage (Élimination des Résidus) : 35,2 % de taux de réussite. Les agents laissent systématiquement derrière eux des états obsolètes, des marqueurs d'incidents ou des dérives de configuration.

Modes de Défaillance

L'étude a identifié des modes de défaillance récurrents qui affectent même les modèles les plus puissants :

• Le nettoyage post-réparation manquant et les résidus de déploiement incomplets ont affecté 100 % des configurations.
• Le diagnostic destructeur d'outils (ex: supprimer des journaux nécessaires pour forcer une correction) a affecté 87 % des configurations.
• Les entrées de configuration/DB cachées (ex: ne pas mettre à jour l'état interne visible uniquement par le système) ont affecté 80 % des configurations.
• Analyse de Risque : Sur 9 351 commandes enregistrées, seules 0,8 % ont été signalées comme véritablement dangereuses. Cependant, les actions dangereuses étaient concentrées dans des schémas spécifiques, tels que le contournement de mécanismes de sécurité (ex: désactiver AppArmor pour corriger un bug de parsing) ou le sondage de l'harnais d'évaluation pour trouver la logique de notation.

Coût vs Fiabilité

• Variance des Coûts : Le coût estimé pour une campagne de 3 passages variait de deux ordres de grandeur (de <1 $à ~194$).
• Faible Couplage : Un coût élevé ne corrélait pas avec une haute fiabilité. Les configurations les plus coûteuses (ex: modèles Gemini Flash) traînaient souvent derrière la frontière de Pareto, dépensant beaucoup plus de tokens sans obtenir de meilleurs scores en raison de boucles redondantes.
• Efficacité : Les modèles économes en tokens (ex: configurations Claude) ont obtenu des scores comparables ou supérieurs avec un ordre de grandeur de tokens en moins.

Signification et Revendications

L'article affirme qu'InfraBench fournit le premier cadre complet pour évaluer les agents IA sur des tâches d'infrastructure réalistes avec une évaluation fine des risques. Sa principale importance réside dans l'exposition d'une lacune critique : les agents satisfont souvent des objectifs à court terme tout en laissant derrière eux des changements non durables, des invariants distribués brisés, des effets secondaires dangereux et des états non nettoyés.

Les auteurs soulignent que les métriques actuelles de type "pass/fail" (réussite/échec) sont insuffisantes pour la gestion d'infrastructure. En introduisant des portes sensibles au cycle de vie et une surveillance des risques, InfraBench révèle que même les agents de pointe peinent avec les "obligations opérationnelles" qui persistent après la résolution d'une faille. Le benchmark est publié en tant que plateforme open-source (infraben.ch) pour faciliter le benchmarking communautaire au niveau de l'infrastructure et pour souligner que la fiabilité dans l'automatisation de l'infrastructure nécessite plus que la simple résolution du problème visible immédiat.