RAG, Graph RAG ou Agentic RAG : le type de question décide l'architecture

Une équipe qui conçoit un système de recherche augmentée commence souvent par comparer des technologies : base vectorielle ou graphe, pipeline déterministe ou agent, embeddings généralistes ou spécialisés. Cette entrée par les composants encourage une architecture ambitieuse avant même d’avoir défini le problème de retrieval.

La première question devrait être différente : quelle forme de preuve faut-il reconstruire pour répondre ?

Certaines demandes portent sur un fait explicitement formulé dans un passage. D’autres exigent de traverser plusieurs relations dont aucun document ne donne seul la conclusion. D’autres encore ne permettent pas de connaître à l’avance la source à consulter, l’outil à appeler ou l’ordre des opérations.

Ces trois formes correspondent à trois niveaux d’architecture : RAG vectoriel, Graph RAG et Agentic RAG. Elles ne constituent pas une échelle de maturité. Un agent n’est pas une version « avancée » dont chaque application devrait se rapprocher. C’est un mécanisme plus coûteux et plus difficile à contrôler, justifié seulement lorsqu’une question exige une décision dynamique.

Faire correspondre le retrieval à la preuve attendue

La distinction proposée par Avi Chawla dans son post consacré aux trois formes de RAG fournit un bon point de départ :

• une recherche factuelle à un saut relève d’abord du RAG standard ;
• une relation multi-hop invisible à la similarité appelle une représentation en graphe ;
• un problème où il faut choisir dynamiquement les sources, les outils et leur ordre peut justifier un agent.

Il s’agit ici d’un fait sourcé : cette taxonomie résume l’argument du post. La règle opérationnelle qui suit est une interprétation d’ingénierie : commencer par l’option la moins complexe, puis n’ajouter un mécanisme que lorsqu’un test reproductible révèle une classe d’échec qu’il sait réellement corriger.

Cette prudence évite trois confusions fréquentes. Une réponse difficile à formuler n’implique pas nécessairement un retrieval difficile. Plusieurs documents pertinents n’impliquent pas nécessairement un graphe. Enfin, appeler deux API dans un ordre fixe ne transforme pas un pipeline en système agentique.

Le bon niveau dépend moins du nombre de sources que de la manière dont leurs informations doivent être reliées.

RAG vectoriel : retrouver un passage qui contient déjà la réponse

Le RAG vectoriel convient lorsque la question et le passage utile partagent un voisinage sémantique suffisamment fort. Le pipeline indexe des fragments, calcule leurs embeddings, récupère les éléments les plus proches de la requête, puis les transmet au modèle avec une consigne de réponse fondée sur le contexte.

Pour une question comme « Quelle est la durée de conservation des journaux d’audit ? », un document contenant « Les journaux d’audit sont conservés pendant 90 jours » porte directement la preuve. Le retrieval doit identifier ce passage, pas reconstruire une chaîne causale.

Cette architecture reste une excellente valeur par défaut parce qu’elle est observable. On peut inspecter les chunks retournés, mesurer leur classement, ajuster la segmentation, combiner recherche lexicale et vectorielle, filtrer par métadonnées ou employer un reranker. Sa latence et son coût sont relativement prévisibles.

Un échec de RAG standard ne prouve toutefois pas qu’il faut un graphe. Le problème peut venir :

• d’une segmentation qui sépare le sujet de sa propriété ;
• d’un embedding mal adapté au domaine ou à la langue ;
• de métadonnées absentes ;
• d’un top-k trop faible ;
• d’une requête contenant des identifiants rares mieux servis par BM25 ;
• d’un corpus obsolète ou incomplet.

Avant de changer d’architecture, il faut établir que la preuve existe, que l’index l’a bien absorbée et qu’un retrieval hybride ou un reranking ne suffit pas.

HyDE améliore une requête, mais ne produit aucune preuve

HyDE, pour Hypothetical Document Embeddings, peut aider lorsque la question est courte, abstraite ou formulée très différemment des documents. La méthode décrite dans le papier de Gao, Ma, Lin et Callan demande à un modèle de générer un document hypothétique, encode ce document, puis utilise son embedding pour retrouver de vrais documents voisins dans le corpus.

Le point décisif est explicitement reconnu par les auteurs : le document généré est irréel et peut contenir des détails faux. Il sert de requête de recherche enrichie, jamais de source probante. L’explication pédagogique d’Outcome School sur le fonctionnement de HyDE le présente à juste titre comme une recherche amorcée par une réponse fictive.

