Studi RAG

Introduzione

I sistemi RAG (Retrieval-Augmented Generation) sono diventati l'architettura di riferimento per le applicazioni di IA documentale in ambito professionale. Combinando un motore di ricerca semantica con un modello linguistico generativo, il RAG permette di rispondere a domande complesse basandosi su una base di conoscenza esterna, senza necessitare di costosi fine-tuning e garantendo che le risposte siano fondate su fonti documentali verificabili. Questo approccio risolve due problemi fondamentali dei LLM: le allucinazioni e l'assenza di conoscenza specifica sul dominio aziendale. Il RAG ancora la generazione ai fatti — quelli contenuti nei documenti dell'organizzazione — e permette di mantenere la conoscenza aggiornata senza dover riaddestrare il modello, tramite il semplice aggiornamento della base documentale.

Sfide Tecniche

La qualità di un sistema RAG si basa su una catena di decisioni architetturali interconnesse. Ogni anello della pipeline — dalla suddivisione dei documenti alla generazione della risposta finale — influenza direttamente la pertinenza e l'affidabilità dei risultati. Un chunking troppo grossolano annega l'informazione pertinente in un oceano di contesto, diluendo la capacità del LLM di estrarre la risposta esatta. Un chunking troppo fine frammenta il ragionamento e priva il modello della visione d'insieme necessaria per una risposta coerente. Un modello di embedding inadatto alla lingua o al dominio del corpus produce similarità vettoriali che non riflettono la prossimità semantica reale. Una strategia di retrieval mal calibrata restituisce documenti fuori tema o omette i passaggi essenziali. La generazione, infine, dipende dalla qualità del contesto fornito: un LLM performante con un contesto scarso produce una risposta mediocre, mentre un LLM modesto con un contesto eccellente può fornire risposte notevoli.

Questo progetto di ricerca propone un'esplorazione sistematica e metodica di tutti i parametri di una pipeline RAG, con l'obiettivo di produrre raccomandazioni concrete, cifrate e riproducibili per la progettazione di sistemi RAG industriali. Non ci limitiamo a compilare conoscenze teoriche: ogni configurazione viene testata, misurata e confrontata su corpora aziendali reali, con metriche oggettivabili. Gli esperimenti coprono corpora vari — documenti tecnici, testi giuridici, manuali prodotto, corrispondenza commerciale, rapporti di attività — per garantire la generalizzabilità dei risultati. I deliverable del progetto includono una guida architetturale, matrici di performance per configurazione e un banco di test riutilizzabile per valutare qualsiasi nuovo componente.

Strategia di Chunking

La strategia di chunking — la suddivisione dei documenti in segmenti elaborabili dal sistema — è il primo e forse il più determinante dei parametri di una pipeline RAG. Una suddivisione errata compromette irrimediabilmente la qualità del retrieval, indipendentemente dalla qualità del modello di embedding o dalla potenza del LLM. Studiamo tre grandi famiglie di strategie. Il chunking fisso è il metodo più semplice: i documenti vengono suddivisi a intervalli regolari, generalmente tra 256 e 1024 token, con o senza sovrapposizione (overlap) tra chunk adiacenti per evitare di tagliare un'informazione a metà. La sua semplicità è il suo principale vantaggio: è rapido, deterministico e facile da implementare. I suoi limiti emergono su documenti con struttura forte: un taglio mal posizionato può separare un titolo dal suo contenuto, una tabella dalla sua legenda o una domanda dalla sua risposta. La sovrapposizione attenua parzialmente questo problema ma aumenta il volume della base vettoriale e può introdurre ridondanza.

Il chunking semantico migliora la suddivisione fissa utilizzando la segmentazione naturale del documento. Invece di tagliare a una dimensione arbitraria, rileva i confini semantici: fine dei paragrafi, cambi di sezione, transizioni tematiche. Il rilevamento di questi confini può basarsi su diversi approcci: l'analisi della similarità tra frasi consecutive (un calo improvviso di similarità indica un cambio di argomento), la struttura del documento (titoli, sottotitoli, numerazione, elenchi) o un modello di segmentazione addestrato specificamente. Il risultato è un insieme di chunk che rispettano l'unità tematica dei documenti, migliorando significativamente la pertinenza del retrieval: ogni chunk contiene un argomento coerente, facilitando la corrispondenza con la query e la comprensione da parte del LLM.

Il chunking gerarchico è l'approccio più sofisticato. Costruisce una rappresentazione multilivello dei documenti: un indice al livello più alto, sezioni e sottosezioni al livello intermedio e il contenuto dettagliato al livello più fine. Il retrieval avviene prima al livello grossolano per identificare le sezioni pertinenti, poi al livello fine per estrarre i passaggi precisi. Questa strategia è particolarmente adatta a documenti lunghi e strutturati: manuali tecnici, rapporti di ricerca, documenti giuridici. La gerarchia permette di rispondere sia a domande generali (qual è la struttura di questo documento?) sia a domande precise (qual è la soglia di tolleranza menzionata a pagina 47?). I risultati delle nostre campagne mostrano che il chunking gerarchico supera gli approcci piatti del 15-25% sulle metriche di precisione del retrieval per documenti di oltre 50 pagine.

