Knowledge graph vs RAG: differenze, GraphRAG e quando combinarli

Un knowledge graph e un sistema RAG rispondono a bisogni diversi. Il RAG classico recupera i passaggi di testo più pertinenti a una domanda e li passa a un modello linguistico, mentre un knowledge graph modella entità e relazioni in una struttura navigabile fatta di nodi e archi. GraphRAG combina le due cose: usa un grafo costruito dai documenti per orientare il recupero quando le domande richiedono di collegare informazioni sparse in più punti del corpus. La scelta giusta dipende dal tipo di domande che riceve davvero, non da quanto è di moda l'approccio.

Cos'è un knowledge graph (e perché non è un database vettoriale)

Un knowledge graph rappresenta la conoscenza come triple soggetto-predicato-oggetto: «Azienda X» «ha sede in» «Milano», «Contratto Y» «è firmato da» «Fornitore Z». Ogni entità diventa un nodo, ogni relazione un arco etichettato. Il grafo si interroga con linguaggi dedicati come Cypher o SPARQL, oppure navigando le connessioni programmaticamente: partendo da un nodo si seguono gli archi per trovare tutto ciò che è collegato, anche a più salti di distanza.

Questo è esattamente ciò che un database vettoriale o un indice full-text non fanno bene: un motore di ricerca semantica trova i passaggi più simili a una domanda, ma non ragiona esplicitamente su «chi è collegato a chi» attraverso più passaggi. Se la domanda è «quali fornitori condividono lo stesso stabilimento del fornitore principale di un certo prodotto», un grafo risponde percorrendo gli archi; un retrieval su passaggi deve sperare che l'informazione completa si trovi tutta in un unico chunk, cosa rara.

Come funziona il RAG "classico": recupero di passaggi

Nel RAG tradizionale i documenti vengono divisi in porzioni (chunk), trasformati in embedding e indicizzati. Alla domanda dell'utente corrisponde una ricerca che combina corrispondenza lessicale e similarità semantica, quella che su Kopik si chiama ricerca ibrida: full-text più espansione semantica delle parole chiave, in modo da recuperare i passaggi più pertinenti anche quando la domanda non usa esattamente le stesse parole del documento. I passaggi trovati vengono passati al modello linguistico insieme alla domanda, e la risposta cita le fonti da cui proviene.

Questo approccio funziona benissimo quando la risposta sta, interamente o quasi, in uno o due passaggi vicini tra loro: una clausola contrattuale, una procedura, un articolo di legge, una FAQ. Il punto debole emerge quando la risposta richiede di mettere insieme fatti distribuiti in documenti diversi, collegati da relazioni che il testo non esprime in modo esplicito e ravvicinato. Qui il retrieval per similarità rischia di trovare passaggi rilevanti singolarmente, ma di non ricostruire la catena di relazioni che li unisce.

GraphRAG: quando il recupero ha bisogno di una mappa

GraphRAG nasce per colmare questo divario. L'idea, resa popolare anche da progetti di ricerca come quello di Microsoft, è in due fasi: prima si costruisce un grafo di conoscenza estraendo automaticamente entità e relazioni dai chunk dei documenti (con un modello linguistico o con pipeline NLP dedicate), poi, al momento della domanda, si naviga il grafo per trovare entità correlate e passaggi associati prima di generare la risposta.

I due passaggi: costruzione e interrogazione

La costruzione è il lavoro pesante: per ogni documento si identificano le entità (persone, organizzazioni, prodotti, date, importi), si estraggono le relazioni tra loro e si deduplicano le entità che compaiono con nomi leggermente diversi (entity resolution: «ACME Srl», «ACME S.r.l.», «Acme» devono diventare lo stesso nodo). L'interrogazione, invece, parte dalla domanda, identifica le entità coinvolte, naviga il grafo per raccogliere il contesto rilevante e lo combina con i passaggi di testo originali prima di passare tutto al modello.

Ricerca locale e globale

