Knowledge graph vs RAG : faut-il un graphe de connaissances ou de la récupération par passages ?

Un knowledge graph et un système RAG par passages répondent à deux besoins différents : relier formellement des entités entre elles, ou retrouver et citer les bons extraits d'un document source. GraphRAG combine les deux approches : il parcourt un graphe pour raisonner sur des relations à plusieurs sauts, puis récupère les passages qui justifient la réponse finale. Le bon choix dépend moins de la nouveauté de la méthode que de la nature de vos questions : relationnelles et transversales, ou factuelles et ancrées dans un texte précis.

Deux logiques de récupération différentes

Avant de parler de GraphRAG, il faut distinguer clairement ce que fait un knowledge graph et ce que fait un système RAG classique. Les deux manipulent de la connaissance, mais pas de la même manière, et ils ne répondent pas aux mêmes questions avec la même efficacité.

Le knowledge graph : des entités et des relations typées

Un knowledge graph (ou graphe de connaissances) représente le monde sous forme de nœuds (des entités : une personne, une société, un produit, un article de loi) et d'arêtes typées qui décrivent la relation entre ces entités (« dirige », « est filiale de », « cite », « est applicable à »). Ce format rend explicite ce qui, dans un texte brut, reste implicite et dispersé sur plusieurs documents. Il permet des requêtes structurées : trouver tous les intermédiaires entre une société A et une société B, lister toutes les clauses qui référencent un même règlement, ou remonter la chaîne de bénéficiaires effectifs d'une structure actionnariale complexe.

Le RAG par passages : retrouver puis citer le bon extrait

Un système RAG classique, lui, ne construit pas de modèle du monde. Il découpe des documents en passages (chunking), les indexe pour la recherche hybride (mots-clés et vecteurs sémantiques), puis, pour chaque question, retrouve les passages les plus pertinents et les donne à un modèle de langage pour qu'il rédige une réponse appuyée sur ces extraits cités. C'est une approche de récupération documentaire : efficace, rapide à mettre en place, et particulièrement adaptée quand la réponse à une question se trouve majoritairement dans un seul passage ou dans deux ou trois passages voisins.

GraphRAG : construire un graphe par-dessus les documents, puis récupérer

GraphRAG désigne une famille de méthodes qui ajoutent une couche graphe à un pipeline RAG. Le principe général : un modèle de langage extrait automatiquement des entités et des relations à partir des documents sources, ces éléments sont assemblés en graphe (parfois avec une détection de « communautés » de nœuds fortement connectés), puis, à la question posée, le système combine une traversée du graphe (pour rassembler les éléments liés à travers plusieurs documents) avec une récupération classique de passages pour ancrer la réponse sur du texte vérifiable.

L'intérêt principal de GraphRAG apparaît sur les questions qui demandent un raisonnement multi-sauts : non pas « que dit ce contrat sur le préavis ? » mais « quelles sont, parmi nos vingt contrats fournisseurs, les clauses de résiliation qui dépendent toutes du même indice, et quels fournisseurs sont liés à la même société mère ? ». Un RAG par passages classique peine sur ce type de question, car la réponse n'existe dans aucun passage unique : elle émerge de la mise en relation de plusieurs documents.

Quand le knowledge graph apporte un vrai gain

Construire et maintenir un graphe de connaissances a un coût réel : extraction d'entités, résolution des doublons (la même société peut apparaître sous trois noms différents), mise à jour quand les documents changent. Ce coût se justifie surtout dans certains contextes précis.

• Enquêtes et due diligence : remonter des chaînes d'actionnariat, de sous-traitance ou de flux financiers à travers des dizaines de documents hétérogènes.
• Conformité LCB-FT et bénéficiaires effectifs : identifier la personne physique derrière des structures imbriquées nécessite de suivre des relations, pas de retrouver un passage isolé.
• Cartographie réglementaire : relier un article de loi à tous les textes qui le citent, l'amendent ou en dépendent, au-delà d'un seul document.
• Bases scientifiques ou techniques denses en entités : relier des molécules, des gènes, des normes ou des composants à travers des milliers de publications.
• Audit et traçabilité de contrats : identifier tous les documents qui partagent une clause, une partie ou une référence commune.

Quand le RAG par passages classique suffit (et coûte moins cher)

Dans la majorité des usages professionnels, la question posée a une réponse localisée dans un ou deux passages d'un document identifiable : une politique RH, une procédure interne, une notice technique, une FAQ produit, un contrat type. Construire un graphe pour ce type de corpus ajoute de la complexité sans bénéfice proportionné. Un assistant qui répond sur le livret d'accueil ou la convention collective n'a pas besoin de raisonner sur des relations entre entités : il a besoin de retrouver le bon paragraphe et de le citer fidèlement.

C'est aussi le cas pour le support client, la documentation technique interrogée par une équipe produit, ou un corpus réglementaire consulté article par article (comme pour interroger le BOFiP). Dans ces contextes, le temps et le budget gagnés en évitant la construction d'un graphe peuvent être réinvestis dans une meilleure stratégie de chunking, une recherche hybride bien réglée et un système de citation fiable, ce qui apporte un gain de qualité plus immédiat qu'une couche graphe sous-utilisée.

Comparatif express

Les combiner sans sur-ingénierie

Dans la pratique, peu d'équipes ont besoin de choisir un camp de façon définitive. Une approche pragmatique consiste à démarrer par un RAG par passages solide, avec une recherche hybride qui combine mots-clés et similarité sémantique, puis à observer les questions qui restent mal servies. Si une part significative des questions échoue parce qu'elles demandent de relier plusieurs documents entre eux (par exemple : « quels fournisseurs partagent une clause de non-concurrence identique ? »), c'est le signal qu'une couche graphe, même légère, apporterait de la valeur. Si en revanche la quasi-totalité des questions trouve sa réponse dans un passage unique correctement récupéré, investir dans un graphe de connaissances serait prématuré.

Une version intermédiaire, moins coûteuse qu'un vrai knowledge graph, consiste à enrichir les métadonnées des documents indexés (entité principale, type de document, date, parties concernées) plutôt que de construire un graphe complet avec extraction automatique de relations. Cela permet déjà de filtrer et de croiser des documents à la récupération, sans le coût de maintenance d'un graphe typé. Cette étape intermédiaire couvre souvent une bonne partie des besoins avant qu'un GraphRAG complet ne soit justifié.

Par où commencer sur vos propres documents

Pour la grande majorité des cas d'usage métier (politiques internes, documentation produit, contrats types, procédures), le point de départ le plus rentable reste un RAG par passages bien construit, avec un chunking adapté à la structure des documents et une recherche hybride. Sur Kopik, créer une base de connaissances de ce type ne demande pas d'infrastructure : vous déposez vos fichiers (PDF, Word, texte, Markdown), la plateforme extrait, découpe et indexe automatiquement le contenu pour une recherche hybride, et vous obtenez des réponses citées sur vos passages sources dès la première question posée.

Si, après quelques semaines d'usage réel, vous constatez que les questions les plus fréquentes portent sur des relations entre entités plutôt que sur des faits isolés, c'est le bon moment d'évaluer une couche graphe par-dessus ce socle, plutôt que de la construire en préalable sur la base d'une intuition. Cette méthode évite l'écueil le plus courant des projets GraphRAG : investir dans l'extraction d'entités et de relations avant même d'avoir vérifié que le besoin existe sur son propre corpus.

Questions fréquentes