Graph RAG : quand les relations comptent plus que la similarité

Graph RAG est une approche de génération augmentée par récupération qui stocke les connaissances non pas (seulement) sous forme de vecteurs, mais sous forme de graphe de connaissances composé d'entités et de leurs relations. Alors que le RAG classique répond à une question par similarité sémantique, en cherchant les passages de texte les plus proches de la requête, Graph RAG suit les liens explicites entre entités. C'est ce qui fait sa force là où les relations et les raisonnements en plusieurs étapes (multi-hop) comptent plus que la simple similarité textuelle.

• Ce que c'est : une variante de RAG qui utilise un graphe de connaissances (entités et relations) comme source de connaissances, seul ou en complément de l'index vectoriel.
• Quand c'est utile : pour les questions multi-hop, les questions relationnelles et les questions de synthèse globales sur tout un corpus.
• Ce que ça coûte : des coûts d'indexation et de maintenance plus élevés qu'avec le RAG vectoriel, car l'extraction du graphe repose sur un LLM.

Pourquoi la similarité seule atteint ses limites

Le RAG classique fonctionne en deux étapes : dans le pipeline d'indexation, les documents sont analysés, découpés en chunks, convertis en vecteurs par un modèle d'embedding et écrits dans une base de données vectorielle. Dans le pipeline de requête, la question est elle aussi vectorisée, les chunks les plus similaires (top-k) sont récupérés, éventuellement combinés à BM25 via une recherche hybride et affinés par un reranker, puis l'ensemble atterrit dans le prompt du générateur. Ce schéma est solide et suffit pour la plupart des questions de connaissances. Le Contextual Retrieval d'Anthropic montre par exemple que les erreurs de récupération peuvent être réduites jusqu'à 67 % grâce à des en-têtes de contexte propres à chaque chunk et au reranking (Anthropic, état 09/2024).

L'angle mort apparaît pour deux types de questions :

• Questions multi-hop : « Quels fournisseurs de notre plus gros client sont eux-mêmes visés par des sanctions ? » exige une chaîne de raisonnements (client -> fournisseurs -> statut de sanction) qui ne figure dans aucun chunk isolé. La similarité top-k ne fournit alors souvent que des fragments, sans établir le lien.
• Questions de synthèse globales : « Quels sont les cinq thèmes centraux sur l'ensemble des 2 000 tickets de support ? » ne peut pas être traité en récupérant cinq à dix chunks similaires. La réponse exige une agrégation sur l'ensemble du corpus.

C'est précisément là qu'intervient Graph RAG : au lieu de trouver des fragments de texte isolés, il navigue dans une structure de connaissances explicite.

Construire un graphe de connaissances à la place (ou en complément) d'un index vectoriel

Le cœur de Graph RAG, c'est l'indexation. Un graphe est extrait des documents sources à l'aide d'un LLM :

1. Extraction des entités : le LLM identifie les entités (personnes, organisations, produits, lieux, concepts) et les décrit.
2. Extraction des relations : il détecte les relations entre ces entités (« livre à », « est une filiale de », « provoque »), avec leur description et, le cas échéant, une pondération.
3. Construction du graphe : les entités deviennent des nœuds, les relations des arêtes. Les entités mentionnées plusieurs fois sont fusionnées.

L'approche open source GraphRAG de Microsoft (Microsoft Research) enrichit ce schéma de base de deux étapes clés (état 2026) :

