Fine-tuning vs RAG: quale approccio scegliere per applicazioni aziendali specifiche

Il 12 giugno 2025 sono stato contattato dal socio di uno studio legale romano specializzato in diritto del lavoro e contenzioso previdenziale per PMI italiane, con un organico di 14 avvocati fra soci e associati e un portafoglio di circa 380 aziende clienti attive. Lo studio aveva avviato tre mesi prima una collaborazione con un consulente AI esterno per costruire un assistente virtuale basato su LLM capace di rispondere in italiano preciso alle domande degli avvocati su normativa specifica - articoli del codice civile, sentenze di Cassazione rilevanti, circolari INPS, accordi sindacali di categoria, interpretazioni Garante Privacy. Il consulente aveva proposto un approccio basato su fine-tuning di un modello open-weight (LLaMA 3 70B) su un corpus proprietario di 18.000 documenti interni dello studio, con un preventivo di 62.000 euro per il primo training e 8.500 euro al mese ricorrenti per training incrementale trimestrale. Dopo tre mesi di lavoro e 31.000 euro di spesa iniziale, il risultato era deludente: il modello rispondeva con sicurezza a domande su normativa aggiornata al 2023 (il taglio del dataset di training originario) ma produceva risposte errate su normativa 2024 e 2025, inclusi aggiornamenti critici come la riforma del PNRR per ammortizzatori sociali e le ultime sentenze su lavoro agile in post-pandemia. Mantenere il fine-tuning aggiornato richiedeva training ripetuti, tempi morti del servizio, costi crescenti.

Il socio mi ha contattato per una second-opinion tecnica prima di continuare a investire nel percorso fine-tuning. Dopo due giornate di analisi tecnica e un'intervista strutturata con tre avvocati senior dello studio per capire davvero che tipo di domande ponevano all'assistente, la diagnosi è stata chiara: il problema non era il modello LLM, era la scelta architetturale fra fine-tuning e Retrieval-Augmented Generation (RAG). Per questo dominio specifico - normativa italiana soggetta ad aggiornamenti continui, documenti proprietari che cambiano settimanalmente, esigenza di citare esattamente la fonte di ogni risposta per responsabilità professionale - il fine-tuning era la scelta sbagliata in partenza. RAG era l'architettura corretta. In cinque settimane di lavoro abbiamo ricostruito il sistema da zero con un'architettura RAG basata su PostgreSQL 16 con estensione pgvector, OpenAI text-embedding-3-large per la vettorializzazione, GPT-5.4 Sonnet come LLM di orchestrazione, e una pipeline di ingestion automatizzata che aggiorna il corpus ogni notte dai feed normativi pubblici rilevanti. Il costo consulenziale dell'intervento è stato 14.800 euro. Il costo operativo ricorrente del sistema RAG è sceso da 8.500 euro/mese del fine-tuning originale a 420 euro/mese (fra API OpenAI e hosting del PostgreSQL). L'accuratezza misurata su una batteria di 180 query di test costruite dai tre avvocati senior è salita dall'84% del fine-tuning iniziale al 96% del sistema RAG, con il beneficio aggiuntivo che ogni risposta del sistema cita esplicitamente la fonte primaria da cui è stata estratta - requisito imprescindibile in contesto legale.

Questo articolo è il distillato pragmatico del confronto fra fine-tuning e RAG per applicazioni LLM aziendali specifiche in contesti PMI italiane, basato sull'esperienza di circa 14 progetti simili negli ultimi due anni dopo l'emergere del mercato degli LLM commerciali maturi. Il principio guida che applico ogni volta che un cliente PMI mi chiede di costruire un assistente AI verticale sul suo dominio è uno: il 90% dei casi d'uso PMI italiane beneficia di RAG, non di fine-tuning. Il fine-tuning ha casi d'uso legittimi ma molto specifici; RAG è la scelta architetturale di default per la stragrande maggioranza dei problemi reali.

