RAG vs. Fine-Tuning: Un Framework Decisionale per Founder

Si utilizzi RAG (retrieval-augmented generation) quando i dati sottostanti cambiano frequentemente o si ha necessità di mostrare agli utenti la provenienza di una risposta. Si utilizzi il fine-tuning quando il problema riguarda il comportamento del modello in sé: tono, formato di output, o un task specifico che continua a sbagliare in modo strutturale. La maggior parte dei team con cui parliamo sceglie il fine-tuning per prima cosa perché suona più "personalizzato", per poi scoprire che RAG avrebbe risolto l'80% del problema a una frazione del costo e della complessità.

Cosa fa ciascuno, concretamente

Risolvono problemi diversi, e confonderli è il modo più sicuro per perdere settimane.

• RAG recupera i documenti pertinenti al momento della query e li inserisce nel prompt come contesto. I pesi del modello non cambiano mai. Si sta estendendo ciò che il modello conosce, non il modo in cui si comporta.
• Il fine-tuning adatta i pesi del modello su un training set di esempi. Si sta cambiando il modo in cui il modello risponde — formato, tono, o pattern di ragionamento specifici del task — non fornendogli nuovi fatti.

Il paper originale su RAG di Lewis et al. (2020) lo inquadrava esattamente in questo modo: abbinare un modello parametrico a una memoria non parametrica aggiornabile in modo indipendente. Questo è ancora il trade-off fondamentale a distanza di anni: si vuole che la conoscenza risieda nei pesi, o in uno store che si può modificare senza riaddestrare?

Quando vince RAG

Si scelga RAG se una qualsiasi di queste condizioni è vera:

• I dati cambiano settimanalmente o quotidianamente. Listini prezzi, inventari, documenti di policy, ticket di supporto. Fare fine-tuning su un target in continuo movimento significa riaddestrare costantemente.
• Si ha bisogno di citazioni. I casi d'uso in ambito sanitario, legale e finanziario richiedono solitamente di mostrare la fonte. RAG fornisce una traccia verificabile; il fine-tuning incorpora i fatti in una matrice di pesi opaca che non è possibile controllare.
• Si è in fase pre-product-market-fit. RAG permette di sostituire il modello sottostante o di regolare la logica di retrieval senza toccare un artefatto addestrato. I meccanismi sono descritti nel nostro primer su RAG e lo storage layer in vector databases explained.
• Il budget è limitato. Nessun training run, nessun noleggio di GPU, nessuna pipeline MLOps da mantenere. Si paga per query, non per ciclo di aggiornamento.

Quando vince il fine-tuning

Il fine-tuning giustifica il suo costo quando il problema non è una conoscenza mancante, ma un comportamento errato:

• Il modello continua a ignorare il formato di output richiesto. È necessario un JSON rigoroso, un tono specifico, o uno stile di ragionamento tipico del dominio (ad es. un workflow di triage) che il solo prompting non riesce a mantenere costantemente su larga scala.
• Si dispone di migliaia di esempi etichettati di comportamento corretto e il pattern è stabile: non "nuovi fatti", ma "esegui questo task esattamente in questo modo".
• La latenza e la dimensione del prompt sono un vincolo reale. Ogni query RAG paga un costo di retrieval e un prompt più lungo. Se si effettuano milioni di chiamate al giorno, un modello fine-tuned con un prompt breve può risultare significativamente più economico e veloce di un contesto RAG esteso, una volta ammortizzato il training. Si veda la nostra analisi dei costi per come questi numeri si confrontano realmente nel tempo.
• Il vocabolario o i pattern di ragionamento del proprio dominio sono sufficientemente insoliti da non poter essere guidati in modo affidabile da un modello general-purpose nemmeno con un buon retrieval e prompting (ad es. un task di codifica clinica altamente specializzata).

La documentazione sul fine-tuning di OpenAI è un riferimento valido per capire a cosa è effettivamente adatto il fine-tuning: aderenza al formato, tono e consistenza su task specifici — non l'iniezione di nuovi fatti.

Il caso ibrido

Nella pratica, i sistemi in produzione più solidi usano entrambi gli approcci, ma non dal primo giorno:

1. Si avvii con RAG e prompting. È rapido da iterare e facile da modificare.
2. Si strumenti tutto: si registrino ogni query, ogni retrieval e ogni output.
3. Una volta identificati pattern di errore reali (non ipotetici), si esegua il fine-tuning in modo mirato sul comportamento specifico che non funziona.

Costruire una pipeline di fine-tuning prima di avere log di produzione significa progettare al buio. Si sta indovinando come appaia il "corretto" invece di addestrare sui propri effettivi casi di fallimento.

Cosa abbiamo visto nella pratica

Gestiamo internamente i nostri strumenti di outreach, che analizzano il sito di un prospect e redigono una cold email personalizzata. Il nostro primo istinto fu quello di adottare l'architettura "corretta": una catena di agenti che estrae fatti, ragiona sulla pertinenza, redige il testo e poi critica la propria bozza. Era più lenta, più costosa e produceva email peggiori rispetto a una singola chiamata LLM ben strutturata che riceveva la pagina analizzata come contesto — essenzialmente un pattern RAG con un documento solo invece di un corpus. Avremmo ricorso al fine-tuning solo se quell'approccio a singola chiamata non fosse riuscito a mantenere una voce coerente su centinaia di email, ma non è stato così. La lezione si generalizza: non si ricorra allo strumento più pesante prima di aver dimostrato che quello più leggero è insufficiente. Lo stesso istinto che sovradimensiona una catena di agenti multi-step quando basterebbe una chiamata sola è quello che sovradimensiona una pipeline di fine-tuning quando il retrieval sarebbe sufficiente.

Una checklist per founder

Prima di impegnare il budget, si risponda a queste domande:

• Con quale frequenza cambiano i dati sottostanti? Ogni giorno/settimana → RAG. Raramente/mai → il fine-tuning è un'opzione valida.
• È necessario mostrare le fonti? Sì → RAG, o quanto meno RAG più fine-tuning, mai fine-tuning da solo.
• Il problema riguarda "fatti sbagliati" o "formato/comportamento sbagliato"? Fatti sbagliati → RAG. Comportamento sbagliato → fine-tuning.
• Si dispone già di esempi etichettati di comportamento corretto? No → non si è pronti per il fine-tuning, indipendentemente dal caso d'uso.
• Qual è il volume di query? Basso o medio → il costo per query di RAG è accettabile. Alto e latency-sensitive → il costo ammortizzato del fine-tuning inizia a diventare conveniente.

Se si sta integrando uno dei due approcci in un prodotto esistente anziché partire da zero, la nostra guida all'integrazione dell'AI nel proprio prodotto illustra le decisioni architetturali correlate — autenticazione, rate limiting e comportamento di fallback — che contano tanto quanto la scelta del modello.

Nessuno dei due approcci è più "avanzato" dell'altro: risolvono problemi diversi, e il percorso più rapido verso un prodotto funzionante è di solito quello più economico che si può validare prima. Se desidera un parere su quale dei due si adatti al suo prodotto, ne parliamo.