Le contrat de sécurité doit donc rester strict :

1. générer l’hypothèse ;
2. l’utiliser uniquement pour le retrieval ;
3. écarter son texte lors de la construction de la preuve ;
4. répondre à partir des documents réels retrouvés ;
5. signaler l’absence de preuve suffisante.

HyDE peut améliorer le rappel d’un RAG vectoriel. Il ne résout pas une dépendance multi-hop et ne transforme pas une hallucination plausible en fait vérifié.

Le cas checkout : quand le fait intermédiaire disparaît de la similarité

Considérons une question d’exploitation :

Quel service sera affecté par la maintenance de vendredi ?

Le corpus contient trois éléments distincts :

1. checkout-service dépend de payments-api ;
2. payments-api est déployée sur cluster-3 ;
3. cluster-3 sera en maintenance vendredi.

La réponse attendue est que checkout-service risque d’être affecté. Pourtant, le passage intermédiaire — « payments-api est déployée sur cluster-3 » — ne contient ni le mot « checkout » ni le mot « maintenance ».

Une recherche vectorielle sur « checkout maintenance vendredi » peut retrouver le premier passage grâce à checkout-service, puis le troisième grâce à « maintenance vendredi ». Elle peut manquer le deuxième, qui est pourtant le pont indispensable. Même si les deux extrémités apparaissent dans le contexte, le modèle n’a pas le droit d’inventer leur connexion.

La preuve est un chemin :

checkout-service → DEPENDS_ON → payments-api → DEPLOYED_ON → cluster-3 → HAS_MAINTENANCE → vendredi

Le Graph RAG devient pertinent lorsque ce type de relation n’est pas une exception, mais une forme récurrente de question. Les entités et leurs arêtes rendent le chemin récupérable sans demander à la similarité sémantique de deviner un lien lexicalement absent.

Cette représentation permet aussi d’attacher la provenance à chaque arête. La relation DEPENDS_ON peut pointer vers un manifeste de service ; DEPLOYED_ON, vers la configuration de déploiement ; HAS_MAINTENANCE, vers un calendrier d’infrastructure. La réponse ne repose alors pas seulement sur un chemin logique, mais sur un chemin dont chaque étape peut être auditée.

Il faut néanmoins séparer deux opérations :

• le graphe retrouve les relations candidates ;
• le modèle explique leur implication dans la réponse.

Un graphe erroné ne devient pas fiable parce qu’il est structuré. Une relation extraite par un LLM reste une donnée dérivée qui doit conserver son document source, sa date, son niveau de confiance et, si nécessaire, une validation métier.

Graph RAG : local, global et exploratoire ne désignent pas la même requête

La documentation du moteur de requête Microsoft GraphRAG distingue plusieurs modes dont les coûts et les usages diffèrent.

Local Search combine les informations du graphe de connaissances extraites par IA avec des chunks des documents bruts. Ce mode vise les questions centrées sur des entités précises. Le cas checkout-service correspond naturellement à cette logique : partir d’une entité, suivre son voisinage pertinent et réinjecter les passages sources.

Global Search interroge des rapports de communautés générés sur l’ensemble du corpus selon une approche map-reduce. Microsoft le décrit comme plus gourmand en ressources et adapté aux questions portant sur le dataset dans son ensemble : thèmes dominants, tendances générales ou caractéristiques transversales. Ce n’est pas le choix automatique pour toute question multi-hop.

DRIFT Search élargit le point de départ d’une recherche locale avec des informations issues des communautés, puis affine la recherche au moyen de questions de suivi. Il convient aux demandes exploratoires qui commencent par une entité mais nécessitent un contexte plus large.

Ces comportements sont des faits documentés. L’interprétation d’ingénierie est la suivante : « utiliser Graph RAG » n’est pas une décision assez précise. Il faut encore choisir le mode de requête compatible avec la portée de la question. Lancer une recherche globale pour chaque demande locale paie le coût maximal sans garantie d’améliorer la preuve.

Le coût existe également à l’indexation. Le dépôt officiel Microsoft GraphRAG avertit que l’indexation peut être coûteuse et recommande de commencer petit. Extraire des entités, résoudre leurs identités, produire des relations, former des communautés et générer des synthèses ajoute des appels de modèle, du stockage et des opérations de maintenance.

