> Monitoraggio e logging di una pipeline AI
in produzione: cosa loggare e perché

Il problema nasce sempre così: il modello funzionava bene durante i test, ma in produzione le risposte si degradano dopo una settimana, oppure i tempi di risposta salgono oltre soglia senza motivo apparente. Senza logging strutturato, stai indovinando. Con un logging intelligente, vedi esattamente cosa è successo.

# Cosa loggare: le quattro categorie fondamentali

Non devi loggare tutto: generarebbe rumore inutile. Devi loggare quello che ti permette di:

• Riprodurre e debuggare errori specifici
• Rilevare derive del modello o peggioramenti di qualità
• Capire costi reali per input/output
• Misurare latenza e disponibilità

1. Input, output e metadati di tracciamento

Loggare sempre: l'input alla pipeline, l'output del modello, l'ID univoco della richiesta (trace ID), timestamp, versione del modello, quale provider è stato usato (se ne usi più di uno in fallback).

Esempio di log strutturato (JSON):

{ "trace_id": "req_abc123xyz", "timestamp": "2025-01-15T14:32:17Z", "model_version": "gpt-4-turbo-2024-12", "provider": "openai", "input_tokens": 342, "output_tokens": 187, "input_hash": "sha256_...", "output": "...", "latency_ms": 1840, "status": "success" }

L'hash dell'input è utile per raggruppare richieste simili senza conservare l'input intero (importante per privacy). Se una richiesta fallisce, logga comunque input e l'errore esatto.

2. Errori e fallback

Distingui tra:

• Errori del provider (rate limit, timeout, non disponibile): loga il codice HTTP, il messaggio di errore, e se è stato attivato un fallback
• Errori di parsing/validazione: loga l'output grezzo del modello e il parsing error
• Errori di business logic: output generato correttamente ma non soddisfa vincoli (es. risposta fuori-contesto nella tua pipeline RAG)

3. Metriche di qualità e derive

Non puoi aspettare che gli utenti ti segnalino degradazione. Devi misurare:

• Latenza percentile (p50, p95, p99): non la media—la media cela picchi
• Token usage reale: il numero di token input/output che effettivamente consumi, non la stima. I costi variano
• Sentiment/qualità umana (se gestito): un campione di output valutato da te o da un team, periodicamente
• Hallucination rate in RAG: quante risposte contengono informazioni inventate (valuta manualmente un campione)
• Deriv temporale: se la qualità media degrada nel tempo, è segno di drift nel modello, nei dati di input, o nei prompt

4. Costi e risorse

Log granulare di:

• Token consumati per richiesta (moltiplicato per prezzo unitario del provider)
• Tempo di elaborazione (CPU, memoria se self-hosted)
• Numero di retry/fallback (costano)
• Aggregazione giornaliera: costo totale della pipeline al giorno, costo medio per richiesta

Se la pipeline costa più di quanto previsto, il log ti dice dove: i modelli più cari vengono usati per richieste semplici? Un fallback è stato attivato troppo spesso?

# Dove salvare i log

Le opzioni dipendono da volume e complessità:

Soluzione	Volume tipico	Costo	Adatto per
File + rotazione locale	Fino a 100 req/s	Quasi zero	Prototipo, self-hosted
CloudWatch (AWS), Stackdriver (GCP)	Qualsiasi	~0,50 USD per GB	Chi usa AWS/GCP, semplice integrazione
Datadog, New Relic	Qualsiasi	150-500 USD/mese	Team maturo, need analitiche avanzate
Loki (stack Prometheus)	Fino a 10k req/s (self-hosted)	Costo infrastruttura	Chi ha gia Prometheus, full control
PostgreSQL/TimescaleDB	Qualsiasi (con scaling)	Hosting DB	Query SQL complesse, dati strutturati

Per una pipeline AI modesta (centinaia di richieste al giorno), file con rotazione o PostgreSQL bastano. Per migliaia di richieste al giorno, passa a una soluzione cloud-native o a un aggregatore.

# Struttura del log: JSON strutturato vs. testo

Mai loggare una stringa tesuale libera. Usa JSON strutturato:

• Parsabile automaticamente
• Aggregabile per campo
• Compatibile con qualsiasi tool di analytics
• Non ambiguo

Se usi Python con logging standard, passa a python-json-logger o simili. Se usi JavaScript, winston o pino con formatter JSON. Loggare un JSON per riga, timestamp UNIX o ISO 8601, sempre lo stesso schema.

# Alerting: cosa deve svegliarti di notte

Non alert su ogni anomalia minore. Configura solo quelle critiche:

1. Error rate > 5% nell'ultima ora
2. Latenza p95 > soglia definita (es. 5 secondi se il tuo SLA è 3)
3. Provider non disponibile (es. tutti i retry OpenAI falliti ultimi 15 min)
4. Costo giornaliero > budget previsto (protezione da bug che consuma token a caso)
5. Hallucination rate > X% (valutato offline, ma aggregato nel log)

Ogni alert deve avere una runbook associata: che cosa controlli prima, dove guardi il log, quali azioni correttive provi. Altrimenti l'alert è rumore.

# Retention e conformità

Quanto tempo conservare i log? Dipende dal regolamento e dal carico:

• GDPR: se l'input contiene dati personali, la retention è vincolata. Hash l'input, non salvare il testo intero
• Audit: se la pipeline prende decisioni critiche, conserva log per 1-3 anni
• Operativo: i dati ultimi 30-90 giorni servono per trend. Oltre, archivia/aggregati

Una strategia comune: log caldi (ultimi 7 giorni) in storage veloce, log warm (7-90 giorni) in storage economico, log freddi (oltre) in archivio o eliminati.

# Quando il logging aggiunge latenza

Se logghi in modo sincrono (la richiesta aspetta il log prima di tornare), rischi di rallentare la pipeline. Soluzioni:

• Log asincrono: scrivi in una coda in-memory, un thread separato scrive su storage. Rischio: se il processo crasha, perdi i log in buffer
• Batch su intervallo: accumula log e scrivi ogni N secondi o ogni M messaggi
• Fire-and-forget per log non-critici: loggare latenza e qualità è critico; loggare il debug dettagliato di una richiesta riuscita no

Misura: il tempo di logging dovrebbe essere meno del 5% della latenza totale della pipeline. Se supera, hai un problema d'infrastruttura.

# Quando NON serve questo livello di logging

Se la tua pipeline è un prototipo monouso, o chiamata una volta al mese, non over-engineerizzare il logging. File di testo e un'occhiata manuale bastano. Ma dal momento in cui il sistema ha utenti reali, dipende da stabilità e costi prevedibili, il logging strutturato è obbligatorio—non optional.