RAG o fine-tuning? Cosa ci hanno insegnato i progetti reali con i clienti sulla scelta

Quasi tutte le conversazioni sull’IA in ambito aziendale a cui partecipo arrivano allo stesso bivio entro la prima ora. Il cliente ha un modello linguistico di grandi dimensioni che fa un’ottima impressione durante una demo, ma non conosce i suoi prodotti, le sue policy né il suo stile di scrittura. Qualcuno nella stanza chiede: dovremmo sottoporre il modello a fine-tuning sui nostri dati o costruirci attorno un sistema di generazione aumentata dal recupero (RAG)?

La risposta onesta è che, di solito, la domanda è posta nel modo sbagliato. RAG e fine-tuning risolvono problemi diversi. I team che li considerano opzioni concorrenti tendono a passare mesi e a spendere una grossa fetta del budget GPU per risolvere il problema sbagliato. Ecco come decidiamo nella pratica e cosa abbiamo visto funzionare e non funzionare.

Partire da ciò che manca al modello

Quando un modello dà una risposta scadente a un’attività aziendale, gli manca una di due cose.

Gli mancano le conoscenze. Non conosce il tuo listino prezzi più recente, la clausola del tuo contratto con i fornitori del 2025 o le procedure di risoluzione dei problemi per un prodotto lanciato il mese scorso. È un problema legato ai fatti.

Gli manca il comportamento adeguato. Ha conoscenze sufficienti, ma non risponde nel modo che ti serve. Ignora il formato di output richiesto, usa un tono sbagliato, interpreta male i tuoi codici interni o non riesce a svolgere un’attività circoscritta e ripetitiva, come classificare i ticket nelle tue 40 categorie. È un problema di competenze.

RAG è lo strumento per il primo problema. Il fine-tuning è lo strumento per il secondo. Gran parte della confusione che riscontro nasce dal tentativo di usare il fine-tuning per insegnare fatti.

Perché il fine-tuning è un metodo poco efficace per aggiungere conoscenze

È allettante pensare che, se addestri un modello sui tuoi documenti, li «conoscerà». In pratica, apprende lo stile di quei documenti in modo molto più affidabile dei fatti che contengono. I ricercatori di Microsoft hanno confrontato direttamente i due approcci su domande che richiedono molte conoscenze e hanno scoperto che RAG ha costantemente ottenuto risultati migliori del fine-tuning non supervisionato, sia per i fatti già incontrati dal modello durante l’addestramento sia per quelli del tutto nuovi.

Ci sono anche problemi pratici. I fatti cambiano. Ogni volta che cambiano le tue policy o il tuo catalogo, un modello sottoposto a fine-tuning diventa obsoleto finché non lo addestri di nuovo. Inoltre, perdi la tracciabilità: quando un modello sottoposto a fine-tuning indica una cifra, non puoi risalire al documento da cui proviene. Per i clienti soggetti a normative nei settori assicurativo e sanitario, questo di solito basta a chiudere la discussione.

RAG, descritto per la prima volta nel lavoro del 2020 di Lewis et al., mantiene le conoscenze al di fuori del modello. Al momento della richiesta, recuperi i passaggi pertinenti e li fornisci al modello come contesto. Per aggiornare le conoscenze basta aggiornare un indice, senza riaddestrare il modello. Inoltre, ogni risposta può citare la propria fonte.

Un nostro cliente del settore logistico è un buon esempio. I suoi clienti volevano risposte immediate su dove si trovassero le loro spedizioni e su quali documenti mancassero. Queste informazioni cambiano ogni pochi minuti. Nessun addestramento avrebbe potuto mantenere aggiornato un modello, quindi l’assistente che abbiamo realizzato risponde usando i dati di tracciamento in tempo reale e i dati IoT al momento della richiesta, anziché attingere alla memoria. Il recupero era l’unica soluzione possibile.

Quando il fine-tuning è la scelta giusta

Il fine-tuning non è superato. È semplicemente più circoscritto di quanto si pensi. Lo scegliamo in tre situazioni:

