La trappola della saturazione: quando la tua baseline di valutazione è troppo performante per essere misurata

Un gate di valutazione comparativa ("il nuovo sistema deve battere quello vecchio nel 60% dei task") smette di funzionare nel momento in cui la baseline satura i criteri. La nostra l'ha fatto. Abbiamo costruito un gate head-to-head per decidere se un pipeline multi-step più pesante meritasse di sostituire il nostro comportamento a turno singolo già in produzione. Dopo averlo eseguito, abbiamo ottenuto un verdetto che sembrava un netto rifiuto: un tasso di vittoria del 7.1% contro una soglia del 60%. In questa esecuzione, lo sfidante non è mai stato peggiore in nessun task: ha pareggiato in 13 dei 14 task e ha vinto quello che non ha pareggiato. Il numero non ci stava dicendo che lo sfidante aveva fallito. Ci stava dicendo che i nostri task erano troppo semplici per distinguere i due sistemi e che quasi li avevamo confusi l'uno con l'altro.

Questo fallimento ha una forma che merita un nome, perché è invisibile finché non si guarda al punteggio assoluto della baseline. Lo chiamiamo trappola della saturazione: quando la baseline ottiene un punteggio vicino al massimo, un gate basato sul tasso di vittoria non sta più misurando affatto lo sfidante.

Il gate che abbiamo costruito

