Diagramm RAG vs. SQL RAG

Ich habe sowohl in einer Graphdatenbank als auch in einer SQL-Datenbank gearbeitet und dann verschiedene große Sprachmodelle (LLMs) verwendet, um Fragen zu den Daten durch einen Retrieval-Augmented Era (RAG)-Ansatz zu beantworten. Durch die Verwendung des gleichen Datensatzes und der gleichen Fragen in beiden Systemen konnte ich bewerten, welches Datenbankparadigma genauere und aufschlussreichere Ergebnisse liefert.

Retrieval-Augmented Era (RAG) ist ein KI-Framework, das große Sprachmodelle (LLMs) verbessert, indem es sie zulässt abrufen Informieren Sie sich über relevante externe Informationen, bevor Sie eine Antwort generieren. Anstatt sich ausschließlich darauf zu verlassen, worauf das Modell trainiert wurde, fragt RAG dynamisch eine Wissensquelle (in diesem Artikel eine SQL- oder Diagrammdatenbank) ab und integriert diese Ergebnisse in seine Antwort. Eine Einführung in RAG finden Sie hier Hier.

SQL-Datenbanken organisieren Daten in Tische bestehend aus Zeilen und Spalten. Jede Zeile stellt einen Datensatz dar und jede Spalte stellt ein Attribut dar. Beziehungen zwischen Tabellen werden mit definiert Schlüssel Und schließt sich anund alle Daten folgen einem festen Schema. SQL-Datenbanken eignen sich preferrred für strukturierte Transaktionsdaten, bei denen Konsistenz und Präzision wichtig sind – beispielsweise Finanzen, Inventar oder Patientenakten.

Graphdatenbanken speichern Daten als Knoten (Entitäten) und Kanten (Beziehungen) mit non-compulsory Eigenschaften an beide angeschlossen. Anstatt Tabellen zu verknüpfen, stellen sie Beziehungen direkt dar und ermöglichen so eine schnelle Durchquerung verbundener Daten. Graphdatenbanken eignen sich hervorragend zur Modellierung Netzwerke und Beziehungen – wie soziale Graphen, Wissensgraphen oder molekulare Interaktionskarten – bei denen Verbindungen genauso wichtig sind wie die Entitäten selbst.

Daten

Der Datensatz, den ich zum Vergleich der Leistung von RAGs verwendet habe, enthält Formel-1-Ergebnisse von 1950 bis 2024. Er enthält detaillierte Ergebnisse bei Rennen von Fahrern und Konstrukteuren (Groups), darunter Qualifikation, Sprintrennen, Hauptrennen und sogar Rundenzeiten und Boxenstoppzeiten. Auch der Stand der Fahrer- und Konstrukteurswertung nach jedem Rennen ist enthalten.

SQL-Schema

Dieser Datensatz ist bereits in Tabellen mit Schlüsseln strukturiert, so dass eine SQL-Datenbank einfach aufgebaut werden kann. Das Schema der Datenbank ist unten dargestellt:

Rennen ist die zentrale Tabelle, die mit allen Arten von Ergebnissen sowie zusätzlichen Informationen wie Saison und Strecken verknüpft ist. Die Ergebnistabellen sind ebenfalls mit verlinkt Treiber Und Konstrukteure Tabellen, um ihre Ergebnisse bei jedem Rennen aufzuzeichnen. Der Meisterschaftsstand nach jedem Rennen wird im gespeichert Fahrerwertung Und Konstruktorstatus Tische.

Diagrammschema

Das Schema der Diagrammdatenbank ist unten dargestellt:

Da Diagrammdatenbanken Informationen in Knoten und Beziehungen speichern können, sind im Vergleich zu 14 Tabellen der SQL-Datenbank nur sechs Knoten erforderlich. Der Auto Knoten ist ein Zwischenknoten, der verwendet wird, um zu modellieren, dass ein Fahrer bei einem bestimmten Rennen ein Auto eines Herstellers gefahren ist. Da sich Fahrer-Konstrukteur-Paare im Laufe der Zeit ändern, muss diese Beziehung für jedes Rennen definiert werden. Die Rennergebnisse werden in den Beziehungen gespeichert, z :RENNEN zwischen Auto Und Wettrennen. Während die :STOOD_AFTER Beziehungen enthalten die Fahrer- und Konstrukteurswertungsstände nach jedem Rennen.

