RAG et GraphRAG : comment connecter une IA à vos données

Le RAG (Retrieval-Augmented Generation) est un pattern d'architecture logicielle qui permet à une application d'IA, comme un chatbot IA, de rechercher dans vos propres contenus avant de répondre. Au lieu de s'appuyer seulement sur les connaissances de son modèle, il récupère les passages pertinents et les ajoute à son contexte.

C'est le principe que j'utilise dans Begonia.pro, mon SaaS de SEO local. Son chatbot IA recherche dans les articles du blog Begonia.pro et le contenu du site, pour répondre avec des informations précises et à jour, sans que le modèle ait été réentraîné sur le contenu Begonia.

Une autre approche d'architecture dérivée du RAG a récemment attiré mon attention : le GraphRAG, que je teste actuellement. Cette technique ne cherche plus seulement des passages similaires à une question. Elle exploite aussi les relations entre les concepts, les entités et les documents.

Dans cet article, je vais expliquer le fonctionnement de ces deux solutions pour les applications IA, comment les implémenter et dans quels cas choisir l'une ou l'autre.

RAG : récupérer avant de générer

Le terme RAG vient d'un article de recherche publié en 2020. Le principe consiste à compléter les connaissances apprises par le modèle avec une source externe que l'application interroge au moment de répondre.

Cette source peut être une base vectorielle, un moteur de recherche, une base SQL ou une API. RAG ne signifie donc pas obligatoirement base vectorielle. L'essentiel est de récupérer une information pertinente, puis de l'ajouter au contexte du modèle.

Une implémentation RAG classique sépare deux pipelines.

Le pipeline d'indexation prépare les connaissances

Avant qu'un utilisateur pose une question, l'application prépare les sources :

1. collecter les pages, articles, fichiers ou enregistrements intéressants ;
2. extraire et nettoyer leur contenu ;
3. les découper en passages cohérents, appelés chunks ;
4. conserver leurs métadonnées : titre, URL, langue, date, droits d'accès ;
5. transformer chaque passage en représentation numérique, ou embedding ;
6. enregistrer le texte, ses métadonnées et son embedding dans un index.

Un embedding transforme un texte en un vecteur numérique conçu pour en capturer le sens. La recherche sémantique peut ainsi retrouver des passages liés à une question même s'ils n'emploient pas les mêmes mots. Elle peut, par exemple, rapprocher une question sur la visibilité dans Google Maps d'un contenu sur le référencement local.

Le pipeline de réponse recherche avant d'appeler le LLM

Lorsqu'une question arrive, l'application recherche les passages pertinents, les classe, puis envoie les meilleurs au modèle avec la question. La réponse peut ensuite citer les sources utilisées.

Le fonctionnement complet peut se résumer ainsi :

Le grand modèle de langage (LLM) continue de générer la réponse. Le RAG ne garantit pas qu'il dira vrai : il lui fournit un contexte plus précis et plus récent.

Le RAG de Begonia.pro pour illustrer ce concept

Sur Begonia.pro, je publie du contenu sur le référencement local : les fiches Google Business Profile, les avis, comment optimiser son site d'entreprise, la visibilité dans les moteurs de recherche classiques ou les IA.

Avec le RAG, une question comme « comment remplir ma fiche Google ? » déclenche une recherche dans les contenus de Begonia.pro. Le modèle reçoit les passages les plus pertinents avec leurs titres et leurs URL, puis compose sa réponse à partir de ce contexte.

Ce système permet de répondre à des questions précises en s'appuyant sur des informations fiables et à jour, tout en citant les sources. Il est utilisé dans 2 fonctionnalités de mon SaaS :

• Le chatbot Begonia.pro dans l'interface pour les utilisateurs
• Le serveur MCP et son outil search_local_seo_knowledgebase pour les agents

J'ai d'ailleurs expliqué dans mon retour d'expérience sur les serveurs MCP de mes SaaS pourquoi je préfère exposer une recherche ciblée plutôt que transmettre toute une base de connaissances à l'agent.

Les deux usages se complètent :

Le moteur de recherche reste le même. Seuls l'interface et le système qui l'appelle changent.

Une première implémentation RAG doit rester simple

Pour comprendre comment construire un RAG, il suffit de suivre le parcours de l'information : définir les questions à traiter, préparer les contenus, les indexer, retrouver les passages utiles, puis les transmettre au modèle.

1. Partir de questions concrètes

Avant de construire le système, je liste les questions auxquelles le chatbot IA devra répondre. Pour Begonia.pro, ce pourrait être :

• « Comment choisir la catégorie principale de ma fiche Google ? »
• « Comment répondre à un avis négatif ? »
• « Que dois-je améliorer pour améliorer mon classement dans les moteurs de recherche ? »

