RAG : augmenter un LLM avec vos données

Votre LLM répond à côté quand vous l’interrogez sur votre documentation interne ? Normal : il n’a jamais vu vos docs. Le RAG (Retrieval-Augmented Generation) résout ce problème : il cherche les passages pertinents dans vos documents, puis les injecte dans le prompt du LLM pour générer une réponse précise et sourcée.

Ce guide est la porte d’entrée vers un parcours complet qui vous emmène du concept à un RAG en production, étape par étape.

Ce que vous allez apprendre dans ce parcours

À la fin de ce parcours, vous saurez :

Collecter du contenu web propre (scraping intelligent)
Nettoyer les textes pour l’indexation
Découper les documents en chunks pertinents
Créer des embeddings et comprendre la similarité sémantique
Stocker dans une base vectorielle (ChromaDB, FAISS)
Construire un RAG complet qui répond en citant ses sources
Optimiser avec la recherche hybride et le reranking
Déployer en production avec sécurité, évaluation et monitoring

Qu’est-ce qu’un RAG ?

RAG signifie Retrieval-Augmented Generation. C’est une technique qui permet à un LLM de répondre à partir de vos documents, sans avoir besoin de le fine-tuner.

Le problème que RAG résout

Un LLM comme GPT-4 ou Claude connaît énormément de choses, mais il ne connaît pas :

Votre documentation interne
Vos runbooks et procédures
Vos tickets et post-mortems
Votre wiki Confluence ou Notion

Si vous lui posez une question sur ces documents, il va inventer une réponse (hallucination) ou avouer qu’il ne sait pas.

La solution RAG

Au lieu de demander au LLM de “connaître” vos documents, on lui fournit les passages pertinents au moment de la question :

[Sans RAG]
User: Comment déployer sur staging ?
LLM: Je ne sais pas, je n'ai pas accès à votre documentation.

[Avec RAG]
User: Comment déployer sur staging ?
RAG: *cherche dans vos docs* → trouve "runbook-k8s.md"
RAG: *injecte le passage dans le prompt*
LLM: Selon votre documentation, utilisez `kubectl apply -f staging/`.
     [Source: runbook-k8s.md]

RAG vs alternatives

Besoin	Solution
Répondre à partir de docs internes / wiki / runbooks	RAG
Données qui changent souvent	RAG
Personnaliser le style (ton, format)	Fine-tuning ou prompt engineering
Faire des actions (déployer, ouvrir un ticket)	Agent + tool calling
Mémoriser des connaissances générales	Fine-tuning

Architecture d’un RAG

Un RAG fonctionne en deux phases distinctes :

Pipeline RAG : indexation, retrieval, génération

Phase 1 : Indexation (offline)

Cette phase prépare vos documents pour la recherche. Elle s’exécute une fois (puis à chaque mise à jour des docs).

Collecter : scraper les pages web, lire les fichiers Markdown, PDF, etc.
Nettoyer : supprimer le HTML, normaliser les espaces, corriger l’encodage
Découper (chunking) : diviser les documents en morceaux de 300-800 tokens
Encoder (embeddings) : transformer chaque chunk en vecteur numérique
Stocker : sauvegarder les vecteurs dans une base vectorielle (ChromaDB, FAISS)

Phase 2 : Recherche + Génération (runtime)

Cette phase s’exécute à chaque question utilisateur.

Encoder la question : transformer la question en vecteur
Rechercher : trouver les chunks les plus proches (similarité cosinus)
Construire le prompt : injecter les chunks pertinents dans le contexte
Générer : le LLM produit une réponse basée sur le contexte
Citer : inclure les sources dans la réponse

Le parcours complet de A à Z

Ce parcours vous guide à travers toutes les étapes pour construire un RAG fonctionnel. Suivez-le dans l’ordre pour une progression logique.

Étape 1 : Collecter le contenu

Avant de créer un RAG, il faut récupérer le contenu à indexer. Si vos documents sont sur le web, vous devez les scraper proprement.

Récupérer du contenu avec Trafilatura Extraire le contenu utile des pages web en ignorant menus et publicités

Ce que vous apprendrez :

Scraper une page web et extraire le texte principal
Gérer les métadonnées (titre, date, auteur)
Traiter plusieurs pages en batch
Respecter les bonnes pratiques (rate limiting, robots.txt)

Étape 2 : Nettoyer les textes

Le contenu brut contient souvent du bruit : caractères spéciaux, espaces multiples, HTML résiduel. Un nettoyage propre améliore la qualité du RAG.

Nettoyer les textes pour le RAG Normaliser, nettoyer et préparer les textes pour l'indexation

Ce que vous apprendrez :

Normaliser l’encodage Unicode
Supprimer les caractères indésirables
Segmenter en phrases avec NLTK/spaCy
Détecter la langue

Étape 3 : Découper en chunks

Un document de 50 pages est trop long pour être utilisé directement. Le chunking le divise en morceaux cohérents que le retriever peut rechercher efficacement.

Chunking : découper pour le RAG 5 stratégies de chunking comparées : fixe, récursif, phrases, sections, sémantique

Ce que vous apprendrez :

