Scegliere un modello linguistico oggi non è una questione di fede. È una decisione di ingegneria che influisce su costi, latenza, privacy e qualità dell’output. E per decidere bene conviene capire cosa c’è sotto quella scatola nera che chiamiamo LLM. Questa comparativa non riguarda «qual è il migliore», ma perché ogni famiglia di modelli si comporta diversamente a seconda del compito, e cosa devi guardare prima di integrarne uno nel tuo flusso di lavoro.
L’architettura comune: tutti partono dallo stesso trucco
I modelli attuali (GPT, Claude, Gemini, Llama, Mistral) sono discendenti diretti del transformer, presentato nel paper Attention Is All You Need (2017). L’idea centrale: elaborare il testo in parallelo mediante meccanismi di attenzione che ponderano quali parole del contesto contano di più per predire la successiva. L’addestramento avviene con la discesa del gradiente su miliardi di token, e l’output è una distribuzione di probabilità sul token successivo.
Questo dettaglio conta: il modello non «sa» nulla in senso stretto. Calcola probabilità. Per questo può sembrare sicuro mentre inventa un riferimento bibliografico. La differenza tra i modelli non sta nel concetto, ma in come vengono messi a punto dopo il pre-addestramento (RLHF, DPO, constitutional AI) e nella quantità e qualità dei dati che vedono.
Comparativa delle quattro famiglie più utilizzate
GPT (OpenAI): l’ecosistema più ampio
La famiglia GPT-4o e le sue varianti mini offrono multimodalità nativa (testo, immagine, audio) e un’API molto documentata. Il suo punto di forza è l’integrazione: plugin, assistenti, function calling maturo. La sua debolezza pratica è l’opacità sull’addestramento e la dipendenza da un unico fornitore. Per prototipi rapidi e strumenti di terze parti, è la via con meno attrito.
Claude (Anthropic): contesto lungo e risposte sfumate
Claude si distingue per finestre di contesto estese (centinaia di migliaia di token nelle sue versioni recenti) e per un comportamento prudente di fronte a istruzioni ambigue: tende a chiedere chiarimenti invece di improvvisare. In compiti di analisi di documenti lunghi o revisione di codice, questa prudenza è apprezzata. Nella generazione creativa pura, a volte risulta meno audace del desiderato.
Gemini (Google): integrazione con l’ecosistema e multimodalità
Le versioni Flash e Pro sono pensate per convivere con i servizi di Google (Workspace, Vertex AI, ricerca). Il loro contesto lungo e la loro capacità multimodale sono competitivi. Il rovescio della medaglia: la documentazione e i limiti di quota cambiano frequentemente, e le differenze tra versioni Flash e Pro influiscono molto sulla qualità del ragionamento.
Llama e Mistral: pesi aperti e controllo totale
Qui la logica è diversa. I pesi sono disponibili (con licenze che conviene leggere, non tutte sono ugualmente permissive). Puoi eseguirli in locale o nel tuo cloud, metterli a punto con il fine-tuning e verificarne il comportamento. Il costo è l’infrastruttura: un modello da 70B parametri in FP16 necessita di circa 140 GB di VRAM solo per i pesi, più memoria per il contesto. La quantizzazione a 4 bit riduce questa cifra a un intervallo gestibile su GPU di fascia alta, ma introduce un degrado misurabile nei compiti di ragionamento.
Cosa confrontare davvero prima di scegliere
- Finestra di contesto reale rispetto a quella effettiva: che un modello annunci 200.000 token non significa che mantenga la coerenza su tutto quell’intervallo. L’attenzione degradata nelle posizioni intermedie (il fenomeno lost in the middle) è documentata in studi del settore. Prova con il tuo documento lungo prima di fidarti.
- Latenza e costo per token: un modello grande può impiegare diversi secondi per generare una risposta completa. Per il chat interattivo, i modelli piccoli messi a punto tendono a vincere in termini di percezione della velocità.
- Comportamento di fronte al rifiuto: tutti hanno filtri. La differenza sta in quanti falsi positivi generano. Un modello che rifiuta una consultazione medica legittima per eccesso di zelo è un problema operativo.
- Determinismo e temperatura: a temperatura 0 l’output non è completamente riproducibile tra chiamate nella maggior parte delle API. Se hai bisogno di risultati identici, dovrai fare caching o validare l’output.
Un caso concreto: l’errore di misurare il contesto dall’annuncio
Qualche mese fa, lavorando all’estrazione di clausole da contratti di locazione, abbiamo verificato che un modello con finestra di 128.000 token iniziava a omettere clausole situate a metà del documento quando questo superava le 60 pagine. La soluzione non è stata cambiare modello, ma suddividere il documento per sezioni e concatenare riassunti parziali. È un pattern che si ripete: il limite annunciato non è il limite utile. Chi integra gli LLM in produzione impara presto che l’ingegneria del contesto (cosa inserisci e in quale ordine) pesa più della scelta del marchio del modello.
Un altro errore frequente: presumere che un modello con migliori benchmark generali sarà migliore nel tuo dominio. Le valutazioni tipo MMLU o HumanEval misurano capacità ampie, non il tuo caso d’uso. L’unica prova valida è un insieme di valutazione proprio, con esempi reali della tua attività e criteri di accettazione definiti.
Limitazioni che nessun modello risolve ancora
Gli LLM non hanno memoria persistente tra le sessioni a meno che non la costruisca tu (RAG, basi vettoriali, cronologia). Non verificano i fatti da soli: se chiedi loro una cifra, la genereranno con la stessa sicurezza di una corretta. Non ragionano in modo simbolico affidabile in problemi di logica formale con molte variabili. E non sono adatti, da soli, a decisioni mediche, legali o finanziarie senza supervisione umana: la documentazione ufficiale dei fornitori stessi lo avverte.
Nemmeno conviene usarli come oracoli di attualità. La loro conoscenza ha una data di taglio, e sebbene alcuni integrino la ricerca web, tale integrazione aggiunge latenza e un ulteriore livello di errore (quale fonte scelgono, come la citano).
Come decidere in pratica
Per compiti di classificazione ed estrazione ad alto volume, un modello piccolo con fine-tuning è di solito più economico e prevedibile di uno grande. Per il ragionamento complesso e i documenti lunghi, i modelli a contesto esteso fanno risparmiare architettura. Per i dati sensibili che non possono uscire dalla tua infrastruttura, i pesi aperti sono l’unica via reale, assumendosi il costo di manutenzione. E per i prototipi, l’API con la migliore documentazione e community ti farà risparmiare giorni.
Nessuna scelta è definitiva: i modelli cambiano ogni pochi mesi e ciò che oggi è un riferimento domani diventa obsoleto. Progetta la tua integrazione con uno strato di astrazione sul fornitore e un insieme di valutazione proprio. Questo ti permetterà di cambiare modello senza riscrivere il prodotto, che è la decisione più redditizia a lungo termine.
E un’ultima avvertenza di trasparenza: non esiste un modello che garantisca risposte corrette. La qualità dipende dal contesto che gli fornisci, da come formuli l’istruzione e dalla validazione che metti dopo. Qualsiasi promessa di risultati infallibili conviene guardarla con distanza.