Architecture GraphRAG / RAG

L'écart entre « fragments sémantiquement similaires » et « réponses correctes et complètes » est le point de rupture de la plupart des déploiements RAG en entreprise. Le laboratoire d'IA de Stanford a révélé que 40 % des réponses RAG subissent des hallucinations même lorsque les bons documents sont récupérés. La récupération a fonctionné. L'ancrage non.

Pourquoi le RAG récupère des documents et non des réponses

Cela s'explique par le fait que la similarité vectorielle standard ne peut pas distinguer un passage thématiquement pertinent d'un passage qui répond véritablement à la question. Lorsque votre équipe de conformité demande « quelles sont les exigences de notification pour une violation de données affectant des résidents de l'UE de moins de 16 ans ? » et que votre système renvoie trois fragments sur la notification de violation au titre du RGPD sans les dispositions spécifiques à l'âge, la réponse paraît correcte mais s'avère dangereusement incomplète.

Notre approche consiste à bâtir des systèmes de récupération conçus pour combler cet écart. L'architecture que nous choisissons dépend de vos documents, de vos requêtes et de votre tolérance aux réponses erronées. Il s'agit parfois d'une récupération hybride BM25 + dense avec un réordonnanceur cross-encoder. Parfois, d'un pipeline GraphRAG complet avec extraction d'entités et résumé communautaire. Parfois encore, d'une boucle de récupération agentique qui décompose les questions complexes, récupère de manière itérative et s'auto-corrige avant la génération. Nous ne choisissons pas par défaut l'option la plus complexe — nous privilégions celle qui résout votre problème de récupération à un coût soutenable.

Trois architectures de récupération, adaptées à vos modèles de requêtes

Nous adaptons l'architecture à vos modèles de requêtes plutôt que de céder systématiquement à la complexité. Les trois schémas ci-dessous couvrent la majorité des besoins de production.

Récupération hybride avec réordonnancement

C'est par là que la plupart des systèmes RAG en production devraient commencer. BM25 gère la correspondance exacte par mots-clés (codes d'erreur, références produits, numéros de citations réglementaires) tandis que les plongements denses capturent l'intention sémantique. La fusion de rangs réciproques (RRF, k=60) fusionne les deux ensembles de résultats sans les problèmes de normalisation de scores qui affectent les approches de fusion apprises.

Un réordonnanceur cross-encoder s'y superpose : BGE-reranker-v2-m3 sur GPU offre une latence de 50–100 ms sans coût d'API récurrent, ou Cohere Rerank pour les équipes qui recherchent une infrastructure gérée. Les benchmarks en production démontrent que ce pipeline à deux étapes surpasse toutes les méthodes à étape unique. La récupération contextuelle d'Anthropic vient s'ajouter en couche supérieure, réduisant les échecs de récupération de 49 % (67 % avec réordonnancement) en préfixant le contexte au niveau du document à chaque fragment avant le plongement.

Récupération enrichie par graphes (GraphRAG)

Lorsque vos questions exigent de synthétiser des informations réparties sur plusieurs documents ou de raisonner sur des relations entre entités, la similarité vectorielle seule ne suffit pas. Une équipe juridique demandant « quelles filiales d'AcquiringCo font l'objet d'actions réglementaires en cours dans les juridictions où TargetCo opère ? » a besoin de résolution d'entités, de traversée de relations et de raisonnement multi-sauts.

Nous construisons des graphes de connaissances à partir de vos documents, grâce à une extraction basée sur les dépendances qui atteint 94 % de la performance des modèles fondés sur les LLM à une fraction du coût en jetons (détaillé dans nos recherches sur le GraphRAG avec citations obligatoires). L'approche GraphRAG de Microsoft (clustering de Leiden + résumé communautaire) fonctionne bien pour les requêtes de compréhension globale à l'échelle du corpus, mais ses coûts d'indexation sont 4 à 8 fois supérieurs au RAG standard. Nous l'utilisons de manière sélective :

• Résumés communautaires pour les requêtes globales.
• Traversée de graphes de propriétés pour les questions relatives aux relations entre entités.
• Récupération vectorielle standard pour tout le reste.

