Fondamentaux de la récupération augmentée pour l’IA générative

L’émergence des grands modèles de langage (large language models, LLM) a ouvert des perspectives considérables pour l’automatisation des tâches cognitives. Cependant, leur architecture présente des limites structurelles : leur connaissance est un instantané statique du passé et leur mémoire de travail est finie. Pour être véritablement utiles en entreprise, ces systèmes d’IA doivent fonder leurs réponses sur des données propriétaires, à jour et factuelles. C’est précisément le rôle de l’architecture de génération augmentée par la récupération (Retrieval-Augmented Generation, RAG). Toutefois, face à des corpus de données où les relations et les connexions sont aussi importantes que le contenu textuel lui-même, une nouvelle approche s’impose. L’enjeu n’est plus seulement de trouver l’information, mais de raisonner sur ses liens.

Cet article propose un cadre de décision pour arbitrer entre deux architectures fondamentales : le RAG traditionnel et le Graph RAG. Il s’agit de comprendre leurs mécanismes, d’évaluer leurs forces respectives et de définir les critères objectifs qui doivent guider le choix d’une architecture capable de transformer des données complexes en un avantage compétitif. La décision entre RAG et Graph RAG conditionne directement la capacité d’un système d’IA à passer d’une simple restitution d’information à un véritable raisonnement opérationnel.

Le principe du RAG traditionnel : combler les lacunes des LLM

Le RAG est une architecture conçue pour résoudre deux des problèmes les plus critiques des LLM : le manque de connaissances spécifiques à un domaine et la tendance aux hallucinations de l’IA. Plutôt que de s’appuyer uniquement sur les informations apprises lors de son entraînement, un système RAG ancre les réponses du LLM dans une base de connaissances d’IA externe et contrôlée. Le processus est pragmatique : lorsqu’un utilisateur pose une question, le système ne la soumet pas directement au LLM. Il l’utilise d’abord comme une requête pour interroger une base de données documentaire (par exemple, des rapports internes, des contrats, des fiches produits).

Les extraits les plus pertinents sont alors récupérés et injectés dans le prompt final, aux côtés de la question initiale. Le LLM dispose ainsi d’un contexte factuel et précis pour formuler sa réponse. En pratique, cette technique transforme le modèle de langage en un synthétiseur intelligent qui travaille sur des documents fournis en temps réel, garantissant des réponses plus fiables, traçables et pertinentes pour les cas d’usage d’une génération augmentée par la récupération pour l’entreprise. L’architecture de base de la récupération d’information (Information Retrieval), comme le décrit la littérature académique de l’université de Stanford, repose sur le modèle de l’espace vectoriel pour faire correspondre requêtes et documents.

Les limites inhérentes à la recherche sur données non structurées

Si le RAG traditionnel est efficace pour les questions dont la réponse se trouve dans des segments de texte contigus, il atteint ses limites lorsque la requête exige une compréhension transversale ou un raisonnement multi-étapes. Le problème fondamental ne réside pas dans la capacité de génération du LLM, mais dans la phase de récupération. Une recherche sémantique standard, même performante, opère sur des fragments de texte isolés, ignorant les relations implicites qui les relient.

Cette approche linéaire peine à répondre aux questions qui nécessitent de connecter des points d’information dispersés dans de multiples documents. La pertinence du système RAG d’entreprise dépend entièrement de sa capacité à trouver le « bon » fragment, ce qui présente plusieurs faiblesses structurelles :

