C'è una bugia che il settore dell'Intelligenza Artificiale racconta volentieri ai clienti: "Una volta addestrato/configurato, il modello impara e migliora nel tempo". La realtà ingegneristica è l'esatto opposto. L'AI non migliora da sola. L'AI degrada.
Nel software tradizionale, se scrivi una funzione che somma due numeri (a + b), quella funzione restituirà sempre lo stesso risultato per dieci anni, a meno che non cambi l'hardware o il compilatore. È deterministica. L'AI Generativa, per sua natura probabilistica, è soggetta a un fenomeno che chiamiamo AI Drift (o Model Drift). I dati cambiano, il mondo cambia, le API dei provider cambiano sotto il cofano. E il tuo chatbot, che ieri era un genio, oggi inizia a rispondere cose senza senso, pur restituendo uno status code 200 OK.
In Weirdoo abbiamo imparato questa lezione nel modo più duro possibile: in produzione. In questo articolo ti racconterò perché la manutenzione di un sistema AI costa spesso più del suo sviluppo iniziale e perché, senza una pipeline di Observability e Continuous Evaluation, il tuo progetto è destinato a fallire entro sei mesi.
La prima volta che abbiamo messo in produzione un sistema basato sulle API di OpenAI, qualche anno fa ormai (all'epoca usavamo GPT-3.5), tutto sembrava perfetto. I test in locale erano verdi. La demo al cliente era stata un successo. Nessuno, all'epoca, parlava seriamente di Guardrails o di Observability. Ci fidavamo del modello.
Poi è arrivato il feedback dalla produzione. E non era il feedback che ci aspettavamo. Il sistema doveva consigliare prodotti basandosi sulle giacenze di magazzino. Passavamo l'inventario nel prompt e il modello rispondeva. Un giorno, l'API esterna (il gestionale del cliente) che ci forniva i dati di magazzino si è rotta silenziosamente. Al nostro prompt arrivava un array vuoto [] invece della lista prodotti.
Per un software classico, questo è un errore gestibile (if empty -> error). Per l'LLM, invece, era un invito a improvvisare. Non avendo dati sul magazzino, il modello ha iniziato ad allucinare. Ha inventato prodotti che non esistevano, prezzi plausibili ma falsi, e disponibilità immaginarie. Per l'utente finale, il sistema funzionava. Per il business, era un disastro.
Da quel giorno abbiamo capito una regola fondamentale: mai fidarsi dell'input, mai fidarsi dell'output. Senza un sistema di controllo (Guardrails) che verifichi l'integrità dei dati prima che tocchino il prompt, e un sistema di verifica dopo, avremmo potuto non accorgercene per settimane. Perché l'AI non crasha. L'AI mente con sicurezza.
Oggi l'architettura standard per l'AI aziendale è il RAG (Retrieval Augmented Generation). Prendi i documenti aziendali, li vettorizzi, e li dai in pasto al modello. Tutti si concentrano su come inserire i dati. Pochissimi si preoccupano di come toglierli.
Il problema dei "Dati Zombie" è reale. Se un cliente aggiorna un listino prezzi o modifica una policy di reso, cosa succede nel tuo Vector Database? Spesso, il vecchio "chunk" (frammento di testo) rimane lì, affiancato a quello nuovo. Risultato: il tuo chatbot GPT based trova due informazioni contraddittorie e, nella sua confusione statistica, le mischia o sceglie quella sbagliata.
In Weirdoo abbiamo dovuto implementare pipeline di Invalidation granulari. Non basta "aggiornare ogni tanto". Bisogna definire delle priorità di business:
Senza una strategia di invalidazione, il tuo RAG inizia ad essere un problema dopo poche settimane dalla messa in produzione.
Nel monitoraggio classico guardiamo CPU, RAM e Latenza. Ma come si misura la "Qualità" di una conversazione? Come fai a sapere se il tono di voce è diventato troppo aggressivo o se la risposta è tecnicamente corretta ma inutile?
Non puoi assumere 100 persone per leggere tutte le chat. In Weirdoo utilizziamo un approccio a tre livelli:
Se il punteggio scende sotto una certa soglia, la pipeline di CI/CD si blocca. Non andiamo in produzione. Questo trasforma la qualità dell'output da un'opinione soggettiva a una metrica oggettiva che possiamo tracciare nel tempo.
Parliamo di costi, ma con onestà. Il debito tecnico esiste in ogni progetto software. Ma nell'AI c'è una minaccia esistenziale diversa: la volatilità delle API.
Se usi una libreria JavaScript, puoi decidere di non aggiornarla per due anni e il sito continuerà a funzionare. Con i Large Language Models, non hai questo lusso. OpenAI, Anthropic o Google possono decidere di deprecare un modello (es. gpt-3.5-turbo-0613) con un preavviso di pochi mesi. Quando quel modello viene spento, il tuo sistema smette di funzionare. Punto.
E non basta cambiare una stringa nel codice da v1 a v2. Un prompt che funzionava perfettamente sul modello vecchio potrebbe rompersi completamente sul modello nuovo (che magari è più "sicuro", più verboso, o formatta il JSON diversamente). Questo costringe a cicli di re-testing e re-engineering forzati. La manutenzione nell'AI non è solo "tenere le luci accese", è una corsa continua per adattarsi al terreno che ti frana sotto i piedi.
C'è un'idea affascinante che circola spesso nei board aziendali: "Automatizziamo il ri-addestramento. Ogni notte prendiamo le interazioni migliori, le usiamo per fare fine-tuning del modello, e lui diventerà sempre più intelligente in autonomia."
Sulla carta, è il Santo Graal. In pratica, è una delle sfide più ardue dell'MLOps moderno. Senza una pipeline di validazione rigorosa, il Continuous Fine-Tuning porta quasi inevitabilmente a due fenomeni distruttivi: il Catastrophic Forgetting e il Model Collapse.
Le reti neurali non funzionano come un database SQL dove aggiungi righe (conoscenza) senza intaccare quelle esistenti. Quando fai fine-tuning, stai modificando i pesi (weights) del modello per minimizzare l'errore sui nuovi dati. Se il nuovo dataset non è perfettamente bilanciato con il vecchio, il modello tende a sovrascrivere le connessioni neurali che codificavano la logica precedente per far spazio alla nuova.
Risultato? Il chatbot impara perfettamente le specifiche del nuovo prodotto lanciato ieri, ma improvvisamente "dimentica" come salutare l'utente, come gestire le negazioni o perde la capacità di ragionamento logico di base che aveva il modello foundation.
Se automatizziamo il training basandoci sui log delle chat passate, introduciamo un rischio statistico sottile. Se il modello commette un piccolo errore (es. un'allucinazione plausibile) e l'utente non lo corregge esplicitamente, quell'errore finisce nel dataset di training della notte successiva come "verità". Il modello viene ri-addestrato sui suoi stessi output (o su dati sintetici generati da sé stesso).
Iterazione dopo iterazione, la varianza del modello crolla e gli errori si cristallizzano. Il modello smette di rappresentare la distribuzione reale dei dati e inizia a convergere verso una rappresentazione distorta e semplificata.
In Weirdoo non sconsigliamo il fine-tuning, ma lo trattiamo come un deploy di codice critico, non come una routine automatica.
L'apprendimento continuo è possibile, ma richiede un'architettura di controllo che è spesso più costosa e complessa del modello stesso.
C'è una differenza fondamentale tra il software tradizionale e l'AI Generativa. Se oggi scrivi un codice PHP fatto male, tra dieci anni quel codice farà ancora schifo, ma funzionerà esattamente allo stesso modo. È statico. Un sistema AI, invece, è soggetto a un'entropia accelerata.
I dati su cui si basa invecchiano. Le API su cui poggia cambiano. Il linguaggio degli utenti evolve. E il modello stesso, se sottoposto a loop di feedback non controllati, inizia a collassare su se stesso.
Lanciare un progetto AI ("Day 1") è la parte facile. È eccitante, c'è l'hype, c'è il budget. Ma è nel "Day 2", quando l'hype scende e iniziano ad arrivare i casi limite, le allucinazioni sui prezzi e i drift dei provider che si vede la differenza tra una demo e un prodotto enterprise.
In Weirdoo abbiamo smesso di vendere l'AI come una "scatola magica" che risolve i problemi da sola. L'AI è un componente infrastrutturale potente ma instabile, che richiede un'impalcatura di controllo (CI/CD, Evaluation, Guardrails) spesso più costosa e complessa del modello stesso.
Se la tua roadmap non prevede budget per l'Observability e per la Manutenzione Evolutiva, il tuo progetto ha già una data di scadenza. Non costruite cattedrali nel deserto. Costruite sistemi che sapete di poter governare anche quando la tempesta (o il prossimo update di OpenAI) arriverà.