Un prototype raisonnable commence donc par un sous-corpus représentatif et deux ou trois types de relations indispensables. Le graphe doit être motivé par des questions réelles, pas par l’espoir qu’une ontologie exhaustive deviendra utile plus tard.

Agentic RAG : décider du chemin de recherche pendant l’exécution

L’Agentic RAG devient pertinent lorsque le chemin ne peut pas être entièrement déterminé avant de recevoir la question ou d’observer les premiers résultats.

Imaginons une demande plus ouverte :

La maintenance de vendredi menace-t-elle des commandes importantes, et faut-il prévenir un client ?

Pour répondre, le système peut devoir :

1. rechercher les dépendances de checkout-service ;
2. consulter le calendrier d’infrastructure ;
3. vérifier le statut actuel de cluster-3 ;
4. interroger les commandes prévues pendant la fenêtre ;
5. identifier les comptes concernés ;
6. s’arrêter si la maintenance est annulée ;
7. demander une validation humaine avant toute communication.

Ici, l’agent ne sert pas seulement à parcourir un graphe. Il choisit les sources et l’ordre des appels selon les observations. Si l’API d’infrastructure indique que la maintenance a été déplacée, il peut éviter les requêtes commerciales. Si le graphe ne connaît pas le service, il peut chercher dans le catalogue technique. Si une source échoue, il peut appliquer une stratégie de repli autorisée.

Ce pouvoir ajoute des risques : boucles, appels redondants, dépassement de budget, choix d’outil incorrect, exposition excessive de données ou action prématurée. Un agent doit donc recevoir des limites structurelles : outils explicitement autorisés, schémas d’entrée stricts, budget d’appels, durée maximale, journal de décision, règles d’arrêt et confirmation pour les actions externes.

Un pipeline qui appelle toujours la recherche vectorielle, puis le graphe, puis une API n’est pas nécessairement agentique. C’est un workflow déterministe, souvent préférable parce qu’il est plus facile à tester. L’agent se justifie lorsque l’ordre ou même la sélection des étapes dépend du résultat intermédiaire.

Router sans transformer chaque requête en débat d’agent

Le routeur peut commencer comme une fonction typée, déterministe et observable. Il ne doit pas prétendre comprendre parfaitement la question : il produit une décision, un niveau de confiance et des signaux vérifiables.

type RetrievalMode = "vector" | "graph" | "agentic";

type RetrievalRoute = {
  mode: RetrievalMode;
  confidence: number;
  signals: Array<
    "single-hop" | "multi-hop" | "dynamic-source" | "dynamic-order"
  >;
  maxToolCalls: number;
};

function routeRetrieval(question: string): RetrievalRoute {
  const q = question.toLowerCase();

  if (/puis|selon le résultat|vérifie.*et décide/.test(q)) {
    return {
      mode: "agentic",
      confidence: 0.78,
      signals: ["dynamic-source", "dynamic-order"],
      maxToolCalls: 6,
    };
  }

  if (/dépend|relié|impacté|chemin|via/.test(q)) {
    return {
      mode: "graph",
      confidence: 0.72,
      signals: ["multi-hop"],
      maxToolCalls: 2,
    };
  }

  return {
    mode: "vector",
    confidence: 0.65,
    signals: ["single-hop"],
    maxToolCalls: 1,
  };
}

Ce code est volontairement court. En production, les règles peuvent être remplacées par un classifieur évalué sur un jeu de questions annotées. Le contrat demeure plus important que l’implémentation : aucune décision silencieuse, un fallback défini et une trace reliant la forme détectée au mode choisi.

Une stratégie robuste autorise aussi l’escalade. Le système commence en vectoriel ; si aucun passage ne porte une preuve suffisante et que la question suppose une relation, il tente le graphe. L’agent n’est activé que lorsque la question ou l’échec observé exige un choix dynamique. L’escalade doit être plafonnée pour éviter qu’une requête simple ne déclenche systématiquement le chemin le plus cher.

Évaluer le retrieval avant la qualité rédactionnelle

Une réponse fluide peut masquer un mauvais retrieval. L’évaluation doit donc séparer la récupération de preuves, la reconstruction du raisonnement et le comportement opérationnel.

RAG vectoriel

Pour un jeu de questions dont les passages pertinents sont annotés, mesurer :

• Recall@k : proportion des preuves attendues présentes parmi les k résultats ;
• hit rate@k : proportion des questions pour lesquelles au moins un passage pertinent est retrouvé ;
• rang moyen ou réciproque du premier passage pertinent ;
• taux de réponses dont chaque affirmation est reliée à un chunk source ;
• latence et coût par requête.