• Difficulté à synthétiser des informations fragmentées : Si la réponse à « Quels sont les impacts du projet A sur les fournisseurs du projet B ? » nécessite de croiser un rapport de projet et plusieurs contrats fournisseurs, une recherche par similarité risque de ne remonter qu’un seul type de document, fournissant une réponse incomplète.
• Incapacité à découvrir des relations indirectes : Le RAG ne peut pas identifier des liens de cause à effet ou des corrélations si ceux-ci ne sont pas explicitement décrits dans un même passage. Il ne peut pas déduire que deux personnes ayant travaillé pour la même entreprise à la même période ont potentiellement collaboré.
• Perte de contexte global : En découpant les documents en fragments indépendants (chunks), le processus RAG perd la vision d’ensemble. La relation entre un chapitre d’introduction et une annexe technique, pourtant essentielle, est dissoute lors de l’indexation.
• Vulnérabilité aux requêtes exploratoires : Pour des questions ouvertes comme « Identifiez les risques cachés dans notre chaîne d’approvisionnement », le RAG est peu performant. Il n’est pas conçu pour naviguer dans un réseau de dépendances, mais pour trouver des correspondances textuelles.

L’architecture du RAG : un mécanisme de recherche sémantique

Comprendre le fonctionnement interne du RAG est essentiel pour saisir à la fois sa puissance et ses limitations. L’architecture se décompose en deux phases distinctes : une phase préparatoire d’indexation, réalisée en amont, et une phase d’exécution en temps réel pour répondre aux requêtes. La distinction entre RAG et Graph RAG réside principalement dans la nature et la structure de la base de connaissances interrogée.

Le processus d’indexation et de vectorisation des documents

La première étape, dite offline, consiste à préparer la base de connaissances documentaire pour qu’elle soit interrogeable par la machine. Ce processus suit une chaîne de traitement rigoureuse, dont la qualité conditionne la performance de l’ensemble du système.

1. Chargement des données : Le système ingère les documents sources depuis divers répertoires (GED, bases de données, sites web).
2. Segmentation (Chunking) : Les documents sont découpés en fragments de texte plus petits et sémantiquement cohérents. La taille de ces fragments est un paramètre crucial : trop petits, ils perdent leur contexte ; trop grands, ils « noient » l’information pertinente dans du bruit.
3. Vectorisation (Embedding) : Chaque fragment est ensuite traité par un modèle de langage spécialisé (modèle d’embedding) qui le transforme en un vecteur numérique. Ce vecteur, ou embedding, représente la signification sémantique du texte dans un espace mathématique de haute dimension. Ce processus de vectorisation des données est au cœur de la recherche sémantique.
4. Indexation : Ces vecteurs sont stockés et indexés dans une base de données vectorielle. Cette base est optimisée pour effectuer des recherches de similarité à très grande vitesse sur des millions, voire des milliards de vecteurs, un processus connu sous le nom d’indexation vectorielle.

La stratégie de récupération et de contextualisation de la réponse

La seconde phase, dite online, est déclenchée par une requête de l’utilisateur. C’est ici que l’architecture RAG démontre son efficacité pour augmenter le LLM.

1. Vectorisation de la requête : La question de l’utilisateur est transformée en vecteur en utilisant le même modèle d’embedding que pour les documents.
2. Recherche de similarité : Le système interroge la base de données vectorielle. Il utilise une mesure mathématique (généralement la similarité cosinus) pour trouver les N vecteurs de documents les plus proches du vecteur de la requête. Ces vecteurs correspondent aux fragments de texte sémantiquement les plus pertinents.
3. Construction du contexte : Les fragments de texte récupérés sont rassemblés et formatés en un contexte unique.
4. Génération de la réponse : Ce contexte, ainsi que la question originale de l’utilisateur, sont insérés dans un prompt final. Ce prompt est ensuite soumis au LLM, qui génère une réponse synthétique et factuellement ancrée dans les informations fournies. L’architecture globale d’un tel système est un sujet fondamental en recherche d’information.

Introduction au Graph RAG : raisonner sur les données connectées

Face aux limites du RAG traditionnel pour le traitement de données complexes et interconnectées, l’approche RAG et Graph RAG propose une évolution majeure. Elle ne remplace pas la recherche sémantique mais l’enrichit en s’appuyant sur une représentation structurée des connaissances : le graphe de connaissance. Cette structure permet à l’IA de naviguer activement dans les relations entre les informations, au lieu de se contenter de récupérer des blocs de texte isolés.

Le rôle du graphe de connaissance comme base de savoir structurée

