RAG o fine-tuning: la regola dell'80/15/5

Il modello risponde con sicurezza, ma sbaglia: non ha mai letto l’ultimo report trimestrale. Da qui in poi ogni progetto AI si trova davanti allo stesso bivio. Gli si passano i documenti nel momento in cui deve rispondere (RAG), oppure lo si riaddestra perché li faccia suoi (fine-tuning)? Le due strade risolvono problemi diversi, costano cifre diverse e si sbagliano in modi diversi. Questa lezione serve a scegliere senza ansia.

L’esame a libro aperto e lo studio matto e disperatissimo

Lo studente con il libro aperto sul banco ha accesso a tutte le informazioni ma non le ha interiorizzate. Se il professore cambia edizione all’ultimo minuto, nessun problema: si sfoglia il testo nuovo e le risposte cambiano all’istante. È il RAG: i documenti vengono recuperati e passati al modello dentro il prompt, ogni volta, e il modello resta identico.

Lo studente che ha fatto mesi di studio non ha più bisogno del libro: la materia è entrata nel suo modo di ragionare. Ma se i dati cambiano, aggiornarsi al volo è impossibile senza rimettersi a studiare da capo. È il fine-tuning: un addestramento che modifica i pesi del modello in modo permanente.

C’è anche lo studente preparato che porta comunque i suoi appunti: il meglio dei due mondi, e anche il più costoso. Ne parliamo tra poco, perché è la combinazione giusta più spesso di quanto sembri.

Dati contro comportamento

Messe da parte le metafore, la differenza vera sta in una parola: il RAG agisce sui dati, il fine-tuning sul comportamento.

Aspetto	RAG	Fine-tuning
Cosa fa	Fornisce contesto temporaneo nel prompt	Modifica i pesi del modello
Il modello cambia?	No, resta identico	Sì, in modo permanente
Costo di setup	Basso: vector DB + modello di embedding	Alto: GPU, dataset, addestramento
Costo per richiesta	Medio: embedding + ricerca + generazione	Basso: solo generazione
Tempo di setup	Ore (indicizzare i documenti)	Giorni o settimane
Aggiornare	Aggiungi o togli documenti	Riaddestra
Citare la fonte	Sì, con il passaggio esatto	No: la conoscenza è fusa nei pesi
Stile e tono	Non cambiano	Possono cambiare
Allucinazioni	Ridotte: la risposta è ancorata alle fonti	Possibili, anche sul dominio addestrato
Privacy	Documenti in un database che controllate	Dati “cotti” dentro il modello
Serve una GPU	No	Sì, per l’addestramento

Una riga di questa tabella vale più delle altre: citare la fonte. Se qualcuno vi chiederà mai “da dove viene questa risposta?”, il fine-tuning non saprà rispondere. Il RAG sì.

La regola 80/15/5

Nella pratica i casi si distribuiscono più o meno così.

L’80% dei progetti si risolve con il RAG. Knowledge base aziendali, manuali, procedure, documentazione tecnica che cambia, normative, listini, il proprio archivio di appunti. Il modello sa già ragionare, riassumere e confrontare: gli mancano solo i dati, e i dati cambiano. Un esempio tipico è la policy aziendale sulle ferie: il RAG cerca nella knowledge base, il modello risponde citando il documento, e quando la policy cambia basta sostituire il file.

Il 15% ha bisogno di entrambi. Un assistente con un tono molto preciso che deve però leggere dati aggiornati; un “esperto di dominio” che ragiona come un medico e consulta le ultime linee guida; un sistema che deve rispettare un formato di output rigido e basarsi su documenti freschi. La divisione del lavoro è netta: il fine-tuning insegna come rispondere, il RAG fornisce su cosa.

Il 5% è fine-tuning puro. Cambiare radicalmente lo stile di scrittura (un modello che scrive in dialetto), un compito ripetitivo e specialistico (classificare migliaia di ticket con le categorie interne dell’azienda), una lingua poco supportata, un linguaggio di programmazione proprietario. Qui non si tratta di dare più informazioni: il modello deve pensare diversamente.

L’albero decisionale in due domande

Il modello risponde già bene con un buon prompt?
├── SÌ → Il problema è che non ha i DATI giusti?
│        ├── SÌ → RAG
│        └── NO → Non serve nulla: migliora il prompt
└── NO → Il problema è il COMPORTAMENTO (tono, formato, gergo)?
         ├── SÌ → Hai un dataset di qualità?
         │        ├── SÌ → Fine-tuning
         │        └── NO → Prima costruisci il dataset
         └── NO → Servono sia comportamento che dati?
                  └── SÌ → Entrambi (fine-tuning + RAG)

Le due domande che contano sono queste:

