#Le RAG en 30 secondes

RAG signifie Retrieval-Augmented Generation : génération de texte augmentée par de la recherche. Au lieu de demander directement au LLM « réponds à cette question », on commence par chercher dans une base de documents les passages les plus pertinents, puis on les colle dans le prompt en disant : « voici les sources, réponds en t'appuyant dessus ».

L'image qui marche bien : un LLM tout seul, c'est un étudiant brillant qui répond de mémoire à un examen. Un RAG, c'est le même étudiant qui a le droit d'ouvrir le cours sur la table. Il invente moins, il cite la bonne page, et si on lui donne un cours qu'il n'a jamais vu (vos PDF, vos emails, votre wiki interne), il peut quand même répondre dessus.

En une phrase

RAG = retrouver les bons passages dans vos documents + les injecter dans le contexte du LLM avant qu'il ne réponde. C'est tout. Le reste, c'est de l'ingénierie autour de ces deux idées.

#Pourquoi (et quand) en avoir besoin

Un LLM a deux gros défauts qui ressortent dès qu'on l'utilise sérieusement : il invente quand il ne sait pas (les fameuses « hallucinations »), et il ne connaît que les données vues à l'entraînement. Mistral 7B n'a jamais lu votre contrat, votre wiki Notion, ni votre base d'incidents. Lui demander d'y répondre directement, c'est demander à quelqu'un d'imaginer le contenu d'un livre qu'il n'a pas ouvert.

Le RAG résout les deux à la fois : on injecte les bons extraits dans le prompt, le LLM s'en sert comme base factuelle, et les réponses deviennent traçables — vous pouvez afficher les sources.

Discuter avec vos PDF: Notices techniques, contrats, articles scientifiques, manuels — tout ce qui pèse trop pour tenir dans une fenêtre de contexte.
Assistant interne d'équipe: Wiki, base de connaissances support, documentation produit. Au lieu d'un Ctrl+F approximatif, une réponse en français qui cite les bonnes pages.
Veille et synthèse: Indexer des centaines d'articles ou rapports, poser des questions transverses, comparer des sources.
Données récentes ou privées: Tout ce que le LLM n'a pas pu voir : votre code, vos emails, des publications postérieures à sa date de coupure.

→

Quand le RAG n'apporte rien

Pour des tâches purement génératives (rédaction libre, brainstorming, traduction, refactoring de code court), un LLM sans RAG suffit largement. Ne mettez pas de RAG juste parce que c'est à la mode — c'est utile quand vous avez un corpus que le modèle ne connaît pas, pas avant.

#Le pipeline en 4 étapes

Un RAG, c'est deux phases : l'indexation (une fois, en amont) et l'interrogation (à chaque question). Voici les quatre briques qui s'enchaînent.

01
1. Chunking — découper les documents
Vos PDF, fichiers Markdown ou pages web sont d'abord découpés en morceaux (chunks) de 200 à 800 mots environ. On ne peut pas embedder un livre entier d'un coup, et de toute façon on veut retrouver le passage précis qui répond à la question, pas tout le document.
02
2. Embeddings — transformer le texte en vecteurs
Chaque chunk passe dans un modèle d'embeddings qui le transforme en un vecteur de nombres (typiquement 384 à 1024 dimensions). Deux passages qui parlent de la même chose donneront des vecteurs proches dans cet espace — c'est la magie qui permet la recherche sémantique.
03
3. Stockage dans une base vectorielle
Les vecteurs + le texte original sont rangés dans une base spécialisée (Chroma, Qdrant, FAISS…) qui sait répondre vite à la question « quels sont les vecteurs les plus proches du mien ? ».
04
4. Retrieval + génération
À la question de l'utilisateur, on calcule son embedding, on récupère les 3 à 10 chunks les plus proches, on les colle dans le prompt du LLM avec une instruction du type « réponds en t'appuyant sur ces extraits », et le LLM génère la réponse.

Pseudo-code du pipeline complet

# Phase 1 : INDEXATION (une fois)
for doc in documents:
    chunks = split(doc, taille=500)              # 1. chunking
    for chunk in chunks:
        vector = embedder.embed(chunk)            # 2. embedding
        vector_db.add(vector, chunk)              # 3. stockage

# Phase 2 : INTERROGATION (à chaque question)
question = "Quel est le délai de résiliation ?"
q_vector = embedder.embed(question)               # même modèle qu'à l'indexation
top_chunks = vector_db.search(q_vector, k=5)      # 4a. retrieval

prompt = f"""Réponds en t'appuyant uniquement sur les extraits ci-dessous.

Extraits :
{top_chunks}

Question : {question}"""
reponse = llm.generate(prompt)                    # 4b. génération

