Comment construire un pipeline RAG en 2026 (étape par étape)

La génération augmentée par la recherche a cessé d’être une simple curiosité scientifique il y a déjà plusieurs années. En 2026, c’est la méthode par défaut pour faire interagir un LLM avec vos propres documents sans avoir à payer pour affiner un modèle ni à prendre le risque qu’il invente des réponses de son propre chef. Le principe est simple à décrire, mais sa mise en œuvre présente de nombreuses difficultés : trouver le bon texte, le transmettre au modèle et laisser celui-ci rédiger la réponse.

Il s’agit d’un guide de mise en place, et non d’une étude. À la fin de ce guide, vous saurez exactement de quels composants un pipeline RAG opérationnel aura besoin en 2026, quels outils et versions de modèles spécifiques utiliser, et vous disposerez d’un code minimal que vous pourrez exécuter localement ou via une API. Nous avons vérifié chaque numéro de version, chaque prix et chaque benchmark ci-dessous par rapport à des sources actuelles — car le pire bug RAG est celui que vous copiez depuis un article de blog rédigé pour les bibliothèques de l’année dernière.

Comment fonctionne concrètement un pipeline RAG ?

Un système RAG comporte deux phases. Indexation Cette opération s'effectue une seule fois (ou à chaque fois que vos documents sont modifiés) : vous divisez les fichiers source en segments, vous convertissez chaque segment en vecteur à l'aide d'un modèle d'intégration, puis vous stockez ces vecteurs dans une base de données. Requêtes Cela se passe à chaque requête : vous intégrez la question de l'utilisateur, vous identifiez les segments les plus similaires, vous les réorganisez éventuellement par ordre de pertinence, vous insérez les meilleurs d'entre eux dans une invite, puis vous interrogez un modèle de langage de grande capacité (LLM).

C'est justement là tout l'intérêt. Tout réside dans les détails techniques : la taille des segments, le modèle d'intégration à utiliser, le nombre de résultats à extraire, la nécessité ou non d'un reclassement, et la manière d'évaluer l'efficacité de ces différents éléments. Si vous souhaitez acquérir les bases théoriques avant de vous lancer dans la mise en œuvre, notre Présentation du RAG traite de la théorie ; cet article porte sur la mise en œuvre. Et si vous hésitez encore entre RAG et la personnalisation du modèle lui-même, le Comparaison entre le réglage fin et la méthode RAG C'est le bon point de départ : pour la plupart des équipes qui alimentent un modèle de langage grand public (LLM) avec des données privées et évolutives, le RAG constitue la solution la moins coûteuse et la plus facile à maintenir.

Étape 1 : Regroupez vos documents par lots

Les modèles d'intégration ont une limite de contexte et, surtout, perdent en précision sur les longs passages. Il faut donc diviser les documents en segments. Le consensus de 2026, étayé par des tests de performance plutôt que par des impressions subjectives, est sans fioritures : utiliser un séparateur de caractères récursif ciblant approximativement 512 tokens présentant un chevauchement de 10 à 201 TP3T (50 à 100 jetons).

Une évaluation réalisée en février 2026 sur 50 documents réels a révélé que le découpage récursif naïf à 512 tokens atteignait une précision de recherche de 691 TP3T, tandis que le découpage sémantique — qui tente de découper en fonction des limites de sens — n'atteignait que 541 TP3T. La raison est simple : le découpage sémantique a produit des fragments d’une taille moyenne de 43 tokens, trop petits pour fournir au modèle suffisamment de contexte pour répondre. Par ailleurs, une autre étude menée en janvier 2026 et utilisant la récupération SPLADE a montré que le chevauchement augmentait le coût d’indexation sans apporter d’avantage mesurable sur son ensemble de données. La conclusion à retenir : commencez par des segments récursifs de taille fixe, et n’optez pour le découpage sémantique ou au niveau de la page que si vos indicateurs d’évaluation démontrent que cela est nécessaire pour vos documents spécifiques.

Étape 2 : Choisir un modèle d'intégration

Il s'agit de la décision la plus déterminante de tout le projet, et les différences entre les options sont bien réelles. Voici les choix qui méritent d'être pris en compte à la mi-2026, accompagnés de chiffres vérifiés.

Pour un prototype, commencez à petite échelle avec nomic-embed-text — il est rapide, gratuit, tient sur un ordinateur portable de 16 Go et, selon certaines sources, surpasse l'ancienne version d'OpenAI text-embedding-ada-002. En matière de production, le secteur de l'open source a véritablement rattrapé son retard : BGE-M3 est le cheval de bataille sous licence MIT sur lequel s'appuient par défaut la plupart des piles auto-hébergées, tandis que Voyage-3.5 et Gemini Embedding dominent les tests de performance des API gérées. La seule règle qui compte : Quel que soit le modèle utilisé pour intégrer vos documents, vous devez intégrer vos requêtes selon le même modèle. Le mélange des modèles nuit imperceptiblement à la recherche.

Étape 3 : Stocker les vecteurs dans une base de données vectorielle

