Il deploy silenzioso
Un team fa un deploy di venerdì sera. Cambia leggermente il prompt di sistema di un chatbot in produzione. I test passano, i dashboard restano verdi per tutto il weekend. Il lunedì mattina, il team customer success segnala che "le risposte sembrano meno utili". Il team AI controlla i log: nessun errore, nessun crash, nessuna anomalia tecnica.
La qualità delle risposte è peggiorata del 15%, ma nessun sistema se n'è accorto.
Questo scenario è il motivo per cui l'osservabilità di un sistema AI è un problema diverso dall'osservabilità di un sistema software tradizionale. Nel software classico, "funzionare" è binario: l'API risponde o non risponde. Nell'AI, "funzionare" è un continuum, e si può degradare lentamente mentre tutti i log dicono che va tutto bene.
I quattro livelli di osservabilità che servono
Un sistema AI in produzione ha bisogno di quattro livelli di visibilità, ognuno con metriche e strumenti diversi:
Livello 1 — Infrastruttura: latenza, errori HTTP, rate limit, timeout. È l'osservabilità classica, necessaria ma non sufficiente.
Livello 2 — Traccia della chiamata: prompt completo, contesto, parametri, risposta, token consumati. Serve per debug puntuale.
Livello 3 — Qualità aggregata: accuracy, faithfulness, refusal rate, user satisfaction nel tempo. Serve per capire se il sistema sta degradando.
Livello 4 — Drift comportamentale: cosa è cambiato rispetto alla baseline, perché oggi il sistema si comporta diversamente da ieri. È il livello più difficile e il più prezioso.
Molti team implementano bene i livelli 1 e 2, con risultati altalenanti sul 3, e quasi mai raggiungono il 4.
Cosa registrare a livello di singola chiamata
Per ogni chiamata al modello, dovresti poter ricostruire tutto. In pratica questo significa salvare, con un trace ID condiviso:
- Input completo: il prompt finale inviato al modello, con tutti gli strati di contesto espansi
- Parametri di chiamata: model ID, temperature, max_tokens, tool disponibili
- Output completo: la risposta grezza prima di qualunque post-processing
- Metadati di esecuzione: tempi di ogni step, token input/output, eventuali tool call
- Decisioni a monte: quale routing ha portato a questa chiamata, quali retrieval sono stati fatti
La tentazione è risparmiare spazio loggando solo un digest. Non farlo. Quando un utente segnala "il chatbot mi ha detto una cosa sbagliata ieri alle 15", il trace completo è l'unica cosa che ti permette di capire cosa è successo. Un hash MD5 del prompt non serve a niente.
Il problema della cardinalità
I sistemi AI hanno un problema di osservabilità che non si presenta nel software classico: ogni chiamata è potenzialmente unica. Non puoi raggruppare metriche per "endpoint" come in un'API REST, perché ogni prompt è diverso.
Per aggirare il problema, servono dimensioni di aggregazione che abbiano senso nel tuo dominio:
- Intent / categoria di richiesta: classificare automaticamente ogni chiamata in una di N categorie operative
- Profilo utente: nuovo vs ricorrente, plan tier, lingua
- Sorgente: da che componente del sistema arriva la chiamata
- Versione del prompt: un hash della parte stabile del system prompt per distinguere le versioni
Senza queste dimensioni, puoi vedere che "l'accuracy media è peggiorata", ma non puoi capire se è peggiorata su tutto o solo su una specifica categoria di query — che è la domanda che ti fa trovare il bug.
Il pattern del golden set
Una tecnica che funziona bene per catturare degradazioni silenti è il golden set: un insieme di 50-200 query rappresentative con risposte attese, fatto girare automaticamente a ogni deploy.
I risultati non servono a produrre un numero per il dashboard. Servono a rispondere a una domanda binaria: il comportamento del sistema su queste query è rimasto stabile?
Se dopo un deploy il golden set mostra che il 10% delle query storicamente corrette ora sta dando risposte diverse, anche senza un'accuracy obiettiva sai che qualcosa è cambiato. A quel punto puoi decidere se il cambio è un miglioramento, una regressione, o semplicemente una variazione stilistica irrilevante.
Le metriche di qualità che contano davvero
Non tutte le metriche di qualità pubblicate nei paper hanno senso in produzione. Tre che si sono dimostrate più utili operativamente:
Refusal rate per categoria. Quante volte il sistema dice "non posso aiutarti" per ciascun intent. Se sale improvvisamente su un intent che prima gestiva bene, c'è un problema.
Tool error rate. Per sistemi agentici, quante volte i tool chiamati dall'agente falliscono. Spesso è il leading indicator di bug downstream (un'API cambiata, un database migrato, un cambio di permessi).
Conversazioni multi-turn che concludono senza risoluzione. Se gli utenti continuano a chattare senza che la richiesta venga soddisfatta, qualcosa non va — anche se ogni singola risposta sembra corretta.
La metrica che quasi nessuno traccia ma che è la più predittiva: la variazione rispetto al periodo precedente. Non importa se l'accuracy è 85%. Importa se la settimana scorsa era 87%.
L'alerting che non grida al lupo
Gli alert per sistemi AI sono difficili perché la qualità fluttua naturalmente. Un alert che scatta a ogni variazione del 2% diventa rumore. Un alert che scatta solo sui crash perde tutto quello che conta.
Un pattern che funziona: alerting a tre soglie:
- Info (notifica passiva): variazioni oltre la deviazione standard storica
- Warning (notifica al team): variazioni persistenti per più di N ore o finestre temporali
- Critical (paging): degradazioni che coinvolgono multiple dimensioni insieme (es. accuracy giù + refusal rate su + tool errors su)
La regola generale è che un singolo segnale debole non merita un alert. Un pattern di segnali coerenti sì.
Il sampling che non mente
Loggare ogni singola chiamata al modello con trace completo è costoso e spesso non sostenibile al volume di produzione. Il sampling è necessario, ma va fatto bene.
Un pattern robusto prevede tre strati di sampling:
- Sampling statistico (es. 1% di tutte le chiamate) per metriche aggregate affidabili
- Sampling forzato (100%) per categorie critiche o errori noti
- Sampling utente-driven: quando un utente segnala un problema, il suo ID attiva il logging completo per le prossime 24h
Questo garantisce che quando serve un trace dettagliato, ce l'hai. E non stai loggando tutto per tutti.
La review che chiude il cerchio
L'osservabilità non è solo strumento, è processo. Senza una cadenza regolare di review dei dati, gli strumenti più sofisticati producono solo log.
Un ritmo minimo che funziona:
- Daily: il team operativo controlla alert aperti e anomalie del giorno
- Weekly: review delle metriche aggregate e delle categorie di errore più frequenti
- Monthly: review del drift del golden set e dei pattern di degradazione lenta
- Quarterly: review strutturale — le dimensioni che tracciamo sono ancora quelle giuste? Il golden set riflette ancora il product?
Senza questa disciplina, l'osservabilità diventa un ornamento. I dashboard esistono, nessuno li guarda fino a quando qualcosa si rompe — e a quel punto spesso è tardi per capire quando esattamente è iniziato a rompersi.
La domanda che chiude tutto
Il test più pratico per valutare il livello di osservabilità del tuo sistema AI è rispondere a questa domanda:
"Un utente mi segnala che ieri alle 14:30 il chatbot gli ha dato una risposta sbagliata. In quanto tempo riesco a dirgli esattamente cosa è successo?"
Se la risposta è "subito", hai un buon sistema. Se è "qualche ora", è accettabile. Se è "non lo so, forse possiamo ricostruire" — l'osservabilità non c'è, e stai gestendo il sistema in modo reattivo invece che controllato.
La qualità di un sistema AI in produzione non si misura quando tutto funziona. Si misura quando qualcosa non funziona e devi capire perché.