Anche le tue valutazioni sono instabili: smetti di fidarti di un tasso di superamento che non puoi riprodurre
La maggior parte delle persone sa che gli agenti AI sono non deterministici. Invii lo stesso prompt, ma ottieni output diversi.
Abbiamo accettato questo fatto. Abbiamo iniziato a usare gli LLM come giudici per valutare questi agenti.
Ma abbiamo commesso un errore enorme. Abbiamo dato per scontato che i nostri giudici fossero deterministici. Non lo sono.
La tua suite di valutazione è un sistema casuale che valuta un altro sistema casuale. Se non misuri quanto il tuo valutatore oscilla, non hai un quality gate. Hai un lancio di moneta.
Ho visto accadere con un agente di supporto. La dashboard è rimasta verde per settimane. Poi, i reclami dei clienti sono aumentati drasticamente. Ho eseguito la stessa valutazione su 200 vecchie risposte. 14 di esse hanno cambiato verdetto. L'agente non era cambiato. Il giudice ha cambiato idea.
Un gate instabile è peggio di un gate inesistente. Ti dà una falsa sicurezza.
Ci sono tre ragioni per cui le tue valutazioni falliscono:
- Il modello giudice: ogni giudice LLM ha una varianza. Anche con temperatura 0, i provider non garantiscono lo stesso risultato. Un aggiornamento silenzioso del modello può rovinare la tua baseline da un giorno all'altro.
- L'harness: se il contesto o gli output degli strumenti cambiano tra un'esecuzione e l'altra, il giudice vede una domanda diversa. L'input ha subito un drift.
- La rubrica: regole vaghe come "è buono?" creano varianza. Regole strette e specifiche la riducono.
Devi trattare le valutazioni instabili come i test software instabili. Non rilasciarle. Mettile in quarantena. Misura il tasso di instabilità.
Smetti di riportare un singolo tasso di superamento. Inizia a riportare l'accordo (agreement).
Esegui ogni chiamata al giudice più volte. Se il giudice non riesce a concordare con se stesso, il verdetto non è un segnale. È UNSTABLE.
Un risultato UNSTABLE dovrebbe essere un esito di prima classe nella tua pipeline CI/CD. Dovrebbe fallire in modo evidente.
Per correggere una valutazione instabile, hai bisogno di due cose:
- Uno strato di scoring: calcola la stabilità e trasforma i risultati in PASS, FAIL o UNSTABLE.
- Uno strato di tracing: devi poter vedere i byte grezzi, il prompt esatto e gli output degli strumenti per ogni esecuzione.
Senza i trace, penserai che il modello sia semplicemente casuale. Abbasserai la temperatura e penserai di aver risolto il problema. Non l'hai risolto. Hai solo reso il bug più silenzioso.
Segui queste regole per costruire una qualità reale:
- Riporta l'accordo, non solo le medie.
- Rendi UNSTABLE uno stato di errore nella tua pipeline.
- Blocca le versioni dei tuoi modelli giudice.
- Leggi i trace quando un controllo fallisce.
Una dashboard verde che non puoi riprodurre non è un segnale. È una storia che racconti a te stesso.
Optional learning community: https://t.me/GyaanSetuAi