RAG o fine-tuning: come scegliere per un progetto AI

RAG o fine-tuning non sono due nomi diversi per la stessa operazione. Il primo collega il modello a fonti esterne recuperate al momento della domanda; il secondo modifica il comportamento del modello usando esempi di addestramento. La scelta corretta parte quindi dal problema: servono informazioni aggiornabili oppure risposte più coerenti in un compito stabile?

RAG o fine-tuning: la differenza operativa

Con la Retrieval-Augmented Generation, una richiesta attiva una ricerca in un indice di contenuti. I passaggi più pertinenti vengono aggiunti al contesto del modello, che formula la risposta usando quel materiale. I documenti possono essere aggiornati senza riaddestrare il modello e, se il sistema è progettato bene, la risposta può rimandare alle fonti consultate.

Il fine-tuning, invece, parte da un insieme di esempi rappresentativi e aggiorna i pesi del modello. È utile quando si vuole stabilizzare un comportamento: classificare ticket, produrre un formato rigoroso, adottare un lessico specialistico o seguire istruzioni ricorrenti. Non è il metodo più pratico per memorizzare un catalogo o una procedura che cambia ogni settimana.

Quando scegliere RAG

RAG è spesso la prima opzione quando il valore risiede nei contenuti: manuali interni, contratti, procedure, cataloghi, policy o basi di conoscenza. È adatto anche quando utenti diversi possono vedere documenti diversi, perché il controllo degli accessi può essere applicato durante il recupero.

Il punto debole è altrettanto concreto. Se l’indice contiene versioni obsolete, i frammenti sono tagliati male o la ricerca non trova il passaggio giusto, il modello riceve un contesto insufficiente. Prima di cambiare modello conviene misurare recall, pertinenza, copertura delle fonti e correttezza delle citazioni.

Quando scegliere il fine-tuning

Il fine-tuning ha senso quando l’obiettivo è ripetibile e gli esempi mostrano chiaramente l’output desiderato. Può ridurre prompt molto lunghi, rendere più uniforme una classificazione o far rispettare uno schema di risposta. Richiede però un dataset pulito, rappresentativo dei casi reali e accompagnato da una batteria di valutazione.

Una raccolta di esempi incoerenti trasferisce l’incoerenza nel modello. Inoltre, ogni modifica rilevante a processo, tassonomia o policy può richiedere una nuova preparazione dei dati e un nuovo ciclo di test. Per questo fine-tuning non significa aggiornamento automatico della conoscenza.

La distinzione più utile è semplice: RAG porta informazioni nel contesto; il fine-tuning insegna un comportamento. Questa logica si collega al context engineering, dove qualità e selezione del contesto diventano parte dell’architettura.

Quando combinarli

Un’architettura ibrida può usare RAG per recuperare informazioni verificabili e fine-tuning per applicare un formato, un tono o una procedura stabile. È una soluzione valida solo se i due bisogni sono stati dimostrati separatamente. Aggiungere entrambi fin dall’inizio aumenta costi, punti di guasto e lavoro di valutazione.

Una decisione da validare con un prototipo

Per scegliere tra RAG o fine-tuning conviene costruire il sistema minimo che possa smentire l’ipotesi iniziale. Un prototipo RAG deve misurare prima il recupero e poi la risposta. Un esperimento di fine-tuning deve essere confrontato con un buon prompt di base sugli stessi casi. Solo risultati ripetibili giustificano l’aumento di complessità.