Benchmark LLM

GPT-4 répond juste 16% du temps sur vos données métier : voici pourquoi

31 mars 2026 10 min de lecture Frédéric Jézégou
Télécharger en .md
L'essentiel en 30 secondes
  • Un benchmark publié par data.world teste GPT-4 sur 43 questions réelles dans le secteur de l'assurance
  • Sans contexte métier : 16,7% de précision en moyenne, et 0% sur les questions complexes
  • Avec un graphe de connaissances (Knowledge Graph) : 54,2%, soit 3 fois plus
  • Les hallucinations SQL sont structurelles : colonnes inventées, valeurs inexistantes, jointures incorrectes
  • Le signal GEO est clair : le contexte sémantique n'est pas un luxe, c'est la condition de la précision

16% : le chiffre qui dérange

1 min

On entend partout que les LLMs vont révolutionner l'accès aux données en entreprise. Posez une question en langage naturel, obtenez une réponse. Simple, non ? Un benchmark rigoureux publié fin 2023 par data.world vient rappeler que la réalité est plus complexe.

Le protocole : 43 questions réelles dans le domaine de l'assurance, posées à GPT-4 en zero-shot (sans exemples préalables), directement sur une base de données de production avec 199 tables. Résultat : 16,7% de précision moyenne. Et pour les questions complexes nécessitant plus de 5 tables : 0% de réponses correctes.

16,7%
Précision GPT-4 sans contexte métier
54,2%
Précision avec Knowledge Graph
43
Questions réelles testées

Ces chiffres ne sont pas une attaque contre les LLMs. Ce sont des données de terrain qui permettent de calibrer les attentes, et de comprendre où investir pour améliorer la précision.

Pourquoi GPT-4 se plante sur des données réelles

1 min

Les benchmarks classiques comme Spider ou WikiSQL donnent l'impression que les LLMs savent interroger des bases de données. Mais ces benchmarks sont construits sur des bases simplifiées, avec des schémas lisibles et des données fictives. Une vraie base de production, c'est autre chose.

Dans le secteur de l'assurance, la table Claim a 14 colonnes. La colonne qui contient le numéro de sinistre ne s'appelle pas claim_number mais company_claim_number. GPT-4 ne le sait pas. Il invente Claim_Identifier à la place, qui existe bien, mais qui est un identifiant interne sans valeur métier. C'est une hallucination de colonne.

Trois types d'hallucinations SQL observées dans le benchmark : noms de colonnes inventés qui n'existent pas dans la table, valeurs filtrées qui n'existent pas dans la base, jointures incorrectes entre tables qui semblent plausibles mais sont fausses.

La cause profonde est simple : GPT-4 voit le schéma SQL brut (la structure des tables), mais pas ce que ces tables signifient dans le contexte de l'assurance. Sans cette couche de sens, il raisonne par analogie avec ce qu'il a vu pendant son entraînement, et se trompe.

La visualisation des résultats

1 min

Le benchmark classe les 43 questions selon deux axes : la complexité de la question (reporting simple vs indicateurs KPI) et la complexité du schéma (peu de tables vs nombreuses tables). Voici les résultats interactifs :

Précision GPT-4 : avec vs sans contexte métier
Source : data.world Knowledge Graph & LLM Accuracy Benchmark, novembre 2023
Sans contexte
GPT-4 + SQL brut
16,7%
16,7%
Avec Knowledge Graph
GPT-4 + contexte sémantique
54,2%
54,2%
Sans contexte métier (SQL brut)
Avec Knowledge Graph

Les trois types d'hallucinations SQL

1 min

L'analyse manuelle des requêtes générées révèle trois patterns d'erreur distincts, tous liés à l'absence de contexte sémantique :

Hallucinations SQL
Colonnes inventées : GPT-4 génère des noms de colonnes qui n'existent pas dans la table. Il devine d'après le contexte, et se trompe.
Valeurs inexistantes : Les filtres appliqués utilisent des valeurs que GPT-4 a supposées être dans la base, mais qui n'y sont pas.
Jointures incorrectes : Les liens entre tables semblent logiques en surface, mais ne correspondent pas à la structure réelle de la base.
Erreurs SPARQL (Knowledge Graph)
️Chemin incorrect : La requête va de A vers C directement, alors que le chemin correct est A vers B vers C. Le LLM connaît le point de départ et d'arrivée, mais rate l'intermédiaire.
️Direction inversée : La relation est parcourue dans le mauvais sens (B vers A au lieu de A vers B).
Aucune classe inventée : Fait remarquable : GPT-4 n'hallucine pas de classes ou de propriétés inexistantes dans l'ontologie.

