IA‑Agenten falliscono silenziosamente: perché gli errori restano invisibili

Il nuovo paradigma degli agenti LLM

Gli agenti costruiti su grandi modelli linguistici (LLM) hanno ormai superato il ruolo di semplici chatbot. Oggi rispondono a richieste di supporto tecnico, interrogano database aziendali, prenotano viaggi e persino gestiscono workflow complessi. Il loro funzionamento è ciclico: il modello legge una prompt, decide quale strumento (API di ricerca, query di database, chiamata a un servizio esterno) attivare, interpreta il risultato e scegli il passo successivo. Ogni ciclo può produrre un errore, ma il sistema registra comunque una risposta di rete “successo”, rendendo difficile distinguere un risultato corretto da uno fallito.

Esempio tipico: il meteo che tradisce

Immaginiamo un agente che deve fornire la previsione del tempo. Il suo workflow prevede una chiamata a un servizio meteo. Se il servizio è offline, restituisce il messaggio “Servizio non disponibile”. Il modello, leggendo quel testo, può semplicemente scusarsi o, peggio, generare una previsione plausibile basata sui dati di addestramento. L’utente riceve una risposta fluida e corretta dal punto di vista sintattico, ma l’informazione è falsa. Nei log del server compare una chiamata con latenza normale e codice di stato 200; nessun avviso di errore viene generato.

Documentazione dei fornitori: la consapevolezza del problema

Le stesse lacune sono evidenziate nelle guide ufficiali dei principali fornitori. Il Gemini‑API‑Leitfaden di Google avverte che il modello non “esegue” la funzione: propone solo il nome della funzione e gli argomenti, mentre è l’applicazione del developer a effettuare la chiamata reale. Di conseguenza, solo l’applicazione vede il risultato effettivo.

Il Leitfaden di Anthropics per lo sviluppo di agenti aggiunge che gli agenti hanno bisogno di una “Ground Truth” fornita dall’ambiente (es. risultato di un tool). Se il tool restituisce un errore sotto forma di testo normale, la Ground Truth diventa errata e l’agente non può riconoscere il fallimento.

Rischi nascosti nelle dipendenze

Questa problematica non è nuova. Già nel 2015, D. Sculley e colleghi di Google descrissero le “technical debt” nascoste nei sistemi di machine learning, sottolineando che il rischio più grande risiede fuori dal codice del modello: dati, configurazioni e codice di integrazione. Gli agenti LLM aggiungono una nuova dimensione: le prompt e le descrizioni degli strumenti sono anch’esse configurazioni che possono alterare il comportamento senza modificare il codice sorgente.

Prompt engineering: piccole variazioni, grandi effetti

Quanto può influire una minima modifica a una prompt? In una ricerca presentata all’ICLR 2024, Melanie Sclar e colleghi dell’University of Washington hanno variato solo la formattazione di few‑shot prompts (spazi, separatori, maiuscole/minuscole). Nonostante il contenuto fosse identico, la performance di LLaMA‑2‑13B è oscillata di fino a 76 punti di accuratezza. Questa sensibilità persiste anche con modelli più grandi, più esempi o con instruction tuning.

Gli autori suggeriscono di riportare una “fascia di performance” per le varie formattazioni plausibili, anziché un singolo valore. Per i team di sviluppo, la lezione pratica è chiara: una modifica alla prompt è equiparabile a una modifica di codice. Deve quindi essere versionata, testata e revisionata prima di essere distribuita agli utenti.

Definizioni degli strumenti: la stessa cura del prompt

Anthropic raccomanda di dedicare la stessa attenzione alle descrizioni degli strumenti (tool definitions) quanto alla prompt principale. Un caso studio descrive un agente programmatore che, a causa di una definizione di tool che richiedeva percorsi relativi, generava costantemente errori. Modificando la definizione affinché accettasse percorsi assoluti, l’agente ha iniziato a operare correttamente senza alcun cambiamento al modello sottostante.

Misurare la affidabilità: il benchmark τ‑bench

Una seconda linea di ricerca si concentra sulla valutazione della robustezza. Il benchmark τ‑bench, presentato da Shunyu Yao e colleghi (Sierra, ICLR 2025), simula conversazioni di assistenza clienti in cui l’agente deve utilizzare strumenti e rispettare regole di business. Introduce la metrica pass^k, ossia la probabilità che l’agente completi correttamente lo stesso compito in k esecuzioni consecutive.

