Choisir une architecture RAG : naïve, avancée, CRAG, GraphRAG, agente.

Pourquoi RAG, et pourquoi un seul design ne suffit pas

Les agents d’IA sont capables, mais ils hallucinent et ne peuvent pas consulter seuls des données spécialisées ou en temps réel. La génération augmentée par récupération de données (RAG) résout ces problèmes en ancrant les réponses de l’agent dans une base de connaissances vérifiée. Cependant, RAG n’est pas une solution unique. La simple recherche vectorielle suffit pour un bot de FAQ de base, mais elle échoue lamentablement face à des raisonnements ou analyses complexes impliquant de nombreux documents. Ce qui suit présente les architectures RAG courantes ainsi qu’un guide pour choisir celle qui convient en fonction des exigences de la tâche.

Ce que fait RAG

RAG récupère des documents depuis une base de connaissances et les utilise pour produire des réponses plus pertinentes. Le diagramme ci-dessous montre le flux allant du stockage des documents, en passant par la récupération vectorielle, jusqu’à la génération par un LLM.

L’idée principale consiste à associer la récupération d’informations, qui s’effectue du stockage à la récupération dans le schéma présenté, à l’IA générative. L’injection de contexte pertinent dans le prompt permet à un modèle de langage de rester lié à des informations réelles. Il peut parcourir des pages de documents spécialisés en quelques secondes, ce qui permet au modèle de langage de répondre avec précision et rapidité aux questions des utilisateurs.

Un flux de travail typique comporte deux phases. La phase hors ligne permet d’ingérer des données brutes et de les préparer en données structurées et recherchables. La phase en ligne récupère les données pertinentes et répond à la question. Une troisième phase mérite d’être ajoutée : un cycle de feedback dans lequel le contexte récupéré est évalué à plusieurs reprises.

Phase 1 : ingestion

La première phase transforme les fichiers bruts en enregistrements structurés et recherchables dans une base de données :

1. Charger des données provenant de sources telles que des PDF, Notion, SQL et Slack, à l’aide d’outils comme LlamaIndex ou LangChain.
2. Nettoyer les éléments indésirables tels que les en-têtes, les pieds de page et les balises HTML.
3. Diviser les documents longs en segments significatifs, par exemple de 500 mots chacun. Les segments trop grands confusent le modèle, tandis que ceux qui sont trop petits perdent le contexte.
4. Intégrer chaque segment à l’aide d’un modèle d’embedding (comme text-embedding-3-small d’OpenAI) afin de convertir le texte en vecteurs.
5. Indexer ces vecteurs dans une base de données vectorielle telle que Pinecone ou Chroma, ce qui permet une recherche sémantique basée sur le sens.

Phase 2 : récupération et génération

Lorsqu’un utilisateur pose une question, ce processus s’effectue en quelques millisecondes :

1. Transformation de la requête. Le système transforme la question, par exemple "Comment puis-je réinitialiser mon mot de passe ?", en un vecteur utilisant le même modèle d’embedding que celui employé en Phase 1.
2. Récupération. Il recherche dans la base de données vectorielle les 3 à 5 fragments mathématiquement les plus proches de la question.
3. Reclassement. Un modèle de reclassement vérifie à nouveau les résultats afin que la meilleure correspondance apparaisse en premier.
4. Augmentation. Les fragments récupérés sont intégrés dans le prompt destiné au LLM. Un prompt typique indique au modèle qu’il s’agit d’un assistant utile, lui transmet les fragments en tant que contexte, puis pose la question relative à la réinitialisation du mot de passe.
5. Génération. Le LLM lit le prompt ainsi que le contexte et rédige une réponse basée exclusivement sur les informations qui lui ont été fournies.

Phase 3 : retour d’information

Les résultats de récupération doivent être évalués en continu afin de prévenir les hallucinations. L’évaluation détermine si une réponse repose réellement sur le contexte, tandis que l’observabilité montre précisément quel fragment a entraîné une réponse erronée. Ces constats permettent d’améliorer la stratégie de segmentation dès la Phase 1.