Choisir la bonne taille de chunk (300-800 tokens)
Utiliser l’overlap pour conserver le contexte
Comparer 5 stratégies (fixe, récursif, phrases, sections, sémantique)
Identifier la stratégie adaptée à votre contenu

Étape 4 : Créer les embeddings

Les embeddings transforment le texte en vecteurs numériques. Deux textes au sens proche auront des vecteurs proches, permettant la recherche sémantique.

Embeddings : représenter le sens Créer des embeddings, comprendre la similarité cosinus, choisir un modèle

Ce que vous apprendrez :

Générer des embeddings avec sentence-transformers
Comprendre la similarité cosinus
Comparer les modèles (all-MiniLM, E5, BGE)
Gérer le multilingue

Étape 5 : Stocker dans une base vectorielle

Une base vectorielle stocke vos embeddings et permet de retrouver les chunks les plus proches d’une requête en millisecondes.

Bases de données vectorielles Comprendre les bases vectorielles : concepts, indexation, cas d'usage

ChromaDB Base vectorielle simple et embarquée, idéale pour débuter

FAISS Librairie Facebook pour la recherche de similarité à grande échelle

Ce que vous apprendrez :

Créer une collection et indexer des vecteurs
Rechercher par similarité (top-K)
Filtrer par métadonnées
Persister les données sur disque

Étape 6 : Construire un RAG complet

Il est temps d’assembler tous les composants pour créer un système RAG fonctionnel qui répond à vos questions.

RAG pratique : assistant documentation Construire un RAG local complet : scraping, indexation, recherche et génération

Ce que vous apprendrez :

Assembler le pipeline complet
Utiliser Ollama pour la génération locale
Écrire un prompt RAG avec citations
Tester et debugger votre RAG

Étape 7 : Optimiser le retrieval

Un RAG basique fonctionne, mais peut manquer des documents pertinents. La recherche hybride et le reranking améliorent significativement la qualité.

RAG avancé : améliorer le retrieval Recherche hybride (dense + BM25), reranking, contextual retrieval

Ce que vous apprendrez :

Combiner dense + BM25 (recherche hybride)
Fusionner les résultats avec RRF
Affiner avec un reranker (cross-encoder)
Implémenter le contextual retrieval d’Anthropic

Étape 8 : Déployer en production

Un RAG en production nécessite sécurité (qui peut voir quoi), évaluation (mesurer la qualité) et observabilité (monitoring).

RAG en production ACL, multi-tenant, évaluation RAGAS, monitoring et alertes

Ce que vous apprendrez :

Implémenter le filtrage ACL et multi-tenant
Évaluer avec RAGAS (recall, faithfulness)
Intégrer l’évaluation en CI/CD
Monitorer avec logs structurés et métriques

Les 4 décisions clés

Avant de commencer, gardez en tête les choix qui impactent le plus la qualité de votre RAG :

1) Taille des chunks

Taille	Effet
Trop petit (<100 tokens)	Perte de contexte, chunks incompréhensibles
300-800 tokens	Bon équilibre (recommandé)
Trop grand (>1500 tokens)	Embeddings dilués, bruit dans les résultats

2) Modèle d’embeddings

Usage	Modèle recommandé
Dev / POC	`all-MiniLM-L6-v2` (rapide, anglais)
Production FR	`intfloat/multilingual-e5-small`
Haute qualité	`BAAI/bge-m3` ou OpenAI `text-embedding-3-large`

3) Top-K (nombre de chunks)

Valeur	Effet
top-K = 3	Rapide, risque de manquer l’info
top-K = 6-10	Bon compromis
top-K > 15	Risque de bruit, coût élevé

4) Recherche dense vs hybride

Approche	Quand l’utiliser
Dense seul	Contenu narratif, peu de termes techniques
Dense + BM25	Docs techniques, codes, IDs (recommandé)

Erreurs fréquentes à éviter

Erreur	Conséquence	Solution
Chunks trop gros	Embeddings dilués, bruit	Réduire à 300-800 tokens
Pas d’overlap	Contexte perdu aux frontières	Overlap 10-20%
Pas de BM25	Rate les termes exacts (codes, IDs)	Recherche hybride
Prompt trop permissif	Hallucinations	”Réponds UNIQUEMENT selon le contexte”
Docs mal extraites	Retrieval incohérent	Nettoyer avec Trafilatura
Pas de métriques	Impossible de mesurer les progrès	Évaluer avec RAGAS

À retenir

RAG = Recherche + Génération : le LLM ne connaît pas vos docs, mais peut les utiliser si vous les injectez
Pipeline complet : Scraping → Nettoyage → Chunking → Embeddings → Vector DB → Retrieval → Génération
Chunking critique : 300-800 tokens, overlap 10-20%, stratégie adaptée au contenu
Recherche hybride : Dense + BM25 > Dense seul pour les docs techniques
Évaluation obligatoire : Sans métriques, vous pilotez à l’aveugle

Commencer le parcours

Trafilatura : récupérer du contenu web Première étape : extraire le contenu des pages à indexer

RAG pratique (parcours accéléré) Vous voulez aller vite ? Ce guide assemble tout en un seul tutoriel