RAG : Le Guide Complet pour Comprendre la Recherche Augmentée par IA

Le problème sans RAG : pourquoi les LLMs hallucinent sur vos données

GPT-4o, Claude, Mistral — ces modèles ont été entraînés sur des milliards de pages web, de livres et de code. Ils savent beaucoup de choses sur le monde en général. Mais ils ne savent rien sur votre entreprise spécifiquement.

Demandez à GPT-4o : "Quels sont les délais de livraison pour ma commande #FR-2024-8847 ?" Il va inventer une réponse plausible-sounding — c'est une hallucination. Il ne peut pas faire autrement : cette information n'est pas dans ses données d'entraînement.

De même, si vous lui demandez de répondre à des questions sur votre documentation interne, vos CGV, vos fiches produit ou votre base de connaissances, le LLM soit invente des réponses, soit répond "je ne sais pas". Ni l'un ni l'autre n'est acceptable en production.

Le RAG résout structurellement ce problème. Au lieu de demander au modèle ce qu'il "sait", on lui donne les informations pertinentes juste avant qu'il réponde.

Ce qu'est le RAG : les trois piliers

RAG est l'acronyme de Retrieval-Augmented Generation. Le nom décrit exactement ce qui se passe :

• Retrieval (Récupération) : trouver les documents pertinents dans votre base de données pour répondre à la question posée
• Augmented (Augmentation) : injecter ces documents dans le prompt du LLM pour enrichir son contexte
• Generation (Génération) : le LLM génère une réponse basée sur les documents fournis, pas sur ses seules connaissances générales

Le résultat est un chatbot qui répond précisément à partir de vos données, cite ses sources, et refuse de répondre quand l'information n'est pas disponible dans le corpus — comportement infiniment plus fiable qu'un LLM non contextualisé.

Les 4 étapes du pipeline RAG : phase d'ingestion

Un système RAG se divise en deux phases bien distinctes : l'ingestion des documents (faite une fois, ou périodiquement) et la réponse aux questions (faite à chaque requête utilisateur). Commençons par l'ingestion :

Étape 1 : Ingestion — charger les documents

Tout commence par charger les documents que votre IA devra connaître. Ces documents peuvent être de formats variés :

• PDF : contrats, documentation technique, fiches produit, rapports
• Word / Google Docs : procédures internes, politiques RH, guides
• Bases de données : catalogue produit, FAQ, tickets support résolus
• Pages web / Confluence : wikis internes, documentation en ligne
• Emails : historique de correspondance, newsletters, communications internes

Pour les PDF, l'extraction de texte est généralement simple via PyPDF2 (Python) ou des services comme AWS Textract pour les PDFs scannés qui nécessitent l'OCR. La qualité de cette extraction impacte directement la qualité finale du système.

Étape 2 : Chunking — découper en morceaux

Un document de 50 pages ne peut pas être envoyé en entier dans un prompt LLM — la fenêtre de contexte a des limites, et injector du texte non pertinent dilue la qualité de la réponse. Il faut donc découper les documents en chunks (morceaux).

La taille optimale d'un chunk est généralement entre 500 et 1 500 tokens (environ 400 à 1 200 mots). Quelques règles pratiques :

• Découpez sur les frontières naturelles : paragraphes, sections, puces
• Ajoutez un chevauchement (overlap) de 50-100 tokens entre les chunks pour ne pas couper un contexte important
• Incluez des métadonnées dans chaque chunk : titre du document, numéro de page, date de mise à jour — elles seront utiles pour citer les sources

Un mauvais chunking est souvent la première cause d'un système RAG qui "ne trouve pas" les bonnes informations malgré un corpus complet.

Étape 3 : Embedding — transformer en vecteurs numériques

C'est l'étape qui permet la "recherche sémantique". Un modèle d'embedding transforme chaque chunk de texte en un vecteur numérique — un tableau de 1 536 nombres qui représente le sens du texte dans un espace mathématique.

Le modèle d'embedding le plus utilisé en production est text-embedding-3-small d'OpenAI. Il est :

• Très peu cher : ~0,02 $ par million de tokens
• Rapide : idéal pour l'ingestion de gros corpus
• Multilingue : fonctionne bien en français sans configuration particulière
• Performant sur les benchmarks sémantiques standards

