Una delle difficoltà più ricorrenti nei sistemi RAG non riguarda soltanto il recupero dei documenti, ma la comprensione delle relazioni tra le informazioni.

Un sistema RAG tradizionale prende una domanda, cerca i frammenti di testo più simili e li passa al modello linguistico. Questo approccio funziona bene quando la risposta si trova quasi “in superficie”, cioè quando basta recuperare un passaggio preciso del manuale. Ma mostra i suoi limiti quando la domanda richiede di collegare più elementi: una procedura, un componente, una regola, una causa, una condizione o un vincolo operativo.

È in questo scenario che nasce l’idea della Knowledge Graph nel progetto RAGraph. Il grafo non viene usato come decorazione visuale, ma come struttura semantica che aiuta il sistema a capire come sono collegate le cose dentro un documento.

Il primo passaggio è semplice da capire. Il documento viene letto, pulito e diviso in segmenti più piccoli, chiamati chunk.

Nel progetto, ogni chunk contiene una porzione del testo originale e conserva alcune informazioni di contesto: documento di provenienza, indice del chunk, pagina stimata e contenuto testuale. Questo è importante perché il sistema non deve perdere il collegamento con la fonte.

Un manuale tecnico, per esempio, può contenere una sezione sulla manutenzione, una sui componenti, una sugli allarmi e una sulle procedure di sicurezza. Dividerlo in chunk permette al sistema di lavorare su porzioni gestibili, senza dover inviare ogni volta l’intero documento al modello.

Ogni chunk viene poi trasformato in un vettore numerico, cioè in una rappresentazione matematica del suo significato. Questo vettore viene salvato in Qdrant, il motore di ricerca vettoriale. Qdrant serve quindi a rispondere a una domanda iniziale: “quali pezzi di testo sono semanticamente più vicini alla richiesta dell’utente?”.

Questa però è solo una parte del sistema.

Un punto importante da chiarire è che la Knowledge Graph non nasce automaticamente da Qdrant.

Qdrant conserva vettori e permette di cercare somiglianze. È molto bravo a dire che un chunk assomiglia a una domanda. Ma non costruisce da solo concetti, ruoli, relazioni e fatti.

Il grafo nasce in una fase successiva, quando l’LLM legge gruppi di chunk e produce un JSON strutturato. Qui il modello non deve semplicemente riassumere il testo. Deve estrarre conoscenza organizzata.

In pratica, per ogni gruppo di chunk, il sistema chiede al modello di individuare tre cose:

Questa è la differenza principale rispetto a un RAG classico. Non ci limitiamo a conservare testo. Costruiamo una rappresentazione più vicina al modo in cui una persona esperta leggerebbe un manuale: “questo componente fa parte di quel sistema”, “questa procedura richiede questo controllo”, “questa regola si applica a questa condizione”.

Immaginiamo un manuale che dica:

Da questo testo il sistema può estrarre alcuni nodi:

Poi può estrarre relazioni:

Infine può generare facts, cioè affermazioni più piccole e verificabili:

La cosa importante è che ogni fatto conserva il riferimento al chunk da cui è stato estratto. Questo permette al sistema di non perdere il legame con il testo originale.

Per evitare che il grafo diventi caotico, il progetto usa una ontologia di base.

L’ontologia è una specie di vocabolario controllato. Definisce quali tipi di concetti esistono e quali relazioni hanno senso. Per esempio, in un dominio tecnico possiamo avere concetti come componente, procedura, parametro, anomalia, regola. E relazioni come PART_OF, REQUIRES, APPLIES_TO, DEPENDS_ON, AFFECTS.

Questo aiuta l’LLM a non inventare una struttura diversa ogni volta. Il modello legge il testo, ma lo interpreta dentro una griglia semantica. In questo modo il grafo è più coerente, più interrogabile e più utile nella ricerca.

Una volta estratti nodi, archi e facts, tutto viene salvato in MongoDB.

MongoDB conserva la parte documentale e strutturata: documenti, chunk, ontologie, nodi, relazioni, facts e audit delle risposte. Qdrant conserva invece la parte vettoriale, cioè gli embedding utili alla ricerca semantica.

I due sistemi hanno quindi ruoli diversi ma complementari:

Questa separazione è importante perché evita di confondere il vettore con la conoscenza. Un vettore aiuta a trovare somiglianze. Un grafo aiuta a seguire relazioni.

Per migliorare la ricerca è stato aggiunto un meccanismo chiamato Semantic Traversal Retrieval.

L’idea è molto semplice: quando l’utente fa una domanda, il sistema non si ferma ai chunk più simili trovati da Qdrant. Usa quei chunk come punto di partenza per esplorare il grafo.

Il processo funziona così.

Prima Qdrant recupera i chunk semanticamente vicini alla domanda. Poi il sistema guarda quali facts, nodi e archi sono collegati a quei chunk. A quel punto attraversa il grafo per cercare concetti vicini, dipendenze, procedure correlate o relazioni utili. Infine aggiunge o ripunteggia i chunk collegati semanticamente, fondendo ricerca vettoriale, keyword e grafo.

In altre parole, non cerchiamo solo “testo simile”. Cerchiamo anche concetti connessi.

Questo cambia molto il comportamento del sistema.

Se l’utente chiede: “cosa devo controllare prima di riavviare la pompa?”, una ricerca vettoriale potrebbe trovare solo il chunk in cui compare la parola “pompa”. Il traversal semantico può invece scoprire che la pompa è collegata a una procedura di riavvio, che quella procedura richiede un controllo del filtro e che il filtro fa parte del sistema di aspirazione.

La risposta diventa più completa perché il sistema non ha seguito soltanto la somiglianza linguistica, ma anche la struttura concettuale del manuale.

Il vantaggio principale è che il sistema riduce il carico interpretativo sul modello linguistico.

In un RAG classico, il modello riceve vari chunk e deve capire da solo quali informazioni collegare. In RAGraph, una parte di questo lavoro è già stata fatta durante l’ingestione: nodi, archi e facts sono stati estratti e salvati.

Questo permette risposte più controllabili. Il modello può ricevere non solo testo, ma anche fatti brevi e relazioni esplicite. Inoltre, grazie alle citazioni ai chunk, ogni affermazione può essere ricondotta a una fonte.

È una differenza importante soprattutto nei manuali tecnici, dove sbagliare una relazione può essere più grave che sbagliare una parola. Sapere che una procedura richiede un controllo è diverso dal sapere che i due concetti compaiono nello stesso documento.

La Knowledge Graph di RAGraph non è un grafo generato automaticamente dal database vettoriale. È il risultato di una estrazione semantica guidata: il documento viene diviso in chunk, i chunk vengono vettorializzati in Qdrant, l’LLM legge gruppi di testo e produce nodi, archi e facts, che vengono salvati in MongoDB.

Il Semantic Traversal Retrieval aggiunge il passaggio decisivo: parte dalla ricerca vettoriale, ma poi attraversa il grafo per trovare relazioni concettuali utili.

Il risultato è un sistema che non cerca solo frasi simili, ma prova a ricostruire il significato operativo dei documenti. Ed è proprio questo il punto: trasformare un manuale da semplice archivio di testo a mappa navigabile della conoscenza