Graph RAG : définition, architecture et guide d’implémentation du pipeline

Architecture et pipeline GraphRAG : de l’extraction à la génération

Le pipeline GraphRAG transforme des documents bruts en un graphe de connaissances exploitable, puis interroge ce graphe pour nourrir un LLM. Il s’articule autour de 4 étapes séquentielles qui remplacent le simple index vectoriel du RAG classique par une structure relationnelle, à l’image de l’architecture RAG multimodal qui étend le RAG textuel aux images et tableaux.

Les 4 étapes du pipeline GraphRAG

• Extraction triplets LLM : découpage des documents en chunks de 300 à 1200 tokens (avec un overlap recommandé de 10 à 20%), puis extraction des triplets (sujet, relation, objet) via un LLM.
• Construction graphe Neo4j : insertion des entités et relations dans une base graphe (Neo4j, MemGraph ou Amazon Neptune). Un graphe de 10 000 documents techniques ou 5 000 entrées de nomenclature devient navigable relationnellement.
• Retrieval hybride vecteurs : combinaison de la recherche vectorielle classique avec des requêtes structurelles sur le graphe.
• Génération contextuelle LLM : le LLM reçoit les triplets et chunks ancrés pour produire une réponse contextualisée.

Pour le prototypage, NetworkX permet de manipuler jusqu’à 100 000 nœuds en mémoire avant de basculer sur une solution industrielle, une approche qui peut bénéficier d’une réduction de latence en RAG, à l’image des étapes nécessaires pour créer un pipeline CI/CD.

Requêtes Cypher et ancrage des chunks

L’interrogation du graphe repose sur Cypher, le langage de requête de Neo4j. Le LLM génère la syntaxe Cypher via un FewShotPromptTemplate, qui lui fournit des exemples de requêtes valides. Cette approche permet de répondre à des questions multi-étapes que la similarité vectorielle seule ne résout pas, tout comme une architecture d’API adaptée (GraphQL ou REST) conditionne la flexibilité des échanges.

L’ancrage des chunks est essentiel : chaque entité est reliée à son chunk d’origine via une relation FROM_CHUNK. Cette liaison garantit la traçabilité la réponse finale cite précisément le passage source, un atout majeur pour l’explicabilité. La structure du graphe supporte des explorations de 2 à 3 hops (sauts de nœuds) pour couvrir des raisonnements indirects, et les moteurs modernes gèrent 1 milliard de triples en quelques secondes, une performance qui rappelle les étapes du déploiement continu automatisé.

Qu’est-ce que le RAG traditionnel et pourquoi ses limites ?

Le RAG traditionnel, ou Retrieval-Augmented Generation, répond à un problème central des grands modèles de langage : leur connaissance reste un instantané statique du passé. Le principe est simple et se déroule en deux phases. Lors de l’indexation, les documents sont découpés en chunks de 300 à 1200 tokens puis transformés en vecteurs numériques via des modèles d’embeddings. Au moment de la requête, le système convertit la question en vecteur et recherche les passages les plus similaires par similarité vectorielle. Cette approche vectorielle montre rapidement ses faiblesses face à des questions multi-documents ou nécessitant un raisonnement multi-étapes. Les embeddings capturent la proximité sémantique mais ignorent les relations explicites et typées entre entités. Résultat : le modèle peut assembler des informations contradictoires ou passer à côté d’une réponse qui exige de relier trois documents distincts. Pour un support client de niveau 1 ou des questions factuelles simples, le RAG classique suffit amplement. En revanche, dès que les données s’interconnectent, la recherche par similarité atteint ses limites et le contexte global se fragmente.

Graph RAG vs RAG classique : avantages, différences et critères de décision

Le RAG classique excelle sur des corpus de textes indépendants. Il interroge par similarité vectorielle et répond efficacement aux questions factuelles simples. Mais il échoue dès qu’il faut croiser plusieurs documents ou suivre un raisonnement en plusieurs étapes, d’où l’intérêt d’un reranking pour affiner les candidats. Le Graph RAG se positionne comme une extension du RAG traditionnel, pas comme une alternative. Il exploite les relations explicites et typées du knowledge graph, capturant une sémantique que les vecteurs ignorent. Un graphe de 10 000 documents techniques reliés devient navigable de proche en proche, là où la recherche vectorielle se noie.

