Fine-tuning: cosa cambia quando si continua ad addestrare un modello e cosa non garantisce

Che cosa significa fine-tuning

Il fine-tuning, o messa a punto, è l’addestramento aggiuntivo di un modello già addestrato in precedenza, con l’obiettivo di adattarne il comportamento a un determinato compito, dominio o formato. L’idea centrale è modificare un modello esistente tramite una nuova fase di addestramento: non si tratta semplicemente di dargli un’istruzione per una singola richiesta.

L’obiettivo di adattamento deve essere formulato con sufficiente chiarezza da orientare sia i dati sia la valutazione. Può consistere, per esempio, nell’assegnare categorie a dei testi o nel generare risposte che rispettino una struttura. Dire «far funzionare meglio il modello» è troppo vago se non si specifica per quale compito, con quali esempi e in base a quale criterio si giudicherà il miglioramento.

Il termine, da solo, non specifica quali parti interne del modello cambino. A seconda del metodo utilizzato, l’addestramento può modificare l’insieme dei parametri del modello oppure limitare gli aggiornamenti a una parte del modello o a parametri aggiunti. Le fonti disponibili sostengono la definizione generale del fine-tuning come addestramento o adattamento di un modello preaddestrato, ma non documentano nel dettaglio le diverse modalità di aggiornamento dei parametri. Occorre quindi verificare l’ambito concreto nella documentazione del metodo e del modello scelti.

Il ciclo: obiettivo, dati, addestramento e valutazione

Un processo di fine-tuning può essere interpretato come una sequenza di decisioni. Per prima cosa si sceglie un modello di partenza e si definisce quale comportamento si vuole adattare. Si preparano poi esempi che rappresentino quell’obiettivo, si esegue l’addestramento con un metodo specifico e si valuta il risultato. La decisione finale non riguarda il fatto che il modello sia cambiato, ma se il cambiamento osservato sia utile per l’uso previsto.

Gli esempi dovrebbero corrispondere al compito reale negli aspetti importanti: input, output attesi, categorie o formato. Se si vuole classificare delle richieste, per esempio, è utile definire chiaramente le categorie e includere casi che rappresentino la varietà che il sistema riceverà. Un insieme di esempi poco rappresentativo può portare a conclusioni che non reggono quando cambia il tipo di input.

Per valutare il risultato occorre distinguere i casi usati durante l’addestramento da quelli impiegati per verificarlo. Se il successo viene misurato sugli stessi esempi utilizzati per addestrare il modello, non si ottiene una verifica indipendente di come risponderà a casi nuovi. La documentazione fornita indica la valutazione come parte dei flussi di lavoro di ottimizzazione e fine-tuning, ma non definisce un protocollo universale né soglie valide per tutti i compiti.

La decisione finale dipende da criteri definiti prima della prova: quali errori contano, quale risultato è accettabile e in quali condizioni si userà il modello. Un miglioramento in una metrica scelta non equivale, di per sé, a un miglioramento generale. Né permette di dedurre che il sistema sia sicuro o accurato in situazioni che non sono state valutate.

Esempio: classificare le richieste di assistenza

Immaginiamo un servizio che riceve messaggi relativi a fatturazione, accesso agli account, problemi tecnici e cancellazioni. Un team vuole che un modello assegni ogni messaggio a una categoria definita dal servizio. In questo esempio, il fine-tuning consisterebbe nell’adattare un modello preaddestrato con esempi di messaggi e le rispettive categorie attese, così da orientarne il comportamento verso questa classificazione.

Prima dell’addestramento, sarebbe necessario definire il significato di ogni categoria e stabilire come gestire le richieste ambigue o quelle che non rientrano in nessuna categoria. Se il team mescola etichette simili, ne cambia i nomi senza un criterio o include messaggi contraddittori, gli esempi non comunicano più una convenzione coerente. Il fine-tuning non risolve automaticamente la mancanza di accordo sulle categorie.

La valutazione potrebbe includere messaggi diversi da quelli usati per l’addestramento, per esempio richieste con più esigenze o descrizioni brevi. Il team verificherebbe non soltanto la percentuale complessiva di risposte corrette, ma anche quali tipi di richieste vengono confusi e quali conseguenze potrebbero avere gli errori. La misura adeguata dipende dall’uso: una classificazione che serve soltanto a organizzare una casella di posta può avere requisiti diversi da una che attiva azioni automatiche.

