Loïc BoninLB
← Veille

ia

Comprendre et architecturer un RAG en 2026

10 août 2026·4 min de lecture

Le RAG (Retrieval-Augmented Generation) expliqué de A à Z

Le RAG, ou génération augmentée par récupération, est une architecture qui connecte un modèle de langage à une base de connaissances externe pour qu'il réponde à partir de données réelles plutôt que de sa seule mémoire d'entraînement. Cet article explique son fonctionnement technique complet (vectorisation, dimensions, recherche, génération), ses usages concrets et ses limites.

Pourquoi le RAG existe

Un grand modèle de langage (LLM) comme GPT ou Claude apprend à partir d'un corpus figé à un instant donné. Une fois l'entraînement terminé, ses connaissances ne bougent plus, ce qui pose deux problèmes : il ne connaît rien des événements postérieurs à sa date de coupure, et il peut "halluciner", c'est-à-dire produire une réponse fausse formulée avec la même assurance qu'une réponse vraie.

Le RAG corrige ce problème sans toucher au modèle lui-même. Au lieu de réentraîner un LLM à chaque mise à jour de connaissance (une opération lourde et coûteuse en calcul), le RAG branche le modèle sur une base de données externe consultée au moment même de la question.

En résumé, le RAG ajoute une étape de recherche documentaire avant la génération de texte : le modèle ne répond plus seul, il répond après avoir consulté des sources pertinentes, choisies spécifiquement pour la question posée.

Deux mots composent le nom du dispositif, et chacun correspond à une phase distincte du processus :

  • Retrieval (récupération) : le système va chercher, dans une base documentaire externe, les passages les plus pertinents pour la question posée.
  • Augmented Generation (génération augmentée) : ces passages sont ensuite injectés dans la requête envoyée au LLM, qui s'appuie dessus pour rédiger sa réponse.

Le fonctionnement pas à pas

Le fonctionnement d'un système RAG peut s'expliquer en quatre étapes distinctes, de la préparation de la donnée jusqu'à sa mise à jour continue.

Étape 1 : créer les données externes

Tout commence par une base de connaissances distincte des données d'entraînement du modèle. Cette base peut provenir d'API, de bases de données ou de dépôts de documents. Ces documents sont d'abord découpés en fragments plus petits, appelés chunks, avant d'être transformés en représentations numériques exploitables: c'est la vectorisation.

Étape 2 : la vectorisation, ou comment transformer du texte en chiffres

C'est le cœur technique du RAG. Une technique appelée embedding convertit chaque chunk de texte en une longue liste de nombres, un vecteur, qui capture le sens du texte plutôt que sa forme exacte. Deux phrases formulées différemment mais porteuses du même sens obtiennent des vecteurs numériquement proches, tandis que deux phrases sans rapport obtiennent des vecteurs éloignés. C'est ce qui permet une recherche "par sens" plutôt qu'une simple recherche par mot-clé exact.

Ces vecteurs sont ensuite stockés dans une base de données vectorielle — Pinecone, Weaviate, Qdrant ou Chroma comptent parmi les solutions les plus utilisées en 2026 . Cette base constitue, une bibliothèque de connaissances optimisé que les modèles d'IA générative peuvent comprendre.

Combien de dimensions comporte un vecteur ? Le nombre de dimensions varie selon le modèle d'embedding choisi, et ce choix a un impact direct sur le coût de stockage et la vitesse de recherche. Voici les dimensions par défaut des modèles les plus utilisés en production :

  • Cohere Embed v3 : 1 024 dimensions par défaut (limite de 512 tokens en entrée), avec réduction possible jusqu'à 256 dimensions (technique MRL).
  • OpenAI text-embedding-3-small : 1 536 dimensions par défaut (limite de 8 191 tokens en entrée), avec réduction via le paramètre dimensions.
  • OpenAI text-embedding-3-large : 3 072 dimensions par défaut (limite de 8 191 tokens en entrée), avec réduction via le paramètre dimensions.

