GraphRAG: come funziona e quando vale la pena usarlo

Documentazione verificata il 26 ottobre 2026, consultando la documentazione di Microsoft GraphRAG, il relativo repository e la documentazione di Neo4j e LlamaIndex. Il confronto che segue analizza i meccanismi descritti nella documentazione: non è un test delle prestazioni. Gli esempi sul feedback di prodotto hanno scopo illustrativo.

Che cos'è GraphRAG?

Microsoft GraphRAG prepara una visione d'insieme della raccolta prima ancora che qualcuno la richieda. Usa un modello linguistico di grandi dimensioni, o LLM, per estrarre entità e relazioni dai documenti, raggruppa le entità collegate in comunità e genera una sintesi per ciascuna comunità. Il motore di interrogazione può poi usare queste strutture per rispondere alle domande. La panoramica di Microsoft descrive il metodo e le principali modalità di recupero delle informazioni.

Un'entità è un elemento identificato per nome nei dati, come un cliente, un prodotto, una persona o un progetto. Una relazione collega le entità: un cliente usa un prodotto, un progetto dipende da un servizio. Insieme formano un grafo di conoscenza. Una comunità è un gruppo di entità collegate; la sua sintesi descrive ciò che accade in quella parte della raccolta.

Immaginiamo la raccolta di documenti come un campus. La ricerca vettoriale trova le stanze il cui contenuto assomiglia alla domanda. Le relazioni del grafo collegano le stanze. Le sintesi delle comunità offrono una vista d'insieme dalle passerelle dei piani superiori. Quando la domanda riguarda ciò che succede in tutto il campus, selezionare poche stanze simili può lasciare fuori intere ali.

È questo il problema alla base di un errore familiare: un'applicazione di retrieval-augmented generation, che fornisce al modello le evidenze recuperate prima della risposta, trova correttamente la policy sulle esportazioni, ma risponde in modo superficiale a «Che cosa frustra i clienti nell'insieme di queste interviste?». La seconda domanda richiede di coprire tutta la raccolta. Potrebbe non esistere alcun passaggio che contenga direttamente la risposta.

«Graph RAG» indica anche una famiglia più ampia di sistemi di recupero delle informazioni basati sui grafi. Questo articolo si concentra sull'implementazione di Microsoft. Un'applicazione che usa un grafo tramite un altro framework non genera automaticamente i report di comunità di Microsoft, né adotta il suo metodo di ricerca globale.

Come funziona GraphRAG?

Il cambiamento principale avviene durante l'indicizzazione: GraphRAG crea descrizioni derivate dai dati, che le interrogazioni successive possono riutilizzare. Il metodo di indicizzazione standard di Microsoft usa gli LLM per estrarre e sintetizzare le informazioni, mentre il clustering del grafo definisce la struttura delle comunità.

Il processo segue una sequenza di passaggi, ciascuno dipendente dai precedenti:

1. Suddividere i documenti in unità di testo. Sono porzioni del testo originale, dette chunk. I collegamenti ai documenti di origine permettono di risalire alla fonte di ogni elemento estratto.
2. Estrarre entità e relazioni. L'LLM legge ogni unità di testo e descrive le entità e i collegamenti che individua.
3. Consolidare il grafo. Le descrizioni di entità e relazioni corrispondenti vengono unite e sintetizzate. Le regole di unione documentate usano il titolo e il tipo dell'entità e i nodi di origine e destinazione della relazione.
4. Individuare le comunità. Hierarchical Leiden, un algoritmo di clustering dei grafi, raggruppa le entità collegate a diversi livelli di dettaglio.
5. Generare report di comunità ed embedding. L'LLM sintetizza le comunità. Per gli artefatti su cui si effettuano ricerche vengono generati anche embedding, rappresentazioni numeriche usate per la ricerca per similarità.

Questi passaggi seguono il flusso di indicizzazione di Microsoft. L'estrazione delle affermazioni è un flusso aggiuntivo facoltativo, disattivato per impostazione predefinita. Non è necessario estrarre le affermazioni per costruire il grafo e i report standard.

