#Pourquoi GraphRAG ?

Imaginez le corpus d'un cabinet juridique : 200 contrats, 500 emails, 80 décisions. Vous posez la question : « Quels sont les principaux risques juridiques évoqués dans nos contrats clients sur les trois dernières années, et avec quels clients récurrents ? ». Un RAG vectoriel classique va chercher 5 ou 10 chunks « pertinents », les donner au LLM, et celui-ci va répondre… avec une vue partielle. Il rate les patterns transverses.

GraphRAG, au lieu de ne retourner que des passages bruts, raisonne sur une structure : qui mentionne quoi, quelles entités reviennent, quelles relations les lient. Pour ce type de question synthétique (« global ») sur un corpus, le graphe bat le vectoriel — c'est précisément ce que démontrait le papier original de Microsoft Research en 2024.

À qui s'adresse ce guide

Vous avez déjà un RAG vectoriel local qui fonctionne (ChromaDB, LlamaIndex, AnythingLLM…), et vous butez sur les questions de synthèse. Sinon, commencez par un RAG classique avant d'attaquer celui-ci.

#GraphRAG vs RAG vectoriel : la vraie différence

Les deux approches partagent un objectif : injecter du contexte externe dans le prompt du LLM pour limiter les hallucinations. Mais elles ne récupèrent pas la même chose.

RAG vectoriel: Découpe le corpus en chunks, calcule un embedding par chunk, stocke dans une base vectorielle (ChromaDB, Qdrant, FAISS). À la requête, récupère les k chunks les plus proches en cosinus.
GraphRAG: Demande à un LLM d'extraire des entités et des relations de chaque chunk, construit un graphe, regroupe les entités en communautés, résume chaque communauté. À la requête, traverse le graphe ou agrège des résumés de communautés.
Forces vectoriel: Rapide à indexer (quelques minutes pour 10 Mo de texte), peu coûteux, excellent pour des questions ciblées (« quelle est la clause de résiliation dans le contrat Acme ? »).
Forces GraphRAG: Excellent pour des questions globales (« quels sont les thèmes récurrents ? », « quelles entités sont les plus connectées ? »), traçabilité fine via les arêtes, multi-hop natif.
Faiblesse vectoriel: Perd les liens entre documents. Une question qui demande de joindre 3 documents éloignés sémantiquement ne ramène pas les bons chunks.
Faiblesse GraphRAG: Indexation lourde : il faut faire passer chaque chunk dans un LLM. Sur un corpus de 10 Mo, comptez plusieurs heures et beaucoup de VRAM, là où le vectoriel termine en 5 minutes.

→

L'approche hybride gagne souvent

En pratique, les meilleures stacks combinent les deux : graphe pour les questions globales et la navigation, vectoriel (ou BM25) pour les requêtes ciblées. Voir aussi la recherche hybride BM25 + vectoriel pour une autre forme de combinaison.

#Comment ça marche en interne

Un pipeline GraphRAG complet enchaîne 5 étapes. Toutes utilisent le LLM (sauf le clustering).

01
Chunking
Le corpus est découpé en passages de 500 à 1500 tokens, comme dans un RAG classique. La taille a un impact direct sur la qualité d'extraction : trop court, le LLM rate des relations ; trop long, il en oublie.
02
Extraction d'entités et de relations
Chaque chunk est passé à un LLM avec un prompt structuré du type : « Extrais toutes les entités (personne, organisation, lieu, concept) et les relations entre elles. Format JSON. » C'est l'étape coûteuse — un appel LLM par chunk.
03
Construction du graphe
Les entités extraites deviennent des nœuds, les relations des arêtes. Les entités identiques apparaissant dans plusieurs chunks sont fusionnées (résolution d'entités, souvent par embedding ou par règle de normalisation).
04
Détection de communautés
Un algorithme de clustering (Leiden chez Microsoft, plus simple chez nano-graphrag) regroupe les nœuds fortement connectés en communautés. Ces communautés sont la clé du raisonnement « global ».
05
Résumé des communautés
Le LLM produit un résumé textuel de chaque communauté à partir des entités et relations qu'elle contient. Ces résumés deviennent les unités de récupération pour les questions globales.

À l'interrogation, GraphRAG distingue deux modes : local (recherche d'une entité précise et de son voisinage) et global (agrégation de résumés de communautés). Le LLM combine ensuite le contexte récupéré et la question pour produire la réponse finale.

#Outils disponibles pour un déploiement local