Un vecteur à 3 072 dimensions capture davantage de nuances sémantiques qu'un vecteur à 256 dimensions, mais il occupe aussi plus d'espace de stockage et ralentit légèrement chaque recherche. Plusieurs fournisseurs, dont Cohere et OpenAI, permettent de tronquer volontairement ces vecteurs vers des dimensions plus petites via une technique nommée Matryoshka Representation Learning (MRL), pour réduire les coûts sans reconstruire toute la base .

Étape 3 : récupérer les informations pertinentes

Quand un utilisateur pose une question, celle-ci est convertie en vecteur exactement de la même manière que les chunks stockés en amont. Le système compare ensuite ce vecteur de question à tous les vecteurs de la base, et retient les documents les plus proches mathématiquement. C'est la phase de recherche de pertinence.

Pour effectuer cette recherche rapidement sur des millions, voire des milliards de vecteurs, les bases vectorielles s'appuient sur des algorithmes d'indexation comme HNSW (Hierarchical Navigable Small World), qui organise les vecteurs en couches hiérarchiques pour naviguer directement vers les voisins les plus proches sans comparer un vecteur de requête à l'intégralité de la base. Une approche comparable à un système postal qui affine sa recherche du pays, à la ville, puis à la rue. Des systèmes combinent cette recherche vectorielle avec une recherche par mot-clé classique (BM25), puis fusionnent les deux classements via une technique appelée Reciprocal Rank Fusion. C'est ce qu'on appelle la recherche hybride.

Étape 4 : augmenter l'invite envoyée au modèle

Les extraits jugés les plus pertinents sont ensuite injectés directement dans le message envoyé au LLM, en même temps que la question initiale de l'utilisateur. Cette étape utilise des techniques d'ingénierie de prompt pour présenter le contexte au modèle de façon exploitable. Le LLM génère alors sa réponse en s'appuyant à la fois sur ces extraits fraîchement récupérés et sur ses connaissances générales acquises pendant l'entraînement. C'est ce mécanisme qui permet, en pratique, d'afficher une citation ou une source à côté de la réponse générée.

Étape 5 : maintenir les données à jour

Un système RAG n'est jamais figé : les documents sources évoluent, et la base vectorielle doit suivre. Une mise à jour asynchrone des documents et de leur représentation vectorielle, soit par des processus automatisés en temps réel, soit par un traitement périodique par lots, est nécessaire.

Le découpage en chunks : un détail technique qui change tout

Le choix de la taille des chunks est l'un des paramètres qui influence le plus la qualité finale d'un système RAG, parfois davantage que le choix du modèle d'embedding lui-même. Une analyse technique de Firecrawl, publiée en 2026, rapporte un écart de taux de rappel pouvant atteindre 9 points de pourcentage entre la meilleure et la moins bonne stratégie de découpage testées sur un même corpus et le même moteur de recherche.

Deux paramètres doivent être calibrés ensemble :

  • La taille du chunk : une étude de référence de LlamaIndex, menée sur un rapport financier réel, a identifié un pic de fidélité et de pertinence des réponses autour de 1024 tokens par chunk, avec une hausse seulement modeste du temps de réponse. Un benchmark de Firecrawl, publié en février 2026, classe en tête le découpage récursif à 512 tokens sur sept stratégies comparées. La fourchette de 512 à 1024 tokens constitue donc un point de départ raisonnable pour la plupart des cas d'usage.
  • Le chevauchement (overlap) entre chunks consécutifs : cette technique consiste à répéter une petite portion de texte à la frontière de deux chunks, pour éviter qu'une phrase importante ne soit coupée en deux et perde son sens. La recommandation la plus répandue en 2026 se situe entre 10 % et 20 % de la taille du chunk,par exemple 50 à 100 tokens de chevauchement pour un chunk de 512 tokens. Un chevauchement excessif (au-delà de 20 %) a toutefois un effet pervers documenté : il peut faire apparaître plusieurs versions quasi identiques du même paragraphe parmi les meilleurs résultats de recherche, ce qui réduit la diversité du contexte transmis au modèle et augmente paradoxalement le risque d'hallucination. Une analyse systématique publiée sur arXiv en janvier 2026 va plus loin et remet en question l'utilité universelle de l'overlap, ne trouvant aucun bénéfice mesurable dans certaines configurations testées,un signal que cette pratique doit être testée sur ses propres données plutôt qu'appliquée par défaut.

