La domanda che poche aziende si pongono prima di investire nel fine-tuning
Quando un dirigente scopre che un modello di IA può essere addestrato con i dati dell’azienda per «parlare la lingua del business», la reazione abituale è l’entusiasmo. Il fine-tuning sembra la soluzione definitiva: un modello che conosce i nostri prodotti, la nostra terminologia, i nostri processi.
Il problema è che il fine-tuning è costoso, richiede una manutenzione continua e in molti casi non è lo strumento adatto al problema da risolvere. Prima di investirci conviene capire quando ha davvero senso e quando esistono alternative più efficienti.
Tre approcci per adattare un LLM: quando usare ciascuno
Prompt engineering
È il modo più rapido ed economico per adattare il comportamento di un LLM. Con istruzioni progettate con cura nel prompt (contesto, ruolo, formato della risposta, esempi few-shot) si ottengono comportamenti molto specifici senza intervenire sul modello. È il punto di partenza corretto per quasi tutti i casi d’uso: se il prompt engineering risolve il problema, non c’è motivo di andare oltre.
RAG (Retrieval-Augmented Generation)
Quando il modello ha bisogno di accedere a informazioni specifiche dell’azienda (cataloghi prodotti, documentazione tecnica, knowledge base interna, storico dei casi), la RAG fornisce quel contesto al momento della richiesta, senza riaddestrare il modello. È la soluzione corretta nella maggior parte dei casi in cui il problema è l’accesso alla conoscenza, non lo stile o il comportamento del modello.
Fine-tuning
Il fine-tuning ha senso quando nessuno dei due approcci precedenti è sufficiente. In particolare: quando il modello deve adottare uno stile di risposta molto specifico, difficile da rendere con i prompt; quando occorre migliorare l’efficienza dell’inferenza riducendo la lunghezza del prompt di sistema; oppure quando il caso d’uso richiede un comportamento che il modello di base non ha in modo nativo e che va rafforzato con migliaia di esempi dello stile corretto.
Quando il fine-tuning porta valore reale
Classificatori ed estrattori specializzati
Per attività molto specifiche, come classificare documenti in categorie proprie del business, estrarre entità definite internamente o rilevare schemi testuali assenti nel linguaggio generale, il fine-tuning di un modello piccolo supera in efficienza (velocità, costo, precisione) i grandi modelli generalisti. Il fine-tuning di modelli di classificazione su dati propri etichettati è il caso d’uso con il ROI più dimostrato.
Modelli con uno stile di comunicazione molto definito
Se l’azienda ha un tono di comunicazione molto particolare (tecnico, formale, molto conciso, con una terminologia propria) e ha bisogno che il modello lo riproduca in modo coerente, il fine-tuning con esempi dello stile corretto può dare risultati che il prompt engineering non raggiunge in modo stabile.
Riduzione dei costi su larga scala
Per applicazioni con milioni di chiamate al giorno, il fine-tuning di un modello piccolo per un’attività specifica può risultare molto più economico dell’uso di un grande modello generalista con prompt lunghi. Serve un’analisi dei costi su scala; per volumi bassi non è rilevante.
Costi, dati e manutenzione: la parte di cui nessuno parla
Il fine-tuning richiede dati etichettati di qualità (in genere da centinaia a migliaia di esempi ben annotati per gli LLM, di più per i modelli di visione o di classificazione), tempo di GPU per l’addestramento (con un costo diretto), una valutazione rigorosa del modello ottenuto e un riaddestramento periodico quando il dominio evolve.
Un modello sottoposto a fine-tuning non è un asset statico: ha bisogno di manutenzione. Se il catalogo prodotti cambia, se la terminologia evolve, se i casi d’uso del modello si ampliano, il modello va riaddestrato. Senza una pipeline di MLOps che supporti questo ciclo, il modello si deteriora nel tempo.
Domande frequenti
Quanti esempi di addestramento servono per il fine-tuning di un LLM?
Per LLM come quelli di OpenAI o Llama, il fine-tuning supervisionato può mostrare miglioramenti già con 100-500 coppie input-output di alta qualità, per attività molto specifiche. Per ottenere una coerenza solida in attività complesse o molto variabili ne servono diverse migliaia. La qualità degli esempi conta più del volume: pochi esempi ben annotati valgono più di migliaia di esempi mediocri.
Fine-tuning di un modello open source o di un modello commerciale via API?
Entrambe le opzioni sono praticabili. Il fine-tuning dei modelli via API (OpenAI, Anthropic) è tecnicamente più semplice, ma i dati di addestramento vengono inviati al fornitore. Il fine-tuning dei modelli open source (Llama, Mistral, Qwen) consente il pieno controllo sui dati e sul modello ottenuto, ma richiede un’infrastruttura GPU e maggiori competenze tecniche. Per i dati sensibili, il fine-tuning in locale è di solito la scelta corretta.
Quando conviene scegliere la RAG invece del fine-tuning?
Quasi sempre, quando il problema riguarda l’accesso alla conoscenza. Se il modello deve conoscere il prezzo di un prodotto, il contenuto di un contratto o i passaggi di una procedura, la RAG è più flessibile, più facile da aggiornare e più spiegabile del fine-tuning. Il fine-tuning non è un database: le informazioni inserite nei pesi del modello sono difficili da aggiornare e non si possono recuperare in modo trasparente. La RAG mantiene la conoscenza fuori dal modello, dove può essere gestita in modo esplicito.