RAG en production : architecturer un système de recherche sémantique sur vos données
Pendant des années, exploiter la connaissance accumulée dans une entreprise relevait du défi : documents épars dans des dizaines de dossiers partagés, wikis mal maintenus, emails perdus dans des archives profondes. Les LLM ont apporté une capacité de compréhension du langage naturel sans précédent, mais leur limite est connue : ils ne savent que ce que leur apprentissage contient, figé à une date de coupure. Le Retrieval-Augmented Generation — RAG — résout exactement ce problème en connectant dynamiquement un LLM à vos données fraîches, en temps réel, sans avoir à réentraîner le moindre modèle.
L'enjeu pour les entreprises est considérable. Une base documentaire interne de quelques milliers de pages, des contrats, des tickets de support, des spécifications techniques ou des données réglementaires deviennent interrogeables en langage naturel avec une précision qui rivalise — et souvent dépasse — celle d'un moteur de recherche full-text classique. Mais déployer un RAG fiable en production ne s'improvise pas : chaque étape du pipeline introduit des sources d'erreur qui se cumulent. Cet article détaille l'architecture complète, les décisions techniques qui déterminent la qualité finale et les outils à privilégier en 2026.
Pourquoi le RAG plutôt qu'un fine-tuning ?
La question revient systématiquement lorsqu'une équipe commence à explorer les LLM pour ses données internes : fine-tuner un modèle existant ou construire un système RAG ? Les deux approches ne s'excluent pas, mais elles répondent à des besoins fondamentalement différents. Le fine-tuning modifie les poids du modèle pour lui faire assimiler un style, un jargon ou des patterns de comportement récurrents. Il est pertinent quand vous voulez un modèle qui raisonne différemment — par exemple un modèle médicalement formé, un modèle juridique ou un assistant codeur spécialisé dans votre DSL interne. En revanche, le fine-tuning ne convient pas pour injecter des faits factuellement précis et fréquemment mis à jour : les LLM oublient et confondent, phénomène connu sous le nom de catastrophic forgetting.
Le RAG offre trois avantages décisifs sur le fine-tuning dans la majorité des cas d'usage entreprise. Premièrement, les données restent fraîches : une mise à jour du document source est immédiatement répercutée dans les réponses, sans cycle d'entraînement. Deuxièmement, la confidentialité est mieux maîtrisée : les données ne quittent jamais votre infrastructure si vous utilisez un modèle on-premise ou un API en mode privé, alors qu'un fine-tuning implique de transmettre vos données à un prestataire. Troisièmement, le coût est sans comparaison : un fine-tuning sur GPT-4 ou un modèle open-source de 70 milliards de paramètres représente des milliers d'euros et plusieurs jours de GPU, là où un RAG se déploie en quelques heures sur des machines standards. Le fine-tuning reste pertinent pour améliorer le format des réponses, le ton ou les capacités de raisonnement spécialisé — mais pour accéder à vos données, RAG est la voie royale.
L'architecture d'un système RAG en production
Un pipeline RAG en production comporte sept étapes distinctes, chacune susceptible d'introduire une dégradation si elle est mal paramétrée :
- Ingestion — chargement des sources (PDF, Word, HTML, bases de données, APIs) via des connecteurs dédiés. LlamaIndex et LangChain proposent des loaders pour la majorité des formats courants.
- Chunking — découpage des documents en segments exploitables. C'est l'étape la plus sous-estimée du pipeline (détaillée ci-après).
- Embedding — conversion de chaque chunk en vecteur numérique dense via un modèle d'embedding (text-embedding-3-large d'OpenAI, ou des modèles open-source comme nomic-embed-text ou bge-m3). Les vecteurs ont typiquement 768 à 3 072 dimensions selon le modèle.
- Vector store — stockage et indexation des vecteurs dans une base vectorielle (Qdrant, Weaviate, pgvector…) avec les métadonnées associées (source, date, catégorie, droits d'accès).
- Retrieval — à chaque requête utilisateur, la question est elle-même convertie en vecteur, puis une recherche ANN (Approximate Nearest Neighbor) retourne les k chunks les plus proches (typiquement k = 5 à 20).
- Reranking — les chunks récupérés sont reclassés par un cross-encoder plus précis mais plus lent, afin d'éliminer les faux positifs du retrieval vectoriel.
- Génération — le LLM reçoit la question originale et les chunks retenus comme contexte, puis génère la réponse finale en s'appuyant uniquement sur ce contexte.
En production, des couches supplémentaires s'ajoutent : cache sémantique (éviter de recalculer les embeddings des questions fréquentes), access control (filtrer les chunks selon les droits de l'utilisateur) et logging structuré pour l'évaluation continue. La latence totale d'un pipeline bien optimisé se situe entre 800 ms et 2,5 s pour une question complexe sur un corpus de 100 000 documents, retrieval et reranking inclus.
Chunking : l'étape sous-estimée qui détermine la qualité
La stratégie de chunking est la variable qui impacte le plus la qualité finale des réponses, et c'est pourtant l'étape sur laquelle les équipes passent le moins de temps. Un chunk trop court perd le contexte nécessaire à la compréhension ; un chunk trop long dilue le signal et dépasse la fenêtre de contexte du modèle d'embedding, provoquant une troncature silencieuse.
Trois stratégies principales existent. Le fixed-size chunking découpe les textes à un nombre fixe de tokens (souvent 256 à 512), avec un overlap de 10 à 20 % pour préserver le contexte aux frontières. Simple à implémenter, il convient aux corpus homogènes (articles de blog, tickets de support). Le recursive chunking (implémenté dans LangChain's RecursiveCharacterTextSplitter) respecte les structures naturelles — paragraphes, phrases, mots — en descendant récursivement jusqu'à atteindre la taille cible. Il produit des chunks plus cohérents sémantiquement. Le semantic chunking analyse les changements de thème dans le texte pour créer des frontières naturelles : plus précis mais aussi plus coûteux en calcul, il brille sur les documents longs à contenu varié.
Pour les documents structurés, des stratégies spécifiques s'imposent. Les PDFs avec mise en page complexe nécessitent une extraction par bloc logique (titre + paragraphes associés), non par page. Les tableaux doivent être convertis en représentation textuelle sérialisée, une ligne par entrée, avec les en-têtes répétés pour chaque chunk. Le code source se découpe mieux par unité syntaxique (fonction, classe) que par nombre de tokens, ce qui préserve la cohérence sémantique et améliore significativement les performances du retrieval.
Choisir sa vector database
Le choix de la base vectorielle est une décision structurante qui conditionne les performances, la flexibilité et les coûts opérationnels à long terme. Quatre solutions dominent le marché en 2026 :
Qdrantest écrit en Rust, ce qui lui confère des performances remarquables : il affiche des latences de requête inférieures à 5 ms sur des corpus de plusieurs millions de vecteurs avec des filtres de métadonnées complexes. Son système de filtrage payload est particulièrement puissant pour le contrôle d'accès et la segmentation multi-tenant. Il supporte le mode hybride sparse + dense nativement depuis 2024. C'est le choix privilégié pour les déploiements on-premise haute performance.
Weaviatemise sur la versatilité : interface GraphQL, modules d'embedding intégrés, multi-tenancy natif et un écosystème de modules qui simplifie l'intégration avec les LLM courants. Sa gestion multi-tenant est la plus mature du marché, ce qui en fait le choix naturel pour les plateformes SaaS qui isolent des données par client. Sa latence est légèrement supérieure à Qdrant sur les requêtes filtrées complexes.
pgvectorest l'extension PostgreSQL qui apporte la recherche vectorielle dans votre base de données existante. Son atout principal est la simplicité opérationnelle : pas d'infrastructure supplémentaire, transactions ACID natives, JOIN entre vecteurs et données relationnelles. Il tient correctement jusqu'à quelques millions de vecteurs et des latences de 10 à 50 ms. Au-delà, les performances se dégradent sans tuning poussé. C'est le choix naturel pour les équipes qui veulent démarrer vite avec un footprint infrastructure minimal.
Pineconeest un service cloud managé qui efface toute complexité opérationnelle. Son scaling automatique, son SLA de disponibilité et son intégration native avec les outils LangChain et LlamaIndex en font le choix par défaut pour les prototypes et les équipes sans compétence DevOps dédiée. Son prix à l'index et aux requêtes peut devenir significatif au-delà de quelques dizaines de millions de vecteurs, et la dépendance à un cloud externe est rédhibitoire pour les environnements souverains.
Reranking et fusion : aller au-delà du cosine similarity
La similarité cosinus entre vecteurs d'embedding est un excellent premier filtre, mais elle souffre d'une limite fondamentale : elle mesure la proximité sémantique globale sans comprendre la relation précise entre une question et un passage. Un chunk qui contient les mêmes mots-clés qu'une question peut être très proche en cosine similarity tout en n'étant pas la source de réponse la plus pertinente. Sur des corpus métier denses, les études montrent que le retrieval pur par similarité cosinus atteint un recall de 60 à 75 % sur les chunks vraiment utiles — insuffisant pour un usage en production.
Le cross-encoder rerankingrésout ce problème. Contrairement aux bi-encoders (qui encodent séparément la question et le document), un cross-encoder traite la paire question/passage ensemble et produit un score de pertinence contextualisé. Cogerent-AI, Mixedbread et Jina proposent des modèles de reranking open-source qui améliorent le recall de 15 à 25 points de pourcentage sur des benchmarks RAG standards. La contrepartie est la latence : un cross-encoder traite typiquement 10 à 50 ms par paire, d'où l'importance de ne reranker que les top-k résultats du retrieval vectoriel (typiquement les 20 premiers) et non l'ensemble du corpus.
La Reciprocal Rank Fusion (RRF) est une technique de fusion de résultats issus de plusieurs stratégies de retrieval. Elle combine les rangs (et non les scores) de plusieurs listes indépendantes pour produire un classement final plus robuste. La formule est simple : RRF(d) = Σ 1/(k + rank(d)) pour chaque liste, avec k = 60 typiquement. L'hybrid search exploite cette fusion en combinant un retrieval par vecteurs denses (sémantique) avec BM25 (exact keyword matching) : le dense capture la proximité thématique, le BM25 capte les correspondances exactes de termes techniques, noms propres ou identifiants. La combinaison des deux améliore systématiquement les performances sur les corpus métier.
Évaluer et monitorer un système RAG
Un système RAG sans évaluation rigoureuse est une boîte noire. Quatre métriques fondamentales permettent de mesurer objectivement la qualité du pipeline, popularisées par le framework RAGAS (RAG Assessment) :
- Faithfulness : la réponse générée est-elle entièrement fondée sur les chunks récupérés, sans hallucination ? Une faithfulness de 0,95+ est l'objectif minimum pour un usage professionnel.
- Answer Relevancy : la réponse répond-elle effectivement à la question posée ? Ce score détecte les dérives où le LLM paraphrase le contexte sans répondre à la question.
- Context Precision : parmi les chunks récupérés, quelle proportion est réellement utile pour répondre ? Un score bas indique un retrieval trop bruité.
- Context Recall : tous les faits nécessaires à la réponse sont-ils présents dans les chunks récupérés ? Un score bas signale des lacunes dans l'indexation ou un chunking inadapté.
En production, ces métriques doivent être calculées en continu sur un échantillon de requêtes réelles, idéalement en comparant les réponses à un ground truth maintenu par des experts métier. Le monitoring de la distribution des scores d'embedding est également crucial : un drift dans la distribution des queries (nouvelles questions hors domaine, évolution du vocabulaire métier) se détecte avant que la qualité des réponses se dégrade. Des outils comme Langfuse, Phoenix ou Arize permettent d'instrumenter ce monitoring avec quelques dizaines de lignes de code.
“La qualité d'un système RAG dépend à 80 % de la qualité de vos données sources et de votre stratégie de chunking. Augmenter la complexité du modèle sur des données mal structurées ne fait qu'amplifier le bruit.”
Déployer un RAG en production est un projet d'ingénierie à part entière, pas un simple branchement d'API. Chaque étape du pipeline — du chunking au reranking en passant par le choix de la vector database — requiert des décisions éclairées qui dépendent de votre corpus, de vos contraintes de latence et de confidentialité. La bonne nouvelle est que les outils et les benchmarks sont désormais matures : il est possible de mesurer objectivement la qualité d'un système RAG et d'itérer méthodiquement. Les organisations qui investissent dans cette rigueur dès le départ construisent un avantage durable sur celles qui empilent de la complexité technique sans jamais mesurer si leurs systèmes répondent vraiment aux questions de leurs utilisateurs.