RAG o fine-tuning: cosa consiglio davvero ai clienti

Quando un’azienda mi contatta per “insegnare all’AI i nostri dati” o “creare un modello che conosce la nostra azienda”, nella maggior parte dei casi quello che sta davvero descrivendo non è un problema di fine-tuning. È un problema di recupero delle informazioni — e la soluzione giusta, nella grandissima maggioranza dei casi che ho visto, è RAG (retrieval-augmented generation), non un modello riaddestrato da zero sui propri dati.

La confusione è comprensibile: “addestrare l’AI sui nostri documenti” suona più impressionante di “colleghiamo un motore di ricerca semantico a un modello esistente”. Ma tecnicamente ed economicamente sono due mondi molto diversi, e scegliere quello sbagliato costa tempo, budget, e spesso produce un sistema peggiore di quello che si voleva sostituire.

Come funzionano, in breve

RAG mantiene il modello linguistico invariato. Quando arriva una domanda, il sistema cerca prima i documenti più rilevanti in una base di conoscenza (contratti, manuali, ticket passati, cataloghi prodotto), li passa al modello insieme alla domanda, e il modello genera la risposta basandosi su quel contesto specifico. È come dare a un consulente molto preparato l’accesso al tuo archivio prima di ogni riunione, invece di provare a fargli memorizzare l’intero archivio a mente.

Il fine-tuning modifica i pesi interni del modello stesso, addestrandolo ulteriormente su un set di esempi specifici. È utile per cambiare come il modello si comporta — il tono, il formato delle risposte, un compito molto specifico e ripetitivo — non per dargli accesso a informazioni che cambiano nel tempo.

Perché RAG vince nella maggior parte dei casi aziendali

I dati aziendali cambiano continuamente: nuovi prodotti, nuovi prezzi, nuove policy. Con RAG, aggiornare la base di conoscenza significa aggiungere o modificare un documento — il sistema risponde correttamente al minuto successivo. Con un modello fine-tuned, ogni aggiornamento sostanziale richiederebbe un nuovo ciclo di addestramento: più lento, più costoso, e con il rischio concreto che il modello “dimentichi” altre cose nel processo.

C’è poi un tema di verificabilità che considero decisivo quando lavoro con clienti in settori regolamentati: con RAG posso mostrare esattamente quali documenti hanno prodotto una certa risposta — è tracciabile, auditabile, correggibile alla fonte. Con un modello fine-tuned, la conoscenza è “dissolta” nei pesi del modello: non c’è modo semplice di dire perché ha risposto in un certo modo, né di correggere un singolo fatto sbagliato senza riaddestrare.

Quando il fine-tuning ha davvero senso

Non è mai un “mai”: ci sono casi in cui il fine-tuning è la scelta giusta, tipicamente quando serve cambiare in modo stabile lo stile o il formato delle risposte su un compito molto ripetitivo e ben definito (classificare ticket in categorie fisse, generare descrizioni prodotto in un tono specifico), oppure quando serve un modello molto più piccolo e veloce specializzato su un singolo compito, per ragioni di costo o latenza.

Nella pratica, il progetto tipico che costruisco per un cliente combina i due elementi in modo mirato: RAG per la conoscenza che cambia (il grosso del sistema), e un intervento di fine-tuning solo se emerge un’esigenza specifica e stabile che lo giustifica economicamente. Partire dal fine-tuning per default, come spesso viene proposto, è quasi sempre la scelta più costosa per il problema sbagliato — la stessa logica che seguo in ogni progetto di automazioni e agenti AI che costruisco.