In una raccolta di feedback di prodotto, un'intervista potrebbe menzionare il progetto Atlas, errori di esportazione e un processo di approvazione. Un'altra conversazione potrebbe collegare Atlas a uno spazio di lavoro condiviso. Se l'estrazione coglie questi legami, i report di comunità possono riunire problemi correlati anche quando i documenti usano parole diverse.

Qui emerge anche il punto debole. Se l'estrazione perde una relazione, unisce entità diverse o tiene separati alias che dovrebbero riferirsi alla stessa entità, le sintesi successive ereditano quella struttura distorta. Anche un grafo ben collegato resta un'interpretazione del testo.

Microsoft salva gli output predefiniti dell'indice in tabelle Parquet, un formato di file orientato alle colonne, e scrive gli embedding nell'archivio vettoriale configurato. Questa organizzazione predefinita non richiede un database a grafo separato. Panoramica dell'indicizzazione.

Le modalità di ricerca Global, Local, DRIFT e Basic

La modalità di interrogazione va scelta in base alle evidenze necessarie per rispondere. La ricerca globale affronta gli schemi ricorrenti nell'intera raccolta; quella locale parte dalle entità pertinenti. Le altre modalità consentono un'esplorazione più ampia oppure offrono una base di confronto vettoriale.

Ricerca globale: i temi dell'intera raccolta

La ricerca globale è il motivo principale per valutare Microsoft GraphRAG quando la domanda è «Quali sono i temi principali in tutti questi documenti?». Usa come materiale per la risposta i report di comunità di un livello scelto della gerarchia.

Il metodo è map-reduce: elabora separatamente gruppi di report, poi ne combina i risultati. Nella fase map, ogni gruppo produce risposte parziali con punti a cui viene assegnato un punteggio. La fase reduce seleziona i punti utili e li trasforma in una risposta finale. Report di comunità più dettagliati possono aumentare sia il dettaglio della risposta sia le risorse necessarie. Documentazione della ricerca globale.

Per un responsabile di prodotto che esamina il feedback dei clienti, il beneficio atteso è una copertura più ampia: onboarding, approvazioni e collaborazione potrebbero contribuire tutti alla risposta. Aumentare semplicemente il numero di passaggi simili recuperati non garantisce che questi ambiti diversi siano rappresentati.

Il limite va tenuto presente: la ricerca globale sintetizza report. Non conta con esattezza quanti clienti abbiano menzionato ciascun problema. Se la decisione richiede una classifica per frequenza, serve una procedura di conteggio con unità esplicite e deduplicazione; il modello potrà poi spiegare i risultati.

Ricerca locale: un'entità e ciò che la circonda

La ricerca locale è adatta a domande come «In che modo il progetto Atlas è collegato ai problemi di esportazione?». Individua entità semanticamente affini, raccoglie le informazioni collegate nel grafo e i passaggi delle fonti associati, poi filtra il materiale per farlo rientrare nella finestra di contesto della risposta. Documentazione della ricerca locale.

È utile quando la risposta dipende da relazioni distribuite tra più documenti. Il grafo fornisce punti di accesso e collegamenti; i passaggi originali offrono i dettagli a sostegno. La ricerca locale continua a usare corrispondenze per similarità e un contesto limitato, quindi non può garantire che emergano tutte le relazioni pertinenti.

Ricerca DRIFT: esplorare partendo dal quadro generale

DRIFT parte dalle informazioni di comunità pertinenti e sviluppa domande di approfondimento che ricorrono alla ricerca locale. È adatto alle domande esplorative, in cui una prima risposta generale fa emergere filoni di indagine più specifici. Documentazione di DRIFT.

Per esempio, «Perché questi clienti faticano a collaborare?» potrebbe portare a indagini distinte su approvazioni, responsabilità condivise e passaggi di consegne legati alle esportazioni. Prima di impostare DRIFT come modalità predefinita per le domande abituali, va verificato se queste ricerche aggiuntive portano alla luce evidenze utili.

Ricerca Basic: mantenere una base di confronto

La ricerca Basic recupera chunk di testo simili tramite ricerca vettoriale. Microsoft la include per facilitare il confronto tra le modalità di interrogazione. È un riferimento utile per una domanda circoscritta come «Che cosa prevede la policy sulle esportazioni?». Documentazione del motore di interrogazione.

GraphRAG vs RAG: confrontare domande e indici

