Migrare il modello con un A/B appaiato e il rollback scritto prima

In breve. Dopo il repricing OpenAI del 30 luglio 2026 ho migrato SupportChat, l'assistente di supporto di Arvo, da gpt-5.4-mini a gpt-5.6-luna. Non l'ho trattato come un taglio di costo ma come un cambio di contratto di qualità: A/B appaiato su 200 casi congelati, baseline di partenza fissata prima dello switch e condizioni di rollback scritte prima di accendere il nuovo modello. Il risparmio, circa 454 dollari al mese contro circa 223, è una stima, non una misura: il confronto dopo il deploy non è ancora stato fatto. Fatti dalla PR #1601 di Arvo; la tesi è un'interpretazione mia.

Perché un cambio di modello non è un taglio di costo

Quando un fornitore abbassa i prezzi, la tentazione è sostituire la stringa del modello e guardare la fattura. Ma il modello nuovo risponde in modo diverso, e la qualità percepita dall'utente può spostarsi senza che nessun test unitario lo veda.

Per me è un cambio di contratto: prima il sistema prometteva un certo livello di risposte, dopo ne promette un altro. Va validato come si valida un rilascio, con un confronto e una soglia di uscita, non come una voce di spesa. Questa è l'interpretazione su cui si regge tutto il resto.

Cosa ho misurato prima di accendere

Il contesto: il repricing del 30 luglio ha abbassato Luna dell'80% e Terra del 20%. La PR è stata fusa il 1° agosto 2026.

• A/B appaiato su 200 casi congelati. Gli stessi casi, passati a entrambi i modelli. Risultato: 83,0% contro 84,0%, con una differenza di un punto percentuale, e un test di McNemar con p = 0,83. In pratica la differenza non si distingue dal rumore. La PR indica anche che le conversazioni a più turni reggono, la latenza è invariata e non ci sono stati errori tecnici.
• Costo per task intorno al 30% di prima.
• Baseline pre-switch congelata. Media di qualità 89,21 su 1.538 casi, fissata prima del passaggio, con trigger di rollback espliciti nel report.

Due precisazioni sull'onestà del dato. Duecento casi sono pochi: un p di 0,83 dice che non ho visto una differenza, non che non ce ne sia. E il test di McNemar confronta la stessa coppia di risposte caso per caso, per questo l'appaiamento conta: due campioni indipendenti da 200 avrebbero detto meno.

Il trigger di rollback va scritto prima

La parte che rifarei sempre è questa: le condizioni per tornare indietro sono nel report prima dello switch, con la baseline congelata accanto. Dopo il deploy, con un modello nuovo che «sembra andare bene», è facilissimo spostare l'asticella. Se la soglia esiste già, il confronto a T+3 e T+7 giorni è meccanico.

Un 400 che nessuno aveva visto

Durante le prove sull'API è emerso che Luna rifiuta il livello di ragionamento minimal. La PR lo descrive come un errore 400 latente, chiuso con la migrazione. La PR aggiunge un ramo dedicato per la famiglia 5.6 e un test. Lo trovo istruttivo: la migrazione non ha solo cambiato la stringa, ha cambiato i parametri che il modello accetta.

Cosa resta aperto: il risparmio è una stima

Lo dico in chiaro perché è la parte più facile da gonfiare. Il costo atteso, da circa 454 a circa 223 dollari al mese (circa 220 da SupportChat e circa 11 da altri agenti della stessa PR), è stimato da listino e volumi, non misurato.

Nel test plan della PR resta una casella non spuntata: il confronto sulla qualità dei messaggi di supporto a T+3 e T+7 contro la baseline congelata. Un controllo parziale esiste: l'audit di Arvo del 2 agosto riporta un check a T+48 ore, anticipato, sui messaggi dal go-live. Il campione era di 145 messaggi, sotto la soglia di 300 prevista dal gate, quindi indicativo. Qualità media 87,41 contro la baseline 89,21 (trigger di rollback sotto 85), casi gravi 1,38% contro 2,15% (trigger sopra 4%), messaggi sotto 60 al 6,90% contro 6,83% (trigger sopra 10%). Nessun trigger è scattato, ma la media è più bassa della baseline e il campione è piccolo.

Non ho trovato nei documenti i confronti a T+3 e T+7, né un costo mensile reale da mettere accanto alla stima. Finché mancano, «qualità invariata» è ciò che l'A/B su 200 casi ha mostrato prima del deploy più un check indicativo a 48 ore, non una misura in produzione. Quando avrò quei dati aggiornerò l'articolo.

Fatto e interpretazione

Fatto (PR #1601): i numeri dell'A/B, la baseline 89,21 su 1.538, il rifiuto di minimal da parte di Luna, il costo stimato, la casella aperta.

Interpretazione (mia): che un cambio di modello vada trattato come cambio di contratto di qualità, con baseline e rollback scritti prima, e non come un'ottimizzazione di costo.

Per chi vuole ragionare sui costi degli LLM in generale c'è quanto costa investire in LLM; su come un'evidenza apparente possa sbagliare, il test rosso che dipendeva dalla shell.

Domande frequenti

Come si confronta un modello nuovo con quello vecchio?

Con un A/B appaiato: gli stessi casi, congelati, passati a entrambi i modelli, e un test statistico adatto alle coppie come McNemar. Nel mio caso 200 casi, 83,0% contro 84,0%, p = 0,83.

Quando scrivere i trigger di rollback?

Prima dello switch, insieme alla baseline di partenza. Dopo, con il modello nuovo in produzione, la soglia tende a muoversi verso ciò che si sta già osservando.

Il risparmio dichiarato è reale?

Per ora è una stima da listino e volumi. Un check a 48 ore sulla qualità esiste ed è indicativo (145 messaggi, media 87,41 contro 89,21 di baseline); il costo mensile reale e i confronti a T+3 e T+7 non risultano nei documenti.