RAG local : introduction

#RAG local : la définition et ce que vous en attendez

RAG signifie retrieval-augmented generation : on récupère d'abord des passages pertinents dans une base de documents, puis on demande au modèle de rédiger une réponse à partir d'eux. Le mot local précise que chaque étape (lecture des documents, calcul des embeddings, stockage, génération) s'exécute sur votre matériel. C'est l'usage le plus utile d'un modèle privé : questions sur des contrats, des notes, une base de connaissances interne, avec des réponses qui citent leurs sources.

#Pourquoi un RAG plutôt que tout envoyer au modèle

Première idée : copier tous ses documents dans le prompt. Deux limites s'opposent. La fenêtre de contexte est bornée : 300 PDF représentent des millions de tokens, bien au-delà de ce qu'un modèle local accepte. Et même quand un document tient, la qualité baisse : une étude de référence (Liu et al., Stanford) montre que la performance peut chuter nettement lorsque l'information utile se trouve au milieu d'un long contexte, même pour des modèles conçus pour de longs contextes. Ce phénomène s'appelle lost in the middle.

Le RAG contourne ces deux problèmes en ne transmettant au modèle que quelques passages choisis pour la question. Le modèle lit quelques centaines de tokens bien ciblés au lieu de dizaines de milliers de tokens peu utiles, avec un coût de calcul et une latence moindres. Tout l'art consiste à bien récupérer.

Un ordre de grandeur, en calcul illustratif : 300 PDF de 20 pages à environ 600 tokens la page représentent 3,6 millions de tokens, soit des centaines de fois la fenêtre de 8 000 tokens que l'on règle souvent sur un modèle local. Découpés en passages de 400 tokens, ils donnent environ 9 000 passages. Une question en retient cinq, soit 2 000 tokens : le modèle lit 0,06 % du corpus, mais les bons 0,06 % si la recherche est réussie.

#Le concept en deux minutes : embeddings et distance

Un embedding est une liste de nombres qui représente le sens d'un texte. Deux textes qui parlent de la même chose ont des vecteurs proches, même s'ils n'emploient pas les mêmes mots. La documentation d'Ollama décrit les embeddings comme des vecteurs numériques que l'on peut stocker dans une base vectorielle, chercher par similarité cosinus ou utiliser dans un RAG, avec une longueur qui dépend du modèle, typiquement entre 384 et 1024 dimensions.

Une question est transformée en vecteur par le même modèle, puis comparée à tous les passages indexés : les plus proches sont renvoyés. Le point qui piège les débutants : le modèle d'embedding utilisé pour l'index et celui utilisé pour les questions doivent être identiques. La documentation de LlamaIndex le rappelle dans son exemple de rechargement d'index : il est important d'utiliser le même embed_model que celui qui a servi à le construire.

#Anatomie d'un RAG : deux phases

#Phase 1 : l'indexation, faite une fois par document

1. 01
   Ingestion

   Lire les fichiers (PDF, Word, Markdown, HTML) et en extraire le texte propre. C'est l'étape la plus sous-estimée.
2. 02
   Découpage

   Couper en passages assez petits pour être précis, assez grands pour garder du sens. Des passages de 200 à 500 tokens sont un point de départ courant.
3. 03
   Embedding

   Passer chaque passage dans le modèle d'embedding, par exemple avec la commande ollama run embeddinggemma ou l'API /api/embed.
4. 04
   Stockage

   Enregistrer les vecteurs avec le texte d'origine et des métadonnées (nom du fichier, page, date).

#Phase 2 : la requête, à chaque question

1. 01
   Embedding de la question

   Avec le même modèle que pour l'indexation.
2. 02
   Recherche

   Trouver les N passages dont le vecteur est le plus proche, mesure par similarité cosinus.
3. 03
   Assemblage du prompt

   Construire un message qui contient les extraits et la consigne de répondre en citant les sources et de dire quand la réponse n'y figure pas.
4. 04
   Génération

   Envoyer ce prompt au modèle local, qui rédige la réponse.

#La pile minimale, et les options sans code

Pour un RAG local qui fonctionne, quatre briques suffisent : un modèle de génération servi par Ollama, un modèle d'embedding, une base vectorielle, et une couche qui les relie. Pour le français, choisissez un modèle d'embedding multilingue ; la page d'Ollama en recommande trois (embeddinggemma, qwen3-embedding, all-minilm), et les tailles de vecteur restent modestes, ce qui permet de les exécuter sur un ordinateur portable.