Une fois que vous disposez de représentations, celles-ci doivent être stockées dans un environnement permettant une recherche rapide par « plus proche voisin ». En 2026, vous disposez de trois niveaux de stockage pertinents.

Une analyse plus détaillée se trouve dans notre Guide sur les bases de données vectorielles, mais pour la plupart des équipes, le processus de décision est simple : si vous utilisez déjà Postgres → pgvector ; si vous avez besoin d'un filtrage intensif ou de milliards de vecteurs → Qdrant ou Milvus ; si vous en êtes encore au stade de l'expérimentation → Chroma.

Étape 4 : Récupération et reclassement

La recherche proprement dite se résume à un seul appel : intégrer la requête, demander à la base de données les k blocs les plus proches (k vaut généralement entre 20 et 50). Mais la similarité vectorielle brute est un outil peu précis. A reranker — un encodeur croisé qui attribue un score à chaque paire requête-document individuellement — reclasse ces candidats et met en avant ceux qui sont véritablement pertinents avant qu’ils n’atteignent le modèle.

Procédure standard : extraire les 50 premiers résultats avec votre bi-encodeur, les reclasser, puis ne conserver que les 5 à 10 premiers. Cohere Rerank 3.5 coûte $0,002 par recherche ($2 pour 1 000) et ajoute généralement une latence de l'ordre de 100 à 300 ms. Si vous disposez d'un GPU et que vous souhaitez un coût par requête nul, l'open source BGE-reranker-v2-m3 s'exécute en environ 50 à 100 ms et prend en charge les contenus multilingues. Le reclassement est l'une des améliorations les plus efficaces et les moins contraignantes que vous puissiez apporter — la plupart des pipelines qui “ renvoient des résultats inutiles ” négligent cette étape.

Étape 5 : Enrichir la consigne et générer

Créez maintenant la consigne : une brève instruction système indiquant au modèle de ne s'appuyer que sur le contexte fourni, les segments reclassés et la question de l'utilisateur. Appelez ensuite votre LLM.

Pour le modèle de génération, vous pouvez choisir entre une solution locale ou via l'API. En local, via Ollama, the 2026 sweet spot is an 8B-class model — Qwen3 8B ou Llama 3.1 8B at Q4_K_M quantization — which fits in 8–12GB of VRAM and runs at 40+ tokens/second on a modern GPU. Qwen3 14B (~8–9GB at Q4) is a strong step up with a 128K context window for stuffing in more retrieved text. For a hosted, higher-ceiling option, a frontier API model works well; our Tutoriel sur le chatbot Claude API parcourt ce chemin de bout en bout. Un rappel utile de la part des praticiens : pour le RAG, la qualité de la recherche est généralement plus importante que la taille du modèle — des segments de données propres, associés à un bon embedder et à un petit LLM, sont plus performants qu’un modèle gigantesque alimenté par un contexte de mauvaise qualité.

Étape 6 : Un exemple de code minimal

Voici un pipeline local complet utilisant LangChain 1.x, Chroma et Ollama. Il indexe un document et répond à une question — aucune clé API n'est requise.

# pip install langchain langchain-community langchain-chroma langchain-ollama
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_chroma import Chroma

# 1. Load + chunk (~512 tokens, ~15% overlap; sizes are in characters)
docs = TextLoader("handbook.txt").load()
chunks = RecursiveCharacterTextSplitter(
 chunk_size=2000, chunk_overlap=300
).split_documents(docs)

# 2. Embed + 3. Store
embeddings = OllamaEmbeddings(model="nomic-embed-text")
store = Chroma.from_documents(chunks, embeddings)

# 4. Retrieve (top 4)
retriever = store.as_retriever(search_kwargs={"k": 4})

# 5. Augment + generate
llm = ChatOllama(model="qwen3:8b")
question = "What is the refund window?"
context = "nn".join(d.page_content for d in retriever.invoke(question))
prompt = (f"Answer using ONLY the context. If it's not there, say so.nn"
 f"Context:n{context}nnQuestion: {question}")
print(llm.invoke(prompt).content)