Un graphe de connaissance (knowledge graph) est une base de données qui modélise l’information sous forme d’un réseau d’entités (les nœuds) et de relations (les arêtes). Par exemple, une entité « Société A » peut être liée à une entité « Personne B » par la relation « est employeur de », et à une entité « Produit C » par la relation « fabrique ». Cette représentation capture explicitement les connexions qui restent implicites et cachées dans des documents non structurés.

Construire un graphe de connaissance est un effort de modélisation plus conséquent que la simple indexation de textes. Il nécessite d’extraire des entités nommées (personnes, lieux, organisations), de les dé-dupliquer et d’identifier les relations qui les unissent. Cependant, l’investissement initial offre un avantage décisif : il transforme une collection de documents en une base de savoir sur laquelle une machine peut raisonner. Pour l’IA, naviguer dans ce graphe s’apparente à suivre un fil de pensée logique. Pour maximiser la pertinence, les systèmes les plus avancés s’appuient sur un pilotage par une IA de gouvernance. Pour fournir un exemple concret, Algos a développé le CMLE (Contextual Multi-Level Expert) Orchestrator, une IA capable de consulter dynamiquement des sources de savoirs hiérarchisées, incluant des architectures RAG et Graph RAG, pour garantir que chaque réponse est fondée sur la source de vérité la plus fiable.

Un mécanisme hybride : recherche vectorielle et parcours de graphe

Le Graph RAG n’est pas une alternative au RAG, mais une extension qui combine le meilleur des deux mondes. Comme le souligne une enquête technique publiée sur arXiv, le Graph RAG innove sur trois axes : une représentation des connaissances structurée, des techniques de récupération basées sur le graphe pour un raisonnement multi-sauts, et des algorithmes d’intégration sensibles à la structure. Son fonctionnement est souvent hybride et séquentiel.

Une requête utilisateur peut d’abord faire l’objet d’une recherche sémantique classique pour identifier les nœuds les plus pertinents dans le graphe (par exemple, trouver l’entité « Projet X »). À partir de ce point d’entrée, le système ne s’arrête pas. Il explore activement le graphe en suivant les relations connectées pour découvrir des informations contextuelles adjacentes. Ce processus de parcours de graphe permet de collecter des faits liés que le RAG seul n’aurait jamais pu associer.

Ce mécanisme hybride offre plusieurs avantages clés :

• Enrichissement contextuel : Le système peut récupérer non seulement la description du « Projet X », mais aussi les noms des membres de l’équipe, les technologies utilisées, et les projets dépendants, en naviguant simplement dans le graphe.
• Raisonnement multi-sauts (multi-hop) : Il peut répondre à des questions complexes comme « Quels experts en cybersécurité ont travaillé sur des projets utilisant la technologie Y pour le client Z ? ». Cela requiert de naviguer de Z à Y, puis aux projets associés, et enfin aux experts impliqués.
• Découverte de liens cachés : L’exploration du graphe peut révéler des connexions inattendues, par exemple qu’un fournisseur à risque travaille sur deux projets critiques différents, un signal faible impossible à détecter avec une recherche textuelle standard.
• Explicabilité des réponses : La réponse générée peut être accompagnée du chemin de raisonnement suivi dans le graphe, offrant une traçabilité et une transparence inégalées.

Analyse comparative : RAG vs. Graph RAG

Le choix entre RAG et Graph RAG n’est pas une question de supériorité absolue, mais d’adéquation entre l’architecture et la nature des données à traiter, ainsi que la complexité des questions à résoudre. Une analyse comparative directe permet de clarifier leurs domaines d’excellence respectifs et de guider une décision éclairée.

Différences clés dans le traitement et la structure des données

La distinction la plus fondamentale entre les deux approches réside dans la manière dont elles représentent et interrogent la connaissance. Cette différence a des implications profondes sur la préparation des données et la maintenance du système. Une normalisation rigoureuse des données est un prérequis pour construire un graphe de connaissance fiable, tandis que le RAG traditionnel est plus tolérant à l’hétérogénéité.

