Fine-tuning vs RAG: quale approccio scegliere per applicazioni aziendali specifiche

Nell'arco di quattro settimane di marzo 2026 ho affrontato nella mia sandbox personale due problemi apparentemente simili e strutturalmente opposti, e la diagnosi che ho dovuto fare per scegliere l'approccio corretto è il cuore di questo articolo. Il primo problema: un task di classificazione di documenti interni - 14 categorie predefinite, 1.200 documenti di esempio etichettati, 30-50 nuovi documenti al giorno da categorizzare. Il secondo problema: un task di generazione di bozze contrattuali in stile aziendale - 150 esempi di contratti precedenti, tono specifico da replicare, uscita di 2.000-3.500 parole per contratto, clausole ricorrenti. Il mio istinto iniziale, influenzato dal rumore di mercato, è stato: fine-tuning per entrambi. È un modello migliore per il tuo dominio, no? La risposta corretta, emersa dopo analisi rigorosa, è stata RAG per il primo, fine-tuning per il secondo - e il ragionamento di come sono arrivato a quella scelta è più utile dei risultati stessi. L'infrastruttura di test era un Hetzner GEX44 (RTX 4000 Ada, 20 GB VRAM, Intel Xeon Gold 5412U, 64 GB RAM, 2x NVMe 1,92 TB, Debian 12) per le fasi di fine-tuning con LoRA, e un Hetzner CCX33 separato per il RAG su pgvector. Ho speso circa 180 dollari di API Claude complessivi nelle quattro settimane di test, 30 euro di costo elettrico sul server GPU di laboratorio, e il tempo vero - il giudizio su quale approccio usare - è stato il vincolo più scarso.

Come capire se serve fine-tuning o RAG senza fare né l'uno né l'altro alla cieca?

La risposta breve è che la scelta dipende da quattro variabili osservabili e misurabili, non dall'intuizione. Prima: i dati sono aggiornati frequentemente? Se il knowledge che l'applicazione usa cambia settimanalmente o mensilmente, fine-tuning è insostenibile - ogni update dei dati richiederebbe un nuovo ciclo di training, con costi e downtime inaccettabili. RAG è la scelta obbligata. Seconda: il task richiede style transfer o pattern linguistico specifico? Se l'output deve suonare in un certo modo - tono aziendale, formato contrattuale, slang tecnico di dominio - RAG da solo fatica. Il modello base impara lo stile solo per esposizione ripetuta durante il training; few-shot prompting arriva al 60-70% della qualità, fine-tuning al 90-95%. Terza: la latenza conta? RAG ha retrieval overhead (50-300 ms di vector search), fine-tuning no. Su task che devono rispondere sotto i 200 ms, fine-tuning è avvantaggiato. Quarta: ho dati di training sufficienti? Fine-tuning utile parte da 500-1.000 esempi di qualità; sotto quella soglia il modello non impara nulla di robusto, solo rumore specifico ai pochi esempi forniti.

Nel caso dei miei due problemi, la tabella di queste quattro variabili ha prodotto verdict opposti. Classificazione documenti: dati aggiornati? Sì, 30-50 nuovi documenti al giorno. Style transfer? No, il task è classificazione, non generazione. Latenza critica? No, 2-5 secondi accettabili. Dati sufficienti? 1.200 etichettati è sotto la soglia fine-tuning. Tutti e quattro i parametri spingevano a RAG. Generazione contrattuale: dati aggiornati? Poco frequenti, cambiano ogni 6-12 mesi. Style transfer? Sì, criticamente. Latenza critica? Moderatamente (5-15 secondi accettabili ma non 30). Dati sufficienti? 150 esempi è basso ma per LoRA con quantization su 7B model è al limite inferiore fattibile. Tre parametri su quattro spingevano a fine-tuning. Ogni decisione motivata, nessuna "intuizione".

Se vuoi vedere come progetto pipeline AI per applicazioni aziendali dove la scelta fra fine-tuning e RAG passa da diagnosi strutturata invece che da mode, nel mio hub sull'integrazione AI per aziende trovi articoli su vector database, embedding, orchestrazione LLM - con criterio comune di evitare l'ottimizzazione prematura dove basta una soluzione più semplice.

