Infrastructure RAG : Construire des systèmes de génération augmentée par récupération prêts pour la production

Mis à jour le 8 décembre 2025

Mise à jour de décembre 2025 : L'adoption du RAG s'accélère en tant que cas d'usage LLM n°1 en entreprise. Les architectures GraphRAG et RAG agentique gagnent du terrain pour le raisonnement complexe. Le marché des bases de données vectorielles se consolide autour de Pinecone, Weaviate, Milvus et Qdrant. Voyage-3-large surpasse les embeddings d'OpenAI et Cohere de 9 à 20 %. Le chunking sémantique améliore le rappel jusqu'à 9 % par rapport aux approches à taille fixe. Les défis de production évoluent des prototypes vers l'échelle — la dérive des embeddings, la multi-tenancy et les exigences de latence inférieure à 50 ms stimulent les investissements en infrastructure.

Harvey AI dessert 97 % des 100 plus grands cabinets d'avocats américains (Am Law 100) en utilisant la génération augmentée par récupération pour ancrer la recherche juridique dans la jurisprudence réelle plutôt que dans des citations hallucinées.¹ Anthropic, OpenAI et Google recommandent tous le RAG comme technique principale pour connecter les grands modèles de langage aux données propriétaires d'entreprise. Pourtant, l'écart entre un prototype RAG fonctionnel et une infrastructure prête pour la production représente des mois d'efforts d'ingénierie. Les organisations découvrent que les bases de données vectorielles, les pipelines d'embedding, les stratégies de chunking et l'optimisation de la récupération présentent chacun des défis d'infrastructure distincts qui se cumulent à l'échelle. Construire des systèmes RAG capables de gérer des millions de documents, de servir des milliers d'utilisateurs simultanés et de maintenir une latence inférieure à la seconde nécessite des décisions architecturales que peu d'équipes anticipent pendant les phases de preuve de concept.

L'architecture de base que tout système RAG de production nécessite

Les systèmes RAG combinent deux capacités fondamentales : récupérer le contexte pertinent d'une base de connaissances et générer des réponses ancrées dans ce contexte. L'architecture se décompose en cinq composants distincts, chacun avec des exigences d'infrastructure spécifiques.

Les pipelines d'ingestion de documents gèrent le flux depuis les documents bruts jusqu'aux embeddings interrogeables. Les systèmes de production traitent des PDF, HTML, documents Word, messages Slack et enregistrements de base de données via des parseurs spécifiques à chaque format. Les pipelines d'ingestion doivent suivre les versions des documents, gérer les mises à jour incrémentales et maintenir les métadonnées pour le filtrage. Les déploiements d'entreprise typiques traitent entre 100 000 et 10 millions de documents lors du backfill initial, avec des chargements incrémentaux quotidiens de 1 000 à 50 000 nouveaux documents.²

Les systèmes de chunking divisent les documents en segments adaptés à la récupération. Le chunking à taille fixe fonctionne pour le contenu homogène comme les articles d'actualité, tandis que le chunking sémantique préserve les frontières de sens pour les documents complexes.³ La plupart des systèmes de production utilisent le chunking récursif avec 400-512 tokens et un chevauchement de 10-20 %, atteignant un rappel de 85-90 % dans les tests de référence.⁴ Le choix de la stratégie de chunking devient semi-permanent — changer d'approche ultérieurement nécessite de ré-embedder l'ensemble du corpus.

L'infrastructure d'embedding convertit les chunks de texte en représentations vectorielles denses. Les organisations choisissent entre des API gérées (OpenAI, Cohere, Voyage AI) et des modèles auto-hébergés. La génération d'embeddings crée la structure de coûts la plus variable dans les systèmes RAG, avec des tarifs allant de 0,02 $ à 0,18 $ par million de tokens selon le modèle sélectionné.⁵ Le traitement par lots parallélise la génération d'embeddings sur des nœuds GPU pour les chargements initiaux, tandis que les pipelines en streaming gèrent les mises à jour incrémentales.

Les bases de données vectorielles stockent et récupèrent les embeddings en utilisant des algorithmes de plus proches voisins approximatifs. Les quatre options dominantes — Pinecone, Weaviate, Milvus et Qdrant — servent différents profils opérationnels. Pinecone offre un service géré sans ops, Weaviate fournit une recherche hybride avec des capacités de graphe de connaissances, Milvus gère les déploiements à l'échelle du milliard, et Qdrant excelle dans le filtrage complexe des métadonnées.⁶ Les besoins de stockage évoluent avec la dimension des embeddings et le nombre de documents ; un corpus de 10 millions de documents avec des embeddings de 1024 dimensions nécessite environ 40 Go de stockage vectoriel.

