💻 computer science

Stalled, Biased, and Confused: Uncovering Reasoning Failures in LLMs for Cloud-Based Root Cause Analysis

Questo articolo presenta una valutazione empirica su larga scala di sei LLM in un framework controllato per isolare e categorizzare i fallimenti del ragionamento nell'analisi delle cause radice basata su cloud, rivelando debolezze specifiche nella propagazione dei guasti multi-hop e fornendo una tassonomia per guidare i futuri miglioramenti nella diagnostica automatizzata dei sistemi.

Autori originali: Evelien Riddell, James Riddell, Gengyi Sun, Michał Antkiewicz, Krzysztof Czarnecki

Pubblicato 2026-02-02

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Evelien Riddell, James Riddell, Gengyi Sun, Michał Antkiewicz, Krzysztof Czarnecki

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere il capo detective di una metropoli futuristica, enorme, fatta interamente di edifici digitali (un "sistema cloud"). Un giorno, una luce sfarfalla in un grattacielo e, improvvisamente, ingorghi stradali, blackout e guasti agli ascensori si verificano in tutta la città. Il tuo compito è l'Analisi della Causa Radice (RCA): trovare la singola, minuscola scintilla che ha dato il via a tutta questa reazione a catena.

In passato, gli esseri umani facevano questo lavoro setacciando montagne di rapporti cartacei. Ora, stiamo cercando di usare i Large Language Models (LLM) — chatbot IA super intelligenti — per agire come i nostri detective. La grande domanda è: i nostri detective IA sono davvero bravi a risolvere il mistero, o stanno solo tirando a indovinare?

Questo articolo è un esperimento massiccio per scoprirlo. I ricercatori hanno costruito una "scena del crimine" controllata per testare sei diversi detective IA sotto regole rigide, rimuovendo tutte le distrazioni che di solito nascondono i loro errori.

Ecco cosa hanno scoperto, spiegato in modo semplice:

1. L'allestimento: Una Scena del Crimine Controllata

Di solito, quando si testa l'IA per risolvere problemi informatici, si costruiscono robot complessi con molte parti (come un team di agenti che parlano tra loro). È difficile capire se l'IA è fallita perché è "stupida" o perché il design del robot era scadente.

I ricercatori hanno deciso di eliminare tutto il superfluo. Hanno dato all'IA:

Gli Indizi: Avvisi semplificati (come "Errore alle 8:42", "CPU calda", "Connessione fallita").
La Mappa: Una mappa chiara e testuale di come sono collegati gli edifici della città (un Grafo di Conoscenza).
Le Regole: L'IA poteva porre solo domande specifiche per controllare la mappa. Non poteva semplicemente scrivere codice o tirare a indovinare selvaggiamente.

Hanno eseguito 48.000 guasti simulati (che è come far lavorare il detective per 228 giorni senza sosta) per vedere quanto bene risolvevi i casi.

2. I Tre Modi in cui l'IA Tenta di Risolvere i Crimini

Hanno testato l'IA in tre diversi "stili di pensiero":

