Scegliere tra un modello di linguaggio di grandi dimensioni (LLM) e una pipeline classica di elaborazione del linguaggio naturale (NLP) non è una questione di moda, ma di adeguatezza tecnica. Questa lista di controllo è pensata per essere usata come filtro prima di impegnare budget, infrastruttura o un intero team nella direzione sbagliata. Ogni punto include la sfumatura che di solito impariamo a nostre spese: quando la risposta ovvia fallisce.
Come usare questa checklist
Non è un questionario sì o no. Segna ogni casella con evidenze (una prova, un documento, una misurazione), non con un’intuizione. Se non riesci a compilare una casella con dati, quella casella è precisamente il punto in cui il tuo progetto si romperà in produzione.
1. Definisci il compito con precisione chirurgica
1.1 È un compito chiuso o aperto?
Classificare 40.000 ticket in 12 categorie fisse è un compito chiuso. Riassumere conversazioni eterogenee è un compito aperto. I modelli tradizionali (regressione logistica su TF-IDF, SVM, CRF per l’etichettatura di sequenze, modelli di argomento come LDA) restano competitivi in compiti chiusi con vocabolario stabile e confini ben definiti. Gli LLM brillano quando l’output non può essere enumerato in anticipo.
1.2 L’etichetta corretta è inequivocabile?
Se due persone esperte non concordano nell’etichettare lo stesso esempio, un LLM tenderà a produrre risposte plausibili ma incoerenti tra un’esecuzione e l’altra, e un modello classico semplicemente apprenderà il rumore. Prima di scegliere la tecnologia, misura l’accordo tra gli annotatori. Senza quella metrica, qualsiasi confronto successivo è fumo.
1.3 Ti serve estrazione strutturata o generazione?
Estrarre entità, relazioni e date dai contratti è un problema di estrazione. Un LLM può farlo con formato JSON forzato, ma un modello di riconoscimento di entità addestrato con dati propri di solito è più economico per documento, più veloce e più stabile di fronte a variazioni di formato. La generazione libera, invece, è territorio quasi esclusivo degli LLM.
2. Verifica i tuoi dati prima di verificare i modelli
2.1 Volume e sbilanciamento
Con 300 esempi etichettati per classe, un modello classico ben ottimizzato può essere sufficiente. Con 30, nessuno dei due funzionerà bene, e l’LLM avrà bisogno di esempi nel prompt (apprendimento in contesto) o di fine-tuning, che non è gratis. Controlla lo sbilanciamento: nella classificazione di frodi o di incidenti critici, la classe minoritaria è quella che conta e quella con meno dati.
2.2 Dominio e gergo
Un LLM generalista conosce l’italiano standard, ma non necessariamente il gergo interno della tua azienda, i codici prodotto o le abbreviazioni del tuo settore. Nemmeno i modelli classici, ma il loro addestramento è più economico e puoi iniettare vocabolario controllato senza riaddestrare un modello da miliardi di parametri.
2.3 Sensibilità e residenza del dato
Se il testo contiene dati personali, cartelle cliniche o informazioni coperte da segreto contrattuale, inviare ogni documento a un’API esterna richiede una valutazione dei rischi che molte organizzazioni non hanno fatto. I modelli classici girano sulla tua infrastruttura con una superficie di esposizione minore. Gli LLM auto-ospitati esistono, ma cambiano completamente il calcolo dei costi e del team necessario.
3. Calcola il costo reale, non il costo per token
3.1 Costo per inferenza contro costo per manutenzione
Il prezzo per token di un LLM sembra basso finché non lo moltiplichi per milioni di documenti e aggiungi tentativi ripetuti, validazioni e token di contesto. Un modello classico ha un costo di inferenza quasi trascurabile, ma porta con sé un costo di manutenzione: riaddestramenti periodici, gestione delle feature, deriva del modello (data drift). La domanda giusta non è quale sia più economico oggi, ma quale lo sarà tra due anni con il tuo volume previsto.
3.2 Latenza ed esperienza utente
Un classificatore lineare risponde in millisecondi; una chiamata a un LLM con contesto lungo può impiegare secondi. Se il compito è nel percorso critico di un’interfaccia (completamento automatico, moderazione in tempo reale, instradamento delle chat), quella differenza è decisiva. Ho visto team migrare un classificatore di intenti a un LLM e scoprire che il tempo di risposta si moltiplicava per dieci senza miglioramenti percepibili nella precisione.
3.3 Costo di valutazione
Valutare un LLM è più costoso e più sfumato che valutare un classificatore: servono insiemi di riferimento, criteri di qualità a volte soggettivi e revisione umana. Metti a budget questo sforzo prima di iniziare; secondo la documentazione di settore, la valutazione di solito consuma più tempo del previsto.
4. Verifica la riproducibilità e l’auditabilità
4.1 Devi spiegare ogni decisione?
In settori regolamentati (assicurazioni, banche, sanità, pubblica amministrazione) spesso bisogna giustificare perché un sistema ha rifiutato una richiesta. Un modello di regressione con coefficienti interpretabili o un albero decisionale si spiega con relativa facilità. Un LLM genera una giustificazione in linguaggio naturale che può suonare convincente e non corrispondere al ragionamento reale. La spiegabilità apparente è un rischio, non un vantaggio.
4.2 L’output deve essere identico a parità di input?
Gli LLM con campionamento stocastico non lo garantiscono. Puoi impostare la temperatura a zero, ma questo non elimina tutte le fonti di variazione (versioni del modello, modifiche del fornitore, contesto). I modelli classici sono deterministici per progettazione. Se il tuo caso d’uso richiede un’auditabilità ripetibile, questo pesa più di qualche punto di precisione.
4.3 Versionamento e dipendenza dal fornitore
Un LLM ospitato può cambiare comportamento senza preavviso quando il fornitore aggiorna il modello. La tua pipeline classica cambia solo quando la cambi tu. Documenta come fisserai le versioni e cosa farai se il fornitore ritira quella che usi.
5. Valuta lo sforzo di ingegneria e il team
5.1 Hai chi mantiene i prompt o chi mantiene le feature?
Un LLM sposta il lavoro dall’ingegneria delle caratteristiche verso la progettazione dei prompt, la validazione degli output e i test di regressione. Un modello classico richiede profili più orientati ai dati e alla statistica. Nessuna delle due strade è gratis; scegli quella che il tuo team può sostenere nel tempo.
5.2 Output non strutturati e validazione
Se l’LLM restituisce testo libero, avrai bisogno di livelli di validazione, tentativi ripetuti e gestione degli errori. Se restituisce JSON forzato, avrai bisogno di schemi rigorosi e tolleranza ai fallimenti di formato. Conta questi pezzi nella progettazione; non sono un dettaglio.
5.3 Test di regressione
Con i modelli classici, una suite di test con metriche fisse di solito basta. Con gli LLM, conviene mantenere un insieme aureo di casi e confrontare le risposte tra versioni, accettando una certa variabilità. Se non hai quell’insieme, non hai modo di sapere se un aggiornamento ha migliorato o peggiorato il sistema.
6. Rivedi i limiti che nessuno menziona nelle demo
6.1 Allucinazioni nei compiti di estrazione
Un LLM può inventare una data che non compare nel documento se il formato lo suggerisce. Nell’estrazione dati, questo è un errore silenzioso e pericoloso. I modelli classici di etichettatura di sequenze hanno i propri errori, ma di solito sono errori di omissione o di confine, non invenzioni.
6.2 Degrado con input lunghi o rumorosi
Le prestazioni di un LLM calano quando il testo è molto lungo, contiene tabelle mal convertite o mescola lingue. In un caso reale di classificazione di email di supporto, la pipeline classica con pulizia specifica superava l’LLM nei messaggi con citazioni annidate e firme, perché quelle parti confondevano il modello generativo. La lezione: la pulizia preliminare conta in entrambi i mondi, e spesso più del modello scelto.
6.3 Lingue e varianti dialettali
Un LLM multilingue può funzionare accettabilmente in molte lingue, ma un modello classico addestrato con dati locali può superarlo in una variante specifica. Se il tuo corpus è molto specifico, prova prima di dare per scontato che il modello grande vinca.
6.4 Cosa non funziona bene con gli LLM
Compiti di altissima precisione con conseguenze legali, decisioni che devono essere identiche e auditabili, elaborazione massiva con latenza minima e budget contenuto, e classificazione di vocabolario molto chiuso con dati etichettati abbondanti. In questi casi, l’LLM aggiunge costo e opacità senza un vantaggio chiaro.
6.5 Cosa non funziona bene con i modelli classici
Generazione di testo coerente, riassunto astrattivo, dialogo aperto, adattamento a nuove istruzioni senza riaddestramento e comprensione di sfumature pragmatiche (ironia, intenzione implicita). Forzare un modello classico a fare questo produce risultati rigidi e fragili.
7. Progetta l’esperimento prima di decidere
7.1 Insieme di valutazione rappresentativo
Raccogli esempi reali, inclusi i casi rari e quelli ambigui. Un insieme di valutazione sbilanciato verso casi facili favorisce l’LLM perché impressiona nel generale; i casi difficili sono quelli che rivelano le differenze.
7.2 Metriche allineate con il business
Precisione, richiamo e F1 sono il punto di partenza, ma chiediti quale errore costa di più. Nella moderazione dei contenuti, un falso negativo può essere grave; nella classificazione dei lead, un falso positivo infastidisce il team commerciale. La metrica deve riflettere questa asimmetria.
7.3 Prova ibrida
La dicotomia è falsa in molti casi. Un pattern abituale è usare un modello classico per filtrare l’80% dei casi facili e riservare l’LLM a quelli ambigui. Oppure usare embedding e ricerca semantica (eredi di tecniche classiche) insieme a un LLM per generare la risposta finale. Documenta questa architettura come un’opzione in più, non come un fallimento del confronto.
8. Checklist finale di decisione
- Ho definito il compito e so se è chiuso o aperto.
- Ho misurato l’accordo tra annotatori umani.
- Conosco il volume, lo sbilanciamento e la qualità dei miei dati.
- Ho calcolato il costo per inferenza e il costo di manutenzione a due anni.
- Ho verificato la latenza ammissibile nel mio caso d’uso.
- So se ho bisogno di spiegabilità e riproducibilità rigorose.
- Ho un piano di versionamento e di dipendenza dal fornitore.
- Il mio team può sostenere l’approccio scelto (prompt o feature).
- Ho identificato i pericolosi errori silenziosi nel mio dominio.
- Ho provato entrambi gli approcci con un insieme di valutazione rappresentativo.
- Ho considerato un’architettura ibrida prima di scartarla.
Se hai segnato tutto con evidenze e non con intuizione, la decisione tra LLM e NLP classico smette di essere una scommessa e diventa una scelta documentata. E se non riesci ancora a segnare qualche casella, quello è il tuo prossimo compito, non la scelta del modello.