Graphique RAG vs SQL RAG

J’ai utilisé à la fois une base de données graphique et une base de données SQL, puis j’ai utilisé divers grands modèles de langage (LLM) pour répondre aux questions sur les données via une approche de génération augmentée par récupération (RAG). En utilisant le même ensemble de données et les mêmes questions dans les deux systèmes, j’ai évalué quel paradigme de base de données fournit des résultats les plus précis et les plus perspicaces.

Génération augmentée par récupération (RAG) est un framework d’IA qui améliore les grands modèles de langage (LLM) en leur permettant récupérer informations externes pertinentes avant de générer une réponse. Au lieu de s’appuyer uniquement sur ce sur quoi le modèle a été formé, RAG interroge dynamiquement une source de connaissances (dans cet article, une base de données SQL ou graphique) et intègre ces résultats dans sa réponse. Une introduction à RAG peut être trouvée ici.

Les bases de données SQL organisent les données en tableaux composé de lignes et de colonnes. Chaque ligne représente un enregistrement et chaque colonne représente un attribut. Les relations entre les tables sont définies à l’aide de clés et rejointet toutes les données suivent un schéma. Les bases de données SQL sont idéales pour les données transactionnelles structurées où la cohérence et la précision sont importantes (par exemple, les finances, l’inventaire ou les dossiers des patients).

Les bases de données graphiques stockent les données sous forme nœuds (entités) et bords (relations) avec optionnel propriétés attaché aux deux. Au lieu de joindre des tables, ils représentent directement des relations, permettant un parcours rapide entre les données connectées. Les bases de données graphiques sont idéales pour la modélisation réseaux et relations – comme les graphes sociaux, les graphes de connaissances ou les cartes d’interactions moléculaires – où les connexions sont aussi importantes que les entités elles-mêmes.

Données

L’ensemble de données que j’ai utilisé pour comparer les performances des RAG contient les résultats de Formule 1 de 1950 à 2024. Il comprend des résultats détaillés des courses des pilotes et des constructeurs (équipes) couvrant les qualifications, la course de sprint, la course principale et même les temps au tour et les temps d’arrêt aux stands. Les classements des championnats pilotes et constructeurs après chaque course sont également inclus.

Schéma SQL

Cet ensemble de données est déjà structuré en tables avec des clés afin qu’une base de données SQL puisse être facilement mise en place. Le schéma de la base de données est présenté ci-dessous :

Courses est le tableau central qui est lié à tous les types de résultats ainsi qu’à des informations supplémentaires comme la saison et les circuits. Les tableaux de résultats sont également liés à Pilotes et Constructeurs des tables pour enregistrer leur résultat à chaque course. Le classement du championnat après chaque course est stocké dans le Pilote_classement et Constructeur_classement tableaux.

Schéma graphique

Le schéma de la base de données graphique est présenté ci-dessous :

Comme les bases de données graphiques peuvent stocker des informations dans des nœuds et des relations, elles ne nécessitent que six nœuds, contre 14 tables pour la base de données SQL. Le Voiture Le nœud est un nœud intermédiaire utilisé pour modéliser le fait qu’un pilote a conduit une voiture d’un constructeur lors d’une course particulière. Les couples pilotes – constructeurs évoluant au fil du temps, cette relation doit être définie pour chaque course. Les résultats de la course sont stockés dans les relations, par exemple :COURSE entre Voiture et Course. Alors que le :STOOD_APRÈS les relations contiennent le classement des championnats des pilotes et des constructeurs après chaque course.

Interrogation de la base de données

j’ai utilisé LangChaîne pour créer une chaîne RAG pour les deux types de bases de données qui génère une requête basée sur une question de l’utilisateur, exécute la requête et convertit le résultat de la requête en réponse à l’utilisateur. Le code peut être trouvé ici dépôt. J’ai défini une invite système générique qui pourrait être utilisée pour générer des requêtes sur n’importe quelle base de données SQL ou graphique. Les seules informations spécifiques aux données ont été incluses en insérant le schéma de base de données généré automatiquement dans l’invite. Les invites du système peuvent être trouvées ici.

Voici un exemple de comment initialiser la chaîne de modèles et poser la question : « Quel pilote a remporté le 92 Grand Prix de Belgique ?

from langchain_community.utilities import SQLDatabase
from langchain_openai import ChatOpenAI
from qa_chain import GraphQAChain
from config import DATABASE_PATH

# connect to database
connection_string = f"sqlite:///{DATABASE_PATH}"
db = SQLDatabase.from_uri(connection_string)

# initialize LLM
llm = ChatOpenAI(temperature=0, model="gpt-5")

# initialize qa chain
chain = GraphQAChain(llm, db, db_type='SQL', verbose=True)

# ask a question
chain.invoke("What driver won the 92 Grand Prix in Belgium?")

Ce qui renvoie :

