GraphRAG — il retrieval che ragiona sulle connessioni

Il problema che GraphRAG affronta

Per capire perché GraphRAG esiste, bisogna prima essere brutalmente onesti sui limiti del RAG classico — quello vettoriale, basato su chunking, embedding e similarity search. È la pipeline che oggi muove la stragrande maggioranza delle applicazioni LLM in produzione, dalla chat documentale aziendale al copilot del codice. Spezzi un corpus in chunk di qualche centinaio di token, calcoli un embedding per ognuno, li salvi in un vector store (pgvector, Pinecone, Qdrant, Weaviate). All'arrivo di una query la trasformi in embedding, fai similarity search, recuperi i top-K chunk più vicini, li infili nel prompt dell'LLM e gli chiedi di rispondere.

Questo schema funziona davvero bene per una categoria di query che chiameremo locali: domande la cui risposta è contenuta — letteralmente o quasi — in uno o pochi chunk. “Qual è la policy di rimborso per i clienti business?” è una query locale: esiste un singolo paragrafo nel documento delle policy che la contiene, e il sistema vettoriale lo trova. “Quando scade il contratto con Acme?” è locale. “Come si configura SSO con Okta?” è locale. È la zona di comfort del RAG vettoriale, e anche la ragione per cui il pattern si è diffuso così velocemente: nella maggioranza dei casi enterprise reali, le persone fanno query locali.

Il problema esplode quando le query diventano globali o relazionali. “Quali sono i temi principali emersi dai feedback clienti dell'ultimo trimestre?” non ha risposta in un singolo chunk: serve sintetizzare migliaia di chunk e identificare pattern. “Quali rischi cyber emergono incrociando l'audit del 2023, il report incidenti 2024 e la nuova NIS2?” richiede di mettere in relazione tre corpora diversi e ragionare sulle intersezioni. “Quali persone nel mio CRM hanno legami indiretti con il decisore di Acme Corp?” è una query multi-hop che il RAG vettoriale non può risolvere strutturalmente: non esiste un chunk che contiene già la risposta, perché la risposta vive nella composizione di fatti distribuiti.

Analogia da impiantare bene, perché tornerà spesso in questa guida: il RAG vettoriale è un bibliotecario molto bravo a trovare il libro giusto sullo scaffale. Gli dici “voglio sapere di Napoleone alla campagna di Russia” e torna in tre secondi con i cinque libri più rilevanti. Ma se gli chiedi “quali figure storiche del XIX secolo hanno avuto influenza incrociata sui movimenti rivoluzionari europei?”, il bibliotecario va in crisi: non esiste un libro che risponde a quella domanda. La risposta vive nelle connessioni tra centinaia di libri, ed è esattamente quel tessuto connettivo che il bibliotecario non possiede. Quello che serve, in quel caso, è uno storico: qualcuno che ha già letto tutti i libri, ha costruito mentalmente la mappa delle relazioni, e può rispondere navigando il grafo cognitivo che ha in testa.

GraphRAG è il passaggio dal bibliotecario allo storico.

C'è poi un secondo limite, più sottile, del RAG vettoriale: la perdita di contesto strutturale durante il chunking. Quando spezzi un documento in chunk da 512 o 1024 token, perdi inevitabilmente la posizione del chunk nella struttura del documento e, soprattutto, le relazioni esplicite tra entità che vivono in chunk diversi. Se un report parla di “Mario Rossi, CFO di Acme dal 2019” a pagina 3, e a pagina 47 dice “il CFO ha approvato la fusione con Beta Corp”, il sistema vettoriale può recuperare i due chunk separatamente ma non sa che si tratta della stessa persona, e non sa che esiste un legame Mario Rossi → ha approvato → fusione Acme/Beta. Per il modello sono due fatti slegati. Per uno storico — di nuovo — sono il filo che racconta come una persona ha cambiato la storia di un'azienda. Questo è il problema. GraphRAG è una famiglia di tecniche per risolverlo.

L'intuizione GraphRAG

L'idea fondamentale, che il paper Microsoft di aprile 2024 “From Local to Global: A Graph RAG Approach to Query-Focused Summarization” (Edge et al., arXiv 2404.16130) ha cristallizzato e portato al mainstream, è semplice da enunciare ma ricca di conseguenze ingegneristiche: invece di indicizzare i documenti come una pila di chunk, costruisci da quei documenti un grafo di conoscenza, e fai retrieval sul grafo.