La distinction est instructive. Avec SQL brut, le LLM invente des éléments qui n'existent pas. Avec le Knowledge Graph, il comprend la structure mais peut se tromper sur les chemins. Le premier type d'erreur est fondamental ; le second est corrigible.

Le seuil critique : 5 tables

1 min

Le résultat le plus frappant du benchmark est aussi le plus concret : dès qu'une question nécessite plus de 5 tables pour être répondue, GPT-4 sans contexte métier tombe à 0% de précision. Pas 5%, pas 10% : zéro.

C'est le seuil au-delà duquel les hallucinations de jointures s'accumulent jusqu'à rendre la requête générée entièrement fausse. Avec un Knowledge Graph, la précision reste entre 35% et 39% même sur ces questions très complexes.

Ce que ça dit sur les LLMs en production

Les démos impressionnantes de ChatGPT interrogeant des données fonctionnent sur des cas simples, avec des schémas lisibles et des volumes réduits. Dès qu'on passe à une vraie base de production métier, sans couche sémantique, la précision s'effondre. Ce n'est pas un défaut des LLMs : c'est la conséquence logique d'un modèle entraîné sur du langage, confronté à des conventions techniques opaques sans explication.

Le signal GEO : pourquoi ça vous concerne

1 min

Ce benchmark porte sur des bases de données, pas sur des contenus web. Mais le principe qu'il démontre s'applique directement au GEO : le contexte sémantique est la condition de la précision.

Quand PerplexityBot ou OAI-SearchBot crawle votre site, il se retrouve dans une situation similaire à GPT-4 face à une base SQL brute : il voit des mots, des phrases, des listes. Mais comprend-il que votre "sinistre" est une réclamation d'assurance, que votre "police" est un contrat, que votre "prime" est un montant annuel ? Sans données structurées Schema.org, sans hiérarchie sémantique claire, il doit deviner.

Les sites qui seront cités avec précision dans les réponses des IA ne seront pas nécessairement les plus connus ou les mieux positionnés sur Google. Ce seront ceux dont le contenu est le plus lisible sémantiquement par les agents IA.

L'analogie directe : vos données Schema.org, vos titres H2 descriptifs, votre maillage interne cohérent jouent exactement le rôle de l'ontologie dans ce benchmark. Ils donnent aux LLMs le contexte qui leur manque pour répondre correctement à vos sujets.

Questions fréquentes

2 min
Ce benchmark est de 2023 : est-il encore pertinent en 2026 ?

Les modèles ont progressé depuis, mais le problème de fond reste identique : un LLM sans contexte métier doit deviner la sémantique d'un schéma qu'il n'a jamais vu. GPT-4o ou Claude 3 Opus obtiendraient de meilleurs chiffres, mais la hiérarchie (avec contexte >> sans contexte) resterait la même. Le principe est structurel, pas lié à une version de modèle.

Qu'est-ce qu'un Knowledge Graph exactement ?

Un graphe de connaissances est une représentation des données où les concepts, leurs attributs et leurs relations sont définis de manière explicite et lisible par une machine. Dans ce benchmark, l'ontologie OWL décrit ce qu'est un "Sinistre", quelles sont ses propriétés (numéro, date d'ouverture, date de clôture) et comment il se rattache à une "Police". Le LLM n'a plus à deviner : tout est décrit.

54% c'est toujours faible, non ?

Oui, et les auteurs le reconnaissent. 54% n'est pas un résultat satisfaisant pour la production. Mais c'est 3 fois plus que sans contexte, et c'est un benchmark de novembre 2023 avec GPT-4 en zero-shot (sans exemples). Avec du prompting plus élaboré (few-shot, chain-of-thought) et des modèles plus récents, les chiffres seraient différents. L'objectif du benchmark est de mesurer la valeur du contexte, pas de valider un système prêt pour la production.

Comment appliquer ça à ma stratégie de contenu ?

Trois actions concrètes : 1) Enrichir vos contenus avec des données Schema.org adaptées à votre secteur (Article, Product, FAQPage, HowTo). 2) Structurer vos H2 et H3 pour qu'ils décrivent explicitement le concept traité, pas seulement pour séduire le lecteur humain. 3) Créer des pages de définition sur les termes clés de votre domaine, ces pages jouent le rôle de l'ontologie pour les crawlers IA.

Frédéric Jézégou
À propos de l'auteur
Frédéric Jézégou Consultant SEO & GEO
Fondateur de Rankit.fr · Dicocitations SASU · Pornichet (44)

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.