Il fine-tuning dei modelli linguistici ha smesso di essere un rituale da laboratorio per diventare un pezzo in più dello stack di prodotto. Ciò che due anni fa richiedeva GPU dedicate e settimane di lavoro, oggi si risolve con tecniche di basso rango, dati sintetici e API gestite. Ma il panorama è cambiato così tanto che molte ricette in circolazione restano ancorate a pratiche ormai obsolete. Questa rassegna si concentra su ciò che sta muovendo il terreno in questo momento, senza promettere miracoli.
Cosa è cambiato nel ciclo di fine-tuning
Il flusso classico —raccogliere coppie istruzione-risposta, addestrare tutti i pesi e valutare a occhio— si è frammentato. I team che lavorano con modelli aperti hanno adottato varianti che riducono costi e rischi:
- LoRA e i suoi derivati (QLoRA, DoRA): si addestra una frazione minima di parametri e si mantiene il modello base congelato. La documentazione ufficiale delle principali librerie di addestramento li presenta già come l’opzione predefinita per fine-tuning con meno di un milione di esempi.
- Allineamento preferenziale: invece di imitare le risposte, si ottimizza con coppie di preferenza (DPO e varianti). Secondo studi del settore, questa via riduce il numero di esempi necessari rispetto al RLHF tradizionale ed evita di addestrare un modello di ricompensa separato.
- Distillazione da modelli grandi: generare dati con un modello più grande e fare fine-tuning su uno più piccolo è diventata una pratica comune. La sfumatura importante: la qualità dell’insegnante segna il tetto dello studente, e i dati sintetici senza filtro trascinano bias e allucinazioni.
Un flusso realistico, passo dopo passo, con le trappole segnalate
1. Definire il comportamento obiettivo prima di toccare i dati
L’errore più ricorrente che vedo nei team che iniziano: lanciare l’addestramento senza una specifica scritta di cosa deve fare il modello e, soprattutto, di cosa non deve fare. Senza quel contratto, la valutazione successiva è interpretazione libera. Conviene redigere tra 10 e 20 casi d’uso con esempi di input e output atteso, includendo casi limite (richieste ambigue, fuori dominio, tentativi di manipolazione).
2. Curare il dataset con più rigore che entusiasmo
La proporzione abituale nei progetti che funzionano si aggira intorno a qualche centinaio fino a qualche migliaio di esempi ben etichettati. Più volume con rumore peggiora il risultato. Tre controlli che di solito si saltano:
- Deduplicazione semantica: risposte quasi identiche con lievi variazioni gonfiano il dataset e distorcono il fine-tuning.
- Coerenza di formato: se l’80% delle risposte usa uno stile e il 20% un altro, il modello impara entrambi e oscilla.
- Revisione dei bias di annotazione: chi etichetta lascia un’impronta. Due annotatori diversi producono distribuzioni diverse anche seguendo la stessa guida.
3. Scegliere base e metodo in base al budget reale
Non tutto richiede un modello da 70B. Per compiti di classificazione, estrazione di entità o risposte con formato fisso, un modello da 7-8B con fine-tuning QLoRA di solito basta e si serve su una singola GPU. Per il ragionamento complesso, il fine-tuning raramente compensa rispetto a un modello più grande con un buon prompting; lì il costo di servire il modello supera il beneficio.
Un dettaglio pratico che compare nella documentazione di diverse piattaforme: se l’obiettivo è insegnare conoscenza nuova (normativa interna, catalogo prodotto), il fine-tuning è uno strumento mediocre. Per questo funziona meglio la retrieval augmented generation. Il fine-tuning brilla quando si vuole cambiare la forma di rispondere: tono, formato, politica di rifiuto, struttura dell’output.
4. Addestrare con validazione separata fin dal primo minuto
Riservare tra il 10% e il 20% dei dati per la validazione non è opzionale. L’overfitting nei modelli piccoli è rapido e silenzioso: la loss di addestramento scende mentre le risposte diventano rigide e ripetitive. Rilevarlo richiede di guardare le metriche di generazione, non solo la loss.
5. Valutare con rubriche, non con impressioni
È qui che la maggior parte dei progetti naufraga. Una valutazione onesta combina:
- Test automatici di formato e vincoli (rispetta lo schema JSON? cita la fonte? rifiuta ciò che deve rifiutare?).
- Valutazione umana cieca su un piccolo campione, confrontando modello base e modello con fine-tuning con lo stesso prompt.
- Un set di regressione che non cambia tra le iterazioni, per misurare la deriva.
Secondo la documentazione ufficiale di diversi fornitori di valutazione, le metriche automatiche tipo BLEU o ROUGE correlano male con l’utilità percepita nei compiti aperti. Servono per il formato, non per la qualità.
Il caso che quasi nessuno racconta: il fine-tuning che peggiorò il prodotto
Un team ha fatto fine-tuning su un modello da 8B perché rispondesse a richieste di supporto con un tono molto controllato. I risultati sul set di validazione erano eccellenti. In produzione, il modello ha iniziato a rifiutare domande legittime che assomigliavano superficialmente a quelle marcate come fuori ambito. Il problema non era l’addestramento: era che il dataset includeva molti esempi di rifiuto e pochissimi di domande ambigue che sì dovevano essere risposte. La lezione: la distribuzione del dataset definisce il comportamento tanto quanto il contenuto. Un fine-tuning non insegna sfumature che non sono rappresentate nei dati.
Tendenze che stanno ridefinendo il terreno
Modelli piccoli specializzati contro monoliti
La curva dei costi di inferenza spinge verso modelli da 3-8B con fine-tuning per un compito specifico. Diversi fornitori di infrastruttura offrono già deployment di basso rango con latenza competitiva. La sfumatura: la specializzazione ha un tetto. Un modello piccolo con fine-tuning per l’assistenza clienti non diventa un assistente generale per quanto lo si addestri.
Fine-tuning con dati sintetici filtrati
Generare dati con un modello più grande e filtrare per qualità prima di addestrare è oggi una pratica diffusa. Il rischio noto: i modelli addestrati su dati sintetici senza verifica tendono ad amplificare gli errori del generatore. La raccomandazione che compare nei forum tecnici e nella documentazione delle librerie è mescolare dati reali con sintetici e mantenere un’audit manuale su un campione.
Valutazione come servizio e tracciabilità
La pressione normativa in alcuni settori ha spinto a documentare il processo di fine-tuning: quali dati, quale metodo, quale valutazione, quali limitazioni note. Non è burocrazia: è ciò che permette di decidere quando ritirare un modello con fine-tuning perché il comportamento è derivato.
Cosa il fine-tuning non risolve
Conviene dirlo senza giri di parole. Il fine-tuning non risolve un problema di dati, non sostituisce una buona ingegneria dei prompt nei compiti semplici e non garantisce che il modello smetta di allucinare. Non è nemmeno la via per mantenere aggiornata la conoscenza: ogni cambiamento di politica interna richiederebbe un nuovo addestramento, cosa che la retrieval augmented generation evita. E nei modelli molto grandi, il costo di servire un fine-tuning proprio può superare quello di usare un’API gestita con un prompting accurato.
La decisione sensata passa da una domanda preliminare: devo cambiare come risponde il modello o devo fargli sapere qualcosa che non sa? La prima domanda giustifica il fine-tuning. La seconda, quasi mai.