Il primo sintomo del problema: "proviamo fine-tuning su tutto"

Quando un team PMI italiano inizia a sentire parlare di AI per il proprio business, il pitch dominante è "fine-tuning di un modello sul tuo dato aziendale". Il pitch è attraente perché evoca esclusività ("il nostro modello") e differenziazione ("nessun altro ha il mio modello"). È quasi sempre sbagliato come scelta di prima mossa. Per due ragioni strutturali. Prima: fine-tuning richiede dati puliti, etichettati, rappresentativi e sufficienti. La maggior parte delle PMI non ha quei dati - ha dati sporchi, non etichettati, rumorosi, con pregiudizi storici difficili da scartare. Dare quei dati a un fine-tuning produce un modello che impara pattern di sporco, non pattern di business. Seconda: fine-tuning congela una foto del mondo al momento del training. Se il business evolve (nuovi prodotti, nuove regolazioni, nuovi pattern di cliente), il modello diventa rapidamente obsoleto e richiede retraining. RAG, al contrario, ha il knowledge base come componente separato che puoi aggiornare senza toccare il modello.

La diagnosi corretta parte dalla domanda opposta: perché NON dovrei usare RAG? Se RAG regge il tuo caso d'uso - e per il 70-80% dei casi d'uso PMI lo fa - fine-tuning aggiunge complessità senza beneficio. La domanda sul fine-tuning emerge solo quando RAG ha un limite specifico e documentato: latenza, style transfer, risposta su knowledge estremamente specializzato che il modello base non ha mai visto.

Caso uno: la classificazione dei documenti interni, dove il RAG ha vinto

Il task concreto era classificare documenti interni in 14 categorie predefinite (contratto-fornitore, fattura-elettronica-attiva, fattura-elettronica-passiva, nota-credito, ordine-cliente, ordine-fornitore, DDT-in, DDT-out, corrispondenza-legale, contratto-cliente, preventivo-out, preventivo-in, rapporto-interno, altro). I 1.200 documenti di training erano già etichettati correttamente - una risorsa preziosa - ma 1.200 è sotto la soglia fine-tuning efficace su un modello 7B+ parametri.

La mia prima prova è stata fine-tuning via LoRA su Llama 3.1 8B con i 1.200 esempi. Il modello raggiungeva 82% di accuracy sul test set dopo 4 epoche, ma non generalizzava: i documenti del mese successivo, anche di categoria già vista, accuracy crollava al 71%. Il modello stava memorizzando quirk specifici dei 1.200 esempi, non imparando il concetto. Classic overfitting su piccolo dataset.

