Chapitre 28

RAG : Donner de la Mémoire à l'IA

Retrieval Augmented Generation Démystifié

18 min de lecture

Sommaire

Une IA qui connaît votre entreprise

Imaginez un assistant IA qui connaît chaque document interne de votre entreprise, chaque procédure, chaque décision passée — et qui peut répondre à n'importe quelle question en citant ses sources avec précision. Ce n'est pas un rêve de science-fiction, c'est exactement ce que permet le RAG (Retrieval Augmented Generation). Sans RAG, un LLM comme GPT-4 ou Claude ne connaît que ses données d'entraînement. Avec RAG, il accède à votre base de connaissances spécifique et produit des réponses contextualisées, sourcées et pertinentes. C'est la technologie qui transforme un chatbot générique en expert de votre domaine.

Le RAG résout le problème fondamental des LLMs : ils savent tout en général, mais rien sur votre entreprise en particulier.

Qu'est-ce que le RAG ?

Le RAG (Retrieval Augmented Generation) est une architecture qui enrichit les réponses d'un LLM en lui fournissant des informations pertinentes extraites d'une base de connaissances externe avant la génération de texte. Le concept est élégant dans sa simplicité : plutôt que de ré-entraîner un modèle (coûteux et complexe), on lui donne accès à des documents pertinents au moment de la requête. Le LLM utilise ces documents comme contexte pour formuler une réponse précise et sourcée. C'est comme donner à un expert accès à une bibliothèque spécialisée juste avant de répondre à votre question.

Retrieval : Recherche des documents pertinents dans une base de connaissances

Augmented : Enrichissement du prompt avec les documents trouvés

Generation : Production d'une réponse contextuelle par le LLM

Comment ça Marche : Embed, Retrieve, Generate

Le pipeline RAG fonctionne en trois étapes distinctes. Premièrement, l'indexation : vos documents sont découpés en chunks (morceaux), convertis en embeddings (représentations vectorielles) et stockés dans une base de données vectorielle. Deuxièmement, la recherche : quand un utilisateur pose une question, celle-ci est également convertie en embedding, et les chunks les plus similaires sémantiquement sont récupérés. Troisièmement, la génération : les chunks pertinents sont injectés dans le prompt du LLM comme contexte, et le modèle génère une réponse basée sur ces informations spécifiques. Ce processus se déroule en quelques secondes et produit des réponses d'une précision remarquable.

Le RAG transforme la question 'que sait l'IA ?' en 'quelles informations l'IA peut-elle trouver dans vos données ?'

Les Embeddings Expliqués

Les embeddings sont le cœur mathématique du RAG. Un embedding transforme un texte en un vecteur — une liste de nombres (typiquement 768 à 3072 dimensions) qui capture le sens sémantique du texte. Deux phrases ayant un sens similaire produiront des vecteurs proches dans cet espace multidimensionnel, même si elles utilisent des mots complètement différents. Par exemple, 'Le chat dort sur le canapé' et 'Le félin se repose sur le sofa' produiront des embeddings très proches. Cette propriété est fondamentale : elle permet de trouver des documents pertinents par similarité de sens, pas juste par correspondance de mots-clés.

text-embedding-3-large (OpenAI) : 3072 dimensions, le plus précis

voyage-3 (Anthropic/Voyage AI) : Excellent pour les documents techniques

BGE-M3 (BAAI) : Open source, multilingue, performant

Cohere Embed v3 : Optimisé pour la recherche sémantique

Les Bases Vectorielles : Pinecone, Weaviate, Chroma

Une base de données vectorielle est conçue spécifiquement pour stocker et rechercher des embeddings de manière efficace. Contrairement à une base SQL classique qui recherche par correspondance exacte, une base vectorielle effectue des recherches par similarité — elle trouve les vecteurs les plus proches de votre requête dans un espace à haute dimension. Pinecone est le leader managed, offrant une infrastructure serverless avec des performances exceptionnelles et une simplicité d'utilisation remarquable. Weaviate combine recherche vectorielle et recherche traditionnelle dans un framework open source puissant. Chroma est la solution minimaliste parfaite pour les prototypes et les applications de taille moyenne.

