Fine-tuning vs RAG: quale scegliere per il proprio caso d'uso ?

#Perché questa domanda si ripete senza sosta

Hai installato Ollama, scelto un modello da 7B o 14B e ora vuoi che "conosca" il tuo settore: la tua documentazione interna, il lessico professionale, le tue decisioni giurisprudenziali, i tuoi ticket di supporto. Si aprono due strade — fine-tuning o RAG — e la comunità ne parla spesso come se fossero alternative intercambiabili. Non lo sono.

La trappola: il fine-tuning ha un'aura di "vera IA", si immagina un modello che diventa esperto. Il RAG sembra una soluzione arrangiata, un "copia e incolla" automatizzato. Nella realtà industriale è il contrario: il RAG è diventato lo standard per l'80% dei casi d'uso aziendali e il fine-tuning è riservato a problemi specifici in cui offre ciò che il RAG non può offrire.

#I due approcci in 1 minuto

#RAG (Retrieval-Augmented Generation)

Il RAG indicizza i tuoi documenti (PDF, Markdown, database, codice) in un database vettoriale (Chroma, Qdrant, Weaviate). Quando viene posta una domanda, il sistema recupera i passaggi pertinenti tramite similarità semantica, li inserisce nel prompt e il LLM genera la risposta basandosi su di essi. Il modello rimane generico, è il contesto che diventa specializzato.

Cosa cambia

Il modello può citare i tuoi dati, indicare le fonti delle sue risposte e accedere a conoscenze che non aveva durante l'addestramento.

Cosa non cambia

Stile della risposta, tono, capacità di ragionare in un formato preciso, vocabolario tecnico molto specializzato.

Costo marginale per l'aggiunta di un documento

Qualche secondo: si indicizza il nuovo documento, tutto qui.

#Fine-tuning (LoRA / QLoRA / full)

Il fine-tuning riaddestra il modello (o una parte dei suoi pesi, tramite LoRA) su un dataset di coppie input/output rappresentative di ciò che vuoi che faccia. La conoscenza e il comportamento vengono assorbiti nei pesi del modello.

Cosa cambia

Il comportamento predefinito: stile, formato di output, convenzioni, terminologia specialistica approfondita del settore, ragionamento implicito.

Ciò che non riesce a modificare bene

L'accesso a informazioni fattuali aggiornate — un modello sottoposto a fine-tuning a marzo sulle tue procedure non saprà nulla delle procedure scritte ad aprile.

Costo marginale per l'aggiunta di un documento

Un nuovo training run completo ogni volta che il dataset viene aggiornato in modo significativo.

#Matrice decisionale

Anziché un « dipende », ecco i criteri che permettono davvero di decidere, riga per riga.

Conoscenza fattuale che cambia spesso

RAG. Il fine-tuning diventa obsoleto nel momento in cui il dataset viene aggiornato. Qualsiasi documentazione di prodotto, raccolta di ticket, FAQ o giurisprudenza rientra in questa categoria.

Stile, tono, formato di output specifico

Fine-tuning. Nessuna quantità di esempi in un prompt può sostituire 500 coppie di addestramento ben costruite per consolidare un formato JSON rigoroso, un tono aziendale o una struttura di rapporto.

Lessico professionale estremamente specializzato

Fine-tuning, soprattutto se la lingua è poco coperta dal pre-addestramento (linguaggio giuridico francese, medico, dialetti). Il RAG non basta se il modello non comprende già i termini.

Tracciabilità e citazione delle fonti

RAG. Puoi mostrare "secondo il documento X, paragrafo Y". Con un modello sottoposto a fine-tuning, è impossibile dimostrare da dove proviene un'affermazione.

Dati altamente riservati, mai nella RAM condivisa

Fine-tuning con pesi memorizzati localmente. Il RAG richiede di inserire i passaggi nel contesto a ogni richiesta — su un’infrastruttura condivisa, questo può creare problemi.

Risposta rapida in meno di 200ms (chatbot, agente inline)

Fine-tuning. Il RAG aggiunge 100-500 ms per il recupero delle informazioni, più un contesto più lungo da elaborare. Quando il tempo reale è un requisito critico, questo incide.

Un volume enorme di conoscenze (> 100k pagine)

RAG. Non puoi ragionevolmente fare il fine-tuning su 100k documenti — e anche se lo facessi, il modello inventerebbe dettagli.

Dataset di qualità disponibile per il training

Se non hai almeno 500-1000 coppie di input/output pulite, il fine-tuning finirà soprattutto per degradare il modello. Parti con il RAG.

#5 casi d'uso tipici

#1. Chatbot di assistenza basato sulla documentazione del prodotto

Verdetto

RAG, senza esitare.

Perché

La documentazione cambia costantemente (nuove funzionalità, correzioni, deprecazioni). Un fine-tune sarebbe obsoleto in 3 settimane e il cliente vuole una risposta con una fonte ("vedi sezione X del manuale"), non un'affermazione opaca.

