Guida GraphRAG: quando i knowledge graph battono il RAG vettoriale (e quando no)

Guida GraphRAG: quando i knowledge graph battono il RAG vettoriale (e quando no)

GraphRAG non è morto, ma non è nemmeno la scelta predefinita. microsoft/graphrag ha rilasciato la v3.1.1 il 2026-07-18 con 35.088 stelle su GitHub, e tre paper di benchmark del 2026 ormai dicono, apertamente, che spesso perde contro il semplice recupero vettoriale. Quindi questa guida a GraphRAG risponde all'unica domanda rimasta: un knowledge graph vale il conto dell'indicizzazione?

Conviene usare GraphRAG? La risposta breve

Usa GraphRAG quando le tue domande attraversano più entità o coprono l'intero corpus, come "a quali fornitori vende anche il nostro cliente più grande?". Resta sul RAG vanilla o ibrido per le ricerche fattuali a singolo hop, i documenti che cambiano spesso e i budget di latenza stretti. Il grafo ripaga il suo costo sulle domande multi-hop e perde denaro ovunque altrove.

GraphRAG non è morto e non è la scelta predefinita. Guadagna il suo conto di indicizzazione quando le domande sono multi-hop o globali sul corpus, e perde denaro quando non lo sono.

La versione breve:

• GraphRAG vince sulle domande multi-hop e sull'intero corpus; il RAG vanilla vince sulle ricerche a singolo hop.
• I benchmark 2026 sono contrastanti: i grafi aiutano l'aggregazione ma possono peggiorare la summarization fine.
• Il costo si paga in fase di indicizzazione, nelle chiamate LLM per l'estrazione, non al momento della query.
• Esegui Basic Search come controllo sul tuo corpus prima di costruire qualsiasi cosa.

Se hai già una pipeline RAG vettoriale funzionante, l'unica decisione è se un grafo sopra ripaghi il suo mantenimento. La tabella qui sotto è l'intero argomento in sei righe, e dove dice di restare sul vanilla, quella è la risposta onesta, più spesso di quanto i vendor ammettano. Il recupero ibrido BM25 più vettori copre la maggior parte di questi casi senza alcun grafo.

Cos'è davvero GraphRAG: dai chunk alle comunità

GraphRAG è una generazione aumentata dal recupero su un knowledge graph invece che su chunk scollegati. In fase di indicizzazione un LLM estrae entità e relazioni dai documenti, l'algoritmo Leiden raggruppa quelle entità in comunità, e ogni comunità riceve un riepilogo. Al momento della query, il grafo più quei riepiloghi rispondono a domande a cui una finestra top_k sui chunk non può strutturalmente rispondere.

La pipeline, da cima a fondo:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Due fasi fanno il lavoro. La fase di indicizzazione è quella costosa: ogni chunk richiede una chiamata LLM per estrarre entità e relazioni, e i riepiloghi di comunità richiedono altre chiamate sopra. La fase di query è dove si vede il guadagno. Poiché il grafo memorizza le relazioni in modo esplicito, una domanda come "a quali fornitori vende anche il nostro cliente più grande?" diventa un attraversamento invece della speranza che i due chunk giusti finiscano nella stessa finestra top_k.

I riepiloghi contano perché sono ciò che Global Search legge davvero: le domande sull'intero corpus ricevono risposta da prosa di comunità scritta in anticipo, non dai chunk grezzi. E ogni arco è una valutazione dell'LLM, memorizzata come tripla che potresti interrogare in Cypher su un vero database a grafo. Questo design è anche il motivo per cui l'indicizzazione domina il costo, e i numeri qui sotto lo rendono concreto.

La cornice che merita il suo posto: il RAG vanilla recupera passaggi, GraphRAG recupera struttura. La scelta del modello di embedding conta ancora per lo strato vettoriale, e il tuo vector database memorizza ancora le descrizioni, ma il grafo è il nuovo elemento portante. La documentazione Index Overview ufficiale descrive ogni fase per esteso.

Quali sono i quattro metodi di query di GraphRAG?

