🧠 C'est quoi le RAG ? (En termes simples)
Le problème
Imaginez un expert brillant qui a lu des millions de livres... mais qui ne peut pas consulter VOS documents. Vous lui demandez "Quel est le chiffre d'affaires de mon entreprise au Q3 ?" et il répond "Je n'ai pas cette information."
C'est exactement ce qui se passe avec les LLM classiques (ChatGPT, Claude, Gemini) :
- Ils connaissent des connaissances générales (ce qu'ils ont appris pendant l'entraînement)
- Ils ne connaissent PAS vos données (documents, notes, base de données)
- Leur connaissance est figée dans le temps (date de coupure)
La solution RAG
RAG = Retrieval-Augmented Generation = Génération Augmentée par la Recherche.
En français simple : avant de répondre, l'IA va chercher les informations pertinentes dans VOS documents, puis les utilise pour formuler sa réponse.
Sans RAG, la question passe directement du LLM à la réponse, basée uniquement sur ses connaissances générales. Avec RAG, la question déclenche d'abord une recherche dans vos documents pour récupérer les extraits pertinents. Ces documents pertinents sont ensuite ajoutés à la question avant d'être envoyés au LLM, ce qui produit une réponse précise et sourcée.
Analogie simple
Pensez à un étudiant passant un examen :
- Sans RAG : il répond de mémoire (parfois il se trompe ou invente)
- Avec RAG : il a le droit de consulter ses fiches de révision avant de répondre
Le RAG ne rend pas l'IA plus intelligente -- il lui donne accès à vos informations.
🔢 Les embeddings : transformer du texte en vecteurs
Le concept clé
Pour que l'IA puisse "chercher" dans vos documents, il faut d'abord transformer le texte en quelque chose que l'ordinateur peut comparer efficacement : des vecteurs (des listes de nombres).
Conceptuellement, un embedding transforme du texte en nombres. Par exemple, "Le chat dort sur le canapé" et "Le félin se repose au salon" donneront des vecteurs très proches car ils partagent le même sens. En revanche, une phrase comme "Python est un langage" produira un vecteur éloigné, car le sujet est totalement différent.
Les deux premières phrases ont des vecteurs proches (elles parlent du même sujet). La troisième est éloignée (sujet différent).
Comment ça marche ?
Un modèle d'embedding (comme text-embedding-3-small d'OpenAI) a été entraîné sur des milliards de textes pour comprendre la sémantique. Il ne compare pas les mots un par un -- il comprend le sens.
Pour générer un embedding, on envoie le texte à l'API d'OpenAI via une requête HTTP POST authentifiée. L'appel spécifie le modèle d'embedding utilisé et le texte en entrée. En retour, l'API renvoie un tableau de nombres (le vecteur) qui capture la signification sémantique du texte.
Comparaison de similarité
Une fois que vous avez des vecteurs, comparer deux textes revient à calculer la distance entre leurs vecteurs. On utilise pour cela la similarité cosinus : on mesure l'angle entre les deux vecteurs dans un espace à plusieurs dimensions. Un score proche de 1 signifie que les textes sont très similaires sémantiquement, tandis qu'un score proche de 0 indique qu'ils n'ont aucun rapport. Cette logique de calcul permet de classer les documents par pertinence par rapport à une question.
| Score de similarité | Signification |
|---|---|
| 0.90 - 1.00 | Quasi identique |
| 0.75 - 0.90 | Très similaire |
| 0.50 - 0.75 | Lié au sujet |
| 0.25 - 0.50 | Peu de rapport |
| 0.00 - 0.25 | Aucun rapport |
🗄️ Vector databases : où stocker les embeddings
Une fois vos textes transformés en vecteurs, il faut les stocker quelque part et pouvoir les rechercher efficacement. C'est le rôle des bases de données vectorielles.
Comparatif des solutions
| Solution | Type | Complexité | Performance | Self-hosted | Idéal pour |
|---|---|---|---|---|---|
| FAISS | Librairie Python | Facile | Excellente | Oui | Prototypage, petits datasets |
| ChromaDB | Base embarquée | Facile | Bonne | Oui | Side projects, <1M docs |
| Qdrant | Serveur dédié | Moyenne | Excellente | Oui | Production, gros volumes |
| pgvector | Extension Postgres | Moyenne | Bonne | Oui | Si vous avez déjà Postgres |
| Pinecone | Cloud managé | Facile | Excellente | Non | Si vous ne voulez pas gérer l'infra |
| Weaviate | Serveur dédié | Complexe | Excellente | Oui | Cas avancés, multimodal |
FAISS : le plus simple pour commencer
FAISS fonctionne comme un index optimisé en mémoire vive. Vous définissez la dimension de vos vecteurs (1536 pour les embeddings OpenAI), puis vous ajoutez vos vecteurs à l'index. Pour rechercher les documents les plus pertinents, vous fournissez le vecteur de votre question et FAISS utilise un algorithme de recherche par distance (comme L2) pour retourner les k vecteurs les plus proches, accompagnés de leurs distances. Tout se passe localement, sans serveur à gérer.
ChromaDB : la base embarquée user-friendly
ChromaDB s'utilise comme une base de données locale persistante. Vous créez une collection avec un espace de distance (par exemple cosinus), puis vous y ajoutez vos documents. ChromaDB peut générer les embeddings automatiquement ou utiliser les vôtres. Chaque document est associé à un identifiant unique et des métadonnées. La recherche s'effectue en fournissant un texte de requête : ChromaDB vectorise la question, compare les vecteurs et retourne les documents les plus pertinents.
Qdrant : pour la production
Qdrant fonctionne comme un serveur dédié accessible via API. Vous créez d'abord une collection en spécifiant la taille des vecteurs et la métrique de distance (cosinus, dot product, euclidienne). L'insertion se fait via des "points", chacun contenant un identifiant, un vecteur et un payload (les métadonnées comme le texte source). La recherche s'effectue en envoyant un vecteur de requête : Qdrant retourne les points les plus proches avec leur score de similarité, ce qui permet de filtrer et d'affiner les résultats côté application.
🔄 Pipeline complet : de l'ingestion à la réponse
Voici le pipeline RAG complet, étape par étape :
Étape 1 - Ingestion : Les documents bruts (PDF, Markdown, TXT, pages web) sont récupérés depuis leurs sources et chargés en mémoire avec leurs métadonnées.
Étape 2 - Chunking : Les gros documents sont découpés en morceaux réguliers d'environ 500 tokens, avec un chevauchement entre les chunks pour ne pas perdre de contexte.
Étape 3 - Embedding : Chaque chunk est envoyé à un modèle d'embedding pour être transformé en vecteur numérique capturant son sens sémantique.
Étape 4 - Stockage : Les chunks et leurs vecteurs sont insérés dans une vector database (comme Qdrant ou ChromaDB), qui les indexe pour des recherches rapides.
Étape 5 - Retrieval : Quand une question arrive, elle est vectorisée à son tour, puis la vector database cherche les chunks les plus proches sémantiquement.
Étape 6 - Génération : La question de l'utilisateur et les chunks pertinents récupérés sont combinés dans un prompt enrichi, envoyé au LLM pour produire une réponse précise et sourcée.
Étape 1 : Ingestion
L'étape d'ingestion consiste à récupérer vos documents depuis toutes les sources disponibles : fichiers locaux (Markdown, texte, PDF), bases de données, pages web ou API. Chaque document est chargé en mémoire avec son contenu brut et ses métadonnées (source, type de fichier, date). L'objectif est de constituer un corpus brut et structuré prêt à être découpé.
Étape 2 : Chunking (découpage)
Les LLM ont une limite de contexte. L'étape de chunking consiste à découper les gros documents en morceaux digestibles de taille régulière (généralement 300 à 800 tokens). On utilise un système de chevauchement (overlap de 50 à 100 tokens) pour éviter de couper une information au milieu de deux chunks. Les séparateurs sont choisis intelligemment : on privilégie les coupures entre paragraphes, puis entre phrases, pour préserver la cohérence sémantique de chaque morceau.
| Paramètre | Valeur recommandée | Impact |
|---|---|---|
| chunk_size | 300-800 tokens | Trop petit = perte de contexte, trop grand = bruit |
| overlap | 50-100 tokens | Assure la continuité entre chunks |
| Séparateur | Paragraphes > phrases > mots | Respecte la structure du texte |
Étape 3 : Embedding
L'étape d'embedding par batch consiste à envoyer les chunks à l'API d'embedding par groupes (généralement de 100) pour respecter les limites de requêtes et optimiser les coûts. Chaque batch est transformé en vecteurs en une seule requête HTTP. Les embeddings retournés sont collectés et associés à leur chunk d'origine. Cette approche par lots réduit drastiquement le temps de traitement comparé à des appels individuels.
Étape 4 : Stockage
L'étape de stockage consiste à insérer les chunks et leurs embeddings dans la vector database choisie. Chaque chunk est enregistré avec son vecteur, un identifiant unique (par exemple chunk_0, chunk_1), et des métadonnées utiles (fichier source, index du chunk, date). La vector database indexe immédiatement ces vecteurs pour permettre des recherches rapides.
Étape 5 : Retrieval (recherche)
L'étape de retrieval se déclenche quand un utilisateur pose une question. On commence par vectoriser la question avec le même modèle d'embedding que lors de l'ingestion. Ce vecteur est envoyé à la vector database, qui compare le vecteur de la question à tous les vecteurs stockés et retourne les k chunks les plus proches sémantiquement (généralement les 5 premiers). Ces chunks constituent le contexte pertinent pour répondre.
Étape 6 : Génération
L'étape de génération consiste à construire un prompt complet contenant la question de l'utilisateur ET les chunks pertinents récupérés lors du retrieval. On envoie ce prompt enrichi au LLM via une API de chat (comme OpenRouter ou l'API directe d'Anthropic), en lui demandant explicitement de baser sa réponse uniquement sur le contexte fourni. Le LLM formule alors une réponse précise et sourcée, sans halluciner.
🪶 Alternatives simples au RAG
Le RAG complet (embeddings + vector DB + pipeline) n'est pas toujours nécessaire. Voici des alternatives plus simples qui marchent étonnamment bien.
1. Fichiers Markdown dans le contexte
La méthode la plus simple : injecter directement vos fichiers dans le prompt. L'injection de fichiers dans le contexte consiste à lire le contenu de vos fichiers Markdown (mémoire, notes de projet, documentation) et à les concaténer directement dans le prompt envoyé au LLM. Chaque fichier est séparé par un titre pour structurer le contexte. Le LLM reçoit ainsi toute l'information en une seule fois, sans aucune infrastructure intermédiaire.
Avantages : zéro infrastructure, fonctionne immédiatement
Limites : limité par la fenêtre de contexte du LLM (~100-200k tokens)
2. MEMORY.md : la mémoire fichier
C'est l'approche utilisée par OpenClaw : un fichier Markdown qui sert de mémoire persistante.
Ce fichier MEMORY.md contient par exemple les préférences utilisateur (réponses concises, version de Python, hébergement), les projets en cours avec leur stack technique, et les décisions importantes datées. L'IA lit ce fichier à chaque conversation et le met à jour quand il y a de nouvelles infos à retenir.
3. Recherche par mots-clés (memory_search)
Plutôt que des embeddings, une recherche textuelle simple. La recherche par mots-clés fonctionne en extrayant les termes de la question de l'utilisateur, puis en parcourant chaque document pour compter combien de ces mots-clés y apparaissent. Les documents sont ensuite classés par ordre décroissant de correspondance, et les k premiers sont retournés. Cette approche est entièrement locale, ne nécessite aucune API externe et s'exécute quasi instantanément.
Avantages : pas besoin d'API d'embedding, gratuit, rapide
Limites : pas de compréhension sémantique ("voiture" ne matchera pas "automobile")
Tableau comparatif
| Méthode | Complexité | Coût | Précision | Échelle |
|---|---|---|---|---|
| Fichiers dans le contexte | Nulle | Gratuit | Bonne (si tout tient) | <100 pages |
| MEMORY.md | Nulle | Gratuit | Bonne | <50 pages |
| Recherche mots-clés | Faible | Gratuit | Moyenne | <10k docs |
| RAG complet (embeddings) | Moyenne | ~0.01$/1k chunks | Excellente | Illimitée |
| RAG + reranking | Élevée | ~0.02$/1k chunks | Optimale | Illimitée |
⚖️ Quand le RAG est overkill vs indispensable
Le RAG est OVERKILL quand...
| Situation | Alternative recommandée |
|---|---|
| Moins de 50 pages de contexte | Fichiers dans le prompt |
| Données qui changent rarement | MEMORY.md |
| Questions simples et prévisibles | Recherche mots-clés |
| Prototype / MVP | Context injection |
| Budget zéro | Fichiers Markdown |
Le RAG est INDISPENSABLE quand...
| Situation | Pourquoi |
|---|---|
| Des milliers de documents | Ne tient plus dans le contexte |
| Base de connaissances qui évolue | Mise à jour incrémentale |
| Questions imprévisibles | Besoin de recherche sémantique |
| Précision critique | Sources vérifiables |
| Multi-utilisateurs | Chacun ses documents |
| Données techniques denses | L'IA doit trouver l'aiguille dans la botte de foin |
Le test simple
Posez-vous cette question :
"Est-ce que TOUTES mes données tiennent dans le contexte du LLM ?"
- Oui (< 100k tokens, soit ~75k mots) --> Pas besoin de RAG, injectez directement
- Non --> RAG nécessaire
🏗️ RAG dans OpenClaw
OpenClaw intègre nativement des mécanismes de mémoire qui utilisent les principes du RAG sans la complexité :
- MEMORY.md : mémoire long-terme, injectée automatiquement
- memory_search : recherche dans les notes quotidiennes
- Fichiers de contexte : AGENTS.md, TOOLS.md, etc.
Pour la plupart des cas d'usage personnels, cette approche fichiers + recherche suffit largement. Le RAG complet avec vector database devient utile quand vous passez à l'échelle.
🎯 Résumé : par où commencer ?
| Votre situation | Notre recommandation |
|---|---|
| Débutant, petit projet | MEMORY.md + fichiers contexte |
| Projet moyen, <1000 docs | ChromaDB + embeddings |
| Production, gros volume | Qdrant + pipeline complet |
| Utilisateur OpenClaw | Utilisez la mémoire native d'abord |
Les étapes concrètes
- Commencez simple : MEMORY.md et fichiers de contexte
- Quand ça ne suffit plus : ajoutez ChromaDB pour la recherche sémantique
- Quand vous passez à l'échelle : migrez vers Qdrant avec un pipeline d'ingestion
- Optimisez : ajoutez du reranking, du chunking intelligent, des métadonnées
Le RAG n'est pas magique -- c'est juste un moyen élégant de donner à votre IA accès à VOS informations. Commencez simple, complexifiez seulement quand c'est nécessaire.
L'essentiel
- Le RAG permet à un LLM de répondre en s'appuyant sur vos documents propres, et non seulement sur ses connaissances d'entraînement.
- Les embeddings transforment le texte en vecteurs numériques capturant le sens sémantique, ce qui permet de comparer des textes par leur proximité mathématique.
- Les vector databases (FAISS, ChromaDB, Qdrant) stockent et indexent ces vecteurs pour des recherches ultra-rapides.
- Le pipeline RAG suit 6 étapes : ingestion, chunking, embedding, stockage, retrieval et génération.
- Le RAG n'est pas toujours nécessaire : pour moins de 50 pages, l'injection directe dans le contexte suffit souvent.
Outils recommandés
| Outil | Usage | Lien |
|---|---|---|
| text-embedding-3-small | Modèle d'embedding OpenAI, bon rapport qualité/prix | openai.com |
| ChromaDB | Vector database embarquée, idéale pour prototyper | chromadb.ai |
| Qdrant | Vector database de production, haute performance | qdrant.tech |
| OpenRouter | Proxy pour accéder à Claude, GPT et autres LLM | openrouter.ai |
| LangChain / LlamaIndex | Frameworks Python pour orchestrer un pipeline RAG | python.langchain.com / llamaindex.ai |
Erreurs courantes
- Chunk trop petit : un chunk de 100 tokens perd le contexte autour de l'information. Visez 300-800 tokens.
- Pas de chevauchement (overlap) : sans overlap, vous risquez de couper une idée au milieu de deux chunks adjacents.
- Mauvais modèle d'embedding : utiliser un modèle d'embedding différent entre l'ingestion et le retrieval fausse complètement la similarité. Restez cohérent.
- Trop de résultats retournés : récupérer 20 chunks noie le LLM dans le bruit. 3 à 5 chunks pertinents valent mieux que 15 moyennement pertinents.
- Ignorer les métadonnées : stocker uniquement le texte sans métadonnées (source, date, catégorie) empêche de filtrer les résultats lors du retrieval.
FAQ
Le RAG fonctionne-t-il avec des PDFs ?
Oui, mais l'étape d'ingestion est plus complexe. Il faut extraire le texte du PDF (avec des outils comme pdfplumber ou PyMuPDF), puis nettoyer les artefacts (en-têtes, pieds de page, numéros de page) avant le chunking.
Quelle est la différence entre RAG et le fine-tuning ?
Le fine-tuning modifie les poids du modèle pour qu'il apprenne un style ou un comportement spécifique. Le RAG ne modifie pas le modèle : il lui fournit dynamiquement des informations au moment de la requête. Pour injecter des connaissances factuelles, le RAG est presque toujours le bon choix.
Combien coûte un pipeline RAG ?
L'essentiel du coût vient des embeddings (~0,02$ par million de tokens avec text-embedding-3-small en 2025) et des appels LLM pour la génération. Pour 10 000 documents de 500 tokens chacun, le coût d'embedding initial est inférieur à 1$.
Peut-on combiner RAG et recherche par mots-clés ?
Oui, c'est ce qu'on appelle le hybride search. On fait une recherche vectorielle ET une recherche par mots-clés, puis on fusionne et rerank les résultats. C'est l'approche utilisée par des solutions comme Qdrant avec ses filtres et payloads.
Quels outils utiliser pour orchestrer un pipeline RAG avec des appels de fonction ?
Le RAG moderne dépasse souvent le simple retrieval : on veut que l'IA puisse décider de chercher dans les documents, mais aussi d'appeler des outils externes. Pour comprendre comment connecter un LLM à des outils et des bases de données, notre guide MCP, Function Calling, Tool Use : le guide complet détaille les mécanismes sous-jacents.
Conclusion
Le RAG est une brique fondamentale de l'IA en 2025, mais ce n'est pas une solution miracle à appliquer partout. L'erreur la plus courante est de sur-ingénierer : monter une stack Qdrant + pipeline d'ingestion alors que trois fichiers Markdown dans le contexte feraient l'affaire.
La bonne approche, c'est le progressive scaling : commencez avec l'injection directe de contexte et un MEMORY.md. Quand vos données dépassent la fenêtre de contexte, passez à ChromaDB. Quand vous avez des milliers de documents et des besoins de production, migrez vers Qdrant. À chaque étape, vous ajoutez de la complexité seulement parce que la solution précédente a atteint ses limites.
Si vous voulez aller plus loin sur l'architecture d'agents intelligents, consultez notre article sur Mémoire IA : comment faire en sorte que votre agent se souvienne de tout. Et si votre projet implique plusieurs agents qui doivent collaborer et partager une mémoire commune, ruflo : la plateforme d'orchestration multi-agent qui explose sur GitHub vous donnera les clés pour architecturer tout ça.
```