Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines

Riepilogo Tecnico: Chi è Andato in Drift? L'Attribuzione Anytime-Valid nelle Pipeline di Valutazione LLM

1. Il Problema

La valutazione continua dei prodotti basati su Large Language Model (LLM) si affida sempre più a pipeline di "LLM-as-judge", in cui un modello forte assegna punteggi alle interazioni per attivare avvisi quando le prestazioni degradano. L'assunto fondamentale in questi sistemi è che il giudice agisca come un metro di misura fisso; pertanto, un calo nei punteggi implica una regressione nel prodotto. Tuttavia, il giudice stesso è un modello basato su API soggetto a aggiornamenti silenziosi delle versioni, modifiche ai prompt o cambiamenti di policy.

Quando un sistema di monitoraggio attiva un allarme, si trova di fronte a un'ambiguità: la qualità del prodotto è degradata, o è cambiato il comportamento di scoring del giudice? Agire con l'attribuzione errata è costoso: i team potrebbero effettuare il rollback di un prodotto sano o distribuire una regressione scambiandola per un "judge drift" (drift del giudice). I metodi statistici classici, come i test z mobili (rolling z-tests), falliscono in questo contesto di monitoraggio continuo perché mancano di anytime-validity (validità in qualsiasi momento); rieseguire un test a $\alpha$ fisso ad ogni step gonfia il tasso di falsi allarmi, portando a rilevamenti spurii anche su flussi privi di drift.

2. Metodologia

Il paper propone un framework per disgiungere il drift del sistema dal drift del giudice utilizzando e-process anytime-valid e una regola di attribuzione ancorata all'umano.

A. Il Monitor Principale a Budget (Rilevamento del Drift del Sistema)
Il sistema impiega un monitor stratificato basato sulla prediction-power (seguendo Csillag et al., 2025b; Angelopoulos et al., 2023) per rilevare regressioni della qualità:

• Architettura: Un giudice economico ($\mu$) assegna punteggi a ogni elemento, mentre un giudice forte ed esteso ($y$) assegna punteggi a un sottoinsieme campionato sotto un budget fisso.
• Meccanismo: Per ogni cella (rubrica $\times$ strato), un e-process basato sulla prediction accumula "ricchezza" per testare l'ipotesi nulla che la media del punteggio non sia scesa al di sotto di una baseline sana.
• Efficienza dei Costi: Il sistema utilizza un trigger di e-wealth escalation. Man mano che l'evidenza del drift si accumula, la probabilità di campionamento per il giudice forte aumenta. Ciò consente al sistema di rilevare regressioni localizzate in punti ciechi a circa un terzo del costo di una valutazione completa, mantenendo l'anytime-validity (garantendo che il tasso di falsi allarmi rimanga limitato in qualsiasi tempo di arresto).

B. La Costruzione dell'Ancora (Rilevamento del Drift del Giudice)
Per risolvere l'ambiguità di attribuzione, gli autori introducono un secondo e-process indipendente, ancorato a etichette umane fisse:

• Set di Ancora ($A$): Una collezione fissa e tenuta da parte di elementi con etichette umane congelate ($h$), estratti prima dell'inizio del monitoraggio.
• Interleaving: A un ritmo costante (ad esempio, ogni $1/\rho$ elementi), l'attuale giudice forte ricalcola il punteggio di un elemento ancora scelto casualmente.
• L'E-Process: Un betting e-process traccia lo scarto tra il punteggio attuale del giudice sull'elemento ancora e l'etichetta umana congelata.
• Asimmetria: Poiché gli elementi ancora e le etichette umane sono fissi, solo un cambiamento nel giudice può alterare la distribuzione dello scarto. Il drift del sistema influenza gli elementi in entrata, ma lascia invariato lo scarto dell'ancora. Questo crea uno "specchio unidirezionale" che rileva esclusivamente il drift del giudice.

C. La Regola di Attribuzione (Finestra di Guardia)
Il sistema combina i tempi di arresto del processo principale ($\tau_{sys}$) e del processo dell'ancora ($\tau_{anc}$) utilizzando una finestra di guardia ($W$) per emettere un verdetto in $\{nessuno, sistema, giudice\}$:

• Verdetto Giudice: Se il processo dell'ancora scatta per primo ($\tau_{anc} < \infty$) e il processo principale scatta entro la finestra di guardia ($\tau_{sys} \le \tau_{anc} + W$), il verdetto è giudice. La logica è che un giudice contaminato invalida l'allarme principale.
• Verdetto Sistema: Se il processo principale scatta per primo e il processo dell'ancora non scatta entro la finestra di guardia, il verdetto è sistema.
• Race Condition (Condizione di Corsa): Il design si basa su una "corsa di attribuzione". Per prevenire la cattiva attribuzione, il processo dell'ancora deve essere fornito per rilevare il drift del giudice più velocemente di quanto il processo principale contaminato possa erroneamente scatenare un allarme di sistema.

