La domanda non è più se convenga usare l’intelligenza artificiale, ma quale tipo di modello si adatta a ciascun problema. Negli ultimi due anni ho visto team tecnici spendere budget in API di modelli generativi per attività in cui un classificatore addestrato su misura sarebbe costato una frazione ed sarebbe stato più prevedibile. E anche il contrario: cercare di risolvere con regole e alberi decisionali un problema di estrazione di informazioni in linguaggio naturale che un LLM risolve in un pomeriggio di lavoro. Questo confronto è pensato per chi deve decidere tra le due opzioni con budget e scadenze reali.
Cosa separa davvero un LLM da un modello tradizionale
Un modello tradizionale (regressione logistica, random forest, gradient boosting, SVM, reti convoluzionali specifiche) viene addestrato per un compito concreto con un insieme di dati etichettati e produce output limitati: una classe, un numero, una probabilità. Un LLM è un modello linguistico preaddestrato su corpus massicci che predice il token successivo e, da lì, generalizza a compiti per i quali non è stato esplicitamente messo a punto.
La differenza pratica più importante non è l’architettura, ma il contratto d’uso. Con un modello classico sai esattamente quale input si aspetta e quale intervallo di output produce. Con un LLM l’input è testo libero e l’output è testo libero, il che sposta lo sforzo di ingegneria dall’addestramento verso la progettazione dei prompt, la validazione degli output e la valutazione continua.
Costo: non è solo il prezzo per token
Il costo di un LLM si misura per token di input e output, e cresce con l’uso. Quello di un modello tradizionale si concentra nella fase di etichettatura e addestramento, e poi l’inferenza è economica e locale. In un caso reale di classificazione di ticket di supporto in cinque categorie, con decine di migliaia di ticket al mese, l’inferenza di un modello piccolo messo a punto costa centesimi ogni mille richieste su infrastruttura propria, mentre chiamare un LLM grande per ogni ticket moltiplica la spesa e aggiunge latenza di rete. Se il volume è alto e il compito è stabile, il modello classico di solito vince sul costo totale.
Dati: il collo di bottiglia cambia posizione
Un modello tradizionale richiede dati etichettati di qualità. Se non li hai, il progetto si blocca. Un LLM permette di partire senza etichette, ma hai bisogno di esempi di valutazione per sapere se azzecca. In pratica, molti team iniziano con un LLM per prototipare, generano etichette con esso e poi addestrano un modello classico con quelle etichette riviste da esseri umani. Questa strategia di distillazione funziona bene quando il dominio è circoscritto; fallisce quando le classi sono ambigue o il linguaggio è molto variabile.
Scenari in cui ciascuna opzione vince
Quando un modello tradizionale è la scelta giusta
- Dati tabellari strutturati: scoring di rischio, previsione di churn, rilevamento di frodi con variabili numeriche e categoriche. I modelli di gradient boosting restano un riferimento in questi casi secondo la documentazione delle principali librerie del settore.
- Requisiti rigorosi di latenza: se hai bisogno di risposte in millisecondi senza dipendere da un’API esterna, un modello piccolo in locale è più affidabile.
- Auditabilità normativa: in settori con l’obbligo di spiegare le decisioni, un modello con importanza delle variabili documentata è più facile da difendere rispetto all’output di un LLM.
- Compiti ripetitivi e ben definiti: classificazione di immagini di prodotto, rilevamento di anomalie in serie temporali, etichettatura di sentiment con un dominio molto specifico.
Quando l’LLM apporta qualcosa che il modello classico non può
- Estrazione di informazioni da testo non strutturato: convertire email, contratti o report in campi strutturati senza definire in anticipo uno schema rigido.
- Compiti con istruzioni variabili: riassumere con un tono diverso, riformattare output o adattare risposte a un contesto che cambia senza riaddestrare.
- Generazione e trasformazione di contenuti: scrittura assistita, traduzione con sfumature, riscrittura.
- Prototipazione rapida: validare se un caso d’uso ha valore prima di investire in dati etichettati.
L’errore che vedo ripetersi: trattare l’LLM come un database
Un pattern che compare continuamente è chiedere al modello di ricordare informazioni di business (prezzi, politiche, catalogo) e confidare che le restituisca correttamente. Non lo fa in modo affidabile: allucina dati plausibili ma falsi. La soluzione non è cambiare modello, ma aggiungere recupero di informazioni (RAG) con una fonte di verità consultabile. E anche così, la validazione della risposta finale resta necessaria per i dati sensibili.
Un altro errore frequente: valutare un LLM con dieci esempi manuali e considerarlo buono. Senza un insieme di valutazione rappresentativo e ripetibile, non c’è modo di rilevare regressioni quando cambi versione del modello o modifichi il prompt. Secondo la documentazione dei principali fornitori, le versioni vengono aggiornate di frequente e il comportamento può variare senza un avviso chiaro.
Confronto pratico per criteri di decisione
| Criterio | Modello tradizionale | LLM |
|---|---|---|
| Dati necessari per iniziare | Etichettati e rappresentativi | Nessuno per prototipare; esempi per valutare |
| Costo di inferenza | Basso e prevedibile | Variabile in base ai token e al fornitore |
| Latenza | Molto bassa in locale | Dipende dalla rete e dalla dimensione del modello |
| Spiegabilità | Alta con le tecniche adeguate | Limitata; la catena di ragionamento non è sempre affidabile |
| Adattamento a nuovi compiti | Richiede riaddestramento | Cambiare le istruzioni di solito basta |
| Robustezza con input insoliti | Degrada in modo prevedibile | Può inventare o divagare |
Architetture ibride: ciò che di solito funziona davvero
Nella maggior parte dei progetti maturi la risposta non è scegliere uno dei due, ma combinarli. Un pattern abituale: un modello classico filtra e classifica il grosso del volume (ad esempio, separare richieste urgenti da quelle informative), e solo i casi ambigui o complessi passano a un LLM che redige o estrae informazioni. Questo riduce i costi, mantiene la latenza sotto controllo e riserva la capacità del modello generativo a dove apporta valore.
Un altro pattern: usare l’LLM per generare dati di addestramento sintetici o per etichettare su larga scala, e poi addestrare un modello classico con revisione umana. Funziona bene in domini chiusi; conviene rivedere un campione per rilevare bias ereditati dall’etichettatura automatica.
Limitazioni che conviene assumere prima di iniziare
Nessuna delle due opzioni risolve problemi di dati mal definiti. Se le etichette sono incoerenti, il modello classico apprende l’incoerenza e l’LLM la riproduce con maggiore sicurezza. Non c’è nemmeno garanzia di precisione al cento per cento in nessuno dei due casi: qualsiasi sistema in produzione necessita di monitoraggio, soglie di confidenza e un percorso di escalation alla revisione umana.
Gli LLM hanno inoltre limiti di contesto, costo crescente con la lunghezza dell’input e dipendenza da fornitori esterni se non vengono distribuiti in locale. I modelli tradizionali, dal canto loro, non generalizzano al di fuori della distribuzione con cui sono stati addestrati: un cambiamento nel formato dei dati di input può degradare le prestazioni senza che scatti alcun allarme.
Come decidere in pratica
Una sequenza che di solito consiglio: prima definire la metrica di successo e il volume atteso; poi verificare se esiste una fonte di dati etichettata o se può essere costruita; se il compito è di linguaggio naturale e non ci sono dati, prototipare con un LLM per validare il valore; se il volume è alto e il compito è stabile, valutare di addestrare un modello classico con i dati generati; e in tutti i casi, allestire un insieme di valutazione prima di passare in produzione. La decisione tra LLM e modello tradizionale non è ideologica: dipende dal volume, dalla latenza, dalla spiegabilità richiesta e dalla disponibilità di dati. Cambiare idea quando i numeri lo giustificano fa parte del lavoro.