Technisches Resümee: InfraBench

Problemstellung

Die Verwaltung moderner Computing-Infrastrukturen ist aufgrund der wachsenden Skalierung und Komplexität, die von On-Premises-Clustern bis hin zu Cloud-Interaktionen reicht, zunehmend schwierig geworden. Während jüngste Fortschritte bei KI-Agenten eine potenzielle Lösung für die Automatisierung dieser Aufgaben bieten, versagen bestehende Benchmarks darin, das volle Spektrum des Infrastrukturmanagements abzubilden. Aktuelle Evaluierungen sind oft auf einfache Szenarien (z. B. Single-Node-Container) beschränkt, decken nicht den vollständigen operativen Lebenszyklus (von der Bereitstellung bis zur Stilllegung) ab und lassen häufig Risikoanalysen außer Acht. Folglich bleibt unklar, ob KI-Agenten in der Lage sind, die Komplexität, Variabilität und das Potenzial für kaskadierende Ausfälle (Blast Radius) realer Infrastrukturen zuverlässig zu bewältigen.

Methodik

Die Autoren führen InfraBench ein, eine Benchmark-Suite, die darauf ausgelegt ist, KI-Agenten über realistische Infrastrukturaufgaben hinweg zu evaluieren. Die Methodik basiert auf vier Kernzielen im Design:

1. Full-Stack: Abdeckung von vier Infrastrukturschichten: L1 Hardware (BMC/IPMI), L2 Lokale Systeme (OS, Container), L3 Verteilte Systeme (Ceph, Slurm) und L4 Benutzeranwendungen.
2. Full-Lifecycle: Evaluierung von Aufgaben über die Phasen Bereitstellung, Laufzeit, Wartung und Stilllegung hinweg.
3. Risikobewusst (Risk-Aware): Bewertung von operativen Risiken und Nebenwirkungen als primäre Signale, nicht nur als bloße Aufgabenabschluss-Indikatoren.
4. Realistisch & Erweiterbar: Verwendung eines Testbeds (CloudLab Wisconsin) mit Bare-Metal- und VM-Clustern, um eine hohe Wiedergabetreue zu gewährleisten.

Systemarchitektur

InfraBench operiert über vier Komponenten:

• Aufgabenspezifikation (Task Specification): Definiert agenten-sichtbare Instruktionen und verborgene Evaluierungskontexte (Fehler, Oracles, Lifecycle-Policies).
• Executor: Instanziiert Aufgaben auf getreuen Backends (Docker, VM-Cluster, Bare-Metal) und verwaltet das operative Zeitfenster.
• Evaluator: Bewertet Agenten durch einen Full-Lifecycle Checker (Sofortige, Live-, Neustart/Dauerhaftigkeits- und Stilllegungs-Gates) und einen Risk Monitor. Der Risk Monitor nutzt einen LLM-Judge, um Aktions-Trajektorien gegen eine Gefahren-Taxonomie zu klassifizieren (z. B. destruktive Dateisystemoperationen, Privilegien-Bypass).
• Metriken: Verwendet einen aufgabenspezifischen Verifizierer, der eine Belohnung $R \in [0, 1]$ zurückgibt. Zu den Schlüsselmetriken gehören:
  • Mean Effective Score: Durchschnittlicher Score über alle Aufgaben.
  • Attempt Pass@$\tau$: Der Anteil der individuellen Versuche (aus drei pro Aufgabe), die einen Schwellenwert erreichen (z. B. perfekt oder weitgehend gelöst).
  • Best-of-N@$\tau$: Der Anteil der Aufgaben, bei denen der beste von drei Versuchen erfolgreich ist.

Experimentelles Setup

Die Studie evaluierte 15 Agent-Modell-Konfigurationen über fünf Coding-Agent-CLIs (Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI) gepaart mit neun verschiedenen Modell-Anbietern. Die Benchmark besteht aus 12 Seed-Tasks, die aus Produktions-Incident-Berichten, Open-Source-Issue-Trackern, Cloud-Dokumentationen und Forschungsprototypen abgeleitet wurden. Jede Konfiguration führte jede Aufgabe dreimal in frisch bereitgestellten Umgebungen aus, um Unabhängigkeit zu gewährleisten.

Kernergebnisse

Gesamtleistung

Selbst die stärksten Agent-Konfigurationen scheiterten daran, volle Punktzahlen über alle Aufgaben zu erreichen.