1. Al modello mancano i dati? Risponde con sicurezza ma sbaglia perché non ha mai visto il documento giusto. Problema di dati: RAG.
2. Il modello sa i fatti ma non li scrive come vorreste? Ignora il formato, cambia tono, non usa il gergo del settore, e nessun prompt lo convince. Problema di comportamento: fine-tuning, a patto di avere un dataset curato.

Prima di rispondere alla seconda, vale sempre la pena esaurire il prompt engineering: è gratis, immediato e risolve più casi di quanto si creda.

Quanto costa davvero

Le strategie sono belle sulla carta; poi ci sono i budget.

RAG, in locale. Modello di embedding gratuito (con Ollama, ad esempio nomic-embed-text), database vettoriale gratuito (ChromaDB), indicizzazione di mille pagine in circa mezz’ora su CPU, un centinaio di megabyte per diecimila documenti. Per ogni richiesta: pochi millisecondi di embedding e ricerca, poi il tempo del modello. Il totale, in locale, è essenzialmente zero; con un’API a pagamento, frazioni di centesimo a domanda. Chi vuole vederlo montato pezzo per pezzo trova la pipeline completa nella lezione dedicata.

Fine-tuning. L’ostacolo è tutto all’inizio: un dataset di 500-5000 esempi di qualità (giorni o settimane per costruirlo), 1-4 ore di GPU per ogni addestramento (in cloud, da 5 a 50 euro a tentativo), tipicamente tra 3 e 10 tentativi prima di un modello buono, e qualcuno in squadra che sappia di machine learning. In compenso, una volta pronto, ogni richiesta costa solo l’inferenza. Setup pesante, uso leggero: è il profilo opposto al RAG.

L’ordine giusto: prompt, poi RAG, poi fine-tuning

Le tre leve non sono alternative alla pari: hanno costi crescenti e vanno provate in ordine. Un esempio concreto, un assistente per il supporto clienti di un’azienda:

1. Prompt          "Rispondi in tono formale, in italiano, massimo 5 righe,
                    e se non sai la risposta dillo."        → costo zero, subito
2. + RAG           Manuali, FAQ e listino indicizzati; il modello
                    cita la pagina da cui ha preso la risposta → ore di lavoro
3. + Fine-tuning   Solo se, dopo 1 e 2, il modello continua a ignorare
                    il formato o il gergo del settore          → settimane e GPU

La maggior parte dei progetti si ferma al passo 2, e non per pigrizia: il passo 3 risolve un problema (il comportamento) che spesso non c’è. Quando c’è, la combinazione funziona bene proprio perché ogni pezzo fa una cosa sola. L’assistente medico dell’esempio classico ragiona con cautela clinica perché è stato addestrato a farlo, e cita le ultime linee guida perché gliele passa il RAG: se le linee guida cambiano, si aggiorna il database, non il modello.

I quattro errori più costosi

Usare il fine-tuning per insegnare dei fatti. “Voglio che il modello sappia tutto della nuova linea di prodotti” è la frase che più spesso fa partire un addestramento inutile. Modificare i pesi è un modo pessimo per far memorizzare dettagli e schede tecniche: il modello li confonderà, e la settimana dopo saranno già cambiati. Per i fatti e la documentazione la strada è una sola, il RAG.

Usare il RAG per la formattazione. L’estremo opposto: “voglio che risponda sempre in questo esatto schema JSON”, e si sperano miracoli aggiungendo documenti al contesto. Il RAG porta dati, non cambia il modo in cui il modello decide di scrivere. Mille documenti in più non lo convinceranno a produrre un JSON perfetto. Se il prompt non basta, quello è un problema di comportamento: fine-tuning.

Credere che il RAG insegni qualcosa di permanente. Non modifica il modello. Chiusa la conversazione, il modello ha dimenticato tutto: i “ricordi” stanno nel database vettoriale, non nei pesi. È una proprietà, non un difetto, ma va saputa.

Pensare che più dati diano risultati migliori. Nel fine-tuning la qualità del dataset conta più della quantità: cinquanta esempi curati alla perfezione valgono più di cinquemila mediocri. “Garbage in, garbage out” qui vale doppio, perché la spazzatura finisce nei pesi.

In sintesi

Domanda	Risposta breve
Al modello mancano i dati	RAG: documenti nel prompt, modello intatto, fonti citabili
Il modello sa i fatti ma non li scrive come serve	Fine-tuning, con un dataset curato
Servono stile preciso e dati freschi	Entrambi: fine-tuning per il come, RAG per il cosa
Quanto spesso basta il RAG	Circa l’80% dei casi; il fine-tuning puro è il 5%
Dove sta il costo del fine-tuning	Tutto all’inizio: dataset, GPU, tentativi, competenze
L’errore più comune	Addestrare un modello per fargli imparare fatti che cambiano