RAG ou graphe de connaissances ? 2 160 réponses notées et l’effet du modèle

Pourquoi mesurer du tout ?

Les débats concernant un assistant technique en entreprise ont tendance à stagner au même point. D’un côté, on défend RAG, de l’autre un graphe de connaissances ; les deux parties avancent de bons arguments, mais aucune ne présente de chiffres concrets. Une expérience contrôlée peut en fournir : deux approches, trois familles de modèles, trois répétitions et 120 questions avec des réponses de référence, ce qui donne 2 160 réponses évaluées. Chaque réponse a été notée selon une métrique déterministe ainsi que par un panel de trois juges.

La conclusion est moins satisfaisante que ce à quoi on pourrait s’attendre. Il n’y a pas de gagnant absolu, le sens de l’effet change en fonction du modèle, et la variable ayant l’effet le plus important n’est ni l’une ni l’autre des stratégies envisagées. C’est plutôt le modèle qui se trouve derrière le système qui compte.

Pour une lecture rapide :

• Le graphe a surpassé RAG avec une signification statistique uniquement sur un des trois modèles.
• Le jury a préféré RAG pour les trois cas.
• Changer de modèle améliorait la qualité davantage que de changer de stratégie.
• Le jeu de données est synthétique et la clé de réponse a été rédigée par l’expérimentateur, ce qui limite ce qui peut être transféré.

Ces limites viennent en premier, car elles déterminent si le reste vaut la peine d’être lu.

Ce que l’étude couvre et ne couvre pas

Elle mesure quelle stratégie de récupération produit des réponses plus correctes, plus complètes et plus traçables concernant un écosystème de microservices, en maintenant le modèle de génération constant dans chaque comparaison.

Elle ne mesure pas l’utilité pratique avec des développeurs réels, le coût de maintenance au fil du temps, la qualité perçue par des personnes connaissant le domaine, ni le comportement sur des documents réels présentant des incohérences et des lacunes.

Ce système ne mesure pas non plus la limite du paradigme graphique. Le graphique présenté ici est délibérément simple, avec des voisins à un seul saut et une correspondance floue entre entités. Un graphique capable de gérer des requêtes à plusieurs sauts et une agrégation globale pourrait répondre à des questions que celui-ci ne peut pas résoudre ; par conséquent, une partie des inconvénients du graphique présenté dans les tableaux provient de l’implémentation et non du paradigme lui-même.

Le problème

Une entreprise est passée aux microservices. Alors qu’auparavant un seul ensemble de codes suffisait, on compte désormais des dizaines de services, de contrats, d’événements et de bases de données. Les connaissances nécessaires sont dispersées dans des fichiers README, un catalogue interne, un tableau de suivi des opérations, ainsi que dans la mémoire de trois personnes seules à les maîtriser. Les questions quotidiennes sont banales mais coûteuses : quelle application stocke les données personnelles, de quoi dépend le service X, cela existe-t-il déjà et peut-il être réutilisé ? Aujourd’hui, la solution consiste à interroger quelqu’un ou à lire une documentation qui risque d’être obsolète, et le véritable coût n’est pas le temps de recherche, mais une décision technique prise sur la base d’informations anciennes.

Un assistant conversationnel permettrait de résoudre ces problèmes d’accès, à condition qu’il soit spécialisé dans ce domaine, et la littérature spécialisée propose deux approches possibles.

Récupération non structurée (RAG) : elle découpe la documentation, l’indexe dans un stock vectoriel, récupère les passages les plus similaires à la question et les intégre dans le prompt. Ce terme vient de Lewis et ses collaborateurs en 2020, et Gao et ses collègues présentent un aperçu des développements récents. Son entretien est peu coûteux et elle intègre les changements sans nécessiter un reconditionnement, mais elle est moins efficace lorsque la réponse exige une réflexion sur des relations explicites.

Récupération structurée (un graphe de connaissances) : elle modélise l’écosystème sous forme de nœuds et d’arêtes typés — service, équipe, événement, base de données, dépendance. Les requêtes sont déterministes et traçables, bien que le modélisation et la gestion du graphe soient coûteux. L’aperçu des graphes de connaissances réalisé par Hogan et ses collaborateurs constitue la référence standard.