L'orchestration de la récupération et de la génération relie les composants ensemble, généralement en utilisant des frameworks comme LangChain, LlamaIndex ou des implémentations personnalisées. L'orchestration gère le traitement des requêtes, la récupération, le reranking, la construction des prompts et la génération de réponses. Les systèmes de production implémentent des couches de cache, des stratégies de fallback et une instrumentation d'observabilité à chaque étape.

Le choix de la base de données vectorielle détermine la complexité opérationnelle

Le marché des bases de données vectorielles s'est consolidé autour de quatre acteurs majeurs en décembre 2025, chacun servant des profils opérationnels et des cas d'usage distincts.

Pinecone domine le segment des services gérés, gérant entièrement l'infrastructure derrière leur API. Les équipes déploient des systèmes de production en heures plutôt qu'en semaines, avec mise à l'échelle automatique, réplication multi-région et conformité SOC 2 incluses. Pinecone supporte jusqu'à 40 Ko de métadonnées par vecteur, permettant un filtrage riche sans systèmes externes. Le compromis implique des coûts par requête plus élevés et un contrôle réduit sur l'optimisation de l'infrastructure. Les organisations avec des charges de travail prévisibles trouvent souvent Pinecone rentable ; celles avec un trafic très variable ou des exigences d'échelle extrêmes migrent généralement vers des alternatives.⁷

Weaviate fait le pont entre la flexibilité open-source et la commodité gérée via Weaviate Cloud. Le système combine la recherche vectorielle avec des capacités de graphe de connaissances, permettant des requêtes hybrides qui filtrent sur des données structurées tout en classant par similarité sémantique. L'architecture modulaire de Weaviate supporte plusieurs modèles d'embedding simultanément, utile pour les organisations expérimentant différentes approches. Les déploiements Docker et Kubernetes nécessitent une expertise opérationnelle modeste, rendant Weaviate populaire parmi les équipes ayant une certaine capacité d'infrastructure.⁸

Milvus (et son équivalent géré Zilliz Cloud) cible les déploiements à l'échelle du milliard avec la performance comme objectif principal de conception. Milvus mène les benchmarks en latence brute, atteignant des temps de requête inférieurs à 10 ms sur des indices de milliards de vecteurs grâce à l'accélération GPU et des algorithmes d'indexation avancés.⁹ L'architecture sépare le calcul et le stockage, permettant une mise à l'échelle indépendante de chaque couche. Opérer Milvus nécessite une expertise significative en ingénierie des données — les équipes sans personnel d'infrastructure dédié ont souvent du mal avec la gestion des clusters et le tuning des performances.

Qdrant a gagné une adoption rapide pour les exigences de filtrage complexe. Construit en Rust, Qdrant exécute le filtrage des payloads directement dans l'algorithme de recherche plutôt qu'en post-traitement, offrant des performances supérieures pour les requêtes filtrées.¹⁰ L'empreinte ressource compacte rend Qdrant populaire pour les déploiements sensibles aux coûts, tandis que sa conception d'API claire accélère la vélocité de développement. Les déploiements auto-hébergés fonctionnent sans problème sur une infrastructure modeste, bien que les fonctionnalités enterprise nécessitent une licence commerciale.

Les critères de sélection devraient prioriser la capacité opérationnelle en premier. Les équipes nécessitant zéro ops choisissent Pinecone ou Weaviate Cloud. Les organisations avec une capacité SRE à l'aise avec les workloads Kubernetes stateful gagnent en économies et en contrôle avec Milvus, Qdrant ou Weaviate auto-hébergés. Les exigences de conformité éliminent parfois des options — Pinecone et Weaviate Cloud offrent la conformité SOC 2 et HIPAA, tandis que les mandats on-premise nécessitent des solutions auto-hébergées.

Le choix du modèle d'embedding affecte à la fois le coût et la qualité de récupération

Les modèles d'embedding convertissent le texte en représentations vectorielles, et le choix du modèle impacte directement la précision de la récupération. Le paysage de décembre 2025 offre trois options commerciales leaders plus plusieurs alternatives open-source solides.

Voyage AI mène les benchmarks MTEB, avec voyage-3-large surpassant text-embedding-3-large d'OpenAI de 9,74 % et embed-v3-english de Cohere de 20,71 % sur les domaines évalués.¹¹ Voyage AI supporte des fenêtres de contexte de 32K tokens (comparé à 8K pour OpenAI et 512 pour les anciens modèles Cohere), permettant le traitement de documents plus longs sans chunking. Les embeddings de 1024 dimensions coûtent 0,06 $ par million de tokens — 2,2x moins cher qu'OpenAI et 1,6x moins cher que Cohere — tout en nécessitant 3x moins de stockage vectoriel que les embeddings de 3072 dimensions d'OpenAI.