Conviene mantenere l'approccio di recupero più semplice che risponde alla domanda in modo affidabile. Il confronto seguente distingue l'adeguatezza alla domanda, il lavoro di indicizzazione e la manutenzione. Sono valutazioni architetturali, non classifiche di costi o velocità misurati.

La ricerca ibrida risolve un problema diverso dalla sintesi globale. La documentazione di Microsoft sulla ricerca ibrida descrive come combinare risultati full-text e vettoriali. Se l'applicazione non trova un codice prodotto esatto, conviene partire dalla ricerca ibrida. Una sintesi globale delle comunità è una soluzione indiretta a un problema di recupero lessicale.

Il RAG agentico modifica il flusso di ricerca. Un modello può scegliere di recuperare informazioni, valutarne la pertinenza, riscrivere la domanda e cercare di nuovo, come mostra il tutorial di LangGraph sul recupero agentico. Il RAG agentico serve quando l'applicazione deve decidere quali evidenze raccogliere nel passaggio successivo.

Questi approcci si possono combinare. Un agente può chiamare un retriever basato su grafo, e un retriever basato su grafo può partire da una ricerca ibrida. La decisione riguarda quale meccanismo aggiuntivo risolva un errore osservato. Introdurli tutti insieme rende più difficile stabilirlo.

Perché l'indicizzazione di GraphRAG richiede più lavoro

GraphRAG standard aggiunge elaborazione generativa al lavoro sugli embedding di un semplice indice vettoriale. Non esiste un moltiplicatore universale attendibile da applicare al numero di documenti: il lavoro dipende dal testo, dalla configurazione dell'estrazione, dal grafo e dai report generati.

Un modello utile per pianificare il lavoro è:

Lavoro di indicizzazione = elaborazione dei chunk + passaggi di estrazione + sintesi delle descrizioni + report di comunità + embedding.

È un modello per contabilizzare il lavoro del progetto pilota, non una formula di prezzo del fornitore. Misurare ogni fase permette di capire che cosa cresce quando si aggiungono dati.

I chunk determinano il lavoro di estrazione ripetuto. Più chunk significano più unità di testo da analizzare. Dimensioni e sovrapposizione dei chunk modificano la quantità di contesto ripetuto che l'estrattore vede. La configurazione di Microsoft espone anche max_gleanings, che controlla i cicli di estrazione aggiuntivi. Non va dato per scontato che ogni chunk richieda sempre esattamente una chiamata all'LLM. Riferimento della configurazione.

Le dimensioni del grafo determinano il materiale da elaborare a valle. Una raccolta con molte entità e relazioni distinte può produrre più descrizioni da consolidare rispetto a una raccolta di dimensioni simili su un argomento circoscritto. Le menzioni ripetute generano descrizioni da unire; la varietà dei collegamenti dà forma alle comunità per cui servono report. Questo dipende dalle fasi di estrazione e sintesi, non soltanto dal numero di documenti.

I report aggiungono un altro carico di generazione. I contenuti delle comunità devono essere sintetizzati e la gerarchia crea diversi livelli di visione d'insieme. Anche gli embedding restano parte dell'indice. L'elenco delle attività del metodo standard è il punto di partenza adatto per individuare questi fattori.

Riutilizzare la cache può evitare di ripetere il lavoro del modello. Microsoft memorizza nella cache i risultati delle chiamate all'LLM per le indicizzazioni successive. La costruzione da zero e un aggiornamento vanno misurati separatamente: una riesecuzione che usa la cache non indica quanto lavoro richiederà una nuova raccolta. Configurazione della cache.

Il lavoro al momento dell'interrogazione richiede un budget separato. Il map-reduce globale e l'esplorazione DRIFT possono comportare più operazioni del modello dopo il completamento dell'indicizzazione. Un progetto pilota riuscito sul fronte dell'indicizzazione non dimostra che i tempi di risposta siano accettabili.

Documenti aggiornati, sintesi ancora obsolete

L'arrivo di un documento nell'archivio non aggiorna automaticamente i report usati dalla ricerca globale. L'obiettivo di aggiornamento deve riguardare l'indice derivato che l'interrogazione legge davvero.