La documentation technique s'accorde sur un principe central : il n'existe pas une taille de chunk ni une stratégie de découpage universellement optimale. La meilleure approche consiste donc à tester plusieurs configurations sur un échantillon représentatif de questions réelles.

RAG et recherche sémantique : deux notions liées mais distinctes

Le RAG est le processus global consistant à enrichir la réponse d'un LLM avec des données externes ; la recherche sémantique est la technologie qui, à l'intérieur de ce processus, permet de retrouver les passages les plus pertinents dans de très grands volumes de documents disparates . Sans recherche sémantique performante, un système RAG appliqué à une base documentaire volumineuse produit des résultats de moins bonne qualité, car la recherche par mot-clé classique donne des résultats limités sur les tâches à forte intensité de connaissances .

Les avantages du RAG en entreprise

Il y a quatre bénéfices principaux de cette architecture pour les entreprises qui utilisent les RAG dans leurs systèmes :

  • Une mise en œuvre plus économique : adapter un modèle de fondation à un domaine précis via le RAG coûte nettement moins cher que de le réentraîner ou de l'affiner (fine-tuning).
  • Des informations à jour : le LLM peut être connecté à des flux d'actualité, des bases de données vivantes ou des réseaux sociaux, sans attendre un nouvel entraînement.
  • Une confiance accrue des utilisateurs : les réponses peuvent être accompagnées de citations vers les documents sources, que l'utilisateur peut vérifier lui-même.
  • Un contrôle plus fin pour les équipes techniques : il devient possible de restreindre l'accès à certaines informations sensibles selon le niveau d'autorisation de chaque utilisateur, et de corriger rapidement une source erronée sans toucher au modèle.

Les limites et pièges courants

Ça coule de source, mais le RAG ne corrige pas la mauvaise qualité des documents sources: si la base de connaissances contient des informations contradictoires ou périmées, le système les restituera fidèlement, sans les détecter comme fausses. Le nettoyage ou la selection des documents en amont reste donc souvent le véritable chantier d'un projet RAG, davantage que le choix technique de l'architecture. Autre piège fréquent : miser uniquement sur la recherche vectorielle. Pour les questions très précises portant sur un identifiant exact, une date ou une référence, une recherche par mot-clé classique reste souvent plus fiable que la recherche par similarité sémantique, et voila pourquoi les systèmes RAG les plus robustes combinent recherche vectorielle, la recherche par mot-clé et le reclassement (reranking) plutôt que de s'appuyer sur une méthode unique.

Comment trouver et comparer les modèles d'embedding

Choisir un modèle d'embedding ne doit pas se faire au hasard: des classements publics permettent de comparer objectivement des centaines de modèles sur des tâches précises sont utiles pour ce choix, à condition de savoir lire ces scores correctement.

Le classement de référence : MTEB Leaderboard

Le MTEB Leaderboard (Massive Text Embedding Benchmark), hébergé sur Hugging Face, est la référence la plus large pour comparer les modèles d'embedding toutes langues confondues. Il regroupe des dizaines de tâches (classification, clustering, reranking, recherche documentaire) et permet de filtrer les résultats par langue, par taille de modèle ou par type de tâche. C'est un bon point de départ pour se faire une idée générale, mais il faut rester vigilant : un excellent score global peut masquer une faiblesse importante sur la tâche de recherche documentaire spécifiquement, qui est pourtant celle qui compte pour un RAG.

Le classement spécialisé pour le français : RTEB French

