Qu’est-ce que l’architecture RAG ? Définition complète et exemples pratiques détaillés

Le RAG, pour « retrieval augmented generation » (génération augmentée par récupération), est un processus dans lequel les LLM s’appuient sur des informations externes pour enrichir et améliorer leurs réponses. L’architecture RAG désigne l’ensemble des composants et des connexions qui rendent le RAG possible.

Il existe plusieurs catégories de RAG, chacune reposant sur sa propre architecture. En substance, l’architecture d’un système RAG détermine la manière spécifique dont les informations sont stockées, récupérées et transmises à un LLM.

Qu’est-ce que l’architecture RAG ?

L’architecture RAG est la configuration sous-jacente des composants (et de leurs capacités associées) qui fait fonctionner un système RAG donné. Toutes ces architectures reposent sur un modèle de base, souvent appelé RAG « simple » ou « naïf ».

Voici un aperçu général de l’architecture RAG de base :

• Source d’information : c’est là que sont stockées les informations externes. Il peut s’agir d’un index de recherche, d’une base de données vectorielle représentant de grandes quantités d’informations ou d’un référentiel de documents bruts.
• Composant de récupération : il s’agit du mécanisme qui permet d’interroger la source d’information. Un système RAG peut par exemple utiliser une simple recherche par mots-clés pour trouver des segments de texte pertinents, ou des requêtes vectorielles plus complexes pour effectuer une recherche par similarité.
• Composant d’orchestration : cette couche est la partie de l’application basée sur un LLM qui déclenche le pipeline RAG pour un prompt utilisateur, soit en collaboration avec le LLM, soit de manière indépendante. Elle compile également les informations récupérées dans un prompt enrichi.

Les composants d’une architecture RAG s’organisent généralement en deux chemins. Le chemin d’ingestion prend les données et les organise en une source d’information interrogeable. Les bases de données vectorielles, dans lesquelles de grandes quantités de texte sont converties en un référentiel interrogeable d’embeddings vectoriels, comptent parmi les applications les plus répandues.

Le chemin de récupération prend le prompt de l’utilisateur et génère une requête permettant d’interroger la source d’information. L’orchestrateur ajoute ensuite les informations récupérées au contexte d’entrée du LLM. Dans les architectures RAG agentiques et hybrides, il peut exister plusieurs chemins de récupération.

Types d’architecture RAG

Il serait trompeur de considérer le RAG comme un ensemble d’architectures entièrement distinctes. La plupart des ingénieurs adoptent une approche modulaire, en mettant en œuvre des composants distincts adaptés à des cas d’usage spécifiques. S’il est possible de tracer des frontières approximatives, il faut souligner que les modèles d’architecture se recoupent largement.

1. RAG de base

Le RAG de base, également appelé RAG « naïf » ou « simple », constitue le modèle architectural des autres types de RAG.

Le processus sous-jacent est relativement simple : un utilisateur saisit un prompt, l’orchestrateur détermine si des informations externes sont nécessaires (de manière indépendante ou en collaboration avec le LLM), puis formule et envoie une requête de récupération en conséquence.

La source d’information externe est généralement une base de données vectorielle, mais il peut aussi s’agir d’une base de données SQL, d’une API web, d’un graphe de connaissances, voire d’un référentiel de documents « bruts ». Ces informations supplémentaires sont ensuite ajoutées au contexte d’entrée du LLM.

En dehors des requêtes SQL et des API, il existe deux grands types de méthodes de récupération :

• Recherche lexicale (recherche par mots-clés) : il s’agit d’une forme simple de RAG dans laquelle des mots-clés sont extraits de la requête de l’utilisateur et comparés à des passages de texte qui les contiennent. Dans les pipelines modernes, l’orchestrateur peut pour cela effectuer ce qu’on appelle une requête vectorielle creuse, qui ne capture pas le sens.
• Recherche vectorielle dense (recherche sémantique) : les embeddings vectoriels denses capturent le sens. Un orchestrateur peut interroger une base de données vectorielle dense de manière à capturer le sens à la fois du prompt de l’utilisateur et des informations sources.