Ces deux approches convergent dans GraphRAG, et c’est vers cela que pointent les résultats de cette expérience.

Conception

La décision la plus importante a été prise avant même d’écrire du code : seule la couche de connaissances peut varier. Sans cette règle, on compare deux implémentations et non deux stratégies. Toute différence dans le format de l’instruction ou du résultat contamine le résultat de manières impossibles à séparer par la suite, c’est pourquoi de nombreux benchmarks informels de RAG finissent par mesurer les compétences de celui qui a rédigé l’instruction.

Les deux approches renvoient exactement le même contrat de réponse : question, méthode, réponse, sources, contexte récupéré, latence et coût estimé. Cela permet au code d’évaluation, à l’API et à l’interface de rester indépendants de l’approche choisie.

Le test nécessitait un écosystème réaliste, publiable et reproductible, et utiliser celui d’un employeur était hors de question. Ainsi, l’installation invente CreditXPTO, une fintech de crédit personnel qui n’existe pas :

Le fait d’être synthétique apporte trois avantages : le contenu est contrôlé, la réponse correcte à chaque question est connue, et n’importe qui peut reprendre le travail sans accès aux systèmes internes. Le prix à payer est la validité externe, qui constitue la principale limitation et sera abordée à la fin.

Les mêmes connaissances existent dans les deux représentations, et l’équivalence est garantie par des règles de validation appliquées lors de l’intégration continue : une référence incorrecte rend l’ensemble de données invalide. Sinon, une des parties pourrait discrètement en savoir plus que l’autre. Les 120 questions sont classées par catégorie (factuelle, explicative, d’impact, relationnelle, de découverte, ambiguë), par difficulté et par type de connaissance, et chacune dispose d’une réponse attendue ainsi que de sources.

Le côté RAG utilise des fragments de 512 tokens avec une superposition de 50 tokens et un top-k de 5. Les embeddings proviennent de BAAI/bge-small-en-v1.5 exécuté localement, avec Qdrant en tant que stockage vectoriel. La récupération dense suit le schéma popularisé par Karpukhin et ses collaborateurs (DPR), les embeddings de phrase dérivent de Sentence-BERT, et la famille BGE est décrite dans C-Pack.

Le côté graphique utilise NetworkX en mémoire, construit directement à partir des fichiers sources afin de correspondre toujours aux données. La correspondance des entités est floue, avec un seuil de 70/100, et la récupération se fait dans un voisinage à un pas.

Évaluation

L’évaluation s’effectue à deux niveaux. Le premier niveau est heuristique : similitude lexicale, présence d’entités clés et couverture de la source. Il est peu coûteux, déterministe et reproductible, mais également superficiel, car il pénalise les paraphrases. C’est la faiblesse connue des métriques d’overlap de n-grammes et la raison pour laquelle des alternatives sémantiques comme BERTScore existent.

Le deuxième niveau consiste en un panel de trois juges basés sur des LLM, un provenant de chaque famille de modèles, qui évaluent la justesse, la complétude, le fondement et la clarté sur une échelle de 0 à 3. Le paradigme des LLM en tant que juges a été consolidé par Zheng et ses collaborateurs avec MT-Bench.

Un détail est crucial : la métrique principale est comparative entre familles de modèles. Pour chaque réponse, le juge appartenant à la famille du modèle lui-même est exclu du calcul. Les modèles reconnaissent leur propre texte et le notent plus haut, et Panickssery et ses collaborateurs (2024) associent cette préférence envers soi à ce recul identitaire. La seule façon de la neutraliser est de le faire de manière structurelle, jamais en demandant de l’impartialité dans l’instruction.

La signification des résultats provient d’un test McNemar apparié, puisque les deux stratégies répondent aux mêmes questions. Les intervalles de confiance sont calculés à l’aide de la méthode bootstrap avec 5 000 rééchantillonnages, et l’accord entre les juges est mesuré à l’aide du kappa de Cohen.

