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

La RAG, pour « retrieval augmented generation » (génération augmentée par récupération), est un processus par lequel les LLM utilisent de l’information externe pour enrichir et améliorer leurs réponses. L’architecture RAG désigne l’ensemble des composants et des connexions qui rendent la RAG possible.

Il existe plusieurs catégories de RAG, chacune reposant sur sa propre architecture. Essentiellement, l’architecture d’un système RAG détermine la façon dont l’information est stockée, récupérée et transmise à un LLM.

Qu’est-ce que l’architecture RAG?

L’architecture RAG est la configuration sous-jacente de composants (et des capacités qui y sont associées) qui alimente un système RAG donné. Toutes ces architectures reposent sur un schéma fondamental, souvent appelé RAG « simple » ou « naïve ».

Voici un survol de l’architecture RAG fondamentale :

• Source d’information : c’est là que l’information externe est stockée. Il peut s’agir d’un index de recherche, d’une base de données vectorielle représentant de grandes quantités d’information ou d’un dépôt 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 lance le pipeline RAG pour une invite de l’utilisateur, soit conjointement avec le LLM, soit de manière indépendante. Elle compile également l’information récupérée dans une invite enrichie.

Les composants d’une architecture RAG sont généralement organisés selon 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 dépôt interrogeable de plongements vectoriels, figurent parmi les applications les plus répandues.

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

Types d’architecture RAG

Il est trompeur de concevoir la RAG comme un ensemble d’architectures complètement distinctes. La plupart des ingénieurs adoptent une approche modulaire, en mettant en œuvre des composants distincts adaptés à des cas d’utilisation précis. S’il est possible de tracer des frontières approximatives, il importe de souligner que les modèles d’architecture se chevauchent considérablement.

1. RAG de base

La RAG de base, aussi appelée RAG « naïve » ou « simple », constitue le schéma architectural des autres types de RAG.