I nodi del grafo sono entità — persone, organizzazioni, luoghi, concetti, eventi. Gli archi sono relazioni — ha fondato, è figlio di, lavora per, è successo prima di, è correlato a. Ogni nodo e ogni arco porta con sé del testo descrittivo (la sua “scheda”), un riferimento ai chunk originali da cui è stato estratto (provenance) e — qui sta una delle innovazioni centrali del paper Microsoft — il grafo viene suddiviso in comunità, cluster di nodi densamente connessi, e per ogni comunità viene generato un summary da un LLM. Questi summary sono il tessuto connettivo che permette di rispondere a query globali senza dover passare ogni volta sull'intero corpus.

Analogia: pensa a Wikipedia. Wikipedia non è solo una collezione di articoli (chunk). È un grafo: ogni articolo è un nodo, ogni link interno è un arco. Se cerchi “Napoleone” e leggi l'articolo, vedi link a “Giuseppina di Beauharnais”, “Talleyrand”, “Campagna d'Egitto”, e da lì navighi per scoperta. Ora aggiungi sopra Wikipedia una cosa che si chiama Wikidata: una rappresentazione strutturata dello stesso sapere, dove le relazioni sono esplicite e queryable (“dammi tutti i monarchi europei che hanno regnato contemporaneamente a Napoleone e gli erano parenti acquisiti”). GraphRAG è esattamente questo: la trasformazione di un corpus testuale in un Wikipedia + Wikidata costruiti automaticamente da LLM, su cui poi un altro LLM può ragionare.

Una nota onesta che vale la pena fissare subito: GraphRAG non è una tecnologia inventata da Microsoft nel 2024. Knowledge graph + retrieval è un pattern che esiste da decenni — basta pensare a sistemi come Cyc, a Freebase, alle ontologie del semantic web (RDF, OWL, SPARQL). Quello che è cambiato di recente è che gli LLM sono diventati abbastanza bravi da fare due cose prima impossibili a scala: (1) estrarre automaticamente entità e relazioni da testo libero con accuratezza usabile, e (2) generare summary in linguaggio naturale di sottografi e comunità. Questi due tasselli, che prima richiedevano costose pipeline NLP custom o annotazione umana, oggi si fanno con prompt engineering. È questo che ha sbloccato GraphRAG come pattern industriale, non un'invenzione algoritmica originale. La differenza pratica è enorme: ciò che valeva 200k€ di consulenza in un progetto knowledge graph dieci anni fa, oggi gira come una pipeline batch su una VM da 50€ al mese.

La pipeline di indexing, stadio per stadio

L'indexing in GraphRAG è la parte più costosa e più interessante. Vale la pena descriverla nei suoi cinque stadi canonici, con esempi reali, perché è qui che si gioca la qualità del sistema finale.

Stadio 1 — Chunking

Si parte come nel RAG classico: il corpus viene spezzato in chunk di dimensione gestibile dal contesto di un LLM, tipicamente 300–1200 token. Non c'è molto di sofisticato qui, anche se chunking semantico (split a confini di paragrafo o sezione, non a finestra cieca) aiuta significativamente la qualità dell'estrazione successiva, perché evita di tagliare a metà una frase che descrive una relazione. Una regola pragmatica: se i tuoi documenti hanno header markdown o struttura HTML, sfruttala. Se sono testo grezzo, usa uno splitter ricorsivo (es. RecursiveCharacterTextSplitter di LangChain) con separatori in ordine di preferenza.

Stadio 2 — Entity and relationship extraction

Per ogni chunk si invoca un LLM con un prompt strutturato che chiede di estrarre (a) tutte le entità rilevanti, ciascuna con un type (PERSON, ORGANIZATION, LOCATION, EVENT, CONCEPT…) e una breve descrizione contestuale, e (b) tutte le relazioni tra coppie di entità nello stesso chunk, ciascuna con descrizione e weight (forza percepita della relazione, tipicamente da 1 a 10).

Esempio concreto. Dato il chunk:

“Nel 2007 Steve Jobs presentò il primo iPhone al Macworld di San Francisco. Il dispositivo, sviluppato in segreto sotto il nome in codice 'Project Purple', segnò la transizione di Apple da produttore di computer a colosso del mobile.”

L'estrazione produrrebbe qualcosa del genere:

# Entities
- Steve Jobs       (PERSON)       CEO di Apple, presentatore del primo iPhone
- iPhone           (PRODUCT)      primo smartphone Apple, presentato nel 2007
- Macworld         (EVENT)        conferenza Apple a San Francisco
- Apple            (ORGANIZATION) azienda tecnologica, lancia iPhone nel 2007
- Project Purple   (PROJECT)      nome in codice dello sviluppo segreto

