Architetture agnostiche: cambiare modello senza ripartire da zero
OpenAI spegne GPT-4 e o1 il 23 ottobre: dove si incastra un progetto AI quando cambia il fornitore, e come progettarlo per il cambio
Luciano Cipriano
10/22/20266 min read
Ciao a tutti,
Ben arrivati su WikiLuc.
Ci si trova spesso davanti a progetti AI che funzionano bene finché il modello resta quello su cui sono stati costruiti. Il giorno in cui il fornitore lo ritira, ne cambia il prezzo o le regole di accesso, si scopre quanto il progetto fosse legato a lui.
Il 23 ottobre OpenAI spegnerà una serie di modelli storici, da GPT-4 a o1, o3-mini e o4-mini, insieme alle loro versioni fine-tuned: lo indica la pagina ufficiale delle deprecazioni, dove il ritiro era annunciato dal 22 aprile. Dieci giorni prima, il 13 ottobre, Stacklok ha pubblicato un sondaggio su 520 responsabili tecnici che dice dove sta davvero il vincolo, e non è dove lo si cerca di solito.
Di cosa parliamo oggi:
dove si incastra davvero un progetto AI quando cambia il modello;
cosa raccontano i numeri sulle migrazioni reali;
perché dati e casi d'uso sono il patrimonio da governare;
come si progetta un'architettura che regge il cambio;
quanto costa restare agnostici, e dove conviene fermarsi.
Partiamo dai fatti.
Il fornitore cambia le regole mentre ci si lavora sopra
Il ritiro di un modello è il caso più visibile, ma non l'unico. Dal 31 agosto Anthropic applica ai nuovi account API il cosiddetto preserved thinking: su Claude Fable 5.1 e Opus 5.5 non si può più modificare il contesto precedente della conversazione. È una difesa contro chi usa le risposte per addestrare modelli concorrenti, e la stessa Anthropic, nel post sulle difese anti-distillazione, riconosce che alcuni sviluppatori hanno dovuto aggiornare le integrazioni.
Anche il prezzo si muove in modi meno ovvi del listino. Claude Haiku 5.5 usa circa il 30% di token in più per lo stesso testo: nell'esempio della guida di migrazione analizzata da LLM Stats, un prompt che supera la soglia dei 100.000 token fa scendere il risparmio dal 90% al 35%. E Gemini 4 Argon, appena aperto a tutti, raddoppia il prezzo dal 1° dicembre.
Nessuna di queste scelte è sbagliata dal punto di vista del fornitore. Sono però decisioni che entrano nell'architettura di chi costruisce sopra quei modelli, senza che sia stato lui a prenderle.
Il vincolo si è spostato negli agenti
Il sondaggio di Stacklok, condotto a settembre da Dimensional Research su aziende nordamericane con più di 500 dipendenti, parte da un dato che smentisce l'immagine del fornitore unico: solo l'8% usa un solo provider di modelli, circa la metà ne usa due o tre, il 24% cinque o più.
Il punto interessante è cosa i rispondenti considerano difficile da spostare. Non il prompt, che si riscrive in fretta. Al primo posto ci sono le integrazioni con i sistemi interni e i server MCP (53%), poi i flussi multi-step degli agenti (52%), poi la possibilità di esportare stato, memoria e test degli agenti (37%, che nei servizi finanziari sale al 52%).
In altre parole, il multi-modello si è fatto a livello di singola chiamata, ma lo strato che ci sta intorno, con autorizzazioni, regole, log e casi limite accumulati nel tempo, è stato costruito sul primo fornitore scelto. È lì che il cambio fa male.
Come si migra davvero
Uno studio pubblicato su arXiv il 25 settembre da Hyungjin Lukas Kim, della Myongji University di Seul, ha osservato le migrazioni reali: 5.139 modifiche al codice, in oltre 4.500 progetti open source su GitHub, legate al ritiro di un modello di OpenAI, Anthropic o Google (arXiv).
I numeri raccontano un comportamento reattivo:
l'82% delle migrazioni arriva dopo lo spegnimento del modello, non prima;
nel 94% dei casi il nome del modello era scritto direttamente nel codice;
solo l'8% coglie l'occasione per cambiare fornitore, mentre circa sette su dieci restano con lo stesso e passano al successore indicato;
appena il 4% aggiunge uno strato di astrazione, e un altro 4% cita una suite di test.
Il costo cresce con la profondità dell'integrazione. Per un'app che usa solo prompt la modifica mediana è di 6 righe; per un agente con strumenti, 63; per un sistema RAG, 155; per un'app con un modello fine-tuned, 693, perché il modello addestrato non vale più sulla nuova base.
Dati e casi d'uso: il patrimonio da governare
Se il modello è un componente che prima o poi si sostituisce, il valore di un progetto AI sta altrove: nella base dati su cui lavora e nei casi d'uso che serve. Sono le due cose che restano, ed è lì che serve la governance più attenta.
Sulla base dati il punto è concreto. Documenti, regole di business e memoria degli agenti vanno tenuti in un formato proprio, leggibile indipendentemente dal modello. Gli embedding, cioè la rappresentazione numerica dei documenti usata per la ricerca, sono legati al modello che li ha generati: cambiarlo significa ricalcolarli tutti, e chi lo scopre il giorno della migrazione si trova a reindicizzare l'intera base sotto scadenza.
Sui casi d'uso vale lo stesso principio. Per ciascuno serve una definizione scritta di cosa vuol dire "funziona": un insieme di domande e risposte attese, con le metriche che contano per quel processo. È il set di test di riferimento, e secondo lo studio di arXiv solo il 4% delle migrazioni ne menziona uno. Senza, cambiare modello è un salto nel buio; con, diventa una verifica che si ripete in un pomeriggio.
È questo che rende l'architettura elastica: la si può far evolvere un pezzo alla volta, perché in ogni momento si sa che cosa deve continuare a fare.
Un'architettura che regge il cambio
In pratica, le scelte che fanno la differenza si prendono il primo giorno e costano poco:
Il modello in configurazione. Il nome del modello sta in un file di configurazione e non nel codice, e si usano le versioni datate invece degli alias, che possono cambiare comportamento senza preavviso.
Un punto unico di accesso. Le chiamate ai modelli passano da un solo strato, un gateway o un modulo interno, che gestisce credenziali, log e un fornitore di riserva se il primo non risponde.
Gli strumenti dietro uno standard. Le integrazioni con i sistemi interni passano da server MCP, che più fornitori sanno usare, invece che da funzioni scritte per l'API di uno solo.
Stato e memoria in casa. La memoria degli agenti e lo storico delle conversazioni stanno in un archivio proprio ed esportabile, non solo nelle funzioni di memoria della piattaforma.
I test prima del cambio. Il set di test di riferimento si rilancia su ogni modello candidato, e la data di ritiro dei modelli in uso si segue come una scadenza contrattuale.
Alcuni punti di attenzione
Restare agnostici ha un costo. Ogni fornitore offre funzioni proprie, come la cache dei prompt, il ragionamento esteso o la memoria gestita, e uno strato di astrazione tende a usare solo ciò che hanno tutti. Lo strato stesso va poi mantenuto: un gateway risolve la compatibilità delle chiamate, ma secondo una stima di settore copre circa un quinto del costo reale di un cambio, e il resto è lavoro di verifica.
Sui dati serve una cautela esplicita. Stacklok vende una piattaforma per gestire i server MCP, cioè proprio lo strato che il suo sondaggio indica come critico: il dato è utile, ma viene da una parte interessata. Lo studio di arXiv è un preprint non ancora revisionato, osserva solo progetti open source e solo le migrazioni dichiarate nei messaggi di commit; le aziende con processi maturi potrebbero comportarsi meglio, ma non ho elementi per dirlo.
Per questo non renderei agnostico tutto. Conviene farlo dove il caso d'uso è destinato a durare anni, e accettare il legame con un fornitore dove serve una sua funzione specifica, sapendo quanto costerebbe uscirne.
Su cosa focalizzarsi
Per ognuno dei casi d'uso in produzione esiste un set di test che dica, in modo ripetibile, se un modello nuovo fa ancora il lavoro?
Dove stanno oggi la memoria degli agenti, le regole e gli embedding, e chi potrebbe esportarli domani mattina?
Quali modelli in uso hanno una data di ritiro nei prossimi sei mesi, e chi la sta seguendo?
Sono domande che oggi possono sembrare da specialisti. Nei prossimi due o tre anni, con modelli che si rinnovano ogni pochi mesi e fornitori che cambiano prezzi e regole d'accesso, diventeranno il modo per distinguere un progetto AI che evolve da uno che va ricostruito a ogni cambio.
Una cosa da leggere
🔧 "When the Model Retires", lo studio sulle migrazioni dei modelli — È il lavoro più concreto che ho trovato sul tema, perché guarda cosa succede davvero nel codice quando un modello viene spento, invece di dire cosa bisognerebbe fare. Le tabelle per tipo di applicazione valgono da sole la lettura, e la parte sui guasti silenziosi, i casi in cui l'errore resta nascosto per settimane, è un buon promemoria per chi gestisce sistemi in produzione. Lo trovate su arXiv.
L'AI dei prossimi anni userà modelli che oggi non esistono ancora. Progettare pensando al cambio vuol dire decidere fin da subito cosa appartiene all'organizzazione, i dati e i casi d'uso, e trattare il resto come un componente che si potrà sostituire senza rifare il progetto.
Grazie per aver letto questo articolo fammi sapere cosa ne pensi!
Ci vediamo presto qui su WikiLuc!