Le processus sous-jacent est relativement simple : l’utilisateur saisit une invite, l’orchestrateur détermine si de l’information externe est nécessaire (de façon indépendante ou conjointement 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 ou même d’un dépôt de documents « bruts ». Cette information supplémentaire est ensuite ajoutée au contexte d’entrée du LLM.

Outre les requêtes SQL et les 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 ce faire, effectuer ce qu’on appelle une requête vectorielle creuse, qui ne capte pas le sens.
• Recherche vectorielle dense (recherche sémantique) : les plongements vectoriels denses captent le sens. Un orchestrateur peut interroger une base de données vectorielle dense de manière à saisir le sens à la fois de l’invite de l’utilisateur et de l’information source.

L’utilisation de la mémoire est aussi un élément important de l’architecture RAG. Il s’agit de la façon dont un LLM utilise le contexte de conversations précédentes pour formuler une requête de récupération, l’ancrant ainsi dans le contexte plus large d’une discussion (ou de plusieurs discussions). La RAG conversationnelle est la norme pour la plupart des robots conversationnels, bien que certains cas d’utilisation, comme les réponses aux billets de soutien, puissent recourir à la RAG à question unique.

2. Hybride

La RAG hybride combine deux types de récupération différents, habituellement 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 apparenté.

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

L’orchestrateur fusionne les résultats et peut les reclasser avant de les transmettre au LLM. Le reclassement consiste à attribuer des scores de pertinence aux segments récupérés afin que le LLM priorise l’information la plus utile.

3. RAG adaptative

Dans la RAG adaptative, un composant de routage sélectionne une stratégie de récupération en fonction des exigences de l’invite de l’utilisateur, puis l’orchestrateur exécute le flux de travail choisi.

Dans le cadre d’origine (Adaptive-RAG), un modèle plus petit agissait comme classificateur et choisissait entre l’absence de récupération, une récupération en une seule étape ou une récupération en plusieurs étapes. Certaines architectures utilisent désormais plutôt des modèles génératifs ou des heuristiques fondées sur des règles.

Il s’agit d’une architecture populaire, car elle attribue la puissance de traitement en fonction de la complexité et des exigences d’une invite, ce qui réduit les étapes de récupération inutiles pour les invites plus simples. On la retrouve couramment dans les assistants qui traitent plusieurs types de questions.

4. RAG corrective (CRAG)

La RAG corrective évalue l’information récupérée avant de l’ajouter au contexte d’entrée du LLM. Un évaluateur de récupération détermine si l’information récupérée est pertinente et utile. Sa particularité architecturale réside dans l’étape explicite d’évaluation et de correction qui précède la génération de la réponse.

Si l’information s’avère incomplète ou non pertinente pour l’invite, 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.

La RAG corrective est courante dans les domaines où l’exactitude est importante, comme la médecine et le droit. Elle nécessite toutefois une source d’information supplémentaire pouvant compléter les passages récupérés au départ.

5. Self-RAG

Dans la 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 probants récupérés à l’aide de jetons de réflexion, et d’autres requêtes sont envoyées par l’intermédiaire de l’orchestrateur au besoin. À l’inverse, le LLM peut décider qu’aucune récupération n’est nécessaire.

Elle se distingue de la RAG corrective 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 au besoin. La RAG corrective, quant à elle, évalue la qualité de l’information récupérée avant la génération.

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

6. RAG agentique

La 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’information nécessaire et choisit parmi les options de récupération disponibles.

La récupération peut être déclenchée plusieurs fois au besoin, et le modèle peut assigner des agents aux requêtes plus complexes. Par exemple, un LLM pourrait demander une consultation de base de données pour trouver un fournisseur, déclencher une recherche de documents pour trouver les contrats pertinents, puis terminer par une recherche Web pour vérifier les coordonnées à l’aide de sources publiques.

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

7. RAG multimodale

La RAG multimodale récupère du contexte dans différents types de médias. Il s’agit d’une forme importante de RAG, car elle rend accessibles aux LLM des informations qui leur seraient autrement hors de portée, 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 pourrait préparer des images pour la recherche en les convertissant directement en plongements. Un système RAG agentique pourrait ensuite récupérer ces images conjointement avec du texte sémantiquement pertinent et transmettre le tout à un modèle vision-langage pour un traitement combiné.

8. GraphRAG

GraphRAG utilise des graphes de connaissances en complément de la recherche vectorielle pour récupérer de l’information sur des entités. En général, l’orchestrateur trouve les entités de départ pertinentes, aussi appelées nœuds, au moyen de l’extraction de mots-clés ou parfois d’une recherche vectorielle préliminaire. Un récupérateur de graphe parcourt 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 repérer des entités précises (des produits). L’orchestrateur déclenche ensuite une recherche dans le graphe de connaissances pour trouver des entités connexes, comme des fournisseurs, des points de vente, des avis, etc.

9. RAG ramifiée

Alors qu’une architecture RAG hybride peut utiliser différentes méthodes de récupération, la RAG ramifiée désigne le processus consistant à 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. L’architecture RAG agentique fait souvent appel à la RAG ramifiée.

10. HyDE (Hypothetical Document Embeddings, ou plongements de documents hypothétiques)

HyDE est une forme novatrice de RAG dans laquelle un LLM crée 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 permettant 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 raisonnement est qu’un passage semblable à une réponse peut mieux correspondre aux documents pertinents qu’une courte question ou une invite ambiguë.

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

La RAG de base sert de fondement à des types d’architecture plus complexes. Dans le cas d’un système RAG simple qui utilise une base de données vectorielle, la documentation source est divisée en éléments plus petits (segments) et convertie en plongements denses. Lorsque l’utilisateur saisit une invite, l’orchestrateur génère une requête, l’encode et interroge la base de données pour trouver les passages pertinents.

Voici le processus, étape par étape :

1. Conversion de grandes quantités de texte en vecteurs à l’aide d’un pipeline d’ingestion automatisé et d’un modèle de plongement 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 une invite dans un robot conversationnel (comme Perplexity).
4. L’orchestrateur de l’application encode l’invite (à l’aide d’un modèle de plongement) afin de récupérer l’information pertinente dans la base de données vectorielle.
5. La base de données vectorielle renvoie les segments pertinents, et l’orchestrateur les ajoute au contexte d’entrée (la « grande invite ») avant de le transmettre au LLM.
6. Le LLM utilise ce contexte supplémentaire pour générer une réponse à l’aide de ses connaissances internes (stockées dans ses poids paramétriques).

Agrandir

Exemple d’architecture RAG avancée : RAG agentique

La 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 d’IA peuvent faire appel à différents outils et pipelines selon la nature d’une invite, en déployant plusieurs agents au besoin.

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, disons que l’invite est « Fournis une prévision des bénéfices de l’entreprise pour les six prochains mois à la lumière des grands événements géopolitiques ».
2. Le LLM détermine, par raisonnement, 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 et (c) la recherche d’images (multimodale).
4. Les agents recherchent de l’information pertinente, comme des articles d’actualité et des données financières internes, par l’intermédiaire de 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 ordre de pertinence.
6. Le LLM évalue l’information et déclenche des recherches supplémentaires au moyen d’agents individuels là où il manque de l’information.
7. Une fois suffisamment d’information récupérée, le LLM génère des prévisions par scénario à partir des données financières existantes (récupérées dans la documentation interne) et fait appel à un outil de calcul pour projeter les bénéfices de chaque scénario.
8. Le LLM génère une réponse finale à partir de l’information récupérée et des calculs, en citant ses sources au besoin.

Agrandir

Quel avenir pour la RAG?

Les innovations en cours visent à donner plus de profondeur et de rapidité aux architectures RAG actuelles, à améliorer la précision de la récupération multimédia et à concevoir des systèmes capables de traiter de l’information mise à jour en temps réel.

Voici trois tendances qui orientent actuellement la recherche :

• Recherche approfondie dans plusieurs sources : il s’agit d’une architecture RAG capable de planifier des recherches, d’exécuter plusieurs branches dans des sources disparates, d’évaluer les éléments probants récupérés et d’optimiser elle-même les réponses générées. La RAG agentique capable d’exécuter toutes ces tâches devient sans cesse plus rapide et plus rentable.
• Applications multimodales : les pipelines de récupération traitent de mieux en mieux les images et les vidéos. Ils parviennent de plus en plus à cibler des types d’information précis dans des données multimodales complexes, comme des vidéos longues et des diagrammes avancés.
• Ancrage des réponses dans une information 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 fournir le contexte d’entrée. Les systèmes peuvent aussi générer des réseaux d’information à multiples facettes, comme avec GraphRAG, pour interpréter ces données.

La RAG est au cœur du fonctionnement des applications basées sur des LLM. Elle permet à une multitude d’utilisateurs, des consommateurs ordinaires aux entreprises œuvrant 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 représentent l’un des domaines les plus dynamiques et les plus passionnants de la recherche en IA.