Abfragen der Datenbank

Ich habe verwendet LangChain um eine RAG-Kette für beide Datenbanktypen zu erstellen, die eine Abfrage basierend auf einer Benutzerfrage generiert, die Abfrage ausführt und das Abfrageergebnis in eine Antwort für den Benutzer umwandelt. Der Code ist hier zu finden Repo. Ich habe eine generische Systemeingabeaufforderung definiert, mit der Abfragen für jede SQL- oder Diagrammdatenbank generiert werden können. Die einzigen datenspezifischen Informationen wurden durch Einfügen des automatisch generierten Datenbankschemas in die Eingabeaufforderung eingefügt. Die Systemaufforderungen sind zu finden Hier.

Hier ist ein Beispiel, wie man die Modellkette initialisiert und die Frage stellt: „Welcher Fahrer hat den 92. Grand Prix in Belgien gewonnen?“

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

# hook up with database
connection_string = f"sqlite:///{DATABASE_PATH}"
db = SQLDatabase.from_uri(connection_string)

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

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

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

Was zurückgibt:

{'write_query': {'question': "SELECT d.forename, d.surname
FROM outcomes r
JOIN races ra ON ra.raceId = r.raceId
JOIN drivers d ON d.driverId = r.driverId
WHERE ra.12 months = 1992
AND ra.title = 'Belgian Grand Prix'
AND r.positionOrder = 1
LIMIT 10;"}} 
{'execute_query': {'outcome': "(('Michael', 'Schumacher'))"}}
 {'generate_answer': {'reply': 'Michael Schumacher'}}

Die SQL-Abfrage fügt sich dem hinzu Ergebnisse, RennenUnd Treiber Tabellen, wählt das Rennen beim Großen Preis von Belgien 1992 und den Fahrer aus, der als Erster ins Ziel kam. Das LLM wandelte das Jahr 92 in 1992 und den Rennnamen von „Grand Prix in Belgien“ in „Belgischer Grand Prix“ um. Diese Konvertierungen wurden aus dem Datenbankschema abgeleitet, das drei Beispielzeilen jeder Tabelle enthielt. Das Abfrageergebnis ist „Michael Schumacher“, das das LLM als Antwort zurückgegeben hat.

Auswertung

Die Frage, die ich nun beantworten möchte, ist, ob ein LLM besser für die Abfrage der SQL- oder der Graphdatenbank geeignet ist. Ich habe drei Schwierigkeitsstufen definiert (einfach, mittel und schwer), wobei „einfach“ Fragen waren, die durch die Abfrage von Daten aus nur einer Tabelle oder einem Knoten beantwortet werden konnten, „mittel“ Fragen, die eine oder zwei Verknüpfungen zwischen Tabellen oder Knoten erforderten, und „schwere“ Fragen, die mehr Verknüpfungen oder Unterabfragen erforderten. Für jeden Schwierigkeitsgrad habe ich fünf Fragen definiert. Zusätzlich habe ich fünf Fragen definiert, die mit Daten aus der Datenbank nicht beantwortet werden konnten.

Ich habe jede Frage mit drei LLM-Modellen (GPT-5, GPT-4 und GPT-3.5-turbo) beantwortet, um zu analysieren, ob die fortschrittlichsten Modelle benötigt werden oder ob auch ältere und günstigere Modelle zu zufriedenstellenden Ergebnissen führen könnten. Wenn ein Modell die richtige Antwort gab, bekam es 1 Punkt, wenn es antwortete, dass es die Frage nicht beantworten konnte, bekam es 0 Punkte, und wenn es eine falsche Antwort gab, bekam es -1 Punkt. Alle Fragen und Antworten werden aufgelistet Hier. Nachfolgend finden Sie die Ergebnisse aller Modelle und Datenbanktypen:

Es ist bemerkenswert, wie fortgeschrittenere Modelle einfachere Modelle übertreffen: GPT-3-turbo hat etwa die Hälfte der Fragen falsch beantwortet, GPT-4 hat 2 bis 3 Fragen falsch beantwortet, konnte aber 6 bis 7 Fragen nicht beantworten, und GPT-5 hat bis auf eine Frage alle Fragen richtig beantwortet. Einfachere Modelle scheinen mit einer SQL-Datenbank eine bessere Leistung zu erbringen als mit einer Graphdatenbank, während GPT-5 mit beiden Datenbanken die gleiche Punktzahl erzielte.

Die einzige Frage, die GPT-5 bei der Verwendung der SQL-Datenbank falsch gestellt hat, battle „Welcher Fahrer hat die meisten Weltmeisterschaften gewonnen?“. Die Antwort „Lewis Hamilton, mit 7 Weltmeisterschaften“ ist nicht korrekt, da Lewis Hamilton und Michael Schumacher 7 Weltmeisterschaften gewonnen haben. Die generierte SQL-Abfrage aggregierte die Anzahl der Meisterschaften nach Fahrer, sortierte sie in absteigender Reihenfolge und wählte nur die erste Zeile aus, während der Fahrer in der zweiten Zeile die gleiche Anzahl an Meisterschaften hatte.

Die einzige Frage, die GPT-5 anhand der Diagrammdatenbank falsch beantwortete, lautete: „Wer hat 2017 die Formel-2-Meisterschaft gewonnen?“ was mit „Lewis Hamilton“ beantwortet wurde (Lewis Hamilton gewann in diesem Jahr die Formel-1-Meisterschaft, aber nicht die Formel-2-Meisterschaft). Dies ist eine knifflige Frage, da die Datenbank nur Formel-1-Ergebnisse enthält, nicht jedoch Formel-2-Ergebnisse. Die erwartete Antwort wäre gewesen, dass diese Frage anhand der bereitgestellten Daten nicht beantwortet werden könne. Da die Systemaufforderung jedoch keine spezifischen Informationen zum Datensatz enthielt, ist es verständlich, dass diese Frage nicht richtig beantwortet wurde.

Interessanterweise ergab die Verwendung der SQL-Datenbank GPT-5 die richtige Antwort „Charles Leclerc“. Die generierte SQL-Abfrage durchsuchte nur die Treibertabelle nach dem Namen „Charles Leclerc“. Hier muss die LLM erkannt haben, dass die Datenbank keine Formel-2-Ergebnisse enthält und diese Frage nach ihrem Allgemeinwissen beantwortet haben. Obwohl dies in diesem Fall zur richtigen Antwort führte, kann es gefährlich sein, wenn das LLM die bereitgestellten Daten nicht zur Beantwortung von Fragen verwendet. Eine Möglichkeit, dieses Risiko zu verringern, könnte darin bestehen, in der Systemaufforderung explizit anzugeben, dass die Datenbank die einzige Quelle zur Beantwortung von Fragen sein darf.

Abschluss

Dieser Vergleich der RAG-Leistung anhand eines Formel-1-Ergebnisdatensatzes zeigt, dass die neuesten LLMs eine außergewöhnlich gute Leistung erbringen und äußerst genaue und kontextbezogene Antworten ohne zusätzliches Immediate-Engineering liefern. Während einfachere Modelle Schwierigkeiten haben, verarbeiten neuere Modelle wie GPT-5 komplexe Abfragen mit nahezu perfekter Präzision. Wichtig ist, dass es keinen signifikanten Leistungsunterschied zwischen den Diagramm- und SQL-Datenbankansätzen gab – Benutzer können einfach das Datenbankparadigma wählen, das am besten zur Struktur ihrer Daten passt.

Der hier verwendete Datensatz dient nur als anschauliches Beispiel; Die Ergebnisse können abweichen, wenn andere Datensätze verwendet werden, insbesondere solche, die spezielle Domänenkenntnisse oder Zugriff auf nicht öffentliche Datenquellen erfordern. Insgesamt verdeutlichen diese Ergebnisse, wie weit abrufgestützte LLMs bei der Integration strukturierter Daten mit dem Denken in natürlicher Sprache fortgeschritten sind.

Sofern nicht anders angegeben, wurden alle Bilder vom Autor selbst erstellt.