RAG vs Fine-Tuning: quando usare ciascuno (con numeri reali)

RAG vs Fine-Tuning: quando usare ciascuno (con numeri reali)

La maggior parte dei consigli su rag vs fine tuning salta l'unico esperimento che li ha misurati entrambi sullo stesso compito. Balaguer e colleghi, in arXiv:2401.08406 (citato 162 volte), hanno sottoposto un dataset di QA agricolo a entrambi gli approcci: il fine-tuning ha portato oltre 6 punti di accuratezza in più, e il RAG ne ha aggiunti altri 5 sopra quel risultato. La loro Tabella 18 colloca GPT-4 al 75% grezzo, 81% con fine-tuning, 86% con fine-tuning e retrieval. Allora perché continuiamo a dire alla maggior parte dei team di partire dal RAG? Perché la freschezza dei dati, le citazioni e i calcoli di costo qui sotto decidono più progetti di un divario di accuratezza di 1 punto.

Punti chiave

• Il RAG è la scelta predefinita quando la conoscenza cambia spesso o le risposte devono citare le fonti; il fine-tuning vince su formato coerente e latenza.
• I costi del fine-tuning si pagano all'inizio (addestramento); quelli del RAG si pagano a ogni query (embedding più token di input aggiuntivi).
• Evidenze pubblicate sullo stesso compito: il fine-tuning ha aggiunto 6 punti di accuratezza, il RAG altri 5 sopra, e l'ibrido ha battuto entrambi da soli.
• Esegui i cinque controlli (freschezza dei dati, esempi etichettati, latenza, citazioni, competenze del team) prima di scrivere qualsiasi codice di addestramento.

Quando conviene usare RAG o Fine-Tuning? (Verdetto rapido)

Scegli il RAG se la tua conoscenza cambia spesso o se le risposte devono includere citazioni. Scegli il fine-tuning se ti servono un formato di output coerente e bassa latenza, e se disponi di centinaia di esempi etichettati. Usali entrambi quando una deployment matura. Il RAG modifica il contesto che il modello legge; il fine-tuning modifica il modello stesso. La maggior parte dei team ha bisogno del primo, non del secondo.

Una riga da ricordare: il RAG cambia ciò che il modello legge; il fine-tuning cambia ciò che il modello è. Scegli in base a quale dei due serve davvero al tuo compito.

Il glossario RAG di NVIDIA definisce bene il lato retrieval se vuoi la versione da manuale. Le definizioni, però, non scelgono la tua architettura. Le evidenze sì, quindi parti da lì.

Cosa mostrano le evidenze? Un compito, entrambi gli approcci, misurati

L'unico confronto misurato sullo stesso compito presente nella top five di Google per questa query è Balaguer et al. 2024, uno studio di Microsoft Research citato 162 volte. Il team ha eseguito un compito di QA agricolo attraverso una pipeline RAG, un modello con fine-tuning e un ibrido dei due, poi ha fatto valutare le risposte a GPT-4. Nel loro setup il fine-tuning da solo ha superato di misura il RAG da solo, e combinarli ha battuto entrambi con un margine più ampio.

Il caso di studio agricolo (arXiv:2401.08406)

Lo studio, inviato a gennaio 2024 da Angels Balaguer con 15 coautori, si chiede cosa serva per fornire agli agricoltori insight specifici per la loro zona. La loro pipeline estrae informazioni da PDF, genera coppie domanda-risposta e valuta Llama2-13B, GPT-3.5 e GPT-4 con e senza retrieval.

Balaguer e colleghi riportano un aumento di accuratezza di oltre 6 punti percentuali dal fine-tuning, cumulativo con il RAG, che ha aggiunto altri 5 punti sopra. La pipeline ibrida ha battuto entrambi gli approcci singoli. La loro Tabella 18 mostra l'ordine per GPT-4: 75% senza aiuto, 80% con RAG, 81% con fine-tuning, 86% con fine-tuning più RAG. Nota quanto sono vicini 80% e 81%: il divario tra RAG da solo e fine-tuning da solo è di un punto, mentre l'ibrido è cinque punti avanti a entrambi. In un esperimento, il modello con fine-tuning ha attinto a conoscenze di altre aree geografiche per rispondere a domande specifiche di una regione, alzando la somiglianza delle risposte dal 47% al 72%.