Le LLM ne « cherche » pas — il lit

Beaucoup d'illustrations laissent croire que le LLM va « interroger une base ». Faux. Le retrieval est fait avant l'appel au LLM. Quand le LLM intervient, il reçoit un prompt classique avec les passages déjà collés dedans. Côté modèle, c'est une simple conversation enrichie.

#Embeddings : le cœur du retrieval

Un modèle d'embeddings est un mini-LLM spécialisé dans une seule tâche : transformer un morceau de texte en un vecteur de nombres qui capture son « sens ». Deux phrases qui parlent du même sujet donneront des vecteurs proches, même si elles n'ont aucun mot en commun. C'est ce qui distingue le RAG d'un bête Ctrl+F.

La qualité finale du RAG dépend autant — souvent plus — du modèle d'embeddings que du LLM derrière. Un mauvais embedding remonte les mauvais chunks, et le meilleur LLM du monde ne pourra pas répondre correctement à partir de bouts de texte hors-sujet.

nomic-embed-text: 137M paramètres, 768 dimensions, contexte 8192 tokens. Le défaut sain proposé par Ollama. Bon en anglais, correct en français.
mxbai-embed-large: 335M paramètres, 1024 dimensions. Plus précis, 3× plus lent. Pertinent quand la qualité du retrieval est limitante.
multilingual-e5-large: 560M, 1024 dimensions. Le meilleur choix si vos documents sont en français ou multilingues.
bge-m3: Excellent en français, supporte des contextes longs. Plus lourd à faire tourner mais référence sur du contenu pluri-langues.

Le piège de l'embedding anglais sur du français

Un nomic ou un bge anglais sur des PDF français divise la pertinence du retrieval par 1.5 à 2. Vous obtiendrez des passages vaguement liés au sujet plutôt que ceux qui répondent vraiment. Pour un corpus français, prenez multilingual-e5-large ou bge-m3 dès le départ — la lenteur supplémentaire est négligeable comparée au gain.

#La base vectorielle : où vivent les vecteurs

Une base vectorielle est une base de données spécialisée dans une opération : « trouve-moi les N vecteurs les plus proches de celui-ci ». En coulisses, elle utilise des algorithmes (HNSW, IVF…) qui rendent cette recherche rapide même sur des millions de vecteurs. Pour démarrer, vous n'avez besoin de rien comprendre à ces algos — juste savoir laquelle choisir.

Chroma: Base vectorielle open source, embarquée dans votre projet Python ou en serveur. Idéale pour démarrer : zéro config, persistance sur disque.
Qdrant: Plus robuste pour la production : serveur dédié, filtres, multi-tenant. Tourne dans un conteneur Docker en une commande.
FAISS: Bibliothèque de Facebook (Meta). Très rapide, mais c'est juste un index — pas de gestion de métadonnées. Bon pour des cas perf-critiques.
Stockée dans l'outil: Open WebUI, AnythingLLM, LM Studio embarquent leur propre base vectorielle. C'est invisible — vous uploadez un PDF, c'est indexé. Parfait pour démarrer sans coder.

#Le LLM : génération guidée

Le LLM est le dernier maillon. Il reçoit un prompt qui ressemble à : « voici 5 extraits issus de la documentation. Réponds à la question en t'appuyant exclusivement dessus. Si l'information n'est pas dans les extraits, dis-le. »

Ce cadrage change tout. Sans contexte injecté, le LLM répond depuis sa mémoire d'entraînement — et invente si elle est lacunaire. Avec les bons extraits dans le prompt, il a une base factuelle sous les yeux et se contente de reformuler ou de synthétiser.

Quelle taille de LLM ?: Pour du RAG simple, un 7B Q4 (Mistral, Llama 3.1 8B, Qwen 2.5 7B) suffit largement. La qualité du retrieval compte plus que la taille du LLM.
Quelle fenêtre de contexte ?: Au moins 4096 tokens. Les chunks récupérés + la question + l'instruction système consomment vite 2000-3000 tokens. Avec 8192 ou plus, vous êtes confortable.
Quel system prompt ?: Un truc du genre : « tu réponds en français en t'appuyant uniquement sur les extraits fournis. Si l'information n'y est pas, dis-le clairement. »

#RAG local vs API cloud