La seconda prova è stata RAG: embedding dei 1.200 documenti con Nomic Embed Text v1.5, vector store pgvector con HNSW (configurazione che ho descritto nell'articolo su pgvector in produzione), prompt a Claude Sonnet 4.6 con i top-5 documenti simili come few-shot context e istruzione di classificare il documento nuovo. Accuracy sul test set: 93%. Accuracy sui documenti del mese successivo: 91%. Generalizzazione tenuta perché il modello non stava imparando dal training set - stava semplicemente ragionando su esempi simili recuperati al volo. E ogni documento nuovo etichettato entra immediatamente nel knowledge base al giorno dopo, senza retraining.

Il costo era il terzo parametro a favore di RAG. Fine-tuning LoRA: circa 45 dollari di API Fireworks (o 4 ore di GPU laboratorio a circa 15 euro in elettricità e ammortamento, più 1,5 ore di mio tempo per setup e tuning). Ripetibile ad ogni retraining. RAG: 18 dollari di API una tantum per l'ingestione iniziale, poi 0,03 dollari per classificazione. Su 40 documenti al giorno medi, circa 36 dollari al mese operativi, totalmente lineari e prevedibili.

Il verdict è stato chiaro: RAG domina nel caso con dati aggiornati frequentemente, task di classificazione con knowledge bounded, e dataset di training sub-millecinquecento. Ho chiuso la prova di fine-tuning e messo in produzione la pipeline RAG.

Caso due: la generazione contrattuale dove il fine-tuning ha vinto

Il task secondo era generare bozze di contratto di servizio in stile aziendale specifico. I 150 esempi di contratti precedenti condividevano caratteristiche consistenti - struttura a 8 sezioni standardizzate, tono formale ma non legalese, clausole ricorrenti su foro competente, privacy, forza maggiore, con variazioni di linguaggio sottili ma riconoscibili.

Prima prova: RAG. Embedding dei 150 contratti, retrieval dei 5 più simili al brief del cliente, prompt a Claude Sonnet 4.6 con istruzione "genera un contratto nello stesso stile dei seguenti esempi". Il risultato era funzionalmente corretto - tutte le clausole c'erano, la struttura era giusta, l'italiano era scorrevole - ma lo stile non matchava. Un avvocato umano che leggeva le bozze RAG e le confrontava con esempi autentici diceva, ogni volta: "è plausibile ma non è nostro". Differenze sottili di lessico, formulazione di condizioni, uso di frasi marcatamente aziendali. Il RAG con few-shot non trasferisce lo stile abbastanza.

Seconda prova: fine-tuning LoRA su Llama 3.1 8B con i 150 esempi di contratto, mascherati per proteggere dati personali e nominativi, normalizzati in formato markdown, split in training-validation 130/20. Dopo 8 epoche con learning rate 2e-5 e batch size 4, la validation loss si stabilizzava a 0,78. Il modello generava contratti che un umano confrontava con autentici e diceva: "suona come nostro". Il 89% delle bozze passava il controllo di uno stakeholder senza modifiche significative, contro il 42% delle bozze RAG. Su 30-40 contratti al mese, la differenza tradotta in tempo di revisione era di 15-25 ore risparmiate mensilmente.

La diagnosi tecnica: fine-tuning è richiesto quando lo style transfer è l'obiettivo core e gli esempi di training sono sufficienti. In questo caso 150 esempi dello stesso genere, con distribuzione ristretta di vocabolario e struttura, erano effettivamente abbastanza per un LoRA su 7B. Su un task con 1.200 esempi distribuiti su 14 categorie diverse, gli esempi per classe scendevano a 85 - troppo pochi per qualunque fine-tuning utile.

Le quattro variabili con soglie concrete di decisione

Dopo questi due casi e una dozzina di altri progetti simili analizzati nella sandbox, ho formalizzato un decision tree operativo per la scelta. Le quattro variabili hanno soglie misurabili.

Variabile uno: frequenza di aggiornamento del knowledge. Soglia RAG forzata: aggiornamenti più frequenti di mensili. Soglia fine-tuning fattibile: aggiornamenti meno frequenti di trimestrali. In mezzo, valuta caso per caso.

Variabile due: tipo di task. Se classificazione, estrazione, domanda-risposta su fatti - RAG vince quasi sempre. Se generazione con style transfer, traduzione stile, ton-of-voice specifico - fine-tuning può avere senso.

Variabile tre: dimensione dataset. Sotto i 500 esempi di qualità per categoria target, fine-tuning è rischioso (overfitting). Sopra i 2.000 esempi ben distribuiti, fine-tuning è fattibile. In mezzo è grigio.

Variabile quattro: latenza tolerable. Sotto i 200 ms, fine-tuning avvantaggiato (niente retrieval overhead). Sopra i 500 ms, RAG non ha penalty percepibile. In mezzo dipende dall'UX specifica.

La regola pratica che uso in prima proposta a clienti: inizia sempre con RAG su Sonnet come baseline, misura l'accuracy, e considera fine-tuning solo se RAG fallisce in un punto specifico identificato. L'alternativa - partire con fine-tuning e ottimizzare - è inversa al principio di fit for purpose e produce la classica situazione dei 40% di progetti agentic AI cancellati entro il 2027 che Gartner ha previsto nel suo press release di giugno 2025: tecnologia sofisticata applicata al problema sbagliato, con aspettative di ROI che non si materializzano.

Il caso ibrido: quando combinare RAG e fine-tuning ha senso

Il terzo scenario che merita menzione è quello ibrido. Se il task richiede contemporaneamente style transfer (fine-tuning) e knowledge aggiornato frequentemente (RAG), l'architettura corretta non è "scegli uno", è "usali insieme". Il modello base viene fine-tunato per lo stile - tono, formato, lessico - ma riceve al runtime il knowledge aggiornato via retrieval. Questa è l'architettura che ho progettato per un proof of concept separato di knowledge assistant per dominio normativo italiano: LoRA su base per il tono tecnico-giuridico italiano, RAG su pgvector per il corpus normativo aggiornato mensilmente. Il costo è la somma delle due - ingegneria di fine-tuning + infrastruttura RAG - e si giustifica solo quando entrambi i requisiti sono critici. Per la maggior parte dei casi PMI, uno dei due è dominante e basta.

Il costo totale di ownership, che nessuno calcola prima di partire

La parte più sottostimata di entrambi gli approcci è il costo operativo nel tempo, non il costo iniziale. RAG ha costi lineari e prevedibili: per ogni query, paghi il retrieval (trascurabile se pgvector è self-hosted) più la chiamata al modello generatore. Zero retraining, zero infrastructure GPU dedicata, zero manutenzione ricorrente. Fine-tuning ha un costo iniziale una-tantum (400-2.000 dollari per un LoRA su modello 7B, molto di più su modelli più grandi) più un costo ricorrente di retraining ogni volta che il dominio evolve. Se il retraining avviene ogni 6 mesi, il costo ammortizzato è gestibile; se avviene ogni mese, è un disastro operativo. Inoltre il fine-tuning produce un modello custom che devi ospitare o mandare a un provider specializzato - aggiungi 200-800 dollari al mese di GPU hosting.

La regola operativa pragmatica: la somma dei costi operativi di 12 mesi è l'indicatore di scelta più affidabile, non il costo del singolo training. Un modello fine-tunato che costa 2.000 dollari di setup ma richiede 300 dollari al mese di hosting costa 5.600 dollari in un anno. Un sistema RAG che costa 300 dollari di setup e 80 dollari al mese di API costa 1.260 dollari in un anno. A parità di qualità funzionale, RAG è 4x più economico. Questa analisi si fa prima di partire, non dopo aver speso il primo budget di 2.000 dollari.

Quando la scelta è di principio, non tecnica

Ci sono tre contesti in cui la scelta è dominata da ragioni non tecniche. Primo: compliance o sovereignty - se il contratto con il cliente impone che i dati non lascino un certo perimetro, fine-tuning self-hosted su GPU locale è obbligato, anche se tecnicamente RAG basterebbe. L'architettura self-hosted LLM con nvidia-container-toolkit su VPS GPU che ho descritto è il fondamento di questa scelta: non usi l'API Anthropic perché i dati non possono lasciare l'UE. Secondo: offline requirement - se il sistema deve funzionare senza connettività (ambiente industrial, air-gapped network), fine-tuning è l'unica strada. Terzo: competitive moat - se il cliente vuole un modello che i concorrenti non possono replicare, il fine-tuning produce un asset proprietario che RAG non produce (chiunque può ricostruire un RAG standard, pochi possono replicare il tuo fine-tuned). Questi tre contesti giustificano fine-tuning anche contro la diagnosi tecnica.

La domanda "fine-tuning o RAG?" ha quasi sempre una risposta sbagliata quando viene posta come domanda binaria astratta. La risposta giusta emerge solo quando qualcuno si siede per un'ora con carta e penna, elenca i dati reali che ha, la frequenza di aggiornamento reale, il budget reale, e fa la diagnosi contro le quattro variabili sopra. La tentazione di saltare questa diagnosi per eccitazione della novità è esattamente il punto in cui tanti progetti AI bruciano soldi senza produrre valore. E la metà dei progetti falliti nel 2026 sta fallendo non perché la tecnologia non funzioni, ma perché è stata applicata al problema sbagliato. Un consulente AI che fa la diagnosi prima di proporre tecnologia sta facendo il lavoro dell'ingegnere serio - non è marketing buzzword, è il prerequisito per un ROI misurabile.

Se stai valutando un'introduzione di LLM nel tuo business e non sei certo se il tuo caso d'uso è RAG, fine-tuning, o una delle architetture ibride, il modulo di preventivo gratuito ti dà una prima lettura in 7 domande, 2 minuti. Ti dico se il tuo progetto rientra nelle cose che so fare bene e, se il caso richiede un profilo diverso, te lo dico e ti indico una direzione utile quando posso.