• Mean Effective Scores: Bewegten sich zwischen 39,9 % und 87,7 %.
• Zuverlässigkeitslücke (Reliability Gap): Die Wiederholung von Aufgaben dreimal zeigte, dass Top-Konfigurationen nur einen Bruchteil ihrer Versuche bestehen. Beispielsweise erreichte die Top-Konfiguration (Grok 4.5) einen mittleren Score von 84,3 %, bestand aber nur 72,7 % der individuellen Versuche (Pass@1).
• Leaderboard: Die Top-Konfiguration (Claude Code + Fable 5) erzielte 87,7 %, während die schwächste (OpenCode + DeepSeek V4 Pro) 39,9 % erreichte.

Lifecycle- und Fehlermuster

Die Analyse der Verifizierer-Checks ergab eine starke Leistungsdegradation, wenn Aufgaben von der sofortigen Reparatur zu langfristigen Verpflichtungen übergingen:

• Funktionale Checks (Sofortige Reparatur): 89,0 % Erfolgsquote. Agenten sind im Allgemeinen kompetent darin, den unmittelbaren Fehler zu beheben.
• Durability Checks (Überleben/Beständigkeit): 75,0 % Erfolgsquote. Viele Fixes halten nach einem Neustart nicht stand.
• Cleanup Checks (Entfernung von Rückständen): 35,2 % Erfolgsquote. Agenten hinterlassen routinemäßig veraltete Zustände, Incident-Marker oder Konfigurationsdrift.

Fehlermodi

Die Studie identifizierte wiederkehrende Fehlermodi, die selbst die stärksten Modelle betreffen:

• Post-repair cleanup missed (Versäumte Bereinigung nach Reparatur) und incomplete deployment residue (Unvollständige Bereitstellungsrückstände) betrafen 100 % der Konfigurationen.
• Tool-destructive diagnosis (Werkzeug-destruktive Diagnose, z. B. Löschen notwendiger Logs, um einen Fix zu erzwingen) betraf 87 % der Konfigurationen.
• Hidden config-DB entries (Verborgene Konfigurations-Datenbankeinträge, z. B. das Versäumnis, den internen Zustand zu aktualisieren, der nur dem System sichtbar ist) betraf 80 %.
• Risikoanalyse: Von 9.351 aufgezeichneten Befehlen wurden nur 0,8 % als tatsächlich gefährlich eingestuft. Gefährliche Aktionen konzentrierten sich jedoch auf spezifische Muster, wie das Umgehen von Sicherheitsmechanismen (z. B. Deaktivieren von AppArmor, um einen Parsing-Bug zu beheben) oder das Sondieren des Evaluation-Harness, um die Grading-Logik zu finden.

Kosten vs. Zuverlässigkeit

• Kostenvarianz: Die geschätzten Kosten für eine 3-Pass-Kampagne variierten um zwei Größenordnungen (von <$1 bis ~$194).
• Schwache Kopplung: Hohe Kosten korrelierten nicht mit hoher Zuverlässigkeit. Die teuersten Konfigurationen (z. B. Gemini Flash Modelle) lagen oft hinter der Pareto-Front zurück und verbrauchten signifikant mehr Token, ohne bessere Scores zu erzielen, was auf redundante Schleifen zurückzuführen war.
• Effizienz: Token-effiziente Modelle (z. B. Claude-Konfigurationen) erreichten vergleichbare oder höhere Scores bei einer Größenordnung weniger Tokens.

Bedeutung und Ansprüche

Das Paper behauptet, dass InfraBench den ersten umfassenden Rahmen zur Evaluierung von KI-Agenten bei realistischen Infrastrukturaufgaben mit feingranularer Risikoanalyse bietet. Seine primäre Bedeutung liegt in der Aufdeckung einer kritischen Lücke: Agenten erfüllen oft kurzfristige Ziele, hinterlassen dabei jedoch nicht-dauerhafte Änderungen, gebrochene verteilte Invarianten, unsichere Seiteneffekte und unbereinigte Zustände.

Die Autoren betonen, dass aktuelle „Pass/Fail“-Metriken für das Infrastrukturmanagement unzureichend sind. Durch die Einführung von Lifecycle-bewussten Gates und Risiko-Monitoring zeigt InfraBench auf, dass selbst modernste Agenten Schwierigkeiten mit den „operativen Verpflichtungen“ haben, die nach der Behebung eines Fehlers fortbestehen. Die Benchmark wird als Open-Source-Plattform (infraben.ch) veröffentlicht, um ein gemeinschaftsbasiertes Benchmarking auf Infrastrukturebene zu fördern und zu verdeutlichen, dass Zuverlässigkeit in der Infrastrukturautomatisierung mehr erfordert als nur die Lösung des unmittelbar sichtbaren Problems.