• Formati di output rigidi e ripetitivi. Quando un modello deve produrre ogni giorno migliaia di volte lo stesso output strutturato, per esempio estrarre campi dalle fatture secondo uno schema JSON predefinito, un piccolo modello sottoposto a fine-tuning è spesso più affidabile e molto meno costoso che impartire istruzioni a un modello di grandi dimensioni.
• Linguaggio specialistico. In alcuni settori si usano abbreviazioni che il modello di base interpreta male. I codici di stato della logistica, le abbreviazioni cliniche e i codici interni dei prodotti sono esempi comuni. Un fine-tuning di portata limitata può risolvere il problema.
• Costi e latenza su larga scala. Quando un’attività è ben definita, un piccolo modello sottoposto a fine-tuning può sostituire un modello generalista di grandi dimensioni. Metodi come LoRA rendono questa soluzione accessibile, perché si addestra un piccolo insieme di pesi aggiuntivi invece dell’intero modello.

Si noti che nessuno di questi casi riguarda i fatti. Si tratta di insegnare a un modello come comportarsi nello svolgere un’attività che già conosciamo bene.

La maggior parte dei problemi di RAG riguarda il recupero

Quando un team mi dice «abbiamo provato RAG, ma non ha funzionato», raramente il problema è il modello. È la fase di recupero. La qualità del modello non può superare quella dei passaggi che gli vengono forniti.

Le soluzioni sono poco appariscenti, ma efficaci:

• Suddividere in base al significato, non al numero di caratteri. Dividere un contratto ogni 500 caratteri spezza a metà le clausole. Suddividerlo per sezioni e titoli mantiene intatto il contesto.
• Aggiungere contesto a ogni segmento. Un segmento che dice «il limite è di 30 giorni» è inutile se non si sa a quale polizza si riferisce. Anthropic ha riferito che aggiungere un breve contesto del documento a ogni segmento prima di indicizzarlo — un approccio che definisce recupero contestualizzato — ha ridotto i recuperi non riusciti del 49% e del 67% se abbinato al riordinamento dei risultati.
• Combinare la ricerca per parole chiave e quella vettoriale. La ricerca vettoriale è efficace nel cogliere il significato, ma meno nel trovare termini esatti, come i codici dei componenti. La ricerca ibrida copre entrambi gli aspetti.
• Verifica separatamente il recupero delle informazioni. Prepara un insieme di domande reali con i passaggi corretti delle fonti già noti e misura se il passaggio giusto compare tra i primi risultati prima di valutare le risposte finali.

Quando usare entrambi

In produzione, i sistemi più efficaci spesso combinano i due approcci. RAG fornisce i fatti. Un modello sottoposto a un leggero affinamento gestisce il formato, il tono e il linguaggio specifico del settore. Anche la ricerca si muove nella stessa direzione: l’approccio RAFT di UC Berkeley affina un modello appositamente per aiutarlo a sfruttare meglio i documenti recuperati e a ignorare quelli irrilevanti.

Ma l’ordine conta. Quasi sempre iniziamo con RAG, misuriamo i suoi punti deboli e solo a quel punto decidiamo se vale la pena ricorrere all’affinamento. Iniziare dall’affinamento significa sostenere i costi dell’addestramento prima di sapere qual è il vero divario da colmare.

Una semplice lista di controllo per decidere

1. L’attività dipende da fatti che cambiano più di una volta a trimestre? Usa RAG.
2. Gli utenti o i revisori devono poter vedere da dove proviene una risposta? Usa RAG.
3. Il problema riguarda il formato, il tono o il vocabolario delle risposte, non i fatti? Valuta l’affinamento.
4. Si tratta di un’attività circoscritta, eseguita su volumi elevati, per cui contano i costi o la velocità? Valuta di affinare un modello più piccolo.
5. Hai misurato la qualità del recupero separatamente? In caso contrario, fallo prima di ogni altra cosa.

In sintesi

RAG e affinamento non sono approcci concorrenti. Il primo fornisce al modello le informazioni giuste, il secondo ne modella il comportamento. Chiarisci qual è il problema che devi davvero risolvere, migliora il recupero prima di incolpare il modello e considera l’affinamento un’ottimizzazione da introdurre quando il sistema funziona, non una scorciatoia per farlo funzionare.