RAG o fine-tuning: guida pragmatica per i team AI aziendali

La domanda sbagliata

Quasi tutti i team AI enterprise impostano la questione come "RAG o fine-tuning?", come se fosse una scelta binaria. In pratica la risposta dipende da quattro variabili specifiche del tuo caso d'uso, e l'architettura giusta spesso combina elementi di entrambi.

Quando vince il RAG

Il RAG è la scelta predefinita giusta quando la base di conoscenza cambia spesso: ogni settimana, ogni giorno o in tempo reale. Corpus documentali, cataloghi prodotto, testi normativi, linee guida cliniche: evolvono di continuo. Rifare il fine-tuning di un modello ogni volta che cambia il materiale sorgente non è sostenibile sul piano operativo.

Il RAG vince anche sulla tracciabilità. Ogni risposta generata può citare i documenti da cui proviene. Nei settori regolati (sanità, farmaceutico, finanza) non è un di più: è un requisito di compliance. Se un auditor chiede "perché il sistema ha detto questo?", devi poter indicare un documento, un paragrafo e una versione precisi.

Infine, il RAG non richiede cicli di addestramento ad alto consumo di GPU. Aggiorni il vector store; il modello resta lo stesso. Questo lo rende più semplice da gestire e molto più economico da mantenere.

Quando vince il fine-tuning

Il fine-tuning è indicato quando il modello deve imparare un comportamento, un tono o uno schema di ragionamento specifico che non si riesce a ottenere in modo affidabile con il solo prompting e il retrieval. Linguaggi di dominio, compiti di classificazione specialistici o requisiti di formattazione dell'output costanti su tutte le richieste sono buoni candidati.

Il fine-tuning riduce anche la latenza di inferenza: la conoscenza è incorporata nei pesi del modello, quindi non c'è un passaggio di retrieval. Per le applicazioni in cui la latenza è critica (interfacce vocali in tempo reale, classificazione ad alto throughput) questo conta.

Il prezzo è la rigidità. Un modello addestrato con fine-tuning riflette lo stato dei dati di training al momento dell'addestramento. Se la conoscenza sottostante cambia, devi riaddestrare, e riaddestrare è costoso, lento e richiede una valutazione attenta per evitare regressioni.

Il framework decisionale

Nei nostri deployment in produzione applichiamo quattro criteri:

• Aggiornamento dei dati: se il materiale sorgente cambia più di una volta al mese → RAG.
• Requisito di tracciabilità: se devi citare le fonti → RAG.
• Budget di latenza: se servono meno di 200 ms e il retrieval aggiunge un overhead inaccettabile → fine-tuning (o approccio ibrido).
• Coerenza di comportamento: se il modello deve adottare in modo affidabile un tono, un formato o una catena di ragionamento specifici → fine-tuning per il comportamento di base, RAG per la conoscenza.

Analisi dei costi: quanto costa davvero ciascun approccio in produzione

Il RAG ha un costo iniziale più basso ma costi operativi continui: hosting del vector store, calcolo degli embedding per l'ingestione dei documenti e overhead di latenza del retrieval su ogni richiesta. Su infrastruttura on-premise questo costo dipende dal volume di richieste e da quanto spesso cambiano i documenti.

Il fine-tuning ha un costo iniziale più alto (ore GPU per l'addestramento, cura del dataset, cicli di valutazione) ma un costo per richiesta più basso una volta in produzione, perché non c'è il passaggio di retrieval. Il costo di un ciclo di fine-tuning dipende dalla dimensione del modello e del dataset e dall'infrastruttura, e si ripresenta ogni volta che i dati di training cambiano in modo significativo.

Il costo nascosto del fine-tuning è la valutazione. Ogni nuova versione del modello va testata con rigore su benchmark di regressione prima di sostituire il modello in produzione. Nei settori regolati questa valutazione non è facoltativa: è un requisito di compliance. Il RAG aggira del tutto il problema: aggiornare la base di conoscenza non cambia il modello, quindi l'onere di valutazione si limita alla qualità del retrieval, che è più economica e più rapida da testare.

Metodologia di valutazione: misurare ciò che conta

Come fai a sapere se la tua pipeline RAG o il tuo modello con fine-tuning funzionano davvero bene? Nei nostri deployment in produzione misuriamo quattro dimensioni:

• Fedeltà: la risposta riflette correttamente il materiale sorgente? Per il RAG significa verificare che le fonti citate sostengano le affermazioni fatte. Per i modelli con fine-tuning significa valutarli su un test set tenuto da parte.
• Pertinenza: la risposta affronta la domanda reale? Si misura con la similarità semantica tra l'intento della richiesta e il contenuto della risposta.
• Completezza: la risposta copre tutti gli aspetti rilevanti? Si valuta rispetto a risposte di riferimento curate da esperti per i casi d'uso critici.
• Innocuità: la risposta evita contenuti clinicamente pericolosi, problematici sul piano legale o errati nei fatti? Si valuta con test avversariali e revisione da parte di esperti di dominio.

Nei casi d'uso sanitari e farmaceutici dominano fedeltà e innocuità. Una risposta pertinente e completa ma non fedele al materiale sorgente è peggio di nessuna risposta. Questa priorità di valutazione favorisce in modo naturale le architetture RAG, dove ogni affermazione è riconducibile a un documento preciso.

L'approccio ibrido

Nella maggior parte dei casi d'uso enterprise che portiamo in produzione, la risposta è un modello di base con fine-tuning (per tono, formato e ragionamento di dominio) combinato con il RAG (per una conoscenza aggiornata e tracciabile). È così che funziona Nexus MDS Core: un model server locale o un endpoint UE sostituibile fornisce il livello di inferenza, Weaviate fornisce la vector search e la pipeline RAG garantisce che ogni risposta sia ancorata a materiale sorgente verificabile.

Il livello con fine-tuning gestisce quello che chiamiamo "comportamento": come risponde il modello, che formato usa, quali catene di ragionamento segue e come tratta i casi limite. Il livello RAG gestisce la "conoscenza": ciò che il modello sa, attinto da documenti che si aggiornano senza riaddestrare. Questa separazione delle responsabilità rispecchia bene la realtà organizzativa: il comportamento cambia di rado (e va governato con cura), la conoscenza cambia di continuo (e deve essere facile da aggiornare).

Per capire meglio come governiamo gli output AI in produzione, compresi i livelli di audit logging e di validazione che stanno sopra sia al RAG sia ai modelli con fine-tuning, leggi il nostro articolo su come governare gli output AI nei settori regolati.