Il motore di query di GraphRAG fornisce quattro metodi: Local Search, Global Search, DRIFT Search e Basic Search. Local Search ragiona a partire da entità specifiche, Global Search aggrega i riepiloghi di comunità sull'intero corpus, DRIFT Search fonde i due in modo ricorsivo, e Basic Search è una semplice baseline vettoriale. Una quinta funzione, Question Generation, sta sopra il motore piuttosto che affiancarlo.

Abbiamo controllato la documentazione live su microsoft.github.io/graphrag/query/overview/ il 2026-07-30, e il conto è quattro. La maggior parte delle guide che si posizionano in SERP ne nomina due o tre. Lo stesso controllo ha trovato la parola "lazy" zero volte sia nella pagina Index Overview sia in quella Query Overview, e questo conta per la sezione sui costi qui sotto.

La riga che merita la tua attenzione è l'ultima. Basic Search è la baseline vettoriale vanilla integrata, ed esiste perché tu possa testare il grafo in A/B contro il semplice recupero sul tuo corpus e scoprire se il grafo sta ripagando il suo conto. Non è un dettaglio; è l'intera procedura decisionale di questa guida in una sola funzione. Esegui prima Basic Search. Se Local, Global o DRIFT Search non lo battono sulle domande che ricevi davvero, il grafo è un costo, non un miglioramento.

Cosa hanno scoperto davvero i benchmark 2026?

Tre paper di benchmark del 2026 trovano che GraphRAG aiuta nei compiti di aggregazione multi-hop e multi-fatto, ma altrove spesso fa peggio del RAG vanilla. Uno dei tre costruisce un benchmark apposta per trovare dove i grafi perdono. Tutti e tre concordano che la vittoria dipende dal tipo di domanda, non dalla dimensione del corpus. L'evidenza dice che GraphRAG è situazionale, non predefinito.

Un quarto lavoro, GraphRAG-Bench (repository), valuta nove metodi GraphRAG su 16 discipline e 20 libri di testo, e arriva alla stessa conclusione da un'angolazione più ampia.

Tutti e tre i paper convergono su un punto: il grafo guadagna il suo costo sull'aggregazione multi-hop e lo perde sul recall fine.

La nostra lettura: il ciclo di hype ha fatto il danno, e questi paper sono la correzione. Nessuno dice che i grafi sono inutili. Quello che dicono, con coerenza, è che il passo di aggregazione che rende GraphRAG bravo sui temi dell'intero corpus è lo stesso passo che sfuma il dettaglio fine. WildGraphBench è l'esempio più chiaro: i grafi hanno aiutato l'aggregazione multi-fatto da un numero moderato di fonti e hanno danneggiato la precisione della summarization nella stessa valutazione. Non è una contraddizione; è un unico meccanismo che si presenta due volte.

La conseguenza pratica è che non puoi deciderlo solo dalla letteratura. I paper ti dicono quali tipi di domanda testare, non se il tuo corpus è uno di quelli. A questo serve esattamente il controllo Basic Search della sezione sui metodi qui sopra.

Quanto costa GraphRAG? (E la svista su LazyGraphRAG che tutti ripetono male)

Il costo di GraphRAG è un conto in fase di indicizzazione, non al momento della query, ed è esattamente per questo che sorprende. Le chiamate LLM che estraggono entità e relazioni da ogni chunk, più il passaggio di summarization delle comunità, sono ciò che lo rende costoso. Paghi in anticipo, prima che venga eseguita una singola query. Il tempo di query è più economico ma non gratuito: Global Search si espande sui riepiloghi di comunità con una chiamata LLM per comunità, ed è il motivo per cui la tabella dei metodi qui sopra lo segna come alto.

Gli unici numeri pubblici e solidi arrivano da Microsoft Research. Il 2024-11-25 il team ha riportato che il costo di indicizzazione di LazyGraphRAG era identico al RAG vettoriale e pari allo 0,1% del costo di GraphRAG completo, e che al 4% del costo di query della global search di GraphRAG ha battuto i metodi concorrenti testati, sia sui tipi di query locali sia globali (Microsoft Research). Queste sono cifre di Microsoft, dal blog di Microsoft, e le riportiamo come tali; non abbiamo eseguito un'indicizzazione con prezzi nostri.