Stack tipico

Ollama (Qwen 3.5 9B per rientrare negli 8 GB, oppure Mistral Small 24B con 16 GB per un francese più curato) + Qdrant/Chroma + nomic-embed-text + Open WebUI o AnythingLLM.

#2. Estrattore di informazioni strutturate (fatture, CV, contratti)

Verdetto

Fine-tuning, o prompting avanzato con modalità JSON.

Perché

Il formato di output deve essere rigorosamente lo stesso ogni volta (stessi campi, stessi tipi, stessi valori predefiniti). Anche un prompt ben scritto si discosta dal formato nel 5% dei casi, compromettendo la pipeline. Un LoRA su 800 esempi annotati risolve definitivamente il problema.

Stack tipico

Unsloth o Axolotl per addestrare, esportazione in GGUF, distribuzione con Ollama. Se la base di "conoscenza" sui tipi di documenti evolve, si può combinare con un RAG leggero.

#3. Assistente giuridico sulla giurisprudenza francese

Verdetto

Ibrido — prima RAG, poi fine-tuning se il vocabolario resta limitato.

Perché

Il corpus di giurisprudenza è enorme e cambia ogni mese (il RAG è indispensabile per avere decisioni aggiornate). Ma il lessico giuridico francese è poco coperto dalla maggior parte dei modelli open-weight, e un fine-tuning leggero (LoRA su 2-3000 esempi di domande/risposte giuridiche) migliora significativamente la comprensione dei termini prima che il RAG entri in gioco.

Stack tipico

Légifrance/Doctrine come fonti → Qdrant + reranker BGE → LLM 14B sottoposto a fine-tuning con LoRA sul gergo giuridico francese.

#4. Generatore di codice adatto a una codebase interna

Verdetto

RAG (lettura dei file del repo), nessun fine-tuning salvo casi estremamente particolari.

Perché

Una codebase evolve ogni giorno. Un modello sottoposto a fine-tuning sarebbe obsoleto a ogni sprint. I migliori assistenti di programmazione (Continue.dev, Aider) leggono dinamicamente i file interessati tramite RAG sull'AST o sugli embedding del codice.

Stack tipico

Continue.dev + Qwen3-Coder 30B-A3B (qwen3-coder:30b, MoE 256k ctx, 3B attivi quindi veloce) o Devstral 24B tramite Ollama, recupero integrato nel plugin.

#5. Stile editoriale interno (newsletter, rapporti, schede prodotto)

Verdetto

Fine-tuning puro.

Perché