# Relationships
(Steve Jobs, iPhone)         "ha presentato"      weight=9
(iPhone, Macworld)           "presentato a"       weight=7
(Apple, iPhone)              "ha sviluppato"      weight=10
(Project Purple, iPhone)     "nome in codice di"  weight=8
(Apple, Project Purple)      "ha condotto"        weight=8extraction

Ciascuna entità e relazione conserva un riferimento al chunk d'origine. Questo è cruciale per la provenance: quando il sistema poi userà queste informazioni, potrà sempre risalire al testo originale per citare la fonte. È la stessa filosofia per cui Wikipedia richiede citazioni per ogni affermazione. Senza provenance, un knowledge graph diventa rapidamente una nuvola di allucinazioni indistinguibili dai fatti, e il sistema perde completamente di valore in qualsiasi contesto serio (legal, medical, investigative).

Stadio 3 — Entity resolution e graph construction

A questo punto hai una lista di triplette estratte chunk per chunk. Ma “Steve Jobs”, “S. Jobs” e “Jobs” estratti da chunk diversi sono la stessa entità, e vanno fusi. È il classico problema di entity resolution (detto anche record linkage o deduplication), che in GraphRAG si risolve tipicamente combinando tre segnali:

1. Match testuale sui nomi (Levenshtein, Jaro-Winkler, soft-TFIDF)
2. Similarità degli embedding delle descrizioni associate
3. Per i casi ambigui, un giudizio LLM-based — passi descrizione_A e descrizione_B al modello e gli chiedi se si tratta della stessa entità

Analogia: l'entity resolution è il lavoro che fa un bibliotecario quando riceve mille schede catalografiche e deve capire che “Dostoevskij, Fëdor”, “Dostoevsky, Fyodor” e “Достоевский, Фёдор” sono lo stesso autore. È noioso, è dove vivono i bug, ed è qualcosa che gli LLM hanno reso molto più trattabile ma non ancora banale. È anche il punto in cui un grafo si rompe più silenziosamente: sotto-merging (rimangono duplicati come “Apple” e “Apple Inc.”) gonfia il grafo e disperde l'attenzione del retriever; over-merging (fondere “John Smith il senatore” con “John Smith il calciatore”) corrompe il grafo creando relazioni fittizie. È uno sweet spot delicato e va monitorato con metriche.

Risolte le entità, costruisci il grafo: ogni entità è un nodo (con descrizione, type, embedding), ogni relazione è un arco (con descrizione, weight, riferimenti ai chunk). Il grafo si materializza in un graph database — Neo4j, Memgraph, Apache AGE su Postgres, NetworkX in memoria per piccola scala. Per ordini di grandezza tipici: un corpus enterprise da 100k chunk produce ~50k–200k entità e ~200k–1M archi. Niente che metta in difficoltà un graph store moderno, ma abbastanza da non essere “ricostruibile da zero ad ogni query”.

Stadio 4 — Community detection

Qui sta la mossa intelligente del paper Microsoft. Una volta costruito il grafo, si applica un algoritmo di community detection per identificare cluster di nodi densamente connessi. Le comunità tendono a corrispondere a temi o domini: un cluster di entità che parlano tutte di calcio, un altro di politica europea, un terzo di startup AI. È un'operazione topologica, non semantica — l'algoritmo non legge il testo, guarda la struttura delle connessioni — ma proprio per questo è veloce e robusta.

L'algoritmo scelto da Microsoft è Leiden (Traag, Waltman, van Eck, 2019), una versione migliorata del più classico Louvain (Blondel et al., 2008). Entrambi massimizzano la modularità del grafo — una misura di quanto le partizioni siano internamente dense ed esternamente sparse — ma Leiden risolve un difetto noto di Louvain (la possibilità di produrre comunità sconnesse) e dà partizioni più stabili. Cruciale: Leiden è gerarchico. Produce non una sola partizione, ma un albero di partizioni a livelli: al livello 0 hai molte piccole comunità densissime, al livello 1 le accorpa in cluster più grandi, e così via. Questa gerarchia è la chiave del “From Local to Global” del titolo del paper: query molto specifiche useranno comunità di basso livello (locali), query molto generiche useranno comunità di alto livello (globali).

Analogia: immagina una conferenza scientifica. Al livello più basso, hai tavoli di discussione di 4–5 persone che parlano di temi ipertecnici — “nuove tecniche di attention sparse per modelli con contesto 1M token”. Al livello sopra, hai sessioni parallele su sotto-discipline — “efficient transformers”. Al livello sopra ancora, hai i grandi panel keynote su “il futuro della ricerca in AI”. Stesso pubblico raggruppato a granularità diverse, a seconda del livello di astrazione della domanda. GraphRAG fa esattamente questo sul corpus.

Stadio 5 — Community summarization