Outils par phase

Les outils RAG constituent les éléments de base qui relient vos données à un modèle de langage, et ils sont classés selon l’étape du processus qu’ils servent. Le choix approprié dépend de la phase sur laquelle vous travaillez.

Le tableau classe la pile technologique RAG par étape du processus.

Une base de données vectorielle est-elle nécessaire ?

Pas strictement. Un stockage vectoriel dédié n’est pas obligatoire pour créer un système RAG, et il existe deux approches plus simples. Avec une approche sans base de données, un petit nombre de documents est divisé en fragments et stocké en RAM. C’est rapide, gratuit et ne nécessite aucune configuration, mais la mémoire est effacée à chaque redémarrage, et les documents volumineux sont lents à traiter. Une approche basée sur une base de données traditionnelle stocke les fragments de texte dans un système comme PostgreSQL et effectue des recherches par mots-clés selon des règles prédéfinies. Elle est efficace pour les phrases uniques telles que le nom d’une personne ou un ID, mais elle ne possède pas de compréhension sémantique : un utilisateur qui cherche des « mammifères » ne trouvera pas de résultat dans un document qui ne mentionne que « chiens ».

Comparaison de six architectures

Aucune configuration n’est adaptée partout. Certaines tâches exigent rapidité et simplicité, d’autres nécessitent une analyse plus approfondie, plusieurs sources ou des entrées non textuelles telles que des images ou des graphiques. Six approches principales couvrent la plupart des besoins : Naive RAG, Advanced RAG, Modular RAG, Corrective RAG (CRAG), GraphRAG et Agentic RAG.

Naive RAG

La forme la plus simple récupère des documents en fonction de la requête et les transmet au modèle sans aucune modification.

Le schéma montre une simple correspondance par similarité vectorielle top-K. La requête est convertie en vecteur, les fragments les plus similaires du top-K proviennent d’une base de données vectorielle, puis ils sont envoyés au LLM. La recherche est sémantique et sa complexité est faible.

• Avantages : il offre les réponses les plus rapides et les coûts de calcul les plus bas, il est facile à mettre en place à l’aide de bibliothèques comme LangChain ou LlamaIndex, et il fonctionne pour la récupération de faits de base à partir de documents propres.
• Faiblesses : des fragments irrelevants peuvent ajouter du bruit qui confond le LLM, il a du mal avec les questions complexes ou à plusieurs parties, et il ne peut pas se corriger lui-même, de sorte qu’une erreur de récupération se transforme en réponse hallucinée.
• Meilleur usage : des questions-réponses simples sur de petits ensembles de données propres, tels que des questions-réponses sur des documents personnels, des FAQ internes d’entreprise et des applications simples de conversation avec des documents.

RAG avancé

Cette variante ajoute de la logique comme le routage des requêtes et le réclassement après l’étape de récupération afin d’améliorer la précision.

Le schéma montre la transformation de la requête avant la récupération et le réclassement après celle-ci. Avant la récupération, la requête est réécrite pour être plus claire. Après la récupération, les résultats sont classés et vérifiés pour que la réponse générée soit aussi pertinente et précise que possible. La recherche est hybride (vecteurs + mots-clés) avec réclassement, et sa complexité est moyenne.

• Points forts : il gère mieux les questions complexes, choisit des approches adaptées aux différentes situations et offre un contrôle plus grand sur la génération du texte.
• Points faibles : le réclassement des résultats augmente la latence, plusieurs appels au modèle par requête entraînent des coûts plus élevés, il y a davantage d’éléments à maintenir, et les composants doivent être ajustés pour fonctionner correctement ensemble.
• Meilleur usage : pour des systèmes exigeants où les erreurs ne sont pas acceptables, tels que des bases de connaissances professionnelles ou des bots de support client.

Modular RAG

Modular RAG utilise une structure « plug-and-play » dans laquelle des modules distincts s’occupent de différentes étapes du flux de travail.