{'write_query': {'query': "SELECT d.forename, d.surname
FROM results r
JOIN races ra ON ra.raceId = r.raceId
JOIN drivers d ON d.driverId = r.driverId
WHERE ra.year = 1992
AND ra.name = 'Belgian Grand Prix'
AND r.positionOrder = 1
LIMIT 10;"}} 
{'execute_query': {'result': "[('Michael', 'Schumacher')]"}}
 {'generate_answer': {'answer': 'Michael Schumacher'}}

La requête SQL rejoint le Résultats, Courseset Pilotes tableaux, sélectionne la course du Grand Prix de Belgique 1992 et le pilote qui a terminé premier. Le LLM a converti l’année 92 en 1992 et le nom de la course de « Grand Prix de Belgique » en « Grand Prix de Belgique ». Il a dérivé ces conversions à partir du schéma de base de données qui comprenait trois exemples de lignes de chaque table. Le résultat de la requête est « Michael Schumacher » que le LLM a renvoyé comme réponse.

Évaluation

Maintenant, la question à laquelle je veux répondre est de savoir si un LLM est meilleur pour interroger la base de données SQL ou graphique. J’ai défini trois niveaux de difficulté (facile, moyen et difficile) : faciles étaient des questions auxquelles on pouvait répondre en interrogeant les données d’une seule table ou d’un nœud, moyens étaient des questions qui nécessitaient un ou deux liens entre des tables ou des nœuds et les questions difficiles nécessitaient plus de liens ou de sous-requêtes. Pour chaque niveau de difficulté, j’ai défini cinq questions. De plus, j’ai défini cinq questions auxquelles il n’a pas été possible de répondre avec les données de la base de données.

J’ai répondu à chaque question avec trois modèles LLM (GPT-5, GPT-4 et GPT-3.5-turbo) pour analyser si les modèles les plus avancés sont nécessaires ou si des modèles plus anciens et moins chers pourraient également produire des résultats satisfaisants. Si un modèle donnait la bonne réponse, il obtenait 1 point, s’il répondait qu’il ne pouvait pas répondre à la question, il obtenait 0 point, et s’il donnait une mauvaise réponse, il obtenait -1 point. Toutes les questions et réponses sont répertoriées ici. Vous trouverez ci-dessous les scores de tous les modèles et types de bases de données :

Il est remarquable de voir à quel point les modèles plus avancés surpassent les modèles plus simples : GPT-3-turbo a eu environ la moitié du nombre de questions erronées, GPT-4 a eu 2 à 3 questions erronées mais n’a pas pu répondre à 6 à 7 questions, et GPT-5 a répondu à toutes les questions sauf une. Les modèles plus simples semblent fonctionner mieux avec une base de données SQL qu’avec une base de données graphique, tandis que GPT-5 a obtenu le même score avec l’une ou l’autre base de données.

La seule question que GPT-5 s’est trompée en utilisant la base de données SQL était « Quel pilote a remporté le plus de championnats du monde ? » La réponse « Lewis Hamilton, avec 7 championnats du monde » n’est pas correcte car Lewis Hamilton et Michael Schumacher ont remporté 7 championnats du monde. La requête SQL générée regroupait le nombre de championnats par pilote, les triait par ordre décroissant et sélectionnait uniquement la première ligne tandis que le pilote de la deuxième ligne avait le même nombre de championnats.

En utilisant la base de données graphique, la seule question que GPT-5 s’est trompée était « Qui a remporté le championnat de Formule 2 en 2017 ? » à quoi on a répondu « Lewis Hamilton » (Lewis Hamilton a remporté le championnat de Formule 1 mais pas de Formule 2 cette année-là). C’est une question délicate car la base de données ne contient que les résultats de Formule 1 mais pas de Formule 2. La réponse attendue aurait été de répondre que cette question ne pouvait pas trouver de réponse sur la base des données fournies. Cependant, étant donné que l’invite du système ne contenait aucune information spécifique sur l’ensemble de données, il est compréhensible que cette question n’ait pas reçu de réponse correcte.

Fait intéressant, en utilisant la base de données SQL, GPT-5 a donné la bonne réponse « Charles Leclerc ». La requête SQL générée recherchait uniquement dans la table des pilotes le nom « Charles Leclerc ». Ici, le LLM a dû reconnaître que la base de données ne contient pas de résultats de Formule 2 et a répondu à cette question à partir de ses connaissances communes. Bien que cela ait conduit à la bonne réponse dans ce cas, cela peut être dangereux lorsque le LLM n’utilise pas les données fournies pour répondre aux questions. Une façon de réduire ce risque pourrait être d’indiquer explicitement dans l’invite du système que la base de données doit être la seule source pour répondre aux questions.

Conclusion

Cette comparaison des performances du RAG à l’aide d’un ensemble de données de résultats de Formule 1 montre que les derniers LLM fonctionnent exceptionnellement bien, produisant des réponses très précises et contextuelles sans aucune ingénierie d’invite supplémentaire. Alors que les modèles plus simples ont du mal, les plus récents comme GPT-5 gèrent les requêtes complexes avec une précision presque parfaite. Il est important de noter qu’il n’y a pas de différence significative en termes de performances entre les approches graphiques et les bases de données SQL : les utilisateurs peuvent simplement choisir le paradigme de base de données qui correspond le mieux à la structure de leurs données.

L’ensemble de données utilisé ici sert uniquement d’exemple illustratif ; les résultats peuvent différer lors de l’utilisation d’autres ensembles de données, en particulier ceux qui nécessitent une connaissance spécialisée du domaine ou un accès à des sources de données non publiques. Dans l’ensemble, ces résultats mettent en évidence à quel point les LLM augmentés par la récupération ont progressé dans l’intégration de données structurées au raisonnement en langage naturel.

Sauf indication contraire, toutes les images ont été créées par l’auteur.