Knowledge Graphs vs bases de données : pourquoi l'un fait tripler la précision des LLMs
Télécharger en .md- SQL brut : le LLM voit une structure de données mais ne comprend pas ce qu'elle signifie. Il hallucine.
- Knowledge Graph : le LLM dispose d'une ontologie qui explique les concepts, leurs relations et leur sens métier. Il raisonne.
- Résultat mesuré : 16,7% de précision sans contexte, 54,2% avec. Un facteur 3 sur les mêmes questions, avec le même modèle.
- Pour le GEO : vos données Schema.org, votre structure de contenu et votre maillage interne jouent exactement ce rôle de graphe de connaissances pour les crawlers IA.
Le problème : un expert sans contexte
1 minclaim_amount_identifier, policy_coverage_detail) sans dictionnaire. Il va deviner, et se tromper. C'est exactement ce qui arrive aux LLM face à votre HTML mal structuré.
Imaginez un expert comptable parfaitement compétent à qui vous demandez d'analyser les comptes d'une assurance. Vous lui donnez les fichiers bruts : des colonnes de chiffres avec des noms techniques comme claim_amount_identifier, company_claim_number, policy_coverage_detail_identifier. Pas de légende, pas d'explication, pas de dictionnaire métier.
Il va faire de son mieux. Il va deviner que claim_amount_identifier est probablement un montant de sinistre. Mais il ne sait pas que company_claim_number est le vrai numéro de sinistre, et que claim_identifier est juste un identifiant technique interne. Il va se tromper.
C'est exactement ce qui se passe quand GPT-4 reçoit un schéma SQL brut sans contexte métier. Le modèle est brillant, mais il navigue à l'aveugle dans une terminologie qu'il n'a jamais vue dans cet ordre précis.
- Le LLM voit des noms de colonnes techniques, opaque et sans sens apparent
- Il doit deviner les relations entre tables par analogie
- Il invente des colonnes qui semblent logiques mais n'existent pas
- Les jointures complexes (plus de 5 tables) : précision = 0%
- Les erreurs sont fondamentales : données inventées de zéro
- L'ontologie définit explicitement chaque concept et ses propriétés
- Les relations entre entités sont déclarées et typées
- Le LLM ne génère pas de classes ou propriétés inexistantes
- Précision maintenue même sur les schémas complexes (35 à 71%)
- Les erreurs résiduelles portent sur des chemins, pas sur des inventions
La mécanique en détail
1 minLe benchmark de data.world teste deux approches sur les mêmes 43 questions dans le domaine de l'assurance. Dans les deux cas, c'est GPT-4 qui répond, avec le même prompt zero-shot. La seule différence : ce qu'on lui donne comme contexte.
Approche 1 : SQL brut
Le modèle reçoit la définition du schéma (DDL) et la question en langage naturel. Il génère une requête SQL qu'on exécute sur la base. Si le résultat correspond à la réponse de référence : succès. Sinon : échec.
Le problème : le DDL décrit la structure, pas le sens. GPT-4 sait qu'il existe une table Claim avec une colonne Claim_Identifier. Mais il ne sait pas que le "numéro de sinistre" dont parle la question correspond à company_claim_number et pas à Claim_Identifier. Il choisit la mauvaise colonne. La réponse est incorrecte.
Approche 2 : Knowledge Graph
Le modèle reçoit une ontologie OWL qui décrit les concepts métier : un Sinistre a un numéro de sinistre, une date d'ouverture, une date de clôture. Il est lié à une Police via une Couverture. Il génère une requête SPARQL sur cette ontologie.
Cette fois, le modèle sait exactement quelle propriété correspond à quoi. Il ne peut pas inventer de propriété qui n'existe pas dans l'ontologie. Les erreurs qui subsistent sont des erreurs de chemin (aller de A à C en oubliant B), pas des inventions.
Les résultats interactifs
1 minMême modèle, même questions, même approche zero-shot. Seul le contexte change. Explorez les gains par type de question :
Simulateur : estimez votre gain de précision
1 minCombien de tables impliquent vos questions métier typiques ? Faites glisser le curseur pour estimer l'impact du contexte sémantique sur votre cas.
Le lien direct avec le GEO
2 minVous n'avez probablement pas de Knowledge Graph OWL. Vos données ne sont pas en SPARQL. Et pourtant, ce benchmark vous concerne directement.
Quand PerplexityBot ou OAI-SearchBot crawle votre site pour alimenter des réponses, il se retrouve dans la même situation que GPT-4 face à une base SQL brute : il lit du texte sans savoir ce que les concepts signifient dans votre domaine. Ce qu'il récupère, c'est votre HTML. Ce qu'il comprend dépend entièrement de la clarté sémantique de ce HTML.
policy_amount_identifier. Un H2 qui dit "Combien coûte un audit SEO en 2026" est une propriété nommée avec son contexte.La conclusion du benchmark est nette : investir dans le contexte sémantique n'est pas un projet R&D, c'est une priorité opérationnelle. En GEO, cela se traduit par des actions concrètes déjà accessibles : enrichissement Schema.org, structure éditoriale sémantique, maillage cohérent, pages de définition sectorielles. Ce sont les équivalents low-code d'un Knowledge Graph, accessibles à tout éditeur de contenu.
Questions fréquentes
2 minNon. Le benchmark utilise un Knowledge Graph formel (OWL/SPARQL), mais le principe qu'il démontre est plus large : le contexte sémantique améliore la précision des LLMs. Pour un éditeur web, Schema.org, une structure de contenu rigoureuse et un maillage cohérent produisent un effet similaire sans nécessiter une infrastructure de graphe de données. C'est plus accessible et déjà recommandé pour le SEO classique.
Les crawlers RAG comme OAI-SearchBot et PerplexityBot crawlent le HTML complet, y compris les balises Schema.org en JSON-LD. Les LLMs sont entraînés sur des corpus qui incluent des données structurées. L'effet n'est pas garanti ni quantifié de manière aussi précise que dans ce benchmark, mais le principe est solide : plus votre contenu est sémantiquement explicite, moins le modèle doit deviner.
Les auteurs eux-mêmes soulignent que le framework est conçu pour être reproduit dans n'importe quel secteur. Le domaine de l'assurance a été choisi parce qu'il dispose d'un modèle de données standardisé (OMG P&C Data Model) qui permettait de construire un benchmark reproductible. Le mécanisme sous-jacent, le contexte sémantique améliore la précision des LLMs, est indépendant du secteur.
Les benchmarks classiques (Spider, WikiSQL) testent des LLMs sur des bases de données simplifiées, avec des schémas lisibles et des données génériques. Ce benchmark utilise un vrai schéma de production (199 tables au total, 13 utilisées), des questions réellement posées par des équipes métier en assurance, et un corpus de données représentatif. C'est précisément ce réalisme qui en fait un signal pertinent.
Freelance SEO Senior, 20 ans d'expérience. J'aide les PME à renforcer leur visibilité sur Google tout en intégrant les nouveaux enjeux liés aux moteurs IA. Mon expertise couvre à la fois le SEO classique et les stratégies émergentes de présence dans les IA (GEO), que j'exploite de manière complémentaire selon les objectifs. Approche basée sur des données réelles : logs serveur, tests en compétition, audits de sites.