Per ogni comunità identificata, a ogni livello della gerarchia, si invoca un LLM con il task di scrivere un report strutturato della comunità: i temi principali, le entità più importanti, le relazioni più rilevanti, eventuali claim emergenti. Questi report sono il cuore del global search.

Quando arriva una query globale, il sistema non guarda i chunk: guarda i community report. Su un corpus di 100.000 chunk magari ottieni 5.000 comunità di basso livello, 800 di medio livello, 50 di alto livello. Riassumere 50 community report dentro un singolo contesto LLM è gestibile; riassumere 100.000 chunk no. È un trade-off classico pre-compute heavy, query cheap.

Esempio reale di community report, output prodotto da Claude Sonnet su un corpus di articoli di tech news:

Comunità “AI Foundation Models 2024–2025” — Questa comunità raggruppa entità relative ai grandi modelli di linguaggio rilasciati nell'ultimo anno. Le entità centrali sono OpenAI (GPT-4o, o1, o3), Anthropic (Claude 3.5 Sonnet, Claude 3 Opus, Claude 4), Google DeepMind (Gemini 1.5 Pro, Gemini 2.0), Meta (Llama 3.1, Llama 3.3). Tema dominante: convergenza sulle capacità di reasoning, con o1/o3 e Claude che spostano il focus dal pre-training al test-time compute. Tensioni rilevanti: la disputa OpenAI-Microsoft sul modello di partnership; l'emergere di Anthropic come polo etico-safety alternativo. Eventi chiave: rilascio di o1 (settembre 2024), Claude 3.5 Sonnet new (ottobre 2024), Claude 4 (maggio 2025). Pattern emergente: i due-tre lab di frontiera convergono su capability simili a distanza di settimane, sintomo di un equilibrio competitivo strettissimo.

Questo report viene generato una volta sola in fase di indexing, salvato, e poi riutilizzato per migliaia di query future. Quando arriverà una query tipo “qual è la dinamica competitiva tra i principali AI lab nel 2024–25?”, il sistema avrà già la risposta confezionata, non dovrà ricostruirla dal corpus.

Query time — local, global, drift

Una volta indicizzato il corpus, GraphRAG offre almeno tre modalità di interrogazione, e trattarle distintamente è importante perché ognuna ha un suo profilo di costo, latenza e qualità.

Local search

È la modalità più vicina al RAG classico, ma arricchita. Quando arriva una query locale — sai che la risposta è in un punto specifico del corpus — il sistema trova le entità più rilevanti per la query via embedding similarity sui nomi e descrizioni delle entità, ne espande il vicinato nel grafo (entità connesse, archi rilevanti, comunità di appartenenza), recupera anche i chunk testuali originali da cui quelle entità sono state estratte, compone un contesto ricco — entità + relazioni + chunk + community summary di appartenenza — e lo passa all'LLM insieme alla query.

La differenza chiave rispetto al RAG vettoriale puro: invece di vedere solo 5 chunk testuali, l'LLM vede una carta del territorio attorno alla query. Se chiedi “che ruolo ha avuto Tim Cook nella transizione di Apple ai servizi?”, il sistema non recupera solo i chunk che menzionano Tim Cook: recupera Tim Cook come entità, il suo vicinato grafico (Apple, Steve Jobs, Services Division, App Store, Apple TV+), i community summary in cui Tim Cook compare, e tutto questo confluisce nel prompt finale. È RAG + contesto strutturale.

Global search

È la modalità che il paper Microsoft considera la sua innovazione principale. Pensata per query di sintesi: “quali sono i temi emergenti?”, “fai un summary delle posizioni delle parti”, “quali sono i tre rischi principali emersi dagli incident report dell'anno?”. L'algoritmo carica i community report del livello gerarchico appropriato (di solito medio-alto), per ogni report chiede all'LLM “questo report contiene informazioni rilevanti per la query? In che modo?”, aggrega le risposte parziali (map step) e le sintetizza in una risposta finale (reduce step).

È una pipeline map-reduce in cui i community report sono le unità mappabili. Molto più costosa di local search in termini di chiamate LLM al query time — decine di chiamate vs una sola — ma produce risposte di qualità incomparabile per query globali. Il paper Microsoft mostra benchmark in cui global GraphRAG batte il RAG vettoriale puro del 70–80% nelle valutazioni human-rated di comprehensiveness e diversity delle risposte. Va detto che quei benchmark sono ottimisti — un RAG vettoriale tunato per bene riduce il gap — ma il vantaggio strutturale di global search per query globali rimane reale.

Drift search (la novità ibrida)