J'ajoute aussi une question dont la réponse n'existe pas dans les contenus. Le chatbot doit alors reconnaître que l'information lui manque.

Cette liste définit simplement ce que le RAG doit savoir faire. Elle permet ensuite de vérifier s'il retrouve les bons passages et s'il répond correctement à partir de ces sources.

2. Préparer des passages qui gardent leur sens

Le découpage influence directement la qualité de la recherche.

Un chunk trop long va potentiellement mélanger plusieurs sujets. Un chunk trop court va perdre les informations nécessaires pour comprendre de quoi parle le texte.

Pour des articles Markdown, je préfère partir de la structure éditoriale : titre, introduction, sections et paragraphes. Chaque passage doit pouvoir être compris sans avoir besoin de deviner ce qui se trouvait trois paragraphes plus haut.

Chaque passage conserve au minimum l'identifiant du document, le titre, la section, l'URL canonique, la langue et la date de mise à jour. Ces métadonnées servent à filtrer la recherche et à produire de vraies citations.

3. Indexer les passages

Une fois les passages préparés, l'application les envoie à un modèle d'embedding. Pour chacun d'eux, le modèle produit un vecteur : une suite de nombres qui représente son sens. Deux passages qui parlent de sujets proches obtiennent ainsi des vecteurs proches, même s'ils n'utilisent pas exactement les mêmes mots.

L'application enregistre ensuite trois éléments dans l'index :

• le vecteur, utilisé pour effectuer la recherche ;
• le texte original, qui sera transmis au LLM ;
• les métadonnées, comme le titre, l'URL, la langue ou la date.

Lors de la première indexation, ce traitement est appliqué à tout le corpus. Par la suite, il suffit de mettre à jour les passages concernés lorsqu'un contenu est ajouté ou modifié, et de les retirer de l'index lorsqu'il est supprimé.

À ce stade, le LLM ne génère encore aucune réponse. L'objectif est simplement de préparer un index dans lequel l'application pourra chercher rapidement lorsqu'une question arrivera.

4. Rechercher, sélectionner, puis générer

Lorsqu'une question arrive, l'application la transforme en embedding avec le même modèle que celui utilisé pour indexer les passages. L'index compare ensuite ce vecteur à ceux de la base et classe les résultats selon leur proximité.

L'application demande alors les k premiers résultats : c'est ce que l'on appelle le top-k. Avec un top-k de 5, elle récupère par exemple les cinq passages les mieux classés et les ajoute au contexte du LLM avec la question et leurs sources.

Il n'existe pas de valeur idéale pour tous les RAG. Trop peu de passages peut laisser de côté une information utile. Trop de passages augmente le nombre de tokens et peut ajouter du bruit dans le contexte. Je commencerais avec une petite valeur, puis je l'ajusterais à partir des questions de test définies précédemment.

Avant d'appeler le LLM, l'application peut aussi éliminer les résultats qui ne respectent pas la langue, les droits d'accès ou un seuil minimal de pertinence. Pour des documents privés, ce contrôle doit avoir lieu avant que les passages soient transmis au modèle. Le LLM reçoit ainsi uniquement les passages retenus et doit indiquer lorsque ces sources ne suffisent pas pour répondre.

La recherche vectorielle peut être combinée à une recherche par mots-clés comme BM25. Les embeddings retrouvent le sens général ; les mots-clés restent utiles pour un nom de produit, un acronyme ou une expression exacte.

Pour un petit corpus bien structuré, ce premier classement peut suffire. Si les tests montrent que le bon passage est retrouvé, mais qu'il apparaît régulièrement derrière des résultats moins utiles, il devient intéressant d'ajouter une seconde étape de classement.

5. Optionnel : améliorer le classement avec un cross-encoder

Cette étape est une optimisation avancée, pas une obligation pour construire un RAG.

La recherche vectorielle décrite jusqu'ici utilise généralement un bi-encoder. Il transforme séparément la question et les passages en vecteurs, puis compare leur proximité. Cette méthode est rapide, car les embeddings des passages ont déjà été calculés pendant l'indexation. Elle peut toutefois sélectionner des textes qui parlent du bon sujet sans répondre précisément à la question.

Le cross-encoder travaille différemment : il lit la question et un passage ensemble pour vérifier plus précisément si le passage répond à la demande. Il répète cette opération pour chaque résultat de la première recherche, puis les classe à nouveau. Cette étape est appelée reranking.

Le cross-encoder n'est appliqué qu'à quelques dizaines de candidats, car relire chaque passage de toute la base serait trop lent et trop coûteux. Son objectif est de réduire le bruit avant d'envoyer le contexte au LLM.

Cette optimisation a deux limites : elle ajoute de la latence et ne peut pas retrouver un passage absent de la première sélection. Il faut donc comparer une version avec et sans reranking sur les mêmes questions pour vérifier que le gain est réel.