• Unité d’information : Le RAG opère sur des « fragments » de texte (des paragraphes ou des pages), qui sont des unités de contenu non structuré. Le Graph RAG travaille sur des « entités » et des « relations » (par exemple, « Paris » – « est la capitale de » – « France »), qui sont des unités de savoir atomiques et structurées.
• Représentation des liens : Dans le RAG, les liens entre les informations sont implicites et doivent être déduits par le LLM à partir de la co-occurrence de mots dans le contexte récupéré. Dans le Graph RAG, les liens sont explicites, typés et font partie intégrante de la base de données.
• Préparation des données : Le RAG nécessite principalement un pipeline de segmentation et de vectorisation, qui est largement automatisable. Le Graph RAG exige en plus une phase d’extraction d’entités et de relations (via des techniques de NLP ou des règles métier) et de modélisation d’un schéma (ontologie), ce qui représente un investissement initial plus important.
• Flexibilité vs. Précision : Le RAG est plus flexible et rapide à mettre en place sur des corpus de documents existants. Le Graph RAG est moins flexible mais offre une précision et une profondeur d’interrogation bien supérieures sur les domaines où les relations sont primordiales.

Impact sur la pertinence et la capacité de raisonnement des réponses

L’impact le plus visible pour l’utilisateur final concerne la qualité et la nature des réponses générées. Alors que les deux systèmes visent à améliorer la pertinence, ils excellent dans des types de tâches différents. Le choix entre RAG et Graph RAG détermine la profondeur analytique du système d’IA.

Des recherches récentes, comme celles publiées dans les actes de l’ACM sur l’optimisation des systèmes de questions-réponses, comparent systématiquement les performances de ces architectures. Les défis liés au raisonnement multi-sauts dans les systèmes Graph RAG complexes font l’objet d’études approfondies, comme le montre un article de recherche sur GraphRAG-R1, qui explore l’utilisation de l’apprentissage par renforcement pour améliorer cette capacité.

Le tableau suivant synthétise les différences de performance selon plusieurs critères clés :

Critère	RAG Traditionnel	Graph RAG
Type de requête idéal	Questions factuelles directes (« Quelle est la clause de résiliation du contrat X ? »).	Questions exploratoires et analytiques (« Quels sont les projets impactés par le départ de l’expert Y ? »).
Capacité de raisonnement	Limitée à la synthèse des informations contenues dans les fragments récupérés.	Élevée, capable de raisonnement déductif et inférentiel en suivant les chemins du graphe (multi-sauts).
Gestion de la complexité	Efficace pour des documents longs mais isolés. Inefficace pour des écosystèmes d’informations connectées.	Conçu pour la complexité relationnelle. Excelle dans la modélisation de dépendances, hiérarchies et réseaux.
Précision de la réponse	Élevée si la réponse est contenue dans un seul fragment bien identifié.	Très élevée pour les questions nécessitant la fusion de faits multiples et connectés.
Explicabilité	Limitée : peut citer les documents sources.	Forte : peut visualiser le chemin de raisonnement exact à travers le graphe.

En pratique, un moteur RAG avancé comme OmniSource Weaver, la technologie propriétaire d’Algos, est optimisé pour garantir que les réponses sont ancrées dans les extraits les plus pertinents des documents sources, maximisant la fidélité factuelle pour les requêtes directes. Le Graph RAG, en revanche, est conçu pour aller au-delà de la simple restitution et découvrir des insights à partir des connexions.

Critères de décision : quand basculer vers le Graph RAG ?

La décision de passer d’une architecture RAG à une architecture intégrant le Graph RAG doit être guidée par une analyse pragmatique de la nature de vos données et des objectifs métiers visés. Il ne s’agit pas d’une mise à niveau technologique systématique, mais d’un choix stratégique qui doit être justifié par un besoin avéré de raisonnement sur des données connectées.

Évaluer la complexité et la connectivité de vos données

