RAG contre Agentic RAG contre Graph RAG : choisir la bonne architecture de récupération
Découvrez comment le RAG naïf échoue face aux questions à plusieurs étapes et aux données structurées, ainsi que la manière dont les boucles agentiques et la récupération basée sur des graphes résolvent chacune des faiblesses distinctes.
Le problème que RAG a été conçu pour résoudre
Tout modèle de langage de grande taille possède des connaissances dont l’accumulation s’arrête une fois l’entraînement terminé, et il ne peut raisonner que sur ce qui entre dans sa fenêtre de contexte. La génération augmentée par récupération de données remédie à cela en intégrant une mémoire externe que le modèle peut consulter pour répondre à une question. Au lieu de dépendre uniquement de ce qu’il a appris pendant l’entraînement, le modèle extrait du texte pertinent d’une collection de documents et utilise ce matériel pour fonder sa réponse.
Les étapes de base vous sont probablement déjà familières :
- Les documents sources sont divisés en plus petits fragments et convertis en embeddings vectoriels.
- Ces embeddings sont stockés dans une base de données vectorielle — Pinecone, Weaviate, pgvector et d’autres outils similaires sont des choix courants.
- Lorsqu’un utilisateur soumet une requête, celle-ci est également convertie en embedding à l’aide de la même méthode.
Toute cette séquence s’exécute une seule fois, du début à la fin : une recherche, une génération. Cela est peu coûteux, son comportement est facile à comprendre, et pour une large gamme d’utilisations — la recherche dans des documents internes, la réponse à des questions de support à partir d’une base de connaissances, ou la gestion de Q&A sur un ensemble statique de documents — il fonctionne parfaitement bien.
Où le RAG naïf échoue
Lorsque ce processus simple échoue, les problèmes relèvent généralement de quelques catégories reconnaissables :
- Questions nécessitant la connexion de plusieurs faits. Une question comme « quels fournisseurs ont renouvelé leurs contrats après la mise à jour de la politique du 3e trimestre ? » requiert deux informations distinctes qui se trouvent presque certainement dans des sections différentes. La similarité vectorielle identifie les sections qui ressemblent sémantiquement à la requête, et non la combinaison précise de faits nécessaire pour y répondre.
- Aucune condition d’arrêt intégrée. Le système renvoie toujours ses k meilleures sections, que celles-ci contiennent réellement la réponse ou non. Lorsque la vraie réponse se trouve en dehors de cet ensemble des k meilleures sections, le modèle invente soit quelque chose de plausible, soit donne une réponse évasive et inutile.
- Aucun boucle de rétroaction. Si la recherche initiale échoue, rien dans le processus ne détecte cela et n’essaie de formuler une requête plus adaptée. Il continue simplement avec ce qu’il a obtenu.
Aucun de ces problèmes n’est vraiment un bug ; ce sont des conséquences naturelles de l’hypothèse fondamentale inscrite dans l’architecture — à savoir que la recherche de similarité sur des fragments de texte non connectés suffit à remplacer une véritable pertinence. Agentic RAG et Graph RAG ciblent chacun un point faible différent de cette hypothèse.
Agentic RAG : Intégrer un cycle de décision à la récupération d’informations
Agentic RAG remplace la séquence rigide « récupérer puis générer » par un cycle dans lequel un LLM agit comme orchestrateur — décidant de ce qu’il faut rechercher, s’une autre recherche est nécessaire, et quand il a suffisamment d’informations pour produire une réponse.
Au lieu d’une seule étape de récupération, le processus se déroule plutôt comme suit :
- Le modèle lit la requête et détermine quelles informations il a réellement besoin.
- Il décide si une récupération est même nécessaire, et le cas échéant, il construit une requête de recherche — en décomposant potentiellement une question complexe en sous-questions plus simples.
- Il récupère les résultats, évalue s’ils sont suffisants, et s’ils ne le sont pas, il réécrit la requête et la renvoie.
- Il peut puiser dans plusieurs sources différentes selon les besoins — un stockage vectoriel, une base de données SQL, une API de recherche web, un service interne — en fonction des exigences de la question.
- Ce n’est qu’après avoir conclu disposer de preuves suffisantes qu’il produit une réponse finale.
En réalité, cela insère le RAG au sein d’un cycle agentiel, en empruntant le même schéma d’appel d’outils utilisé par les assistants de codage : planifier, agir, observer le résultat, puis décider s’il faut continuer. La récupération d’informations n’est plus une étape obligatoire en premier lieu et devient simplement l’un parmi plusieurs outils, invoqués de manière sélective plutôt que automatiquement à chaque demande.
Le bénéfice est la flexibilité. Une question simple déclenche une seule recherche ; une question nécessitant trois recherches successives dans différents systèmes obtient précisément cela. Cette configuration permet également l’autocorrection — si les fragments récupérés sont clairement erronés, l’agent peut le reconnaître et formuler une autre requête au lieu de répondre avec assurance à partir d’un contexte peu fiable.
Ce niveau de flexibilité a un coût réel. Chaque étape de planification et chaque étape d’évaluation représentent en soi une appel distinct au modèle, ce qui entraîne davantage d’appels à l’LLM par requête, une latence plus élevée, ainsi qu’un profil de coûts beaucoup plus difficile à prévoir à l’avance. L’approche Agentic RAG fonctionne bien lorsque la complexité des requêtes varie fortement d’une demande à l’autre, car un pipeline unique et fixe gaspillerait des ressources pour les questions simples ou ne suffirait pas pour celles qui sont complexes. C’est un choix moins adapté lorsque l’on a besoin d’une latence constamment faible, ou lorsque les requêtes sont suffisamment ciblées pour que un récupérateur de données à une seule tentative, soigneusement ajusté, puisse déjà les gérer efficacement.
Graph RAG : récupérer la structure détruite par le chunking
Graph RAG vise une limitation complètement différente : la recherche vectorielle classique sur des chunks ne prend pas en compte de manière intégrée la façon dont les entités sont liées les unes aux autres.
Au lieu de s’appuyer uniquement sur un index vectoriel (bien qu’il puisse encore en utiliser un en complément), Graph RAG construit un graphe de connaissances directement à partir du matériel source. Cela implique l’extraction d’entités — personnes, produits, organisations, concepts — ainsi que des relations qui les relient, telles que « travaille chez », « dépend de », « est causé par » ou « est une version de ». La récupération cesse alors d’être purement une recherche de similarité pour devenir en partie un problème de parcours de graphe : à partir d’une entité pertinente, le système peut passer à des entités connectées et obtenir des informations qui ne seraient jamais mises en évidence uniquement par une correspondance de mots-clés ou d’encodages, simplement parce qu’elles se trouvent à plusieurs relations de distance dans un document complètement différent.
La recherche GraphRAG de Microsoft est l’implémentation la plus citée de cette approche, et elle intègre une fonctionnalité supplémentaire particulièrement utile pour un type de requête : la détection de communautés. Le système regroupe le graphe en clusters d’entités étroitement liées et précompute un résumé pour chaque cluster. Cela confère à Graph RAG un avantage réel pour les questions portant sur l’ensemble du corpus — comme par exemple « quels sont les thèmes récurrents dans l’ensemble de ces rapports ? » — ce qui correspond précisément à la catégorie avec laquelle le RAG naïf a le plus de difficultés, car aucun fragment isolé ne contient la réponse complète ; celle-ci n’apparaît que par la synthèse de l’ensemble des données.
Les coûts ici sont structurels, et non accessoires. La construction du graphe est coûteuse, car elle nécessite d’effectuer une extraction des entités et des relations sur l’ensemble du corpus, généralement assurée par un LLM, en plus de l’étape supplémentaire de génération de résumés des communautés. De plus, cette méthode ne convient pas aux corpus qui changent fréquemment, car le graphe doit être reconstruit ou mis à jour de manière incrémentale chaque fois que des documents changent — une opération bien plus lourde que simplement ajouter un nouveau vecteur dans un index d’incorporation.
Comparaison des trois approches
Il convient de souligner que ces approches ne sont pas mutuellement exclusives. Un schéma courant en pratique consiste à utiliser un cycle agentique équipé à la fois d’un récupérateur de vecteurs et d’un récupérateur de graphes en tant qu’outils disponibles, permettant à l’agent de choisir entre eux ou d’en utiliser les deux, en fonction des exigences de la requête. La couche agente constitue en réalité une stratégie d’orchestration qui se situe au-dessus de n’importe quel mécanisme de récupération utilisé, ce qui lui permet de s’intégrer naturellement à Graph RAG plutôt que de concurrencer ce dernier.
Un cadre décisionnel pratique
Au lieu de choisir une approche simplement parce qu’elle est actuellement populaire, il est utile de suivre un processus décisionnel concret :
- Commencez par un RAG naïf. C’est l’option la moins coûteuse à mettre en place et à dépanner, et pour une grande partie des applications du monde réel, elle est déjà suffisante. Évitez d’ajouter de la complexité avant d’avoir des preuves que vous en avez réellement besoin.
- Passez à un RAG agentiel dès que vous observez des schémas d’échec spécifiques : des questions nécessitant la récupération d’informations à partir de plusieurs sources, des réponses erronées parce que le modèle devait chercher, évaluer ce qu’il avait trouvé, puis chercher à nouveau, ou un volume de travail mélangeant des requêtes simples et complexes d’une manière qui rend un pipeline fixe soit excessif, soit insuffisant.
La leçon principale reflète un schéma récurrent dans la conception de systèmes : une architecture plus sophistiquée n’est pas intrinsèquement supérieure, elle l’est uniquement face à un type particulier de problème. Le RAG naïf peine avec le raisonnement à plusieurs étapes et les questions relationnelles. Le RAG agentique comble ce manque de capacité de raisonnement en introduisant l’itération. Graph RAG comble le manque relationnel en introduisant une structure. Diagnostiquer correctement le type de problème auquel on est confronté constitue l’étape la plus importante.
Lectures complémentaires
- Pourquoi le coût de l’IA agentielle explose : un modèle de coûts basé sur l’architecture — Explique pourquoi les coûts des agents LLM doivent être mesurés par tâche accomplie et non par appel, et présente des leviers architecturaux tels que le routage des modèles, les budgets de contexte et le cache pour contrôler les dépenses.
- Deuxième cerveau : transformer les transcriptions de réunion en un graphe de connaissances interrogeable — Explique comment un système agentiel extrait des entités à partir des transcriptions de réunion et les stocke dans Cosmos DB afin de permettre une récupération par langage naturel et une exploration du graphe de connaissances.