OpenAI text-embedding-3-large offre l'option la plus éprouvée pour les déploiements de production. Le modèle supporte des dimensions de sortie configurables de 256 à 3072, permettant des compromis coût-stockage. À 0,13 $ par million de tokens, OpenAI se situe au milieu de la gamme de prix tout en offrant une disponibilité fiable et une documentation extensive. Les organisations utilisant déjà les API d'inférence d'OpenAI standardisent souvent sur leurs embeddings pour la simplicité opérationnelle.

Cohere embed-v4 a atteint le score MTEB le plus élevé (65,2) en novembre 2025, optimisé spécifiquement pour la recherche et la récupération plutôt que pour l'embedding généraliste.¹² Les embeddings Cohere s'associent naturellement avec le reranker de Cohere pour les pipelines de récupération à deux étages. Le modèle excelle dans les applications multilingues, supportant plus de 100 langues avec une récupération cross-lingue solide.

Les alternatives open-source incluant les modèles BGE, E5 et GTE permettent l'embedding auto-hébergé à l'échelle. Les organisations traitant des milliards de documents déploient souvent ces modèles sur une infrastructure GPU interne pour éliminer les coûts par token. L'auto-hébergement nécessite de gérer les mises à jour des modèles, la planification de capacité et l'optimisation de l'inférence — des compromis qui n'ont de sens qu'à une échelle significative.

La décision sur le modèle d'embedding se répercute sur l'ensemble du système. Changer de modèle ultérieurement nécessite de ré-embedder le corpus complet de documents, un processus qui coûte du temps, du calcul et potentiellement une interruption de service. Les systèmes de production devraient évaluer les modèles sur des benchmarks spécifiques au domaine plutôt que de se fier aux scores MTEB génériques. Un modèle excellant en connaissances générales peut sous-performer sur des textes juridiques, médicaux ou financiers.

Les stratégies de chunking déterminent la précision de la récupération

Le chunking de documents crée les unités atomiques que le système de récupération recherche. Le choix de la stratégie de chunking compte parmi les décisions d'infrastructure les plus conséquentes, avec une variation potentielle de rappel de 9 % entre les meilleures et les pires approches.¹³

Le chunking à taille fixe divise les documents à des comptages de tokens prédéterminés indépendamment de la structure du contenu. L'approche fonctionne bien pour les corpus homogènes — articles d'actualité, descriptions de produits ou documents standardisés. L'implémentation nécessite une complexité minimale, faisant du chunking à taille fixe le point de départ naturel pour les prototypes. La plupart des systèmes de production utilisent des chunks de 400-512 tokens avec des chevauchements de 50-100 tokens, équilibrant la granularité de récupération avec la préservation du contexte.

Le chunking sémantique divise les documents aux frontières significatives — sauts de paragraphe, en-têtes de section ou changements thématiques — préservant des idées cohérentes dans chaque chunk. L'implémentation utilise les embeddings de phrases pour détecter les frontières sémantiques, coupant lorsque la similarité entre phrases adjacentes tombe sous un seuil. Le chunking sémantique améliore le rappel jusqu'à 9 % pour le contenu narratif comme la documentation, les FAQ et les données conversationnelles.¹⁴ L'approche nécessite plus de calcul pendant l'ingestion et un ajustement soigneux des seuils de similarité.

Le chunking récursif applique des règles de division hiérarchiques, tentant d'abord de grandes divisions (sauts de section), puis progressivement de plus petites (sauts de paragraphe, sauts de phrase) jusqu'à ce que les chunks atteignent la taille cible. Le RecursiveCharacterTextSplitter de LangChain implémente ce pattern, atteignant de fortes performances sur des types de documents divers sans ajustement par corpus. Le chunking récursif équilibre la simplicité d'implémentation avec la qualité de récupération, en faisant la recommandation par défaut pour les nouveaux systèmes.

Le chunking au niveau de la page a émergé des benchmarks NVIDIA montrant une précision de 0,648 avec la plus faible variance entre les types de documents.¹⁵ Pour les documents structurés comme les rapports et les articles, traiter chaque page comme un chunk préserve les relations spatiales et les références croisées. Les approches au niveau de la page fonctionnent mal pour les documents sans frontières de page claires (HTML, logs de chat, code) mais excellent pour les corpus lourds en PDF.

Le chunking hiérarchique construit des index multi-niveaux avec une granularité imbriquée — niveaux section, sous-section, paragraphe et phrase. La récupération identifie d'abord les sections pertinentes, puis approfondit dans des p

[Contenu tronqué pour la traduction]