Le choix entre les deux dépend de la complexité et de la connectivité de vos données. Des questions comme « quel produit utilise la machine X et a été acheté par un client de la région Y ? » nécessitent un graphe le RAG vectoriel ne peut pas suivre ce raisonnement multi-hop.

Pour des données faiblement connectées ou un support client de Niveau 1, le RAG classique suffit amplement. Il reste plus rapide à déployer et moins coûteux. Le Graph RAG s’impose quand l’interconnexion des entités devient le cœur de la valeur métier avec une compréhension macro (communautés) et micro (nœuds individuels) que le RAG vectoriel ne fournit pas.

Construction et interrogation du knowledge graph pour le Graph RAG

Le knowledge graph constitue la colonne vertébrale du Graph RAG. Sa structure repose sur un principe simple : représenter l’information sous forme d’entités (les nœuds) et de relations (les arêtes). Cette organisation en triplets (sujet, prédicat, objet) permet de modéliser des connaissances complexes et interconnectées qu’un simple vecteur ne peut capturer.

Création du graphe : extraction automatique ou manuelle

Deux approches s’offrent à vous pour construire votre graphe. La première, manuelle, fait appel à des experts métier qui définissent précisément les entités et leurs relations. Cette méthode garantit une qualité optimale mais s’avère coûteuse en temps, surtout pour des volumes importants comme les 10 000 documents techniques ou les 5 000 entrées de nomenclature typiques d’un environnement industriel.

La seconde, automatique, exploite les capacités d’un LLM pour extraire les triplets directement depuis vos textes. Un prompt structuré en JSON guide le modèle pour identifier les entités et les relations pertinentes. Cette approche nécessite cependant une validation humaine pour éviter les erreurs d’extraction. Le choix dépend de votre besoin : la méthode manuelle pour la précision chirurgicale, l’automatique pour sa rapidité d’exécution.

Structures et exemples de triplets

La puissance du knowledge graph réside dans sa capacité à représenter des relations explicites et typées. La structure est toujours la même :

• Entités (nœuds) : sociétés, personnes, produits, machines, clients
• Relations (arêtes) : liens typés entre les entités
• Triplet : Paris, est-la-capitale-de, France

Le choix du niveau de granularité est crucial. Un triplet trop générique (exemple : « est-relié-à ») génère du bruit inexploitable, tandis qu’un triplet spécifique (exemple : « fournit-des-composants-à ») offre une précision sémantique élevée. Cette finesse de modélisation distingue fondamentalement le Graph RAG du RAG vectoriel, qui ne capture pas ces relations typées.

Pour l’interrogation, le langage Cypher de Neo4j permet d’explorer le graphe avec des requêtes ciblées. Avec une gestion performante capable de traiter 1 milliard de triples en quelques secondes, le graphe devient un atout majeur pour votre pipeline d’inférence.

Explicabilité, réduction d’hallucinations et contexte dans le Graph RAG

Le Graph RAG transforme la boîte noire du LLM en un système traçable. Chaque réponse s’ancre dans une représentation transparente : le chemin emprunté dans le graphe entre les entités est visible et vérifiable. Cette vision macro des communautés de nœuds, couplée à une vision micro des relations précises, offre un niveau d’explicabilité impossible à atteindre avec la simple similarité vectorielle.

Cette structure favorise un raisonnement déductif : le modèle peut déduire de nouvelles connaissances à partir de relations existantes. En s’appuyant sur un contexte fiable et structuré plutôt que sur des associations statistiques, le système réduit drastiquement les hallucinations. Les réponses deviennent traçables, chaque triplet pouvant être utilisé comme preuve, avec une corrélation fidélité à température 0 atteignant 0,976.

Le graphe unifie des sources multiples en un tout cohérent, donnant au modèle une compréhension holistique des relations entre entités. Cette richesse contextuelle permet des réponses nuancées, même sur des sujets transversaux. L’architecture du knowledge graph agit ainsi comme un garde-fou cognitif, guidant le raisonnement du LLM vers des conclusions justifiées et vérifiables.

Stratégies de récupération : Local Search, Global Search et approche hybride