Le evidenze economiche

Lo studio pubblicato da Snorkel AI (novembre 2022) copre il lato dei costi. Su un benchmark di classificazione legale a 100 classi (LEDGAR, 80.000 clausole contrattuali), un modello RoBERTa con fine-tuning ha eguagliato un GPT-3 con fine-tuning pur essendo 1.400 volte più piccolo, usando meno dell'1% delle etichette ground-truth e girando allo 0,1% del costo di inferenza in produzione del modello GPT-3 con fine-tuning: circa un millesimo. Costo totale di costruzione: 1.915 $ con etichettatura programmatica contro 7.418 $ per annotazione manuale più fine-tuning di GPT-3. Una precisazione: si tratta di classificazione, non di QA generativo, quindi tratta i rapporti come indicazioni di direzione.

La nostra lettura

La nostra interpretazione: il loro setup è il caso più favorevole che il fine-tuning possa mai incontrare, e ha comunque vinto di un solo punto. Balaguer e colleghi hanno addestrato su un corpus PDF fisso e valutato contro quello stesso corpus congelato, quindi nulla di ciò che i pesi hanno imparato ha avuto il tempo di diventare obsoleto durante l'esperimento. La maggior parte delle basi di conoscenza in produzione non sta ferma così. Un bot di supporto che risponde a domande sulla release della settimana scorsa si riguadagna i 6 punti a ogni ciclo di riaddestramento, mentre l'indice che alimenta il RAG si aggiorna lo stesso pomeriggio. Per questo leggiamo un vantaggio di accuratezza di 1 punto come l'input più debole di questa decisione, e la freschezza come il più forte. Dove le evidenze non si generalizzano: il risultato di Snorkel è un benchmark di classificazione, e nessuno dei due studi testa il controllo di tono o formato, che resta il caso più forte del fine-tuning.

Il fine-tuning è la risposta giusta meno spesso di quanto i team pensino: la maggior parte dei progetti che dice "fine-tuning" in realtà intende "retrieval".

Come funziona il RAG e quando vince?

Il RAG (retrieval-augmented generation) risponde a partire da documenti che controlli tu, invece che da qualunque cosa il modello abbia memorizzato durante l'addestramento. Proposto per la prima volta da Lewis et al. nel 2020, è diventato lo standard per il lavoro sulla conoscenza perché la conoscenza vive fuori dal modello: aggiorni l'indice e ogni risposta cambia il giorno dopo, senza riaddestramento.

La pipeline è di quattro passaggi:

1. Acquisizione. Analizza i tuoi documenti (PDF, wiki, ticket) in un corpus.
2. Chunking ed embedding. Suddividi in chunk di qualche centinaio di token e converti ciascuno in un vettore con un modello di embedding.
3. Retrieval. Al momento della query, trova i top-K chunk più simili, più le corrispondenze a parola chiave per stringhe esatte come SKU e codici di errore.
4. Augmentation e generazione. Inserisci quei chunk nel prompt e lascia che l'LLM risponda con le fonti allegate.

Il RAG vince su tre assi: freschezza (reindicizzazione invece di riaddestramento), citazioni (ogni risposta punta al chunk da cui proviene) e controllo dei dati (i dati dei clienti non entrano mai in un addestramento). Se vuoi la guida completa alla costruzione, ecco come costruire un'applicazione RAG passo dopo passo.

Un avvertimento sulla qualità del retrieval: la pipeline vale quanto il suo mix di embedding e retrieval. Il Contextual Retrieval di Anthropic ha misurato un tasso di fallimento del retrieval top-20 del 5,7% su setup semplici, che scende al 2,9% con embedding contestuali più BM25 e all'1,9% aggiungendo un reranker. Se le query a corrispondenza esatta continuano a fallire, la ricerca ibrida (BM25 vs vettoriale) è la soluzione.

