RAG vs fine-tuning: quale scegliere?

L'errore più comune e più costoso è fare fine-tuning per aggiungere conoscenza — un modo lento e costoso per fare ciò che RAG fa a basso costo e all'istante, e che spesso peggiora le allucinazioni. La domanda giusta non è mai "quale è meglio" ma "cosa voglio cambiare: ciò che il modello sa, o come si comporta?". Rispondi e la scelta è ovvia.

A confronto

RAG, oltre la versione da un paragrafo

Il loop di base: documenti → chunk → embeddings → DB vettoriale; alla query recuperi i chunk più rilevanti, li inietti nel prompt, rispondi con citazioni. La conoscenza si aggiorna modificando i documenti — niente retraining. Questa è la brochure. La qualità del RAG in produzione la decidono le parti senza glamour:

• Ricerca ibrida + reranking. La similarità vettoriale pura manca gli identificatori esatti (codici, nomi, numeri di articolo); combinarla con la ricerca keyword (BM25) e rerankare i candidati uniti è di routine il singolo salto di qualità più grande in un sistema RAG.
• Chunking per struttura (titoli, paragrafi, tabelle intere) batte lo splitting a dimensione fissa; i chunk devono avere senso da soli.
• Trasformazione della query. Gli utenti fanno domande vaghe; riscrivere/espandere la query prima del retrieval (o recuperare per più riformulazioni) alza sostanzialmente il recall.
• RAG agentico / multi-hop. Per domande che attraversano documenti ("confronta la policy A col contratto B"), un solo retrieval non basta — il modello recupera, legge, poi recupera ancora. Più costoso, a volte necessario.
• Dove fallisce: retrieval mancati (la risposta non era nei top-k), indici stantii, documenti contraddittori, e domande che richiedono sintesi su tutto ("quali sono i nostri rischi principali?") invece di lookup — RAG è un meccanismo di lookup, non un analista.

Il fine-tuning, oltre la versione da un paragrafo

Il fine-tuning continua l'addestramento sui tuoi esempi così che il modello interiorizzi un comportamento. In pratica quasi nessuno riaddestra tutti i pesi: LoRA addestra piccole matrici adapter a basso rango accanto ai pesi congelati (~0,1–1% dei parametri), e QLoRA lo fa sopra una base quantizzata a 4-bit — ecco perché un 70B si può fine-tunare su una singola GPU da 48GB. L'adapter è un piccolo file che puoi caricare, scambiare o impilare al serving.

• Dove brilla: formati di output rigidi ("sempre questo schema JSON" — molto più affidabile del prompting), voce del brand, classificazione/estrazione su larga scala, fluidità nel gergo di dominio, e la distillazione — addestrare un modello piccolo sugli output di uno grande così che quello economico faccia il lavoro in produzione. Quest'ultima è la leva di costo più sottoutilizzata dell'AI locale.
• Il dataset è il prodotto. ~500–5.000 esempi di alta qualità e coerenti di norma battono 50.000 rumorosi per un comportamento specifico. Ogni incoerenza nei dati di training diventa un comportamento che il modello impara.
• I rischi: catastrophic forgetting (un tuning troppo aggressivo degrada le capacità generali — tieni rank/epoche modesti e valuta ad ampio raggio), obsolescenza (il prossimo trimestre esce una base migliore e il tuo adapter non si trasferisce — metti a budget il rifacimento), e falsa sicurezza (un modello tunato suona più on-brand anche quando sbaglia).
• Oltre il supervised: il preference tuning (DPO) plasma stile/giudizio da coppie scelto-vs-scartato — utile quando hai feedback degli utenti, eccessivo prima.

"Ma il long context uccide RAG" — no

I modelli con finestre di contesto giganti tentano una scorciatoia: salta il retrieval, incolla tutto. Tre ragioni per cui in produzione perde: costo — ogni query paga centinaia di migliaia di token che la risposta non richiedeva (e il tempo di prompt processing di conseguenza); recall — i modelli perdono dimostrabilmente precisione nei contesti molto lunghi (l'"ago nel pagliaio" si fa più difficile al crescere del pagliaio, specie a metà contesto); freschezza/permessi — ti serve comunque un sistema che sappia quali documenti esistono e chi può vederli, cioè… un sistema di retrieval. Il long context è un regalo al RAG: permette di recuperare chunk più ricchi e lunghi senza ansia da selezione. Non sostituisce lo scegliere ciò che conta.

Combinarli (il pattern di produzione)

• Fine-tuning per il comportamento + RAG per la conoscenza — il setup forte standard: l'adapter impone tono, formato e disciplina delle citazioni; il retrieval fornisce fatti aggiornati.
• Fine-tunare il modello per essere migliore nel RAG (a volte detto RAFT): addestra su esempi di risposta dal contesto fornito — citare accuratamente, rifiutare quando il contesto non contiene la risposta. Corregge direttamente i comportamenti RAG più fastidiosi.
• Distillazione + RAG: modello piccolo fine-tuned con buon retrieval ≈ modello grande generico, a una frazione del costo di serving — il punto ideale per deployment on-prem con VRAM limitata (vedi la guida al ChatGPT privato).

Matrice decisionale per scenario

• Bot di supporto sui tuoi documenti → RAG (+ più avanti, un LoRA leggero per il tono).
• "Rispondi rigorosamente nel nostro schema JSON" → fine-tuning (l'output strutturato è il suo terreno di casa).
• Classificatore / estrattore ad alto volume → fine-tuna un modello piccolo; servilo a basso costo.
• Redattore con voce del brand → fine-tuning (lo stile è comportamento).
• Assistente esperto di dominio (legale, pharma, engineering) → RAG per il corpus + fine-tuning per stile di dominio e disciplina delle citazioni.
• Freschezza critica (prezzi, policy, ticket) → solo RAG; i cicli di retraining non possono inseguire la realtà.

Errori comuni

• Fine-tuning per aggiungere fatti. Il classico. Costoso, inaffidabile, incline alle allucinazioni — è compito di RAG.
• Incolpare il modello per i fallimenti del retrieval. Prima di passare a un 70B, logga cosa è stato davvero recuperato: la maggior parte delle "risposte sbagliate" sono chunk sbagliati.
• Saltare il set di valutazione. ~50–100 domande con risposta nota, misurate prima/dopo ogni modifica, o stai guidando per aneddoti.
• Addestrare su dati incoerenti. Il modello impara il rumore del tuo dataset come policy.
• Saltare al fine-tuning prima di esaurire il prompting. Un buon system prompt più esempi few-shot risolve più di quanto i team si aspettino, a costo zero.