Les composants mis en évidence incluent les modules de recherche et de mémoire. En divisant le système de cette manière, il est possible de personnaliser n’importe quelle partie sans devoir reconstruire le reste : une équipe peut intégrer un moteur de recherche différent, un réordonneur plus performant ou un autre générateur. La récupération des données peut provenir de multiples sources telles que des API, des bases de données et le web, et la complexité est élevée car elle nécessite une couche d’orchestration sophistiquée.

• Forces : chaque composant est facile à ajuster, et ses parties peuvent être mises à niveau ou remplacées sans devoir tout recommencer.
• Faiblesses : le coût de mise en place et la complexité architecturale sont très élevés, ce qui exige une planification préalable ; une équipe d’ingénierie solide est nécessaire pour gérer l’orchestration, et différentes versions de modules peuvent entrer en conflit.

Idéal pour : des systèmes d’entreprise complexes nécessitant une personnalisation approfondie, comme un assistant qui vérifie simultanément Jira, Slack et Google Drive.

RAG correctif (CRAG)

CRAG a été conçu pour vérifier à nouveau ses réponses et les corriger en cas d’anomalie.

Le flux présente une étape d’évaluation complétée par une recherche web de secours. Un modèle d’évaluation attribue une note aux documents récupérés. Lorsque la note est trop basse, le système met de côté la base de données interne et effectue une recherche web pour trouver la réponse ailleurs, comme le montre le chemin pointillé dans la figure. Sa complexité est élevée en raison des branches basées sur de la logique et des appels API externes.

• Avantages : les mauvais résultats de recherche sont corrigés avant que l’utilisateur ne les voie, et cette couche supplémentaire de contrôle qualité rend les réponses plus fiables et précises.
• Faiblesses : la recherche de secours consomme du temps et des ressources informatiques, et le système peut entrer en boucle indéfiniment s’il n’est jamais satisfait de ce qu’il trouve.
• Meilleur usage : pour des travaux à haut risque où des informations erronées ou obsolètes sont inacceptables, comme la recherche médicale et juridique.

GraphRAG

GraphRAG utilise un graphe de connaissances pour structurer les relations entre les différentes informations et ne se base pas uniquement sur la similarité textuelle.

Le schéma montre la navigation dans le graphe de connaissances ainsi que la génération de résumés de communautés. Une fois le graphe créé, le système le parcourt à la recherche de motifs dans les données et non seulement de correspondances de mots, ce qui lui permet de déterminer comment l’Entité A est liée à l’Entité B, même lorsqu’elles apparaissent dans des documents différents. La complexité est très élevée, car il faut créer et maintenir une base de données de graphe structurée.

Une deuxième illustration, tirée d’une représentation de Microsoft Research, montre un graphe de connaissances généré par un LLM à partir d’un ensemble de données privé avec GPT-4 Turbo.

• Forces : il gère des questions complexes reliant plusieurs concepts, évite des réponses dispersées et peut mettre en évidence des résultats inattendus mais pertinents en reliant les éléments entre eux.
• Faiblesses : la création du graphe exige beaucoup d’efforts, il est plus lent que les méthodes RAG de base, et sa qualité limite ses performances, car il n’est aussi bon que les connexions présentes dans le graphe.
• Meilleur usage : pour avoir une vue d’ensemble et effectuer des raisonnements à plusieurs étapes à travers plusieurs sources de données, comme dans le journalisme d’investigation, la détection de fraudes ou la découverte de médicaments.

RAG agent

Dans cette approche dynamique, un agent IA agit comme coordinateur pour planifier, récupérer et affiner la réponse.

Le flux de travail montre un agent de coordination qui utilise des outils pour un raisonnement en plusieurs étapes. Au lieu de saisir les premiers documents pertinents, il planifie une approche, décide de ce qu’il faut examiner et agit à l’aide de ses outils. Il divise la tâche en étapes plus petites, cherche dans diverses sources de données, vérifie si les résultats répondent à la question et continue de chercher s’ils ne le font pas.

