L'agente di supporto ha risposto alla richiesta di un utente di resettare l'autenticazione a due fattori con passaggi che semplicemente non esistono. La risposta sembrava sicura, la richiesta HTTP ha restituito 200 OK, la latenza era normale e ogni grafico di monitoraggio è rimasto verde.

Un agente di supporto basato su IA ha allucinato una risposta perché i controlli interni che avrebbero dovuto rilevare l'errore non sono mai stati eseguiti. Le dashboard su cui fanno affidamento gli ingegneri riportavano un'esecuzione perfetta, mentre l'agente ha fabbricato silenziosamente una soluzione.

Perché le dashboard tradizionali non rilevano le allucinazioni dell'IA

La maggior parte degli stack di osservabilità tratta un agente IA come qualsiasi altro microservizio: una singola richiesta in entrata e una singola risposta in uscita. Registrano lo stato HTTP, il tempo di risposta e il conteggio degli errori. Non registrano i passaggi nascosti all'interno della richiesta: il recupero di documenti esterni, le chiamate ai modelli linguistici di grandi dimensioni, l'uso di strumenti ausiliari e qualsiasi logica di guard-rail che validi l'output.

Quando un passaggio di recupero restituisce un risultato vuoto, il modello spesso "riempie il vuoto" con un testo che sembra plausibile. Dal punto di vista del sistema di monitoraggio, la chiamata è andata a buon fine, perché nulla è andato in crash e il codice di stato è rimasto 200. L'allucinazione rimane invisibile e l'unico sintomo è una risposta errata che raggiunge l'utente.

Trasformare una black box in un albero leggibile

Il primo passo per un debugging affidabile è smettere di trattare l'agente come una chiamata monolitica e iniziare a visualizzare ogni operazione interna come una riga separata in una tabella di tracciamento (trace table). Un'esecuzione tipica si suddivide in:

  • L'invocazione dell'agente di alto livello
  • Il passaggio di recupero che estrae la documentazione pertinente
  • Ogni inferenza del modello linguistico che elabora i dati recuperati
  • Ogni chiamata a uno strumento (ad es., ricerca nel database, richiesta API)
  • Controlli di guard-rail che garantiscono la fattualità o la conformità alle policy

Ogni riga registra il timestamp, il flag di successo e il payload che ha attraversato quel passaggio. Con questa struttura, l'esecuzione diventa un albero che può essere ispezionato riga per riga invece di dover indovinare partendo dall'output finale.

Il bug che è passato inosservato

Nell'interazione di supporto errata, il trace appariva così:

  1. Il recupero è stato eseguito ma non ha restituito documenti.
  2. Il passaggio successivo è proceduto comunque, passando un contesto vuoto al modello.
  3. Il modello ha generato una risposta che ha riempito le informazioni mancanti con passaggi inventati.
  4. Il sistema ha restituito 200 perché la pipeline non ha riscontrato eccezioni.

L'allucinazione non era un difetto del modello linguistico in sé; era la mancanza di un guard-rail tra le fasi di recupero e di generazione. L'agente ha risposto anche quando non aveva nulla su cui basare la propria risposta.

Semplici guard-rail per fermare le allucinazioni

Due cambiamenti concreti hanno eliminato il problema:

  • Abort sul recupero vuoto – se il repository dei documenti non restituisce nulla, l'agente deve rispondere "Non sono riuscito a trovare le informazioni di cui hai bisogno" invece di procedere alla generazione.
  • Controllo di grounding – dopo che il modello produce una risposta, verificare che ogni affermazione fattuale compaia nel contenuto recuperato. Se il controllo fallisce, rifiutare la risposta e passare a una risposta di tipo "impossibile rispondere".

Un workflow pratico per un debugging più rapido

  1. Tracciare ogni chiamata interna – strumentare l'agente in modo che ogni recupero, inferenza del modello e uso di strumenti scriva una riga in un log persistente.
  2. Preservare le esecuzioni fallite – memorizzare l'intero trace di qualsiasi interazione che l'utente segnali come errata. Eliminarle per risparmiare spazio nasconde i dati necessari per trovare le regressioni.
  3. Taggare le esecuzioni con informazioni sulla versione – includere l'identificativo del rilascio e lo stato di qualsiasi feature flag in ogni riga del trace. Ciò consente di correlare un nuovo bug con una recente modifica al codice.
  4. Valutare la qualità, non solo la velocità – aggiungere metriche che misurino quanto bene la risposta segua l'istruzione e rimanga ancorata al contenuto recuperato. Un alto throughput conta poco se le risposte sono errate.
  5. Revisionare i fallimenti quotidianamente – una breve e regolare revisione dei fallimenti memorizzati spesso rivela pattern (ad es., un particolare tipo di query restituisce costantemente recuperi vuoti) prima che colpiscano molti utenti.

Convertendo il "verde" in "verificato", i team possono intercettare precocemente le allucinazioni e mantenere l'esperienza utente affidabile.

Il costo dell'ignorare i fallimenti interni

Quando le dashboard riportano il successo solo a livello HTTP, le organizzazioni distribuiscono agenti che sembrano affidabili ma forniscono regolarmente indicazioni errate.

Cosa monitorare successivamente

Finché questi non diventeranno la norma, l'approccio più sicuro è trattare ogni operazione interna come osservabile e fallire rapidamente quando mancano le evidenze.

Punto chiave: Una dashboard verde ti dice che l'infrastruttura funziona; non garantisce che la risposta sia corretta. Tracciando ogni recupero, chiamata al modello e controllo dei guardrail, trasformi le allucinazioni nascoste in fallimenti visibili che possono essere corretti prima che raggiungano l'utente.