I segnali che il tuo LLM in produzione ha smesso di funzionare come prima

Il drift di un LLM in produzione raramente produce un errore: risposte leggermente peggiori, formati leggermente diversi, comportamenti fuori spec, abbastanza da degradare l’esperienza, non abbastanza per far scattare un alert. Riconoscere i segnali prima che diventino visibili è la parte che manca nella maggior parte dei sistemi AI che vediamo in produzione. È il tipo di problema sistematico che documentiamo perché ricorre spesso nel lavoro che facciamo in Snowinch.

Perché il drift è invisibile per default

Un’applicazione web tradizionale fallisce in modo binario: risponde o non risponde, il dato c’è o non c’è, il test passa o non passa. Un LLM in produzione può degradare su un asse completamente diverso, la qualità dell’output, senza che nessun sistema di monitoring standard se ne accorga.

Le cause sono multiple e spesso concorrenti. Il provider aggiorna il modello sottostante in modo silenzioso. Il prompt che funzionava con la versione precedente produce output leggermente diversi con quella nuova. I dati in ingresso degli utenti reali divergono dai casi che avevi in mente quando hai scritto il prompt. La temperatura che hai scelto in staging si comporta diversamente sotto il carico reale. Qualcuno ha modificato il system prompt per «migliorarlo» senza un processo di verifica.

Il risultato è che il sistema funziona, nessuna eccezione, nessun timeout, nessun 500, ma produce output che non soddisfano più i requisiti originali. E lo scopri quando un utente si lamenta, o peggio quando nessuno si lamenta ma le conversioni calano.

I segnali da monitorare

Distribuzione dei formati di output

Se il tuo LLM è istruito a restituire JSON con una struttura definita, o a rispondere in un certo formato, la prima metrica da tracciare è quante risposte rispettano quel formato. Non «il JSON è valido», quello lo coglie il parser, ma «i campi attesi sono presenti, i tipi sono corretti, i valori sono nel range previsto».

Un aumento anche piccolo del tasso di risposte che richiedono fallback o repair è un segnale precoce. Se passi dall’1% al 4% di risposte malformate nell’arco di una settimana senza aver cambiato nulla nel tuo deploy, qualcosa è cambiato dall’altra parte, le cifre sono esemplificative, non soglie universali.

// Esempio minimo: traccia ogni validazione schema in produzione
const result = OutputSchema.safeParse(llmResponse);

await metrics.increment('llm.output.validation', {
  status: result.success ? 'valid' : 'invalid',
  // Non loggare il contenuto, solo il sito del fallimento
  failure_path: result.success ? null : result.error.issues[0]?.path.join('.'),
});

Lunghezza media delle risposte

La lunghezza dell’output è un proxy grezzo ma sorprendentemente affidabile. Se il tuo LLM produce riassunti e la lunghezza media scende del 30% in una settimana, qualcosa è cambiato, nel modello, nel prompt, o nella distribuzione degli input. Non è una metrica che ti dice cosa è cambiato, ma ti dice che vale la pena guardare.

Stesso discorso in senso opposto: risposte che diventano improvvisamente più lunghe possono indicare che il modello sta aggiungendo verbosità non richiesta, o che il formato di output si è allentato.

Tasso di risposte che attivano la logica di fallback

Quasi ogni sistema LLM in produzione ha una logica di fallback, un retry, un messaggio di errore generico, un valore di default. Quante volte al giorno viene attivata? Se quel numero cresce, c’è un problema a monte che vale la pena investigare prima che diventi visibile agli utenti.

Latenza per token

Un aumento della latenza non sempre indica un problema di qualità, ma spesso precede un cambio di comportamento del modello. I provider comunicano raramente in anticipo gli aggiornamenti ai modelli in produzione, monitorare la latenza è uno dei modi indiretti per accorgersi che qualcosa è cambiato nell’infrastruttura sottostante.

Segnali di business collegati

Il monitoring tecnico non basta da solo. Le metriche di business collegate all’output LLM, tasso di completamento di un flusso, tempo medio di interazione, tasso di rifiuto esplicito da parte dell’utente, sono spesso i primi indicatori di drift percepito. Sono più rumorose e più lente, ma colgono la degradazione che gli strumenti tecnici non vedono: output formalmente corretti ma semanticamente inutili.

La distinzione che conta: drift del modello vs drift dei dati

Non tutto il drift viene dal modello. A volte sono gli input degli utenti reali a spostarsi rispetto ai casi per cui il sistema era stato progettato. Un classificatore addestrato su un certo tipo di testo inizia a ricevere testo con caratteristiche diverse, slang, lingue miste, abbreviazioni, e degrada non perché il modello sia cambiato ma perché il dominio si è allargato.

Distinguere le due cause cambia la risposta. Drift del modello → rivedi il prompt, valuta se cambiare provider o versione, aggiorna il golden set. Drift dei dati → il sistema ha bisogno di casi di training o di prompt aggiornati che coprano i nuovi pattern. Trattarli allo stesso modo porta a soluzioni sbagliate.

Un modo pratico per separare i due segnali: campiona periodicamente input reali e verificali manualmente contro le aspettative. Se gli input sono ancora nel dominio previsto e gli output sono peggiorati, è drift del modello. Se gli input sono cambiati, è drift dei dati.

Cosa non funziona come sistema di monitoring

Usare un LLM come giudice degli output di un altro LLM è l’approccio che sembra ovvio e che introduce più problemi di quanti ne risolva. Il giudice ha i suoi bias, il suo drift, il suo costo. Non è deterministico, due valutazioni dello stesso output possono dare risultati diversi. Non è tracciabile su Git. Non ti dice se il problema è nel sistema sotto test o nel giudice stesso.

Il monitoring basato su metriche deterministiche, validazione schema, distribuzione lunghezze, tasso di fallback, latenza, è meno sofisticato ma più affidabile e molto più economico. Per i casi in cui serve una valutazione qualitativa, la revisione umana su campione è più onesta di un LLM-as-judge.

Su come costruire un sistema strutturato di test con golden set e matcher deterministici, l’articolo sul protocollo di regressione LLM copre l’implementazione in dettaglio.

Quando iniziare a monitorare

La risposta è: prima di andare in produzione, non dopo. Il costo di aggiungere queste metriche su un sistema già live è sempre più alto di quello di aggiungerle prima, i dati storici non li recuperi, e il baseline da cui misurare il drift non esiste se non hai iniziato a raccoglierlo fin dall’inizio.

In pratica, il minimo accettabile per un sistema LLM in produzione è: tasso di validazione schema loggato, latenza per chiamata tracciata, logica di fallback con counter esplicito. Tutto il resto può venire dopo, ma questi tre non sono opzionali se vuoi sapere cosa sta succedendo.

Sintesi operativa

• Il drift di un LLM in produzione non produce errori, produce degradazione silenziosa. Non lo coglie nessun sistema di monitoring standard.
• Le metriche da tracciare: tasso di validazione schema, distribuzione lunghezze output, attivazione fallback, latenza per token, segnali di business collegati.
• Distingui drift del modello da drift dei dati, le cause sono diverse e le soluzioni anche.
• Evita LLM-as-judge per il monitoring: non è deterministico, non è tracciabile, ha il suo drift.
• Il baseline va costruito prima di andare in produzione. I dati storici non si recuperano.