Introdotto da Microsoft nell'ottobre 2024, drift search è un'evoluzione ibrida. Inizia come una query globale (consulta community report), ma se identifica che la risposta richiede dettagli specifici, “drifta” verso local search nelle aree del grafo più promettenti. Combina i vantaggi di entrambi a costo intermedio. È diventato il default consigliato da Microsoft GraphRAG dalla versione 0.4 in poi.

Tre query per fissare la differenza

Prendi un corpus di 10.000 articoli sul cambiamento climatico, e considera questi tre tipi di domanda:

Dietro le quinte — gli algoritmi che contano

Tre famiglie di algoritmi sono il cuore tecnico di GraphRAG, e vale la pena guardarle un po' più da vicino di quanto faccia di solito il marketing dei vendor.

Community detection — modularità e Leiden

Il problema matematico è: data una rete G=(V,E), trovare una partizione di V in cluster che massimizza la modularità:

Q = (1 / 2m) · Σ_ij [ A_ij  -  (k_i · k_j) / (2m) ] · δ(c_i, c_j)

dove:
   A_ij = 1 se esiste un arco tra i e j, 0 altrimenti
   k_i  = grado del nodo i (numero di archi incidenti)
   m    = numero totale di archi
   c_i  = comunità di appartenenza del nodo i
   δ    = delta di Kronecker (1 se c_i == c_j, 0 altrimenti)math

L'intuizione: Q confronta la densità di archi interna a ogni comunità con la densità che ci si aspetterebbe da un grafo random con la stessa distribuzione dei gradi. Se la prima è molto più alta della seconda, la partizione è “significativa” e Q è alto. Massimizzare Q è NP-hard, quindi si usano euristiche greedy: Louvain itera move-and-merge fino a convergenza, Leiden aggiunge un refinement step che garantisce comunità ben-connesse (cosa che Louvain non garantiva: poteva produrre comunità con nodi isolati internamente).

Perché conta nella pratica: la granularità delle community che ottieni determina la qualità del global search. Comunità troppo piccole — ogni nodo è una comunità — producono community summary inutili, perché sono solo descrizioni di singole entità. Comunità troppo grandi — tutto il grafo è una comunità — producono un summary inutilizzabile, perché troppo generico. Leiden gerarchico ti dà la flessibilità di scegliere il livello giusto per ogni query. Per un corpus di 100k chunk, ti aspetti tipicamente 2.000–5.000 comunità al livello 0, 200–500 al livello 1, 20–50 al livello 2.

Entity resolution — il problema più sottovalutato

Decidere se due record (nel nostro caso, due menzioni di entità in chunk diversi) si riferiscono alla stessa entità reale è il problema su cui vivono o muoiono molti grafi di conoscenza in produzione. La letteratura accademica è ricca (il libro di Peter Christen, Data Matching, Springer 2012, è il riferimento canonico), ma in pratica nelle pipeline GraphRAG si usa una combinazione di tre fasi.

Prima fase, blocking: per evitare confronti O(n²), si raggruppano i candidati per chiavi grezze — le prime lettere del nome, il type, la lunghezza approssimata. Un'entità “Steve Jobs” verrà confrontata solo con altre entità di type PERSON che iniziano con “S”. Si passa da O(n²) a qualcosa di trattabile.

Seconda fase, similarity computation: per ogni coppia candidata, si computano feature di similarità — string distance (Levenshtein, Jaro-Winkler, soft-TFIDF), cosine similarity tra gli embedding delle descrizioni, eventualmente similarità topologica (i due nodi candidati hanno vicini in comune nel grafo?).

Terza fase, decision: un classificatore decide match/non-match. In GraphRAG moderno questo classificatore è spesso un LLM con prompt strutturato che riceve le due descrizioni e le feature di similarità e risponde con un'etichetta + giustificazione. È più costoso di un classificatore ML tradizionale, ma molto più accurato sui casi al confine.

Gli errori tipici hanno nomi precisi. Under-merging: rimangono duplicati come “Apple” e “Apple Inc.” — il grafo si gonfia, le statistiche di centralità si distorcono, il retriever è confuso. Over-merging: fonde “John Smith il senatore” e “John Smith il calciatore” — il grafo crea relazioni fittizie tra mondi che non c'entrano, e il sistema produce risposte allucinate ma strutturalmente plausibili, che è il tipo peggiore di allucinazione perché passa più facilmente i controlli.

Graph embeddings — utili o vezzo accademico?