Vous pouvez monter un RAG avec l'API OpenAI ou Claude (rapide à mettre en place, perf maximale) ou tout en local avec Ollama + une base vectorielle + un modèle d'embeddings (zéro fuite de données, zéro coût à l'usage). Le choix dépend de la sensibilité des documents et de votre budget.

RAG via API cloud: Vos documents sont envoyés au prestataire (OpenAI, Anthropic, Mistral…) lors de l'indexation et de chaque question. Performance et qualité au top, mais incompatible avec des données confidentielles (RGPD, secret médical, contrats clients).
RAG 100% local: Ollama pour le LLM, nomic ou bge pour les embeddings, Chroma ou Qdrant pour la base. Aucune donnée ne quitte la machine. Idéal pour les pros (juriste, médecin, RH), les entreprises soumises au RGPD, et tous ceux qui veulent garder le contrôle.
Hybride: Embeddings en local, LLM via API : limite l'exposition (les documents complets restent locaux, seuls les chunks pertinents partent au cloud à la question). Compromis pragmatique mais déconseillé si les chunks eux-mêmes sont sensibles.

→

Le RAG local marche sur du modeste matériel

Vous n'avez pas besoin d'une RTX 4090. Un PC avec 16 Go de RAM et un CPU récent fait tourner un RAG complet (Mistral 7B Q4 + nomic-embed-text + Chroma) à 5-10 tokens/sec. Avec un GPU 8 Go (RTX 3060, 4060), vous passez à 30-50 tokens/sec. C'est largement suffisant pour discuter avec ses documents.

#Par où commencer concrètement

Trois chemins selon votre profil. Tous les trois tournent 100% en local sur votre machine.

01
Sans coder, avec une interface (Open WebUI ou AnythingLLM)
Vous installez Ollama, vous lancez Open WebUI ou AnythingLLM dans Docker, vous uploadez vos PDF dans une « Knowledge Base » et vous discutez. Tout — chunking, embeddings, retrieval — est géré pour vous. 30 minutes du début à la fin.
02
Sans coder, en mode tout-en-un (LM Studio)
Depuis la version 0.3, LM Studio a une fonctionnalité « Chat with Documents » : vous attachez un fichier au chat, il s'en charge. Limite : 5 fichiers par chat et des formats restreints (PDF texte, DOCX, TXT, MD). Parfait pour des questions ponctuelles sur un doc.
03
En Python avec LangChain ou LlamaIndex
Le contrôle total : choix du chunker, du modèle d'embeddings, de la base, du LLM, du prompt. Prévoyez une demi-journée pour un premier prototype propre, plus si vous voulez optimiser (reranker, recherche hybride, etc.).

Stack RAG local minimale avec Ollama

# 1. Installer Ollama (https://ollama.com)
# 2. Récupérer un LLM et un modèle d'embeddings
ollama pull mistral
ollama pull nomic-embed-text

# 3. Vérifier que le daemon répond
curl http://localhost:11434/api/tags

# 4. Lancer Open WebUI (interface ChatGPT-like avec RAG intégré)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Ouvrir http://localhost:3000
# Settings -> Documents -> uploader des PDF
# Dans un chat : taper # pour attacher une Knowledge Base

#Les pièges classiques quand on débute

Embedder en anglais, documents en français: Cause numéro 1 de RAG décevant en France. Vérifiez que votre modèle d'embeddings supporte le français (multilingual-e5, bge-m3).
Chunks trop grands ou trop petits: 500 mots est un bon point de départ. Trop petit (< 100 mots), les chunks perdent leur contexte ; trop grand (> 1500), l'embedding moyenne tout et perd en précision.
Changer d'embedder sans réindexer: Les vecteurs d'un modèle ne sont pas compatibles avec ceux d'un autre. Si vous passez de nomic à bge, il faut tout réindexer — sinon le retrieval renvoie n'importe quoi.
Trop de chunks dans le contexte: Au-delà de 8-10 chunks, le LLM commence à se perdre. Mieux vaut 5 chunks très pertinents que 20 moyennement pertinents (c'est là qu'un reranker entre en jeu, à un niveau plus avancé).
Pas de citations affichées: Pour vérifier qu'un RAG fonctionne vraiment, affichez les sources utilisées à chaque réponse. Si vous n'avez pas cette visibilité, vous ne saurez pas distinguer une bonne réponse d'une hallucination convaincante.

#Pour aller plus loin

Maintenant que vous savez ce qu'est le RAG, voici les guides naturels pour passer à la pratique.

RAG local avec Ollama sans coder: Le tuto pas à pas Open WebUI + AnythingLLM pour monter votre premier RAG en 30 minutes, même sans GPU.
Les meilleurs modèles d'embeddings FR: Comparatif détaillé pour choisir entre nomic, multilingual-e5, bge-m3 et Solon selon votre corpus.
RAG local : introduction: Le guide conceptuel approfondi : chunking, retrieval, reranking, métriques d'évaluation.
Ollama c'est quoi et comment ça marche: Si vous n'avez pas encore Ollama installé, par là.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Use Cases · 10 min

Le RAG c'est quoi et comment ça fonctionne (guide débutant)