Perché il fine-tuning è quasi sempre la scelta sbagliata per un assistente aziendale PMI?

Il fine-tuning è il processo di continuare l'addestramento di un LLM pre-addestrato su un dataset proprietario specifico, modificando i pesi del modello per specializzarlo su un dominio particolare. La documentazione ufficiale di OpenAI sul fine-tuning dei loro modelli copre in dettaglio il processo tecnico, i requisiti di dataset e i casi d'uso suggeriti. Il fine-tuning produce un modello che ha interiorizzato i pattern del tuo dominio - risponde con lo stile, il vocabolario e le convenzioni del tuo settore come se avesse letto quel corpus durante il suo addestramento originario. È un'operazione potente, ma ha tre limiti strutturali che la rendono inadatta alla maggioranza dei casi PMI.

Primo limite: la conoscenza del modello fine-tunato è congelata al momento del training. Se il tuo dominio cambia - nuova normativa, nuovi prodotti, nuove procedure interne - devi rifare il training per aggiornare il modello. Per i domini dinamici (legale, fiscale, sanitario, finanziario), questo costo ricorrente rende il fine-tuning economicamente insostenibile. Secondo limite: il fine-tuning non elimina le allucinazioni, anzi le rende più subdole. Un modello fine-tunato risponde con maggiore sicurezza perché ha visto pattern simili durante il training, ma quando incontra una domanda fuori dal corpus di training può inventare risposte che sembrano autorevoli ma non lo sono, e senza meccanismo esplicito di citazione della fonte l'utente non ha modo di verificarle. Terzo limite: il costo iniziale e ricorrente è significativo. Un fine-tuning serio su modelli open-weight richiede GPU dedicate (mediamente 8 A100 per 24-48 ore per un 70B parameter model), pipeline MLOps dedicate, team con competenze specifiche che le PMI italiane non hanno internamente.

Retrieval-Augmented Generation (RAG) risolve tutti e tre i limiti con un'architettura fondamentalmente diversa. Il modello LLM non viene modificato: resta il modello commerciale base (GPT-5.4, Claude Opus 4.7, Gemini 2.5 Pro). La conoscenza proprietaria vive in un database vettoriale esterno. Quando arriva una domanda, il sistema prima recupera (retrieve) i chunk di documenti più rilevanti dal database vettoriale usando ricerca semantica, poi aumenta (augment) il prompt con questi chunk come contesto, infine genera (generate) la risposta via l'LLM con accesso a quel contesto. Il pattern è descritto nel paper fondativo del 2020 di Lewis et al. e nella letteratura successiva come la soluzione canonica per applicazioni enterprise specifiche su dominio proprietario. Il beneficio è che aggiungere o modificare un documento nel corpus è un'operazione istantanea - vettorizzi il nuovo documento, lo inserisci nel database, il sistema lo usa alla richiesta successiva senza retraining.

Per casi PMI, i benefici concreti di RAG rispetto a fine-tuning sono cinque. Primo, freschezza del dato: aggiornamenti istantanei del corpus senza retraining. Secondo, citazione della fonte: ogni risposta può includere esplicitamente i documenti da cui è stata estratta, fondamentale in contesti professionali legali, medici, finanziari. Terzo, costo inferiore: per volumi PMI tipici, RAG con modelli commerciali costa 10-50x meno del mantenimento di un modello fine-tunato. Quarto, auditability: il comportamento del sistema è deterministico e debuggable - se una risposta è sbagliata, puoi ispezionare quali chunk sono stati recuperati e capire dove il sistema ha sbagliato. Quinto, flessibilità di modello: RAG è agnostico rispetto all'LLM sottostante, quindi puoi passare da GPT-5.4 a Claude Opus 4.7 in base al costo o alla qualità senza toccare il corpus.

