RAG local : introduction

#Pourquoi un RAG plutôt que tout balancer au LLM ?

Première idée naïve : copier-coller tous ses documents dans le prompt et demander au modèle de répondre. Deux problèmes immédiats :

La fenêtre de contexte est limitée

8k, 32k, 128k tokens selon les modèles. 300 PDF = des millions de tokens. Ça ne rentre pas.

Le signal se dilue

Même quand ça rentre, le modèle "se perd" au milieu d'un long contexte (phénomène du lost-in-the-middle). Les réponses se dégradent.

Le RAG résout ça en ne donnant au modèle que les 3 à 10 passages les plus pertinents pour votre question. Le LLM voit 2 000 tokens bien choisis au lieu de 200 000 tokens moyennement pertinents.

#Le concept en 2 minutes

Imaginez un bibliothécaire qui lit tous vos documents une fois et attribue à chacun un "lieu" dans un espace mental. Les documents qui parlent de choses similaires se retrouvent proches. Quand vous posez une question, il va directement au bon quartier chercher les 5 passages les plus pertinents, qu'il donne au LLM pour formuler la réponse.

Ce "lieu dans l'espace" s'appelle un embedding — un vecteur de nombres qui représente le sens d'un morceau de texte. La base de données qui stocke ces vecteurs s'appelle une base vectorielle.

#Anatomie d'un RAG

Tout RAG a deux phases distinctes, qui peuvent tourner sur des machines différentes :

#Phase 1 : Indexation (une seule fois)

Ingestion

Lire PDF, Word, Markdown, HTML… et en extraire le texte propre.

Chunking

Découper le texte en morceaux de 200-500 tokens — assez petits pour être précis, assez gros pour avoir du contexte.

Embedding

Transformer chaque chunk en vecteur via un modèle d'embedding (par ex. BGE, E5, Solon pour le FR).

Stockage

Enregistrer les vecteurs dans une base (ChromaDB, Qdrant, Weaviate…) avec le texte original et les métadonnées.

#Phase 2 : Requête (à chaque question)

Embedding de la question

On encode la question de l'utilisateur avec le même modèle d'embedding.

Recherche

On trouve les N chunks dont le vecteur est le plus proche de celui de la question (cosine similarity).

Assemblage du prompt

On construit un prompt du type : "Voici 5 extraits. Réponds à la question en citant tes sources. [extraits] Question : [question utilisateur]"

Génération

On envoie au LLM (Mistral, Llama, Qwen…) qui produit la réponse finale.

#La stack minimale

Pour un RAG 100 % local qui marche bien, voici la recette de base :

LLM de génération

Mistral 7B, Llama 3.1 8B ou Qwen 2.5 7B — via Ollama.

Modèle d'embeddings

Pour du français, Solon-embeddings ou intfloat/multilingual-e5-large. Pour anglais uniquement, BGE-large.

Base vectorielle

ChromaDB pour démarrer (fichier SQLite, zéro configuration). Qdrant pour production.

Orchestration

LlamaIndex ou Haystack — frameworks qui câblent tout ensemble.

Interface

Open WebUI, AnythingLLM ou un simple script Python pour commencer.

#Le pipeline étape par étape (minimal Python)

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex

docs = SimpleDirectoryReader("./mes_documents").load_data()
# docs est une liste de Document(text=..., metadata=...)

from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.embed_model = HuggingFaceEmbedding("intfloat/multilingual-e5-large")
Settings.llm = Ollama(model="mistral", request_timeout=120)

index = VectorStoreIndex.from_documents(docs)
# À la première exécution : ça prend 2-10 min selon la taille

query_engine = index.as_query_engine(similarity_top_k=5)
response = query_engine.query("Quelles sont les échéances du contrat Dupont ?")
print(response)
print("Sources :", response.source_nodes)

#Les pièges que personne n'évoque

Le chunking naïf casse les tableaux

Une phrase coupée au milieu d'un tableau Markdown donne des chunks incompréhensibles. Utilisez un splitter qui respecte la structure (docling, unstructured).

La langue compte

Un modèle d'embedding anglais sur du contenu français divise la pertinence par 2. Prenez multilingue ou FR-spécifique.

Top-k = 5 rarement optimal

Trop peu : réponse pauvre. Trop : le modèle se noie. Ajustez selon vos documents — 3 pour des notes courtes, 10 pour du juridique dense.

Pas de recherche = mauvais RAG

Un RAG qui renvoie des sources non pertinentes, c'est pire qu'un LLM seul : il hallucine avec l'air d'être sûr. Toujours mesurer la pertinence du retrieval avant de blâmer le LLM.

Les PDF sont des pièges

Double colonne, pieds de page, tableaux, OCR foireux… un tiers du travail sur un RAG industriel, c'est nettoyer l'ingestion.

#Quand ne PAS faire de RAG

Vos documents tiennent dans le contexte

Moins de 20 pages au total ? Envoyez tout directement au LLM. Plus simple, plus précis.

Vous cherchez des réponses factuelles précises

Pour "quel est le chiffre d'affaires en 2024", un bon vieux SQL ou un script d'extraction bat un RAG.

Les documents changent en permanence

Si votre base est réindexée à chaque changement, vous passez plus de temps à indexer qu'à interroger.

Les questions demandent du raisonnement global

"Compare les stratégies 2024 et 2025" nécessite de lire tous les documents, pas d'extraire 5 passages. Là, un résumé puis un LLM sur le résumé marche mieux.

#Et après ?

Le RAG basique marche. Le RAG qui vaut la peine en prod, c'est un RAG tuné. Les chantiers logiques :

Chunking structure-aware

Respecter titres, sections, tableaux, listes.

Recherche hybride

Combiner vectoriel (sémantique) et BM25 (lexical) pour ne pas rater les termes exacts.

Reranking

Un cross-encoder qui réordonne les 20 premiers résultats. +15 % de pertinence en moyenne.

Évaluation

Pas de mesure = pas de progrès. Jeu de 50 questions-réponses de référence, suivi de la précision.