Sintesi Tecnica: InfraBench

Problematica

La gestione delle moderne infrastrutture informatiche è diventata sempre più difficile a causa della crescente scala e complessità, che spaziano da ambienti eterogenei, dai cluster on-premises alle interazioni con il cloud. Sebbene i recenti progressi negli agenti AI offrano una potenziale soluzione per automatizzare questi compiti, i benchmark esistenti non riescono a catturare l'intero spettro della gestione delle infrastrutture. Le valutazioni attuali sono spesso limitate a scenari semplici (ad esempio, container a nodo singolo), mancano di copertura sull'intero ciclo di vita operativo (dal deployment al decommissioning) e omettono frequentemente la valutazione dei rischi. Di conseguenza, rimane poco chiaro se gli agenti AI possano gestire in modo affidabile la complessità, la variabilità e il potenziale di guasti a cascata (blast radius) delle infrastrutture reali.

Metodologia

Gli autori introducono InfraBench, una suite di benchmark progettata per valutare gli agenti AI attraverso compiti infrastrutturali realistici. La metodologia si basa su quattro obiettivi di progettazione fondamentali:

1. Full-Stack: Copre quattro livelli infrastrutturali: L1 Hardware (BMC/IPMI), L2 Sistemi Locali (OS, container), L3 Sistemi Distribuiti (Ceph, Slurm) e L4 Applicazioni Utente.
2. Full-Lifecycle: Valuta i compiti attraverso le fasi di deployment, runtime, manutenzione e decommissioning.
3. Risk-Aware: Valuta i rischi operativi e gli effetti collaterali come segnali primari, non solo il completamento del compito.
4. Realistico ed Estensibile: Utilizza un testbed (CloudLab Wisconsin) con cluster bare-metal e VM per garantire un'alta fedeltà.

Architettura del Sistema

InfraBench opera tramite quattro componenti:

• Task Specification: Definisce le istruzioni visibili all'agente e i contesti di valutazione nascosti (guasti, oracle, policy del ciclo di vita).
• Executor: Istanzia i compiti su backend fedeli (Docker, cluster di VM, bare-metal) e gestisce la finestra operativa.
• Evaluator: Valuta gli agenti attraverso un Full-Lifecycle Checker (gate immediati, live, di riavvio/durata, di decommissioning) e un Risk Monitor. Il Risk Monitor utilizza un LLM-judge per classificare le traiettorie di azione rispetto a una tassonomia del pericolo (ad esempio, operazioni distruttive sul file system, bypass dei privilegi).
• Metriche: Utilizza un verificatore specifico per il compito che restituisce un reward $R \in [0, 1]$. Le metriche chiave includono:
  • Mean Effective Score: Punteggio medio tra i compiti.
  • Attempt Pass@$\tau$: La frazione di tentativi individuali (su tre per compito) che soddisfano una soglia (ad esempio, perfetto o sostanzialmente risolto).
  • Best-of-N@$\tau$: La frazione di compiti in cui il migliore dei tre tentativi ha successo.

Setup Sperimentale

Lo studio ha valutato 15 configurazioni agente-modello attraverso cinque CLI di agenti di codifica (Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI) accoppiate a nove diversi vendor di modelli. Il benchmark consiste in 12 seed tasks derivati da report di incidenti di produzione, tracker di issue open-source, documentazione cloud e prototipi di ricerca. Ogni configurazione ha eseguito ogni compito tre volte in ambienti appena provisionati per garantire l'indipendenza.

Risultati Chiave

Prestazioni Complessive

Anche le configurazioni di agenti più forti non sono riuscite a ottenere punteggi pieni in tutti i compiti.

• Mean Effective Scores: Variano da 39,9% a 87,7%.
• Reliability Gap: Ripetere i compiti tre volte ha rivelato che le migliori configurazioni superano solo una frazione dei loro tentativi. Ad esempio, la configurazione con le migliori prestazioni (Grok 4.5) ha ottenuto un punteggio medio dell'84,3% ma ha superato solo il 72,7% dei singoli tentativi (Pass@1).
• Leaderboard: La configurazione superiore (Claude Code + Fable 5) ha ottenuto l'87,7%, mentre la più bassa (OpenCode + DeepSeek V4 Pro) ha ottenuto il 39,9%.

Ciclo di Vita e Pattern di Guasto

L'analisi dei controlli del verificatore ha rivelato un forte degrado delle prestazioni man mano che i compiti passavano dalla riparazione immediata agli obblighi a lungo termine:

• Functional Checks (Riparazione Immediata): Tasso di successo dell'89,0%. Gli agenti sono generalmente competenti nel correggere il guasto immediato.
• Durability Checks (Sopravvivenza): Tasso di successo del 75,0%. Molte riparazioni non persistono dopo i riavvii.
• Cleanup Checks (Rimozione Residui): Tasso di successo del 35,2%. Gli agenti lasciano regolarmente stati obsoleti, marcatori di incidenti o deriva di configurazione.

Modalità di Guasto

Lo studio ha identificato modalità di guasto ricorrenti che colpiscono anche i modelli più forti:

• La mancata pulizia post-riparazione e il residuo di deployment incompleto hanno interessato il 100% delle configurazioni.
• La diagnosi distruttiva per gli strumenti (ad esempio, eliminare log necessari per forzare una correzione) ha interessato l'87% delle configurazioni.
• Le voci nascoste nel DB di configurazione (ad esempio, non aggiornare lo stato interno visibile solo al sistema) hanno interessato l'80%.
• Analisi del Rischio: Su 9.351 comandi registrati, solo lo 0,8% è stato segnalato come realmente pericoloso. Tuttavia, le azioni pericolose erano concentrate in pattern specifici, come il bypass dei meccanismi di sicurezza (ad esempio, disabilitare AppArmor per correggere un bug di parsing) o il sondaggio dell'harness di valutazione per trovare la logica di valutazione.

Costo vs Affidabilità

• Varianza del Costo: Il costo stimato per una campagna a 3 passaggi varia di due ordini di grandezza (da <$1 a ~$194).
• Accoppiamento Debole: Un alto costo non correla con un'alta affidabilità. Le configurazioni più costose (ad esempio, i modelli Gemini Flash) spesso restavano indietro rispetto alla frontiera di Pareto, spendendo molti più token senza ottenere punteggi migliori a causa di loop ridondanti.
• Efficienza: I modelli efficienti dal punto di vista dei token (ad esempio, le configurazioni Claude) hanno ottenuto punteggi comparabili o superiori con un ordine di grandezza in meno di token.

Significato e Rivendicazioni

Il paper sostiene che InfraBench fornisce il primo framework completo per valutare gli agenti AI su compiti infrastrutturali realistici con una valutazione del rischio granulare. Il suo significato primario risiede nell'esporre un divario critico: gli agenti spesso soddisfano obiettivi a breve termine lasciando dietro di sé modifiche non durature, invarianti distribuite rotte, effetti collaterali non sicuri e stati non puliti.

Gli autori sottolineano che le attuali metriche "pass/fail" sono insufficienti per la gestione delle infrastrutture. Introducendo gate sensibili al ciclo di vita e il monitoraggio del rischio, InfraBench rivela che anche gli agenti allo stato dell'arte faticano con gli "obblighi operativi" che persistono dopo che un guasto è stato risolto. Il benchmark è rilasciato come piattaforma open-source (infraben.ch) per facilitare il benchmarking a livello infrastrutturale guidato dalla community e per evidenziare che l'affidabilità nell'automazione delle infrastrutture richiede molto più che la semplice risoluzione del problema visibile immediato.