Pour ne pas coder, le guide sur le RAG dans LM Studio et celui sur AnythingLLM détaillent chaque voie ; le guide sur NotebookLM et les alternatives locales couvre la requête « notebook lm rag ».

#Le pipeline en Python, étape par étape

L'exemple ci-dessous suit le schéma officiel du tutoriel LlamaIndex avec modèles locaux : un lecteur de répertoire, un modèle d'embedding, un modèle servi par Ollama, puis un moteur de requête. Installez d'abord les paquets llama-index-llms-ollama et llama-index-embeddings-huggingface. Adaptez les noms de modèles à ce que vous avez téléchargé.

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

Settings.embed_model = HuggingFaceEmbedding(model_name="intfloat/multilingual-e5-large")
Settings.llm = Ollama(model="qwen3.5:9b", request_timeout=360.0, context_window=8000)

documents = SimpleDirectoryReader("mes_documents").load_data()
index = VectorStoreIndex.from_documents(documents)
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(response.source_nodes)

La première exécution calcule tous les embeddings, ce qui prend plus ou moins de temps selon le volume et la machine. Pour éviter de tout recalculer, sauvegardez l'index avec index.storage_context.persist, puis rechargez-le avec load_index_from_storage en réutilisant le même modèle d'embedding. Le paramètre context_window limite la mémoire consommée, comme le précise le tutoriel.

#Les pièges qui font échouer les premiers essais

Le découpage naïf casse les structures

Une coupure au milieu d'un tableau donne des passages illisibles. Utilisez un découpeur qui respecte titres et tableaux, ou convertissez d'abord les documents avec Docling.

La langue de l'embedding compte

Un modèle d'embedding entraîné surtout sur l'anglais retrouve moins bien des passages français. Prenez un modèle multilingue et testez-le sur 10 questions réelles avant d'indexer tout le corpus.

Un top-k unique convient rarement

Trop peu de passages appauvrit la réponse ; trop en noie le modèle. Ajustez selon la nature des documents et vérifiez sur des questions dont vous connaissez la réponse.

Une mauvaise recherche produit une réponse assurée et fausse

Un modèle à qui l'on donne des extraits non pertinents peut inventer une réponse qui semble sûre. Mesurez d'abord la pertinence des extraits.

Les PDF sont piégeux

Double colonne, pieds de page, tableaux, scans : une part importante du travail est de nettoyer l'ingestion. Un PDF scanné demande de l'OCR avant tout autre traitement.

Mélanger les modèles d'embedding

Indexer avec un modèle et interroger avec un autre donne des résultats absurdes, sans message d'erreur.

#Quand ne pas faire de RAG

Le guide comparant fine-tuning et RAG détaille ce dernier cas.

#Matériel et confidentialité : ce qui reste chez vous

Dans un RAG entièrement local, les documents, les vecteurs et les questions restent sur la machine, à condition que chaque brique le soit : embedding servi par Ollama ou chargé depuis le disque, base vectorielle en fichier ou en service local, modèle de génération local. Vérifiez qu'aucun composant n'appelle un service en ligne : un embedder ou un modèle cloud sélectionné par erreur enverrait vos passages à l'extérieur.

Côté matériel, le poste le plus lourd est le modèle de génération : en Q4, un modèle de 8 à 9 milliards de paramètres tient dans environ 5 Go de mémoire, plus le contexte. Le contexte s'agrandit ici, car il contient les extraits : prévoyez de la marge si vous augmentez le nombre de passages. L'embedding, lui, est léger ; l'indexation initiale d'un gros corpus reste l'opération la plus longue et se fait une fois. Le guide sur les LLM sans GPU indique ce que chaque quantité de RAM permet.

#Et après ? Les améliorations dans l'ordre

Un RAG de base répond souvent bien à des questions simples. Pour aller plus loin, l'ordre le plus rentable est le suivant : d'abord un découpage qui respecte la structure, puis la recherche hybride (vectorielle et par mots-clés BM25, pour ne pas rater un terme exact comme un numéro de contrat), puis un reranker qui réordonne les premiers résultats, enfin une évaluation sur un jeu d'une cinquantaine de questions dont vous connaissez la réponse. Sans mesure, chaque changement reste une impression.

• Le RAG c'est quoi : guide débutant
• Stratégies de découpage des documents
• Embeddings pour le français
• RAG dans LM Studio
• AnythingLLM : tutoriel RAG
• Évaluer un RAG avec Ragas

• Source : embeddings dans Ollama
• Source : tutoriel LlamaIndex avec modèles locaux
• Source : Lost in the Middle (Liu et al.)
• Source : LM Studio, Chat with Documents