GenAI in 10 Minutes è una guida tecnica per ingegneri che vogliono padroneggiare lo sviluppo di applicazioni basate su LLM. L’obiettivo è fornire una mappa operativa chiara per navigare la complessità della GenAI, focalizzandosi sui trade-off architetturali e sulle best practice necessarie per passare dal prototipo alla produzione.

Contenuti della serie:

1. Dalle basi ai Foundation Model
2. Progettare l’Architettura di un’Applicazione Enterprise
3. Controllo dell’Inference tramite Prompt Engineering
4. Retrieval-Augmented Generation (RAG) e Knowledge Integration
5. FINE-TUNING E ALLINEAMENTO (questo articolo)
6. Architetture di Deployment, Serving e Scalabilità dei Modelli
7. Eval Automatici e Monitoring della Qualità
8. Sicurezza dei Sistemi GenAI

Questo articolo chiarisce quando il fine-tuning è la scelta giusta (vs prompt/RAG) e quali tecniche usare per cambiare comportamento, stile o formati con costi sostenibili.

Quando servono risposte consistenti per stile, tono o formati rigidi, l’approccio basato su prompt e contesto recuperato può non essere sufficiente. In questi casi, l’intervento si sposta dal guidare il modello al modificarne in modo mirato il comportamento.

Può accadere che un modello risponda correttamente, ma non mantenga un tono coerente con un brand, oppure fallisca in modo ricorrente su formati rigidi (es. JSON complessi per integrazioni). In altri casi, l’obiettivo è ottenere prestazioni vicine a quelle di un modello di fascia alta con costi e latenza compatibili con modelli più piccoli.

Quando le istruzioni e il contesto non sono sufficienti, bisogna intervenire modificando il modello stesso. È il momento del Fine-Tuning.

Se il Prompt Engineering è come dare istruzioni a un neolaureato brillante, il Fine-Tuning è iscriverlo a un master specialistico intensivo. Vediamo come trasformare un modello generalista in uno specialista verticale.

Fine-Tuning applicativo: significato e criteri di scelta

Il termine fine-tuning viene spesso usato per descrivere due fasi concettualmente diverse nel ciclo di vita di un modello.

La prima avviene prima del rilascio ed è tipicamente in carico ai produttori del modello (OpenAI, Google, Meta, ecc.). Come visto nel primo articolo della serie, dopo il pre-training si ottiene un base model, potente ma non ancora adatto all’interazione. Per renderlo utilizzabile come assistente, viene applicato un ulteriore strato di addestramento di alignment (ad esempio instruction fine-tuning e RLHF), che insegna a seguire istruzioni, mantenere un dialogo coerente e rifiutare richieste dannose. Questa fase è parte della costruzione del prodotto-modello e si colloca su scale di costo e infrastruttura non confrontabili con quelle tipiche di un team applicativo.

La seconda, che interessa lo sviluppo di applicazioni, è il fine-tuning post-rilascio e application-oriented: si parte in genere da un modello già instruction-tuned/chat-tuned e lo si specializza su un dominio o un compito specifico. L’obiettivo non è aumentare le capacità generali del modello, ma adattarne stabilmente il comportamento (tono, stile, struttura dell’output, affidabilità su un task) rispetto a requisiti operativi. Anche in questo caso l’intervento modifica i parametri (i pesi) e produce un nuovo artefatto da gestire e rilasciare.

Da qui discende una distinzione pratica importante:

• Prompting/RAG ⭢ modificano l’input e il contesto al momento dell’inferenza. Il modello rimane invariato.
• Fine-Tuning ⭢ modifica il modello. Il cambiamento è permanente e va governato (versioning, eval, deploy).

Il fine-tuning applicativo resta un’operazione costosa e complessa rispetto a prompt engineering e RAG: richiede un dataset di alta qualità, tempo di sperimentazione e risorse computazionali; nelle forme complete (discusse di seguito) può richiedere GPU di fascia alta e portare a costi rilevanti anche per un singolo esperimento. Per questo non è una prima opzione, ma una scelta da motivare quando le alternative più agili non raggiungono i requisiti.