Microsoft mette a disposizione graphrag update; la CLI attuale indica che, per impostazione predefinita, il nuovo indice viene scritto in update_output. La configurazione prevede anche uno spazio di archiviazione separato per gli aggiornamenti, così da preservare gli output esistenti. L'aggiornamento incrementale esiste, quindi, ma un comando di aggiornamento da solo non costituisce una politica di sincronizzazione completa. Riferimento della CLI, archiviazione degli aggiornamenti.

Consideriamo una conversazione con l'assistenza che corregge una precedente affermazione su Atlas. Il nuovo documento potrebbe essere presente mentre un report di comunità in uso descrive ancora la situazione precedente. È un problema di manutenzione, anche se una ricerca diretta riesce a trovare la correzione.

Aggiunte, correzioni ed eliminazioni vanno testate sulla versione e sulla configurazione effettivamente distribuite. Occorre controllare i chunk delle fonti, le relazioni estratte e le risposte sia locali sia globali. La documentazione della CLI citata non dimostra che ogni modifica si propaghi automaticamente con gli effetti richiesti dall'applicazione.

Per chi gestisce il sistema, il requisito pratico è avere una versione dell'indice visibile e sapere fino a quale momento sono aggiornate le fonti incluse. Si pubblica un insieme coerente di artefatti e si indirizzano le interrogazioni a quella versione. Se l'attività richiede risposte immediate su dati che cambiano rapidamente, conviene mantenere disponibile un percorso di recupero diretto mentre si valuta il processo di aggiornamento dei report.

Altre due strade per il RAG con grafi

Neo4j e LlamaIndex offrono componenti per il recupero tramite grafi, con scelte diverse su estrazione, archiviazione e interrogazione. Va valutato il meccanismo descritto nella rispettiva documentazione, senza trattare «GraphRAG» come un unico prodotto intercambiabile.

GraphRAG con Neo4j

Neo4j GraphRAG for Python include VectorCypherRetriever: prima individua nodi simili, poi esegue una query di recupero per raccogliere ulteriore contesto. Cypher è il linguaggio di interrogazione dei grafi di Neo4j. Il pacchetto offre anche il recupero ibrido tramite indici vettoriali e full-text, oltre a Text2Cypher per tradurre una domanda in una query sul database. Guida ai retriever di Neo4j.

Questa strada è adatta a chi sviluppa e vuole controllare esplicitamente quali relazioni seguire dopo aver individuato un nodo pertinente. Per esempio, recuperare un progetto e poi le dipendenze a esso collegate tramite una query sul grafo definita in anticipo.

Gli strumenti di Neo4j per costruire il grafo supportano anche l'estrazione di entità e relazioni tramite LLM, la scrittura del grafo e la risoluzione delle entità duplicate. La documentazione descrive una gestione degli errori di estrazione che può ignorare i chunk non elaborati correttamente, salvo diversa configurazione. Va verificata la completezza dell'acquisizione dei dati, oltre al corretto funzionamento della query. Guida a Knowledge Graph Builder.

Il limite: una ricerca vettoriale seguita da una query sul grafo non produce, da sola, la gerarchia di report di comunità di Microsoft. Se servono sintesi tematiche ampie, bisogna specificare come costruire quel livello.

I grafi di proprietà di LlamaIndex

Il PropertyGraphIndex di LlamaIndex orchestra la costruzione del grafo e il recupero delle informazioni. Un grafo di proprietà contiene entità dotate di etichette, i loro attributi e le loro relazioni. Gli estrattori lavorano sui chunk; SchemaLLMPathExtractor può limitare l'estrazione agli schemi di entità e relazioni consentiti. VectorContextRetriever individua i nodi del grafo rappresentati tramite embedding e recupera i percorsi collegati, con il testo originale disponibile tramite le opzioni di recupero. Guida ai grafi di proprietà.

Questa strada è adatta a chi vuole estrattori e retriever configurabili all'interno di un framework applicativo. Le operazioni documentate di inserimento, upsert ed eliminazione forniscono componenti per mantenere il grafo; l'applicazione ha comunque bisogno di una politica per le modifiche alle fonti e ai fatti derivati.

Il limite: le operazioni disponibili dipendono dall'archivio del grafo. Il SimplePropertyGraphStore predefinito non è un database a grafo e non supporta Cypher. Archiviazione e recupero vanno scelti insieme. Inoltre, non bisogna dare per scontato che un indice a grafo di proprietà includa il flusso di sintesi globale di Microsoft.