Questo caso illustra una possibile forma di adattamento, non un risultato dimostrato. Non implica che il modello riconoscerà tutte le espressioni dei clienti, che le categorie siano adatte a qualsiasi organizzazione o che il fine-tuning sia necessariamente la soluzione migliore rispetto alle alternative.

Esempio: ispezione di immagini industriali

In una linea di ispezione si potrebbe valutare l’adattamento di un modello di visione per classificare le immagini in base a tipi di difetto definiti dal team. Gli esempi di addestramento sarebbero immagini associate alle relative etichette. L’obiettivo non sarebbe «comprendere la fabbrica» in generale, ma svolgere un compito circoscritto nelle condizioni di acquisizione delle immagini rappresentate dai dati.

Per preparare i dati occorre concordare che cosa costituisce ciascun difetto e come trattare le immagini sfocate, i pezzi parzialmente nascosti o i casi in cui un’immagine non permette di decidere. È inoltre importante verificare che gli esempi coprano la diversità rilevante del processo. Una raccolta di immagini ottenuta in condizioni molto uniformi potrebbe non rappresentare cambiamenti di illuminazione, telecamere, materiali o fasi di produzione che si presenteranno in seguito.

La verifica dovrebbe essere effettuata con immagini non utilizzate per mettere a punto il modello e, se lo scopo lo richiede, in condizioni diverse da quelle degli esempi di addestramento. I criteri di successo devono tenere conto degli errori concreti: non rilevare un difetto e segnalare come difettoso un pezzo corretto possono avere conseguenze diverse. Questa scheda non propone una soglia né afferma che un metodo specifico sia adatto a un determinato impianto.

L’esempio mostra che il fine-tuning non si limita ai modelli linguistici. Le fonti fornite comprendono una spiegazione introduttiva dell’adattamento dei modelli di apprendimento automatico e un riferimento specifico al campo della visione; gli estratti disponibili, tuttavia, non dimostrano dettagli di implementazione né risultati di ispezione.

Esempio: referti clinici con una struttura definita

Un team potrebbe valutare l’adattamento di un modello linguistico per organizzare informazioni fornite e redigere una bozza con campi prestabiliti, come motivo della visita, anamnesi e piano. L’obiettivo del fine-tuning sarebbe rispettare una struttura o una convenzione di output. Questo esempio non implica che il sistema possa formulare diagnosi, consigliare trattamenti o produrre documentazione clinicamente valida.

Gli esempi dovrebbero rispecchiare il formato richiesto e le regole da seguire quando un dato manca, le informazioni sono ambigue o compaiono contraddizioni. Altrimenti il modello potrebbe completare i campi con contenuti non forniti o presentare come certa un’interpretazione che richiede una revisione. La valutazione dovrebbe verificare ogni campo e non limitarsi a giudicare se il testo appare scorrevole.

In un contesto clinico, l’adeguatezza del formato non dimostra l’accuratezza dei contenuti. Sarebbe inoltre necessario valutare chi controlla la bozza, quali informazioni possono essere inserite e quali conseguenze potrebbe avere un errore. Questi aspetti riguardano la valutazione del sistema e il suo contesto d’uso: non vengono risolti dal semplice fatto di aver messo a punto un modello.

Il caso è illustrativo, non costituisce una raccomandazione per l’uso clinico né afferma che il fine-tuning garantisca risultati adeguati. Le fonti incluse offrono definizioni generali e non documentano le prestazioni di uno specifico sistema clinico.

Fine-tuning e concetti affini

Il fine-tuning può essere confuso con altri modi di orientare o ampliare l’uso di un modello. Una distinzione pratica consiste nel chiedersi dove viene introdotto il cambiamento: si forniscono istruzioni al modello in una richiesta? Si recuperano documenti esterni per rispondere? Si addestra il modello con dati aggiuntivi? Oppure si trasforma un modello per generarne uno più piccolo? Queste opzioni non sono nomi intercambiabili per una stessa operazione.

Nell’apprendimento in contesto, istruzioni o esempi vengono forniti come parte dell’input di una richiesta. Questa descrizione è diversa dalla definizione del fine-tuning come addestramento aggiuntivo. I materiali disponibili non sviluppano in modo specifico questo confronto; è quindi opportuno considerarlo una distinzione concettuale generale e verificare il comportamento di ciascun sistema nella relativa documentazione.

