Gli agenti di intelligenza artificiale (IA) basati su modelli di linguaggio di grandi dimensioni (LLM) stanno assumendo ruoli sempre più complessi: rispondono a richieste di supporto, consultano basi di dati e pianificano viaggi. Tuttavia, quando qualcosa va storto, spesso restituiscono una risposta “sicura” e un codice di successo, rendendo difficile individuare il problema.
Perché i fallimenti sono invisibili
Nel software tradizionale, gli errori sono evidenti: una funzione lancia un'eccezione, un server restituisce un codice di errore e un pannello di monitoraggio si colora di rosso. Un agente IA, invece, opera in un ciclo continuo: il modello legge un'istruzione, decide di chiamare uno strumento (ad esempio un'API di ricerca o un database), legge il risultato e decide il passo successivo. Ogni fase può fallire, ma le richieste di rete completano correttamente.
Consideriamo un caso tipico: un servizio meteorologico restituisce il messaggio “servizio non disponibile” all'interno di una risposta altrimenti normale. Il modello interpreta quel testo, si scusa oppure, peggio, genera un pronostico plausibile basandosi sui dati di addestramento. L'utente riceve una risposta fluida, i log mostrano una chiamata di rete corretta e nessun segnale di errore appare nei sistemi di monitoraggio convenzionali.
Documentazione dei fornitori
La guida API di Google per Gemini specifica che il modello “non esegue la funzione da solo”; propone solo il nome della funzione e i suoi argomenti, lasciando l'effettiva chiamata al codice dell'applicazione. Di conseguenza, solo l'applicazione vede il risultato reale.
Anthropic, nella sua guida ingegneristica per creare agenti, sottolinea che gli agenti hanno bisogno della “verità sul terreno” ad ogni passo, ovvero i risultati concreti degli strumenti, per valutare il proprio progresso. Quando uno strumento segnala un fallimento come semplice testo, l'agente non può riconoscerlo.
Debito tecnico nascosto
Il problema non è nuovo. Già nel 2015, ingegneri di Google guidati da D. Sculley descrissero la “debito tecnico nascosto” nei sistemi di apprendimento automatico, evidenziando che la maggior parte del rischio in produzione risiede al di fuori del codice del modello: dipendenze di dati, configurazioni e codice di integrazione. Gli agenti introducono una nuova dimensione: le istruzioni e le descrizioni degli strumenti sono configurazioni che possono alterare il comportamento senza modificare il codice.
Impatto di piccoli cambiamenti
Un esperimento presentato a ICLR 2024 da Melanie Sclar (University of Washington) dimostra quanto sia sensibile il sistema a minime variazioni di formato delle istruzioni (spazi, separatori, maiuscole). Nonostante il significato rimanga invariato, la precisione su una stessa attività varia fino a 76 punti percentuali su LLaMA‑2‑13B. Questa sensibilità persiste con modelli più grandi, più esempi o addestramento per istruzioni.
Gli autori consigliano di riportare un intervallo di prestazioni per diversi formati plausibili di istruzioni, anziché una singola cifra. Per gli ingegneri, la lezione pratica è chiara: modificare un'istruzione equivale a modificare il codice, richiedendo versioning e test prima del rilascio.
Lo stesso vale per le descrizioni degli strumenti. Anthropic raccomanda di dedicare “la stessa attenzione ingegneristica alle definizioni degli strumenti” della istruzione principale. Un agente di programmazione che commetteva errori con percorsi relativi di file ha funzionato correttamente dopo che la descrizione dello strumento è stata cambiata per richiedere percorsi assoluti; il modello non è cambiato, solo la sua “documentazione” è stata aggiornata.
Consistenza e metriche di valutazione
Un altro filone di ricerca analizza la consistenza tramite la benchmark τ‑bench, introdotta da Shunyu Yao e colleghi (ICLR 2025). Simula conversazioni di assistenza clienti dove l'agente deve usare strumenti e rispettare regole aziendali. La metrica pass^k misura la probabilità che un agente completi correttamente la stessa attività in k tentativi.
I risultati sono poco rassicuranti: GPT‑4o ha risolto circa il 61 % delle attività in un singolo tentativo, ma la percentuale scende al 25 % quando deve riuscirci otto volte di seguito. Una dimostrazione di successo una volta non garantisce affidabilità a lungo termine.
Fallimenti nei sistemi multi‑agente
Molti team concatenano più agenti: uno pianifica, un altro esegue e un terzo revisiona. Uno studio del 2025 di UC Berkeley, “Why do multi‑agent large language model systems fail?”, ha analizzato più di 1 600 tracce di esecuzione in sette framework multi‑agente. Gli autori hanno creato la tassonomia MAST, con 14 modalità di errore raggruppate in tre categorie: problemi di progettazione del sistema, mismatch tra agenti e verifica dei compiti.
La conclusione principale è che molti errori derivano dal design del sistema, non solo dalle limitazioni del modello. Gli agenti possono ignorare il ruolo assegnato, perdere il filo della conversazione o dichiarare completato un compito senza verificare il risultato. Questi errori non generano log di errore; sono visibili solo leggendo i dettagli di ogni azione.
Un'analisi di Unite.AI sulla “paradosso multi‑agente” suggerisce che aggiungere agenti può amplificare un errore iniziale anziché cancellarlo.
Rendere visibile l’invisibile: tracciamento e testing
L’ingegneria propone di adottare tecniche di tracing, comuni nei sistemi distribuiti, per seguire ogni richiesta dell’utente attraverso i vari “segmenti” (model call, tool call, ecc.). Ogni segmento registra ingresso, uscita, token consumati e durata. OpenTelemetry, l’organismo di standardizzazione, sta definendo convenzioni per i segmenti di IA generativa; al 2026 le specifiche sono ancora in fase di sviluppo.
Progetti open source come Langfuse, Arize Phoenix e AcruxCore già implementano questi concetti. Il loro codice pubblico permette ai team di esaminare come vengono salvati i trace e di eseguire il software sui propri server. Registrano le chiamate a modelli e strumenti come segmenti di un unico trace e consentono di assegnare punteggi di qualità. È cruciale che il segmento di uno strumento registri il valore reale restituito, non solo l'esito della chiamata HTTP; altrimenti il fallimento del servizio meteorologico rimane invisibile.
Stato attuale del settore
Le indagini mostrano che il tracing è ormai comune, ma le pratiche di testing sono ancora arretrate. L’“Agent Engineering State of the Union” di LangChain, basato su un sondaggio a 1 340 professionisti alla fine del 2025, evidenzia che:
- Il 78 % delle organizzazioni utilizza qualche forma di tracing per agenti IA.
- Solo il 42 % esegue test automatizzati di fine‑to‑fine su scenari con più strumenti.
- Il 35 % ha riscontrato errori critici non rilevati da monitoraggi tradizionali negli ultimi sei mesi.
Questi dati indicano una crescente consapevolezza ma anche una necessità urgente di standardizzare test, monitoraggio e gestione delle versioni delle istruzioni e delle descrizioni degli strumenti.
Conclusioni e linee guida pratiche
Per mitigare i fallimenti silenziosi degli agenti IA, le organizzazioni dovrebbero adottare le seguenti pratiche:
- Versionare istruzioni e descrizioni degli strumenti come se fossero codice, includendo revisioni e test di regressione.
- Implementare tracing end‑to‑end con segmenti che registrino output reali di tutti gli strumenti.
- Definire metriche di consistenza (ad esempio pass^k) e monitorarle su più iterazioni.
- Eseguire test automatizzati su scenari multi‑agente, includendo verifiche di risultato e di conformità alle regole aziendali.
- Educare i team sulla “debito tecnico nascosto” dei LLM, enfatizzando che modifiche a istruzioni o descrizioni hanno lo stesso peso di modifiche al codice.
Solo combinando una rigorosa gestione della configurazione, un tracing dettagliato e test sistematici sarà possibile trasformare gli errori invisibili in segnali osservabili, migliorando la affidabilità dei sistemi IA sempre più presenti nella nostra vita digitale.