Lo scambio di non-inferiorità: come implementiamo cambiamenti di modelli con un pareggio di qualità

Il 2026-09-01 abbiamo spostato la nostra interfaccia di chat a pagamento (think) da Grok 4.6 (con reasoning attivo) a GLM 5.3 (con effort alto) dopo una valutazione in cui il modello sfidante ha ottenuto un punteggio inferiore di 1,7 punti sulla qualità delle risposte. Sul nostro prompt di produzione, il tempo mediano per il primo token del modello incumbent era di 88.906 ms; quello del modello sfidante era di 4.169 ms. La stessa valutazione ha anche spostato l'interfaccia di chat a pagamento (fast) (con un netto vantaggio di +10,0 punti) e entrambe le modalità dell'interfaccia gratuita (+13,3 e +11,7 punti). Tutte e tre le interfacce utilizzano oggi il modello sfidante in produzione, mentre i modelli precedenti sono a un solo parametro di distanza. Chiamiamo questa pratica lo scambio di non-inferiorità (non-inferiority swap), e riteniamo che sia la strategia corretta per i cambiamenti di modelli in produzione: il compito della valutazione non è trovare un vincitore, ma stabilire, secondo regole pre-congelate prima dell'esecuzione, che il modello sfidante non perda, lasciando poi che siano le metriche percepite dagli utenti (latenza del primo token, code, affidabilità) a risolvere il pareggio.

Perché la porta intuitiva fallisce

La maggior parte dei team gestisce un cambio di modello nel modo ovvio: esegue una valutazione e implementa solo se il nuovo modello ottiene un punteggio più alto. Due problemi invalidano questa porta.

