RAG vs Fine-Tuning: perché il vostro modello AI non impara davvero

Se una agenzia vi ha vendito un "assistente AI aziendale" negli ultimi 12 mesi, c'è una probabilità del 95% che dietro ci sia la stessa architettura: un modello generico (GPT-4, Claude, Gemini) esposto via API, a cui vengono passati i vostri documenti al volo a ogni richiesta. Questa tecnica si chiama RAG — Retrieval Augmented Generation. Funziona. Ma nasconde due problemi che quasi nessuno vi spiega.

In questo articolo spieghiamo la differenza tra RAG e fine-tuning in termini concreti, senza buzzword. Parliamo di cosa succede davvero ai vostri dati, di perché il vostro modello non sta imparando nulla, e di cosa cambia quando si fa la cosa difficile: addestrare un modello proprio sui vostri dati.

Cos'è il RAG (e perché lo vendono tutti)

RAG significa Retrieval Augmented Generation. L'idea è semplice: c'è un modello di linguaggio generico che non conosce la vostra azienda, e ci sono i vostri documenti. Quando un utente fa una domanda, un sistema intermedio cerca nei documenti i 3-5 paragrafi più rilevanti e li mette davanti al modello come contesto. Il modello risponde usando quel contesto.

Immaginate uno straniero che non ha mai lavorato nella vostra azienda. Ogni volta che qualcuno gli fa una domanda, gli passate al volo le pagine giuste del manuale. Lui legge, risponde, dimentica tutto. Domani, stessa domanda, stesso rito: ripassate le pagine, risponde, dimentica. Questo è RAG.

Il motivo per cui tutti lo vendono è pragmatico: è l'approccio più veloce e meno costoso da mettere in piedi. Non serve hardware potente (si appoggia alle API esterne), non serve competenza di training AI (il modello è già pronto), e si vedono risultati decenti in poche settimane. Per molti casi d'uso funziona. Per altri, i limiti diventano problemi reali.

I due problemi reali del RAG per un'azienda

1. I vostri dati escono. Sempre. Ad ogni richiesta.

Ogni volta che un dipendente o un cliente pone una domanda al vostro assistente AI basato su RAG, il sistema recupera frammenti di documenti interni — contratti, comunicazioni, pratiche, anagrafiche — e li invia al modello esterno via API. Il modello vive sui server del fornitore, che nel 99% dei casi è negli Stati Uniti.

Questo significa che, migliaia di volte al giorno, piccoli pezzi dei vostri dati più sensibili attraversano l'oceano Atlantico. L'utente non lo vede. Il manager non lo vede. Il Data Protection Officer, quando fa l'audit annuale, lo scopre — e parte il panico.

Per uno studio legale che elabora atti, per una clinica con cartelle cliniche, per un commercialista con dichiarazioni dei redditi, questo è inaccettabile sotto il GDPR. Anche con data processing agreement, sub-processor clauses e tutta la documentazione del caso, il dato lascia l'Europa. L'AI Act, che entra pienamente in vigore nel 2026, aggiunge ulteriori restrizioni.

2. Il modello non impara. Mai.

Il secondo problema è più sottile ma altrettanto serio. Un sistema RAG non impara mai davvero la vostra azienda. Legge contesto al volo, risponde, dimentica. Ogni domanda parte da zero.

Le conseguenze pratiche sono tre:

• Tono e stile incoerenti: il modello risponde col suo tono generico, non col linguaggio della vostra azienda. Ogni settore ha un gergo, una struttura espositiva, formalità specifiche. Un modello RAG non le interiorizza, le mima solo quando trova un esempio nel contesto recuperato.
• Ragionamento limitato: se la risposta richiede di collegare informazioni presenti in 15 documenti diversi, il sistema RAG ne recupera forse 5. Gli altri 10 pezzi di contesto mancano, e la risposta è parziale o errata.
• Uso massivo di token: a ogni domanda si manda al modello contesto lungo (migliaia di parole). Il costo cresce linearmente. Su un sistema usato 500 volte al giorno, i costi API esplodono.

Cos'è il fine-tuning (la strada difficile)

Il fine-tuning è un'altra cosa. Invece di passare il contesto al volo a un modello generico, si parte da un modello base open-source e lo si addestra direttamente sui dati dell'azienda. L'addestramento modifica i pesi interni del modello: dopo il training, il modello conosce permanentemente il dominio dell'azienda. Non legge, sa.