La regola pratica è: non usare il fine-tuning per insegnare fatti. Se serve coprire informazioni aggiornate (listini, policy, documentazione recente), l’approccio corretto è la RAG: è più manutenibile e riduce il rischio di rendere la conoscenza statica o di introdurre incoerenze.

Il fine-tuning è appropriato quando il problema riguarda comportamento o forma:

• Stile e tono ⭢ se è necessario un registro stabile, non fragile rispetto alla durata della conversazione.
• Formato (output strutturato) ⭢ se serve alta affidabilità nel generare strutture rigide (ad esempio JSON o SQL complessi) per integrazioni software.
• Ottimizzazione (distillazione) ⭢ se un modello di frontiera è troppo costoso o lento, si può usare per generare dati di training e specializzare un modello più piccolo sul task rilevante.

Un criterio operativo conservativo è procedere per gradi: si parte da prompting avanzato e RAG e si considera il fine-tuning solo se, dopo test mirati, questi approcci non soddisfano requisiti di affidabilità, costo o qualità.

Le Tecniche: Dal Full Fine-Tuning al PEFT

Fino a poco tempo fa, fare Fine-Tuning significava aggiornare tutti i miliardi di parametri del modello (Full Fine-Tuning). Richiedeva cluster di GPU di fascia alta e budget elevati. Anche versioni più light, come fare freezing di alcuni parametri (letteralmente, congelarli durante l’addestramento), è spesso impraticabile per ragioni di costi e risorse computazionali richieste.

La velocità con cui i modelli evolvono richiede cicli di iterazione rapidi. Con un approccio lento può accadere che, durante l’addestramento, venga rilasciato un nuovo modello di base che rende meno conveniente proseguire con la specializzazione.

La rivoluzione a questi problemi è arrivata con il PEFT (Parameter-Efficient Fine-Tuning). Invece di modificare tutto il modello, si congelano i pesi originali e si aggiungono piccoli moduli aggiuntivi che vengono addestrati in modo efficiente.

LoRA e QLoRA: Lo standard de facto

La tecnica regina oggi è LoRA (Low-Rank Adaptation). Senza entrare troppo nella matematica delle matrici: LoRA aggiunge un numero ridotto di parametri addestrabili (i LoRA adapter) tra i layer del modello, mantenendo congelati i pesi originali.

L’intuizione è che, invece di riscrivere tutti i pesi, si apprenda una variazione a bassa dimensionalità che modifica in modo controllato il comportamento del modello. Il risultato è un addestramento più efficiente e, soprattutto, un artefatto finale (i LoRA adapter) che può essere versionato e gestito come un componente separato rispetto al modello base.

Il risultato immediato è che l’addestramento diventa molto più leggero. Inoltre, questa tecnica introduce vantaggi pratici:

• Archiviazione minima ⭢ I LoRA adapter sono tipicamente molto più piccoli del modello completo, semplificando versioning e distribuzione.
• Hot-Swapping e Multi-Tenancy ⭢ È possibile caricare una sola volta il modello base e applicare dinamicamente adapter diversi a seconda del contesto o del tenant, riducendo costi e complessità operativa.

Ma non basta. Spesso anche solo caricare il modello base richiede troppa memoria per una GPU comune. Qui entra in gioco la Quantizzazione.

Si può vedere la quantizzazione come una compressione intelligente. I pesi di un modello sono normalmente salvati come numeri ad altissima precisione (es. a 16 o 32 bit). La quantizzazione riduce questa precisione (es. a 4 bit), un po’ come quando si riduce la risoluzione di un’immagine ad alta definizione: l’immagine occupa molto meno spazio, ma a occhio nudo sembra quasi identica.

