La tesi in una frase: cambiare modello di IA è la prima cosa che si fa quando qualcosa non funziona e l’ultima che si dovrebbe fare. Esce un modello nuovo, qualcuno legge che è più sveglio, e la conversazione del team passa da «perché questo non rende?» a «passiamo all’ultimo?». È la reazione più comoda del mondo —non obbliga a guardarsi dentro— e quasi sempre è quella sbagliata. Il collo di bottiglia raramente è il modello. Sono il processo che nessuno ha definito bene e i dati che nessuno ha pulito.
Cambiare modello di IA è curare il sintomo, non la malattia
Quando un progetto di IA delude, ci sono due colpevoli possibili: il motore o tutto ciò che lo circonda. Il motore è il modello; ciò che lo circonda è come gli arriva l’informazione, cosa gli si chiede, con quali dati lavora e cosa si fa con la sua risposta. L’intera industria ti spinge a guardare il motore, perché è ciò che si vende, si confronta e finisce nei titoli. Ma nella maggior parte dei progetti che si incagliano, il motore non è il problema: il problema è che gli stai chiedendo di indovinare su un processo che nemmeno tu hai chiaro, alimentato con dati che si contraddicono a vicenda.
Pensaci con un’analogia noiosa ma esatta: se la tua auto non parte perché il serbatoio è vuoto, cambiare il motore con uno più potente non la sposta di un metro. Cambiare modello quando il freno è il processo è esattamente questo —un lavoro costoso che non tocca la causa—. E intanto il team si convince di «averle provate tutte», quando in realtà non ha toccato l’unica cosa che contava.
Il vero collo di bottiglia: processo mal definito e dati sporchi
Un modello di IA è buono tanto quanto la chiarezza del lavoro che gli affidi e la qualità di ciò che gli dai per lavorare. Quando fallisce, quasi sempre fallisce per una di queste due, non per mancanza di intelligenza bruta:
Processo mal definito
Se tu non sai spiegare il processo in passi chiari, nemmeno l’IA lo inventerà per te. Molti «casi d’uso di IA» sono in realtà processi che non sono mai stati documentati: ognuno li faceva a modo suo, con eccezioni in testa e criteri che nessuno ha mai scritto. Chiedi all’IA di automatizzare quel caos e, logicamente, produce caos con una grammatica migliore. Un modello più potente non ti darà la definizione del processo che a te manca. Come spezzettare un compito in istruzioni che un’IA può seguire davvero è metà del lavoro, e lo affrontiamo in automatizzare i compiti con ChatGPT.
Dati sporchi
L’altra metà è di cosa si alimenta. Se l’IA risponde a partire da informazione datata, duplicata, contraddittoria o sparsa in dieci posti che non si parlano, la risposta sarà scadente per quanto il modello sia eccellente. Spazzatura entra, spazzatura esce —questo non lo sistema nessun release—. Questo freno è così comune che gli dedichiamo un articolo intero: i dati disordinati sono il vero freno dell’IA. E se il tuo caso esige che il modello conosca il tuo business, il rimedio quasi mai è cambiare modello: è dargli accesso ordinato alla tua informazione, cosa che scomponiamo in addestrare l’agente con la tua informazione.
Perché cambiare modello è così allettante (e così inutile)
Se il problema quasi sempre è il processo, perché la reazione di default è cambiare modello? Perché è facile. Cambiare modello è una decisione di un pomeriggio: tocchi una configurazione, punti a un altro endpoint e via. Sistemare il processo e i dati è una decisione di settimane, obbliga a parlare con chi fa il lavoro, a documentare ciò che nessuno ha documentato e a pulire ciò che nessuno vuole pulire. Davanti a questa scelta, l’essere umano preferisce quella che sembra progresso senza essere scomoda.
- Dà la sensazione di agire senza agire. Migrare modello sembra produttivo —c’è qualcosa da toccare, un prima e un dopo— anche se il risultato non si muove. È teatro del progresso.
- Il marketing ti dà l’alibi. Ogni release arriva con benchmark che promettono un salto. È facilissimo convincerti che È QUESTO quello che mancava, invece di accettare che il difetto è a casa tua.
- Guardarsi dentro è scomodo. Ammettere che il tuo processo non era definito o che i tuoi dati sono un disastro punta il dito su decisioni tue. Cambiare fornitore esternalizza la colpa: è stato il modello, non noi.
E c’è un costo che quasi nessuno mette in conto: ogni migrazione di modello non è gratis. Riscrivi i prompt, rivalidi i risultati, aggiusti l’integrazione e riprovi tutto. Se lo fai inseguendo un problema che non era nel modello, spendi quello sforzo per finire nello stesso posto —con il processo altrettanto rotto, ma con un modello diverso a cui dare la colpa la prossima volta—.
Quando cambiare modello è davvero la decisione giusta
Questo non è «non cambiare mai modello». A volte il motore è davvero il limite, e allora cambiare è la cosa sensata. La differenza è che lo fai dopo aver escluso il resto, non prima di guardarlo. Questi sono i segnali che il modello è davvero il tuo tetto:
- Un umano con le tue stesse istruzioni e dati lo fa bene, e l’IA no. Se il compito è ben definito, i dati sono puliti e una persona con quella stessa informazione ci azzecca, ma il modello fallisce in un tipo di ragionamento concreto, lì sì il motore è il limite.
- Sbatti contro un limite tecnico reale. Finestra di contesto insufficiente per il tuo caso, lingua che il modello gestisce male, latenza o costo per token che non tornano al tuo volume: sono limiti del motore, non del processo.
- L’hai provato a parità di condizioni. Hai cambiato solo il modello, con lo stesso processo e gli stessi dati già ordinati, e il nuovo vince in modo misurabile e ripetibile —non in una demo fortunata—.
Nota l’ordine: prima sistemi processo e dati, e solo allora, con quella base pulita, confrontare i modelli diventa una decisione sensata invece di una fuga in avanti. Su come costruire quella base per poter cambiare motore senza dolore —disaccoppiando l’applicazione dal fornitore— abbiamo scritto in IA open source vs API chiusa.
Cosa fare lunedì invece di cambiare modello
- Scrivi il processo a mano, in passi. Se non riesci a spiegarlo in una pagina chiara, l’IA non salverà ciò che tu non hai definito. Quel documento è il rimedio, non il modello.
- Guarda di quali dati si nutre l’IA. Traccia l’informazione che usa fino alla sua origine e verifica se è aggiornata, è unica e non si contraddice. Ordina quello prima di toccare altro.
- Fai la prova del dipendente nuovo. Un umano brillante con quelle istruzioni e quei dati farebbe bene il compito? Se no, sistema le istruzioni e i dati. Se sì e l’IA fallisce, allora —e solo allora— confronta i modelli.
Se facendo questo scopri che il freno non era il modello ma il processo —che è la cosa più probabile—, quello è esattamente il lavoro che facciamo: definire il processo, ordinare i dati e lasciare l’automazione a funzionare sopra, con automazione delle operazioni. Il modello è la parte facile; che il lavoro sia fatto bene, la difficile.