Se stai valutando un progetto di AI verticale sul tuo dominio aziendale e qualcuno ti sta proponendo un fine-tuning come soluzione, prima di firmare un preventivo significativo vale la pena fare una valutazione tecnica indipendente. Nel mio profilo professionale trovi il dettaglio dei progetti AI e RAG che ho implementato in contesti PMI italiane, sempre con approccio di valutazione onesta dei trade-off fra le alternative architetturali disponibili.

Quando il fine-tuning è invece la scelta giusta: i tre casi d'uso legittimi

Per onestà intellettuale è importante riconoscere che il fine-tuning ha casi d'uso legittimi in cui è oggettivamente superiore a RAG. Sono tre e li identifico con precisione. Primo caso: adattamento di stile e tono di voce. Se vuoi che il modello risponda nel preciso registro linguistico del tuo brand - formale ma informale, con terminologia aziendale specifica, evitando certi termini - il fine-tuning su esempi di comunicazioni corrette è superiore a RAG, perché lo stile è una proprietà implicita del linguaggio che il modello interiorizza meglio tramite training che tramite contesto RAG. Secondo caso: domini altamente strutturati con ontologia fissa. Se il tuo dominio ha un vocabolario molto specializzato che il modello base conosce male (tassonomie mediche ICD-10 dettagliate, codici tecnici manifatturieri, nomenclature chimiche IUPAC), fine-tuning sul corpus del dominio produce una performance migliore di RAG, perché il modello impara a usare il vocabolario nativo invece di riferirsi a esso via contesto. Terzo caso: compiti di classificazione o estrazione strutturata ripetitivi. Se il tuo assistente deve fare sempre la stessa operazione (classificare ticket in 8 categorie, estrarre 12 campi specifici da un tipo di documento), fine-tuning su esempi input-output è più efficiente e più preciso di RAG con few-shot prompting.

Per il cliente legale romano, nessuno dei tre casi d'uso si applicava. Il dominio era troppo dinamico per freezare la conoscenza (primo problema), la terminologia giuridica italiana era già ben conosciuta dal modello base Anthropic Claude (non serviva adattamento di ontologia), e il compito era domande-risposte aperte non classificazione strutturata. RAG era la scelta giusta per tutti e tre i criteri.

Architettura RAG di produzione: PostgreSQL pgvector, embedding, chunking strategy, retrieval ibrido

L'architettura RAG che ho costruito per il cliente legale romano - replicabile in modo praticamente identico in altri contesti PMI - si basa su quattro componenti integrati. Primo, un database vettoriale - ho scelto PostgreSQL 16 con estensione pgvector perché il cliente aveva già PostgreSQL in infrastruttura e non voleva introdurre un database aggiuntivo (Pinecone, Weaviate, Qdrant sarebbero alternative valide ma overkill per volumi PMI). Secondo, un modello di embedding per trasformare testo in vettori numerici - ho scelto OpenAI text-embedding-3-large (3072 dimensioni, multilingue incluso italiano) per qualità delle embedding italiane superiore rispetto alle alternative open-weight che ho benchmarkato. Terzo, un LLM di orchestrazione che produce la risposta finale - Claude Opus 4.7 di Anthropic nel caso legale, scelto per l'accuratezza del ragionamento giuridico italiano superiore misurata in benchmarking interno. Quarto, una pipeline di ingestion che processa i documenti in entrata, li splitta in chunk, genera embedding, popola il database.