Ecco la correzione che la maggior parte degli articoli manca. LazyGraphRAG non è un'opzione installabile via pip. Secondo la nota dell'editor di Microsoft del 2025-06-06, è stato rilasciato in Microsoft Discovery e Azure Local, non nel pacchetto open source. Abbiamo controllato le pagine ufficiali Index Overview e Query Overview il 2026-07-30: la parola "lazy" compare zero volte in entrambe. Quindi se una guida elenca LazyGraphRAG come una variante che puoi avviare questo pomeriggio, sta ripetendo un'affermazione che ha smesso di essere vera nel mondo open source.

Cosa puoi fare oggi: eseguire il modello di estrazione in locale. Puntare il passo di indicizzazione a un modello locale via Ollama rimuove le tariffe API per token dalla fase più costosa, e abbinarlo a un vector store self-hosted mantiene il resto del conto vicino allo zero.

Quale libreria GraphRAG è davvero mantenuta?

Due delle sei librerie GraphRAG più citate non ricevono un push da sei e nove mesi. Abbiamo estratto queste cifre dalla GitHub API il 2026-07-30, e il censimento qui sotto è il controllo che le vecchie rassegne saltano, con il comando per ripeterlo prima di impegnarti su una. LightRAG e microsoft/graphrag sono quelle attive; nano-graphrag e fast-graphrag stanno scivolando verso l'abandonware.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

La nostra lettura: le stelle sono una metrica vanitosa; la data di push è il numero che conta. LightRAG e microsoft/graphrag sono entrambe mantenute attivamente, con Graphiti subito dietro sull'angolo del grafo temporale. nano-graphrag e fast-graphrag sono le due che i vecchi post raccomandano ancora per sola reputazione, e nessuna delle due rilascia da mezzo anno.

Come scegliere: prendi microsoft/graphrag se vuoi l'implementazione di riferimento con i quattro metodi di query ufficiali, LightRAG se vuoi il progetto più attivo e un'impronta più leggera, e una libreria mantenuta dal vendor come neo4j-graphrag-python se usi già il database di quel vendor. Evita qualsiasi cosa il cui ultimo push preceda il tuo progetto di mezzo anno.

Graphiti merita una nota circoscritta: il suo design a grafo temporale è costruito per il recupero su dati sensibili al tempo, e si sovrappone alla memoria degli agenti, che copriamo separatamente nella nostra guida su Graphiti e la memoria a grafo temporale. Per il campo più ampio, vedi il panorama degli strumenti RAG.

Cosa si rompe dopo il giorno 200: graph drift e ri-estrazione

Il graph drift è la tassa che paghi dopo il lancio, ed è l'obiezione numero uno dei practitioner per un buon motivo. Ogni tutorial tratta il grafo come una cosa che costruisci una volta. I team reali si bloccano al giorno 200.

Tre cose decadono. Primo, la reindicizzazione sugli aggiornamenti dei documenti. Quando 40 documenti cambiano, non puoi rigenerare solo gli embedding; devi rieseguire l'estrazione LLM sui chunk modificati, riconciliare le nuove entità con il vecchio grafo e ricalcolare le comunità interessate e i loro riepiloghi. Una guida su Medium definisce facile l'aggiornamento incrementale. I practitioner su r/Rag non sono d'accordo. L'OP di un thread del 2026-04-25 che gira BM25 più BGE-M3 su circa 600 documenti la mette in modo netto: "L'estrazione LLM di entità/relazioni è rumorosa, e la reindicizzazione sugli aggiornamenti dei documenti sembra dolorosa."

Secondo, il decadimento della risoluzione delle entità. "Acme Corp", "Acme" e "ACME Corporation" arrivano in documenti diversi a mesi di distanza e si dividono in tre nodi che dovrebbero essere uno. Niente li fonde automaticamente.

Terzo, relazioni che erano vere al momento dell'estrazione e smettono silenziosamente di esserlo. Nessuno riceve un avviso quando un arco reports_to diventa obsoleto.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Un codebase è il caso peggiore, e il più interessante. L'autocompletamento ora suggerisce "graphrag for codebase", "graphrag claude code" e "graphrag mcp server", e un codebase è un grafo che cambia ogni ora: ogni commit riscrive gli archi di chiamata, sposta simboli ed elimina funzioni. Questo è graph drift con una cadenza che nessuna reindicizzazione notturna riesce a seguire del tutto. È anche il motivo per cui gli strumenti seri per i grafi di codice si appoggiano a parser deterministici come tree-sitter e LSP per gli archi, e riservano l'LLM alla prosa intorno: docstring, messaggi di commit, thread di review. Se stai mettendo a grafo un repository, metti a grafo lo strato lento con l'LLM e quello veloce con un parser.

