RAG con Knowledge Base: come eliminare le allucinazioni nella consultazione di capitolati tecnici

Immagina di dover verificare, in mezzo a centinaia di pagine di normative tecniche, il coefficiente di attrito di un singolo componente oppure le caratteristiche di un articolo preciso. Per rispondere serve risalire a informazioni presenti in documenti diversi: un ragionamento a più salti che, manualmente, richiede diversi minuti di consultazione.

Questo scenario è comune a molte aziende. Una in particolare aveva affrontato in precedenza il problema utilizzando Microsoft Copilot, istruito con i PDF presenti nel server aziendale e manuali di meccanica. Il risultato è stato solo parzialmente soddisfacente: le risposte generate contenevano frequenti allucinazioni, obbligando comunque gli utenti a verificare ogni risultato e vanificando gran parte del vantaggio promesso.

Da questa esperienza è nato il progetto di un sistema di Retrieval-Augmented Generation (RAG) ibrido con Knowledge Base integrata.

Perché un RAG “puro” non basta

Un sistema RAG classico funziona in tre fasi: i documenti vengono divisi in frammenti (chunk), convertiti in vettori tramite un modello di embedding e indicizzati in un database vettoriale; alla domanda dell’utente viene applicata la stessa trasformazione per recuperare i chunk semanticamente più simili; infine, un modello linguistico genera la risposta sulla base del contesto recuperato. Questo approccio risolve già un problema — un LLM “puro” tende a inventare o parafrasare le risposte — ma non basta quando il dominio è composto da dati strutturati e precisi come coefficienti, temperature, dimensioni e codici.

La ricerca vettoriale è per natura semantica, non esatta: trova testo simile alla domanda, non il valore numerico corretto. Nel caso dei capitolati, il problema è aggravato dalla struttura stessa dei documenti: alcuni sono organizzati in paragrafi narrativi, altri contengono tabelle tecniche, altri ancora presentano disegni e testi bilingue. Un sistema che si affidasse solo alla similarità semantica rischierebbe di restituire un valore “vicino”, ma sbagliato.

Una Knowledge Base per eliminare le allucinazioni

La soluzione progettata affianca al retrieval vettoriale una Knowledge Base strutturata: un archivio centralizzato in cui ogni informazione tecnica non è mantenuta come testo grezzo, ma come fatto atomico. Tre estrattori collaborano per popolarla, estraendo dettagli tecnici in diversi modi. Il risultato viene poi organizzato in indici precalcolati (per suffisso, codice articolo e tipo di rivestimento) che permettono operazioni di ricerca in tempo costante, invece di scansionare l’intera Knowledge Base a ogni domanda.

Come collaborano KB e retrieval vettoriale

Il cuore architetturale del sistema è un componente che coordina questi due meccanismi: quando arriva una domanda, il sistema prova a riconoscere pattern noti e a interrogare gli indici della KB. Se trova un fatto pertinente, lo usa per arricchire la query prima di passarla al motore di ricerca vettoriale, aumentando la precisione del recupero. Se dal lookup emergono anche i documenti di provenienza, la ricerca vettoriale può essere ristretta solo a quelli, anziché sull’intera collezione.

Qdrant e BM25 per una risposta precisa

Eseguito in locale invece che come servizio cloud — una scelta non secondaria quando i documenti indicizzati sono riservati —, Qdrant è risultato il database vettoriale più adatto per questo progetto. Per mantenere i tempi di risposta rapidi anche quando l’archivio cresce, Qdrant si appoggia all’algoritmo Hierarchical Navigable Small World (HNSW), che costruisce un grafo di prossimità organizzato su più livelli gerarchici, permettendo la ricerca del vicino in tempo logaritmico: una soluzione ottima per uno scenario in continuo aggiornamento.

Come metrica di similarità è stata scelta la cosine similarity, coerente con la natura degli embedding testuali: il significato semantico di un vettore è legato al suo angolo rispetto agli altri, non alla sua lunghezza. Inoltre, Qdrant supporta l’aggiornamento incrementale della collezione: quando un documento viene aggiunto o rimosso, solo i vettori corrispondenti vengono toccati, senza dover ricostruire l’intero indice. Un dettaglio che riduce i tempi di aggiornamento del corpus da ore a pochi minuti.

In parallelo alla ricerca vettoriale su Qdrant, una ricerca lessicale (basata sull’algoritmo BM25) affianca la ricerca semantica, così da non perdere termini tecnici specifici che il solo embedding tenderebbe a parafrasare verso concetti simili ma meno precisi. I punteggi delle due ricerche vengono infine normalizzati e combinati in un unico score, che determina quali porzioni di testo verranno effettivamente mostrate al LLM.

4 domande, 4 strade, 4 risposte

Il sistema instrada ogni domanda verso uno di quattro possibili percorsi di risposta, a seconda di ciò che trova. Il percorso più importante, quello che definisce l’intero progetto, si attiva quando due condizioni sono vere contemporaneamente: la Knowledge Base ha trovato un fatto classificato come primario (cioè estratto da una tabella e non da un testo narrativo) e la domanda riguarda una proprietà tecnica specifica. Solo in questo caso il sistema esclude del tutto il modello linguistico: la risposta viene composta direttamente dai dati strutturati della KB, con una precisione del 100%.

Quando questa condizione non si verifica, il sistema ripiega su percorsi più flessibili:

• Flusso guidato: l’LLM riceve sia i fatti strutturati sia il testo narrativo per costruire una risposta discorsiva ma vincolata.
• Puro retrieval: attivo quando la Knowledge Base non trova nulla di pertinente; la risposta si appoggia solo sui chunk recuperati da Qdrant e dalla ricerca lessicale.
• Filtro di specificità: di fronte a domande troppo generiche, il sistema chiede di specificare meglio la richiesta invece di tentare una risposta.

Ogni risposta, indipendentemente dal percorso, riporta esplicitamente la fonte da cui proviene, per consentire una verifica manuale immediata quando serve.

Cosa dicono i numeri?

La combinazione finale di modelli di embedding e LLM arriva da una serie di benchmark comparativi, non da una scelta a priori. Per quanto riguarda gli embedding, il confronto tra due modelli (uno multilingue e più pesante, l’altro più leggero e specializzato sull’inglese) ha mostrato una qualità di retrieval quasi identica, ma una velocità di quasi cinque volte superiore a favore del modello leggero. Nonostante questo, per un corpus documentale in italiano e inglese destinato a crescere nel tempo, è stato scelto il modello multilingue: la marginale perdita di velocità passa in secondo piano a fronte di un’ottima coerenza semantica.

Sul fronte dei modelli linguistici, quattro LLM open-source sono stati messi a confronto su un set misto di domande. Nessuno dei quattro ha dominato su entrambi i fronti: il modello più efficace sulle domande strutturate ha ottenuto il punteggio più alto in assoluto, mentre un modello diverso si è distinto per fluidità e precisione sulle domande più aperte. La scelta finale ha bilanciato precisione, qualità e tempi di risposta.

Conclusione

Questo lavoro non punta a creare l’ennesimo chatbot sui documenti aziendali. L’obiettivo è un’architettura che separi i casi in cui una risposta deve essere deterministica da quelli in cui serve la flessibilità di un LLM. In un contesto industriale dove un valore sbagliato o impreciso — un coefficiente d’attrito, una temperatura, un codice — può avere ripercussioni operative reali, questa distinzione non è un dettaglio superfluo.

C’è una grande differenza tra uno strumento semplicemente utile e uno strumento di cui ci si può davvero fidare senza dover ricontrollare ogni dato a mano.