Comment vérifier qu'un RAG fonctionne ?

Une mauvaise réponse ne vient pas toujours du LLM. L'information peut être absente ou obsolète, la recherche peut ne pas retrouver le bon passage, ou le modèle peut mal utiliser le contexte reçu.

Avec les questions préparées au début, je vérifie donc séparément :

• si le bon passage apparaît parmi les premiers résultats ;
• si la réponse reste fidèle aux passages fournis et cite les bonnes sources ;
• si le chatbot reconnaît que l'information manque lorsqu'aucune source ne permet de répondre.

Ce même jeu de questions permet ensuite de comparer chaque changement : nouveau découpage, recherche hybride, reranking ou GraphRAG.

Pourquoi le RAG vectoriel atteint ses limites

La recherche vectorielle retrouve ce qui ressemble sémantiquement à la question. Elle ne représente pas explicitement les relations contenues dans les documents.

Par exemple, trois documents peuvent indiquer qu'un composant dépend d'un service et que la panne de ce service a provoqué plusieurs incidents. Une recherche vectorielle peut retrouver un ou deux passages et manquer cette chaîne complète.

La difficulté apparaît surtout avec :

• les questions relationnelles : « quels composants dépendent de ce service et dans quels documents sont-ils décrits ? » ;
• les questions en plusieurs étapes : « quels incidents ont la même cause et quels produits ont été touchés ? » ;
• les questions globales : « quels thèmes reviennent dans toute cette base ? ».

C'est le terrain du GraphRAG.

Le GraphRAG ajoute une carte des relations

GraphRAG désigne une famille d'architectures qui utilisent un graphe pour récupérer le contexte.

Dans un graphe de connaissances, les informations sont représentées par :

• des nœuds : comme une entreprise, un produit, un composant, un incident ou un document ;
• des relations : comme DÉPEND_DE, CAUSE, EXPLIQUE, CITE ou CONCERNE ;
• des propriétés : comme un nom, une date, une importance ou une URL.

Une information ne vit plus seulement dans un paragraphe. Elle peut être exprimée comme une relation interrogeable :

Le système peut partir d'une entité détectée dans la question, parcourir ses relations et retrouver les passages associés.

Le terme porte toutefois deux sens qu'il faut distinguer. Graph RAG désigne le pattern d'architecture général qui utilise un graphe pour la récupération. GraphRAG désigne aussi l'implémentation open source de Microsoft Research, qui propose sa propre méthode d'indexation et de recherche.

L'implémentation GraphRAG de Microsoft va du local au global

Microsoft GraphRAG transforme des documents en entités, relations et communautés. Il résume ensuite ces groupes à plusieurs niveaux et crée aussi des embeddings pour certaines recherches.

Cette préparation permet plusieurs modes de requête.

• Local Search combine le graphe et les passages sources pour une question ciblée.
• Global Search synthétise les rapports de communautés pour répondre sur l'ensemble du corpus.
• DRIFT Search part d'une vue générale, puis explore progressivement les détails liés.
• Basic Search fournit une recherche vectorielle simple comme point de comparaison.

Cette implémentation répond donc à un problème plus précis que « rendre le RAG meilleur » : produire une synthèse guidée par une question lorsque la réponse dépend d'une grande partie du corpus.

Comment implémenter une approche GraphRAG

Pour illustrer, je prends l'architecture GraphRAG de Microsoft comme référence.

1. Vérifier que le besoin justifie un graphe

Je commencerais par préparer quelques questions auxquelles un RAG vectoriel répond mal :

• quels incidents partagent la même dépendance technique ?
• quelles décisions ont affecté plusieurs produits ou équipes ?
• quels thèmes reviennent dans l'ensemble des retours clients ?

Ces questions demandent de relier plusieurs informations ou de synthétiser une grande partie des documents. Si un RAG classique y répond déjà correctement, le graphe n'est peut-être pas nécessaire.

2. Préparer les documents

Comme dans un RAG classique, les documents sont découpés en passages. Microsoft les appelle des TextUnits. Chaque passage reste lié à son document d'origine afin de pouvoir retrouver et citer la source.

Il faut aussi préciser les éléments importants à repérer dans ces textes. Ce sont les entités : par exemple des personnes, des entreprises, des produits, des services ou des incidents. Leur nature dépend du contenu et des questions auxquelles l'application doit répondre.

Si ces entités et leurs relations existent déjà dans les données de l'entreprise, Microsoft GraphRAG peut partir de ce graphe au lieu de les extraire des documents.

3. Construire l'index GraphRAG

Un LLM lit chaque passage pour identifier les entités et décrire leurs relations. Par exemple, il peut repérer qu'un produit dépend d'un service et que ce service est mentionné dans plusieurs incidents.