Microsoft GraphRAG: L'implémentation de référence (github.com/microsoft/graphrag). Complète, soignée, mais lourde : pensée pour Azure OpenAI à l'origine, le portage Ollama demande de la patience. Indexation très coûteuse en tokens.
nano-graphrag: Implémentation minimale (~1000 lignes) compatible Ollama nativement (github.com/gusye1234/nano-graphrag). C'est ce qu'on va utiliser ici : 10x moins de code à comprendre, et la même idée.
LightRAG: Variante plus récente, optimisée pour la latence d'interrogation. Compatible Ollama. Plus simple que Microsoft GraphRAG, plus structurée que nano-graphrag.
LlamaIndex KnowledgeGraphIndex: Si vous êtes déjà sous LlamaIndex, l'intégration est immédiate, mais l'approche est plus rudimentaire (pas de communautés).

Le choix pédagogique

Ce guide utilise nano-graphrag parce que tout tient dans deux fichiers Python qu'on peut lire, modifier, déboguer. Une fois le concept maîtrisé, passer à Microsoft GraphRAG ou LightRAG en production devient trivial.

#Prérequis

Ollama installé et fonctionnel: Si ce n'est pas le cas, suivez d'abord notre guide d'installation d'Ollama.
Un LLM de raisonnement >= 14B: L'extraction d'entités demande du jus. Qwen 2.5 14B, Llama 3.1 8B (limite basse), Mistral Small 24B fonctionnent bien. En dessous de 8B, le JSON produit est souvent malformé.
Un modèle d'embeddings local: nomic-embed-text via Ollama, ou bge-m3 / multilingual-e5-large via sentence-transformers.
16 Go de VRAM minimum: 12 Go suffisent pour des modèles 7-8B Q4 mais l'indexation sera lente. 24 Go (RTX 3090, 4090, M-Max) sont confortables.
Python 3.10+: nano-graphrag et la plupart des frameworks RAG modernes exigent 3.10 ou plus.

#1. Indexer un corpus avec nano-graphrag

Préparez d'abord les modèles côté Ollama. Pour ce tutoriel, on prend Qwen 2.5 14B en Q4 et nomic-embed-text comme embeddings.

Terminal

ollama pull qwen2.5:14b
ollama pull nomic-embed-text
ollama serve  # si pas déjà en service

Installez ensuite nano-graphrag dans un venv dédié.

Terminal

python -m venv .venv
source .venv/bin/activate  # Linux/macOS
pip install nano-graphrag

Le script d'indexation tient en une vingtaine de lignes. On le branche sur Ollama via l'endpoint OpenAI-compatible sur le port 11434.

index.py

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

WORKING_DIR = "./graphrag_cache"

async def main():
    rag = GraphRAG(
        working_dir=WORKING_DIR,
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "qwen2.5:14b"},
        cheap_model_kwargs={"model_name": "qwen2.5:14b"},
    )

    with open("corpus.txt", encoding="utf-8") as f:
        text = f.read()

    await rag.ainsert(text)

if __name__ == "__main__":
    asyncio.run(main())

Lancez l'indexation. Selon la taille du corpus et le GPU, comptez de quelques minutes (1 Mo de texte) à plusieurs heures (50 Mo).

Terminal

python index.py

Patience : c'est lent par nature

Sur un corpus de 5 Mo avec Qwen 14B sur RTX 4090, comptez environ 1 heure. nano-graphrag traite les chunks séquentiellement par défaut. C'est normal — vous payez l'extraction LLM, pas un calcul d'embeddings.

À la fin, le dossier graphrag_cache/ contient le graphe sérialisé, les embeddings, et les résumés de communautés.

#2. Interroger le graphe

Une fois indexé, l'interrogation est rapide (quelques secondes par requête) car le LLM ne lit plus que le contexte récupéré du graphe, pas l'intégralité du corpus.

query.py

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

async def main():
    rag = GraphRAG(
        working_dir="./graphrag_cache",
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "qwen2.5:14b"},
        cheap_model_kwargs={"model_name": "qwen2.5:14b"},
    )

    # Mode global : synthèse à partir des résumés de communautés
    print(await rag.aquery(
        "Quels sont les thèmes principaux du corpus ?",
        param=QueryParam(mode="global")
    ))

    # Mode local : recherche centrée sur des entités
    print(await rag.aquery(
        "Quelle est la position de l'entreprise X sur le sujet Y ?",
        param=QueryParam(mode="local")
    ))

asyncio.run(main())

→

Choisir le bon mode

Question commençant par « quels sont les principaux… », « quelles tendances… », « fais une synthèse… » → mode global. Question portant sur une entité précise → mode local. Si vous ne savez pas, essayez les deux : les réponses diffèrent souvent radicalement.

#Coût compute en local : à quoi s'attendre

C'est la partie qui surprend tout le monde la première fois. Indexer 5 Mo de texte en GraphRAG demande environ 50 à 200 fois plus de compute qu'un RAG vectoriel sur le même corpus. Voici des repères concrets mesurés.