Cosa dicono davvero gli sviluppatori di GraphRAG?

Gli sviluppatori sul campo sono divisi, e Google sembra saperlo: un thread di Reddit si posiziona al secondo posto su "graphrag vs rag", che è il motore di ricerca che ti dice che questo argomento vuole opinioni tra pari, non testi dei vendor.

Lo scetticismo è reale. Sul thread di r/Rag del 2024 "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 punti, 86% di upvote), u/EncartaIt ha scritto: "Tutti i tutorial che ho trovato sono troppo semplicistici e non sostengono davvero con forza il pattern del knowledge graph." u/Prestigious_Run_4049 è stato più diretto: "Penso che graph rag sia solo hype. Alla gente piace parlarne e suona bene, ma nessuno lo usa davvero in casi d'uso reali." Non tutti concordano. u/pytheryx, argomentando dalla produzione, ha notato che il recupero a grafo vince sulle domande a lista che richiedono contesto da più chunk di quanti top_k ne restituisca; il suo corpus di whitepaper richiede circa 50 chunk per una risposta completa.

Il thread del 2026 è più misurato. u/Popular_Sand2773: "La maggior parte dei setup graph rag bara e basta su scala. Esegui una ricerca vettoriale o per metadati standard per trovare i nodi seme e poi cammini intorno." u/ggone20, che gestisce un sistema da circa 300 milioni di artefatti: "Su scala, senza di loro non puoi letteralmente rispondere alle domande vere."

La nostra lettura combacia con l'argomento più affilato di entrambi i thread: il punto di svolta è la complessità delle tue domande, non la dimensione del corpus. È anche ciò che i benchmark qui sopra hanno trovato, ed è il motivo per cui ci schieriamo con i practitioner che limitano lo strumento al lavoro multi-hop piuttosto che con quelli che lo danno per morto.

L'approccio di Techsy

Ecco la sequenza che usiamo sui progetti per i clienti, ed è deliberatamente noiosa.

Primo, dimostra il soffitto del recupero ibrido. La maggior parte delle richieste "ci serve un grafo" che sentiamo sono in realtà un problema di chunking o di reranking mascherato. Una pipeline BM25 più vettori con un reranker decente risponde a più domande di quanto i team si aspettino.

Secondo, esegui Basic Search come controllo sul tuo corpus prima di costruire qualsiasi cosa. È esattamente a questo che serve il quarto metodo di query: una baseline vettoriale semplice contro cui testare il grafo in A/B, sui tuoi dati, con le tue domande.

Terzo, costruisci il grafo solo quando una classe misurata di domande fallisce quel controllo. Se le query multi-hop o sull'intero corpus sbagliano, hai un caso reale. Se non sbagliano, ti sei appena risparmiato un conto di indicizzazione e un problema di drift.

Vuoi un secondo paio di occhi sul tuo stack di recupero? Richiedi una consulenza gratuita.

Domande frequenti

Come funziona GraphRAG?

GraphRAG indicizza i tuoi documenti in un knowledge graph. Un LLM estrae entità e relazioni da ogni chunk, l'algoritmo Leiden raggruppa quelle entità in comunità, e ogni comunità riceve un riepilogo. Al momento della query il motore cerca nel grafo e in quei riepiloghi, così può collegare fatti che stanno in chunk diversi.

In cosa GraphRAG è diverso dal RAG?

Il RAG standard recupera i top-k chunk più simili e li passa al modello. GraphRAG recupera struttura: entità, le relazioni tra loro e riepiloghi di comunità scritti in anticipo. Quella struttura extra è ciò che gli permette di rispondere alle domande multi-hop e sull'intero corpus, ed è anche ciò che rende l'indicizzazione più lenta e costosa.

Quando dovrei usare GraphRAG?