Les stratégies de retrieval conditionnent la pertinence des réponses. Contrairement au RAG vectoriel qui applique une recherche unique, le Graph RAG propose des parcours différenciés dans le knowledge graph. Ces parcours déterminent la profondeur de l’exploration et la nature du contexte fourni au LLM.

Local et Global Search : quand les utiliser ?

Le choix entre recherche locale et globale dépend du type de question posée. La Local Search est conçue pour les requêtes ciblées portant sur des entités précises. Elle explore le graphe de proche en proche, sur une profondeur de 2-3 hops, afin de collecter les nœuds et relations directement liés à l’entité de départ. La Global Search répond aux questions transversales nécessitant une vue d’ensemble. Elle s’appuie sur l’interrogation des rapports communautaires, des résumés générés pour des clusters de nœuds fortement interconnectés.

– Questions ciblées : identification d’une entité spécifique, analyse de ses relations directes.
– Exploration 2-3 hops : profondeur de parcours suffisante pour obtenir un contexte riche sans bruit.
– Interrogation rapports communautaires : lecture des résumés de clusters pour une synthèse macro.

Retrieval hybride : combiner vecteurs et triplets

L’approche hybride, comme la stratégie DRIFT, combine les forces des deux méthodes. Elle commence par une recherche vectorielle pour identifier les nœuds sémantiquement proches de la requête, puis utilise ces nœuds comme points d’ancrage pour une exploration locale du graphe, enrichie d’insights issus des communautés. Elle exploite la similarité vectorielle pour la récupération initiale, puis la structure relationnelle pour le raisonnement multi-étapes. Les requêtes Cypher, générées par le LLM via un `FewShotPromptTemplate`, permettent d’exprimer ces parcours complexes. Cette synergie dépasse la précision d’une correspondance exacte seule, car elle intègre à la fois la sémantique des chunks et la typologie des relations.

Limitations, coûts et évaluation de performance du Graph RAG

Adopter un Graph RAG ne se fait pas sans contrepartie. Le coût initial de construction du knowledge graph est le premier frein à considérer : l’extraction des triplets via des appels LLM sur des corpus de 10 000 documents techniques ou 5 000 entrées de nomenclature représente un investissement massif en temps et en tokens. Contrairement au RAG vectoriel classique, l’indexation n’est pas un simple calcul d’embeddings, mais une étape d’ingénierie logicielle à part entière.

– Coût d’extraction élevé : la génération de triplets (sujet, relation, objet) par LLM multiplie les appels API et le temps de calcul, ce qui peut vite devenir prohibitif sur de gros volumes documentaires.
– Hallucinations à la source : un LLM peut inventer des relations inexistantes lors de l’extraction des triplets. Une étape de validation humaine ou automatisée est indispensable pour garantir la fiabilité du graphe en aval.
– Fusion d’entités non triviale : distinguer les homonymes et regrouper les variantes (par exemple « Alice » et « Alice Smith ») reste un défi technique. Sans résolution robuste des entités, le graphe accumule du bruit et des doublons.
– Maintenance continue requise : le graphe doit être mis à jour au fil des nouvelles données, sans quoi les réponses générées deviennent obsolètes. Cette maintenance permanente ajoute un coût opérationnel structurel.
– Schémas trop génériques : des relations vagues (ex. « lié à ») créent du bruit et dégradent la précision du retrieval plutôt que de l’améliorer.

Côté évaluation, les métriques classiques du RAG (faithfulness, answer relevancy) restent valables, mais il faut y ajouter la précision et le rappel sur les triplets extraits. Les scores de corrélation fidélité à température 0 (0,976) et à température 1 (0,846) montrent que la température influence fortement la qualité des réponses. Le score AUC moyen de 0,878 pour l’attribution confirme que le système performe, mais qu’il faut mesurer ces indicateurs finement pour valider l’ajout du graphe. Le choix de la stack technique compte aussi : NetworkX plafonne à 100 000 nœuds en mémoire pour le prototypage, tandis que Neo4j gère 1 milliard de triples en quelques secondes. La similarité composite moyenne de 0,017 vs MedAlpaca (contre 0,319 vs Mistral) illustre enfin l’importance de comparer le Graph RAG à des modèles de référence spécialisés sur le domaine.