Pour le stockage sous-jacent du graphe, FalkorDB prend en charge les charges de travail RAG intensives en lecture à 6 693 QPS avec des démarrages à froid inférieurs à la milliseconde, tandis que Neo4j demeure le choix pertinent lorsque vous exigez un RBAC mature, du clustering et des agrégations complexes.

Récupération agentique

Le schéma le plus performant en 2026, et le plus coûteux à maîtriser. Une boucle de récupération agentique décompose les requêtes complexes en sous-requêtes, achemine chacune vers la stratégie de récupération appropriée (vectorielle, graphe ou base de données structurée), évalue si les résultats sont suffisants et itère jusqu'à atteindre les seuils de confiance fixés.

Nous implémentons cela sur LangGraph, où l'abstraction de machine à états fournit un branchement conditionnel, des nœuds d'interruption avec intervention humaine (human-in-the-loop) et une auditabilité déterministe. Les couches de RAG correctif ajoutent 100 à 800 ms de latence par requête mais interceptent les erreurs de récupération avant qu'elles n'atteignent le LLM. Ce schéma est prêt pour la production chez Morgan Stanley, PwC et ServiceNow. Il n'est pas adapté aux équipes dépourvues de capacité MLOps dédiée pour surveiller et ajuster les boucles de récupération.

Ce qui se passe avant le plongement : réussir le découpage en fragments (chunking)

Le découpage en fragments est l'étape où les systèmes RAG échouent silencieusement. Un découpage naïf à taille fixe produit des scores de fidélité de 0,47–0,51. Le découpage sémantique atteint 0,79–0,82, mais nécessite de plonger chaque phrase de votre corpus. La stratégie adéquate dépend de vos documents :

• Dépôts réglementaires structurés — l'analyse syntaxique sensible à la mise en page préserve la hiérarchie des sections.
• PDF à contenu mixte avec tableaux et graphiques — le découpage guidé par la vision (qui traite chaque page comme une image pour détecter la mise en page, puis extrait les zones de texte) améliore la précision de récupération de 8 à 15 % par rapport à l'analyse textuelle seule.
• Documents narratifs longs — le découpage tardif (late chunking) passe d'abord l'intégralité du document dans le transformeur afin que chaque plongement de jeton reflète le contexte bidirectionnel, puis applique les limites de fragments après la passe avant.

Nous testons trois à quatre stratégies de découpage sur votre ensemble réel de requêtes avant d'en retenir une. Le banc d'évaluation (métriques de fidélité et de précision contextuelle RAGAS, jugements de pertinence propres au domaine) est livré comme partie intégrante du pipeline, et non comme un ajout après coup. 60 % des nouveaux déploiements RAG intègrent désormais une évaluation systématique dès le premier jour, contre moins de 30 % début 2025. Nous intégrons l'évaluation dans votre CI/CD pour mesurer la qualité de récupération à chaque déploiement, plutôt que de la découvrir lorsque les utilisateurs se plaignent.

Combien coûte l'exploitation d'un système RAG d'entreprise ?

Une entreprise industrielle a dépensé 400 000 $ pour déployer un système RAG, avant de constater que les opérations récurrentes coûtaient 18 000 $/mois — soit plus du double de leurs prévisions. Le modèle de coût qu'ils avaient négligé : le réordonnancement. Les API de plongement coûtent 20 à 120 $ par milliard de jetons. L'hébergement de bases de données vectorielles pour 10 millions de vecteurs coûte 1,5 à 3 fois plus cher avec des services gérés (Pinecone, Weaviate Cloud) qu'en auto-hébergement (Qdrant, pgvector). Mais c'est au volume de requêtes de production que le réordonnancement fait exploser les budgets : Cohere Rerank coûte 2 $ pour 1 000 requêtes, tandis que BGE-reranker-v2-m3 auto-hébergé sur un seul GPU égale cette latence sans aucun coût par requête — bien que vous payiez l'instance GPU.