Pour comparer des modèles avant de vous engager sur un projet RAG en français, la démarche la plus fiable consiste à croiser plusieurs sources plutôt qu'à se fier à un classement unique :

  • Consulter RTEB French pour présélectionner des modèles dont la tâche de recherche documentaire en français est spécifiquement mesurée, et non simplement estimée par une couverture linguistique déclarée.
  • Vérifier sur le MTEB Leaderboard général la taille du modèle, sa licence et sa fenêtre de contexte maximale, des critères absents du classement RTEB mais déterminants pour un déploiement réel.
  • Toujours regarder la date de sortie du modèle et la date de la mesure : ce domaine évolue vite, un modèle non testé sur RTEB French n'est pas forcément mauvais, il peut simplement être trop récent pour y figurer.
  • Ne jamais se fier uniquement à un score agrégé multilingue ou multi-tâches : toujours chercher le sous-score correspondant précisément à la tâche de recherche documentaire, dans la langue cible du projet.

Compléments pédagogiques sur le fonctionnement du RAG

Au-delà des mécanismes déjà détaillés, quelques notions supplémentaires permettent d'affiner la compréhension du RAG et d'anticiper les choix de réglage lors d'une mise en œuvre concrète.

Le réglage du top-K

Lors de la phase de recherche, le système ne retourne pas un nombre fixe et universel de passages : ce nombre, appelé top-K, est un paramètre à ajuster explicitement. Un top-K trop faible risque de faire manquer une information utile si elle se trouve dans un chunk qui n'a pas été sélectionné parmi les meilleurs résultats ; un top-K trop élevé, à l'inverse, noie le modèle sous des passages redondants ou hors sujet, ce qui peut dégrader la qualité de la réponse générée plutôt que l'améliorer. Ce réglage se teste empiriquement, comme la taille des chunks, en fonction de la nature des documents traités.

Le reranking, une étape de tri supplémentaire

Une fois les premiers passages candidats récupérés par la recherche vectorielle, une étape optionnelle appelée reranking peut être ajoutée : un second modèle, spécialisé dans le classement de pertinence, relit ces passages et les réordonne avant de les transmettre au modèle de génération. Cette étape est particulièrement utile lorsque plusieurs chunks semblent proches sémantiquement de la question mais n'ont pas la même utilité pour y répondre concrètement.

Graph RAG et Modular RAG, les évolutions du RAG classique

Deux variantes plus avancées prolongent l'architecture RAG de base. Le Graph RAG organise les connaissances sous forme de graphe, avec des nœuds et des relations explicites entre entités, ce qui permet de mieux répondre à des questions portant sur des liens de cause à effet, des dépendances ou des historiques complexes, plutôt que de se limiter à des passages de texte isolés. Le Modular RAG, de son côté, découpe le pipeline en modules indépendants et remplaçables (recherche, filtrage, reranking, génération, vérification, citation des sources), ce qui facilite le contrôle qualité et l'amélioration ciblée de chaque étape, au prix d'une complexité de mise en œuvre plus importante qu'un pipeline RAG simple.

Une checklist pratique avant un déploiement

Avant de passer d'un prototype à un système en production, il est recommandé de suivre une démarche progressive : sélectionner un petit corpus de documents fiables (une vingtaine suffit pour débuter), les découper en passages courts et cohérents, générer les embeddings et construire l'index, puis tester le système sur une dizaine de questions réalistes en vérifiant à la fois la justesse de la réponse et l'exactitude des sources citées, avant d'envisager un élargissement du corpus ou une mise en production plus large.

Un exemple concret en production

Plutôt que d'inclure de longs blocs de code dans cet article, un dépôt public permet de consulter le fonctionnement d'un pipeline RAG minimaliste prêt pour la production. Ce projet sert notamment de base technique au chat IA intégré à ce site. Tout le code source est disponible sur le dépôt owlinstack/rag-chat-minimal.

Ce qu'il faut retenir

Le RAG fonctionne avec une logique simple : découper l'information en chunks, la transformer en vecteurs numériques pour permettre une recherche par sens, retrouver les passages pertinents au moment de la question, puis les injecter dans le prompt du modèle avant qu'il ne génère sa réponse. La qualité finale du système dépend moins du modèle de langage utilisé que de la rigueur apportée à chaque étape en amont : qualité des documents sources, choix de la taille des chunks, stratégie de chevauchement, dimension du modèle d'embedding retenu, et choix de la profondeur de l'architecture RAG selon la tache à aborder.

Sources officielles

IALLMBonnes pratiques