L’utilisation de la mémoire est également un élément important de l’architecture RAG. Elle désigne la manière dont un LLM utilise le contexte de conversations précédentes pour construire une requête de récupération, l’ancrant ainsi dans le contexte plus large d’une discussion (ou de plusieurs discussions). Le RAG conversationnel est la norme pour la plupart des chatbots, bien que certains cas d’usage, comme les réponses aux tickets d’assistance, puissent recourir au RAG à question unique.

2. Hybride

Le RAG hybride combine deux types de récupération différents, généralement la récupération par mots-clés et la récupération sémantique. La recherche par mots-clés trouve les termes correspondants, tandis que la recherche vectorielle trouve des passages au sens proche.

D’autres formes de récupération, comme le parcours d’un graphe de connaissances ou les requêtes sur une base de données SQL, peuvent également être utilisées. Le processus est souvent guidé par une logique de routage, sous la forme de règles programmées ou d’une classification de la question par un modèle (même si plusieurs pipelines peuvent aussi s’exécuter simultanément).

L’orchestrateur fusionne les résultats et peut les reclasser avant de les transmettre au LLM. Le reclassement (reranking) consiste à attribuer des scores de pertinence aux segments récupérés afin que le LLM donne la priorité aux informations les plus pertinentes.

3. RAG adaptatif

Dans le RAG adaptatif, un composant de routage sélectionne une stratégie de récupération en fonction des exigences du prompt de l’utilisateur, puis l’orchestrateur exécute le flux de travail sélectionné.

Dans le cadre d’origine (Adaptive-RAG), un modèle plus petit faisait office de classificateur et choisissait entre aucune récupération, une récupération en une seule étape ou une récupération en plusieurs étapes. Certaines architectures utilisent désormais à la place des modèles génératifs ou des heuristiques fondées sur des règles.

Cette architecture est très répandue, car elle alloue la puissance de traitement en fonction de la complexité et des exigences d’un prompt, ce qui réduit les étapes de récupération inutiles pour les prompts plus simples. Elle est courante dans les assistants qui traitent plusieurs types de questions.

4. RAG correctif (CRAG)

Le RAG correctif évalue les informations récupérées avant de les ajouter au contexte d’entrée du LLM. Un évaluateur de récupération détermine si les informations récupérées sont pertinentes et utiles. La particularité de cette architecture réside dans l’étape explicite d’évaluation et de correction qui précède la génération de la réponse.

Si les informations s’avèrent incomplètes ou non pertinentes pour le prompt, des requêtes supplémentaires sont déclenchées. Celles-ci peuvent faire appel à des méthodes de récupération différentes de celles utilisées pour la requête initiale, comme la recherche web ou le parcours d’un graphe de connaissances.

Le RAG correctif est courant dans les domaines où la précision est essentielle, comme la médecine et le droit. Il nécessite toutefois une source d’information supplémentaire capable de compléter les passages initialement récupérés.

5. Self-RAG

Dans le self-RAG, le modèle peut lancer des requêtes après avoir reçu le contexte d’entrée initial. Les réponses générées sont évaluées par rapport aux éléments récupérés à l’aide de tokens de réflexion, et de nouvelles requêtes sont envoyées via l’orchestrateur si nécessaire. À l’inverse, le LLM peut décider qu’aucune récupération n’est nécessaire.

Il se distingue du RAG correctif en ce que le LLM juge ses propres sorties, détermine si une récupération est nécessaire et si le texte récupéré est utile, et surveille ses propres réponses en les modifiant si nécessaire. Le RAG correctif, en revanche, évalue la qualité des informations récupérées avant la génération.

Cette architecture est particulièrement utile pour les prompts complexes de type recherche approfondie. Comme elle intègre l’évaluation de la pertinence (des informations récupérées) à la génération des réponses, elle constitue une bonne option pour les prompts qui exigent des réponses fondées sur des éléments probants.

6. RAG agentique