Résultats

Le premier tableau indique la précision stricte, où seules les réponses entièrement correctes sont prises en compte, avec n = 360 par case :

Deux interprétations sont importantes.

Tout d’abord, le résultat varie en fonction du modèle utilisé. RAG l’emporte avec deux générateurs, tandis que le graphe l’emporte avec le troisième, et seule cette dernière différence est significative. Effectuer l’expérience avec un seul modèle, comme le font la plupart des benchmarks, aurait conduit à une conclusion erronée mais affirmée, accompagnée d’une intervalle de confiance. Rien dans les résultats n’aurait laissé supposer cela.

Deuxièmement, l’écart entre les modèles dépasse l’écart entre les approches. Passer de claude-sonnet-4-6 à gpt-5.5 est plus efficace que de changer de stratégie au sein d’un même modèle. Cela réduit la question « RAG ou graphe ? » au rang d’une décision de second ordre, ce qui constitue la conclusion principale de cette étude.

En répétant le test avec une définition large, en attribuant des points complets ainsi que des points partiels et en ne pénalisant que les erreurs flagrantes, on obtient un résultat inverse. RAG devance désormais de loin les deux premiers modèles, et l’avantage du graphe sur le troisième cesse d’être significatif. Il convient de comprendre que la force de RAG ne réside pas dans le fait d’avoir raison plus souvent, mais dans le fait de se tromper moins gravement. Lorsque la récupération d’informations est partielle, il donne des réponses incomplètes. Lorsque la correspondance avec les entités échoue, le graphe fournit des réponses fausses mais avec assurance. Pour un assistant interne, cette distinction est cruciale : un développeur peut compléter une réponse incomplète, mais une réponse fausse accompagnée d’une source citée peut être transmise lors d’une réunion.

Les résultats du jury suivent :

Le jury préfère RAG pour les trois modèles, y compris celui pour lequel l’heuristique a attribué un avantage significatif au graphe. Il s’agit d’un effet d’instrument et non d’une contradiction. Dans un cas concret, une question a obtenu une similarité lexicale de 0,25 et a été classée comme incorrecte par l’heuristique, pourtant le jury lui a attribué 2,88 sur 3. La réponse était correcte, simplement formulée différemment. Les métriques de n-grammes mesurent le vocabulaire, tandis que les juges basés sur les LLM évaluent la correction perçue, avec des biais. Aucun de ces éléments seul ne répond à la question, et lorsqu’ils sont en désaccord, ce désaccord indique où chercher.

Le jury mérite une mise en garde honnête : l’accord entre les juges n’a été que modéré, avec un kappa de Cohen compris entre 0,09 et 0,56. Un jury de juges basés sur des LLM n’est pas un outil de précision. Il s’agit d’une deuxième opinion structurée, et des cadres comme RAGAS existent précisément parce que l’évaluation de la génération augmentée par la récupération d’informations reste un problème non résolu.

En ce qui concerne la latence, RAG était de 12 à 20 % plus rapide sur les trois modèles. Le contexte du graphe est plus compact, mais la requête nécessite une étape supplémentaire. Le coût varie selon le modèle : le graphe est moins cher avec deux générateurs et plus cher avec un autre. La combinaison de tokens d’entrée et de sortie diffère suffisamment d’un fournisseur à l’autre pour inverser le signe du coût. Il s’agit d’une observation et non d’une conclusion, puisque la composition des tokens n’a pas été testée formellement.

Comment chaque approche échoue

C’est la partie la plus utile, et elle n’apparaît dans aucune table.

Le graphe échoue sur le plan structurel. Lorsqu’on demande quelle base de données utilise un service, il renvoie l’identifiant du nœud et non le moteur, car cet attribut n’a pas été modélisé. Lorsqu’on demande combien d’équipes utilisent une technologie donnée, le voisinage à un pas récupère deux services et répond avec assurance qu’il s’agit de deux. Et si la correspondance floue sélectionne la mauvaise entité, tout le contexte est erroné sans qu’aucun signal ne l’indique.

