vibe-coding · 2026-08-10
RAG vs Fine-tuning: quando usare cosa (e quando nessuno dei due)
Due tecniche spesso presentate come alternative sono in realtà risposte a due problemi diversi. Confonderle costa mesi di lavoro sulla tecnica sbagliata.
Il Retrieval-Augmented Generation (RAG) risponde alla domanda "come faccio in modo che il modello conosca informazioni specifiche che non erano nei suoi dati di addestramento, e che cambiano nel tempo" -- documenti interni, prezzi aggiornati, policy aziendali. Funziona recuperando i pezzi rilevanti di quella informazione al momento della domanda e passandoli al modello come contesto. Il fine-tuning risponde a una domanda diversa: "come faccio in modo che il modello si comporti in modo sistematicamente diverso" -- un tono specifico, un formato di risposta particolare, un ragionamento specializzato su un dominio ristretto.
L'errore più comune, che costa mesi di lavoro sulla tecnica sbagliata, è usare il fine-tuning per il problema che il RAG risolve meglio: qualcuno vuole che il modello "sappia" i prezzi aggiornati dei propri prodotti e li inserisce in un dataset di addestramento. Il risultato, quasi garantito, è un modello che ha imparato uno stile di risposta sui prezzi ma che diventa obsoleto dal giorno dopo, perché il fine-tuning congela la conoscenza al momento dell'addestramento -- non è progettato per essere aggiornato ogni settimana con un nuovo listino.
Il RAG, al contrario, separa esplicitamente "cosa il modello sa fare" da "quali fatti specifici usa in questo momento" -- aggiornare il listino prezzi significa aggiornare un documento nella base di conoscenza, non riaddestrare nulla. Questo lo rende la scelta giusta per qualunque informazione che cambia più spesso del ciclo di addestramento di un modello, che nella pratica significa quasi ogni informazione operativa reale di un'azienda: prezzi, disponibilità, policy, contratti in corso, stato dei progetti.
C'è però una terza risposta, spesso la più corretta e la meno raccontata: né RAG né fine-tuning, ma codice deterministico con una chiamata al modello solo dove serve davvero giudizio. Se un sistema deve calcolare un totale con IVA, non serve un modello che "impari" a fare aritmetica né uno che "recuperi" la formula -- serve una funzione che fa il calcolo, sempre uguale, verificabile. La domanda da farsi prima di scegliere tra RAG e fine-tuning è: questo passo richiede davvero giudizio linguistico o probabilistico, o è in realtà un calcolo o una regola che il codice tradizionale fa meglio, più veloce, e a costo zero?
La combinazione che funziona nella maggior parte dei sistemi reali maturi non è "RAG o fine-tuning", è una gerarchia: codice deterministico per tutto ciò che ha una risposta certa, RAG per informazione che cambia e deve restare accurata, fine-tuning (quando davvero serve, che è più raro di quanto il marketing suggerisca) per comportamenti specializzati che restano stabili nel tempo. Scegliere la tecnica sbagliata per il problema sbagliato non è solo inefficiente -- è il modo più comune in cui un progetto AI interno spende un trimestre intero senza produrre nulla di usabile.
Un errore pratico comune e sottovalutare quanto spesso la risposta giusta sia "nessuna delle due tecniche" -- prima di implementare RAG o fine-tuning, vale sempre la pena chiedersi se il problema ha in realta una risposta calcolabile con codice tradizionale, piu veloce, piu economico, e piu prevedibile di qualunque approccio basato su un modello.