Quando il fine-tuning supera il prompting

Quando è necessario che un LLM si comporti in un modo specifico, si hanno due opzioni fondamentali: il prompt engineering (indicare al modello cosa fare al momento dell’inferenza usando prompt elaborati con cura) oppure il fine-tuning (insegnare al modello nuovi comportamenti addestrandolo su esempi). Entrambi possono produrre risultati simili per molte attività, ma differiscono notevolmente in termini di costi, velocità, flessibilità e livello qualitativo massimo raggiungibile.

Il prompting è quasi sempre il punto di partenza giusto. Non richiede un’infrastruttura di addestramento, produce risultati nel giro di poche ore, può essere aggiornato immediatamente senza ripetere l’addestramento e funziona bene per le attività che il modello di base sa già gestire in modo adeguato. Inizi con il prompting per: attività in cui GPT-4o o Claude produce già risultati accettabili con istruzioni chiare, requisiti che cambiano rapidamente, casi d’uso a basso volume e situazioni in cui si sta ancora esplorando il problema.

Il fine-tuning è la scelta migliore quando è necessario un formato di output rigorosamente coerente che il prompting non riesce a garantire in modo affidabile. Se l’applicazione richiede il rispetto al 100% di uno specifico schema JSON, di un formato documentale strutturato con precisione o di uno stile di scrittura molto particolare, diverso dall’output naturale del modello, un fine-tuning con qualche centinaio di esempi può raggiungere una coerenza quasi perfetta, che nemmeno il prompt progettato con la massima cura riesce a garantire.

Il fine-tuning è la scelta giusta quando il modello deve apprendere conoscenze che non esistono nei dati di addestramento pubblici: le convenzioni interne di programmazione della sua azienda, una tassonomia proprietaria per classificare i documenti, una terminologia legale o medica specializzata in un settore di nicchia oppure le linee guida specifiche sul tono e sullo stile del suo brand. Queste conoscenze non possono essere trasmesse efficacemente tramite esempi nel prompt, perché il volume degli esempi supera ciò che può essere contenuto in una finestra di contesto.

Un importante argomento economico a favore del fine-tuning è la compressione del prompt. Un prompt di sistema complesso può contenere 2000 token. Se si chiama l’API 10 milioni di volte al giorno, quei 2000 token costano decine di migliaia di dollari al mese. Un modello sottoposto a fine-tuning può essere guidato da un prompt molto più breve (50-100 token), perché le istruzioni dettagliate sono ormai incorporate nei pesi. Su larga scala, questo può ridurre i costi dei token di input del 90% o più.

I modelli sottoposti a fine-tuning possono migliorare la latenza in due modi. Innanzitutto, prompt più brevi significano che il modello elabora meno token di input, riducendo direttamente il tempo necessario per generare il primo token. Inoltre, i modelli sottoposti a fine-tuning spesso convergono più rapidamente verso il formato corretto (generano meno token nella risposta prima di arrivare alla risposta effettiva), riducendo il numero totale di token di output e il tempo di generazione. Per le applicazioni sensibili alla latenza, entrambi gli effetti si sommano e producono miglioramenti significativi.

Il fine-tuning richiede dati di addestramento e questo rappresenta spesso il principale ostacolo pratico. Come regola generale: servono almeno 50-100 esempi di alta qualità per osservare un miglioramento significativo rispetto al modello di base, 500-1000 esempi per ottenere un rispetto affidabile dello stile e del formato e 1000-10.000 esempi per acquisire una quantità significativa di conoscenze di dominio. Al di sotto dei 50 esempi, il prompting con gli stessi esempi nel contesto (few-shot) offrirà solitamente prestazioni migliori del fine-tuning.

Il fine-tuning comporta costi nascosti significativi oltre a quelli di calcolo. Servono: un’infrastruttura per eseguire l’addestramento (ore GPU o un servizio gestito), un processo per raccogliere i dati e controllarne la qualità, una valutazione per verificare che il modello sottoposto a fine-tuning migliori effettivamente la metrica obiettivo, una pipeline di deployment per il modello personalizzato e un processo di manutenzione continua per ripetere l’addestramento quando il modello di base viene aggiornato o cambiano i requisiti. Questi costi sono reali e devono essere valutati rispetto ai vantaggi.

Il fine-tuning non può aggiornare le conoscenze in tempo reale. Le conoscenze di un modello sottoposto a fine-tuning restano congelate al momento dell’addestramento. Per i casi d’uso che richiedono informazioni aggiornate (eventi attuali, prezzi in tempo reale, normative soggette a cambiamenti), il RAG è sempre la scelta migliore, perché può recuperare informazioni aggiornate al momento della richiesta. Il fine-tuning è invece ideale per le conoscenze durature che cambiano raramente: lo stile di scrittura dell’azienda, la tassonomia per categorizzare i prodotti o il vocabolario tecnico di un settore consolidato.

Utilizzi questo framework decisionale prima di impegnarsi nel fine-tuning. Innanzitutto, dimostri che è necessario: esegua il prompt migliore su 1000 esempi reali e misuri il tasso di errore. In secondo luogo, quantifichi il vantaggio: stimi il ROI derivante da una maggiore accuratezza, da costi inferiori dei token o da una latenza migliore. Terzo, valuti la fattibilità: dispone di oltre 500 esempi di addestramento di alta qualità? Infine, confronti le alternative: un modello più piccolo con un prompt migliore potrebbe raggiungere le prestazioni di un modello più grande con un prompt complesso?

I migliori sistemi di produzione spesso combinano entrambi gli approcci. Usi il fine-tuning per le proprietà durature (formato dell’output, tono, vocabolario di dominio) che cambiano raramente e i prompt per le proprietà dinamiche (contesto dell’attività, documenti recuperati, preferenze dell’utente) che cambiano a ogni richiesta. Questa combinazione offre l’affidabilità e l’efficienza dei costi del fine-tuning senza sacrificare la flessibilità del prompting.

In questa lezione ha imparato che il prompting è quasi sempre il punto di partenza giusto grazie ai costi inferiori e alla maggiore rapidità di iterazione, che il fine-tuning è la scelta migliore per il rispetto coerente del formato, le conoscenze proprietarie del dominio e la riduzione dei costi dei token in caso di volumi elevati e che l’aggiornamento delle conoscenze è l’ambito del RAG: il fine-tuning non può aggiornare ciò che un modello conosce durante l’esecuzione. Nella prossima lezione prepareremo un dataset di addestramento di alta qualità per il fine-tuning.