RAG échoue en raison de son incomplétude. Il identifie correctement que un service utilise Redis, mais il limite la réponse au service récupéré alors que la question demandait une vue d’ensemble.

Les deux méthodes sont erronées, mais de manières différentes. Les défauts sont complémentaires, ce qui explique précisément pourquoi la direction évidente est hybride, avec un routage selon le type de question.

Recommandations

• Choisissez d’abord le modèle. C’est la variable ayant l’effet le plus important. La traiter comme un détail d’implémentation tout en passant des semaines à ajuster la taille des fragments optimise un paramètre de deuxième ordre.
• Commencez par RAG. Il présente des limites inférieures plus favorables et un coût de maintenance moindre, de plus son mode de défaillance est acceptable.
• Ajoutez la structure de manière ciblée, pour les dépendances, la propriété et la consommation d’événements. Ne tentez pas de modéliser l’ensemble de l’écosystème avant de livrer quoi que ce soit.
• Ne vous fiez pas à une seule métrique. Utilisez une heuristique déterministe ainsi qu’un ensemble de méthodes provenant de familles différentes. Lorsqu’elles divergent, c’est qu’un cas intéressant est apparu et non un bug.
• Utilisez un test en paires. Les deux stratégies répondent aux mêmes questions, et comparer les moyennes sans McNemar crée une confiance que les données ne justifient pas.

Limites

• Le jeu de données est synthétique et la clé de réponse est celle de l’expérimentateur lui-même. Aucun utilisateur réel ne l’a validée. Cela permet un contrôle et une reproductibilité accrus, mais au détriment de la validité externe.
• L’implémentation du graphique est délibérément simple, de sorte que certaines de ses faiblesses en matière d’agrégation pourraient provenir de l’implémentation plutôt que du paradigme lui-même.
• L’utilité pratique et la maintenabilité n’ont pas été mesurées. Elles faisaient partie des objectifs et sont restées de nature qualitative.
• L’heuristique n’a pas été validée par rapport au jugement humain. Le panel atténue ce problème sans pour autant le résoudre.
• Onze des 2 160 réponses (0,51 %) étaient dues à des erreurs du réseau du fournisseur et non à des erreurs système.

Conclusion

On espérait aboutir à des réponses du type « utiliser un graphique » ou « utiliser RAG ». En réalité, aucune de ces solutions n’existe tant que la question du modèle à utiliser n’a pas été tranchée, et c’est la variable considérée comme secondaire qui a eu le plus d’influence. Cela est moins satisfaisant mais plus utile. De plus, cela s’applique à d’autres cas : un benchmark avec une variable cachée ne commet pas d’erreur flagrante, mais plutôt une erreur accompagnée d’une intervalle de confiance. Avant de choisir une architecture en fonction d’un nombre, demandez ce qui a été maintenu constant dans l’expérience, et si cela devait vraiment l’être.

Lectures complémentaires

• RAG avancé en production : architecture, outils et compromis — Une présentation du RAG en environnement de production : ingestion, analyse, segmentation en blocs, génération d’embeddings, stockage vectoriel, recherche hybride, réclassement, évaluation et sécurité, ainsi que les compromis associés à chacun de ces éléments.
• GraphRAG vs Vector RAG : pourquoi la recherche vectorielle échoue à grande échelle et comment GraphRAG y remédie — Le Vector RAG rencontre des difficultés avec l’isolation des blocs, le raisonnement entre documents et la gestion à grande échelle. Découvrez comment GraphRAG crée des communautés et des résumés pour résoudre ces problèmes, ainsi que les cas où il convient d’en choisir un ou l’autre.

ROE contre TechRAG : GraphRAG sur Docker et Qdrant ou sur SQLite et LanceDB — Deux approches d’une même thèse GraphRAG : Qdrant, MongoDB et un modèle de 120 milliards de paramètres contre LanceDB, SQLite et qwen2.5 de 7 milliards de paramètres, avec une comparaison de la logique de récupération et des leçons tirées.