GraphRAG — Microsoft Estende RAG con Knowledge Graph per Query Globali

Cos'è: GraphRAG è un'architettura di Retrieval-Augmented Generation pubblicata da Microsoft Research a febbraio 2024 (post blog) e open-sourced a luglio 2024 sul GitHub microsoft/graphrag. Risolve un limite specifico del RAG naive: l'incapacità di rispondere a "query globali" che richiedono comprensione del corpus nel suo insieme (tema, narrativa dominante, pattern trasversali). La soluzione: un LLM estrae entità e relazioni dal corpus costruendo un knowledge graph, l'algoritmo di community detection di Leiden lo partiziona gerarchicamente, e per ogni comunità a ogni livello viene generato un summary. Al query time, le domande "locali" vengono indirizzate alla retrieval semantica classica, quelle "globali" ai summary di livello alto. È 10-100x più costoso del RAG naive in fase di indexing, ma sblocca casi d'uso prima impossibili.

Il fallimento del RAG naive sulle query globali

Il RAG standard (Lewis et al., Meta, 2020) funziona così: si chunkizza il corpus in passaggi da 200-500 token, si embedda ogni chunk con un modello di sentence embedding, si memorizzano gli embedding in un vector store, al query time si calcola l'embedding della domanda e si recuperano i top-k chunk più simili (cosine similarity), che vengono inseriti nel prompt del LLM. Sulle "query locali" — domande la cui risposta sta in uno o pochi passaggi specifici del corpus — questa pipeline funziona molto bene: "qual è il nome del CEO citato nel rapporto?", "in che anno è successo X?".

Su un altro tipo di domanda, però, il RAG naive crolla. Microsoft Research le chiama "query globali" o "sense-making questions": "qual è il tema dominante in questi 200 documenti?", "quali sono le tensioni principali nel dataset?", "come si è evoluto il messaggio nel tempo?". Per rispondere serve sintetizzare informazione distribuita sull'intero corpus, non recuperare passaggi isolati. Il vector retrieval restituisce 10 chunk a caso più o meno semanticamente vicini alla query — non danno mai una visione d'insieme, e il LLM riceve un quadro fatalmente parziale.

L'osservazione chiave del paper è che questo non è un problema risolvibile aumentando k, il numero di chunk recuperati. Aumentando k a 100 si saturano i context window ma si dilata anche il rumore: il LLM viene sommerso da passaggi parzialmente rilevanti e produce risposte vaghe o contraddittorie. Il problema è strutturale: il RAG naive non ha alcuna rappresentazione esplicita della struttura del corpus.

Pipeline di indexing: estrazione, grafo, comunità, summary

GraphRAG sposta il lavoro pesante all'indexing time, costruendo una rappresentazione strutturata del corpus in più passi. Primo, estrazione di entità e relazioni: ogni chunk viene passato a un LLM con un prompt che gli chiede di identificare entità (persone, organizzazioni, luoghi, concetti) e relazioni esplicite tra di esse, restituendo un oggetto strutturato. Microsoft suggerisce GPT-4 o GPT-4-Turbo per questa fase per qualità di estrazione. Il risultato è un grande grafo eterogeneo con migliaia o centinaia di migliaia di nodi.

Secondo, community detection: si applica l'algoritmo Leiden (Traag et al., 2019, miglioramento del classico Louvain) per partizionare gerarchicamente il grafo in comunità coese. Leiden produce una gerarchia multi-livello: a livello 0 ogni nodo è una comunità, a livelli più alti le comunità si raggruppano. Una comunità è un sottoinsieme di entità densamente connesse tra loro — corrisponde intuitivamente a un "tema" o "sotto-narrativa" del corpus.

Terzo, community summarization: per ogni comunità a ogni livello, un LLM genera un summary in linguaggio naturale che descrive il contenuto della comunità — chi sono le entità chiave, quali relazioni emergono, qual è la narrativa dominante. Per un corpus medio (300 documenti, 50K chunk) si producono tipicamente migliaia di summary distribuiti su 4-5 livelli gerarchici. Tutti gli artefatti — grafo, communities, summary — vengono persistiti in storage strutturato (parquet su disco nel reference implementation Microsoft).

Query time: routing tra local search e global search

Al momento della query GraphRAG espone due modalità. Local search è simile al RAG classico ma arricchito: data una query, si recuperano le entità più rilevanti, e per ognuna si raccolgono le sue relazioni dal grafo, i chunk originali in cui appare e i summary delle comunità che la contengono. Il contesto fornito al LLM è quindi strutturato — entità, relazioni, passaggi, contesto di comunità — invece di una pila piatta di chunk. Funziona bene su domande specifiche su singole entità.

Global search aggredisce direttamente le query globali. Si itera sui summary di un dato livello della gerarchia (tipicamente il livello 2 o 3, configurabile), si chiede al LLM di rispondere alla query usando ciascun summary in modo indipendente, e poi si fa un map-reduce: si combinano le risposte parziali in una risposta finale sintetica. Per query come "quali sono i tre temi principali del corpus?" il sistema non recupera passaggi: consulta i summary di alto livello che sono già sintesi tematiche, e li compone.

Costi, tradeoff, quando ha senso

Il costo è il principale tradeoff e va affrontato esplicitamente. L'indexing di GraphRAG passa ogni chunk del corpus attraverso un LLM (almeno una volta per l'estrazione entità/relazioni) e produce molte chiamate aggiuntive per i summary di comunità. Microsoft riporta che su corpora medi GraphRAG costa 10-100x più del RAG naive in fase di indexing, con il fattore esatto che dipende dalla densità di entità e dalla profondità della gerarchia configurata. Su un corpus di 1M token, l'indexing GraphRAG con GPT-4 può facilmente costare diverse centinaia di dollari di token API.

Il calcolo razionale è: GraphRAG ha senso quando le query globali sono parte essenziale del caso d'uso e il corpus è abbastanza statico da ammortizzare il costo di indexing su molte query. Casi d'uso tipici: due diligence su corpus documentali aziendali, intelligence analysis, ricerca scientifica multi-paper, analisi di archivi narrativi. Per use case in cui il corpus cambia rapidamente o le query sono solo locali (chatbot di customer support su FAQ), il RAG naive resta più appropriato.

Dal rilascio open source a luglio 2024, GraphRAG ha generato un'ondata di varianti: LightRAG (Hong Kong, ottobre 2024) cerca di ottenere benefici simili a costo inferiore; nano-graphrag riimplementazione minimale; integrazioni in Microsoft Fabric e Azure AI Search. Il paper accademico sottostante è "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (Edge et al., arXiv:2404.16130).

---