From atum-ai-ml
GraphRAG (Graph-based Retrieval Augmented Generation) pattern library — implementation of the GraphRAG paradigm popularized by Microsoft Research in 2024 (From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Edge et al.) which constructs a knowledge graph from a corpus by extracting entities and relationships with an LLM, runs community detection on the graph (Leiden algorithm), generates hierarchical community summaries, and then routes queries to either local search (around specific entities) or global search (across community summaries) depending on the query intent. Covers the core GraphRAG pipeline (LLM entity extraction with custom prompts, relationship extraction with type classification, graph construction in Neo4j or NetworkX, Leiden community detection at multiple resolutions, hierarchical summarization of communities by LLM, query classification as local or global, local search via entity-centric subgraph retrieval, global search via community summary aggregation), the production frameworks (Microsoft GraphRAG official implementation in Python, LightRAG by HKU as a faster alternative, FalkorDB for graph storage with claimed -90% hallucinations vs vector RAG, Neo4j GraphRAG library, ms-graphrag-mcp for Claude Code integration), benchmark gains for query-focused summarization (Microsoft paper shows comprehensiveness +72%, diversity +62% over vector RAG baseline), comparison with vector RAG (vector RAG is best for fact lookup with dense semantic similarity, GraphRAG is best for global understanding requiring relationship traversal), comparison with hybrid RAG (vector + sparse), use cases where GraphRAG dominates (research synthesis, executive summaries, narrative understanding, multi-document reasoning, scientific literature review, legal case law), use cases where it underperforms (single-fact lookup, simple Q&A, low-latency requirements), implementation considerations (extraction quality is critical, LLM cost for entity extraction is high, graph maintenance as corpus evolves, query routing accuracy), and the limitations (cost of graph construction, latency, graph schema design challenges, less mature than vector RAG ecosystem). Use when standard RAG fails on global summarization queries, when relationships between entities matter more than semantic similarity, or when building research/analytics applications. Differentiates from rag-architect (vector-centric) by deep focus on graph-based knowledge representation.
npx claudepluginhub arnwaldn/atum-plugins-collection --plugin atum-ai-mlThis skill uses the workspace's default tool permissions.
Pattern popularisé par **Microsoft Research en 2024** dans le papier "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (Edge et al.). GraphRAG résout une limitation fondamentale du RAG vectoriel : **comprendre globalement un corpus** au lieu de juste retrouver des passages similaires.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Processes code review feedback technically: verify suggestions against codebase, clarify unclear items, push back if questionable, implement after evaluation—not blind agreement.
Dispatches code-reviewer subagent to evaluate code changes via git SHAs after tasks, major features, or before merging, with focused context on implementation and requirements.
Pattern popularisé par Microsoft Research en 2024 dans le papier "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (Edge et al.). GraphRAG résout une limitation fondamentale du RAG vectoriel : comprendre globalement un corpus au lieu de juste retrouver des passages similaires.
Question : "Quelles sont les principales tendances de l'IA en 2025 selon ce corpus de 500 articles ?"
RAG vectoriel : récupère 5 chunks "similaires" → vue myope, pas de synthèse globale.
GraphRAG : extrait les entités (modèles, techniques, chercheurs, dates), construit le graphe, détecte les communautés (clusters thématiques), résume chaque communauté → réponse globale et structurée.
[CORPUS]
│
▼
┌────────────────────────┐
│ ENTITY EXTRACTION │ ← LLM avec prompt structuré
│ (LLM) │ Output: entités + relations
└──────────┬─────────────┘
│
▼
┌────────────────────────┐
│ GRAPH CONSTRUCTION │ ← Neo4j / NetworkX / FalkorDB
│ Nodes + Edges │
└──────────┬─────────────┘
│
▼
┌────────────────────────┐
│ COMMUNITY DETECTION │ ← Algorithme Leiden (multi-resolution)
│ (Leiden algorithm) │
└──────────┬─────────────┘
│
▼
┌────────────────────────┐
│ COMMUNITY SUMMARIES │ ← LLM résume chaque communauté
│ (hierarchical LLM) │ Niveau 0 (fine) → Niveau N (gros)
└──────────┬─────────────┘
│
▼ (KB built, ready for queries)
[QUERY]
│
▼
┌─────────────────────┐
│ QUERY CLASSIFIER │
│ Local or Global ? │
└─────────┬───────────┘
│
┌──────┴──────┐
│ │
▼ ▼
LOCAL GLOBAL
SEARCH SEARCH
(entity (community
subgraph) summaries)
│ │
└──────┬──────┘
│
▼
[LLM Generate]
│
▼
[ANSWER]
Prompt LLM appliqué chunk par chunk pour extraire entités et relations.
Tu es un extracteur d'entités. Pour ce texte, identifie :
1. Toutes les ENTITÉS (personnes, organisations, concepts, lieux, dates)
2. Toutes les RELATIONS entre ces entités
Format JSON :
{
"entities": [
{"name": "...", "type": "person|org|concept|place|date", "description": "..."}
],
"relationships": [
{"source": "...", "target": "...", "type": "...", "description": "..."}
]
}
Texte: {chunk}
Coût : 1 appel LLM par chunk de 1k tokens. Pour 1M tokens corpus → ~1k appels.
| Outil | Type | Avantages |
|---|---|---|
| Neo4j | Graph DB mature | Cypher, AuraDB managed, écosystème |
| FalkorDB | Redis-based, ultra-rapide | -90% hallucinations claimed, low-latency |
| Memgraph | In-memory, streaming | Real-time analytics |
| NetworkX | Python in-memory | Prototypage, petits graphes |
| Kùzu | Embedded, columnar | Embarqué dans l'app, fast analytical |
| TigerGraph | Distributed enterprise | Très gros graphes |
L'algorithme Leiden (Traag et al. 2019, successeur de Louvain) partitionne le graphe en communautés denses à plusieurs niveaux de granularité.
import igraph as ig
import leidenalg
g = build_graph_from_neo4j()
partition = leidenalg.find_partition(
g,
leidenalg.ModularityVertexPartition,
resolution_parameter=1.0,
)
# partition.membership = [community_id pour chaque node]
Multi-résolution : on lance Leiden avec différents resolution_parameter pour créer une hiérarchie :
Pour chaque communauté détectée, un LLM génère un résumé structuré :
Cette communauté contient les entités suivantes :
{entities_in_community}
Et les relations suivantes :
{relationships_in_community}
Génère un résumé structuré :
- Theme : ...
- Key entities : ...
- Key relationships : ...
- Insights : ...
Ces résumés sont stockés et indexés.
Le LLM classifie la query :
Récupère le sous-graphe autour d'une entité, sérialise et passe au LLM.
Map-reduce : pour chaque community summary, génère une réponse partielle, puis combine en réponse finale.
| Métrique | Vector RAG | GraphRAG | Gain |
|---|---|---|---|
| Comprehensiveness | baseline | +72% | Réponses plus complètes |
| Diversity | baseline | +62% | Moins de redondance |
| Empowerment (insight) | baseline | +52% | Plus actionnable |
Bénéfices typiques : pour des questions de synthèse globale, GraphRAG domine. Pour des questions factuelles ponctuelles, vector RAG suffit.
| Pattern | Best for | Latency | Cost build | Cost query |
|---|---|---|---|---|
| Vector RAG | Fact lookup, similarité sémantique | Bas (~100ms) | Bas (embeddings) | Bas |
| Hybrid RAG | Mixed needs, BM25 + vector | Bas (~150ms) | Bas | Bas |
| GraphRAG | Global summarization, narrative | Modéré (~1-5s) | Élevé (LLM extraction) | Modéré |
| Local GraphRAG | Entity-centric Q&A | Bas-Modéré | Élevé | Bas |
| Global GraphRAG | Theme synthesis, cross-doc | Élevé (~5-30s) | Élevé | Élevé |
Règle : utiliser GraphRAG en complément, pas en remplacement. Hybrid (vector + graph) est souvent optimal.
| Framework | Auteur | Avantages | Inconvénients |
|---|---|---|---|
| Microsoft GraphRAG | Microsoft Research | Implémentation officielle, mature | Lourd, coûteux |
| LightRAG | HKU 2024 | 5x plus rapide que MS GraphRAG, dual-level retrieval | Moins de features |
| Neo4j GraphRAG (Python lib) | Neo4j | Stack Neo4j, mature | Lock-in Neo4j |
| FalkorDB GraphRAG | FalkorDB | Ultra-low latency, -90% hallucinations | Newer ecosystem |
| Nano-GraphRAG | community | Lightweight, ~800 lignes Python | MVP only |
| ms-graphrag-mcp | community | MCP server pour Claude Code | Wrap MS GraphRAG |
pip install graphrag
# 1. Init projet
python -m graphrag.index --init --root ./graphrag_workspace
# 2. Configurer .env (OpenAI/Azure key)
echo "GRAPHRAG_API_KEY=sk-..." > ./graphrag_workspace/.env
# 3. Mettre les documents dans ./graphrag_workspace/input/
# 4. Build le graphe (coûteux : ~$10-50 pour 1M tokens corpus)
python -m graphrag.index --root ./graphrag_workspace
# 5. Query
python -m graphrag.query \
--root ./graphrag_workspace \
--method global \
"Quelles sont les principales tendances ?"
Build : très coûteux. Pour 1M tokens corpus :
Query :
→ GraphRAG est rentable si vous réutilisez beaucoup le corpus. Pour du one-shot, c'est trop cher.
✅ Bons cas :
❌ Mauvais cas :
Le meilleur setup en 2026 = hybride :
def hybrid_rag(query):
intent = classify_intent(query)
if intent == "factual":
return vector_rag(query)
elif intent == "global":
return graphrag_global(query)
else:
return graphrag_local(query)
rag-architect (ce plugin)pinecone-patterns / weaviate-patterns / qdrant-patterns (ce plugin)corrective-rag (ce plugin)rag-architect (ce plugin)