Pinecone : Managed, serverless, le plus simple à intégrer — idéal pour la production

Weaviate : Open source, hybrid search (vectoriel + keyword), très flexible

Chroma : Léger, open source, parfait pour prototyper et les projets de taille moyenne

Qdrant : Rust-based, performant, bon compromis open source / managed

pgvector : Extension PostgreSQL — si vous utilisez déjà Postgres

Stratégies de Chunking : L'Art du Découpage

Le chunking — la manière dont vous découpez vos documents en morceaux — est probablement le facteur le plus déterminant de la qualité d'un système RAG. Un chunk trop petit perd le contexte, un chunk trop grand dilue l'information pertinente. La stratégie optimale dépend du type de document et du cas d'usage. Pour des documents structurés (manuels, documentation), le découpage par section ou par paragraphe fonctionne bien. Pour du texte libre (emails, conversations), un découpage par fenêtre glissante avec chevauchement préserve mieux le contexte. La taille idéale se situe généralement entre 256 et 1024 tokens, avec un chevauchement de 10 à 20%.

80% des problèmes de qualité RAG viennent d'un mauvais chunking. C'est la première chose à optimiser avant de toucher au reste.

Chunking par taille fixe : Simple mais perd le contexte sémantique

Chunking par paragraphe/section : Respecte la structure du document

Chunking récursif : Découpe hiérarchique (titre → section → paragraphe)

Chunking sémantique : Utilise un modèle pour détecter les ruptures de sens

Construire un Pipeline RAG Étape par Étape

Construire un pipeline RAG fonctionnel requiert une approche méthodique. La première étape est la collecte et le nettoyage des données : rassemblez vos documents, supprimez le bruit (headers, footers, formatting), et normalisez le texte. Ensuite, choisissez votre stratégie de chunking et découpez les documents. Puis, générez les embeddings avec un modèle adapté et stockez-les dans votre base vectorielle. Configurez la chaîne de recherche : quand une question arrive, convertissez-la en embedding, recherchez les K chunks les plus pertinents (typiquement K=3 à 5), et construisez le prompt avec ces chunks comme contexte. Enfin, envoyez le prompt enrichi au LLM pour la génération.

Étape 1 : Collecter et nettoyer les documents sources

Étape 2 : Chunker avec la stratégie adaptée au type de contenu

Étape 3 : Générer les embeddings et les indexer dans la base vectorielle

Étape 4 : Configurer la recherche sémantique (top-K, seuil de similarité)

Étape 5 : Construire le prompt template avec injection de contexte

Étape 6 : Tester, évaluer et itérer sur la qualité des réponses

RAG Avancé : Hybrid Search et Reranking

Le RAG basique fonctionne bien, mais les systèmes de production exigent des techniques plus sophistiquées. L'hybrid search combine la recherche vectorielle (sémantique) avec la recherche par mots-clés (BM25) pour capturer à la fois le sens et les termes exacts — crucial pour les noms propres, les codes produit ou les acronymes que la recherche sémantique seule peut manquer. Le reranking ajoute une étape de reclassement après la recherche initiale : un modèle cross-encoder évalue la pertinence de chaque chunk par rapport à la question, améliorant significativement la précision des résultats. Ces deux techniques combinées peuvent augmenter la qualité des réponses de 20 à 40%.

Hybrid Search : Combine vectoriel (sens) + BM25 (mots-clés exacts)

Reranking : Cross-encoder qui reclasse les résultats par pertinence

Query expansion : Reformuler la question en plusieurs variantes pour élargir la recherche

HyDE : Générer une réponse hypothétique et l'utiliser pour la recherche

RAG vs Fine-Tuning : Quand Utiliser Quoi ?