HyDE doit être comparé au même pipeline sans HyDE. Le gain attendu concerne le retrieval. Si le rappel augmente mais que les réponses citent le document hypothétique, l’intégration viole le contrat de preuve.

Graph RAG

Le hit rate sur des chunks isolés ne suffit plus. Il faut annoter les chemins attendus :

• taux de chemins multi-hop complets retrouvés ;
• proportion d’arêtes accompagnées d’une provenance valide ;
• précision des relations extraites ;
• couverture des entités et taux de doublons après résolution d’identité ;
• longueur du chemin utile par rapport au chemin exploré ;
• coût d’indexation par document et coût de mise à jour.

Pour le cas checkout, une réponse n’est correcte que si elle récupère les trois relations. Deux arêtes sur trois peuvent produire une formulation plausible, mais pas une preuve complète.

Agentic RAG

L’évaluation porte aussi sur la trajectoire :

• nombre moyen et percentile élevé des appels outil ;
• coût total et latence par tâche ;
• taux de sélection correcte du premier outil ;
• taux de tâches terminées dans le budget ;
• fréquence des appels redondants ;
• taux d’arrêts justifiés ;
• proportion d’actions sensibles correctement soumises à validation ;
• exactitude finale, avec provenance de chaque fait.

Il est utile de conserver un « chemin de référence » sans exiger que l’agent le reproduise exactement. Plusieurs trajectoires peuvent être valides ; elles doivent toutefois respecter les permissions, le budget et les exigences de preuve.

Limites et contre-exemples qui empêchent les raccourcis

Une question multi-hop ne requiert pas toujours un graphe. Si les documents contiennent déjà des synthèses fiables — par exemple une fiche indiquant directement que checkout-service dépend de cluster-3 — un RAG hybride peut suffire. Le graphe dupliquerait alors une relation explicitement matérialisée.

À l’inverse, un graphe n’est pas nécessairement meilleur pour les formulations exactes. Rechercher un numéro d’incident, une clause contractuelle ou une commande précise peut être plus efficace avec une recherche lexicale filtrée. Les embeddings et le graphe ajoutent peu lorsque l’identifiant est la meilleure clé.

Un Graph RAG vieillit mal si ses relations changent plus vite que son index. Une dépendance de service obsolète peut conduire à une réponse structurée, explicable et fausse. Les relations opérationnelles doivent être datées, invalidées ou récupérées directement depuis leur système de référence.

Global Search n’est pas un substitut universel à Local Search. Les rapports de communautés condensent le corpus ; cette compression peut éliminer un détail rare mais décisif. Une question globale mérite une vue globale, tandis qu’un incident précis exige généralement les entités, relations et chunks sources les plus proches.

L’Agentic RAG n’est pas requis pour toute utilisation d’outils. Lorsque la séquence est connue, un workflow explicite offre moins de variance, une meilleure couverture de tests et des coûts plus prévisibles. L’autonomie n’a de valeur que si une décision doit réellement être prise pendant l’exécution.

Enfin, aucune variante de RAG ne répare un corpus sans autorité. Si deux sources se contredisent, l’architecture doit connaître leur priorité, leur fraîcheur et leur domaine de validité. Le retrieval peut retrouver les deux versions ; il ne peut pas inventer une politique de résolution légitime.

Le choix peut ainsi rester sobre : utiliser le vectoriel lorsque la preuve tient dans un passage, le graphe lorsqu’elle forme un chemin, et l’agent lorsqu’il faut décider comment chercher. Puis mesurer l’échec réel avant d’élargir l’architecture.

Sources et prolongements

• Avi Chawla — distinction entre RAG standard, Graph RAG et Agentic RAG — Source primaire de la taxonomie fondée sur la forme de la question et du retrieval.
• Precise Zero-Shot Dense Retrieval without Relevance Labels — Papier fondateur de HyDE ; le document hypothétique peut contenir des détails faux et sert à retrouver des documents réels.
• Microsoft GraphRAG — Query Engine Overview — Présentation officielle de Local Search, Global Search, DRIFT Search et Basic Search.
• Microsoft GraphRAG — dépôt GitHub — Implémentation de référence, avertissement sur le coût potentiel de l’indexation et recommandation de commencer petit.
• Outcome School — How does HyDE work in RAG? — Explication pédagogique du passage d’une question à un document hypothétique utilisé comme requête de retrieval.