Le implementazioni più mature distinguono due modalità. La ricerca locale parte da un'entità precisa e ne esplora i vicini diretti, utile per domande puntuali tipo «chi riporta a questo manager». La ricerca globale lavora invece su riassunti di «comunità» di nodi fortemente collegati tra loro, utile per domande di sintesi tipo «quali sono i temi ricorrenti nei verbali del comitato rischi dell'ultimo anno». Questa seconda modalità è difficile da ottenere con un RAG puramente basato su similarità, perché nessun singolo chunk contiene la sintesi: serve aggregare informazioni sparse in decine di documenti.

Quando conviene ciascun approccio

Combinare knowledge graph e RAG in pratica

Nella maggior parte delle organizzazioni italiane, PMI comprese, la domanda non è «grafo o RAG» ma «quanta parte del grafo serve davvero». Una ricerca ibrida che combina BM25 e vettori copre già una fetta sorprendentemente ampia delle domande multi-entità, perché l'espansione semantica recupera passaggi collegati concettualmente anche senza un grafo esplicito. Costruire e mantenere un knowledge graph completo ha un costo ricorrente non trascurabile: ogni nuovo documento va ri-processato per estrarne entità e relazioni, e gli errori di deduplica delle entità (due nomi diversi per la stessa persona o azienda) degradano silenziosamente la qualità delle risposte.

Un pattern pragmatico è quello ibrido a due livelli: si mantiene un RAG con citazioni per tutte le domande ordinarie, e si aggiunge un livello di metadati strutturati (non necessariamente un grafo completo) per le relazioni che contano davvero per il proprio dominio, per esempio collegare ogni clausola contrattuale al fornitore e alla data di scadenza, o ogni policy HR al CCNL di riferimento come descritto nella guida su assistente IA per le policy HR. Questo livello intermedio dà gran parte del valore di un grafo senza il costo di una pipeline di estrazione entità su tutto il corpus.

Chi vuole partire senza impegnare un team di data engineering può caricare i documenti su una base di conoscenza su Kopik: l'indicizzazione ibrida gestisce automaticamente full-text ed espansione semantica, e ogni risposta arriva con i passaggi citati, utile anche solo per capire, osservando dove il sistema fatica, se il proprio caso d'uso ha davvero bisogno di un grafo o se il problema è altrove, per esempio un chunking troppo grossolano o documenti disorganizzati.

Checklist per decidere l'approccio

• Le domande tipiche richiedono di collegare informazioni presenti in più documenti distinti, o stanno quasi sempre in un singolo passaggio?
• Ha già dati strutturati disponibili altrove (CRM, ERP, organigramma) che potrebbero essere collegati ai documenti invece di essere estratti da zero?
• Il team ha competenze per mantenere un database a grafo e una pipeline di estrazione entità nel tempo, o rischia di diventare un progetto abbandonato dopo il primo rilascio?
• Serve tracciabilità delle fonti per ogni affermazione (per esempio per motivi di conformità)? Un grafo puro spesso perde questo collegamento se non progettato apposta.
• Il volume e la frequenza di aggiornamento dei documenti permettono una ri-estrazione periodica del grafo senza costi insostenibili?
• Ha già provato un RAG ibrido e misurato dove fallisce, con metriche concrete come descritto in come valutare un sistema RAG?

Se la maggior parte delle risposte punta verso «serve collegare molte entità, abbiamo dati strutturati, abbiamo competenze e il volume lo giustifica», GraphRAG o un grafo dedicato hanno senso. Se le risposte sono più tiepide, conviene partire da un RAG solido e aggiungere struttura solo dove serve, piuttosto che costruire un'infrastruttura a grafo che pochi useranno davvero. Vale anche la pena confrontare l'alternativa dei modelli a contesto lungo, discussa in RAG vs modelli a contesto lungo, per i casi in cui il corpus è piccolo abbastanza da stare quasi interamente nel prompt.

Domande frequenti