Le premier axe d’analyse concerne votre patrimoine informationnel. Toutes les bases de connaissances ne se prêtent pas à une représentation sous forme de graphe ou n’en tirent pas un bénéfice suffisant pour justifier l’investissement. Le choix entre RAG et Graph RAG dépend de la structure intrinsèque de votre savoir.

Le tableau ci-dessous propose une grille d’analyse pour identifier les signaux qui plaident en faveur d’une architecture Graph RAG.

Signal de complexité	Description	Implication pour le choix
Haute densité d’entités nommées	Vos documents mentionnent fréquemment les mêmes personnes, entreprises, produits, projets ou régulations.	Un graphe peut unifier ces mentions, créant une vue à 360 degrés sur chaque entité clé.
Importance des relations	La compréhension des liens (hiérarchiques, causals, temporels) est cruciale pour votre métier.	Le Graph RAG est nativement conçu pour modéliser et exploiter ces relations, là où le RAG est aveugle.
Besoin de raisonnement multi-sauts	Les réponses aux questions importantes nécessitent de croiser des informations de plusieurs sources ou types de documents.	Le parcours de graphe est le mécanisme idéal pour ce type de raisonnement, impossible avec le RAG seul.
Nature des données hétérogène	Vous devez intégrer des données structurées (bases SQL) avec des données non structurées (textes, emails).	Un graphe de connaissance peut servir de couche sémantique unifiée pour réconcilier ces silos de données.
Volonté d’exploration et de découverte	Vos utilisateurs cherchent à découvrir des tendances, des risques ou des opportunités non évidents.	Le graphe permet une navigation et une exploration des données qui favorisent la sérendipité et la découverte d’insights.

Aligner l’architecture sur les cas d’usage et les objectifs métiers

Le second axe est fonctionnel. La pertinence d’une technologie se mesure à sa capacité à résoudre des problèmes concrets et à générer de la valeur. Le choix entre RAG et Graph RAG doit être directement lié aux cas d’usage que vous souhaitez adresser.

• Le RAG traditionnel est suffisant pour :

  • Agents conversationnels de support client (Niveau 1) : Répondre à des questions factuelles basées sur une base de connaissances (FAQ, manuels produits). Des systèmes de questions-réponses pour le service client basés sur les LLM intègrent souvent des graphes de connaissance pour améliorer la performance.
  • Moteurs de recherche documentaire améliorés : Permettre aux employés de trouver rapidement des informations précises dans de vastes corpus internes (SharePoint, Confluence).
  • Assistants de rédaction : Aider à la génération de résumés ou de brouillons de documents en se basant sur des sources spécifiques. Un cas d’usage comme le RAG juridique est un excellent exemple.

• Le Graph RAG devient indispensable pour :

  • Systèmes d’aide à la décision stratégique : Analyser des écosystèmes complexes (marchés, concurrents, chaînes logistiques) pour identifier des menaces et opportunités.
  • Analyse de fraude et de conformité : Détecter des réseaux de fraudeurs ou des schémas de blanchiment d’argent en identifiant des relations inhabituelles entre des transactions et des entités.
  • Découverte scientifique et R&D : Accélérer la recherche en aidant les scientifiques à formuler et valider des hypothèses en connectant des informations issues de milliers d’articles de recherche et de brevets.
  • Intelligence commerciale et gestion des risques : Comprendre l’impact en cascade d’un événement (par exemple, la faillite d’un fournisseur) sur l’ensemble de son portefeuille de projets et de clients.

Des plateformes avancées permettent de construire des systèmes d’agents autonomes qui tirent parti de la bonne architecture pour la bonne tâche. Par exemple, le framework Lexik d’Algos est conçu pour orchestrer des agents intelligents qui peuvent utiliser une approche RAG pour des tâches de récupération simple et basculer vers une exploration de graphe pour des missions d’analyse stratégique, comme l’enrichissement de fiches contact ou le déclenchement d’interventions préventives.

Implications stratégiques et opérationnelles du choix d’architecture