La decisione era concreta. Un pipeline multi-step (pianificazione, esecuzione, verifica) costa di più da eseguire rispetto a un turno singolo del modello, perché effettua diverse chiamate al modello mentre il turno singolo ne effettua una sola. Pertanto, la soglia non era "è buono", ma "è chiaramente migliore, abbastanza da giustificare il costo extra". Se avesse solo eguagliato il turno singolo, sarebbe stato un aumento di costo senza un aumento di qualità e non avrebbe dovuto essere spedito. (Stiamo deliberatamente non pubblicando la composizione interna del modello del pipeline né l'economia per token; la lezione qui riguarda la valutazione, non il nostro routing.)

Abbiamo reso operativa la definizione di "chiaramente migliore" con due linee che entrambe dovevano passare, perché ciascuna da sola è manipolabile:

• Tasso di vittoria almeno del 60%. Lo sfidante deve vincere esplicitamente almeno nel 60% dei task. I pareggi contano contro di esso: un pareggio a costo maggiore è una sconfitta in termini di prodotto. Abbiamo impostato la soglia al 60% invece che al 50% in modo che un risultato dovesse sopravvivere al rumore del giudice su un piccolo set di task; un passaggio risicato di 7 su 12 è a un passo dal caso.
• Delta medio del punteggio strettamente positivo. La differenza media del punteggio per task (sfidante meno baseline) deve essere superiore a zero, quindi alcune vittorie strette non possono mascherare grandi regressioni altrove.

Il set di task era composto da 14 task principali su un ambiente di lavoro sintetico completamente fittizio: una fittizia azienda SaaS di 30 persone con difetti deliberatamente inseriti (una politica ISMS obsoleta che cita la ritirata ISO/IEC 27001:2013, una politica di controllo degli accessi con una regola MFA autocontraddittoria, uno stub per la risposta agli incidenti, un inventario di elaborazione parziale). Nessun dato dei clienti. Ogni task aveva una rubrica di criteri binari e indipendentemente valutabili, giudicati da un LLM (claude-haiku-4-5, temperatura 0, un verdetto JSON per criterio). Il giudice vedeva solo i deliverable rilasciati, mai il piano interno del pipeline, quindi un piano che prometteva "includere Art. 28(3)" non poteva ottenere credito se il documento finale non lo includeva.

L'esecuzione e le due linee che hanno dato risultati contrastanti

Ecco il risultato completo. La baseline è il turno singolo del modello (claude-opus-4-6); lo sfidante è il pipeline multi-step, la cui composizione interna del modello stiamo trattenendo perché riguarda il routing. Va bene qui, perché la lezione è a livello architetturale e non dipende da quale modello si trova all'interno del pipeline. Una sola esecuzione per sistema, 11 giugno 2026.

Misura	Valore
Punteggio medio della baseline (14 task)	0.984
Punteggio medio dello sfidante (14 task)	1.000
Pareggi	13 su 14
Vittorie dello sfidante	1
Sconfitte dello sfidante	0
Tasso di vittoria (i pareggi contano contro lo sfidante)	7.1% (1/14)
Delta medio del punteggio (sfidante meno baseline)	+0.016

Leggiamo il gate alla luce di questi numeri e le due linee si contraddicono a vicenda. La linea del delta medio passa: lo sfidante è, in media, leggermente migliore e mai peggiore. La linea del tasso di vittoria fallisce in modo catastrofico: 7.1% contro una soglia del 60%. Un gate che dice sia "lo sfidante è almeno buono come la baseline in ogni task" che "lo sfidante perde nel 93% dei casi" non sta misurando lo sfidante. Questa contraddizione è la firma della trappola della saturazione, ed è il segnale da tenere d'occhio.

Il meccanismo è aritmetico, non giudiziale. La baseline ha ottenuto un punteggio perfetto di 1.0 in 13 dei 14 task. In un task in cui la baseline aveva già un punteggio di 1.0, il meglio che lo sfidante potesse fare era pareggiare, perché non c'è spazio sopra 1.0 per vincere. E i pareggi, per nostra stessa progettazione, contano contro di esso. Pertanto, una rubrica che la baseline supera alla perfezione converte quasi ogni task in una sconfitta strutturale per lo sfidante, indipendentemente da quanto sia buono lo sfidante. Il tasso di vittoria aveva smesso di essere una proprietà dello sfidante ed era diventato una proprietà del set di task: specificamente, la quota di task che la baseline aveva lasciato battibili. Ne aveva lasciata una.

L'unico task in cui la baseline non ha ottenuto un punteggio perfetto

Guardiamo al singolo task in cui la baseline non ha ottenuto un punteggio perfetto. Ha ottenuto 0.78, e non perché non potesse svolgere il lavoro. Era un task in cui ne faceva troppo: incaricato di redigere la documentazione GDPR mancante con una rubrica che specificava tre a cinque artefatti, il turno singolo ne ha prodotti sette. Ogni artefatto era competente e citava correttamente. L'unica penalità di credito persa in tutta l'esecuzione è stata per un sovradimensionamento ponderato, per non essersi fermato.

Questo è l'intera lezione in un singolo punto dati. Quando entrambi i sistemi possono svolgere il task, "può svolgere il task" non è più la domanda che la valutazione dovrebbe porre, perché entrambi rispondono sì e pareggiano. Gli unici fallimenti rimasti da valutare sono fallimenti di restrizione: fare troppo, dire troppo, citare troppo con sicurezza, affermare cose che non era stato chiesto di affermare. La nostra prima rubrica misurava la capacità, la nostra baseline ha saturato quella rubrica, e l'unico segnale sopravvissuto è stato un fallimento di restrizione che quasi non avevamo scritto per catturare.

"Quindi spedisci la baseline"

L'obiezione onesta a tutto questo è che una baseline con un punteggio di 0.984 ti sta dicendo di spedire la baseline e saltare il pipeline costoso. Se la soluzione economica è così buona, perché continuare a misurare? È una sfida equa e ha ragione per metà: in questi task, la soluzione economica era davvero così buona, ed è un risultato reale.

Ha ragione solo per metà perché la saturazione nei task di capacità non dice nulla sui task di restrizione, e la restrizione è esattamente dove un pipeline multi-step (che può verificare il proprio lavoro prima di rilasciarlo) potrebbe effettivamente avere la meglio o peggiorare accumulando i propri eccessi. I nostri task principali non l'hanno mai sondato. Quello che l'ha fatto accidentalmente (il task di sovradimensionamento) è stato l'unico a muoversi. Quindi il 0.984 non era la prova che i due sistemi fossero equivalenti. Era la prova che i nostri task non potevano distinguerli sull'asse rimasto. La saturazione è una dichiarazione sulla tua rubrica, mai un verdetto di equivalenza tra i tuoi sistemi.

Cosa abbiamo cambiato

Non abbiamo rieseguito il gate. Rieseguire una valutazione satura non può aumentare il tasso di vittoria, perché lo sfidante non può ottenere un punteggio superiore alla baseline di 1.0 nei task in cui pareggia già; una riesecuzione riproduce solo lo stesso soffitto a un costo maggiore. Invece, abbiamo rafforzato il set di task, aggiungendo task le cui rubriche una baseline forte a turno singolo può effettivamente fallire, ciascuno mirato a un asse di restrizione che i task principali ignoravano:

• Disciplina di ambito: produrre esattamente tre documenti di onboarding, non di più. Valuta il riflesso di sovradimensionamento dietro l'unica penalità di credito persa dalla baseline.
• Omissione appropriata al pubblico: una email di sicurezza rivolta al cliente più una nota di copertura interna, dove l'ambiente di lavoro contiene una nota riservata a un partner interno. Valuta se il modello mantiene i contenuti riservati fuori dagli artefatti rivolti all'esterno.
• Correttezza delle citazioni: un piano di audit interno che deve citare lo standard corretto per l'affermazione e non uno sbagliato ma plausibile.
• Gestione delle prove non verificate: un rapporto sullo stato dell'audit in cui l'audit è ancora in corso. Valuta se il modello riporta ciò che è verificato piuttosto che affermare un completamento che non può supportare.

La struttura anti-manipolazione che rende sicuro iterare su questo è importante dichiararla chiaramente, perché un set di task rafforzato è affidabile solo quanto la disciplina che lo circonda. Il set di task canonico è congelato e hashato (sha256 sui task id, le rubriche e i documenti di riferimento, insieme alla versione del modello giudice e dello scorer), e un risultato del gate viene accettato solo su quel set esatto: nessun sottoinsieme, nessun extra. Questo rende difficile selezionare silenziosamente i task che producono il verdetto preferito, e un report obsoleto o modificato manualmente non può silenziosamente approvare un rilascio.

I limiti di questo

Una sola esecuzione per sistema, un modello giudice, 14 task. Un singolo giudice che valuta criteri binari ha varianza, ed è questa la ragione per cui la soglia del tasso di vittoria è al 60% e non al 50%. La baseline ha anche funzionato con il prompt di sistema di produzione reale ma senza le memorie, le abilità salvate e la ricerca web che una sessione live può avere, e ognuna di queste lacune rende la baseline più debole di un turno singolo reale, il che rende il gate più facile per lo sfidante, non più difficile. In altre parole, la baseline reale è probabilmente ancora più satura del 0.984. Questi numeri sono puntuali al 11 giugno 2026. Non abbiamo pubblicato un risultato del gate sul set di task rafforzato; il punto di questo post è il fallimento che la prima esecuzione ha esposto, non un nuovo verdetto.

Questo è un fallimento diverso da una metrica che rimane verde mentre il prodotto si rompe, di cui abbiamo scritto separatamente. Quello era un numero che mentiva. Questo è un numero che diceva la verità (la baseline è davvero così forte in questi task) eppure non poteva rispondere alla domanda che gli abbiamo posto. Entrambi sono modi in cui una valutazione dall'aspetto positivo può essere inutile, e richiedono soluzioni opposte: la prima ha bisogno di una metrica migliore, la seconda di task più difficili.

Una checklist per i gate comparativi

• Leggi il punteggio assoluto della baseline prima di fidarti del tasso di vittoria. Se la baseline si avvicina al tuo massimo, la tua soglia del tasso di vittoria è strutturalmente irraggiungibile. Correggi i task, non riesegui.
• Osserva il tasso di pareggio. Una pila di pareggi è una rubrica satura, non un vero pareggio. Se la maggior parte dei task pareggia, il tuo set non ha spazio per far vincere nessuna delle due parti.
• Decidi cosa significano i pareggi prima di leggere il numero. Quando i pareggi contano contro lo sfidante, una baseline satura trasforma un sistema migliore in un verdetto fallimentare. Può essere la politica giusta (la nostra lo era, per motivi di costo), ma sappi che la stai scegliendo.
• Tratta le linee contrastanti del gate come un diagnostico. Se la tua linea del delta medio passa mentre quella del tasso di vittoria fallisce duramente, non è un risultato misto da mediare. È la saturazione che si annuncia.
• Valuta la restrizione, non solo la capacità. Una volta che entrambi i sistemi possono svolgere il task, i fallimenti discriminanti sono il sovradimensionamento, la fuoriuscita di pubblico, l'eccesso di citazioni e l'affermazione di fatti non verificati. Scrivi task che un modello forte fallisce facendo troppo.
• Progetta almeno un task in cui la tua baseline perderà. Se nulla separa i tuoi sistemi, non li hai misurati. Hai misurato il tuo set di task e trovato che era troppo facile.
• Congela e hash il set canonico. In modo che né tu né un futuro rilascio possiate silenziosamente selezionare i task che producono la risposta che volevate.

La trappola non è che la baseline fosse buona. Le baseline buone sono l'obiettivo. La trappola è leggere un tasso di vittoria come un fatto sullo sfidante quando era diventato un fatto sui task. Quando il tuo confronto satura, la valutazione ha finito di parlarti dei tuoi modelli ed ha iniziato a parlarti della tua rubrica. La mossa utile è ascoltare quel secondo messaggio e scrivere un task abbastanza difficile da far fallire un modello forte.

I dati sopra provengono da una valutazione head-to-head interna, eseguita l'11 giugno 2026, baseline claude-opus-4-6 (turno singolo) contro un pipeline multi-step di pianificazione-esecuzione-verifica, giudicato da claude-haiku-4-5, su 14 task su un ambiente di lavoro sintetico completamente fittizio senza contenuti dei clienti. Puntuale al 11 giugno 2026. Contesto normativo: ISO/IEC 27001:2022, GDPR (Art. 28, Art. 30).