GraphRAG ajoute un niveau de coût supplémentaire. La construction du graphe de connaissances consomme 4 à 8 fois plus de jetons que le texte source pour l'extraction d'entités et les résumés communautaires. La maintenance absorbe 40 à 60 % du budget d'ingénierie de la première année car la résolution d'entités, la déduplication et les mises à jour d'ontologies constituent un travail continu, et non une configuration ponctuelle. L'extraction basée sur les dépendances (NLP classique au lieu d'appels LLM) réduit les coûts de construction d'environ 90 % tout en conservant 94 % de la qualité d'extraction. Nous cadrons chaque mission avec des prévisions explicites de coûts opérationnels mensuels couvrant le plongement, le stockage, la récupération, le réordonnancement et la maintenance du graphe.

Quand GraphRAG en vaut la peine (et quand ce n'est pas le cas)

Vous avez besoin d'une récupération enrichie par graphes lorsque vos requêtes exigent un raisonnement multi-sauts à travers des entités et des relations :

• Audits préalables de fusions-acquisitions (M&A) portant sur des centaines de documents de filiales.
• Synthèse de preuves cliniques sur des bases de données d'interactions médicamenteuses.
• Analyse des risques de chaîne d'approvisionnement reliant les réseaux de fournisseurs aux actions réglementaires.

GraphRAG offre sa plus haute précision de recherche sur les requêtes d'entreprise complexes et multicouches dans les benchmarks (voir une démonstration fonctionnelle de récupération juridique vérifiée par citations). Vous n'en avez pas besoin lorsque vos requêtes se limitent à la recherche dans un document unique, à des réponses de type FAQ ou à des recherches par mots-clés — la récupération hybride BM25 + dense avec un réordonnanceur gère ces cas à une fraction du coût et de la complexité. Si votre corpus compte moins de 5 millions de vecteurs et que vos questions ne franchissent pas les frontières d'un document, pgvector avec indexation HNSW s'avère amplement suffisant. Nous évaluons ce point avant de recommander une architecture, et nous vous indiquons clairement quand l'option la plus simple est la bonne.

La question « avons-nous seulement besoin du RAG ? » se pose également. Avec des fenêtres de contexte atteignant plus d'un million de jetons (Gemini 3 Pro à 10M), certaines équipes envisagent d'injecter des corpus entiers dans le prompt. Le problème : une seule requête d'un million de jetons coûte 2–10 $, ce qui est intenable face au volume de requêtes d'une entreprise. La qualité du contexte se dégrade au-delà de certains seuils, même dans les limites annoncées. Le RAG reste l'architecture de référence pour tout système traitant des requêtes répétées sur des ensembles documentaires volumineux et évolutifs.

Quelle est la surface d'attaque d'un pipeline RAG ?

Les recherches de PoisonedRAG (USENIX Security 2025) ont démontré que cinq documents soigneusement préparés et injectés dans un corpus d'un million de documents peuvent manipuler les réponses de l'IA avec plus de 90 % de succès. Votre pipeline de récupération constitue une voie d'ingestion pour les contenus hostiles. L'OWASP reconnaît désormais formellement les vulnérabilités vectorielles et de plongement (LLM08:2025) ainsi que l'injection de prompt via des documents récupérés (LLM01:2025) parmi les risques majeurs de sécurité des LLM.

Nous intégrons au pipeline de récupération la traçabilité de provenance des documents, la détection d'anomalies au niveau des plongements et des couches d'assainissement des entrées. Chaque passage récupéré comporte des métadonnées de source et un score de confiance. La couche de génération est contrainte de citer des passages précis, et les affirmations qui ne peuvent être ancrées dans le contenu récupéré sont signalées plutôt que transmises. Cela n'a rien de facultatif pour tout système RAG déployé dans des environnements réglementés, comme détaillé dans nos recherches sur la sécurisation des LLM privés d'entreprise.

Ce que nous livrons

Chaque mission produit :

• Une architecture de récupération sélectionnée selon vos modèles de requêtes et vos types de documents spécifiques.
• Une stratégie de découpage et de plongement évaluée sur vos requêtes réelles.
• Un banc d'évaluation prêt pour la production avec métriques RAGAS et cas de test propres au domaine.
• Des prévisions explicites de coûts couvrant le plongement, le stockage, la récupération, le réordonnancement et la maintenance éventuelle du graphe.
• Un durcissement de la sécurité contre les attaques fondées sur la récupération.
• Une pile de surveillance qui détecte la dégradation de la qualité de récupération avant les utilisateurs.

Nous vous indiquons également quand votre configuration actuelle suffit et qu'investir dans une récupération plus complexe ne sera pas rentable.