• Forces : il convient au raisonnement en plusieurs étapes, permet de faire des choix intelligents pour collecter des informations et peut améliorer les résultats pour des requêtes complexes.
• Faiblesses : de multiples recherches augmentent les coûts, et le travail de type recherche ralentit les réponses.
• Meilleur usage : pour des tâches nécessitant une planification méthodique, comme une analyse approfondie de cas dans la recherche juridique ou une analyse financière combinant des données de marché et des informations réglementaires.

Un parcours de décision en quatre étapes

Aucune règle ne s’applique à tout, mais une approche commune facilite la tâche à accomplir.

Le diagramme de flux guide les architectes entre les solutions Simple, Graph, Corrective et Advanced RAG en fonction des contraintes de la tâche. Les étapes sont les suivantes :

Étape 1 : le test de complexité. La réponse se trouve-t-elle dans un seul document ? Si oui, No-DB RAG pour un petit document, ou Simple RAG, est la meilleure option, car elle est rapide, peu coûteuse et presque facile à mettre en place.

Étape 2 : le test de relation. La réponse nécessite-t-elle de comprendre des hiérarchies complexes ou des liens cachés entre plusieurs sources de données ? Dans ce cas, GraphRAG permet de représenter ces ressources et ces liens, que la recherche de texte brut ne peut pas détecter. Prenons l’exemple : « Quels départements sont affectés par la politique A, et qui en sont les responsables ? » Il faut alors relier les données des départements à celles des employés, et GraphRAG représente les deux en tant qu’entités liées.

Étape 3 : le test de fiabilité et de raisonnement. Le système peut-il se permettre de se tromper ? Lorsque la précision extrême est essentielle, Corrective RAG ou Self-RAG intègrent une étape spécifique qui vérifie si les données récupérées répondent réellement à la question avant de les transmettre à l’utilisateur. Si cette tâche nécessite également un raisonnement en plusieurs étapes, Agentic RAG permet d’assurer une planification et un auto-amélioration grâce à ses agents.

Étape 4 : l’équilibre entre performance et coût. Lorsque la latence est prioritaire, une configuration plus simple comme No-DB, Naive ou Simple RAG est la plus adaptée. Lorsque la qualité prime sur le coût, mais pas au point de requérir la précision extrême de l’Étape 3, Advanced RAG comprend mieux l’intention derrière une requête que les solutions plus simples, au prix d’un temps de traitement plus long.

Quand ne pas utiliser RAG

RAG permet aux modèles de langage de fournir des réponses tenant compte du contexte à partir de vastes ensembles de données privées, sans nécessiter un réentraînement constant. Cependant, il n’est pas utile dans tous les cas, en particulier lorsque une tâche exige un raisonnement approfondi, une synthèse créative ou une maîtrise des schémas linguistiques, plutôt que la consultation d’un document. Dans ces situations, il est généralement préférable de s’en passer :

• Raisonnement général concernant le bon sens, les subtilités éthiques ou le comportement humain en général. On s’appuie sur les poids internalisés du modèle pré-entraîné.
• Consultations de connaissances générales sur des sujets restés inchangés depuis des décennies. Le modèle pré-entraîné suffit, et RAG ne ferait qu’augmenter le temps de réponse sans améliorer la précision.
• Rédaction créative avec un ton et un style spécifiques. On utilise des modèles pré-entraînés ou une fine adaptation, car RAG est superflu.

Problèmes mathématiques ou logiques complexes nécessitant des calculs en plusieurs étapes. L’ajustement fin ou les prompts de type Chain-of-Thought (CoT) conviennent mieux.

Besoins de latence extrêmement faible avec des réponses quasi instantanées. Les opérations d’incorporation, de recherche et d’injection ajoutent tous des surcoûts.

Ensembles de données de petite taille qui tiennent entièrement dans le prompt. Coller les données est plus simple que de créer un pipeline.

Le tableau final compare les performances des modèles RAG, d’ajustement fin et de raisonnement.