I modelli di embedding costituiscono il cuore della ricerca semantica in un sistema RAG. Il loro ruolo è trasformare il testo — chunk di documenti e query — in vettori numerici in uno spazio ad alta dimensione, dove la prossimità geometrica riflette la prossimità semantica. La scelta del modello di embedding ha un impatto diretto sulla qualità del retrieval: un buon modello produce rappresentazioni in cui i documenti pertinenti sono naturalmente vicini alla query, mentre un cattivo modello confonde i concetti e produce risultati fuori tema. Valutiamo sistematicamente i modelli di embedding più utilizzati dell'ecosistema: i text-embedding di OpenAI (ada-002, text-embedding-3-small, text-embedding-3-large), i modelli BGE (BAAI), E5 (Microsoft), i Sentence Transformers (all-MiniLM-L6-v2, multilingual-e5-large), i modelli Cohere e i modelli di embedding di Mistral e Jina AI.

I criteri di valutazione dei modelli di embedding coprono diverse dimensioni. La performance di retrieval misura la capacità del modello di classificare i documenti pertinenti in testa ai risultati: utilizziamo le metriche standard recall@k, precision@k e MRR (Mean Reciprocal Rank) su set di query annotate per ogni corpus aziendale. La robustezza multilingue valuta la qualità della rappresentazione vettoriale in diverse lingue: un modello eccellente in inglese può degradare del 30-50% su francese giuridico o tedesco tecnico. La resistenza al dominio misura la capacità del modello di catturare la semantica specializzata: un corpus di documenti di ingegneria utilizza un vocabolario e concetti che differiscono sensibilmente dal linguaggio generale su cui i modelli sono maggiormente addestrati. La dimensione dei vettori impatta la performance, l'archiviazione e la velocità di ricerca: vettori da 384 dimensioni sono più rapidi da cercare ma possono essere meno espressivi di vettori da 1536 o 3072 dimensioni.

I risultati delle nostre campagne di valutazione rivelano differenze significative tra i modelli. Su corpus tecnico in francese, i modelli multilingue (multilingual-e5-large, BGE-m3) ottengono un recall@5 dal 15 al 25% superiore ai modelli inglesi monolingue. I modelli OpenAI text-embedding-3-large dominano sulla qualità grezza ma il loro costo di inferenza — proporzionale al numero di token — può essere proibitivo per basi di diversi milioni di documenti. I modelli open source come BGE ed E5 offrono il miglior rapporto qualità-costo: liberi da utilizzare, eseguibili localmente tramite Ollama o Sentence Transformers e con performance vicine ai modelli proprietari sulla maggior parte dei corpora. La scelta del modello dipende dal compromesso tra qualità, costo, latenza e sovranità dei dati: un modello locale garantisce che nessun dato documentale lasci l'infrastruttura, un criterio determinante per dati sensibili o soggetti a vincoli normativi.

La strategia di retrieval — come selezionare e ordinare i chunk pertinenti per rispondere a una query — è il secondo parametro critico della pipeline RAG. Esploriamo diversi approcci combinabili. La ricerca vettoriale pura (top-k) è il metodo base: la query viene vettorizzata, viene effettuata una ricerca di similarità coseno o distanza L2 nella base vettoriale e vengono restituiti i k chunk più vicini. Il valore di k è un parametro sensibile: un k troppo basso (1-3) può omettere passaggi complementari essenziali, mentre un k troppo alto (20-50) annega il LLM in un contesto voluminoso e diluisce l'informazione pertinente. I nostri esperimenti mostrano che un k tra 5 e 15 offre il miglior equilibrio per la maggior parte dei casi d'uso, con un'ottimizzazione fine in base alla lunghezza dei chunk e alla complessità delle query.

La fusione di risultati (fusion retrieval) combina più strategie di ricerca per migliorare la copertura e la robustezza. Il principio è eseguire più query in parallelo — con formulazioni diverse, modelli di embedding diversi o modalità di ricerca diverse — e poi fondere i risultati in un unico elenco classificato. La fusione può avvenire per interpolazione ponderata dei punteggi, per rango (rank fusion, metodo RRF — Reciprocal Rank Fusion) che dà più peso ai documenti classificati primi in ogni elenco, o per voto maggioritario. Il metodo RRF è particolarmente efficace: è semplice, deterministico e non richiede calibrazione dei pesi. I nostri test mostrano che la fusione di due o tre strategie di retrieval migliora il richiamo del 10-20% rispetto a una strategia singola, con una riduzione significativa della varianza dei risultati.

