Come si decide se aggiornare il modello
Esce una versione nuova ogni tre settimane e nessuna azienda riesce a starci dietro — cinque criteri per decidere in base a quello che ti serve, non a quello che è uscito
Luciano Cipriano
9/22/20268 min read
Ciao a tutti,
Ben arrivati su WikiLuc.
Quando si lavora su un sistema già in produzione spesso ci si trova davanti a questo interrogativo: "è uscito il nuovo, dobbiamo aggiornare?". E' una domanda a cui, negli ultimi due anni, quasi nessuno ha dato una risposta metodica: si aggiorna perché è uscito, oppure non si aggiorna finché qualcosa non si rompe.
Nessuna delle due è una decisione. Vale la pena costruirne una, perché il ritmo dei rilasci non rallenterà.
Di cosa parliamo oggi:
Quanto velocemente escono davvero le versioni nuove, con le date
Perché la performance dichiarata è il criterio sbagliato
Perché i benchmark pubblici non decidono, e cosa si usa al loro posto
Quanto costa realmente un cambio di modello
Come si organizza il lavoro per rendere la decisione un dato
Partiamo dai numeri.
Il ritmo, misurato
Prendiamo una sola famiglia di modelli e mettiamo le date in fila.
Gemini 3 Pro viene annunciato il 18 novembre 2025. Gemini 3 Flash arriva 39 giorni dopo, il 17 dicembre. Gemini 3.1 Pro in preview il 19 febbraio 2026, 64 giorni più tardi. Gemini 3.1 Flash-Lite in preview dopo 12 giorni, il 3 marzo, e in disponibilità generale il 8 maggio, dopo altri 66. Gemini 3.5 Flash viene annunciato all'I/O l'19 maggio, 11 giorni dopo. Il 24 giugno arriva l'uso del computer dentro 3.5 Flash. Il 21 luglio Gemini 3.6 Flash e 3.5 Flash-Lite raggiungono la disponibilità generale. Ad agosto compaiono Gemini 3.7 Flash, Gemini Omni 1.1 Flash e Gemini 3.5 Transcribe.
Gli intervalli reali stanno tra gli 11 e i 66 giorni. E questa è una famiglia sola: nello stesso periodo Anthropic ha portato in campo Opus 5 a fine luglio, oltre alle linee Mythos e Fable, e ogni altro fornitore ha la sua cadenza.
Ora mettiamoci accanto il tempo di un ciclo di validazione aziendale serio: definire i casi di prova, farli girare, confrontare gli esiti, verificare le regressioni, aggiornare la documentazione, passare la sicurezza. Difficilmente sotto le sei settimane, in un'organizzazione strutturata anche il doppio.
Il conto non torna, e non tornerà mai. Il divario tra la velocità di rilascio e la velocità di validazione è strutturale: non si chiude correndo di più. L'unica cosa che si può fare è smettere di trattare ogni rilascio come un evento che richiede una risposta.
Perché la performance dichiarata è il criterio sbagliato
Questo è il passaggio che secondo me conta più di tutti gli altri messi insieme.
Quando esce un modello nuovo, il materiale che lo accompagna parla di capacità: ragiona meglio, sbaglia meno, capisce più contesto. Sono affermazioni quasi sempre vere. Il problema è che descrivono un progresso medio su compiti generici, mentre quello che tu hai in produzione è un compito specifico, in un dominio specifico, con vincoli specifici.
Un esempio concreto. Se il tuo sistema estrae dati strutturati da fatture, il miglioramento che ti serve non è "ragiona meglio": è che rispetti lo schema JSON il 99,9% delle volte invece del 99,5%, perché ogni deviazione ti costa un intervento manuale. Un modello che ragiona molto meglio ma è marginalmente meno disciplinato sull'output strutturato è un peggioramento per te, per quanto sia un progresso per il settore.
Da qui il primo criterio, ed è una domanda sola: quale limite misurato del sistema attuale mi sta bloccando? Non "cosa potrei fare di più", ma quale vincolo concreto sto colpendo oggi. Le risposte utili sono poche e sono tutte numeriche.
La finestra di contesto non basta — devi spezzare i documenti e perdi coerenza.
La latenza è sopra la soglia che rende l'esperienza accettabile.
Il costo per compito non regge il modello economico ai volumi previsti.
Manca una modalità — immagini, audio, video — che ti serve davvero.
L'affidabilità su un compito specifico è sotto la soglia che rende sostenibile la revisione umana.
Se nessuna di queste è vera, non hai un motivo per aggiornare. Averlo scritto nero su bianco vale più di qualunque analisi comparativa, perché toglie la decisione dal terreno dell'entusiasmo e la porta su quello del bisogno.
Perché i benchmark pubblici non bastano per decidere
Il riflesso naturale, davanti a un rilascio, è guardare i punteggi. È un riflesso che va disinnescato per due ragioni distinte.
La prima è tecnica e si chiama contaminazione. Se le domande di un test pubblico sono finite, anche indirettamente, nei dati di addestramento, il punteggio misura in parte la memoria e non la capacità. È un problema noto e serio, tanto che il 27 agosto Google DeepMind ha annunciato il pilota della prima valutazione in doppio cieco su un modello di frontiera proprietario: usando un ambiente crittografato, il valutatore non vede i pesi del modello e chi possiede il modello non vede le domande del test. Il fatto stesso che serva costruire una scatola crittografica per fidarsi di un punteggio dice quanto poco ci si possa fidare dei punteggi normali.
La seconda ragione è più banale e più importante: quei test non misurano il tuo lavoro. Un punteggio alto su problemi di programmazione competitiva non dice nulla su quanto bene un modello classifichi le richieste dei tuoi clienti in italiano, con il tuo gergo aziendale.
Il sostituto esiste ed è alla portata di chiunque: un insieme di casi reali con la risposta attesa. Sessanta o cento esempi presi dal traffico vero, con l'esito corretto scritto da una persona che sa il mestiere. Costa uno o due giorni di lavoro una tantum, e diventa lo strumento con cui ogni rilascio successivo si valuta in mezz'ora invece che in tre settimane di discussioni. È la singola cosa che consiglierei di fare a chiunque abbia qualcosa di serio in produzione e non l'abbia ancora.
Un avvertimento: quell'insieme di casi va tenuto privato e non va incollato dentro strumenti che potrebbero conservarlo, altrimenti si ricrea in casa lo stesso problema di contaminazione.
Quanto costa davvero cambiare
L'errore di stima più comune è considerare il cambio di modello un'operazione di configurazione. Cambia una stringa, si riparte. Nella pratica il costo sta altrove, ed è composto da cinque voci che vale la pena elencare perché nessuna è visibile in anticipo.
I prompt sono tarati. Le istruzioni che funzionano bene con un modello producono comportamenti diversi con un altro: verbosità, tono, propensione a chiedere chiarimenti. Vanno riviste tutte, e non c'è modo di saperlo senza provarle.
Gli output strutturati cambiano ai margini. Un modello nuovo può rispettare lo schema in modo leggermente diverso nei casi limite — proprio quelli che il tuo codice gestisce con assunzioni implicite scritte mesi fa.
Le soglie vanno rifatte. Se hai un valore di confidenza sopra il quale il sistema decide da solo e sotto il quale passa a una persona, quel valore è calibrato sul modello attuale e non è trasferibile.
I test di regressione devono esistere. Se non ci sono, il costo del cambio include il costo di scriverli — che è un investimento buono, ma va contato.
La documentazione e la formazione. Chi usa il sistema ha imparato come si comporta. Un cambio di comportamento senza avviso genera segnalazioni che sembrano guasti e non lo sono.
La stima onesta, per un sistema in produzione con un minimo di complessità, sta tra i cinque e i quindici giorni-uomo. È un numero che va messo accanto al beneficio atteso prima di decidere, non scoperto dopo.
Serve invece sincronizzarsi sul ritiro dei modelli
C'è un caso in cui la decisione non è tua, ed è quello che le aziende scoprono sempre tardi: il modello che usi viene spento.
I preavvisi sono pubblicati e sono molto diversi tra loro. Anthropic dichiara almeno 60 giorni di preavviso per il ritiro di modelli rilasciati pubblicamente. OpenAI distingue per tipo: almeno sei mesi per i modelli in disponibilità generale, almeno tre per le varianti specializzate, e fino a due sole settimane per i modelli in preview. Sull'API Gemini il preavviso sugli alias di anteprima è di circa due settimane. Su Amazon Bedrock la politica è la più protettiva: almeno dodici mesi di disponibilità della piattaforma e almeno sei mesi di stato "legacy" prima del fine vita.
Due conseguenze pratiche. La prima: chi ha costruito su un modello in preview ha un orizzonte di due settimane, e quasi sempre non lo sa, perché la preview era più veloce o più economica al momento della scelta. La seconda: lo stesso modello ha date diverse su piattaforme diverse. Il calendario che conta è quello della piattaforma da cui lo consumi, non quello del laboratorio che l'ha addestrato.
La regola operativa che ne segue è semplice: tenere da qualche parte un elenco dei modelli in uso con la loro data di ritiro nota, e rivederlo una volta al trimestre. Dieci minuti, e toglie di mezzo l'intera categoria di emergenze evitabili.
Come organizzare il lavoro: due binari
Chiudo con la parte organizzativa, che è quella che rende tutto il resto praticabile.
Il primo binario è la produzione, con la versione bloccata in modo esplicito. Non l'alias "ultima versione", ma l'identificativo completo del modello, scritto nella configurazione. L'alias comodo è la ragione per cui alcuni sistemi cambiano comportamento di notte senza che nessuno abbia toccato niente.
Il secondo binario è un ambiente in ombra, dove il modello candidato riceve una copia del traffico reale e produce risposte che non vengono servite a nessuno, ma vengono registrate e confrontate. Non serve costruirlo per ogni rilascio: basta che esista e che si possa accendere quando un rilascio merita attenzione.
Con questi due binari la domanda "è uscito il nuovo, aggiorniamo?" smette di essere una discussione di opinioni e diventa una procedura: si accende il confronto sul proprio insieme di casi, si guardano gli scostamenti, si stima il costo di migrazione, e si decide con dei numeri in mano. Il tempo per arrivare alla risposta scende da settimane a giorni — che è l'unico modo per stare al passo con una cadenza di undici giorni senza inseguirla.
Le domande da portare in review
Qual è il vincolo misurato che il modello attuale non supera. Se non sai rispondere, la valutazione dell'aggiornamento può aspettare.
Su quali casi verifichi che il nuovo sia meglio, e chi ha scritto le risposte attese. Se la risposta è "i benchmark pubblici", non stai verificando il tuo lavoro.
Quando viene spento quello che usi oggi, sulla piattaforma da cui lo consumi. È una data, e o ce l'hai scritta o non ce l'hai.
Sono domande che oggi sembrano da manutenzione ordinaria. Man mano che i sistemi basati su modelli passano dal pilota al processo critico, saranno la differenza tra un parco applicativo governato e uno che si aggiorna per reazione — e chi si costruisce adesso l'insieme di casi e il registro delle scadenze avrà, tra un anno, un vantaggio che non si recupera in fretta.
Notizie da tenere d'occhio
La prima valutazione in doppio cieco di un modello di frontiera
Il 27 agosto Google DeepMind ha annunciato un pilota con Singapore AI Safety Institute, OpenMined, AVERI e MLCommons: un ambiente crittografato in cui il valutatore non vede i pesi e Google non vede i prompt del test.
Perché importa: è un tentativo tecnico di rendere credibili i punteggi pubblicati, e conferma che oggi non lo sono abbastanza.
Il 12 novembre Cursor perde i modelli OpenAI
Il 28 agosto OpenAI ha annunciato la fine della fornitura all'editor dopo l'acquisizione di Anysphere da parte di SpaceX.
Perché importa: è la stessa lezione di questo articolo applicata agli strumenti — un modello o un tool possono sparire dal tuo stack per ragioni che non ti riguardano.
Anthropic impegna 45 miliardi in capacità di calcolo
Il 26 agosto CNBC e TechCrunch riportano un accordo di sei anni con Nscale, con capacità operativa attesa a fine 2027 su chip Vera Rubin, che si somma agli impegni presi con Volta, AMD, SpaceX e Amazon nei mesi precedenti.
Perché importa: la disponibilità futura dei modelli dipende da infrastrutture che oggi non esistono ancora.
Una cosa da usare
🔧 Il calendario pubblico delle deprecazioni del tuo fornitore — Anthropic, OpenAI e Google pubblicano tutti le date di ritiro dei modelli. Aprirlo, cercare i modelli che hai in produzione e copiare le date in un foglio richiede dieci minuti a trimestre, ed è probabilmente il rapporto tra tempo speso e problemi evitati più alto di tutta la manutenzione di un sistema AI.
La cosa che mi sembra più utile in questa fase non è tenere il passo dei rilasci, che non è possibile per nessuna organizzazione normale, ma cambiare la domanda di partenza: non "quanto è più bravo il modello nuovo", ma "quale limite del mio sistema oggi mi costa qualcosa, e questo rilascio lo toglie". È una domanda che si può rispondere con dei dati propri in poche ore, e ha il pregio di funzionare identica tra sei mesi, quando i numeri di versione saranno altri e la logica sarà la stessa.
Grazie per aver letto questo articolo fammi sapere cosa ne pensi!
Ci vediamo presto qui su WikiLuc!