Lo "Scatto Diretto" (L'Indovino Istantaneo): L'IA riceve tutti gli indizi in una volta sola e deve indovinare il colpevole immediatamente. Senza pensare ad alta voce.
Il "ReAct" (Il Detective con il Taccuino): L'IA pensa, poi controlla un indizio, poi pensa di nuovo in base a ciò che ha trovato. È un processo di avanti e indietro.
Il "Pianifica ed Esegui" (Il Grande Pianificatore): L'IA scrive prima un piano d'indagine completo, poi cerca di seguirlo passo dopo passo.

3. Le Grandi Sorprese (I Risultati)

Sorpresa n. 1: Più grande non significa sempre meglio, e "pensare" non sempre aiuta.

Alcuni modelli di IA erano sorprendentemente bravi a indovinare l'edificio giusto, mentre altri erano terribili.
Il metodo "Pianifica ed Esegui" spesso peggiorava le cose. Per i modelli di IA più piccoli, cercare di creare un piano complesso prima di iniziare finiva solo per confonderli. Finivano in loop o si arrendevano. È come chiedere a uno studente stanco di scrivere un saggio di 10 pagine prima ancora di aver letto il libro di testo; finisce solo per inventare fatti.
Lo "Scatto Diretto" (indovinare immediatamente) era spesso altrettanto efficace, o addirittura migliore, rispetto ai metodi complessi per i modelli più piccoli.

Sorpresa n. 2: L'IA si distrae con gli indizi sbagliati.

Le Metriche (numeri come l' "utilizzo della CPU") erano gli indizi migliori. Quando l'IA aveva questi numeri, riusciva solitamente a trovare l'edificio giusto.
I Log (messaggi di testo) aiutavano a capire cosa fosse andato storto (ad esempio, "Database crashato" rispetto a "Rete fallita").
Le Tracce (il percorso seguito da una richiesta) erano in realtà una trappola. Quando all'IA veniva forniti i dati delle tracce, spesso si confondeva e le prestazioni peggioravano. Era come se il detective diventasse così ossessionato dalle impronte del sospettato da dimenticare di guardare la serratura rotta sulla porta. Le tracce erano troppo rumorose e distraevano l'IA.

Sorpresa n. 3: L'IA ha una "personalità" specifica di errori.
I ricercatori hanno creato una "Galleria della Vergogna" (una tassonomia) di 16 modi in cui l'IA fallisce. Ecco i più comuni:

Allucinazione di Prove: L'IA afferma con sicurezza: "Ho visto un file di log che diceva X", quando in realtà quel file non esisteva. È come un detective che dice: "Ho visto il sospettato al parco", quando il parco era chiuso.
Bias di Ancoraggio: L'IA sceglie un sospettato troppo presto e si rifiuta di cambiare idea, anche quando nuove prove dimostrano che ha torto.
Stallo: L'IA rimane bloccata in un loop, ripetendo lo stesso pensiero ripetutamente senza fare progressi.
Confusione della Mappa: L'IA pensa che un sintomo (come un ascensore lento) sia la causa, invece di rendersi conto che l'ascensore sta solo reagendo a una linea elettrica interrotta.

4. Il Verdetto

L'articolo conclude che, sebbene l'IA mostri potenziale, gli attuali detective IA open-source non sono pronti per gestire da soli un sistema cloud.

Spesso sono in stallo (bloccati in loop), preconcetti (scelgono la prima idea che piace loro) e confusi (confondono causa ed effetto).
Aggiungere flussi di lavoro più complessi (come farli pianificare in anticipo) spesso fa fallire di più i modelli di IA più piccoli perché non riescono a gestire il carico mentale.
L'IA è brava a usare i numeri (metriche) ma scarsa nel gestire contemporaneamente percorsi complessi (tracce) e log testuali.

Il Punto Fondamentale:
Per rendere l'IA utile per riparare i sistemi cloud, non possiamo limitarci a darle strumenti più complessi. Dobbiamo insegnarle capacità di ragionamento migliori, impedirle di distrarsi con dati rumorosi e, forse, mantenere "l'umano nel ciclo" per controllare il suo lavoro. L'IA è un tirocinante intelligente, ma in questo momento ha bisogno di un manager molto severo per evitare che inventi la propria realtà.

Sintesi Tecnica: Stalled, Biased, and Confused: Uncovering Reasoning Failures in LLMs for Cloud-Based Root Cause Analysis

Definizione del Problema

L'Analisi della Causa Radice (Root Cause Analysis, RCA) è fondamentale per mantenere l'affidabilità nei moderni sistemi cloud-native basati su microservizi. Tuttavia, la natura distribuita e interdipendente di questi sistemi complica la diagnosi, in particolare per la propagazione dei guasti multi-hop, dove i sintomi appaiono distanti dalle loro vere cause. Sebbene i Large Language Models (LLM) offrano promesse per l'automazione della RCA attraverso capacità di ragionamento generale e uso di strumenti, la loro utilità pratica rimane incerta.

Gli approcci esistenti soffrono di due lacune metodologiche primarie:

Ragionamento Oscurato: Molti framework inseriscono gli LLM all'interno di pipeline multi-agente complesse o flussi di lavoro pesantemente ingegnerizzati. Questo intreccio rende difficile isolare se i fallimenti derivino dalle capacità di ragionamento dell'LLM o da scelte di progettazione periferiche (ad esempio, dipendenze tra agenti, euristiche specifiche del sistema).
Mancanza di Valutazione del Ragionamento: Il lavoro precedente valuta tipicamente solo l'accuratezza dell'output finale o si affida a giudizi umani grossolani. Non esiste una valutazione sistematica, riproducibile e automatizzata della qualità delle tracce di ragionamento intermedie, il che è essenziale per comprendere la propagazione dei guasti multi-hop.

Di conseguenza, manca una comprensione empirica delle capacità di ragionamento isolate degli LLM nella RCA, dei fattori che influenzano le loro prestazioni e dei fallimenti specifici del ragionamento che manifestano.

Metodologia

Gli autori presentano una valutazione empirica controllata progettata per isolare il comportamento di ragionamento dell'LLM dai fattori di confondimento. Lo studio utilizza un ambiente sperimentale semplificato che mette in primo piano l'LLM pur mantenendo la complessità del ragionamento multi-hop.

Framework Sperimentale

Dataset: Sono stati utilizzati due dataset di microservizi reali: GAIA (derivato dall'applicazione MicroSS) e OpenRCA (derivato dall'applicazione Online Boutique). Questi forniscono dati di telemetria multi-modali (log, metriche, tracce).
Elaborazione dell'Input:
- Estrazione degli Alert: La telemetria grezza viene elaborata tramite fusione delle caratteristiche. I log vengono analizzati (Drain), le tracce sono analizzate per anomalie (Isolation Forest) e le metriche sono segnalate tramite la regola del 3-sigma.
- Unificazione degli Alert: Gli alert vengono unificati tramite strategie basate sul tempo o sull'elemento per creare una rappresentazione di input coerente.
- Grafo di Conoscenza (KG): Un KG esplicito e tipizzato viene costruito dalla documentazione architettonica e dai manifest, codificando entità (servizi, host) e relazioni (flusso di controllo, flusso di dati, deployment). Questo funge da verità fondamentale (ground truth) per la topologia del sistema.
Workflow degli Agenti: Sei LLM open-source (inclusi Llama 3.2/3.3, Qwen 3, Command R+, e DeepSeek-R1) sono stati valutati sotto tre paradigmi distinti:
1. Straight-Shot (Non-agentico): L'LLM riceve tutti gli input e restituisce una diagnosi in un unico passaggio.
2. ReAct: L'LLM alterna il ragionamento con chiamate a strumenti (ciclo Thought-Action-Observation).
3. Plan-and-Execute: L'LLM genera un piano di alto livello, esegue i passaggi sequenzialmente e ri-pianifica in base ai risultati.
Strumenti: Agli LLM sono stati forniti strumenti deterministici e semanticamente minimalisti per l'ispezione dei dati e la navigazione del grafo (ad esempio, recupero di vicinati a $r$ -hop). L'accesso diretto al KG grezzo o l'esecuzione del codice sono stati limitati per garantire che il ragionamento fosse la variabile primaria.

Metriche di Valutazione

Qualità dell'Output: Misurata tramite Localizzazione Accuratezza (LA), Tipo di Accuratezza (TA), Accuratezza dell'Ipotesi (HA) e Validità del Percorso di Propagazione (PA) ai top- $k$ ( $k=1, 3$ ).
Qualità del Ragionamento: È stato impiegato un approccio innovativo LLM-as-a-Judge per annotare le tracce di inferenza. Una tassonomia di 16 Fallimenti del Ragionamento (RF) è stata sviluppata attraverso il coding aperto e il raffinamento iterativo (coinvolgendo annotazioni umane e di LLM). I fallimenti sono stati categorizzati in:
- Procedurali: Problemi nel ciclo decisione-azione (ad esempio, fallimento nell'aggiornamento delle credenze, ripetizione).
- Specifici della RCA: Errori di dominio (ad esempio, interpretazione delle metriche, confusione sulla provenienza).
- Generali: Fallacie logiche, collegamenti causali non supportati e contraddizioni interne.
Scala: Lo studio ha eseguito 48.000 scenari di guasto simulati, per un totale di 228 giorni di tempo di esecuzione.

Risultati Chiave

1. Efficacia degli Agenti LLM (RQ1)

Nessuna Soluzione Universale: Le prestazioni del modello sono specifiche per il compito. Qwen 3 (32B) ha ottenuto la più alta accuratezza complessiva dell'ipotesi, mentre Llama 3.3 eccelle nella ricostruzione del percorso di propagazione. I modelli più piccoli (ad esempio, Llama 3.2, Qwen 3 4B) hanno ottenuto prestazioni competitive in workflow semplici, ma sono degradati significativamente in contesti agentici complessi.
Rendimenti Decrescenti dei Workflow Agentici: Contrariamente all'ipotesi che i workflow agentici migliorino le prestazioni, lo Straight-Shot spesso eguaglia o supera ReAct e Plan-and-Execute in LA, TA e HA. Per i modelli più piccoli, l'aumento della complessità del workflow ha portato a cali di prestazione, scendendo talvolta al di sotto del caso casuale.
Validità del Percorso: I workflow agentici hanno migliorato la Validità del Percorso di Propagazione (PA) per i modelli capaci (ad esempio, Llama 3.3), suggerendo un migliore radicamento nel contesto del sistema, ma questo beneficio è condizionato alla capacità del modello di pianificare ed eseguire in modo affidabile le chiamate agli strumenti.
Errori di Esecuzione: I modelli piccoli hanno subito alti tassi di errore di esecuzione (ad esempio, 87,3% per Qwen 3 4B in Plan-and-Execute) a causa di limiti di ricorsione ed errori di ri-pianificazione, limitando severamente l'utilità end-to-end.

2. Sensibilità alle Modalità di Alert (RQ2)

Le Metriche sono Critiche per la Localizzazione: La mancanza di dati metrici ha causato il calo più grande nella localizzazione dell'accuratezza (LA), indicando che gli LLM si affidano fortemente alle anomalie delle metriche per identificare le posizioni dei guasti.
I Log sono Critici per il Tipo di Guasto: L'esclusione dei log ha degradato principalmente l'attribuzione del tipo di guasto (TA), suggerendo che gli alert testuali forniscono indizi semantici essenziali per la classificazione dell'errore.
Le Tracce come Distrazioni: Sorprendentemente, l'esclusione delle tracce ha spesso migliorato l'accuratezza. Gli autori hanno scoperto che gli alert delle tracce erano spesso rumorosi e voluminosi, causando agli LLM di concentrarsi sulle relazioni di chiamata ignorando altre dipendenze critiche (ad esempio, il deployment). Rimuoverli ha portato a un'analisi più focalizzata e basata sul KG.

3. Fallimenti del Ragionamento (RQ3)

Fallimenti Pervasivi: I fallimenti del ragionamento sono stati diffusi in tutti i modelli.
Instabilità Procedurale: I fallimenti procedurali (ad esempio, fallimento nell'aggiornamento delle credenze, speculazione eccessiva) variano significativamente per modello e workflow, con i modelli più piccoli che mostrano una maggiore instabilità sotto controllo agentico.
Lacune Specifiche della RCA: I fallimenti relativi alla conoscenza del dominio (ad esempio, interpretazione delle metriche, provenienza) sono stati coerenti tra i modelli, indicando una mancanza di capacità di ragionamento intrinseche specifiche per la RCA.
Debolezze Generali: I fallimenti generali per ipotesi (ad esempio, fabbricazione di prove, insufficienza delle evidenze) hanno avuto la prevalenza media più alta, suggerendo che le affermazioni ipotetiche sono frequentemente debolmente supportate.

4. Impatto dei Fallimenti sulla Correttezza (RQ4)

Predittori Negativi: La presenza di specifici fallimenti del ragionamento — in particolare l'ancoraggio (RF-13), la ripetizione/stallo del progresso (RF-12), la selezione arbitraria delle prove (RF-07) e il fallimento nell'aggiornamento delle credenze (RF-09) — è stata fortemente associata a una ridotta correttezza (Differenza di Rischio < -0,15).
Interazione con il Workflow: Sebbene i workflow agentici abbiano mostrato differenze di rischio assolute minori per singolo fallimento (suggerendo che il ragionamento iterativo possa diluire l'impatto dei singoli errori), la co-occorrenza di molteplici fallimenti e l'accumulo precoce di errori nelle tracce agentiche hanno contribuito a una perdita netta di accuratezza.
Differenze tra Modelli: I modelli orientati al "pensiero" (ad esempio, Qwen) hanno mostrato una minore prevalenza di fallimenti trasversali rispetto ad altri, suggerendo che lo stile di addestramento influenza la coerenza del ragionamento più della struttura del workflow da sola.

Significato e Contributi

Il paper sostiene di essere la prima investigazione empirica sulle capacità di ragionamento isolate degli agenti RCA basati su LLM e sui loro specifici modi di fallimento. I suoi principali contributi sono:

Un Framework di Valutazione Controllato: Una metodologia che isola il ragionamento dell'LLM dalla complessità del framework, consentendo una valutazione trasparente delle capacità di ragionamento indipendentemente dall'intreccio multi-agente.
Una Tassonomia dei Fallimenti del Ragionamento: Una tassonomia etichettata di 16 comuni fallimenti del ragionamento RCA, categorizzati in tipi procedurali, specifici della RCA e generali, derivata attraverso un rigoroso processo di elicitazione a metodi misti.
Valutazione Automatica del Ragionamento: Un sistema LLM-as-a-Judge capace di valutare automaticamente e in modo riproducibile la qualità del ragionamento RCA, validato da controlli di affidabilità umana.
Approfondimenti Empirici: Risultati estesi (48.000 campioni) che quantificano la sensibilità degli LLM alle modalità di input e identificano specifici fallimenti del ragionamento che predicono la correttezza finale.

Gli autori concludono che, sebbene le configurazioni semplificate non rendano banale il compito della RCA, gli attuali LLM open-source faticano con il ragionamento multi-hop, specialmente in workflow agentici complessi. Il progresso nella RCA automatizzata richiederà probabilmente il miglioramento di specifiche capacità di ragionamento (ad esempio, controlli di sufficienza delle prove, diversificazione delle ipotesi) e la fornitura di una guida di dominio esplicita, piuttosto che fare affidamento esclusivamente sulle strutture agentiche. Il lavoro fornisce una base per lo sviluppo di agenti RCA che non siano solo automatizzati, ma anche interpretabili e allineati con le richieste pratiche della diagnosi dei guasti.