Perché gli agenti IA possono dare risposte “corrette” quando qualcosa è andato storto

Gli agenti costruiti su grandi modelli di linguaggio (LLM) sono ora in grado di gestire richieste di assistenza, interrogare basi di dati e persino pianificare viaggi. Quando questi sistemi non funzionano, però, tendono a restituire una risposta sicura e un codice di successo, nascondendo l’errore reale.

Al contrario dei tradizionali software, i cui errori si manifestano con eccezioni, codici di errore o dashboard in rosso, un agente IA opera in un ciclo continuo: legge un prompt, decide di chiamare uno strumento (ad esempio un’API di ricerca), elabora il risultato e decide il passo successivo. Ogni fase può fallire anche se le richieste di rete terminano con successo.

Un esempio tipico riguarda un servizio meteorologico non disponibile che restituisce la stringa “service unavailable”. Il modello, leggendo quel testo, può scusarsi educatamente o, peggio, generare previsioni plausibili basate sui dati di addestramento, consegnando all’utente una risposta fluida. I log del server mostrano una chiamata riuscita con latenza normale, quindi nessun allarme viene attivato.

Documentazione dei fornitori e la “verità terreno” mancante

Le guide ufficiali dei fornitori riconoscono questa lacuna. Il guida API Gemini di Google specifica che il modello “non esegue la funzione da solo”; si limita a suggerire il nome della funzione e gli argomenti, mentre l’applicazione del developer è l’unica parte a conoscere il risultato reale.

Allo stesso modo, il guida di ingegneria di Anthropic afferma che gli agenti hanno bisogno, ad ogni passo, di una “verità terreno” proveniente dall’ambiente (i risultati degli strumenti) per valutare i propri progressi. Se uno strumento segnala un fallimento con un semplice testo, quella verità è errata e l’agente non può accorgersene.

Questo problema non è nuovo. Già nel 2015, gli ingegneri di Google guidati da D. Sculley descrissero la “debito tecnico nascosto” dei sistemi di machine learning: la maggior parte dei rischi in produzione risiede al di fuori del codice del modello, nelle dipendenze dai dati, nella configurazione e nel codice di integrazione. Gli agenti aggiungono un nuovo elemento a questa lista: i prompt e le descrizioni degli strumenti, che possono modificare il comportamento senza alterare il codice.

Impatto di piccole variazioni nei prompt

Quanto può influire una minima modifica di prompt? Uno studio presentato a ICLR 2024 da Melanie Sclar e colleghi dell’University of Washington ha sperimentato cambiamenti minori nella formattazione di pochi esempi (separatori, spaziatura, maiuscole). Il contenuto rimaneva identico, ma le performance su una stessa task variavano fino a 76 punti di precisione con LLaMA‑2‑13B.

Questa sensibilità persisteva anche con modelli più grandi, più esempi o fine‑tuning per istruzioni. Gli autori suggeriscono di riportare una gamma di performance ottenute con formati di prompt plausibili, anziché un unico valore.

Per le squadre di ingegneria la lezione è pratica: modificare un prompt equivale a modificare codice. È necessario mantenere un versionamento, testare le variazioni e rilasciare solo quelle verificate.

Descrizioni degli strumenti: un altro punto critico

Lo stesso principio vale per le descrizioni degli strumenti, che il modello legge all’interno del prompt. Il guida di Anthropic raccomanda di dedicare “tutta l’attenzione dell’ingegneria dei prompt” anche a queste definizioni.

Un caso di studio descrive un agente di programmazione che sbagliava costantemente i percorsi di file relativi. Dopo aver modificato la descrizione dello strumento per richiedere percorsi assoluti, l’agente ha operato correttamente, nonostante il modello fosse rimasto invariato. Solo la descrizione era cambiata.

Misurare la regolarità dei risultati

Un’altra linea di ricerca si concentra sulla consistenza delle prestazioni. Il benchmark τ‑bench, introdotto da Shunyu Yao e colleghi di Sierra e presentato a ICLR 2025, simula conversazioni di assistenza clienti in cui un agente deve utilizzare strumenti e rispettare regole commerciali.