• Détection de communautés : par clustering de graphe (par exemple avec l'algorithme de Leiden), les nœuds fortement connectés sont regroupés en « communautés » hiérarchiques, c'est-à-dire en sous-graphes thématiques.
• Résumés de communautés : pour chaque communauté, un LLM génère un résumé dès l'indexation. Ces résumés sont la clé des questions globales : face à une question de synthèse, ce ne sont pas des chunks isolés mais des résumés de communautés qui servent de briques à une réponse de type map-reduce.

Il en découle deux modes de requête : Local Search répond à des questions ciblées sur une entité donnée et son voisinage dans le graphe ; Global Search répond à des questions thématiques portant sur tout le corpus, à partir des résumés de communautés.

Pseudo-code : indexation et requête

```text

Indexation (hors ligne, gourmande en LLM)

for document in corpus:
entités, relations = LLM_extraire(document)
graphe.merge(entités, relations)

communautés = cluster(graphe) # p. ex. Leiden
for c in communautés:
c.summary = LLM_résumer(c) # résumé de communauté

Requête (en ligne)

if question_est_globale(question):
réponses_partielles = [LLM(question, c.summary) for c in communautés_pertinentes]
réponse = LLM_reduce(question, réponses_partielles) # Global Search
else:
sous_graphe = graphe.parcourir(start=entités_de(question), hops=2)
réponse = LLM(question, sous_graphe + chunks_associés) # Local Search
```

Graph RAG vs RAG vectoriel : comparaison directe

Le choix n'est pas binaire : il dépend du type de question et du budget. La matrice suivante résume les différences.

Les valeurs de latence et de recherche hybride pour le RAG classique proviennent de la base de recherche de Blck Alpaca (matrice comparative des architectures RAG). La caractérisation de Graph RAG repose sur des connaissances générales établies concernant le projet GraphRAG et les index de graphe de connaissances dans des frameworks comme LlamaIndex.

Coûts et complexité comparés

La plus grande différence se situe au niveau de l'indexation. Avec le RAG vectoriel, l'opération ponctuelle la plus coûteuse est l'embedding de chaque chunk : comme ordre de grandeur, la base de recherche indique des coûts d'indexation d'environ 0,02 à 0,13 dollar US par million de tokens, et d'environ 1,02 dollar US par million de tokens de document avec le prompt caching d'Anthropic pour Contextual Retrieval (état 09/2024). Graph RAG exige plusieurs passes de LLM par document : extraction des entités, extraction des relations et résumés de communautés. Cela multiplie les coûts et la durée d'indexation.

Exemple : 50 000 documents

Supposons qu'une agence indexe pour un client un corpus de connaissances de 50 000 documents :

• RAG vectoriel : embedding unique plus index hybride. Les principaux coûts sont l'API d'embedding et l'hébergement de la base vectorielle. Les mises à jour se font de manière incrémentale via des ID de document stables.
• Graph RAG : chaque document nécessite plusieurs appels au LLM pour l'extraction, puis des appels au LLM par communauté pour les résumés. Dès un corpus de taille moyenne, les coûts d'indexation atteignent ainsi un multiple de ceux du RAG vectoriel, auxquels s'ajoute un effort d'exploitation supplémentaire pour le schéma du graphe, la déduplication des entités et la réindexation en cas de modifications importantes.

La règle empirique : Graph RAG est rentable lorsque l'intérêt des réponses fondées sur les relations justifie l'effort supplémentaire, pas comme choix par défaut. La recherche de Blck Alpaca met de manière générale en garde contre l'anti-pattern « le RAG comme solution miracle » ; pour Graph RAG, cette mise en garde vaut d'autant plus que le coût total de possession y est nettement plus élevé.

Quand choisir Graph RAG, et quand l'éviter

Adapté si :

• les réponses doivent relier des informations issues de nombreux documents (chaînes d'approvisionnement, structures organisationnelles, réseaux de conformité, paysages de la recherche et des brevets).
• les relations explicites entre entités sont centrales sur le plan métier.
• des questions de synthèse et des questions thématiques globales doivent être traitées sur tout un corpus.

Plutôt pas si :

• les questions portent surtout sur des faits isolés ou des passages très ciblés ; dans ce cas, un RAG hybride avec reranking suffit.
• le corpus est petit ou souvent réécrit en entier (la maintenance du graphe devient un goulot d'étranglement).
• le budget ne permet pas une indexation gourmande en LLM.

En pratique, l'architecture hybride est la plus solide : la recherche vectorielle ou hybride assure une large couverture sémantique, et le graphe de connaissances est activé de manière ciblée pour les questions relationnelles et multi-hop. Graph RAG reste ainsi une surcouche précise plutôt qu'un remplacement complet et coûteux.

Note DACH (Allemagne, Autriche, Suisse) : la protection des données s'applique aussi au graphe

En Allemagne et en Autriche, Graph RAG ne change rien aux principes du RGPD. Les entités et les relations comportant des données personnelles doivent, comme les embeddings et les chunks dans le RAG classique, être traitées comme des enregistrements adressables et supprimables. Les principes de limitation des finalités et de minimisation des données (art. 5) s'appliquent, tout comme l'exigence d'une base légale pour le traitement (art. 6) et le droit à l'effacement (art. 17). Le cloisonnement entre clients et un concept de rôles et de droits sont les mesures techniques et organisationnelles courantes qui te permettent de mettre en œuvre la limitation des finalités et la protection des accès selon l'art. 25 et l'art. 32 du RGPD. La Conférence allemande des autorités de protection des données (DSK) cite ces deux mesures comme des pratiques éprouvées dans son guide d'orientation sur les systèmes RAG d'octobre 2025. Si des collaborateurs utilisent le système à des fins différentes, ils doivent, selon la DSK, se voir attribuer des rôles différents. Un hébergement dans la région UE est recommandé, mais pas obligatoire : quiconque héberge hors de l'EEE doit s'appuyer sur un mécanisme prévu au chapitre V du RGPD, par exemple une décision d'adéquation ou des clauses contractuelles types.

En Autriche, c'est l'autorité de protection des données (Datenschutzbehörde, DSB) qui est compétente. Sa position sur l'usage de l'IA figure dans une FAQ sur l'IA et la protection des données. En Suisse, c'est avant tout la loi fédérale révisée sur la protection des données (nLPD, en vigueur depuis le 1er septembre 2023) qui s'applique. Le RGPD s'y applique en outre lorsqu'une entreprise propose des biens ou des services à des personnes dans l'UE ou observe leur comportement, dans la mesure où ce comportement a lieu dans l'UE (art. 3, par. 2, du RGPD). Ces indications sont fournies à titre informatif et ne constituent pas un conseil juridique.

Pour les agences et les décideurs B2B

Graph RAG n'est pas un remplaçant à la mode du RAG vectoriel, mais un outil spécialisé pour les connaissances riches en relations. Pour les agences, cela signifie : commence par un RAG hybride avec reranking comme base standard solide, et n'introduis Graph RAG que là où les questions multi-hop ou de synthèse apportent une valeur métier démontrable. Pour les décideurs B2B, la question centrale n'est pas « Quelle technique est la plus récente ? », mais « Quelles questions nos utilisateurs posent-ils vraiment, et ces réponses ont-elles besoin de relations ou seulement de similarité ? ». Blck Alpaca t'aide à faire cette distinction, calcule le TCO honnêtement et construit des architectures RAG conformes au RGPD qui évoluent avec les besoins réels, du simple index vectoriel au système hybride à graphe de connaissances.