Le RAG agentique désigne toute forme de RAG exécutée dans le contexte d’une plateforme agentique. Le modèle utilise ses capacités de raisonnement pour déterminer le type d’informations nécessaires et choisit parmi les options de récupération disponibles.

La récupération peut être déclenchée plusieurs fois selon les besoins, et le modèle peut confier les requêtes plus complexes à des agents. Par exemple, un LLM peut demander une consultation de base de données pour identifier un fournisseur, déclencher une recherche documentaire pour trouver les contrats pertinents, puis terminer par une recherche web afin de vérifier les coordonnées à partir de sources publiques.

Le RAG agentique est la principale architecture mise en œuvre dans les chatbots grand public comme Perplexity, ChatGPT, Claude, etc. Comme ces plateformes donnent au modèle principal accès à plusieurs outils et pipelines RAG, celui-ci peut choisir la forme de récupération la mieux adaptée à un prompt.

7. RAG multimodal

Le RAG multimodal récupère du contexte à partir de différents types de médias. Il s’agit d’une forme importante de RAG, car elle met à la disposition des LLM des informations qui leur seraient autrement inaccessibles, comme des graphiques et des enregistrements audio.

L’architecture sous-jacente est la même que dans tout autre système. Par exemple, un pipeline d’indexation peut préparer des images pour la recherche en les convertissant directement en embeddings. Un système RAG agentique pourrait ensuite récupérer ces images avec du texte sémantiquement pertinent et les transmettre à un modèle vision-langage pour un traitement conjoint.

8. GraphRAG

GraphRAG utilise des graphes de connaissances en complément de la recherche vectorielle pour récupérer des informations sur des entités. En général, l’orchestrateur identifie les entités de départ pertinentes, également appelées nœuds, par extraction de mots-clés ou parfois par une recherche vectorielle préliminaire. Un module de récupération sur graphe parcourt ensuite un graphe de connaissances pour construire un contexte plus large.

Par exemple, en réponse à une demande d’analyse détaillée d’une catégorie de produits, un LLM peut déclencher une recherche vectorielle pour identifier des entités spécifiques (des produits). L’orchestrateur déclenche ensuite une recherche dans le graphe de connaissances pour trouver des entités associées, comme des fournisseurs, des points de vente, des avis, etc.

9. RAG ramifié

Alors qu’une architecture RAG hybride est capable d’utiliser différentes méthodes de récupération, le RAG ramifié désigne le fait d’exécuter plusieurs requêtes, appelées branches, en même temps. Chaque branche peut interroger une source d’information distincte, ou plusieurs branches peuvent interroger la même source en parallèle avec des requêtes ou des filtres différents. Les architectures RAG agentiques font souvent appel au RAG ramifié.

10. HyDE (Hypothetical Document Embeddings)

HyDE est une forme innovante de RAG dans laquelle un LLM rédige un document textuel hypothétique représentant ce à quoi pourrait ressembler une réponse optimale. Ce « document hypothétique » sert ensuite à créer une requête pour une récupération plus précise. Même si les connaissances pertinentes ne sont pas représentées dans les paramètres du LLM, le principe est qu’un passage semblable à une réponse peut mieux correspondre aux documents pertinents qu’une question courte ou un prompt ambigu.

Exemple d’architecture RAG simple : base de données vectorielle

Le RAG de base sert de fondation à des types d’architecture plus complexes. Dans le cas d’un système RAG simple utilisant une base de données vectorielle, la documentation source est découpée en segments plus petits (chunks) et convertie en embeddings denses. Lorsqu’un utilisateur saisit un prompt, l’orchestrateur génère une requête, l’encode et interroge la base de données pour trouver les passages pertinents.

Voici les étapes détaillées du processus :