Innanzitutto, su compiti reali di prodotto, le differenze di qualità tra i modelli di frontiera attuali sono solitamente inferiori alla capacità del giudice di misurarle. Il nostro benchmark di conformità su 20 task ha misurato un errore di test-retest del giudice pari a 18,2 punti su una scala di 100, e ha pre-registrato il verdetto come pareggio proprio su questa base (la valutazione è avvenuta il giorno dopo questo scambio; l'abbiamo documentata qui). Una porta che richiede un miglioramento su questo strumento non si attiva quasi mai in modo onesto. Una porta senza questo requisito implementa decisioni basate sul rumore.

In secondo luogo, una porta che richiede un miglioramento stretto crea gli incentivi sbagliati: o non viene mai implementato nulla, o qualcuno ri-esegue la valutazione finché il rumore non favorisce il modello sfidante.

L'alternativa è presa in prestito dai trial clinici. Un trial di non-inferiorità non chiede se il nuovo trattamento sia migliore, ma solo se sia accettabilmente non peggiore, entro un margine definito prima di qualsiasi dato. Adottiamo questo disegno integralmente: pre-registriamo una banda di pareggio e le guardie operative, eseguiamo una sola volta e rendiamo il verdetto meccanico.

L'impostazione: tre interfacce, tre regole congelate

Abbiamo valutato tre interfacce di chat di produzione dello stesso prodotto, una singola struttura di valutazione, una singola esecuzione. Ogni interfaccia aveva la propria regola decisionale, congelata il 2026-09-01 prima di qualsiasi chiamata:

Interfaccia	Modello incumbent	Modello sfidante	Regola pre-registrata
A pagamento (fast)	GLM 5.2	GLM 5.3-Flash, effort basso	Qualità entro 5,0 punti E latenza mediana del primo token non materialmente peggiore E p90 sotto la soglia di fallback di 8 s E tasso di code oltre 10 s non peggiore di oltre 5 pp
A pagamento (think)	Grok 4.6, reasoning attivo	GLM 5.3, effort alto	Qualità entro la banda di pareggio di 5,0 punti consente lo scambio
Gratuita (fallback per utenti non autenticati e oltre quota)	GLM 4.7	GLM 5.3-Flash, effort basso	Qualità entro 5,0 punti E latenza mediana del primo token sotto 2x l'incumbent

La banda di pareggio era di 5,0 punti sulla metrica di qualità, congelata nel piano e non aggiustata dopo aver visto i punteggi. Una guardia era congelata in forma testuale piuttosto che numerica: la regola per l'interfaccia a pagamento (fast) afferma che la latenza mediana del primo token del modello sfidante deve essere "non materialmente peggiore", senza una soglia numerica allegata. Il piano è il piano, e questa guardia ha richiesto una chiamata di giudizio nella sezione dei risultati; la soluzione è una guardia numerica la prossima volta, ed è nella checklist. Il nostro strato di streaming effettua un fallback a uno stato di attesa dopo 8 secondi senza il primo token di contenuto sulle interfacce fast e dopo 120 secondi su quelle think, quindi le guardie di latenza sono state scritte in base a questi budget reali.

Metodologia, come congelata:

• Il prompt era l'assembly di produzione. 22.445 caratteri: il prompt di stile conciso, l'iniezione di conoscenza del framework costruita dalla domanda, il blocco workspace, la data. Identico byte per byte tra tutte le varianti. Un prompt demo compatto avrebbe misurato un prodotto diverso.
• Quattro task, tre compiti di risposta GRC di lunga durata più un task di policy basato su workspace nativo per la chat, ciascuno valutato su una rubrica a cinque criteri 0-2. Tre campioni per variante per task a temperatura 0.
• Un modello giudice ha valutato ogni output al buio: Grok 4.3, eseguito tramite OpenRouter, senza etichette delle varianti, senza conoscenza di quale modello avesse prodotto cosa. Condivide una famiglia di vendor con esattamente una variante, l'incumbent think. La preferenza auto-riferita negli valutatori LLM è documentata quando il giudice valuta le proprie generazioni (Panickssery, Bowman e Feng, arXiv:2404.13076, 2024-04-15), e i bias di posizione e verbosità sono catalogati negli setup LLM-as-a-judge (Zheng et al., arXiv:2306.05685, 2023-06-09). Nessuno dei due articoli misura il bias a livello di famiglia, e neanche noi l'abbiamo fatto, quindi abbiamo registrato la direzione del rischio invece di assumere neutralità: se esiste un favoritismo a livello di famiglia, questo gonfia l'incumbent, il che rende lo scambio think conservativo, non permissivo.
• I baseline dell'incumbent sono stati rigenerati freschi nella stessa esecuzione. La nostra valutazione di giugno dello stesso incumbent utilizzava un giudice diverso e un assembly di prompt precedente, quindi riutilizzare i suoi numeri archiviati avrebbe significato confrontare due strumenti diversi. Stesso giudice, stesso giorno, stesso assembly, altrimenti il confronto non è decisivo.
• Un tetto di spesa pre-registrato con un aborto automatico e timeout rigidi per chiamata.

I risultati

La qualità è il punteggio medio del giudice come percentuale del massimo della rubrica; 12 generazioni valutate per variante (4 task, 3 campioni), 2026-09-01:

Interfaccia	Variante	Qualità
A pagamento (fast)	GLM 5.2 (incumbent)	81,7
A pagamento (fast)	GLM 5.3-Flash, effort basso	91,7
A pagamento (think)	Grok 4.6, reasoning attivo (incumbent)	91,7
A pagamento (think)	GLM 5.3, effort alto	90,0
Gratuita (fast)	GLM 4.7 (incumbent)	80,0
Gratuita (fast)	GLM 5.3-Flash, effort basso	93,3
Gratuita (think)	GLM 4.7, reasoning attivo (incumbent)	80,8
Gratuita (think)	GLM 5.3-Flash, effort basso	92,5

La latenza è il tempo al primo token di contenuto su una connessione streaming; sei ripetizioni per variante su un task di produzione basato su workspace (lo stesso assembly di prompt di 22.445 caratteri della valutazione di qualità), 2026-09-01:

Variante	TTFC p50	TTFC p90	Ripetizioni oltre 10 s
A pagamento (fast): GLM 5.2	773 ms	2.626 ms	0 su 6
A pagamento (fast): GLM 5.3-Flash	2.641 ms	4.011 ms	0 su 6
A pagamento (think): Grok 4.6	88.906 ms	101.591 ms	6 su 6
A pagamento (think): GLM 5.3	4.169 ms	57.707 ms	2 su 6
Gratuita (fast): GLM 4.7	2.857 ms	3.163 ms	0 su 6
Gratuita (fast): GLM 5.3-Flash	3.350 ms	3.640 ms	0 su 6
Gratuita (think): GLM 4.7	18.014 ms	24.156 ms	6 su 6
Gratuita (think): GLM 5.3-Flash	3.052 ms	7.612 ms	0 su 6

Applicate meccanicamente, le regole congelate hanno prodotto tre verdetti:

• A pagamento (fast): VA BENE, e l'interfaccia è diventata più lenta. Qualità +10,0 punti. Primo token 3,4 volte più lento (da 773 ms a 2.641 ms di mediana), ma p90 a 4,0 s contro la soglia di 8 s e zero ripetizioni oltre 10 s su entrambi i lati. Qui il verdetto ha smesso di essere completamente meccanico: la guardia testuale ("non materialmente peggiore") non ha una soglia, e abbiamo giudicato che 2,6 s di mediana con un p90 a 4,0 s e nessuna coda superi questo limite. Questa chiamata è registrata qui invece di essere "lavata" in una soglia che non è mai esistita. Se gli utenti percepiscano 2,6 s come peggiore di 0,8 s non è qualcosa che questa valutazione ha misurato; ciò che ha stabilito è che la guardia, come congelata, è passata, e che un requisito di velocità superiore all'incumbent avrebbe vetoato uno scambio che le regole congelate hanno valutato come un netto vantaggio di qualità.
• A pagamento (think): VA BENE su un pareggio. 90,0 contro 91,7 è -1,7 punti, all'interno della banda di 5,0 punti. Di contro, i 88,9 secondi di mediana del primo token dell'incumbent sulla nostra sonda (6 ripetizioni su 6 oltre 10 s) sono diventati 4,2 secondi di mediana (2 su 6 oltre 10 s, e il p90 dell'incumbent era già oltre 100 s). Un miglioramento di 21 volte in una metrica che gli utenti percepiscono, per 1,7 punti che si trovano all'interno della banda di pareggio pre-registrata.
• Gratuita: VA BENE. +13,3 punti in modalità fast, +11,7 in modalità think, e il vecchio braccio think con mediana a 18,0 secondi e 6 code su 6 è diventato 3,1 s senza code.

Il verdetto think è quello su cui vale la pena discutere, quindi ecco l'argomento per intero. La banda pre-registrata afferma che un divario di 1,7 punti non è una differenza di qualità. I 18,2 punti di errore di test-retest che il nostro benchmark di conformità ha misurato il giorno successivo, su un set di task e una rubrica diversi, è l'unica misurazione diretta che abbiamo della risoluzione del giudice sui nostri strumenti, e si trova un ordine di grandezza sopra questo divario. Nessuno dei due numeri è un intervallo di confidenza su questo divario specifico, e la banda è una regola decisionale, non un pavimento di rumore misurato. Ma entrambi puntano nella stessa direzione. Mantenere l'interfaccia think a 1,7 punti che i nostri strumenti non riescono a risolvere, mentre la mediana del primo token dell'incumbent sulla nostra sonda era a 89 secondi, inverte le priorità: il numero che gli utenti percepiscono per primo è la latenza, e si è mosso di 21 volte nella nostra misurazione.

Un verdetto ha una data di scadenza

Nel giugno 2026 abbiamo valutato GLM 5.2 (rilasciato il 2026-06-16) come sostituzione di GLM 4.7 sullo stesso prodotto, e il verdetto del 2026-06-18 era non sostituire: due giudici indipendenti e al buio lo hanno valutato alla pari di GLM 4.7, con pareggi esatti una volta escluso un errore infrastrutturale, ma ha fallito le guardie operative in modo decisivo, soprattutto sulla latenza think: 93 s di mediana al primo token di contenuto contro i 2,1 s di GLM 4.7 sui nostri task e configurazione, un divario di 44 volte.

Tre mesi dopo, il suo successore ha battuto lo stesso incumbent in entrambe le modalità gratuite nella valutazione di settembre. Due conclusioni che ora trattiamo come regole consolidate.

I verdetti sui modelli hanno una data di scadenza misurata in mesi. Una chiamata del tipo "pari di qualità, non implementabile operativamente" è un verdetto su un modello in un momento specifico, non sullo slot; lo slot ha ricevuto un modello diverso e il verdetto è cambiato. Questo è un altro motivo per cui rigeneriamo i baseline dell'incumbent in ogni valutazione di scambio invece di citare quelli archiviati: i baseline archiviati confrontano silenziosamente strumenti diversi, e i verdetti obsoleti confrontano silenziosamente generazioni di modelli diverse. Il numero di giugno era vero. Non lo abbiamo ereditato, e non ci ha vincolato.

Due cose che la struttura di valutazione ha catturato

Generazioni vuote a un limite stretto. Il primo passaggio di latenza del 2026-09-01 ha eseguito ogni variante con un limite di completamento di 256 token. Tutte e dodici le righe dei due bracci think GLM (GLM 4.7 e GLM 5.2, sei ciascuno) sono tornate vuote: il canale di reasoning ha consumato il budget prima che esistesse il primo token di contenuto, quindi la riga misurava il limite, non il modello. Il braccio think Grok 4.6 ha streamato correttamente con lo stesso limite. Abbiamo invalidato il passaggio e abbiamo rieseguito i bracci think GLM con un limite di 4.096 token prima di leggere qualsiasi percentile; la valutazione di qualità aveva utilizzato un budget di 16k in tutto e non è stata influenzata. Questo è lo stesso tipo di fallimento di cui abbiamo scritto ad agosto (dati senza nulla dentro, valutati come una misurazione). La guardia economica è poco appariscente: conta le generazioni vuote per braccio e rifiuta di aggregare qualsiasi braccio il cui conteggio vuoto sia diverso da zero.

La forma della richiesta dell'incumbent non si trasporta. Abbiamo verificato se la configurazione precedente potesse essere copiata sul modello sfidante. Nei nostri test lato API del 2026-09-01, 24 chiamate su 24 su GLM 5.3 e GLM 5.3-Flash che portavano reasoning: {enabled: false} sul percorso testato hanno restituito HTTP 400, quindi nei nostri test, il reasoning non può essere disattivato su questa famiglia; l'effort basso è il limite inferiore, non un interruttore. Una migrazione di modello ridefinisce la configurazione della richiesta dal comportamento effettivo del modello sfidante. Ogni parametro che copi dall'incumbent senza ritestare è un confondente che inserisci nella tua valutazione.

Cosa questa analisi afferma e non afferma

I numeri di qualità provengono da 12 generazioni valutate per braccio (4 task, 3 campioni, temperatura 0), un modello giudice, nessuna calibrazione umana delle rubriche di chat, una singola esecuzione in un solo giorno (2026-09-01), solo sul nostro assembly di prompt e sulla nostra configurazione di servizio. La banda di pareggio di 5,0 punti era una regola decisionale pre-registrata, non un pavimento di rumore misurato per questo strumento; il nostro benchmark di conformità su 20 task, eseguito il giorno successivo (2026-09-02) su un set di task e una scala di rubrica diversi, ha misurato 18,2 punti di errore di test-retest del giudice, quindi trattiamo le differenze di qualità all'interno della banda come non misurate, non come zero. I percentili di latenza provengono da 6 ripetizioni streaming per braccio su un task di workspace, il nostro assembly di prompt, la nostra configurazione, quel giorno: proprietà del nostro setup, non benchmark di vendor. Tutti i risultati sono puntuali al 2026-09-01. Una descrizione pubblica della nostra metodologia di benchmark, inclusa la misurazione dell'errore del giudice, è disponibile nella pagina sulla qualità dei modelli.

La checklist

Prima del prossimo scambio di modelli in produzione:

1. Congela la regola decisionale per interfaccia prima dell'esecuzione: banda di pareggio, guardie di latenza, guardie di code, tetto di spesa e cosa significa un pareggio.
2. Dimensione la banda di pareggio in base all'errore di test-retest del tuo giudice sulle tue rubriche. Se non hai mai rieseguito la valutazione di risposte identiche, non sai quanto siano piccoli i tuoi divari di qualità misurabili.
3. Valuta sull'assembly di prompt di produzione, identico byte per byte tra i bracci. Un prompt demo misura un prodotto che non esegui.
4. Rigenera i baseline dell'incumbent nella stessa esecuzione, con lo stesso giudice, lo stesso giorno. I baseline archiviati sono confronti tra strumenti diversi.
5. Proteggi le code, non le medie: latenza p90 del primo token e tasso di code oltre 10 s, in base ai tuoi reali fallback di streaming.
6. Conta le generazioni vuote per braccio e rifiuta di valutare qualsiasi braccio che ne abbia. Correggi il budget di completamento, poi misura.
7. Ridefinisci la configurazione della richiesta per il modello sfidante, inclusi i parametri di reasoning. Non copiare mai la forma dell'incumbent nella valutazione.
8. Conosci la direzione del bias della famiglia del tuo giudice e progetta in modo che spinga verso una decisione conservativa.
9. Metti una data di scadenza su ogni verdetto. Riesegui qualsiasi cosa più vecchia di un trimestre.

Un pareggio non è indecisione. È il verdetto che la tua valutazione di qualità può difendere davvero, e renderlo pre-registrato è ciò che consegna la decisione alle metriche che i tuoi utenti percepiscono.