Quando vince il Fine-Tuning? (E cos'è il PEFT?)

Il fine-tuning vince quando il problema è come il modello risponde, non cosa sa: formato di output coerente, tono del brand o un budget di latenza rigido senza round-trip di retrieval. È anche la leva per l'economia dei modelli piccoli. Il risultato di Snorkel "qualità GPT-3 allo 0,1% del costo" citato sopra esiste solo perché qualcuno ha fatto il fine-tuning di un modello piccolo invece di servirne uno grande.

Full fine-tuning vs PEFT (LoRA / QLoRA)

Il full fine-tuning aggiorna ogni peso del modello. È costoso, lento e raro fuori dai grandi laboratori. Quasi tutti rilasciano in produzione il PEFT (parameter-efficient fine-tuning). LoRA (Hu et al. 2021) congela i pesi di base e addestra un piccolo adattatore a basso rango, in genere lo 0,1-1% del numero di parametri. QLoRA aggiunge la quantizzazione a 4 bit sopra, così un modello 13B sta su una sola GPU consumer. Un termine correlato che vale la pena conoscere: il continuous pretraining, in cui un modello continua il pretraining su un corpus grezzo di dominio (non supervisionato) prima del fine-tuning supervisionato su esempi etichettati.

Una configurazione LoRA minima, dalla documentazione PEFT di Hugging Face:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Per preparazione del dataset, numero di epoche e valutazione, vedi la nostra guida al fine-tuning passo dopo passo.

I rischi sono reali: overfitting su dataset piccoli (poche centinaia di esempi possono memorizzare invece di imparare), obsolescenza (i pesi congelano la tua conoscenza alla data di cutoff dell'addestramento) e nessuna attribuzione delle fonti (un modello con fine-tuning non può mostrare le ricevute). Se anche solo uno di questi tre è un ostacolo insormontabile, ti sei appena convinto da solo a tornare al RAG.

RAG vs Fine-Tuning vs Prompt Engineering: dove si collocano gli altri?

I tre sono una scala, non rivali. Il prompt engineering cambia le istruzioni, il RAG cambia il contesto che il modello legge e il fine-tuning cambia i pesi. La guida al fine-tuning della stessa OpenAI mette il fine-tuning per ultimo nel ciclo: prima le eval, poi i prompt, l'addestramento solo quando il prompting non basta più. Due opzioni più recenti completano la cassetta degli attrezzi.

Una confusione che vale la pena nominare: i server MCP e i framework per agenti sono orchestrazione, non personalizzazione. Decidono quali tool e fonti il modello può raggiungere; non cambiano come il modello risponde. Puoi eseguire una pipeline RAG dentro un agente e fare il fine-tuning del modello sotto, e molti sistemi in produzione fanno entrambi. Le guerre dell'autocompletamento ("vs mcp", "vs agenti") sono errori di categoria.

Il RAG costa meno del Fine-Tuning? Il modello di costo reale

Risposta breve: a volumi di query realistici, sì. Il conto del fine-tuning arriva all'inizio (dati etichettati più addestramento), mentre quello del RAG arriva a ogni query (embedding più token di input extra). La documentazione sul fine-tuning di OpenAI fa pagare l'addestramento a token, ma le tariffe sui token sono spiccioli rispetto al costo umano degli esempi etichettati. Ecco i calcoli sui prezzi di listino pubblici.

La domanda di pareggio: quante query servono prima che la tassa cumulativa per query del RAG eguagli l'investimento del fine-tuning?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

A 50.000 query al mese, sono più di dieci anni. Per la maggior parte dei prodotti, l'investimento del fine-tuning non si ripaga mai con il solo risparmio sui token: il fine-tuning si fa per formato e latenza, non per battere il RAG sui costi. La matematica si ribalta oltre i milioni di query al mese o con contesti recuperati molto grandi. E nota l'asimmetria: il conto del fine-tuning si rinnova ogni volta che la deriva dei dati impone un riaddestramento, mentre il RAG scala linearmente con volume per dimensione dei chunk. Se la spesa per query è la preoccupazione vera, parti prima dal taglio dei costi LLM per query; se poi scegli la strada dell'addestramento, confronta i tool di fine-tuning prima di firmare l'assegno.

Una nota sulla freschezza: a luglio 2026, la documentazione di OpenAI sul fine-tuning indica che la piattaforma hosted è in fase di dismissione per i nuovi utenti, mentre gli utenti esistenti mantengono l'accesso all'addestramento per i prossimi mesi. È una ragione in più per cui i team si orientano verso il PEFT su modelli aperti o il semplice RAG.

5 controlli prima di scegliere

Esegui questi cinque controlli sì-o-no prima di scrivere qualsiasi codice di addestramento: lo schema delle risposte indica RAG, fine-tuning o ibrido in modo più affidabile di qualsiasi benchmark. Rispondi onestamente, poi conta.

1. La conoscenza cambia più velocemente di quanto tu possa riaddestrare? Sì → RAG. Un riaddestramento per ogni aggiornamento dei documenti non è un piano operativo.
2. Hai qualche centinaio di esempi etichettati? No → RAG o prompt engineering. Il fine-tuning su 40 esempi memorizza; non impara.
3. C'è un budget di latenza rigido? Stretto → pende verso il fine-tuning. Saltare il round-trip di retrieval fa risparmiare 50-200 ms.
4. Le risposte devono includere citazioni o un audit trail? Sì → RAG. I modelli con fine-tuning non possono puntare al chunk di origine.
5. Il team ha competenze ML più budget GPU o API per l'addestramento? No → RAG. Un indice che puoi ricostruire batte dei pesi che non puoi riaddestrare.

Prevalenza di sì su 1, 4, 5 → RAG. Prevalenza di sì su 2 e 3 con un dominio stabile → fine-tuning. Risposte divise, o un prodotto maturo con traffico reale → ibrido (prossima sezione). Il senso della checklist è decidere con le evidenze, non con la tecnica che va di moda nel tuo feed questo mese.

Si possono usare RAG e Fine-Tuning insieme?

Sì, e per le deployment mature lo schema ibrido è la norma, non l'eccezione. Fine-tuning per la fluidità di dominio e il formato di output (il come), retrieval per i fatti al momento dell'inferenza (il cosa). Balaguer e colleghi riportano esattamente questo sul loro compito agricolo: la pipeline ibrida ha battuto entrambi gli approcci singoli, con il guadagno di 5 punti del RAG che si somma ai 6 del fine-tuning.

Il percorso di maturità che raccomandiamo: parti con il prompt engineering, aggiungi il RAG nel momento in cui le risposte richiedono dati privati o freschi, e aggiungi il fine-tuning solo quando le incongruenze di formato o la latenza iniziano a fare male in produzione. Salta direttamente al fine-tuning e paghi la tassa di addestramento prima di sapere se il retrieval ha già risolto il problema.

Lo schema ibrido non è un compromesso: per le deployment mature è la scelta predefinita. Fine-tuning per il formato, retrieval per i fatti.

Come valuti il vincitore?

Scegli il vincitore come sceglieresti un database: misura sul tuo carico di lavoro, non sulle sensazioni. La ricetta sta in un paragrafo e copre i quattro numeri che decidono davvero.

• Set di domande held-out. 100-300 domande reali degli utenti. Non sintetiche, mai nulla di visto durante addestramento o indicizzazione.
• Faithfulness e correttezza della risposta. La faithfulness chiede se la risposta è radicata nel contesto recuperato; la correttezza chiede se è effettivamente giusta. La coppia, resa popolare da RAGAS, cattura sia le allucinazioni sia gli errori di retrieval.
• Latenza al p95, non la media. Il retrieval aggiunge un round-trip; misura la coda.
• Costo per 1.000 query, token più infrastruttura, misurato invece che stimato.
• Riesegui con la deriva. Nuovi documenti, nuovo snapshot del modello, nuovo trimestre: riesegui il set.

L'analisi completa delle metriche, inclusi i tool, è nella nostra guida alla valutazione degli LLM.

Domande frequenti

Si possono usare RAG e fine-tuning insieme?

Sì. Fine-tuning per il formato di output e la fluidità di dominio, e mantieni il retrieval per i fatti al momento dell'inferenza. Balaguer e colleghi hanno misurato questo ibrido su un compito di QA agricolo e hanno scoperto che batte entrambi gli approcci singoli, con i guadagni di accuratezza che si sommano. La maggior parte dei sistemi maturi in produzione finisce qui: i pesi per il come, il retrieval per il cosa.

Quando non usare il fine-tuning?

Salta il fine-tuning quando la tua conoscenza cambia più velocemente di quanto tu possa riaddestrare, quando hai meno di qualche centinaio di esempi etichettati, quando le risposte devono includere citazioni o audit trail, o quando non c'è budget per riaddestrare con la deriva dei dati. Queste quattro condizioni descrivono la maggior parte dei prodotti in fase iniziale, ed è per questo che il RAG è di solito la prima mossa giusta.

Il fine-tuning è stato smentito?

No, ma il suo territorio si è ristretto. Le finestre di contesto lunghe e il RAG economico hanno assorbito casi d'uso che nel 2023 richiedevano il fine-tuning. Ciò che resta è reale: formato di output rigido, tono del brand, budget di latenza senza round-trip di retrieval ed economia dei modelli piccoli. Se il tuo problema è come il modello risponde piuttosto che cosa sa, il fine-tuning è ancora lo strumento giusto.

Quando useresti RAG o fine-tuning?

Usa il RAG quando le risposte dipendono da conoscenza privata o aggiornata di frequente, o quando servono citazioni. Usa il fine-tuning quando ti servono formato, tono o latenza coerenti e disponi di abbastanza esempi etichettati. Usali entrambi quando il prodotto matura. Nel dubbio, parti dal RAG: è più economico da annullare rispetto a un ciclo di addestramento.

Il RAG costa meno del fine-tuning?

All'inizio, sì. Il costo del RAG è per query (embedding più token di input extra), mentre il fine-tuning si paga una volta per addestramento e dati etichettati, poi si rinnova a ogni riaddestramento. Ai prezzi di listino pubblici, il pareggio si colloca intorno a 6,4 milioni di query nel nostro esempio svolto, quindi ai volumi tipici il RAG resta più economico per l'intera vita del prodotto.

Il RAG è meglio del fine-tuning per le allucinazioni?

Di solito, ma non gratis. Il RAG radica le risposte nei chunk recuperati, così puoi citare le fonti e controllare i fallimenti. Un retrieval scadente, però, avvelena la risposta: Anthropic ha misurato un tasso di fallimento del retrieval top-20 del 5,7% su setup semplici, ridotto all'1,9% con contextual retrieval più reranking. Il fine-tuning, nel frattempo, può incorporare errori nei pesi senza alcun modo di risalirvi.

RAG vs fine-tuning vs prompt engineering: qual è la differenza?

Il prompt engineering cambia le istruzioni che invii. Il RAG cambia il contesto che il modello legge al momento della query. Il fine-tuning cambia i pesi del modello. Ciascuno è un intervento più grande del precedente: prova prima i prompt, aggiungi il retrieval quando la conoscenza è il collo di bottiglia e addestra solo quando formato, tono o latenza fanno ancora male.

Come valuti le prestazioni di RAG e fine-tuning?

Costruisci un set held-out di 100-300 domande reali degli utenti e valuta entrambi gli approcci su di esso: faithfulness (è radicata?), correttezza della risposta (è giusta?), latenza al p95 e costo per 1.000 query. Riesegui il set ogni volta che i documenti o lo snapshot del modello cambiano. Le domande sintetiche lusingano entrambi i sistemi; quelle reali li separano.

Fine-tuning o RAG per domande multi-hop su conoscenza nuova?

RAG, con un retrieval migliore. Il meccanismo decide questa da solo: un modello con fine-tuning può ragionare solo su ciò che i suoi pesi hanno assorbito, quindi la conoscenza che non ha mai visto è irraggiungibile per quanto bene sia stato addestrato. Il retrieval gli consegna i pezzi mancanti al momento della query. Il trucco è che un singolo passaggio di retrieval raramente raccoglie tutti i salti, quindi pianifica la decomposizione delle query o il retrieval iterativo più un reranker, non una singola ricerca top-K.

Conclusioni

Il riassunto, senza giri di parole:

• Il RAG è la scelta predefinita per conoscenza che cambia e risposte con citazioni. Il fine-tuning è lo specialista per formato, tono e latenza.
• Le evidenze sullo stesso compito (Balaguer et al.) danno al fine-tuning +6 p.p. e al RAG altri +5 p.p. sopra, con l'ibrido migliore dei tre. Il nostro consiglio di partire dal RAG si basa su freschezza, citazioni e costi, non su quel tabellino.
• I calcoli di costo pendono a favore del RAG a volumi realistici: il pareggio si collocava intorno a 6,4 milioni di query nel nostro esempio svolto.
• Decidi con i cinque controlli, non con l'abitudine.

Hai scelto il RAG? Vedi la nostra classifica dei tool RAG per lo stack intorno alla pipeline.