GPT-4 répond juste 16% du temps sur vos données métier : voici pourquoi
Télécharger en .md- 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 minOn 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.
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 minclaim_number mais company_claim_number. GPT-4 invente Claim_Identifier : c'est une hallucination de colonne.
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.
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 minLe 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 :
Les trois types d'hallucinations SQL
1 minL'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 :
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 minLe 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.
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 minCe 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.
Questions fréquentes
2 minLes 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.
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.
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.
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.