Inizia qui¶

Il problema, in una storia¶

Ho un piccolo script che ogni mattina legge qualche centinaio di articoli sull'IA e chiede a un modello linguistico di scegliere i cinque che vale la pena leggere. Funzionava. Poi un giorno ha iniziato a tralasciare quelli buoni.

Niente era andato in crash. Nessun test era fallito. Il codice era lo stesso della settimana precedente. Era cambiato il comportamento del modello — una modifica al prompt qui, un aggiornamento del modello là — e il comportamento non è qualcosa che un test unitario verifica. Lo script restituiva sempre cinque articoli. Solo che erano i cinque sbagliati.

Questa è una regressione degli LLM: il tuo sistema continua a funzionare, a rispondere, a passare i test, ed è silenziosamente peggiore di prima.

Perché i tuoi test non la vedono¶

I test ordinari confrontano un output con un valore atteso. Un modello linguistico non ti dà un valore atteso. Fagli la stessa domanda due volte e potresti ottenere due risposte diverse, entrambe accettabili. Così i team o smettono di testare il comportamento del modello, oppure scrivono un test che passa oggi e non sa dirti niente su domani.

Le domande concrete, alla fine, sono queste:

• Confrontato con cosa? Serve un riferimento: il comportamento che hai accettato per ultimo.
• Peggiore di quanto? Un punteggio che passa da 0.88 a 0.86 può essere rumore. Da 0.88 a 0.73 è una regressione. Senza sapere quanto il sistema oscilli da solo, non puoi distinguere i due casi.
• Chi decide cosa significa «giusto», e dove è messa per iscritto questa decisione?

Cosa fa digline¶

digline è un gate che metti davanti a quella domanda. Scrivi una volta per tutte cosa ti aspetti dal tuo sistema, sotto forma di un insieme di check: quelli deterministici (la risposta è JSON valido, non contiene numeri di telefono, cita il nome del cliente) e quelli giudicati (un secondo modello valuta la risposta rispetto a una griglia di valutazione). Li esegui sul tuo sistema. Quando il risultato ti soddisfa, lo promuovi: diventa la baseline, un file committato nel tuo repository accanto al codice.

Da quel momento ogni run viene confrontato con quella baseline, e il report risponde all'unica domanda che conta. Ecco un run in cui niente è peggiorato, anche se due check si sono spostati e un caso non ha potuto essere risolto:

Nothing got worse compared with the reference. 2 checks moved within noise. 3 checks are on the line: the bands they measured cover their thresholds. Every case could be judged. 1 case is suspended. The suite is unchanged from the reference. 1 file under test changed since the reference.

ed ecco un run in cui sei check sono peggiorati:

6 checks got worse compared with the reference. Every case could be judged. No case is suspended. The suite is unchanged from the reference. 1 file under test changed since the reference.

Entrambi sono ciò che digline compare ha stampato sulla suite di esempio del primo capitolo della Guida, catturati dalla release da cui provengono questi documenti. Il modello e il giudice di quella suite sono preregistrati e non viene chiamato alcun provider, quindi le risposte e i loro costi sono fissati dall'esempio e si riproducono in modo identico; i numeri sono quelli che digline ha calcolato a partire da essi.

La baseline è un file in git. Ha una cronologia, si può confrontare con diff, e nessuno la promuove tranne te. Non c'è una dashboard a cui accedere né un servizio che riceve i tuoi dati: digline gira dove gira il tuo codice.

Trenta secondi, in immagini¶

Episodio 1 di una breve serie sulla regressione degli LLM. Ospitato su questo sito — nessun player di terze parti, nessun cookie.

Dove andare adesso¶

• Perché — il ragionamento dietro le scelte di progetto, se vuoi contestarlo.
• Guida — installalo e arriva al tuo primo compare in pochi minuti.
• La GitHub Action — lo stesso gate su ogni pull request, e cosa significa ciascun exit code.
• Come si colloca digline — se usi già uno strumento di eval e vuoi sapere cosa cambia.

Dieci parole che incontrerai lungo la strada: run, baseline, confronto, promozione, check, giudice, tolleranza, noise floor, regressione, gate. Ciascuna è spiegata la prima volta che compare nella Guida.