In un’architettura di generazione aumentata dal recupero, nota come RAG, la questione centrale è come incorporare documenti esterni durante la richiesta. In linea di principio, questo è diverso dall’aggiornare i parametri tramite addestramento. Le fonti fornite, però, non includono una spiegazione verificabile di RAG e non permettono di stabilire in quali condizioni sarebbe preferibile al fine-tuning. Non si deve dedurre che una soluzione sostituisca sempre l’altra.

Anche la continuazione del preaddestramento comporta un addestramento aggiuntivo, ma non va automaticamente equiparata al fine-tuning orientato a un compito specifico. Per spiegare con precisione la differenza servirebbero fonti che descrivano gli obiettivi e i dati di addestramento di entrambe le fasi; gli estratti disponibili non sono sufficienti a definire questi confini.

La distillazione è un altro termine che ricorre nelle conversazioni sui modelli, ma neppure questo processo è documentato dalle fonti fornite. Perciò, qui non viene presentata come una variante del fine-tuning e non si attribuiscono ai due processi fasi equivalenti. Se una decisione di progetto dipende da questo confronto, occorre consultare documentazione tecnica specifica.

LoRA e ambito dei parametri

LoRA viene spesso menzionata nelle conversazioni sull’adattamento dei modelli, ma le fonti verificate che accompagnano questa scheda non spiegano la tecnica né documentano in modo specifico il suo rapporto con il fine-tuning. Per rigore, qui non se ne descrive il funzionamento e non le si attribuiscono caratteristiche di costo, qualità o prestazioni. Si può però formulare una cautela terminologica: non è opportuno usare «LoRA» come sinonimo automatico di «fine-tuning» senza verificare quale metodo sia stato applicato.

Anche la questione dei parametri aggiornati richiede precisione. Una definizione fornita da una delle fonti afferma che il fine-tuning modifica almeno un parametro di un modello preaddestrato; altre fonti descrivono il processo più in generale come adattamento o addestramento aggiuntivo. Nessuno degli estratti disponibili permette di affermare che tutti i metodi aggiornino tutti i parametri o di descrivere in modo affidabile le alternative.

In una scheda tecnica o in una proposta di progetto è preferibile indicare il metodo preciso e consultare la documentazione corrispondente: che cosa viene addestrato, che cosa rimane fisso e quali componenti, se presenti, vengono aggiunti. Senza queste informazioni, «mettere a punto il modello» descrive l’intenzione generale, ma non basta a dedurre l’architettura dell’addestramento.

Che cosa non garantisce e come decidere

Il fine-tuning non garantisce la generalizzazione a input diversi da quelli valutati, l’accuratezza in tutti i casi, la sicurezza o prestazioni migliori al di fuori delle condizioni di prova. Un risultato positivo su un compito circoscritto informa soltanto sul criterio misurato e sull’insieme di valutazione utilizzato. Non dimostra automaticamente che il modello si comporterà allo stesso modo con altri utenti, dati, formati o contesti.

L’overfitting è una preoccupazione ricorrente quando si valuta un modello addestrato su esempi limitati, ma le fonti fornite non presentano un’analisi tecnica che consenta di quantificarlo o di specificare come rilevarlo in ogni caso. È prudente non basare le conclusioni soltanto sui dati di addestramento e documentare quali casi sono stati riservati alla valutazione. La scelta concreta del metodo richiede ulteriori fonti tecniche.

Prima di decidere, definire il comportamento necessario, il costo degli errori e il modo in cui verrà verificato il risultato. Confrontare il fine-tuning con le alternative pertinenti al caso, senza presumere che una soluzione sia migliore se non è stata misurata. Se le prove disponibili non riguardano il metodo, il dominio o le condizioni d’uso, questa mancanza di informazioni deve far parte della decisione.

Questa scheda appartiene al glossario sull’IA: è un punto di partenza per comprendere il termine, non una ricetta di implementazione. Per proseguire, consultare la voce del glossario sul fine-tuning e le pagine comparative del glossario; ogni decisione tecnica dovrebbe inoltre basarsi sulla documentazione specifica del modello e del metodo.

Concetti correlati