Adopter une architecture RAG ou Graph RAG n’est pas seulement une décision technique ; c’est un choix qui engage l’organisation sur le long terme en matière de gouvernance des données, de maintenance des systèmes et de mesure de la performance. Chaque approche implique des contraintes et des exigences opérationnelles spécifiques qu’il est crucial d’anticiper.

Gouvernance et gestion des bases de connaissances respectives

La viabilité d’un système d’IA repose sur la qualité, la fraîcheur et la fiabilité de sa base de connaissance. Les processus de gouvernance pour un RAG textuel et un Graph RAG diffèrent considérablement.

La maintenance d’une base vectorielle pour un RAG sécurisé est relativement simple. Elle consiste principalement à mettre en place des pipelines automatisés pour synchroniser les documents : à chaque ajout, modification ou suppression d’un fichier source, le système doit mettre à jour les fragments et les vecteurs correspondants dans la base. L’enjeu principal est la gestion des versions et le contrôle d’accès.

En revanche, la construction et la maintenance d’un graphe de connaissance sont une discipline plus exigeante. Elles requièrent :

• Une modélisation sémantique (ontologie) : Il faut définir en amont les types d’entités et de relations que le graphe doit capturer. Cette ontologie est le squelette du graphe et doit être alignée avec la terminologie métier.
• Des processus ETL complexes : Il faut développer des chaînes de traitement pour extraire les entités et les relations à partir de sources structurées et non structurées, les nettoyer, les dé-dupliquer et les charger dans le graphe.
• Une gouvernance de la qualité des données : La validité des liens dans le graphe est critique. Des mécanismes de validation, de correction et d’enrichissement continus sont nécessaires pour éviter la propagation d’erreurs qui fausseraient le raisonnement de l’IA.

Quelle que soit l’architecture, la souveraineté des données est un impératif. Des acteurs comme Algos s’engagent à garantir une souveraineté totale en assurant un hébergement et un traitement 100 % en France pour leurs clients français, dans le respect strict du RGPD et de l’EU AI Act.

Mesurer la performance : indicateurs pour chaque système d’IA

Évaluer l’efficacité d’un système RAG ou Graph RAG nécessite d’aller au-delà des métriques traditionnelles de performance des modèles. Les indicateurs clés de performance (KPI) doivent refléter la finalité métier de l’application. Des benchmarks académiques sont développés pour évaluer rigoureusement ces systèmes.

Pour les deux architectures, on suivra des métriques communes :

• Précision et Rappel (Retrieval) : Le système récupère-t-il les bonnes informations (précision) et toutes les bonnes informations (rappel) ?
• Fidélité factuelle (Generation) : La réponse générée est-elle entièrement conforme aux sources fournies ?
• Latence : Quel est le temps de réponse total du système, de la requête à la génération ?

Toutefois, le Graph RAG introduit des dimensions d’évaluation supplémentaires, plus qualitatives mais essentielles :

• Pertinence du raisonnement : Le chemin suivi dans le graphe pour arriver à la réponse est-il logique et pertinent ? Le système a-t-il identifié les connexions les plus importantes ?
• Capacité d’explicabilité (XAI) : Le système est-il capable de présenter le parcours dans le graphe de manière intelligible pour un utilisateur humain, justifiant ainsi sa conclusion ?
• Taux de découverte d’insights : Le système permet-il de mettre en lumière des relations ou des faits nouveaux et actionnables qui n’étaient pas connus auparavant ?

En définitive, la performance ultime se mesure à la confiance que les utilisateurs accordent au système. Pour cela, des garanties fortes sont nécessaires. À titre d’exemple, Algos s’appuie sur le cycle de validation itératif de son CMLE Orchestrator pour garantir un taux d’hallucination inférieur à 1 %, un indicateur de fiabilité qui transcende l’architecture de récupération sous-jacente et assure une pertinence factuelle absolue. Le choix entre RAG et Graph RAG est donc une étape fondamentale, mais il s’inscrit dans une démarche plus large de conception d’une IA d’entreprise pertinente, gouvernée et souveraine.