Storicamente, la quantizzazione era considerata particolarmente adatta all’inferenza, mentre risultava più delicata in addestramento: lavorare con pesi a bassa precisione può degradare l’apprendimento. QLoRA affronta il problema separando i ruoli: il modello base può essere caricato quantizzato per ridurre il footprint di memoria, mentre l’aggiornamento avviene sui LoRA adapter (mantenuti a precisione più alta). Questo approccio consente di contenere costi e requisiti hardware senza rinunciare alla qualità del fine-tuning.

Se si combinano queste due tecnologie, si ottiene QLoRA (Quantized LoRA): il modello base viene caricato quantizzato (riducendo la memoria occupata) e si addestrano i LoRA adapter mantenendo precisione adeguata per l’apprendimento. In pratica, QLoRA riduce in modo ancora più significativo i requisiti hardware per il fine-tuning.

Il Carburante: Il Dataset

Si possono avere GPU potenti e algoritmi raffinati, ma nel Machine Learning vige una legge ferrea: Garbage In, Garbage Out. La qualità del modello fine-tunato dipende in larga misura dalla qualità dei dati con cui viene addestrato.

Un errore comune è pensare che servano milioni di esempi. Nel fine-tuning, la qualità spesso batte la quantità. Il paper LIMA (Less Is More for Alignment) mostra che anche dataset relativamente piccoli (es. ~1.000 esempi) ma ad alta qualità possono essere competitivi rispetto a dataset molto più grandi ma rumorosi. Perché? Perché non stiamo insegnando al modello nuove conoscenze (per quello c’è la RAG), ma gli stiamo insegnando come comportarsi. E per imparare uno stile, la coerenza è molto più importante del volume.

Quindi, il vero lavoro dell’AI Engineer non è solo scrivere codice di training, ma anche (e soprattutto) curare il dataset.

In pratica, un dataset efficace tende a rispettare tre proprietà:

1 – Qualità (correttezza, rilevanza, atomicità) ⭢ ogni coppia input/output deve essere un esempio di riferimento del comportamento da insegnare.

• Correttezza ⭢ l’output è esattamente quello desiderato (non approssimativo); se l’obiettivo è un formato rigido (es. JSON), deve essere sempre valido e consistente.
• Rilevanza ⭢ gli esempi devono rappresentare i task reali attesi in produzione, non scenari ipotetici poco probabili.
• Atomicità ⭢ ogni esempio, quando possibile, deve insegnare una singola sfumatura (uno specifico pattern di risposta, un vincolo di formato, un tono), evitando campioni troppo compositi che mescolano molti obiettivi.

2 – Coerenza e specificità ⭢ il dataset deve incarnare in modo uniforme stile, tono, struttura e vincoli. Incoerenze interne (stesso input con risposte impostate in modi diversi, convenzioni di naming variabili, formati non allineati) confondono l’addestramento e portano a output instabili.

3 – Diversità e copertura ⭢ a parità di coerenza, serve varietà di formulazioni e scenari per ridurre l’overfitting e migliorare la generalizzazione.

• Formulazioni differenti ⭢ sinonimi, livelli di dettaglio diversi, rumore realistico (refusi, abbreviazioni).
• Casi limite ⭢ input ambigui, richieste incomplete, domande irrilevanti o richieste che il modello deve rifiutare.
• Copertura del dominio ⭢ gamma ampia di argomenti e situazioni operative, non solo i casi più frequenti.

Queste proprietà rendono più misurabile l’impatto del fine-tuning e riducono il rischio di regressioni tra versioni successive, perché spostano l’attenzione dalla quantità di addestramento a ciò che viene effettivamente insegnato.

Ma come si ottiene un dataset di questo tipo? Ci sono due strade principali:

1 – Human-Generated ⭢ Log di chat di supporto, email commerciali, report interni e altri artefatti operativi possono costituire una base preziosa.

