Addestrare un modello linguistico da zero non è un esercizio di forza bruta computazionale. È un progetto di ingegneria con decine di decisioni concatenate in cui un errore precoce può invalidare settimane di calcolo e migliaia di euro di GPU. La maggior parte delle guide spiega la pipeline ideale (tokenizzatore, dataset, preaddestramento, fine-tuning), ma quasi nessuna si sofferma sugli errori che si verificano davvero quando qualcuno prova a metterla in pratica. Questo articolo copre esattamente questo: gli errori più frequenti e come individuarli prima che sia troppo tardi.
Errori nella fase dei dati: l’origine di quasi tutto
1. Misurare il dataset in gigabyte invece che in token utili
Un errore comune è vantarsi del corpus per la sua dimensione su disco. Un file compresso di 50 GB può contenere meno testo utile di quanto suggerisca, e dopo la deduplicazione e il filtraggio del boilerplate HTML può ridursi a una frazione. Ciò che conta è il numero di token dopo la tokenizzazione reale, non il peso del file.
Come evitarlo: tokenizza un campione rappresentativo (ad esempio, 1 GB decompresso) con il tokenizzatore esatto che utilizzerai, calcola il rapporto token/carattere ed estrapola. Ripeti il calcolo dopo ogni fase di pulizia. Se il corpus finale non raggiunge un volume ragionevole per la dimensione del modello, ripensa l’obiettivo prima di avviare l’addestramento.
2. Deduplicare solo con corrispondenza esatta
La deduplicazione tramite hash esatto elimina le copie identiche, ma lascia passare parafrasi, template ripetuti e frammenti quasi duplicati che gonfiano artificialmente alcune distribuzioni. Il modello finisce per memorizzare frasi ricorrenti e generare output ripetitivi.
Come evitarlo: applica una deduplicazione fuzzy per n-grammi o per similarità di MinHash su blocchi di documento. Non hai bisogno di un sistema perfetto: eliminare i duplicati vicini a livello di paragrafo riduce già molto il rumore.
3. Ignorare la miscela di domini e il filtraggio di qualità
Mescolare web generico, codice, articoli scientifici e forum senza ponderare produce modelli che imitano il tono di un forum in risposte che dovrebbero essere formali. È anche comune non filtrare contenuti tossici, spam o testo generato automaticamente.
Come evitarlo: definisci proporzioni esplicite per fonte, documenta da dove proviene ogni blocco e applica classificatori di qualità leggeri. Secondo la documentazione ufficiale di diversi progetti aperti, il filtraggio di qualità ha più impatto sul risultato finale che aggiungere più dati di bassa qualità.
4. Contaminazione del set di valutazione
Questo è probabilmente l’errore più silenzioso. Se il tuo set di validazione o i tuoi benchmark interni compaiono, anche solo parzialmente, nei dati di addestramento, le metriche mentono. Un modello che «migliora» a ogni valutazione potrebbe semplicemente stare memorizzando.
Come evitarlo: separa i set di valutazione prima di costruire il corpus, salva le impronte (hash di n-grammi) di quei set e verifica la sovrapposizione con il dataset di addestramento. Se ci sono corrispondenze, eliminale dal corpus, non dal test.
Errori nella tokenizzazione e nell’architettura
5. Addestrare il tokenizzatore con un corpus che non rappresenta il dominio finale
Se il tokenizzatore viene addestrato solo con l’inglese e poi il modello viene usato in spagnolo o su codice, il numero di token per parola esplode, la finestra di contesto effettiva si riduce e il costo di addestramento e inferenza aumenta senza che si noti nelle metriche iniziali.
Come evitarlo: addestra il tokenizzatore con un campione stratificato che rifletta le lingue e i domini d’uso reali. Verifica con testo fuori campione quanti token consuma la stessa frase in lingue diverse; se ci sono differenze abissali, rivedi il vocabolario.
6. Scegliere la dimensione del modello senza un chiaro budget di calcolo
Un modello più grande non è sempre migliore per un obiettivo concreto, e inoltre impone requisiti di memoria e tempo che molti progetti sottovalutano. Avviare un preaddestramento senza aver calcolato il costo totale (ore di GPU, checkpoint, archiviazione, tentativi ripetuti) è una via rapida per rimanere a metà.
Come evitarlo: fai una prova di scalabilità con un modello piccolo per poche ore, misura il throughput reale sul tuo hardware ed estrapola. Se il budget non copre l’addestramento completo più almeno un riavvio da checkpoint, riduci la dimensione.
7. Non definire una lunghezza di contesto realistica
Annunciare contesti enormi senza dati che li sfruttino genera modelli che rendono peggio su finestre lunghe di quanto suggerisca l’architettura. L’attenzione su sequenze lunghe rende più costoso l’addestramento e, se il corpus è composto da documenti brevi, il modello non impara mai a usarla.
Come evitarlo: allinea la lunghezza di sequenza con la distribuzione reale dei tuoi documenti. Se hai bisogno di un contesto lungo, includi dati con struttura lunga e valuta specificamente i compiti che lo richiedono.
Errori durante il preaddestramento
8. Non monitorare la perdita per dominio
La perdita globale può scendere mentre un dominio specifico peggiora. Se il modello si sta sovradattando al web generico e perdendo capacità sul codice o su una lingua specifica, la metrica aggregata lo nasconde.
Come evitarlo: registra la perdita di validazione suddivisa per fonte. Un pannello con curve separate per dominio individua gli squilibri molto prima della media globale.
9. Checkpoint insufficienti o mal gestiti
Salvare solo alla fine è una scommessa. Guasti hardware, riavvii del cluster o instabilità numerica possono obbligare a ripetere giorni di calcolo. È anche comune salvare checkpoint senza registrare la configurazione esatta associata, il che rende impossibile riprodurre lo stato.
Come evitarlo: salva checkpoint periodici con la loro configurazione, seed e stato dell’ottimizzatore. Verifica che la ripresa da checkpoint funzioni prima di avviare l’addestramento lungo.
10. Ignorare l’instabilità numerica
Picchi di perdita, gradienti che esplodono o NaN intermittenti sono segnali che la configurazione di addestramento non è stabile. Molti progetti li trattano come rumore e vanno avanti, e il modello finale resta degradato in modo difficile da diagnosticare.
Come evitarlo: usa il clipping del gradiente, rivedi la scala di inizializzazione e prova con sequenze più corte prima di scalare. Se compaiono NaN, fermati e analizza; non riavviare alla cieca.
Errori nel fine-tuning e nella valutazione
11. Confondere il fine-tuning con la soluzione di tutto
Il fine-tuning non corregge un preaddestramento carente. Se il modello base non ha capacità o dati sufficienti, il fine-tuning maschera solo il risultato sul set di valutazione e generalizza male.
Come evitarlo: valuta il modello base prima di fare fine-tuning. Se le metriche di base sono scarse, investi in dati e preaddestramento, non in più epoche di fine-tuning.
12. Valutare solo con metriche automatiche
Perplessità e accuratezza su compiti sintetici non descrivono il comportamento reale. Un modello può migliorare in una metrica e diventare più ripetitivo, più insicuro o meno utile in conversazione.
Come evitarlo: combina metriche automatiche con valutazioni umane su un campione piccolo ma ben definito. Documenta i criteri e verifica periodicamente se continuano a misurare ciò che ti interessa.
13. Non documentare il processo
Senza un registro delle versioni dei dati, degli iperparametri e dei risultati, ogni esperimento è irripetibile. Non è un dettaglio accademico: in produzione, quando qualcosa fallisce, la tracciabilità è ciò che permette di diagnosticare.
Come evitarlo: versiona il dataset, la configurazione e i checkpoint con identificatori chiari. Un registro minimo ma coerente evita settimane di confusione.
Un caso concreto che illustra il problema
In un progetto reale di fine-tuning di un modello piccolo per risposte tecniche in spagnolo, il team ha rilevato che il modello generava risposte corrette ma con un tono stranamente promozionale. La causa non era nel fine-tuning: il corpus di preaddestramento includeva una proporzione elevata di pagine di marketing e blog di prodotto che dominavano certi argomenti. La perdita globale era buona e le metriche automatiche non lo rilevavano. È stato corretto riequilibrando la miscela di domini e filtrando i contenuti promozionali, non aggiungendo più dati.
Questo tipo di problema si individua solo leggendo regolarmente gli output reali del modello e confrontandoli con quanto atteso, non solo guardando le curve di perdita.
Cosa non copre questo articolo e perché
Addestrare un LLM da zero su scala industriale richiede infrastruttura distribuita, strategie di parallelismo e ottimizzazioni di memoria che dipendono dall’hardware specifico e dal framework scelto. Quanto descritto qui si concentra sugli errori di criterio che riguardano qualsiasi scala, da un modello piccolo su una singola GPU fino a un progetto più grande. Nessuna di queste raccomandazioni garantisce risultati: il comportamento finale dipende dall’interazione tra dati, architettura e configurazione, e c’è sempre incertezza.
Se qualcosa caratterizza chi ha addestrato modelli con successo è la prudenza: danno per scontato che il dataset abbia problemi, che le metriche possano ingannare e che il primo addestramento non sarà quello definitivo. Pianificare per questa realtà fa risparmiare più tempo di qualsiasi ottimizzazione prematura.