Il re-ranking costituisce una fase complementare al retrieval iniziale. Dopo aver recuperato un insieme ampio di chunk candidati (k = 20-50), un modello di re-ranking — più performante ma più lento del modello di embedding — rivaluta la pertinenza di ogni chunk rispetto alla query. I modelli di re-ranking come Cohere Rerank, BGE-Reranker o Cross-Encoder sono specializzati in questo compito: invece di confrontare vettori, prendono in input la coppia (query, chunk) e producono un punteggio di pertinenza più preciso. Questo approccio in due fasi combina la rapidità della ricerca vettoriale (fase 1) con la precisione del re-ranking (fase 2). Il guadagno è sostanziale: recall@5 migliorato del 15-30% secondo i corpora, con un sovraccosto in latenza accettabile (poche centinaia di millisecondi per query per re-ranking su GPU).

L'hybrid search — che combina ricerca vettoriale e ricerca lessicale BM25 — è una tecnica potente per ovviare ai limiti rispettivi dei due approcci. La ricerca vettoriale eccelle nel catturare la similarità semantica: trova documenti che parlano dello stesso argomento anche con parole diverse. La ricerca BM25 eccelle nella corrispondenza lessicale esatta: trova documenti contenenti i termini precisi della query, essenziale per identificatori, riferimenti, codici, nomi propri e termini tecnici rari. La combinazione delle due modalità permette di coprire tutti i casi: una query su «recesso anticipato clausola 12» troverà sia i documenti che usano altre formulazioni (recesso, risoluzione) tramite il vettoriale, sia i documenti che menzionano esattamente «clausola 12» tramite BM25.

L'implementazione dell'hybrid search dipende dalla base vettoriale utilizzata. Qdrant supporta nativamente la combinazione di ricerca vettoriale e filtri, ma BM25 deve essere implementato tramite un indice invertito separato o tramite una funzione di scoring personalizzata. Nel nostro banco di test, utilizziamo un'architettura a doppio indice: un indice vettoriale Qdrant per la ricerca semantica e un indice BM25 basato su Tantivy o Elasticsearch per la ricerca lessicale. I risultati dei due indici vengono fusi tramite RRF con pesi configurabili. La calibrazione del peso tra le due modalità è un parametro dipendente dal corpus: un peso vettoriale elevato (0.7-0.8) è preferibile per documenti narrativi o descrittivi, mentre un peso lessicale più alto (0.5-0.7) è ottimale per documenti ricchi di termini tecnici, codici e riferimenti. I nostri test mostrano che l'hybrid search migliora il recall@10 del 12-18% rispetto alla ricerca vettoriale pura, con un guadagno particolarmente marcato sulle query contenenti entità nominate specifiche.

La valutazione sistematica della qualità di una pipeline RAG è una sfida in sé, oggetto di un sottoprogetto dedicato. A differenza di un compito di classificazione dove la precisione si misura direttamente, la qualità di un sistema RAG è multidimensionale e parzialmente soggettiva. Abbiamo sviluppato un framework di valutazione completo che copre cinque assi: la fedeltà misura se la risposta del LLM è fedelmente fondata sui documenti recuperati — una risposta può essere corretta in sé ma non fondata sulle fonti fornite, il che è un fallimento del RAG; la pertinenza valuta se i chunk recuperati sono effettivamente pertinenti per la query; la completezza verifica che la risposta copra tutti gli aspetti della domanda; l'assenza di allucinazioni garantisce che la risposta non introduca informazioni non presenti nelle fonti; e la qualità redazionale valuta la chiarezza, la concisione e la struttura della risposta.

Il framework utilizza una combinazione di metriche automatiche e valutazione tramite LLM (LLM-as-a-judge). Le metriche automatiche includono la similarità coseno tra la risposta e le fonti (per la fedeltà), il recall delle entità nominate (per la completezza) e il tasso di citazione corretta (per la tracciabilità). La valutazione tramite LLM utilizza un modello giudice — generalmente GPT-4o o Claude — che riceve la query, i chunk recuperati, la risposta generata e valuta ogni asse secondo una griglia standardizzata con giustificazione testuale. Questo approccio correla bene con la valutazione umana (coefficiente di correlazione di Spearman > 0.85 nei nostri test) pur essendo automatizzabile e riproducibile. Ogni campagna di valutazione produce un rapporto dettagliato con i punteggi per asse, gli esempi di successo e insuccesso e le raccomandazioni di miglioramento.

Casi d'Uso