I risultati sono preoccupanti: un agente basato su GPT‑4o risolve correttamente il 61 % dei compiti in un singolo tentativo, ma la probabilità scende al 25 % quando si richiede otto esecuzioni consecutive senza errore. Una singola demo riuscita non è quindi indicativa della performance a lungo termine.

Multi‑agent system: complicazioni moltiplicate

Molti team ora concatenano più agenti: uno pianifica, un altro esegue, un terzo verifica. Una ricerca della UC Berkeley (2025), “Why do multi‑LLM systems fail?”, ha analizzato oltre 1 600 protocolli di esecuzione provenienti da sette framework popolari. Gli autori, guidati da Mert Cemri, hanno creato la tassonomia MAST con 14 modalità di errore divise in tre gruppi: design del sistema, coordinamento tra agenti e verifica dei risultati.

Le conclusioni indicano che la maggior parte dei fallimenti deriva da errori di architettura, non da limitazioni del modello. Gli agenti spesso ignorano il ruolo assegnato, perdono il contesto della conversazione o dichiarano conclusa un’attività senza controllare il risultato. Questi errori non generano messaggi di errore; sono visibili solo analizzando i log dettagliati di ogni agente.

Il paradosso dei multi‑agent

Un articolo di Unite.AI sul “paradosso dei sistemi multi‑agent” osserva che l’aggiunta di agenti può amplificare un errore iniziale anziché attenuarlo, se non esiste un meccanismo di verifica robusto.

Rendere visibile l’invisibile: tracing distribuito

La risposta tecnica più promettente si ispira ai sistemi distribuiti, dove le richieste attraversano numerosi microservizi e vengono tracciate tramite tracing. Trasportando questo concetto agli agenti, ogni richiesta dell’utente diventa un trace, e ogni chiamata a modello o tool è rappresentata da uno span. Uno span registra input, output, token utilizzati e tempo di esecuzione.

OpenTelemetry, l’organizzazione di riferimento per gli standard di tracing, sta definendo convention per span di IA generativa. Anche se, al 2026, le specifiche sono ancora in fase di bozza, l’obiettivo è standardizzare attributi quali “toolresponse”, “toolsuccess” e “error_message”.

Progetti open‑source già operativi

• Langfuse: raccoglie trace di modelli e tool, permette di etichettare ogni span con metriche di qualità.
• Arize Phoenix: fornisce dashboard per visualizzare performance e rilevare drift.
• AcruxCore: focalizzato su tracciamento a livello di token e latenza.

Il punto cruciale è che lo span del tool deve catturare il risultato effettivo del tool, non solo lo stato HTTP 200. Solo così il fallimento “Servizio non disponibile” del weather‑tool diventa rilevabile.

Stato del settore: testing ancora indietro rispetto al tracing

Un sondaggio di LangChain (fine 2025) ha intervistato 1 340 professionisti del settore. I risultati mostrano che, mentre il 78 % delle aziende utilizza qualche forma di tracing per gli agenti, solo il 32 % ha implementato test automatici sistematici per valutare la robustezza dei flussi multi‑step. La disparità indica una lacuna critica: è possibile vedere dove avvengono gli errori, ma spesso non c’è un processo continuo di verifica.

Raccomandazioni operative

• Versionare ogni prompt e ogni descrizione di tool come codice sorgente.
• Integrare OpenTelemetry o soluzioni analoghe per tracciare ogni chiamata di modello e di tool.
• Definire metriche di pass^k nei test di integrazione per valutare la stabilità a lungo termine.
• Utilizzare la tassonomia MAST per classificare e correggere i fallimenti di design.
• Implementare verifiche post‑esecuzione (es. confrontare la risposta del tool con uno schema atteso) prima di generare la risposta finale all’utente.

Conclusioni

Gli agenti basati su LLM offrono potenzialità rivoluzionarie, ma la loro capacità di “mascherare” gli errori con risposte plausibili li rende pericolosi in contesti critici. La ricerca dimostra che il problema è radicato nella mancanza di una Ground Truth affidabile, nella sensibilità alle configurazioni di prompt e nella complessità dei sistemi multi‑agent. Le soluzioni emergenti – tracing distribuito, benchmark come τ‑bench e la tassonomia MAST – forniscono una base per rendere visibili gli errori e per costruire pipeline di testing più robuste. Solo adottando questi approcci le organizzazioni potranno trasformare gli agenti da “casi di successo invisibili” a sistemi affidabili e verificabili.