1. De grandes quantités de texte sont converties en vecteurs à l’aide d’un pipeline d’ingestion automatisé et d’un modèle d’embedding comme BERT.
2. L’application de base de données organise, indexe et stocke les vecteurs pour permettre une recherche rapide.
3. L’utilisateur saisit un prompt dans un chatbot (comme Perplexity).
4. L’orchestrateur de l’application encode le prompt (à l’aide d’un modèle d’embedding) afin de récupérer les informations pertinentes dans la base de données vectorielle.
5. La base de données vectorielle renvoie les segments pertinents ; l’orchestrateur les ajoute au contexte d’entrée (le « prompt étendu ») et transmet celui-ci au LLM.
6. Le LLM utilise ce contexte supplémentaire pour générer une réponse en s’appuyant sur ses connaissances internes (stockées dans ses poids paramétriques).

Agrandir

Exemple d’architecture RAG avancée : RAG agentique

Le RAG agentique désigne l’architecture sous-jacente des systèmes RAG au sein d’une plateforme agentique. Les flux de RAG agentique ont tendance à être complexes, car les agents IA peuvent invoquer différents outils et pipelines selon la nature d’un prompt, et déployer plusieurs agents si nécessaire.

Voici un exemple concret du processus :

1. Un utilisateur saisit une question complexe qui nécessite une recherche approfondie sur un sujet. Pour cet exemple, supposons que le prompt soit : « Fournis une prévision des résultats de l’entreprise pour les six prochains mois, compte tenu des grands événements géopolitiques. »
2. Par son raisonnement, le LLM détermine qu’une combinaison de requêtes RAG, portant sur différents types de contenu, sera nécessaire.
3. Trois agents différents sont déployés pour (a) la recherche vectorielle, (b) l’ancrage web (web grounding) et (c) la recherche d’images (multimodale).
4. Les agents recherchent des informations pertinentes, comme des articles d’actualité et des données financières internes, via l’orchestrateur à l’aide des outils de récupération disponibles.
5. Le LLM compare les résultats récupérés à la question de recherche de chaque agent et les classe par pertinence.
6. Le LLM évalue les informations et déclenche des recherches supplémentaires via des agents individuels lorsque des informations manquent.
7. Une fois suffisamment d’informations récupérées, le LLM génère des scénarios de prévision à partir des chiffres financiers existants (récupérés dans la documentation interne) et fait appel à un outil de calcul pour projeter les résultats de chaque scénario.
8. Le LLM génère une réponse finale à partir des informations récupérées et des calculs, en citant ses sources si nécessaire.

Agrandir

Quel avenir pour le RAG ?

Les innovations actuelles visent à apporter profondeur et rapidité aux architectures RAG existantes, à améliorer la précision de la récupération multimédia et à concevoir des systèmes capables de traiter des informations actualisées en temps réel.

Voici trois tendances qui orientent actuellement la recherche :

• Recherche approfondie sur plusieurs sources : il s’agit d’une architecture RAG capable de planifier des recherches, d’exécuter plusieurs branches sur des sources disparates, d’évaluer les éléments récupérés et d’optimiser elle-même les réponses générées. Le RAG agentique capable d’exécuter l’ensemble de ces tâches devient de plus en plus rapide et rentable.
• Applications multimodales : les pipelines de récupération gèrent de mieux en mieux les images et les vidéos. Ils parviennent de plus en plus à repérer des types d’informations précis dans des données multimodales complexes, comme les vidéos longues et les schémas élaborés.
• Ancrer les réponses dans des informations en constante évolution : les applications basées sur des LLM peuvent puiser dans des sources d’information en direct (comme des flux vidéo et des capteurs) pour alimenter le contexte d’entrée. Les systèmes peuvent également générer des réseaux d’informations à multiples facettes, comme avec GraphRAG, pour interpréter ces données.

Le RAG est au cœur du fonctionnement des applications basées sur des LLM. Il permet à une grande diversité d’utilisateurs, des particuliers aux entreprises opérant dans des domaines spécialisés, de surmonter les problèmes liés aux hallucinations, aux données d’entraînement incomplètes et au manque d’accès à des connaissances internes spécialisées.

C’est pourquoi les systèmes RAG et leur architecture sous-jacente constituent l’un des domaines les plus dynamiques et les plus passionnants de la recherche en IA.