Cos'è l'eval alerting?

L'eval alerting è la pratica di trasformare un punteggio di valutazione di un sistema AI in una soglia operativa che decide quando svegliare una persona e con quale severità: una chiamata al reperibile di turno oppure un ticket da guardare domattina. Gli evals misurano la qualità su casi noti, ma un numero su una dashboard non sveglia nessuno da solo: serve una regola che dica quale calo, su quale finestra di tempo, merita un'interruzione. L'approccio deriva dall'affidabilità tradizionale: trattare il punteggio di qualità come un indicatore di livello di servizio, con un obiettivo interno e un budget di errore che si consuma, e far scattare l'allarme sulla velocità di consumo invece che sul singolo valore, misurata su finestre temporali confrontabili e con un campione minimo. Così un crollo improvviso dopo un rilascio fa scattare subito la chiamata, mentre un degrado lento del giudice automatico diventa un ticket.

Leggi anche: Evals (valutazione dei modelli) · Gli evals sono suite di test sistematiche che misurano la qualità di un sistema LLM su casi noti, invece di fidarsi dell'impressione di chi lo prova.

La soglia che sveglia qualcuno

Il meccanismo non va reinventato: è l'alerting su SLO descritto nel capitolo Alerting on SLOs del Google SRE Workbook, con finestre multiple e burn rate differenziati: un allarme rapido sui crolli, uno lento sul degrado che il model monitoring sorveglia in produzione. Applicato agli evals, il punteggio diventa l'indicatore, l'obiettivo interno la soglia, e la velocità di consumo del budget decide la severità. Anche gli strumenti di osservabilità per l'AI si stanno muovendo in questa direzione. Costruire un buon punteggio resta il territorio degli evals; misurare un servizio quello di SLI, SLO e SLA; qui conta cosa il punteggio fa scattare.

Cosa merita le tre di notte

La severità è la decisione vera. Il giudice automatico va in deriva lentamente e i suoi verdetti vanno ricontrollati con una revisione umana: è un degrado lento, da ticket. Un crollo netto dei tassi di errore merita invece la chiamata, e una singola valutazione negativa non la merita mai, perché sotto un campione minimo il segnale è rumore. Regola pratica: chiamare per ciò che brucia in fretta o costa soldi a ogni minuto, accodare ciò che decade piano e vuole un occhio umano prima di agire.

Un esempio enterprise

Una PMI con un assistente LLM in produzione mette due soglie sullo stesso punteggio di qualità. Se il punteggio crolla dopo un rilascio, scatta la chiamata al tecnico di turno, che blocca il rollout e, escluso che a essersi rotto sia il giudice, ripristina la versione precedente: è la risposta agli incidenti applicata a un modello. Se invece scende di poco per giorni, si apre un ticket che il responsabile guarda la mattina: spesso il giudice è andato in deriva o il catalogo è cambiato, e serve un campione rivisto prima di toccare prompt o modello. In entrambi i casi c'è un nome di turno, mai un canale generico dove l'allarme muore. Questo è LLMOps applicato all'ultimo miglio: chi si alza dal letto quando il numero scende.

Perché conta per chi decide

Chi porta un sistema AI in produzione si prende in carico anche le sue notti: senza soglie concordate, o il team viene svegliato per cali che potevano aspettare, oppure il degrado lo segnalano i clienti. La domanda da fare al fornitore è diretta: quale punteggio fa scattare cosa, chi risponde, e quanto passa tra il calo e la chiamata? Senza eval alerting, la qualità la governa il cliente più attento.