Des alternatives comme les modèles d'embedding de Cohere ou de Mistral peuvent être préférables pour certaines langues ou domaines spécifiques.

Étape 4 : Stockage — dans une base vectorielle

Les vecteurs générés sont stockés dans une base de données vectorielle spécialisée. Cette base permet de faire des recherches de proximité très rapides sur des millions de vecteurs.

Pour la plupart des projets d'entreprise en France :

• Supabase avec pgvector : PostgreSQL classique avec extension vectorielle. Simple, hébergeable en EU, excellente option par défaut
• Pinecone : service managé, très performant à grande échelle, mais données aux USA par défaut
• Weaviate : open-source, déployable sur vos propres serveurs EU
• Chroma : idéal pour les prototypes et le développement local, moins adapté à la production à grande échelle

Au moment de la question : le pipeline de réponse

Quand un utilisateur pose une question, voici exactement ce qui se passe dans un système RAG bien construit :

1. Embedding de la question : la question de l'utilisateur ("Quelle est la politique de remboursement ?") est transformée en vecteur par le même modèle d'embedding utilisé lors de l'ingestion.

2. Recherche de similarité cosinus : le système cherche dans la base vectorielle les N chunks dont le vecteur est le plus proche (mathématiquement) de la question. La similarité cosinus mesure l'angle entre deux vecteurs — plus il est petit, plus les textes ont un sens similaire.

3. Sélection et tri des chunks pertinents : les 3 à 7 chunks les plus similaires sont sélectionnés. Un score de confiance minimum (typiquement 0.75 sur une échelle de 0 à 1) peut être appliqué pour filtrer les résultats non pertinents.

4. Construction du prompt augmenté : les chunks sélectionnés sont injectés dans le prompt envoyé au LLM, typiquement dans un format comme :

5. Génération de la réponse : le LLM (GPT-4o, Claude Sonnet...) génère une réponse factuelle basée sur les chunks fournis. L'instruction "répondez uniquement à partir du contexte" est la clé pour éviter les hallucinations.

Quand utiliser le RAG ?

Le RAG est particulièrement adapté à ces trois grandes catégories d'applications :

Chatbot sur documentation interne : service RH qui répond aux questions sur les politiques de l'entreprise, assistant technique qui répond sur la documentation produit, support client qui répond depuis la base de connaissances. C'est le cas d'usage le plus courant et souvent le plus rapide à déployer.

Recherche intelligente sur corpus : remplacer un moteur de recherche par mots-clés par une recherche sémantique sur des contrats, des brevets, des études de marché. L'utilisateur tape "risques liés aux fournisseurs asiatiques" et trouve des sections pertinentes même si elles utilisent des termes différents ("exposition supply chain Asie", "dépendance fournisseurs APAC").

Analyse de documents avec génération : extraction structurée depuis des contrats (parties, dates, clauses importantes), résumés automatiques de rapports, comparaison de plusieurs documents pour identifier les différences ou contradictions.

Les limites du RAG à ne pas ignorer

Le RAG est puissant, mais pas magique. Voici les quatre limites principales qui influencent les résultats en production :

Latence : une requête RAG enchaîne au minimum deux appels API (embedding de la question + génération LLM) plus une requête base de données. Le temps de réponse est généralement de 2 à 5 secondes — acceptable pour un assistant, mais à anticiper dans le design UX.

Coût des embeddings : ingérer un gros corpus (100 000 documents) représente un coût one-time non négligeable. Prévoyer le budget d'ingestion initiale, et le coût d'ingestion des nouvelles données au fil du temps.

Qualité du chunking : un chunk mal découpé qui coupe un contexte crucial donnera une mauvaise réponse même si le document correct est récupéré. Invest dans la qualité du pipeline d'ingestion — c'est là que se joue 50 % de la qualité finale.

Documents mal structurés : les tableaux complexes dans les PDFs, les documents scannés de mauvaise qualité, les présentations PowerPoint avec du texte en image — tous ces formats dégradent la qualité d'extraction et d'embedding. Un travail de préparation des données (data cleaning) est souvent nécessaire avant l'ingestion.