Pensate alla differenza tra uno studente che studia per un esame (fine-tuning) e uno studente che lo affronta con il libro aperto davanti (RAG). Entrambi possono rispondere. Il primo lo fa più velocemente, con più coerenza interna, e connettendo concetti che nel libro sono a pagine diverse. Il secondo deve cercare, leggere, interpretare — ogni volta.

Un modello fine-tuned sui vostri atti legali conosce il vostro linguaggio, le vostre sentenze ricorrenti, i vostri clienti tipo, le vostre strutture argomentative. Un modello fine-tuned sulla vostra documentazione medica conosce protocolli, casi passati, cartelle anonimizzate, linguaggio del vostro reparto specifico.

Differenza pratica: studio legale con 80.000 atti

Facciamo un esempio concreto. Uno studio legale con 80.000 atti digitalizzati vuole un assistente AI per aiutare gli avvocati a impostare nuove cause, trovare precedenti interni, redigere bozze di memorie.

Con il RAG: l'avvocato pone una domanda. Il sistema cerca vettorialmente i 5 atti più simili, li manda al modello esterno via API. Il modello risponde usando quei 5 atti. Problemi:

• I 5 atti scelti potrebbero non essere i più rilevanti — il vector search è approssimato
• Se l'atto rilevante è lungo, ne viene passato solo un estratto
• Lo stile di scrittura delle risposte è quello del modello generico, non del vostro studio
• I dati escono, ogni volta, dal perimetro europeo
• Il modello non sviluppa intuizione sul vostro modo di impostare le cause

Con il fine-tuning: il modello viene addestrato per settimane sugli 80.000 atti. Dopo l'addestramento conosce i pattern argomentativi dello studio, le strutture formali, i clienti ricorrenti, la giurisprudenza di riferimento. L'avvocato pone una domanda: il modello risponde in uno stile coerente con lo studio, collegando concetti presenti in centinaia di atti diversi, senza che un singolo byte esca dal perimetro aziendale. Risposta più veloce, più coerente, più privata.

Perché quasi nessuno lo fa davvero

Il motivo è banale: fine-tuning on-premise richiede tre cose che poche agenzie in Italia mettono insieme.

• Hardware dedicato: GPU con abbastanza memoria per fare training, non solo inferenza. Parliamo di investimenti reali in server, non di API calls da pochi centesimi.
• Competenza di training: saper scegliere il modello base giusto, preparare il dataset, gestire il training, valutare il risultato senza che il modello "dimentichi" ciò che sapeva prima (catastrophic forgetting).
• Infrastruttura di deploy privata: non basta addestrare, serve servire il modello ai dipendenti con latenze basse, alta concorrenza, alta disponibilità. Tutto in Italia, tutto sotto controllo.

Le agenzie che vendono RAG non lo fanno perché sono cattive. Lo fanno perché costruire la pipeline completa costa di più, richiede anni di competenza, e non tutti i clienti hanno il budget o la sensibilità. Ma per un cliente con dati davvero sensibili — studi legali, strutture sanitarie, PA, banche — non esiste alternativa.

RAG e fine-tuning non sono sempre in contrapposizione

Per onestà: ci sono casi in cui RAG è la scelta giusta. Documentazione che cambia ogni giorno (e non si può ri-addestrare costantemente), basi di conoscenza dinamiche, casi d'uso dove i dati non sono particolarmente sensibili. E le due tecniche possono coesistere: un modello fine-tuned sul dominio che usa RAG per recuperare informazioni in tempo reale (prezzi, disponibilità, stato di un ordine).

Quello che va evitato è pensare che RAG sia l'unica opzione, o che "fine-tuning" sia una parola magica vuota. Sono due strumenti diversi con casi d'uso diversi. La scelta dipende dalla sensibilità dei dati, dal volume di query, dal budget, e da quanto è importante che il modello "parli" come l'azienda.

La domanda giusta da fare al vostro consulente AI

Se state valutando una soluzione AI per la vostra azienda, la domanda non è "fate AI con GPT-4?". È più specifica:

• Dove vivono i dati durante inferenza?
• Dove vivono i dati durante il training, se ne fate?
• Il modello impara i nostri dati o li legge al volo?
• Su quale infrastruttura gira il modello, di chi è, dove è fisicamente?
• Se domani la normativa ci obbliga a rientrare in EU, siamo già conformi?

Se la risposta onesta a una di queste domande è "i dati passano da server USA", per voi — come azienda regolata — la soluzione non va bene. Punto. Non è un dettaglio tecnico: è rischio legale e reputazionale.