Il rumore attorno al fine-tuning
Poche tecniche di intelligenza artificiale hanno accumulato aspettative così sproporzionate come il fine-tuning dei modelli linguistici. Viene spesso presentato come una bacchetta magica che trasforma un modello generico in un assistente esperto semplicemente caricando un CSV di esempi. La realtà è molto più prosaica: il fine-tuning è uno strumento chirurgico con un costo reale, limiti chiari e, in molti casi, alternative più economiche che funzionano meglio.
Questo articolo non è un tutorial di comandi, ma un confronto tra ciò che si dice nei forum e ciò che accade quando si esegue il processo con dati reali. Se cerchi una ricetta infallibile, non la troverai qui. Se vuoi sapere quando vale la pena e quando stai buttando via i soldi, continua a leggere.
Mito 1: «Con 100 esempi hai già un modello esperto»
È probabilmente l’affermazione più ripetuta nei thread di discussione. La documentazione ufficiale dei principali fornitori di modelli personalizzabili consiglia di solito set di dati che vanno da diverse centinaia a migliaia di esempi di alta qualità, a seconda della complessità del compito. Cento esempi possono funzionare per una classificazione binaria molto specifica, ma non per un assistente che debba ragionare su normative interne.
C’è un dettaglio che quasi mai viene menzionato: la qualità pesa più della quantità, ma non in modo lineare. Un dataset di 500 esempi revisionati da una persona competente può superare uno di 5.000 generati automaticamente con il modello stesso. Il fenomeno è noto come model collapse quando si addestra in modo iterativo con dati sintetici senza filtro umano.
Un caso concreto che illustra il problema
In un progetto di classificazione di ticket di supporto, un team ha generato 3.000 esempi etichettati con un modello grande e ha fatto fine-tuning di un modello piccolo. La precisione iniziale sembrava eccellente in validazione, ma al momento del deployment in produzione le categorie ambigue (reclami che mescolavano fatturazione e supporto tecnico) si sono degradate. La causa: l’etichettatore automatico ha ereditato i propri bias e il modello sottoposto a fine-tuning ha imparato a imitare quegli errori con grande sicurezza. La soluzione non è stata più dati, ma revisionare manualmente 200 casi ambigui e aggiungere regole esplicite nel prompt di sistema.
Mito 2: «Il fine-tuning sostituisce il RAG»
Questa confusione appare costantemente. Sono tecniche diverse che risolvono problemi diversi:
- Fine-tuning: modifica il comportamento del modello (stile, formato, tono, criteri di decisione). È utile quando vuoi che il modello risponda sempre in un modo specifico.
- RAG (Retrieval-Augmented Generation): inietta conoscenza esterna al momento dell’inferenza. È utile quando le informazioni cambiano frequentemente o sono troppo estese per rientrare nell’addestramento.
Se il tuo problema è che il modello non conosce il tuo catalogo prodotti aggiornato ogni settimana, il fine-tuning è una cattiva scelta: dovresti riaddestrare ogni volta. Se il tuo problema è che il modello risponde con un tono troppo informale per il servizio clienti, il RAG non lo risolverà. Secondo la documentazione ufficiale di piattaforme come OpenAI o Anthropic, la raccomandazione abituale è iniziare con il prompting avanzato, poi il RAG, e solo dopo considerare il fine-tuning.
Mito 3: «È economico e veloce»
Il costo visibile dell’addestramento è diminuito, ma il costo totale no. Ci sono tre voci che di solito vengono ignorate:
- Preparazione dei dati: pulizia, deduplicazione, revisione delle etichette e formato. In pratica, consuma più tempo dell’addestramento stesso.
- Valutazione: hai bisogno di un set di validazione indipendente e di metriche che riflettano l’uso reale. Senza questo, stai volando alla cieca.
- Manutenzione: ogni volta che cambia il dominio (nuova normativa, nuovo prodotto, nuova politica), il modello sottoposto a fine-tuning può diventare obsoleto e bisogna ripetere il ciclo.
In molti casi, un buon prompt con esempi (few-shot) e una temperatura bassa offre l’80% del beneficio con il 5% dello sforzo. Il fine-tuning si giustifica quando quel 20% rimanente è critico per il business.
Realtà: quando il fine-tuning fa la differenza
Ci sono scenari in cui il fine-tuning è chiaramente superiore:
- Riduzione della latenza e del costo per token: un modello piccolo sottoposto a fine-tuning può sostituire uno grande in compiti molto circoscritti, con minore latenza e minore costo di inferenza.
- Formati rigorosi: quando l’output deve seguire uno schema JSON complesso o un formato di report interno, il fine-tuning riduce la necessità di validazioni successive.
- Dominio molto specifico con gergo proprio: ad esempio, classificazione di incidenti in un settore regolamentato dove il vocabolario non appare nel corpus generale.
- Stile di marca coerente: quando il tono è parte del prodotto e non può essere delegato a istruzioni che il modello a volte ignora.
Al di fuori di questi casi, conviene chiedersi se il problema sia realmente di comportamento del modello o di dati di input.
Il passo dopo passo che conta davvero (e che di solito non viene raccontato)
Al di là dell’esecuzione di uno script di addestramento, il processo reale ha fasi che determinano il risultato:
1. Definire il criterio di successo prima di toccare i dati
Non è la stessa cosa «che risponda bene» e «che riduca del 20% le escalation a un operatore umano nei ticket di fatturazione». Senza una metrica operativa, qualsiasi miglioramento è aneddotico.
2. Costruire un set di valutazione indipendente
Deve provenire dalla stessa distribuzione dei dati di produzione, ma mai dallo stesso lotto di addestramento. Un errore frequente è valutare con esempi che il modello ha già visto, il che gonfia i risultati.
3. Formattare i dati secondo il fornitore
Ogni piattaforma si aspetta un formato diverso (coppie istruzione-risposta, conversazioni con ruoli, ecc.). Un formato errato può passare inosservato e produrre un modello che ignora le istruzioni.
4. Addestrare con un modello base adeguato
Non tutti i modelli supportano il fine-tuning, e quelli che lo supportano hanno limiti di dimensione e di token. Scegliere un modello troppo piccolo per un compito complesso porta a un fine-tuning che non generalizza.
5. Valutare con metriche e con revisione umana
Le metriche automatiche (accuratezza, F1, BLEU) non catturano le sfumature di utilità. Una revisione cieca da parte di qualcuno che non ha partecipato all’etichettatura rileva problemi che le metriche nascondono.
6. Distribuire con monitoraggio
Il modello sottoposto a fine-tuning può degradarsi se la distribuzione di input cambia. Senza monitoraggio della deriva, il problema viene rilevato quando gli utenti si lamentano.
Limiti che conviene accettare
Il fine-tuning non elimina le allucinazioni. Un modello sottoposto a fine-tuning con dati corretti può continuare a inventare informazioni quando gli viene chiesto qualcosa al di fuori della sua distribuzione. Non garantisce nemmeno il rispetto delle policy: se il dataset contiene esempi ambigui, il modello apprenderà quell’ambiguità.
Un altro limite pratico: la dimenticanza catastrofica. Quando si fa fine-tuning di un modello per un compito specifico, può perdere capacità generali che prima aveva. Se hai bisogno di un assistente versatile, un fine-tuning aggressivo può peggiorare le prestazioni in compiti non previsti.
E un avviso di trasparenza: non esiste una formula che garantisca che il fine-tuning migliorerà il tuo caso. La decisione deve basarsi su una prova controllata con metriche chiare, non su promesse di terzi.
Alternative che a volte vincono
Prima di fare fine-tuning, vale la pena esplorare:
- Prompt engineering con esempi dinamici: selezionare gli esempi più rilevanti per ogni query al momento dell’inferenza.
- RAG con buoni embedding: per conoscenza fattuale e aggiornata.
- Strumenti esterni: delegare calcoli o query ad API invece di aspettarsi che il modello li faccia a memoria.
- Modelli già sottoposti a fine-tuning dal fornitore: in alcuni casi, un modello specializzato disponibile commercialmente copre l’esigenza senza addestramento proprio.
La combinazione di più tecniche di solito dà risultati migliori che puntare tutto sul fine-tuning.
Conclusione senza promesse
Il fine-tuning degli LLM è una tecnica potente, ma non è una scorciatoia. Funziona quando il problema è di comportamento e ci sono dati di qualità sufficiente per definirlo. Fallisce quando viene usato per iniettare conoscenza mutevole, quando i dati sono rumorosi o quando ci si aspetta che un modello piccolo eguagli uno grande nel ragionamento complesso. La differenza tra un progetto di successo e uno che resta nel cassetto sta meno nell’addestramento e più nella definizione del problema, nella valutazione onesta e nella disponibilità ad accettare che, a volte, la risposta corretta è non fare alcun fine-tuning.