Gli autori hanno definito la metrica passk: la probabilità che un agente completi correttamente la stessa attività in ciasuna delle k prove. I risultati sono preoccupanti: un agente GPT‑4o raggiungeva circa il 61 % di successo in una singola prova, ma scendeva al 25 % quando doveva ripetere correttamente l’attività otto volte consecutive. Una dimostrazione che funziona una volta non garantisce il comportamento su scala massiva.

Fallimenti nei sistemi multi‑agente

Molte organizzazioni collegano più agenti in catena: uno pianifica, un altro esegue, un terzo verifica. Uno studio del 2025 dell’UC Berkeley, intitolato “Perché i sistemi LLM multi‑agente falliscono?”, ha analizzato oltre 1 600 tracce di esecuzione annotate provenienti da sette framework popolari.

Gli autori, guidati da Mert Cemri, hanno creato la tassonomia MAST, che elenca 14 modalità di fallimento raggruppate in tre categorie:

    • Problemi di progettazione del sistema
    • Disallineamento tra gli agenti
    • Verifica delle attività

La conclusione principale è che molti errori derivano dalla progettazione del sistema più che dalle limitazioni del modello. Gli agenti possono ignorare il ruolo assegnato, perdere il filo della conversazione o dichiarare una task completata senza verificarne il risultato. Tali fallimenti non generano errori visibili; sono rilevabili solo esaminando le azioni reali di ciascun agente.

L’articolo di Unite.AI sul “paradosso multi‑agente” sottolinea che l’aggiunta di agenti può amplificare un errore iniziale anziché correggerlo.

Tracciamento: rendere visibile l’invisibile

La soluzione tecnica si ispira ai sistemi distribuiti, dove le richieste sono seguite attraverso numerosi servizi mediante il tracing. Applicato agli agenti, ogni richiesta dell’utente diventa una traccia e ogni chiamata al modello o a uno strumento è un “segmento” della traccia.

Un segmento registra:

    • l’input fornito
    • l’output generato
    • il numero di token utilizzati
    • il tempo di esecuzione

L’organismo di standardizzazione OpenTelemetry sta definendo convenzioni comuni per i segmenti di IA generativa. Nel 2026 queste convenzioni sono ancora in fase di bozza, quindi i nomi degli attributi potrebbero cambiare.

Progetti open source come Langfuse, Arize Phoenix e AcruxCore implementano già questo approccio. Il loro codice è pubblico, permettendo alle squadre di ispezionare come viene memorizzata una traccia e di eseguire il software sui propri server. Questi strumenti registrano sia le chiamate al modello sia le chiamate agli strumenti all’interno della stessa traccia e consentono di assegnare “score di qualità” a ciascun segmento.

Il punto cruciale è che un segmento relativo a uno strumento deve catturare ciò che lo strumento ha realmente restituito, non solo l’esito della richiesta di rete. Solo così l’esempio del servizio meteo “service unavailable” diventa visibile al team di monitoraggio.

Stato attuale e prospettive future

Le indagini di settore indicano che il tracing è ormai una pratica diffusa, ma i test automatizzati non sempre lo accompagnano. Molte organizzazioni hanno introdotto il tracciamento, ma la verifica della correttezza dei segmenti (ad esempio controllare che il contenuto restituito dallo strumento sia coerente con le aspettative) rimane un’attività manuale.

Per colmare questo divario, gli esperti propongono:

    • Integrare test di end‑to‑end che simulino errori reali degli strumenti e verifichino che l’agente li riconosca.
    • Definire soglie di “confidence” per ogni segmento e generare avvisi quando la fiducia scende sotto una certa percentuale.
    • Utilizzare metriche di passk nei pipeline CI/CD per garantire stabilità su più esecuzioni consecutive.

In sintesi, gli agenti IA non “piantano raramente”; piuttosto, i loro fallimenti sono spesso nascosti dietro risposte apparentemente corrette. La ricerca evidenzia tre cause principali: la dipendenza da una “verità terreno” non verificata, la sensibilità ai prompt e alle descrizioni degli strumenti, e la mancanza di visibilità nei sistemi multi‑agente.

Affrontare questi problemi richiede un approccio sistemico: versionare e testare i prompt come codice, mantenere descrizioni degli strumenti accurate, e adottare il tracing standardizzato per rendere ogni passo osservabile. Solo così le organizzazioni potranno trasformare gli errori silenziosi in segnali gestibili, migliorando affidabilità e fiducia nei sistemi IA avanzati.