RAG local avec Ollama : un assistant qui lit VOS documents, 100% hors-ligne

Un LLM, même excellent, ne connaît pas vos contrats, vos procédures internes ni vos notes de réunion. Le RAG (Retrieval-Augmented Generation) comble ce trou : on indexe vos documents, on récupère les passages pertinents à chaque question, et on les injecte dans le contexte du modèle. Fait correctement, vous obtenez un assistant qui cite vos sources réelles — et avec Ollama, tout reste sur votre machine. Zéro fuite, zéro abonnement, zéro Internet.

Cet article est un guide d'ingénieur, pas une démo marketing. On va poser les vrais chiffres 2026, les pièges qui cassent un pipeline RAG, et une architecture qui tient la route hors-ligne.

Pourquoi le RAG local devient sérieux en 2026

Jusqu'à récemment, l'argument « le local est moins bon » tenait surtout sur les embeddings — ces vecteurs qui transforment du texte en coordonnées sémantiques. Ce n'est plus vrai. La famille qwen3-embedding est la première à rivaliser frontalement avec les API commerciales : le modèle 8B atteint 70,58 au classement MTEB multilingue. Pour du français, c'est décisif.

En face, les classiques restent solides : nomic-embed-text (73,8 millions de pulls sur Ollama, score MTEB English ~62,4, contexte natif de 8 192 tokens) et mxbai-embed-large (score ~64,7, mais contexte limité à 512 tokens). En test RAG réel, l'écart entre les deux est faible : nomic gagne sur les questions courtes et directes (63,75% de précision de récupération contre 57,5%), mxbai reprend l'avantage sur les questions longues et contextuelles.

L'architecture en 5 briques

Un pipeline RAG hors-ligne complet tient en cinq étages :

• Ingestion : extraire le texte de vos PDF, Markdown, DOCX, etc.
• Chunking : découper en morceaux digestes pour la recherche.
• Embeddings : vectoriser chaque chunk via un modèle Ollama.
• Base vectorielle : stocker et indexer les vecteurs (Chroma ou Qdrant).
• Retrieval + génération : retrouver les top-k chunks et les passer à un LLM local.

Côté installation, le socle est trivial : ollama pull nomic-embed-text pour les embeddings, ollama pull qwen3:8b (ou llama3.1:8b) pour la génération, et une base vectorielle en local. Tout passe par l'API http://localhost:11434.

Le chunking : là où 80% des RAG échouent

Le découpage est le paramètre le plus sous-estimé. Trop gros, vos chunks noient l'information ; trop petits, ils perdent le contexte. Le consensus 2026 est clair :

• Taille : 256 à 512 tokens couvre la majorité des cas. Descendez à 128-256 pour des questions factuelles précises, montez à 512-1024 pour de l'analytique ou du résumé. Attention au « context cliff » identifié vers 2 500 tokens, où la qualité chute.
• Recouvrement (overlap) : 10 à 20% de la taille du chunk (soit ~50-100 tokens pour 512). NVIDIA a mesuré 15% comme optimal sur FinanceBench. Mais une étude de janvier 2026 montre que sur certains corpus l'overlap n'apporte rien et gonfle juste l'index : testez sur VOS données.
• Stratégie : le découpage récursif (paragraphes → phrases) est le défaut sain. La recherche de Chroma donne 85-90% de rappel à 400 tokens en récursif, contre 91-92% en sémantique — mais le sémantique impose d'embedder chaque phrase, donc un coût compute bien supérieur.

Piège critique : nomic-embed-text est natif 8 192 tokens mais la fiche Ollama affiche 2 048. Si vos chunks dépassent 2 048 tokens sans régler num_ctx, ils sont tronqués silencieusement. Vous croyez indexer un document, vous n'en indexez que le tiers.

Chroma ou Qdrant ? Le vrai arbitrage

Les deux tournent en local, mais ne jouent pas dans la même cour :

• Chroma : le plus simple. Tourne en mémoire ou dans un conteneur Docker minuscule, intégrations LangChain/LlamaIndex les plus matures. Parfait pour prototyper. Plafond réel : au-delà de quelques centaines de milliers de vecteurs, les performances deviennent inconsistantes.
• Qdrant : écrit en Rust, faible empreinte mémoire, latence p99 prévisible, excellent en filtrage par métadonnées (filtrer par source, date, auteur sans exploser la latence). Tient des millions de vecteurs sur un petit VPS à 30-50€/mois.

Verdict : Chroma pour démarrer et valider votre pipeline en une après-midi. Qdrant dès que vous visez de la production, du filtrage sérieux, ou que votre corpus dépasse ~100 000 chunks. La règle communautaire « Chroma pour le proto, Qdrant pour la prod » revient trop souvent pour être ignorée. Mon conseil : si vous savez que ça va grossir, démarrez directement sur Qdrant pour éviter une migration forcée.

Le LLM de génération : dimensionner par la VRAM

Le retrieval ramène les chunks, le LLM rédige la réponse. Choisissez-le selon votre matériel — et n'oubliez pas que les chunks récupérés consomment la fenêtre de contexte (le cache KV grossit avec elle) :

• 6-8 Go VRAM : Llama 3.1 8B ou Qwen3 8B en Q4_K_M, 40+ tokens/s. Le sweet spot pour la plupart des utilisateurs.
• 10-12 Go : Gemma 3 12B ou Qwen3 14B, contexte étendu confortable.
• 24 Go : Qwen3 32B ou Gemma 3 27B (tient sur une RTX 4090 avec contexte serré).
• 48 Go+ : Llama 3.3 70B, la référence RAG (128K de contexte, hallucinations minimales sur le contenu récupéré, 95% de la qualité du 405B pour 17% des paramètres).

Deux optimisations gratuites : activez Flash Attention (moins de VRAM, plus de vitesse, zéro perte de qualité) et, si besoin, la quantification du cache KV en Q8_0 (divise par deux la mémoire du cache). Évitez Q4_0 sur le KV : la perte de qualité devient visible. Pour bien calibrer poids + cache + overhead, voir notre guide VRAM, RAM : calculer ce qui fait tourner un LLM en local.

Assembler le tout, en pratique

Le flux d'une requête : la question est embeddée par le même modèle que les documents (jamais un autre, sous peine d'espaces vectoriels incompatibles), Qdrant/Chroma renvoie les top-k chunks (k=4 à 6 est un bon départ — évitez k=2, trop restrictif), puis on construit un prompt « voici les extraits, réponds uniquement à partir d'eux et cite tes sources ». Le LLM local génère.

Côté outillage, LangChain et LlamaIndex font le ciment, mais pour un assistant codé maison vous n'avez besoin que de trois appels HTTP (embed, search, generate). Et si vous voulez brancher ce RAG dans votre éditeur ou un agent, regardez nos intégrations Ollama avec Codex, Claude et OpenClaw en local. Pour le choix du modèle générateur, notre tour d'horizon des nouveaux modèles LLM local 2026 sur Ollama reste à jour.

Le verdict honnête

Le RAG local en 2026 n'est plus un compromis de second choix. Avec qwen3-embedding au niveau des API commerciales, Qdrant qui encaisse des millions de vecteurs pour le prix d'un VPS, et des LLM 8-14B qui répondent à 40+ tokens/s, vous obtenez un assistant privé, gratuit à l'usage et totalement hors-ligne. Le seul vrai travail n'est pas l'infra — c'est le chunking et l'évaluation sur vos données. Personne ne peut le faire à votre place, et c'est précisément là que se joue la qualité.