Tutorial GraphRAG: partire dal problema da risolvere

Si parte da una raccolta circoscritta e da domande le cui risposte siano verificabili. Il repository di Microsoft avverte che l'indicizzazione può essere costosa, e la guida introduttiva consiglia di fare esperienza su un piccolo dataset prima di avviare un lavoro su larga scala.

Una volta configurati l'ambiente di lavoro e le credenziali, questi comandi usano la sintassi attualmente documentata della CLI:

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

La query è un argomento posizionale nel riferimento attuale della CLI.

L'output va giudicato valutando insieme copertura e riscontri nelle fonti. Una risposta che elenca più temi ma inventa collegamenti non ha risolto il problema. Chi revisiona deve poter ricondurre ogni tema importante alle evidenze, annotare quali temi attesi mancano e verificare se gruppi distinti siano stati accorpati in una generalizzazione di comodo.

Chi sviluppa dovrebbe adottare il grafo solo se risolve la categoria di domande problematica, mantenendo accettabile il comportamento delle ricerche puntuali. Chi gestisce il sistema deve esigere una procedura di aggiornamento che regga a correzioni ed eliminazioni. Chi commissiona un sistema dovrebbe chiedere le stesse dimostrazioni su documenti rappresentativi, prima di accettare una visualizzazione del grafo come prova di risposte migliori.

Se le evidenze sono già presenti ma il modello continua a usare il formato o il comportamento sbagliato, conviene riconsiderare il confronto tra RAG e fine tuning. Un indice più elaborato interviene sull'accesso alle evidenze; non è automaticamente la soluzione adatta a ogni errore di generazione.

Quali promesse vanno ridimensionate?

L'affermazione più solida è più circoscritta di «i grafi migliorano il RAG»: un certo grafo, insieme a un certo metodo di interrogazione, può migliorare un determinato tipo di raccolta delle evidenze.

I collegamenti non certificano la verità. Le relazioni estratte e i report di comunità possono essere errati. Vanno trattati come interpretazioni su cui effettuare ricerche, conservando la possibilità di risalire alle fonti. Un percorso nel grafo può rendere il recupero più facile da ispezionare senza dimostrare che l'affermazione sottostante sia corretta.

Risposte con più collegamenti non sono necessariamente più complete. Una sintesi apparentemente ampia può comunque omettere un problema isolato. Nel campione da revisionare vanno inclusi temi minoritari ed eccezioni difficili da inquadrare, soprattutto se possono cambiare una decisione di prodotto.

Una sintesi di comunità non è una tabella di frequenza. Menzioni ripetute, connettività delle entità e valutazione dell'importanza da parte di un modello sono cose diverse dal conteggio dei clienti distinti. Prima di affermare che un tema sia il più comune, occorre definire l'unità di analisi.

Il repository non è un servizio gestito da Microsoft. Le indicazioni di Microsoft sul repository descrivono il codice come una dimostrazione della metodologia, non come un'offerta ufficialmente supportata da Microsoft. Distribuzione, monitoraggio e aggiornamento dei dati richiedono comunque un responsabile.

Domande frequenti su GraphRAG

Da dove partire la prossima settimana

Si parte dalla domanda tematica a cui l'applicazione risponde male e si individuano le evidenze che una buona risposta dovrebbe raccogliere nell'intero corpus. Intorno a quel problema si costruisce una piccola valutazione di GraphRAG, mantenendo il retriever esistente come riferimento.

Conviene procedere se la sintesi dell'intera raccolta è un requisito ricorrente del prodotto e qualcuno può assumersi la responsabilità dell'indice derivato. Meglio attendere se il corpus cambia più rapidamente di quanto si riescano a validare i report, oppure se nessuno può giudicare la completezza di una risposta tematica. Se il carico di lavoro consiste soprattutto in ricerche fattuali già affidabili, conviene mantenere l'architettura attuale. Il risultato utile è una decisione motivata sul recupero delle informazioni, indipendentemente dal fatto che il grafo rimanga.

Per guide pratiche alla realizzazione di sistemi di IA, iscriviti alla newsletter.