Voilà toute la boucle. Pour ajouter un reclassement, insérez un Récupérateur de compression contextuelle avec un encodeur croisé entre les étapes 4 et 5. Avec LlamaIndex 0.14.x, le même flux nécessite généralement moins de code grâce à ses abstractions de recherche spécialement conçues — c’est le meilleur choix pour les applications faisant un usage intensif de la recherche, tandis que le runtime LangGraph de LangChain excelle lorsque vous avez besoin d’agents à plusieurs étapes et avec état. (Le choix d’une couche d’orchestration est un sujet à part entière ; consultez notre Comparaison des frameworks d'agents IA.)

Étape 7 : Évaluer — ne passez pas cette étape

La différence entre une démo et un produit réside dans la mesure. L'outil standard est RAGAS, qui évalue la fidélité (la réponse correspond-elle bien au contexte ?), la précision contextuelle et la couverture contextuelle en utilisant un modèle de langage de grande envergure (LLM) comme juge. Créez un petit ensemble de 20 à 50 paires question-réponse à partir de vos documents réels et testez-le à chaque modification.

C'est également ainsi que vous prenez chaque décision en amont en toute objectivité. Faut-il passer au « semantic chunking » ? Ajouter un « reranker » ? Faire passer k de 4 à 8 ? Ne vous fiez pas à votre intuition : modifiez une variable, relancez RAGAS, et ne conservez la modification que si les résultats s'améliorent. Sans cette boucle, vous effectuez des réglages à l'aveuglette.

FAQ

Combien coûte l'exploitation d'un pipeline RAG ?

La création de prototypes est pratiquement gratuite. Grâce aux intégrations locales d’Ollama, à Chroma et à un LLM local, votre seul coût est celui de l'électricité. À grande échelle, les principales dépenses concernent la base de données vectorielle (une instance Qdrant ou pgvector auto-hébergée sur votre propre machine virtuelle revient nettement moins cher que les offres gérées, dont le coût peut dépasser $5 000 par mois pour 100 millions de vecteurs) et, si vous utilisez des API, les encodages (OpenAI text-embedding-3-large coûte $0,13 par million de tokens) ainsi que les appels de génération.

Ai-je besoin d'une base de données vectorielle, ou puis-je utiliser une base de données classique ?

Vous avez besoin d'une recherche vectorielle, mais pas nécessairement d'un produit dédié. pgvector ajoute cette fonctionnalité à PostgreSQL et gère 1 million de vecteurs avec une faible latence p95 (quelques millisecondes sur NVMe, un peu plus sur un SSD cloud) ; ainsi, si vous utilisez déjà Postgres, vous pouvez vous passer complètement d'une nouvelle infrastructure. Optez pour une base de données dédiée comme Qdrant lorsque vous avez besoin d’un filtrage intensif des métadonnées ou de milliards de vecteurs.

Quelle taille de bloc dois-je utiliser ?

Commencez avec environ 512 tokens et un chevauchement de 10 à 20% en utilisant un séparateur récursif. Un test de performance réalisé en 2026 a montré que cette méthode surpassait le découpage sémantique en termes de précision de recherche, avec un score de 691 TP3T contre 541 TP3T. Ne passez à un découpage plus sophistiqué que si vos indicateurs d'évaluation montrent que cela améliore les résultats sur vos documents spécifiques.

Un « reranker » est-il vraiment nécessaire ?

Ce n’est pas pour que ça fonctionne, mais c’est l’une des améliorations de qualité les moins chères qui existent. Récupérez un ensemble étendu (les 50 premiers), reclassez-les à l’aide de Cohere Rerank 3.5 ou de l’outil open source BGE-reranker-v2-m3, puis ne conservez que les 5 à 10 premiers. La plupart des pipelines qui font ressortir des segments non pertinents omettent tout simplement cette étape.

Puis-je créer un RAG sans LangChain ni LlamaIndex ?

Oui. La boucle principale — intégration, recherche, invite, génération — compte environ 40 lignes de code Python simple qui appellent directement votre modèle d’intégration, votre client de base de données vectorielle et votre LLM. Les frameworks permettent de gagner du temps sur les chargeurs, les réclassificateurs et l’orchestration des agents, mais ils sont facultatifs, et une implémentation « à partir de zéro » vous offre un contrôle total sur chaque étape.

Dois-je utiliser un modèle local ou une API pour la génération ?

L'exécution locale (via Ollama, avec un modèle 8B et 8 à 12 Go de VRAM) est idéale pour préserver la confidentialité, maîtriser les coûts et utiliser l'application hors ligne. Une API vous offre une qualité maximale et zéro opération. De nombreuses équipes réalisent leurs prototypes en local pour itérer à moindre coût, puis choisissent le mode de déploiement en fonction de la sensibilité des données et de leur budget.

Comment puis-je actualiser l'index à mesure que les documents évoluent ?

Réintégrez et effectuez des « upserts » uniquement sur les éléments modifiés, plutôt que de tout reconstruire. Suivez un hachage de contenu ou une date de modification pour chaque document source, et lors d'une mise à jour, supprimez les anciens segments de ce document et insérez les nouveaux. La plupart des bases de données vectorielles prennent en charge les « upserts » et les suppressions via un filtre de métadonnées, ce qui facilite grandement les mises à jour incrémentielles.

Conclusion

Construire un pipeline RAG en 2026 est vraiment à la portée de tous : six étapes, quelques outils éprouvés et environ 40 lignes de code suffisent pour obtenir un prototype fonctionnel. Les pièges ne se trouvent pas dans l’architecture, mais dans les paramètres par défaut. Utilisez des blocs classiques de 512 tokens, harmonisez vos embedders de requêtes et de documents, ajoutez un module de reclassement, et ne procédez jamais à des réglages sans impliquer RAGAS dans le processus. Commencez localement et gratuitement avec nomic-embed-text, Chroma et un modèle Ollama de 8 milliards de paramètres ; ne passez à pgvector, Qdrant, Voyage ou une API de pointe pour les composants individuels que lorsque vos résultats d’évaluation — et non un article de blog — vous y incitent. Maîtrisez bien la recherche et un petit modèle vous mènera étonnamment loin.