> Fine-tuning o RAG: come scegliere per il tuo caso d'uso
Fine-tuning e RAG risolvono lo stesso problema — adattare un LLM ai dati e al contesto specifico del tuo progetto — ma in modi completamente diversi. La scelta sbagliata costa tempo e denaro; quella giusta dipende da tre variabili concrete: i dati che hai, come cambiano, e quanto denaro puoi spendere in infrastruttura.
Chi inizia con i Large Language Model scopre presto che un modello generico (ChatGPT, Llama, Claude) non conosce i tuoi processi, i tuoi clienti, le tue regole di business. Allora la domanda naturale è: come lo adatto? E qui le due strade divergono drasticamente.
# La differenza fondamentale
RAG (Retrieval-Augmented Generation) significa: quando l'utente fa una domanda, il sistema cerca nel tuo archivio i documenti rilevanti e li passa al modello come contesto. Il modello rimane immutato.
Fine-tuning significa: modifichi il modello stesso, allenandolo su esempi specifici finché "impara" il tuo stile, i tuoi dati, le tue regole. Il risultato è un nuovo modello.
La distinzione è critica perché hanno costi, tempi, limiti e manutenzione completamente diversi.
# Quando scegliere RAG
RAG è il punto di partenza giusto in quasi tutti i casi. Usa RAG quando:
- I tuoi dati cambiano frequentemente. Se aggiorni documenti, FAQ, procedure ogni settimana, RAG si adatta senza toccare il modello. Fine-tuning richiederebbe un re-training ogni volta.
- Non hai abbastanza dati etichettati. Fine-tuning serio richiede centinaia o migliaia di esempi (input-output) ben formattati. Se ne hai 50, RAG è l'unica opzione.
- I dati sono già in forma di documenti, PDF, database. RAG eccelle a cercare e citare fonti. L'utente vede cosa ha inspirato la risposta; è più tracciabile e affidabile per compliance.
- Vuoi evitare i costi di training. Il fine-tuning richiede API costose (OpenAI fine-tuning: tra 0,03 e 0,30 dollari per 1.000 token di training, dipende dal modello), oppure GPU potenti se usi modelli open-source. RAG usa semplicemente un'API di embedding (economica) e una ricerca vettoriale.
- Hai bisogno di update senza downtime. Aggiungi documenti al tuo database di RAG mentre il sistema è in produzione. Fine-tuning richiede deployment di una nuova versione del modello.
In pratica: se il tuo problema è "il modello non conosce le mie FAQ, i miei documenti, le mie policies", RAG lo risolve in 1-2 settimane di lavoro.
# Quando scegliere fine-tuning
Fine-tuning ha senso in casi specifici e più rari:
- Devi insegnare uno stile o un formato fisso. Esempio: il modello deve generare sempre report nel tuo formato aziendale, con sezioni specifiche, tono specifico. Fine-tuning rende questa coerenza automatica.
- Hai centinaia di esempi input-output annotati. Se hai 500+ coppie di domande e risposte "giuste", o 500+ conversazioni con un cliente, puoi sfruttare il fine-tuning per specializzare il modello.
- I dati sensibili non escono dalla tua infrastruttura. Fine-tuning locale su hardware tuo significa nessun dato a OpenAI o Anthropic. Se lavori in regulated industries (sanità, finanza), questo conta.
- Il RAG non è abbastanza veloce o preciso. Caso raro: se retrievi milioni di documenti e il modello si distrae dalle istruzioni specifiche, a volte il fine-tuning aiuta a enfatizzare certi comportamenti. Ma di solito il problema è il retrieval, non il modello.
- Usi modelli open-source e hai budget per GPU. Con Llama, Mistral, o Phi, puoi fare fine-tuning in-house senza pagare API. Se hai accesso a un cluster GPU, i costi operativi sono contenuti.
In pratica: il fine-tuning conviene quando il cambiamento che devi fare è nel "cervello" del modello, non nei dati che consulta.
# Una tabella comparativa
| Criterio | RAG | Fine-tuning |
|---|---|---|
| Tempi di implementazione | 1-2 settimane | 3-8 settimane |
| Costo setup iniziale | € 2.000-5.000 | € 5.000-15.000 |
| Costo operativo mensile | € 200-800 | € 300-2.000+ |
| Frequenza update dati | Continua (no re-training) | Richiede re-training |
| Dati minimi richiesti | Pochi (50+ documenti) | Molti (300+ esempi annotati) |
| Tracciabilità (sai la fonte della risposta?) | Sì, esplicita | No, scatola nera |
| Privacy (dati rimangono in-house) | No, se usi embedding API esterni | Sì, se fatto in-house |
| Scalabilità orizzontale | Facile | Complessa |
# L'errore più comune
Saltare diretto a fine-tuning credendo che sia la soluzione "più potente". Ho visto progetti che raccoglievano maniacalmente 200-300 esempi per un fine-tuning, quando RAG con 20-30 documenti ben scelti avrebbe risolto il problema in una frazione del tempo e del costo. Fine-tuning è una leva più pesante; usiamola solo se RAG davvero non ce la fa.
# Quando NON conviene nessuno dei due
Se il tuo problema è "il modello commette errori di logica" o "ho bisogno di una decisione determistica", nessuno dei due è la risposta. RAG e fine-tuning migliorano la conoscenza, non la correttezza matematica o il ragionamento logico rigoroso. Per quei casi usi una pipeline ibrida: modello per la parte generativa, regole/codice per la parte critica.
# Una decisione pratica: l'albero
Se devi decidere adesso:
- Hai dati strutturati (documenti, FAQ, database)? → Vai a RAG subito.
- I dati cambiano più di una volta al mese? → RAG. Fine-tuning è troppo lento a stare dietro.
- Hai già 300+ coppie input-output annotatе? → Considera il fine-tuning in parallelo a RAG, come secondo passo.
- Serve che il modello "dimentichi" dati pubblici e parli solo dei tuoi? → Fine-tuning, e con privacy ristretta.
- Non sei sicuro? → Parti con RAG. È reversibile, economico, veloce. Misuri i risultati. Se non bastano, evolvi verso fine-tuning.
Nella mia esperienza di chi lavora su questi sistemi, il 70-80% dei casi trova la soluzione sufficiente con RAG ben fatto. Fine-tuning è per il 15-20% rimasto, dove il problema è davvero nello stile o nel comportamento del modello, non nei dati che conosce.
// FAQ
Se uso sia RAG che fine-tuning insieme, ottengo il meglio dei due mondi?
Teoricamente sì, ma nella pratica non sempre. Se combini RAG (che passa documenti come contesto) e fine-tuning (che modifica il modello), il modello fine-tuned potrebbe ignorare il contesto di RAG per seguire ciò che ha imparato durante l'allenamento. L'approccio ibrido funziona meglio se: (1) prima fai un buon RAG e misuri i risultati, (2) solo allora raccogli i casi in cui RAG fallisce, (3) usi quelli per fine-tuning mirato su quei fallimenti. Sconsiglio di avviarli in parallelo "per sicurezza"; costa doppio e non è il doppio efficace.
Quanti documenti/esempi mi servono per cui RAG vale veramente la pena?
RAG funziona anche con pochi documenti se sono rilevanti. Ho visto chatbot efficaci con 15-20 PDF di FAQ ben indicizzati. Il limite pratico è: se hai meno di 5-10 documenti totali e la tua base di conoscenza è davvero microscopica, forse non serve nemmeno un LLM, basta un motore di ricerca classico o un albero decisionale. Per fine-tuning, il minimo sono 100-150 esempi (meglio 300+) ben formattati e coerenti, altrimenti il modello overfits o non impara nulla di stabile.
Il fine-tuning mi rende indipendente dal provider (OpenAI, Anthropic)?
Solo se usi modelli open-source (Llama, Mistral) e li fine-tuning in-house o su infrastruttura tua. Se usi l'API di OpenAI fine-tuning, rimani legato a OpenAI — il modello fine-tuned vive sui loro server e costa comunque per ogni query. Se vuoi vero lock-in avoidance, devi ospitare il modello tu, il che significa costi di infrastruttura non banali (GPU, bandwidth). RAG è più neutrale: puoi cambiare provider di embedding o LLM facilmente, perché i dati rimangono tuoi in un database vettoriale separato.
Vuoi valutare una soluzione simile per la tua azienda?
Dimmi il tuo caso, valuto la fattibilità e ti dico costi e tempi realistici. Il primo confronto è gratuito.