La chunking strategy - come dividere un documento lungo in pezzi piccoli indicizzabili - è la scelta progettuale più critica di un sistema RAG, ed è quella che la letteratura generalista trascura più spesso. Un chunk troppo piccolo perde contesto semantico (una frase isolata da un articolo normativo perde il riferimento al comma e all'articolo). Un chunk troppo grande diluisce il segnale di rilevanza (troppa informazione non pertinente accanto a quella che serve). La soluzione che applico è il semantic chunking con overlap: divido i documenti per unità semantiche naturali (articoli normativi per documenti di legge, paragrafi per sentenze, sezioni per accordi sindacali) con dimensione target di 500-800 token per chunk e overlap di 100 token fra chunk adiacenti. Per il corpus legale del cliente, ho implementato un chunker custom che riconosce la struttura degli articoli ("Art. 2087 c.c.", "L. 300/1970 art. 18") e li preserva come unità di chunking, con metadata esplicito che marca il codice, l'articolo, il comma e la data di vigenza - informazione cruciale per citazioni precise.

Il retrieval ibrido è il secondo pattern avanzato che fa la differenza fra un RAG mediocre e uno eccellente. Il retrieval semantico puro (via vector similarity) funziona bene quando la query e il documento usano vocabolario simile ma concetti diversi, ma fallisce quando la query contiene termini tecnici esatti che devono matchare letteralmente (codice fiscale, numero sentenza, riferimento normativo). La soluzione è combinare vector search (rilevanza semantica) con keyword search tradizionale (BM25 su PostgreSQL tramite tsvector), aggregare i punteggi con formula pesata, e restituire i top-K combinati. Per il caso legale, la formula che ha funzionato meglio nel benchmarking era 0.6 × vector score + 0.4 × bm25 score, con K=8 chunk recuperati per query prima della fase di augment. Questo pattern di retrieval ibrido è complementare ai pattern di ricerca che ho descritto nel mio articolo su Elasticsearch in produzione per Laravel per ricerca full-text su cataloghi grandi, dove i principi di ranking ibrido si applicano con tecniche analoghe.

Pipeline di ingestion e freschezza del corpus: il segreto del RAG in produzione

Il vero vantaggio di RAG su fine-tuning emerge nella pipeline di ingestion - il meccanismo automatizzato con cui il corpus del sistema resta allineato alle fonti reali. Senza una pipeline di ingestion solida, qualunque sistema RAG degrada nel tempo verso l'obsolescenza. Con una pipeline ben progettata, il sistema diventa auto-aggiornante e la qualità si mantiene nel tempo con intervento operativo minimo.

Per il cliente legale romano, la pipeline di ingestion ha tre percorsi di alimentazione. Primo percorso, feed pubblici automatici: ogni notte un job schedulato scarica gli aggiornamenti da fonti ufficiali pubbliche rilevanti (Gazzetta Ufficiale via feed RSS, portale Normattiva, Cassazione civile sezione lavoro, Garante Privacy per provvedimenti), processa i documenti nuovi, li chunka, genera embedding, inserisce in PostgreSQL. Il job termina mediamente in 15-20 minuti per una media di 8-12 documenti nuovi al giorno. Secondo percorso, upload manuale dallo studio: gli avvocati senior possono caricare via interfaccia web documenti proprietari dello studio - pareri legali redatti, memorie processuali, appunti di formazione interna - che entrano nel corpus con un tag proprietario che permette filtering a livello di ricerca. Terzo percorso, aggiornamento incrementale trimestrale: un sub-consulente legale esterno rivede manualmente il corpus ogni tre mesi, segnala documenti da deprecare per obsolescenza, aggiorna metadata di vigenza. Questo terzo percorso è importante in un dominio legale per evitare che il sistema citi normativa abrogata come se fosse ancora in vigore.

La freschezza del corpus è misurata come age medio dei documenti rilevanti recuperati per query. Sul cliente legale, prima dell'intervento con sistema fine-tuning, l'age medio era di 18 mesi (al training originario del 2024). Dopo il sistema RAG con ingestion automatica, l'age medio è sceso a circa 45 giorni sul percorso automatico e a 0 giorni su documenti proprietari dello studio - un miglioramento radicale della pertinenza delle risposte alle esigenze reali degli avvocati. La pipeline di ingestion è stata costruita con lo stesso approccio di event-driven architecture in PHP con disaccoppiamento degli handler che ho descritto in un articolo dedicato, con eventi di dominio DocumentIngested, DocumentUpdated, DocumentDeprecated che orchestrano indipendentemente le diverse fasi della pipeline (scarico, parsing, chunking, embedding, indicizzazione, notifica agli utenti) senza accoppiamento sincrono.

Valutazione e monitoraggio di produzione: come sapere se il tuo RAG sta davvero funzionando

Un aspetto critico ma sottovalutato dei progetti RAG in produzione è la valutazione continua della qualità del sistema. Senza una batteria di test oggettivi, non sai se il sistema sta degradando nel tempo (per drift del corpus, regressioni dell'LLM, cambi di comportamento dell'embedding model) - ti accorgi solo quando un utente si lamenta. La metodologia che applico è un gold-standard evaluation set costruito collaborativamente con i domain expert del cliente.

Per il cliente legale romano, i tre avvocati senior hanno costruito insieme a me, nell'arco di quattro mezze giornate di lavoro, una batteria di 180 query rappresentative del loro uso reale dell'assistente, ciascuna con una risposta di riferimento considerata corretta e precisa. Le query sono distribuite su sette categorie (giurisprudenza Cassazione, normativa primaria, normativa regolamentare, circolari INPS/INAIL, accordi sindacali, dottrina, casi d'uso proprietari dello studio). Ogni query ha metadata di difficoltà (facile/media/difficile) che permette analisi stratificata. Il sistema di valutazione automatica è un secondo LLM (lo stesso Claude Opus 4.7) configurato come judge che compara la risposta del sistema con la risposta di riferimento e produce uno score 0-10 su quattro dimensioni (accuratezza fattuale, completezza, precisione della citazione, pertinenza al quesito). Il benchmark gira settimanalmente e i risultati vanno in una dashboard Grafana interna.

Il risultato finale dell'intervento sul cliente legale romano, al termine delle cinque settimane di implementazione più sei mesi di operatività misurata, è stato il seguente. Accuratezza media sulla batteria dei 180 test del sistema RAG: 96%, contro l'84% del precedente sistema fine-tuning. Latency media p50 per una risposta RAG completa: 2,8 secondi (acceptable per un contesto legale dove l'utente si aspetta pensiero), p95 sotto i 6 secondi. Costo operativo mensile: 420 euro/mese fra API OpenAI per embedding, API Anthropic per generazione, hosting PostgreSQL. Contro: 8.500 euro/mese del fine-tuning precedente (95% risparmio). Freschezza del corpus: age medio dei documenti recuperati sceso da 18 mesi a 45 giorni. Adozione interna: 11 dei 14 avvocati usano il sistema quotidianamente, con media di 28 query al giorno per avvocato. Tempo risparmiato stimato dallo studio in ricerca normativa manuale: circa 400 ore nei primi sei mesi di operatività, valorizzate a tariffa oraria dello studio in circa 60.000 euro. ROI sulla prima annualità di operatività: oltre 4x, in uno studio legale di dimensione medio-piccola che prima dell'intervento considerava l'AI "non applicabile al nostro contesto specialistico".

Se guidi una PMI italiana in un settore con forte componente di conoscenza proprietaria e stai valutando l'introduzione di un assistente AI verticale sul tuo dominio, il confronto onesto fra fine-tuning e RAG va fatto sui tuoi specifici criteri di dominio - non sulle mode o sulle proposte di fornitori che tendono a privilegiare le soluzioni più complesse perché hanno marginalità superiore. Nel 90% dei casi PMI, RAG è la scelta architetturalmente e economicamente superiore, e il vero valore dell'intervento è nella qualità della pipeline di ingestion e della valutazione continua, più che nella scelta del modello LLM di turno. Se vuoi confrontarti su una valutazione tecnica del tuo caso specifico, contattami per una consulenza iniziale: in una sessione di analisi guidata produciamo insieme una mappatura del tuo corpus di conoscenza proprietaria, una stima realistica dei costi operativi fra le alternative architetturali, e una decisione informata su se procedere con RAG o con uno degli specifici casi d'uso in cui il fine-tuning è invece giustificato.