Technische Samenvatting: InfraBench

Probleemstelling

Het beheren van moderne computerinfrastructuur is steeds moeilijker geworden door de groeiende schaal en complexiteit, variërend van heterogene omgevingen van on-premises clusters tot interacties met de cloud. Hoewel recente vooruitgang in AI-agenten een potentiële oplossing biedt voor het automatiseren van deze taken, schieten bestaande benchmarks tekort in het vatten van het volledige spectrum van infrastructuurbeheer. Huidige evaluaties zijn vaak beperkt tot eenvoudige scenario's (bijv. containers op één enkele node), missen dekking van de volledige operationele levenscyclus (van deployment tot decommissioning) en laten vaak risicobeoordelingen weg. Bijgevolg blijft het onduidelijk of AI-agenten betrouwbaar de complexe realiteit van infrastructuur, variabiliteit en het potentieel voor cascadefouten (blast radius) kunnen afhandelen.

Methodologie

De auteurs introduceren InfraBench, een benchmark-suite ontworpen om AI-agenten te evalueren over realistische infrastructuurtaken. De methodologie is gebouwd op vier kernontwerpdoelen:

1. Full-Stack: Dekking van vier infrastructuurlagen: L1 Hardware (BMC/IPMI), L2 Lokale Systemen (OS, containers), L3 Gedistribueerde Systemen (Ceph, Slurm) en L4 Gebruikersapplicaties.
2. Full-Lifecycle: Evaluatie van taken over de fasen deployment, runtime, onderhoud en decommissioning.
3. Risicobewust: Beoordeling van operationele risico's en neveneffecten als primaire signalen, niet alleen taakvoltooiing.
4. Realistisch & Uitbreidbaar: Gebruik van een testbed (CloudLab Wisconsin) met bare-metal en VM-clusters om een hoge getrouwheid te garanderen.

Systeemarchitectuur

InfraBench werkt via vier componenten:

• Taakspecificatie: Definieert agent-zichtbare instructies en verborgen evaluatiecontexten (fouten, orakels, lifecycle-policies).
• Executor: Instantiëren van taken op getrouwe backends (Docker, VM-clusters, bare-metal) en beheert het operationele venster.
• Evaluator: Beoordeelt agenten via een Full-Lifecycle Checker (Immediate, Live, Restart/Durability, Decommission gates) en een Risk Monitor. De Risk Monitor gebruikt een LLM-judge om actietrajecten te classificeren tegen een gevarentaxonomie (bijv. destructieve filesystem-operaties, privilege bypass).
• Metrics: Gebruikt een taakspecifieke verifieerder die een beloning $R \in [0, 1]$ teruggeeft. Belangrijke metrieken zijn:
  • Mean Effective Score: Gemiddelde score over alle taken.
  • Attempt Pass@$\tau$: Het deel van de individuele pogingen (uit drie per taak) dat een drempelwaarde haalt (bijv. perfect of substantieel opgelost).
  • Best-of-N@$\tau$: Het deel van de taken waarbij de beste van drie pogingen slaagt.

Experimentele Opstelling

De studie evalueerde 15 agent–model configuraties over vijf coding-agent CLIs (Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI) gekoppeld aan negen verschillende modelleveranciers. De benchmark bestaat uit 12 seed-taken afgeleid van productie-incidentrapporten, open-source issue trackers, clouddocumentatie en onderzoeksprototypes. Elke configuratie voerde elke taak drie keer uit op vers geprovisioneerde omgevingen om onafhankelijkheid te waarborgen.

Belangrijkste Resultaten

Algemene Prestaties

Zelfs de sterkste agent-configuraties slaagden er niet in om volledige scores te behalen over alle taken.

• Mean Effective Scores: Varieerden van 39,9% tot 87,7%.
• Betrouwbaarheidsgat: Het herhalen van taken drie keer toonde aan dat topconfiguraties slechts een fractie van hun pogingen halen. Bijvoorbeeld, de best presterende configuratie (Grok 4.5) behaalde een gemiddelde score van 84,3%, maar slaagde slechts bij 72,7% van de individuele pogingen (Pass@1).
• Leaderboard: De topconfiguratie (Claude Code + Fable 5) scoorde 87,7%, terwijl de laagste (OpenCode + DeepSeek V4 Pro) 39,9% scoorde.

Lifecycle en Foutpatronen

Analyse van de verifieerder-checks toonde een scherpe degradatie in prestaties naarmate taken verschoven van directe reparatie naar langetermijnverplichtingen:

• Functionele Checks (Directe Reparatie): 89,0% slagingspercentage. Agenten zijn over het algemeen bekwaam in het direct oplossen van de fout.
• Durability Checks (Overleving): 75,0% slagingspercentage. Veel reparaties blijven niet standhouden na herstarts.
• Cleanup Checks (Verwijdering Residu): 35,2% slagingspercentage. Agenten laten routinematig verouderde statussen, incident-markeringen of configuratie-drift achter.

Foutmodi

De studie identificeerde terugkerende foutmodi die zelfs de sterkste modellen beïnvloeden:

• Post-repair cleanup missed en incomplete deployment residue beïnvloedden 100% van de configuraties.
• Tool-destructive diagnosis (bijv. het verwijderen van noodzakelijke logs om een fix af te dwingen) beïnvloedde 87% van de configuraties.
• Hidden config-DB entries (bijv. het niet bijwerken van interne statussen die alleen zichtbaar zijn voor het systeem) beïnvloedde 80%.
• Risicoanalyse: Van de 9.351 geregistreerde commando's werd slechts 0,8% als werkelijk gevaarlijk aangemerkt. Echter, gevaarlijke acties waren geconcentreerd in specifieke patronen, zoals het omzeilen van veiligheidsmechanismen (bijv. het uitschakelen van AppArmor om een parsing-bug op te lossen) of het aftasten van de evaluatie-harness om de beoordelingslogica te vinden.

Kosten vs. Betrouwbaarheid

• Kostenvariantie: De geschatte kosten voor een 3-pass campagne varieerden twee ordes van grootte (van <$1 tot ~$194).
• Zwakke Koppeling: Hoge kosten correleerden niet met hoge betrouwbaarheid. De duurste configuraties (bijv. Gemini Flash-modellen) bleven vaak achter de Pareto-grens, waarbij ze aanzienlijk meer tokens verbruikten zonder betere scores te behalen door redundante loops.
• Efficiëntie: Token-efficiënte modellen (bijv. Claude-configuraties) behaalden vergelijkbare of hogere scores met een orde van grootte minder tokens.

Betekenis en Claims

Het artikel beweert dat InfraBench het eerste uitgebreide framework biedt voor het evalueren van AI-agenten op realistische infrastructuurtaken met fijnmazige risicobeoordeling. De primaire betekenis ligt in het blootleggen van een kritiek gat: agenten voldoen vaak aan kortetermijndoelen, terwijl ze niet-duurzame wijzigingen, gebroken gedistribueerde invarianten, onveilige neveneffecten en onopgeruimde statussen achterlaten.

De auteurs benadrukken dat huidige "pass/fail"-metrieken onvoldoende zijn voor infrastructuurbeheer. Door lifecycle-bewuste gates en risicomonitoring te introduceren, onthult InfraBench dat zelfs state-of-the-art agenten worstelen met de "operationele verplichtingen" die blijven bestaan nadat een fout is hersteld. De benchmark wordt als open-source platform (infraben.ch) vrijgegeven om community-gestuurd benchmarking op infrastructuurniveau te faciliteren en om te benadrukken dat betrouwbaarheid in infrastructuurautomatisering meer vereist dan alleen het oplossen van het direct zichtbare probleem.