Il 27 agosto Google ha portato in general availability Gemini Omni 1.1 Flash, il suo modello di generazione video, con l'ID stabile gemini-omni-1.1-flash. Nella stessa mossa, il vecchio endpoint gemini-omni-flash-preview è stato messo in deprecazione per il 30 settembre. Fate il conto: circa trenta giorni per migrare, ritestare e rimettere in produzione. Non uso quel modello — la preview del taglio di Miraviso lavora su immagini, non su video — ma quel pattern è esattamente il rischio con cui convive chiunque abbia messo un modello hosted dentro un prodotto. E nel mio caso c'è una complicazione in più che vale la pena raccontare: un'architettura privacy-first ti toglie proprio lo strumento che vorresti usare per gestire la migrazione.
Il pattern: la GA è una buona notizia con una scadenza dentro
La sequenza è sempre la stessa e ormai la conosciamo: un modello esce come preview, tu lo integri perché è l'unico modo di avere quella capacità, il prodotto inizia a dipenderne, e un giorno arriva la GA — che è una buona notizia — insieme alla data di spegnimento della preview, che è una scadenza sul tuo calendario decisa da qualcun altro. Nel caso di Omni ci sono anche i dettagli tipici di queste transizioni: un ID di canale separato su Vertex AI (gemini-omni-1.1-flash-preview, che non è l'ID stabile della Gemini API, nonostante il nome quasi identico), controlli nuovi che la preview non aveva, e — stando ai resoconti di terze parti che ho letto, da verificare sui listini ufficiali — un prezzo GA non ancora pubblicato chiaramente al momento dell'annuncio. Migrare non è cambiare una stringa: è ritestare qualità, latenza e costi con i tuoi input, perché le release notes non lo faranno per te.
Trenta giorni sono pochi se la migrazione la scopri dalla mail di deprecazione. Sono comodi se il giorno della mail devi solo eseguire una procedura che esiste già. Tutta la differenza sta lì.
Il mio caso: metà prodotto è immune, metà no
Miraviso ha due percorsi tecnici dichiaratamente diversi, e questa storia li illumina bene. La prova colore gira interamente sul tablet del salone, con MediaPipe on-device: il video non lascia mai il dispositivo. Quel percorso è strutturalmente immune alle deprecazioni di endpoint — il modello sta nell'app, nessuno può spegnermelo da remoto. È un vantaggio dell'on-device di cui si parla poco: non è solo privacy e latenza, è anche indipendenza dal calendario di rilascio altrui.
L'anteprima del taglio invece è generata su server in UE, con Gemini su Vertex AI, previo consenso della cliente. Lì la dipendenza c'è, ed è il prezzo di una capacità che on-device oggi non ottieni. Quel percorso vive sul calendario di Google, e va progettato sapendolo.
La complicazione: non puoi fare regression test su dati che non conservi
Il modo standard di affrontare un cambio di modello è avere un corpus di regressione: prendi un campione di input reali di produzione, li rigiochi sul modello nuovo, confronti gli output. Ecco, io non posso. Per scelta, non per caso: le immagini dell'anteprima non vengono mai scritte su disco. Passano, vengono elaborate, tornano al tablet, fine. È una delle promesse su cui il prodotto sta in piedi, e non è negoziabile nemmeno quando sarebbe comoda.
La conseguenza è che il corpus di test va costruito fuori dal traffico di produzione, e in anticipo. In pratica significa tre cose:
- Un golden set esplicito e consensato: immagini raccolte apposta per il testing — le tue, di volontari che hanno firmato per quello scopo specifico, o di dataset con licenza adatta — che coprano i casi che contano davvero: tipi di capelli, incarnati, illuminazioni da salone vero, inquadrature storte. Non è un ripiego rispetto ai dati di produzione: è l'unico corpus che hai, quindi la sua qualità è il tetto della qualità dei tuoi test.
- Il modello dietro un confine netto: un punto solo del codice che sa quale modello viene chiamato e come. Se il nome dell'endpoint compare in più file, in variabili d'ambiente sparse o dentro template di job, il primo passo della migrazione — trovare tutte le occorrenze — diventa già un'attività da pomeriggio intero.
- Una valutazione che non richieda gli originali: se il confronto vecchio/nuovo lo fai a occhio sul golden set, bene; ma i criteri — cosa rende un'anteprima "accettabile" — vanno scritti prima, perché a migrazione in corso il giudizio estetico sotto pressione è il peggiore che avrete mai.
La scadenza è il prodotto che funziona
C'è una lettura pigra di queste notizie: "le big tech ti spengono le API, che disastro". Non la condivido. Un fornitore che porta un modello in GA e spegne la preview sta facendo manutenzione seria del proprio catalogo; l'alternativa — preview eterne che nessuno promette di mantenere — è peggio. La deprecazione non è il problema. Il problema è arrivarci senza un golden set, senza un confine attorno al modello e con l'ID dell'endpoint copiato in quattro posti.
La regola che mi sono dato è banale da enunciare: ogni capacità comprata da un modello hosted deve avere, dal primo giorno, la risposta alla domanda "come lo sostituisco?". Non un piano dettagliato — una risposta. Se la risposta è "non lo so", quella non è una dipendenza, è un'ipoteca. E come per i dati che finiscono nei log senza che nessuno l'abbia deciso, il momento giusto per pensarci è mentre l'architettura è ancora fresca, non quando arriva la mail con la data dentro.