La question revient constamment : faut-il utiliser le RAG ou le fine-tuning pour adapter un LLM à son domaine ? La réponse est nuancée mais claire dans la plupart des cas. Le RAG excelle quand vos données changent fréquemment, quand vous avez besoin de citer vos sources, et quand la précision factuelle est critique. Le fine-tuning est préférable quand vous voulez modifier le style ou le comportement du modèle, quand vos données sont stables, ou quand la latence est un enjeu majeur. En pratique, les meilleurs systèmes combinent les deux : un modèle fine-tuné sur le style de votre domaine, enrichi par du RAG pour les données factuelles à jour.

Le RAG donne de nouvelles connaissances au modèle. Le fine-tuning change sa personnalité. Les deux sont complémentaires, pas concurrents.

RAG : Données dynamiques, traçabilité des sources, mise à jour sans ré-entraînement

Fine-tuning : Style/ton spécifique, données stables, latence réduite

Hybride : Fine-tuning pour le comportement + RAG pour les connaissances à jour

Applications Réelles du RAG

Le RAG est déjà déployé massivement dans des cas d'usage très variés. Les chatbots de support client alimentés par RAG répondent aux questions en se basant sur la documentation produit, les FAQ et les tickets précédents — avec un taux de résolution au premier contact qui dépasse souvent les 60%. Les assistants juridiques utilisent le RAG pour parcourir des milliers de documents légaux et fournir des analyses contextualisées. Les systèmes de knowledge management d'entreprise permettent aux employés de trouver instantanément l'information pertinente dispersée dans des centaines de documents internes, Confluence, Notion ou Google Drive.

Support client : Chatbot alimenté par la documentation et les tickets passés

Juridique : Analyse de contrats, recherche de jurisprudence, conformité

Knowledge management : Assistant interne connecté à toutes les bases documentaires

RH : Réponses aux questions sur les politiques, avantages, procédures internes

R&D : Exploration de la littérature scientifique et des brevets

Pièges Courants et Comment les Éviter

Les échecs RAG sont rarement spectaculaires mais souvent insidieux. Le piège le plus courant est le 'garbage in, garbage out' : si vos documents sources sont mal structurés, incomplets ou contradictoires, le système RAG amplifiera ces défauts. Le deuxième piège est le chunking inadapté qui découpe le contexte au mauvais endroit. Le troisième est la confiance aveugle dans les résultats sans évaluation systématique : un système RAG peut halluciner malgré le contexte fourni, surtout quand la question sort du périmètre des documents indexés. Enfin, négliger la mise à jour de l'index quand les documents sources changent crée un décalage dangereux entre la réalité et les réponses du système.

Nettoyer les données sources avant l'indexation — la qualité est non-négociable

Tester différentes stratégies de chunking et mesurer la qualité des réponses

Implémenter une évaluation continue (RAGAS, DeepEval) pour détecter les dérives

Mettre en place un pipeline de mise à jour automatique de l'index

Toujours inclure un mécanisme de feedback utilisateur

Conclusion : Le RAG, Fondation de l'IA d'Entreprise

Le RAG n'est pas une simple technique — c'est la fondation sur laquelle repose l'IA d'entreprise moderne. Il résout le problème fondamental de la personnalisation des LLMs sans les coûts et la complexité du fine-tuning. Pour tout professionnel travaillant avec l'IA, comprendre le RAG est devenu aussi essentiel que comprendre les bases de données l'était il y a vingt ans. La technologie continue d'évoluer rapidement : agentic RAG, graph RAG, multi-modal RAG ouvrent de nouvelles possibilités chaque mois. Maîtriser les fondamentaux aujourd'hui, c'est être prêt pour les innovations de demain.

Le RAG est à l'IA d'entreprise ce que SQL est aux bases de données : un fondamental que tout professionnel tech doit comprendre.

Sources & Références

Retour aux cours Chapitre suivant — Vers une Culture Data & IA