3. Contributi Chiave

1. Costruzione dell'Ancora e Regola di Attribuzione: Un metodo innovativo che utilizza un e-process ancorato all'umano e anytime-valid per separare esplicitamente il drift del giudice dal drift del sistema, emettendo un verdetto a tre stati invece di un allarme binario.
2. Garanzie Teoriche:
   • Anytime-Validity: La famiglia dell'ancora mantiene un tasso di falsi allarmi limitato ($\alpha_{judge}$) in qualsiasi tempo di arresto dipendente dai dati.
   • Identificazione Unidirezionale: L'e-process dell'ancora è matematicamente garantito per essere insensibile al drift del sistema; può essere attivato solo da un cambiamento nel giudice.
   • Attribution Race: Il paper stabilisce una legge di design secondo cui il processo dell'ancora deve essere configurato per "superare in velocità" il processo principale. La cattiva attribuzione (falsi allarmi di sistema durante un drift del giudice) è funzione della larghezza della finestra di guardia, del tasso dell'ancora e della dimensione del set di ancora.
   • Ortogonalità: Il budget dell'ancora e la configurazione del processo principale sono indipendenti, consentendo una gestione separata della latenza del giudice e della potenza del sistema.
3. Validazione Empirica su Drift Reali: Il metodo è stato testato su due cambiamenti reali del giudice (un aggiornamento silenzioso della versione e un aggiornamento della policy di un prompt più rigoroso) su due domini (HelpSteer2 e riassunto TL;DR) senza necessità di ri-taratura.
4. Superiorità Operativa: Il processo e-proposto supera significativamente i baseline classici (test z mobili ingenui e detector Page–Hinkley calibrati) in termini di controllo dei falsi allarmi e rilevamento di drift sottili.

4. Risultati

• Accuratezza del Rilevamento:
  • Silent Version Bump: Rilevato come drift del giudice in 60/60 run con zero misattribuzione da giudice a sistema.
  • Strict-Prompt Change: Attribuito correttamente in 110/120 run (con finestra di guardia $W=300$) su HelpSteer2. Sul dominio TL;DR, dove lo shift del prompt era più severo, l'attribuzione è stata perfetta (240/240).
  • Misattribution: Il tasso di falsi allarmi di sistema durante il drift del giudice è diminuito monotonicamente all'aumentare della finestra di guardia ($W$), confermando la teoria della "corsa di attribuzione".
• Confronto con i Baseline:
  • Un test z mobile ingenuo (standard del settore) ha generato falsi allarmi su il 75% dei flussi privi di drift.
  • Un detector Page–Hinkley calibrato ha rispettato il budget dei falsi allarmi ma ha fallito nel rilevare il sottile version bump reale (solo l'8% di rilevamento su HelpSteer2) e richiedeva dati di calibrazione tenuti da parte.
• Efficienza dei Costi: Il monitor opera a circa lo 0,64 del costo di valutare ogni singolo elemento (o 0,21 in un regime "più economico ma meno sensibile").

5. Significato e Claim

Il paper sostiene di aver risolto un fallimento critico e non affrontato nelle operazioni LLM: l'incapacità di distinguere tra il degrado del prodotto e l'instabilità del giudice nel monitoraggio continuo.

• Impatto Pratico: La costruzione fornisce una garanzia netta che il drift del giudice non venga mai erroneamente imputato al sistema oltre un definito budget di errore ($\alpha_{judge}$). Ciò evita che i team prendano decisioni operative costose e errate (ad esempio, effettuare il rollback di modelli sani).
• Contributo Teorico: Dimostra che l'anytime-validity non è solo un dettaglio teorico, ma una necessità pratica per il monitoraggio continuo, poiché i metodi standard a orizzonte fisso falliscono catastroficamente sotto test sequenziali.
• Legge di Design: Il paper stabilisce che l'attribuzione è una condizione di corsa. Fornisce una ricetta concreta di "co-provisioning": il budget dell'ancora deve essere dimensionato per garantire che il processo dell'ancora rilevi il drift del giudice più velocemente di quanto il processo principale contaminato possa scatenare un falso allarme di sistema.
• Limitazioni: Gli autori notano con modestia che il metodo assume che le etichette umane rimangano un riferimento valido (richiedendo aggiornamenti periodici se gli standard evolvono) e che non rivendica l'ottimalità nelle strategie di betting o il minimo della misattribuzione a budget fissi, bensì la validità e l'identificazione.

In sintesi, il paper presenta un framework robusto e consapevole dei costi che trasforma l'ambiguo "allarme di drift" in un'attribuzione verificabile, assicurando che il "metro di misura" sia monitorato con la stessa rigore del "prodotto" che misura.