GraphRAG regroupe ensuite les entités fortement liées en communautés, puis génère un résumé de chaque groupe. Ces résumés donnent une vue d'ensemble du corpus, tandis que les passages d'origine conservent les détails. Des embeddings permettent enfin de retrouver les éléments proches d'une question.

Cette préparation est plus lourde que celle d'un RAG classique, car elle demande plusieurs analyses et résumés par le LLM. Microsoft recommande donc de commencer avec un petit corpus.

4. Choisir le mode de recherche adapté à la question

Une fois l'index construit, il faut choisir la recherche adaptée à la question :

• Local Search convient à une question ciblée sur une personne, un produit ou un autre élément précis. Il retrouve les entités proches de la question, puis rassemble leurs relations et les passages sources utiles.
• Global Search convient à une question sur l'ensemble des documents, comme « quels sont les principaux thèmes ? ». Il s'appuie sur les résumés des communautés pour construire une réponse générale.
• DRIFT Search commence par une vue d'ensemble, puis approfondit progressivement certains points avec des recherches plus ciblées.

Il n'existe donc pas un unique parcours GraphRAG. Une question ciblée sur une entité n'appelle pas la même recherche qu'une demande sur les grands thèmes de toute la base.

5. Comparer les résultats sur un petit corpus

Je testerais d'abord GraphRAG sur quelques documents dont je connais bien le contenu. Le projet inclut aussi une recherche vectorielle simple, utile pour comparer ses résultats avec les recherches locale et globale.

J'utiliserais les mêmes questions pour comparer la qualité des réponses, le coût de préparation des données et le temps de réponse. Je vérifierais aussi que les entités et les relations extraites correspondent bien aux documents sources. Cette comparaison permet de vérifier que le graphe apporte un gain réel avant de l'étendre à toute une base documentaire.

RAG ou GraphRAG : comment choisir ?

Ce que je teste maintenant avec GraphRAG

Le GraphRAG a attiré mon attention par sa promesse de retrouver des relations qu'une recherche vectorielle ne trouve pas. Je le teste actuellement sur un prototype, sans l'avoir encore intégré à l'un de mes projets en ligne.

Je veux vérifier trois points :

1. un graphe retrouve-t-il mieux les relations dispersées dans plusieurs documents ?
2. apporte-t-il une réponse plus complète aux questions en plusieurs étapes et aux synthèses globales ?
3. ce gain compense-t-il le coût d'indexation, la complexité de mise à jour et le temps de réponse supplémentaire ?

Je compare ces tests à un RAG vectoriel, puis à une version avec recherche hybride et reranking. Si cette dernière répond aussi bien, le graphe n'est pas justifié.

C'est ma façon d'aborder le métier de Product Engineer à l'ère de l'IA : partir du problème, construire la plus petite version utile, mesurer, puis ajouter de la complexité seulement lorsqu'elle améliore réellement le produit.

Pour la plupart des chatbots documentaires, je commencerais donc par un bon RAG. GraphRAG devient intéressant lorsque les questions exigent de suivre des relations ou de synthétiser un corpus entier. La meilleure architecture reste celle qui retrouve la bonne preuve, au bon moment, avec un coût acceptable.

📌 Vous souhaitez connecter un chatbot ou une fonctionnalité IA aux données de votre produit ? Je peux vous accompagner pour cadrer le cas d'usage, construire le pipeline de recherche et mesurer sa qualité avec une approche complète de Product Engineering.

Questions fréquentes sur RAG et GraphRAG

Qu'est-ce que le RAG en intelligence artificielle ?

Quelle différence entre RAG et GraphRAG ?

Faut-il une base vectorielle pour faire du RAG ?

Le GraphRAG remplace-t-il le RAG vectoriel ?

Quand utiliser le GraphRAG ?

Le RAG empêche-t-il les hallucinations ?

Sources

• Patrick Lewis et al., « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks ».
• Microsoft Research, « From Local to Global: A Graph RAG Approach to Query-Focused Summarization ».
• Microsoft GraphRAG, documentation du pipeline d'indexation.
• Microsoft GraphRAG, documentation des modes de recherche.
• Microsoft GraphRAG, utiliser un graphe existant.
• Microsoft GraphRAG, guide de démarrage et avertissement sur le coût de l'indexation.
• Microsoft, guide de la phase de récupération et du reranking d'une solution RAG.
• Anthropic, « Contextual Retrieval ».
• Sentence Transformers, guide « Retrieve & Re-Rank » avec bi-encoder et cross-encoder.
• AWS, bonnes pratiques de rédaction des sources pour un RAG.
• Neo4j, documentation du package GraphRAG pour Python.
• Shahul Es et al., « RAGAS: Automated Evaluation of Retrieval Augmented Generation ».