Il contenuto è nuovo ogni volta (non c'è nulla da "recuperare"), ma il tono, la struttura, il ritmo delle frasi, l'uso del "vous" e dei titoli intermedi devono essere assolutamente coerenti. È esattamente ciò che il fine-tuning codifica bene.

Stack tipico

200-500 articoli ben redatti → formato Alpaca o ChatML → QLoRA su Qwen 3.5 9B con Unsloth → esportazione in GGUF, modelfile Ollama con prompt di sistema aggiuntivo.

#I costi nascosti dei due approcci

I confronti pubblici si limitano spesso a "prezzo di una GPU per 4 ore di addestramento". La realtà operativa è più dura su entrambi i fronti.

#Costi nascosti del RAG

Qualità del chunking

La suddivisione dei documenti condiziona tutto. Se è fatta male, il retrieval restituisce frammenti fuori contesto, il LLM genera allucinazioni e nessuno capisce perché. Raramente basta «mettere i PDF in Chroma»: spesso serve un chunking per sezione, a volte un pretrattamento OCR per le scansioni.

Latenza cumulata

Embedding della query + ricerca vettoriale + (opzionale) reranker + contesto esteso per il LLM. Con una configurazione poco ottimizzata, si può passare da 400 ms (solo LLM) a 2-3 s (RAG completo). Da tenere in conto fin dalla progettazione.

Manutenzione della base documentale

Quando un documento viene eliminato o aggiornato, bisogna rimuoverlo o reindicizzarlo. Per le fonti esterne (web, API), prevedere un'attività automatizzata di aggiornamento. Più lo stack evolve, più lavoro richiede.

Qualità del modello di embedding

Per il francese, gli embedding predefiniti (come text-embedding-ada) sono mediocri. nomic-embed-text, BGE-M3 o Solon fanno la differenza — ma vuol dire conoscere le opzioni.

#Costi nascosti del fine-tuning

Preparazione del dataset

È l'80% del lavoro. Raccogliere, pulire, formattare in coppie istruzione/risposta, deduplicare, bilanciare le classi. Su 4 settimane di progetto di fine-tuning, prevedi 3 settimane di preparazione dei dati e 1 settimana di addestramento.

Rischio di regressione

Un fine-tune mal calibrato compromette le capacità generali del modello (il "catastrophic forgetting"). Il modello diventa bravo nel tuo compito e pessimo in tutto il resto. Occorre testarlo su un benchmark generico prima e dopo.

Riaddestramento a ogni modifica

Il dataset si arricchisce nel tempo. Ogni release richiede di ripetere l'addestramento con 2–12 ore di utilizzo della GPU, validare di nuovo e ripetere il deployment. Diventa obbligatorio gestire le versioni dei dataset e dei checkpoint.

Hardware di training

Eseguire l'inferenza con un 7B Q4 richiede 5 GB di VRAM, ma addestrarlo (anche con QLoRA) richiede almeno 12-16 GB. Il fine-tuning ha requisiti hardware minimi più elevati rispetto all'inferenza.

#Approccio ibrido: RAG + fine-tuning

Le architetture più efficienti non scelgono — combinano. Il fine-tuning definisce come il modello parla del tuo settore, il RAG gli dà accesso a ciò che deve sapere al momento T.

Fine-tuning sullo stile e sul formato

200-1000 esempi che consolidano il tono (aziendale, tecnico, giuridico), il formato della risposta (JSON, Markdown strutturato) e l'approccio (citare sempre la fonte, non inventare mai).

RAG sulla conoscenza fattuale

Documentazione, database di ticket, giurisprudenza, codebase — tutto ciò che cambia e che deve essere recuperabile e citabile.

Misure di salvaguardia nel prompt di sistema

Il system prompt ricorda al modello di rifiutare di rispondere se il contesto RAG è vuoto o contraddittorio. Indispensabile per limitare le allucinazioni.

#Decisione rapida in 3 domande

1. 01
   Domanda 1 — I tuoi dati cambiano più di una volta al mese?

   Se sì: RAG obbligatorio. Il fine-tune non può mantenere il ritmo senza diventare un incubo operativo.
2. 02
   Domanda 2 — Hai almeno 500 coppie input/output di qualità, verificate da persone?

   Se non è così: inizia con il RAG. Il fine-tuning su 100 esempi messi insieme alla buona degrada il modello. Se hai intenzione di accumularne, configura prima il RAG e sfrutta i suoi log per costruire il dataset.
3. 03
   Domanda 3 — Il problema è "sapere qualcosa" o "rispondere in un certo modo"?

   Sapere → RAG. Rispondere in un certo modo → fine-tuning. Entrambi → approccio ibrido. È lo schema decisionale più semplice ed è corretto in 9 casi su 10.

#Trappole classiche da evitare

"Fare fine-tuning per apprendere fatti"

L'errore più frequente. Un modello sottoposto a fine-tuning non è una base di conoscenze — interpola a partire dagli esempi visti, ma genera allucinazioni sui dettagli precisi (numeri, date, riferimenti) molto più di un RAG.

"RAG senza reranker" su corpus > 10k chunk

La sola ricerca vettoriale recupera molti risultati, ma non sempre quelli pertinenti. Un reranker cross-encoder (BGE, mxbai) applicato ai primi 20 risultati cambia radicalmente la qualità, con un tempo aggiuntivo di 50–100 ms.

Confondere RAG e contesto lungo

"Mi limiterò a mettere tutto il documento nel prompt". Oltre gli 8k token utili, la qualità cala drasticamente (perdita nella parte centrale, "lost in the middle"). Un RAG con una buona suddivisione in blocchi supera un contesto lungo usato ingenuamente a partire da un certo volume.

Eseguire il fine-tuning su un modello già allineato, con un dataset non allineato

Se esegui il fine-tuning di un modello "instruct" con esempi che non hanno la stessa struttura del prompt, rompi l'allineamento e il modello si comporta in modo strano. Rispettare sempre il template del modello (ChatML, Alpaca, Mistral, Llama-3 chat).

Volere un benchmark pubblico per decidere

Nessun benchmark generico ti dirà se, nel TUO caso, si ottengono risultati migliori con il RAG o con il fine-tuning. Predisponi una valutazione interna con 30-50 domande rappresentative e misura i risultati prima di passare all'impiego su scala industriale.

#Per approfondire

Una volta presa la decisione, le guide corrispondenti illustrano l'implementazione concreta, con le insidie e le ottimizzazioni.

Implementazione del RAG senza scrivere codice

Open WebUI o AnythingLLM permettono di creare un RAG documentale in poche ore, senza scrivere codice Python — utile per validare l'approccio prima di industrializzarlo.

Fine-tuning locale LoRA / QLoRA

La guida dedicata tratta Unsloth, il formato del dataset, la scelta tra LoRA e QLoRA e l'esportazione GGUF per Ollama. Una RTX 3090 basta per un 7B.

Ottimizzare un RAG già esistente

Reranker, ricerca ibrida BM25 + vettoriale, strategie di chunking — tre leve che trasformano un RAG "che funziona" in un RAG pronto per la produzione.