Una volta costruito il grafo, può essere utile calcolare embeddings dei nodi che catturino sia la semantica testuale sia la struttura grafica. Node2Vec produce embeddings via random walk + skip-gram (è l'analogo di Word2Vec sui grafi: invece di parole in una frase, hai nodi in un cammino random). GraphSAGE produce embeddings inductive (funzionano anche su nodi nuovi, non visti in training) tramite aggregazione iterativa delle feature dei vicini. Node2Vec+ e RotatE sono estensioni più recenti che gestiscono meglio i grafi knowledge tipici.

In GraphRAG, questi embeddings si usano per trovare entità “simili” anche quando non sono direttamente connesse (utile per query expansion), per migliorare la qualità della community detection (clustering su embeddings vs solo su struttura grafica), e per linkare entità a chunk semanticamente affini. Detto questo, va detto onestamente: molti sistemi GraphRAG production-grade saltano questa parte e usano solo embeddings testuali dei nomi e descrizioni delle entità. Il guadagno marginale di Node2Vec/GraphSAGE su un sistema già funzionante è spesso piccolo, e il costo implementativo è alto. È un trade-off ricerca-vs-pragmatismo, e per la maggior parte dei progetti il pragmatismo vince: parti senza, aggiungili solo se misuri un problema specifico che risolvono.

Tech stack — chi fa cosa nel 2026

Il panorama implementativo si è ormai settato in alcune famiglie di tecnologia, ognuna con un posizionamento riconoscibile.

Gli scogli — costi, drift, hallucinations, latenza

GraphRAG non è una bacchetta magica, e i suoi limiti vanno trattati con la stessa serietà dei suoi vantaggi. Quattro categorie di problemi meritano attenzione.

Costo di indexing

Già accennato: l'estrazione di entità/relazioni e la community summarization sono token-heavy. Un corpus medio (100k chunk) può costare €100–1000 di solo LLM in indexing, oltre al tempo (ore o giorni). Per corpora dinamici — memorie che crescono giorno per giorno — il re-indexing incrementale è un problema non banale: aggiungere un nuovo chunk potrebbe richiedere di riconsiderare entity resolution, community membership, community summary. Microsoft GraphRAG ha supporto incremental indexing dalla versione 0.3, ma è imperfetto: in pratica si combina un “delta layer” (nuove memorie indicizzate al volo) con un re-indexing batch periodico (settimanale o mensile) per consolidare. È una distinzione esattamente analoga a come funzionano gli indici in Postgres con HOT updates vs VACUUM FULL: piccoli aggiornamenti veloci, periodicamente compattati.

Stale graph e drift semantico

Le comunità e i loro summary sono snapshot temporali. Se nuove informazioni cambiano la struttura del grafo — un'azienda fa un'acquisizione che riassetta le relazioni industriali, un personaggio politico viene arrestato e cambia il suo ruolo, una persona cambia lavoro — il community summary basato sul vecchio grafo diventa stale. Esempio concreto in un sistema di personal memory: ti sei spostato di azienda, l'entità “il mio collega Tizio” adesso appartiene a un cluster diverso, ma il community summary che il sistema ha generato sei mesi fa lo colloca ancora nella vecchia azienda. La soluzione canonica è il full re-indexing periodico, che però è costoso; alcune pipeline ibride mantengono un delta layer sopra il grafo principale per cui le memorie recenti hanno priorità.

Hallucinated entities and relations

Gli LLM in estrazione non sono perfetti. Possono produrre entità che non esistono nel testo — “ha detto X” diventa X come PERSON anche se X è in realtà un'azienda — o relazioni inferite ma non esplicite nel testo: “Mario lavora ad Acme. Anna lavora ad Acme.” diventa (Mario, Anna, “sono colleghi”) anche se il testo non lo afferma direttamente. Quest'ultima è particolarmente insidiosa, perché spesso è vera — Mario e Anna probabilmente sono colleghi — ma il sistema l'ha inferita, non estratta. La differenza conta in domini sensibili: in legal, “probabilmente vero” non è “documentato”.

Mitigazioni: prompt più rigidi (“extract only what is explicitly stated; do not infer”), self-consistency check (estrarre due volte con seed diversi e confrontare), human-in-the-loop su entità di alta importanza, e marcatura esplicita di relazioni inferite vs estratte con un flag is_inferred usato dal retriever per pesarle diversamente.

Latenza al query time

Local search è ~2x più lento del RAG vettoriale, perché aggiunge graph traversal. Global search è 10–30x più lento, per via del map-reduce sui community report. Drift search è una via di mezzo. Per applicazioni real-time chat questo conta: se la query è globale e ci mette 15 secondi, l'utente percepisce il sistema come lento. Mitigazioni: caching delle risposte globali frequenti (le query globali tendono a ripetersi: “riassumi il mese” viene chiesta ogni mese), classificazione preventiva della query (un piccolo classificatore decide local vs global vs drift in 50ms, così non spendi sempre il costo della modalità più cara), streaming della risposta parziale così l'utente vede qualcosa subito.

E quindi: GraphRAG vale davvero la pena?

Le evaluation oneste sono difficili. Il paper Microsoft mostra vantaggi netti su query globali, ma su benchmark domain-specific i risultati sono più sfumati. Studi indipendenti suggeriscono che per il ~70% degli use case enterprise (Q&A, documentale standard, customer support, FAQ semantica), il RAG vettoriale ben fatto è competitivo a una frazione del costo. GraphRAG si distacca nettamente nei domini dove le relazioni sono il fulcro:

• Intelligence e investigative work — chi conosce chi, chi finanzia cosa, chi ha incontrato chi
• Biomed — relazioni gene-malattia-farmaco, pathway molecolari
• Legal — precedenti, norme, parti, citazioni incrociate
• Personal memory — relazioni persone-eventi-luoghi-emozioni-progetti
• Investigative journalism — Panama Papers, Pandora Papers, Suisse Secrets vivono di grafo

La regola pratica: se la domanda “qual è il vantaggio strutturale del grafo qui?” non ha una risposta concreta nei primi 60 secondi di analisi, probabilmente non sei in un dominio GraphRAG. Conviene, ma con consapevolezza dei costi e con scelte architetturali che li tengano sotto controllo.

Applicazioni reali — chi sta facendo cosa

Per ancorare la discussione, alcuni casi d'uso production-grade documentati, utili sia per ispirazione architetturale sia per poterli citare in un contesto di colloquio.

Microsoft Copilot e il Microsoft Graph

Microsoft 365 Copilot, quando interroga le sorgenti aziendali dell'utente, lavora sopra il “Microsoft Graph”: il grafo di documenti, email, calendar, contatti, conversazioni Teams. Il grafo è pre-esistente (non costruito da LLM: viene dalla struttura nativa delle relazioni in M365), ma la modalità di retrieval ibrido — entità + community + chunk testuali — è chiaramente ispirata al paper GraphRAG. È uno dei più grandi deployment graph-based al mondo, anche se Microsoft non chiama esplicitamente “GraphRAG” il sistema.

LinkedIn customer service

Pubblicato a EMNLP 2024 (Dong et al.), LinkedIn ha implementato un knowledge-graph-based RAG per il customer service interno: ticket storici trasformati in grafo con nodi problema, sintomo, soluzione, agente. Il risultato riportato è una riduzione del 28.6% del median time-to-resolution sui ticket. È uno dei pochi case study con numeri rigorosi pubblicati su peer-reviewed venue.

Investigative journalism — ICIJ e Bellingcat

Le grandi inchieste collaborative (Panama Papers, Pandora Papers, Suisse Secrets) lavorano da anni su grafi di entità — persone, aziende, conti offshore, transazioni. L'integrazione con LLM è recente: nel 2024 ICIJ ha sperimentato GraphRAG per permettere ai giornalisti di porre query in linguaggio naturale sopra il grafo. Tipo: “quali politici sono collegati indirettamente a aziende offshore attraverso almeno due intermediari, e quali di questi intermediari compaiono in più di tre casi diversi?”. È la quintessenza dell'use case multi-hop, e il RAG vettoriale non lo tocca.

Drug discovery — PrimeKG

Knowledge graph biomedico costruito da Harvard (Chandak, Huang, Zitnik, Nature Scientific Data 2023) con circa 4 milioni di relazioni tra geni, malattie, farmaci, pathway biologici. È un esempio in cui il grafo è stato curato manualmente da fonti strutturate (DrugBank, DisGeNET, ChEMBL), e poi un layer LLM è stato aggiunto sopra per permettere query in linguaggio naturale. Casi d'uso reali: drug repurposing — trovare farmaci esistenti potenzialmente utili per malattie nuove attraverso path nel grafo (es. “farmaci che agiscono su pathway X, dove X è coinvolto anche nella malattia Y”).

Legal — Harvey AI, CaseText

Sistemi che indicizzano giurisprudenza, normativa, contratti dei clienti. Le relazioni “questo caso cita quest'altro”, “questa norma è stata modificata da”, “questo contratto si rifà al template X” sono naturalmente grafiche. GraphRAG-style retrieval è diventato lo standard de facto per query del tipo: “tutti i casi in cui la Corte Suprema ha rivisto sentenze di un tribunale di appello su materia di privacy, negli ultimi cinque anni, citando il caso fondamentale Y”. Thomson Reuters ha acquisito CaseText per ~650M$ nel 2023 proprio per integrare queste capacità nel suo prodotto Westlaw.

Personal memory — Mem0, Letta, Pieces

L'area più vicina a use case personal. Mem0 nella sua versione graph espone esplicitamente un knowledge graph dell'utente: ogni interazione con un AI agent estrae fatti, preferenze, relazioni, e li deposita nel grafo. Letta (ex MemGPT) usa una memoria gerarchica core/archival con elementi grafici per gestire la dimensione finita del contesto LLM. Pieces è più orientato al code workflow e fa retrieval semantico + entità sui repository e snippet dell'utente. Sono tre punti di vista diversi sullo stesso problema — come costruisco una memoria personale persistente che un AI può interrogare — e tutti convergono, da angolazioni diverse, verso una qualche forma di GraphRAG.

Schema dati indicativo

Una bozza in pseudo-Cypher per Apache AGE, che dà un'idea concreta delle strutture in gioco in una pipeline GraphRAG production-grade:

-- Nodo entità
CREATE (e:Entity {
  id: 'ent_001',
  name: 'Francesco Gasparetto',
  type: 'PERSON',
  description: 'Founder ChipsBuilder, esperto blockchain',
  embedding: vector(1536),
  first_seen: '2025-08-01',
  memory_refs: ['mem_42', 'mem_138', 'mem_905']
})

-- Relazione tra entità (con provenance)
MATCH (a:Entity {id: 'ent_001'}), (b:Entity {id: 'ent_007'})
CREATE (a)-[r:RELATION {
  type: 'founded',
  description: 'ha fondato ChipsBuilder nel 2025',
  weight: 10,
  memory_refs: ['mem_42'],
  is_inferred: false
}]->(b)

-- Community summary (un nodo a sé con riferimenti ai membri)
CREATE (c:Community {
  id: 'comm_l1_017',
  level: 1,
  members: ['ent_001', 'ent_002', 'ent_007', ...],
  summary: 'Cluster relativo al business ChipsBuilder...',
  generated_at: '2026-05-24',
  generator: 'claude-sonnet-4-6'
})cypher

Notare tre dettagli che spesso saltano: embedding sul nodo (per local search via similarity sui nomi e descrizioni), memory_refs sia su entità che su relazioni (per provenance verso i chunk originali), e is_inferred sulla relazione (per distinguere fatti estratti letteralmente da fatti dedotti dall'LLM, che andranno pesati diversamente in retrieval).

Best practices e anti-pattern

Riferimenti essenziali

Per chi vuole scendere più in profondità, una bibliografia ragionata. L'ordine è dal più immediatamente utile (per implementare) al più accademico (per capire le fondamenta).

• Microsoft GraphRAG repository — github.com/microsoft/graphrag. L'implementazione di riferimento, MIT licensed.
• Edge, Trinh, Cheng, Bradley et al. — “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”, arXiv:2404.16130, aprile 2024. Il paper Microsoft. 12 pagine, leggibile in due ore, fa da manifesto al pattern.
• Traag, Waltman, van Eck — “From Louvain to Leiden: guaranteeing well-connected communities”, Scientific Reports 9, 5233 (2019). Spiega perché Leiden è meglio di Louvain.
• Guo, Lao, Hou et al. — “LightRAG: Simple and Fast Retrieval-Augmented Generation”, arXiv:2410.05779, ottobre 2024. La versione efficiente, con onesta discussione dei compromessi.
• Neo4j LLM Knowledge Graph Builder — github.com/neo4j-labs/llm-graph-builder. Anche se non userai Neo4j, il codice della pipeline è ben documentato.
• Apache AGE documentation — age.apache.org. Per chi sceglie lo stack Postgres-based.
• Dong et al. — “Retrieval-Augmented Generation with Knowledge Graphs for Customer Service Question Answering”, EMNLP 2024. Il case study LinkedIn, con numeri e ablation studies.
• Chandak, Huang, Zitnik — “Building a knowledge graph to enable precision medicine”, Nature Scientific Data 10, 67 (2023). PrimeKG, riferimento biomed.
• Christen, Peter — Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection. Springer, 2012. Il riferimento accademico su entity resolution.

Collegamento con altri temi

GraphRAG è un pezzo di un puzzle più grande. Per costruire sistemi reali:

• Parti dai fondamentali: RAG vettoriale — capire bene il punto di partenza prima del salto a grafo
• Tecniche di retrieval avanzato nel RAG Avanzato — reranking, HyDE, query rewriting
• Esporre il query layer come servizio standard con MCP
• Integrare il grafo in un sistema agentico con Orchestrazione di agenti
• Ottimizzare i prompt di estrazione e summarization in Prompt Engineering
• Vedi come ChipsBot integra retrieval e memoria nel caso studio