Corpus 1 Mo (~300 pages): Qwen 2.5 14B Q4 sur RTX 4090 : ~25 min d'indexation. Sur RTX 3060 12 Go : ~2h. Sur Mac M3 Max 64 Go : ~40 min.
Corpus 5 Mo (~1500 pages): RTX 4090 : ~2h. M4 Pro 48 Go : ~3h. Au-delà de ce volume, prévoyez de laisser tourner la nuit.
VRAM peak: Le modèle 14B Q4 occupe ~9 Go en permanence. Les embeddings nomic ajoutent ~1 Go. Sous 12 Go de VRAM, attendez-vous à du swap CPU.
Coût d'une requête: Quelques secondes en mode local, 5 à 30 s en mode global (agrégation de plusieurs communautés). Indolore comparé à l'indexation.
Re-indexation incrémentale: nano-graphrag ne sait pas mettre à jour proprement un graphe existant à l'heure actuelle. Ajouter 10 % de nouveaux documents = relancer une indexation partielle ou complète. Microsoft GraphRAG gère mieux ce point.

Le piège du LLM trop petit

Tentés par Llama 3.2 3B pour aller plus vite ? L'extraction JSON sera incohérente, les entités mal nommées, le graphe inutilisable. C'est exactement l'erreur où l'indexation rapide produit un graphe inexploitable. Investissez dans 14B minimum.

#Quand GraphRAG bat vraiment le vectoriel

GraphRAG n'est pas un remplaçant universel du RAG vectoriel. Il l'écrase sur certains cas d'usage, le sous-performe nettement sur d'autres.

Synthèse sur corpus: « Quels sont les 5 thèmes principaux discutés dans nos 200 emails sur le sujet X ? » → GraphRAG gagne haut la main. Le vectoriel ne ramène que 5-10 emails, le graphe agrège les communautés.
Questions multi-hop: « Quels fournisseurs travaillent à la fois avec Acme et Beta Corp ? » → GraphRAG le résout par traversée d'arêtes. Le vectoriel doit retrouver les bons chunks et compter sur le LLM pour faire le join.
Exploration de relations: « Qui sont les personnes les plus mentionnées en relation avec le projet Atlas ? » → GraphRAG est natif pour ça (centralité, voisinage). Le vectoriel n'a pas la notion de relation.
Q&A factuelle ciblée: « Quelle est la durée du préavis dans le contrat Acme du 12 mars 2024 ? » → RAG vectoriel gagne : plus rapide, plus précis, moins coûteux à indexer.
Corpus très évolutif: Si vous ajoutez des documents tous les jours, le coût de re-indexation de GraphRAG devient prohibitif. Restez sur du vectoriel ou du vectoriel + BM25.
Corpus < 500 Ko: Pas besoin de graphe : le LLM peut tout lire en contexte si vous avez 32k+ tokens. GraphRAG ne se justifie que sur des corpus trop gros pour tenir en contexte.

→

La règle pratique

Si vos utilisateurs posent surtout des questions de type « cherche cette info précise », restez sur du vectoriel. Si la valeur est dans la synthèse, l'exploration de patterns ou l'analyse transversale d'un corpus stable, GraphRAG vaut son coût d'indexation.

#Pour aller plus loin

GraphRAG est un domaine actif : les implémentations évoluent vite, les benchmarks aussi. Quelques pistes pour continuer.

RAG local : introduction: Si certains concepts du RAG vectoriel restent flous, le guide d'introduction est une bonne base avant de pousser GraphRAG en production.
Stratégies de chunking: La qualité d'extraction d'entités dépend directement de la taille et de la cohérence des chunks. Ce guide creuse les bonnes pratiques.
Recherche hybride BM25 + vectoriel: Pour combiner GraphRAG avec un retrieval classique, regardez d'abord la recherche hybride : même logique d'union de signaux.
Choisir son GPU pour l'IA locale: L'indexation GraphRAG est gourmande. Si vous tournez sur un GPU 8-12 Go aujourd'hui, le passage à 16-24 Go change radicalement la cadence.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

RAG · 12 min

#Pourquoi GraphRAG ?

#GraphRAG vs RAG vectoriel : la vraie différence

#Comment ça marche en interne

#Outils disponibles pour un déploiement local

#Prérequis

#1. Indexer un corpus avec nano-graphrag

#2. Interroger le graphe

#Coût compute en local : à quoi s'attendre

#Quand GraphRAG bat vraiment le vectoriel

#Pour aller plus loin

RAG local : introduction

Stratégies de chunking

Recherche hybride BM25 + vectoriel

Choisir son GPU pour l'IA locale