RAG, fine-tuning o prompt engineering: quale approccio scegliere

Molti progetti chiedono al modello di sapere informazioni interne, rispettare un formato e ragionare su una richiesta. Questi bisogni vengono spesso confusi. Il prompt definisce compito e contesto immediato. Il retrieval recupera documenti o passaggi pertinenti al momento della domanda. Il fine-tuning modifica il comportamento appreso dal modello attraverso esempi. Capire quale componente è debole evita soluzioni costose che non agiscono sulla causa.

Se il sistema usa la policy sbagliata perché non ha accesso alla versione corrente, il fine-tuning non è la risposta: quella conoscenza cambierà ancora. Se recupera il documento giusto ma produce sempre un formato incoerente, esempi migliori o fine-tuning possono aiutare. Se il problema è un requisito non definito, nessuna tecnica compensa l’assenza di una valutazione chiara.

Le istruzioni dovrebbero esplicitare obiettivo, input, vincoli, criteri e gestione dell’incertezza. Alcuni esempi mostrano forma e livello di dettaglio. Il contesto include dati della richiesta, profilo dell’utente e output di strumenti. Questa base è veloce da modificare e rende visibili le decisioni progettuali. È il punto da cui partire anche se in seguito si aggiungono retrieval o fine-tuning.

Prompt molto lunghi possono però diventare fragili, costosi e difficili da mantenere. Inserire interi manuali in ogni richiesta non garantisce che il modello selezioni il passaggio corretto. Occorre separare istruzioni stabili, dati dinamici e conoscenza. Versionare i prompt e testarli su un set fisso permette di capire se una modifica migliora davvero il sistema.

Il retrieval-augmented generation cerca contenuti rilevanti in una base documentale e li fornisce al modello. È adatto a cataloghi, procedure, manuali, knowledge base e informazioni che cambiano. Può migliorare tracciabilità mostrando le fonti recuperate, ma una citazione non garantisce che la risposta le interpreti correttamente. Qualità dei documenti, segmentazione, metadata e strategia di ricerca sono determinanti.

Il test deve separare retrieval e generazione. Prima si verifica se il passaggio necessario appare tra i risultati; poi se il modello risponde fedelmente. Se il documento corretto non viene trovato, cambiare il prompt finale serve poco. Filtri per prodotto, data, lingua o permesso evitano di mescolare versioni e contenuti non autorizzati. Anche l’assenza di una risposta deve essere un esito previsto.

Il fine-tuning può essere utile per classificazioni, trasformazioni e formati ripetuti, oppure per rendere più stabile un comportamento difficile da ottenere con esempi nel prompt. Richiede un dataset rappresentativo, coerente e controllato. Se gli esempi contengono errori, eccezioni non spiegate o stili contrastanti, il modello li apprende. La preparazione e valutazione dei dati sono spesso il costo principale.

Non è il modo ideale per memorizzare un archivio che cambia o informazioni che devono essere rimosse rapidamente. Inoltre non elimina la necessità di istruzioni, controlli e test. Prima di addestrare conviene costruire una baseline con il modello standard e definire il miglioramento necessario. Solo così si può decidere se il guadagno giustifica costi e manutenzione.

Un sistema maturo può usare prompt per ruolo e regole, RAG per conoscenza aggiornata e fine-tuning per un formato stabile. A questi si aggiungono strumenti per eseguire azioni e guardrail per limitarle. La combinazione non deve essere adottata tutta insieme. Ogni componente aumenta superfici di errore, latenza e osservabilità necessaria.

Il percorso incrementale parte dalla soluzione più semplice che supera i test. Si aggiunge retrieval se mancano conoscenze, si migliora la ricerca se le fonti sono errate e si valuta il fine-tuning quando il comportamento resta instabile nonostante istruzioni ed esempi. Questa sequenza rende più facile attribuire i miglioramenti e tornare indietro.

Il confronto include qualità, latenza, costo per richiesta, costo di aggiornamento, sicurezza e tempo del team. Il RAG richiede ingestione, permessi e aggiornamento dell’indice. Il fine-tuning richiede dataset, training, versioni e rivalutazione. Prompt estesi aumentano token e possono esporre informazioni non necessarie. Ogni approccio deve rispettare minimizzazione e controllo degli accessi.

Un set di valutazione contiene casi frequenti, casi limite, input avversi e richieste a cui il sistema deve rifiutare di rispondere. Si misurano correttezza, fedeltà alle fonti, formato, costo e tempo. La decisione finale non è RAG contro fine-tuning in assoluto, ma quale architettura soddisfa soglie concrete con il minor carico operativo sostenibile.