• La sfida: i dati reali sono spesso grezzi e richiedono filtraggio rigoroso (rimozione di risposte errate, correzioni) e soprattutto anonimizzazione (nomi, carte di credito e dati PII) per non violare la privacy. In alternativa, se non si dispone di dati reali, è possibile creare esempi manualmente, ma richiede tempo e competenze specifiche.

2 – Synthetic Data ⭢ Se i dati storici sono pochi, si può usare un modello più potente per generare esempi ad alta qualità.

• La tecnica: scrivere un meta-prompt dettagliato per generare conversazioni o coppie input/output rappresentative del caso d’uso. In pratica, un modello (Teacher) genera dati su cui si specializza un modello più piccolo (Student).
• Nota: anche in questo caso è necessaria una revisione umana a campione per ridurre il rischio che il modello assorba errori o allucinazioni.

Per quanto riguarda il formato dei dati, dipende dall’obiettivo del fine-tuning. Il formato standard oggi è quello Chat (una lista JSON di messaggi con ruoli system, user, assistant), che è diventato lo standard universale digerito nativamente da tutti i framework moderni.

L’Addestramento: Entrare nel cuore del Machine Learning

Lanciare il training (usando librerie come Hugging Face Transformers) non è un’operazione che si configura una sola volta e poi si lascia procedere in automatico. È un esperimento di Machine Learning che richiede scelte esplicite e verifica continua. Tra gli iperparametri più rilevanti:

• Epoche ⭢ numero di passaggi completi sul dataset. Troppe epoche aumentano il rischio di overfitting e memorizzazione; troppo poche portano a underfitting.
• Learning Rate ⭢ ampiezza degli aggiornamenti dei pesi. Un valore troppo alto rende l’ottimizzazione instabile o divergente; troppo basso rallenta la convergenza.

Ma soprattutto, vanno osservate le curve della Loss (l’errore). In genere si monitorano due linee:

• Training Loss ⭢ loss calcolata sul training set. In condizioni sane tende a diminuire.
• Validation Loss ⭢ loss calcolata su un validation set non usato per aggiornare i pesi. Serve a stimare la generalizzazione.

Se la Training Loss scende ma la Validation Loss inizia a salire, si è in overfitting: il modello sta iniziando a memorizzare il training set. In questo scenario è opportuno interrompere l’esperimento o intervenire su dati e configurazione.

Questo è solo il minimo. Il fine-tuning richiede competenze ML e disciplina sperimentale: non coincide con l’esecuzione di trainer.train() . Include ciò che avviene prima (pulizia dati, bilanciamento, definizione dell’obiettivo e baseline), durante (monitoraggio e controllo della stabilità) e dopo (verifiche tramite eval e integrazione in pipeline di deployment).

Per questo conviene valutare prima le soluzioni più semplici e considerare il fine-tuning solo quando:

• Gli obiettivi sono chiari e misurabili.
• Esiste una giustificazione dei costi e dei rischi rispetto alle alternative.
• Sono disponibili competenze e risorse adeguate per condurre esperimenti e governare il rilascio.

Key Takeaways

➭ COMPORTAMENTO, NON CONOSCENZA
Il fine-tuning è adatto a stile, tono e formato; per i fatti e la conoscenza aggiornata la scelta corretta è la RAG.

➭ QUALITÀ > QUANTITÀ
Meglio un dataset piccolo e curato che un dataset grande ma rumoroso.

➭ EFFICIENZA CON PEFT
Tecniche come LoRA e QLoRA riducono i requisiti computazionali rispetto al full fine-tuning.

➭ MONITORAGGIO ATTIVO
Il training va seguito: le curve di loss aiutano a individuare overfitting e instabilità.

Ora c’è un modello specializzato: controllabile via prompt, ancorato a conoscenza esterna via RAG e adattato nel comportamento via fine-tuning. Il passo successivo è renderlo operativo in produzione in modo affidabile: nel prossimo articolo entriamo nel mondo dell’LLMOps e del deployment.