Usalo quando le tue domande attraversano entità o coprono l'intero corpus, come le domande su fornitori in comune o l'analisi di temi ricorrenti su migliaia di documenti. Saltalo per le ricerche fattuali a singolo hop, i corpus che cambiano spesso e i budget stretti di latenza o costo. Se una pipeline ibrida semplice risponde già a una classe di domande, il grafo aggiunge costo senza aggiungere valore.

GraphRAG è morto?

No, ma non è nemmeno la scelta predefinita. I benchmark 2026 mostrano che spesso fa peggio del RAG vanilla sui compiti ordinari, e questo ha ucciso l'hype, pur vincendo ancora sulle domande multi-hop e di aggregazione. La cornice onesta è situazionale: GraphRAG guadagna il suo costo per i tipi di domanda giusti e perde denaro per il resto.

Quali sono i metodi di query di GraphRAG?

Il motore di query ufficiale ne fornisce quattro: Local Search per le domande centrate su un'entità, Global Search per l'aggregazione sull'intero corpus, DRIFT Search per una fusione ricorsiva di entrambi, e Basic Search per il semplice recupero vettoriale. Una quinta funzione, Question Generation, sta sopra. Basic Search conta più di tutti: è il controllo contro cui testi il grafo in A/B.

Quanto costa l'indicizzazione di GraphRAG?

Il costo cade in fase di indicizzazione, nelle chiamate LLM che estraggono entità e relazioni da ogni chunk più la summarization delle comunità. Microsoft Research ha riportato l'indicizzazione di LazyGraphRAG allo 0,1% del costo di GraphRAG completo e identica al RAG vettoriale, ma quella variante è arrivata nei prodotti Microsoft, non nella libreria open source. Non abbiamo eseguito un'indicizzazione con prezzi nostri.

Posso eseguire GraphRAG in locale con Ollama?

Sì. La libreria microsoft/graphrag ti permette di puntare indicizzazione e query a un modello locale servito da Ollama, il che rimuove le tariffe API per token dal passo di estrazione. Baratti velocità e qualità con il costo: i modelli locali sono più deboli nell'estrazione di entità, quindi aspettati grafi più rumorosi e indicizzazioni più lunghe su hardware modesto.

Meglio LightRAG o Microsoft GraphRAG?

Ottimizzano per cose diverse. LightRAG (38.353 stelle, push il 2026-07-30) è la più attiva e più leggera da eseguire; microsoft/graphrag (35.088 stelle, v3.1.1) è l'implementazione di riferimento con i quattro metodi di query ufficiali. Scegli LightRAG per un grafo di produzione efficiente, quella di Microsoft per un comportamento fedele alla specifica e per il controllo Basic Search.

Chi ha creato GraphRAG e quando?

Microsoft Research ha creato GraphRAG. Il team ha pubblicato il paper nel 2024 e mantiene il repository open source microsoft/graphrag sotto licenza MIT, con documentazione su microsoft.github.io/graphrag. La libreria di riferimento ha raggiunto la v3.1.1 il 2026-07-18, e intorno è cresciuto un ecosistema attivo di implementazioni di terze parti, tra cui LightRAG e Graphiti.

Il verdetto: quando un grafo guadagna il suo costo

L'evidenza punta in una direzione, quindi ecco la posizione.

• GraphRAG non è morto. È situazionale, e i benchmark 2026 lo dicono apertamente.
• Guadagna il suo conto di indicizzazione sulle domande multi-hop tra entità e sull'aggregazione dell'intero corpus. Perde denaro sulle ricerche a singolo hop.
• Il costo è un conto in fase di indicizzazione, e la variante economica che tutti citano, LazyGraphRAG, non è mai arrivata nella libreria open source.
• Il grafo decade dopo il lancio: la risoluzione delle entità va alla deriva e le relazioni diventano obsolete, quindi metti in budget la reindicizzazione.
• Esegui Basic Search come controllo sul tuo corpus prima di costruire qualsiasi cosa.

In una frase: un knowledge graph guadagna il suo costo quando le tue domande sono multi-hop o globali sul corpus, e non prima. Se vuoi una seconda opinione sul tuo stack di recupero, richiedi una consulenza gratuita.