I casi d'uso concreti coprono due domini principali che struttureranno le nostre raccomandazioni. Il trattamento di documenti tecnici — manuali d'uso, specifiche, documentazione API, rapporti di test, procedure operative — è un terreno di applicazione naturale del RAG. Questi documenti sono generalmente ben strutturati, con titoli, sezioni, numerazioni e indici, il che li rende particolarmente adatti al chunking gerarchico. Le query tecniche sono spesso precise e fattuali: qual è la coppia di serraggio raccomandata per questa vite? Quale versione di Python è richiesta per questo modulo? La precisione del retrieval è critica perché un'informazione errata — una specifica sbagliata, un parametro mal interpretato — può avere conseguenze materiali o finanziarie. Le nostre raccomandazioni per questo dominio privilegiano il chunking gerarchico con overlap ridotto (50 token), un modello di embedding multilingue di tipo BGE, un top-k da 8 a 12 e l'hybrid search con un peso lessicale di 0.4 per i termini tecnici.

Il trattamento di documenti giuridici — contratti, clausole, condizioni generali, appendici, decisioni giudiziarie — presenta requisiti specifici. Il vocabolario giuridico è preciso e normato: un termine ha un significato legale esatto che non tollera approssimazioni semantiche. I documenti giuridici sono ricchi di rinvii, definizioni incrociate e riferimenti ad altri articoli o contratti, il che richiede una capacità di navigazione tra i chunk — un punto in cui il chunking gerarchico con un grafo di relazioni tra chunk si rivela particolarmente utile. Le query giuridiche sono spesso condizionali: cosa succede se il cliente recede prima della data anniversaria? L'analisi della condizione implica ritrovare diverse clausole potenzialmente distribuite in vari articoli del contratto. La precisione del retrieval è qui altrettanto critica, ma la tolleranza agli errori è ancora più bassa: un'interpretazione errata di una clausola contrattuale può avere conseguenze giuridiche e finanziarie gravi. Per questo dominio, raccomandiamo un chunking semantico con chunk più lunghi (800-1200 token) per preservare la coerenza dei ragionamenti giuridici, un modello di embedding giuridico fine-tunato (SaulLM o LegalBERT) se disponibile, un top-k da 10 a 15 per coprire le clausole connesse e un re-ranking obbligatorio con un modello cross-encoder.

I risultati di questo progetto prendono la forma di una guida di raccomandazioni architetturali che classifica le configurazioni per tipo di corpus, per vincolo aziendale (precisione, latenza, costo, sovranità) e per volume documentale. Ogni raccomandazione è supportata dai risultati cifrati delle nostre campagne di test, con le metriche di performance attese, i prerequisiti hardware e i compromessi associati. La guida è progettata per essere utilizzabile da un team tecnico senza esperienza pregressa in RAG: fornisce configurazioni pronte all'uso, alberi decisionali per la scelta dei componenti e procedure di test per validare ogni fase della pipeline. Il banco di test stesso è distribuito come progetto open source, permettendo a qualsiasi organizzazione di riprodurre le nostre valutazioni sui propri corpora e validare le proprie scelte architetturali prima del passaggio in produzione.

Prospettive

Le prospettive di evoluzione del progetto sono numerose. La valutazione delle architetture agentiche che estendono il RAG classico con capacità di pianificazione e utilizzo di strumenti è una pista promettente: un agente RAG capace di decidere iterativamente quali documenti consultare, in quale ordine e come combinare le informazioni, può gestire domande complesse che vanno oltre le capacità di un RAG a passaggio singolo. L'integrazione della generazione aumentata da grafo (GraphRAG), che utilizza un grafo di conoscenza in complemento alla base vettoriale per il retrieval, apre prospettive per corpora altamente interconnessi. L'estensione ad altre modalità — RAG su documenti contenenti immagini, tabelle, grafici — è un asse di ricerca attivo. Infine, lo studio del RAG conversazionale, dove il sistema mantiene uno storico del dialogo e adatta il retrieval in base al contesto cumulato degli scambi, prefigura la prossima generazione dei sistemi di IA documentale.

Conclusione

Il RAG non è una tecnologia statica ma un campo di ricerca attivo le cui architetture si evolvono rapidamente. Questo progetto contribuisce a strutturare questa evoluzione documentando rigorosamente ciò che funziona, in quale contesto e a quale costo. Le decisioni architetturali di un sistema RAG — chunking, embedding, retrieval, generazione — sono interdipendenti e devono essere ottimizzate in modo olistico: un miglioramento su un anello può essere annullato da una regressione su un altro. Il nostro approccio sistematico, che combina valutazione quantitativa rigorosa e casi d'uso concreti, fornisce ai team tecnici le chiavi per progettare sistemi RAG performanti, affidabili e adatti ai loro vincoli aziendali. La padronanza di queste architetture è un vantaggio competitivo decisivo per qualsiasi organizzazione che desideri sfruttare appieno il valore delle proprie basi di conoscenza professionali.