Text-to-SQL: Vergleich der Genauigkeit von LLMs
Ich verlasse mich seit 18 Jahren auf SQL für die Datenanalyse, begonnen in meiner Zeit als Berater. Die Übersetzung von natürlichsprachlichen Fragen in SQL macht Daten zugänglicher und ermöglicht es jedem, auch Personen ohne technische Kenntnisse, direkt mit Datenbanken zu arbeiten.
Wir haben unsere Benchmark-Methodik für Text-to-SQL auf über 35 große Sprachmodelle (LLMs) angewendet, um deren Leistung bei der Generierung von SQL-Befehlen zu bewerten:
Häufige Fehler in von LLMs generiertem SQL
LLMs machen oft vier Fehlertypen: fehlerhafte Joins, Aggregationsfehler, fehlende Filter und Syntaxfehler.
Falsche Join-Logik
Modelle hatten oft Schwierigkeiten, die notwendigen `JOIN`-Operationen zwischen Tabellen korrekt zu identifizieren und zu implementieren, ließen sie manchmal ganz weg oder verwendeten weniger optimale Unterabfragen.
Das LLM schaffte es nicht, die Tabellen `frpm` und `schools` korrekt über `CDSCode` zu verknüpfen. Es halluzinierte auch Spaltennamen (`Charter`) und Filterwerte (`County = 'Fresno'`).
Fehler in der Join-Logik zerstören grundlegend den relationalen Aspekt der Abfrage und führen zu unvollständigen oder falschen Datenabrufen, wenn mehrere Tabellen beteiligt sind.
Aggregations- und Gruppierungsfehler
Die falsche Anwendung von Aggregatfunktionen (wie `MAX`, `AVG`, `COUNT`, `SUM`) oder `GROUP BY`-Klauseln war ein weiterer häufiger Fehlerschwerpunkt, der zu Ergebnissen führte, die semantisch nicht der Absicht des Benutzers entsprachen.
Das LLM erkannte korrekt, dass der Ausdruck „höchste durchschnittliche Punktzahl“ eine Gruppierung der Daten nach Bezirk (GROUP BY dname) und die Verwendung einer Aggregatfunktion (AVG(AvgScrRead)) erfordert. Dieser Teil der Logik ist richtig.
Allerdings versäumte es das LLM, einen kritischen Filter aus der Frage einzubauen: das Wort „active“. Um diese Anforderung zu erfüllen, hätte die Abfrage die Tabelle `satscores` mit der Tabelle `schools` über JOIN verknüpfen und die Ergebnisse dann mit einer WHERE T1.StatusType = 'Active' Klausel filtern müssen.
Dies verdeutlicht ein häufiges Versagen von LLMs: eine primäre, offensichtliche Anweisung korrekt auszuführen (Berechnung eines Durchschnitts), während eine sekundäre, aber ebenso wichtige Bedingung (Filtern nach Status) übersehen wird. Dies zeigt eine Schwäche bei der Synthese mehrerer Einschränkungen zu einer einzigen korrekten Abfrage.
Fehlende oder falsche Filter
Modelle versäumten es manchmal, notwendige `WHERE`-Klauseln einzufügen oder wählten die falschen Spalten in der `SELECT`-Anweisung, ohne die im Prompt explizit angeforderten Einschränkungen oder Informationen vollständig zu berücksichtigen.
Das LLM erkannte korrekt die Logik, um die Schule zu finden (`ORDER BY NumGE1500 DESC LIMIT 1`), versäumte es jedoch, die angeforderte `Phone`-Nummer auszuwählen und ließ den notwendigen Join zur Tabelle `schools` weg, um sie abzurufen.
Diese Fehler resultieren oft aus einer unvollständigen Analyse der Benutzeranfrage oder dem Versagen, alle Teile der Anfrage auf die endgültigen SQL-Abfragekomponenten abzubilden.
Syntaxfehler
Über semantische Fehler hinaus traten auch handfeste Syntaxfehler auf, wie die Verwendung falscher Tabellenaliase oder die Erzeugung unvollständiger SQL-Anweisungen, die Ausführung der Abfrage verhindern.
Das LLM verwendete falsche Aliase (`accounts` statt `account`) und enthielt ein unvollständiges Zeichenkettenliteral (`'POPLATEK PO OBRATU…'`), was zu ungültiger SQL-Syntax führte.
Diese Syntaxprobleme verdeutlichen die Herausforderungen bei der Generierung von Code, der sich strikt an die SQL-Grammatik und datenbankspezifische Konventionen hält.
Warum manche LLMs besser in SQL sind
Mehrere Schlüsselfaktoren bestimmen, wie gut ein Large Language Model (LLM) eine einfache englische Frage in eine korrekte SQL-Datenbankabfrage umwandeln kann.
1. Modellgröße und Trainingsdaten
- Größe und Design: Größere Modelle oder solche, die mit spezifischen Strukturen gebaut wurden, können komplexe Aufgaben wie die SQL-Generierung effektiver bewältigen.
- Was es gelernt hat: Die Daten, mit denen das LLM trainiert wurde, sind entscheidend. Wenn es viele Beispiele von Fragen gesehen hat, die mit SQL-Antworten verknüpft sind, insbesondere solche mit komplexen Operationen wie Joins oder Berechnungen (SUM, AVG), wird es wahrscheinlich besser abschneiden.
2. Feinabstimmung für SQL-Aufgaben
- Modelle können zusätzlich speziell auf Text-to-SQL-Aufgaben trainiert werden. Diese „Feinabstimmung“ hilft ihnen, Datenbankstrukturen und SQL-Regeln besser zu verstehen als Modelle, die auf allgemeinem Text trainiert wurden. Training mit spezifischen Anweisungen hilft ebenfalls.
3. Fähigkeiten zum logischen Denken und Schema-Mapping
- Logisches Denken: Wie gut kann das LLM die genauen Schritte aus einer manchmal vagen Frage ableiten? Das Erstellen von SQL erfordert oft logische Schritte.
- Verständnis der Datenbank-Landkarte (Schema): Einige LLMs sind besser darin, Konzepte aus der Frage (wie „Kunden“ oder „Gesamtumsatz“) mit den tatsächlichen Tabellen- und Spaltennamen in der Datenbank zu verknüpfen, selbst wenn die Namen nicht sofort offensichtlich sind.
Wie LLMs SQL generieren: Eine Schritt-für-Schritt-Betrachtung
Um Faktoren wie „logisches Denken“ und „Schema-Mapping“ in Aktion zu sehen, gehen wir den schrittweisen Prozess durch, dem ein Modell folgt, um eine Abfrage zu generieren. Dieser gesamte Workflow wird durch eine Technik namens Retrieval-Augmented Generation (RAG) angetrieben.
Stufe 1: Erste Analyse und Datenbankauswahl
Wenn eine Frage gestellt wird, analysiert das LLM zunächst die Absicht des Benutzers, um das relevanteste Datenbank-Tool auszuwählen.
- Frage: „How many accounts have an owner disposition and request for a statement to be generated upon a transaction?“
- Aktion des LLMs: Das Modell identifiziert Schlüsselwörter wie „accounts“, „disposition“ und „transaction“. Es kommt zu dem Schluss, dass das Datenbank-Tool
financialdie richtige Wahl ist, gegenüber anderen wiecalifornia_schoolsodersuperhero.
Stufe 2: Abrufen des Schemas per RAG
Sobald das Modell ein Tool ausgewählt hat, benötigt es die „Landkarte“ der Datenbank – das Schema. Es hat diese Informationen nicht auswendig gelernt. Stattdessen ruft das RAG-System sie in Echtzeit ab.
- Abruf: Die Frage des Benutzers wird verwendet, um eine Vektordatenbank zu durchsuchen, die Schemainformationen speichert. Die Suche findet und ruft die relevantesten Schemadetails ab, wie die Definitionen der Tabellen
accountsunddisp. - Anreicherung: Dieser abgerufene Schematext wird automatisch zusammen mit der ursprünglichen Frage in den Prompt eingefügt.
- Generierung: Das LLM hat nun den gesamten Kontext, den es zum Fortfahren benötigt.
Dieser RAG-Prozess stellt sicher, dass das Modell die notwendigen Schemainformationen erhält, was seine Aufgabe fokussierter und effizienter macht.
Stufe 3: Logisches Denken und Abfragekonstruktion
Mit der Frage und dem vom RAG bereitgestellten Schema ordnet das Modell Konzepte aus der Benutzeranfrage den spezifischen Tabellen- und Spaltennamen zu, die es gerade erhalten hat.
Innerer Monolog des LLMs:
- Ziel: Der Benutzer möchte eine Zählung, also beginne ich mit
SELECT COUNT(...). - Bedingungen:
- „…owner disposition…“ -> Das Schema der Tabelle
dispenthält eine Spaltetype. Ich brauche eineWHERE-Klausel fürtype = 'OWNER'. - „…statement to be generated upon a transaction…“ -> Das Schema der Tabelle
accountsenthält eine Spaltefrequency. Der Filter solltefrequency = 'POPLATEK PO OBRATU'sein.
- „…owner disposition…“ -> Das Schema der Tabelle
- Joins: Die Informationen sind auf die Tabellen
accountsunddispverteilt. Das Schema zeigt, dass sie überaccount_idverknüpft sind, also muss ich sieJOIN.
Stufe 4: Generierung des endgültigen SQL
Schließlich setzt das Modell diese logischen Teile zu einer syntaktisch korrekten SQL-Abfrage zusammen. Die Qualität dieser Ausgabe hängt ab von:
- Fähigkeit zum logischen Denken: Die Fähigkeit des Modells, die Benutzeranfrage logisch mit dem bereitgestellten Schema zu verbinden.
- SQL-Wissen aus dem Training: Das grundlegende Verständnis des Modells für SQL-Syntax und -Funktionen.
Dieser Prozess erklärt, warum Fehler auftreten. Wenn das abgerufene Schema mehrdeutig ist oder ein Begriff in der Frage nicht sauber zugeordnet werden kann, muss das LLM eine fundierte Vermutung anstellen, was zu den zuvor analysierten Fehlern führen kann.
Was ist Text-to-SQL?
Text-to-SQL ist eine Technologie der natürlichen Sprachverarbeitung, die Alltagssprache in eine SQL-Abfrage in Structured Query Language umwandelt. Anstatt manuell SQL-Code zu schreiben, stellt ein Benutzer eine Frage in natürlicher Sprache, und das System generiert eine SQL-Anweisung, die auf einer Datenbank ausgeführt werden kann.
Der Hauptzweck von Text-to-SQL besteht darin, die Lücke zwischen der Art und Weise, wie Menschen über Daten denken, und der Art und Weise, wie Datenbanken Abfragen erfordern, zu verringern. Dies ist besonders relevant für nicht-technische Benutzer und Datenanalysten, die den Geschäftskontext verstehen, sich aber möglicherweise nicht wohl dabei fühlen, SQL-Syntax von Grund auf neu zu schreiben.
Auf einer grundlegenden Ebene, wenn ein Benutzer eine Frage stellt wie:
- „Zeige alle Kunden aus New York, die letzten Monat Einkäufe getätigt haben.“
Übersetzt das System diese Anfrage in eine generierte SQL-Abfrage, die richtigen Spalten auswählt, Zeilen mit Datums- und Standortbeschränkungen filtert und die erforderlichen Datenbanktabellen verknüpft. Die Qualität der Ausgabe hängt davon ab, ob das System genaue Abfragen generieren kann, die sowohl die Benutzerabsicht als auch das Datenbankschema widerspiegeln.
Wo Text-to-SQL heute nützlich ist
Text-to-SQL funktioniert einigermaßen gut für:
- Entwurf von Abfragen, die Datenanalysten überprüfen und anpassen können.
- Unterstützung explorativer Datenanalysen, bei denen Geschwindigkeit wichtiger ist als Präzision.
- Ermöglichung des Zugriffs nicht-technischer Benutzer auf einfache Daten über vordefinierte Schemata.
- Unterstützung von SQL-Benutzern, indem die Notwendigkeit reduziert wird, sich wiederholende Abfragen zu schreiben.
In diesen Fällen fungiert Text-to-SQL als unterstützendes KI-Tool und nicht als autonomes System. Menschliche Überprüfung bleibt Teil des Workflows, insbesondere wenn Korrektheit wichtig ist.
Wie funktioniert Text-to-SQL?
Moderne Text-to-SQL-Systeme stützen sich auf große Sprachmodelle, die auf Paaren von natürlichsprachlichen Fragen und SQL-Abfragen trainiert wurden. Diese Modelle lernen Muster, die Alltagssprache mit SQL-Strukturen, Tabellennamen, Spalten und Beziehungen verbinden. Der Prozess folgt typischerweise einer Abfolge von Schritten:
Verstehen natürlicher Sprache
Das System analysiert zunächst die Benutzereingabe, um Absicht, Einschränkungen und Entitäten zu bestimmen. Dieser Schritt umfasst:
- Identifizieren, wonach der Benutzer fragt (z. B. Summen, Filter, Vergleiche)
- Extrahieren relevanter Bedingungen wie Zeiträume, Orte oder Kategorien
- Interpretation mehrdeutiger Formulierungen, die Geschäftskontext erfordern könnten
Fehler in dieser Phase führen oft zu einer korrekt aussehenden SQL-Abfrage, die falsche Frage beantwortet.
Schema-Mapping
Als Nächstes ordnet das System Begriffe aus der Frage dem Datenbankschema zu. Dazu gehört:
- Zuordnung von Konzepten in der Frage zu Tabellennamen und Spalten
- Verstehen der Beziehungen zwischen Tabellen
- Beachtung von Datentypen, wie Datumsangaben, numerischen Feldern oder Kategorien
Das Schema-Mapping wird schwieriger, je mehr Tabellen vorhanden sind oder wenn Spaltennamen nicht genau der Art und Weise entsprechen, wie Benutzer Daten in natürlichsprachlichen Fragen beschreiben.
SQL-Abfragekonstruktion
Sobald Absicht und Schemaelemente identifiziert sind, konstruiert das System die SQL-Abfrage. Dies kann Folgendes beinhalten:
- Auswahl der richtigen Tabellen und Spalten
- Hinzufügen von Joins über alle benötigten Tabellen hinweg
- Anwenden von Filtern, Aggregationen und Gruppierungslogik
- Erzeugen von syntaktisch gültigem SQL-Code für Systeme wie MySQL oder PostgreSQL
In dieser Phase kann das System leicht gültiges, aber logisch falsches SQL produzieren, z. B. durch Verwendung der falschen Join-Bedingung oder Aggregation.
Validierung und Ausführung
Einige Systeme enthalten Validierungsschichten, die überprüfen, ob die generierte SQL-Abfrage ausgeführt werden kann und Ergebnisse zurückgibt. Fortgeschrittenere Tools können begrenzte Optimierungen versuchen oder Rückfragen stellen, wenn die Abfrage mehrdeutig ist.
Die Validierung garantiert jedoch selten eine korrekte Antwort. Eine Abfrage kann erfolgreich ausgeführt werden und dennoch auf subtile Weise falsch sein.
Einschränkungen und praktische Risiken
Trotz starker Benchmark-Ergebnisse offenbart der Einsatz in der Praxis mehrere Einschränkungen, die nicht ignoriert werden können.
Zuverlässigkeit und Korrektheit
Selbst leistungsstärkste Modelle produzieren für einen signifikanten Anteil komplexer Abfragen kein korrektes SQL. Eine Fehlerquote von 20% oder mehr bedeutet:
- Eine von fünf generierten Abfragen kann irreführende Ergebnisse liefern
- Fehler sind oft semantischer und nicht syntaktischer Natur
- Falsche Joins, Filter oder Aggregationen können unbemerkt bleiben
Dies ist besonders riskant in Berichts-, Prognose- oder Entscheidungsunterstützungssystemen, bei denen Benutzer davon ausgehen, dass die Ausgabe korrekt ist.
Abhängigkeit von menschlicher Aufsicht
Angesichts der aktuellen Leistung muss das generierte SQL von jemandem überprüft werden, der SQL und die Datenbank versteht. Ohne diese Aufsicht:
- Können Benutzer einer falschen Abfrage vertrauen, weil sie erfolgreich ausgeführt wird
- Können sich Fehler in Dashboards, Berichte oder nachgelagerte Systeme ausbreiten
- Wird die Verantwortlichkeit unklar, wenn Entscheidungen auf KI-generierten Ausgaben beruhen
Text-to-SQL beseitigt nicht die Notwendigkeit von SQL-Expertise; es verlagert, wo diese Expertise angewendet wird.
Komplexitätsobergrenze
Wenn die Abfragekomplexität zunimmt, sinkt die Leistung stark. Modelle haben Schwierigkeiten mit:
- Mehrfachen Joins über viele Tabellen hinweg
- Verschachtelter Logik und Unterabfragen
- Domänenspezifischen Berechnungen
- Abfragen, die tiefe Kenntnisse des Datenbankschemas erfordern
Benchmarks wie BIRD-SQL zeigen, dass komplexe Abfragen auch für fortgeschrittene Modelle der Hauptfehlerpunkt bleiben.
Modellvariabilität
Die Leistungsunterschiede zwischen Modellen sind erheblich. Einige Sprachmodelle schneiden recht gut ab, während andere auf demselben Datensatz häufig versagen. Das bedeutet:
- Die Modellauswahl hat einen direkten Einfluss auf die Genauigkeit
- Feinabstimmung und Trainingsdaten sind wichtig
- Allzweckmodelle funktionieren möglicherweise nicht gut ohne Domänenanpassung
Es gibt keine universelle Lösung, die gleichermaßen gut über Datenbanken und Anwendungsfälle hinweg funktioniert.
Data Governance und Datenschutz
Text-to-SQL-Systeme bringen zusätzliche Zugriffsrisiken mit sich:
- Benutzer können sensible Tabellen abfragen, ohne die Auswirkungen zu verstehen
- Generiertes SQL kann Metadaten über das Datenbankschema preisgeben
- Datenschutzkontrollen müssen außerhalb des Sprachmodells durchgesetzt werden
Ohne starke Zugriffskontrollen kann Text-to-SQL bestehende Governance-Praktiken schwächen.
Als bevorzugte Quelle hinzufügenBenchmark-Methodik für Text-to-SQL
Dieser Benchmark teilt seinen Evaluierungsrahmen mit unserem agentischen RAG-Benchmark, der die Datensatzkonstruktion, die Agentenarchitektur, die Herausforderung der semantischen Mehrdeutigkeit und die vollständige Bewertungsmatrix detailliert beschreibt.
Beide Benchmarks verwenden dieselbe Teilmenge von 500 Fragen aus BIRD-SQL1 , dieselbe agentische Pipeline, dasselbe ChromaDB-gestützte Schema-Retrieval und dieselbe LLM-as-Judge-Bewertung mit Claude 4 Sonnet. Die hier berichtete Metrik, die Rate der korrekten SQL-Befehlsgenerierung, ist der Prozentsatz der Fragen, bei denen das Modell sowohl zur richtigen Datenbank geroutet als auch eine semantisch korrekte SQL-Abfrage generiert hat. Alle Modelle wurden unter identischen Zero-Shot-Bedingungen mit Temperatur 0 und ohne domänenspezifische Hinweise evaluiert.
Weiterführende Literatur
Entdecken Sie andere RAG-Benchmarks, wie zum Beispiel:
- Embedding Models: OpenAI vs Gemini vs Cohere
- Top Vector Database für RAG: Qdrant vs Weaviate vs Pinecone
- Hybrid RAG: Steigerung der RAG-Genauigkeit
- Agentic RAG-Benchmark: Multi-Datenbank-Routing und Abfragegenerierung
- Top 10 mehrsprachige Embedding-Modelle für RAG
FAQs
Basierend auf unseren Ergebnissen sollten Sie komplexen Abfragen, die von aktuellen LLMs generiert wurden, nicht ohne Validierung vollständig vertrauen. Obwohl sie für Entwürfe und einfache Anfragen nützlich sind, weisen selbst leistungsstärkste Modelle signifikante Fehlerquoten auf (bis zu 20% bei komplexen Aufgaben). Überprüfen und verifizieren Sie das generierte SQL immer, insbesondere für kritische Anwendungen.
Ja, viele LLMs verfügen über Fähigkeiten, die über die einfache SELECT-Generierung hinausgehen. Sie können oft dabei helfen, vorhandenen SQL-Code zu verstehen und Änderungen vorzuschlagen oder sogar DDL (Data Definition Language) wie CREATE TABLE-Anweisungen basierend auf Beschreibungen zu generieren, obwohl die Genauigkeit für diese Aufgaben ebenfalls eine Überprüfung erfordert.
Die Bereitstellung eines klaren Kontexts ist der Schlüssel. Stellen Sie sicher, dass das LLM Zugriff auf das Datenbankschema hat (Tabellennamen, Spaltennamen, Beziehungen). Das klare Formulieren des gewünschten Ergebnisses und möglicherweise die Bereitstellung einiger relevanter Beispielabfragen (Few-Shot-Prompting), von denen das LLM lernen kann, können seine Fähigkeit, die richtigen Tabellen auszuwählen und genaue Abfragen zu konstruieren, erheblich verbessern.
Obwohl LLMs möglicherweise einige geringfügige Syntaxunterschiede zwischen Datenbankdialekten abstrahieren können, lösen sie die Kompatibilitätsprobleme zwischen Datenbanktypen und -versionen nicht vollständig. Sie generieren möglicherweise immer noch SQL, das für einen bestimmten Dialekt spezifisch ist (z. B. PostgreSQL vs. MySQL), oder verwenden Funktionen, die nicht mit älteren Versionen kompatibel sind, es sei denn, sie werden explizit angeleitet oder darauf trainiert. Die Validierung gegen die Zieldatenbank bleibt wichtig.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{Text-to-SQL: Vergleich der Genauigkeit von LLMs}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Abgerufen am 17. Juli 2026}
}
Kommentare 1
Teilen Sie Ihre Gedanken
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.
Curious, how much of the context engineering and specific prompting did you apply in your benchmarks. Or, was it to review the models only? I have found much higher return of correct and consistent responses. A higher fidelity. To do that, I needed to provide a most sophisticated prompt that fed the context window as the question was being asked. Not perfect, but better than those scores represented in this article when using the Grok 4.x .
Great point. This benchmark intentionally uses zero-shot, minimal prompting with temperature=0. No few-shot examples, no domain-specific instructions, no iterative refinement. The goal was to measure each model's baseline text-to-SQL capability. So your experience with Grok 4 getting higher fidelity through sophisticated context engineering is completely expected. A well-crafted prompt with detailed schema descriptions, few-shot examples, and domain-specific rules will improve any model's performance significantly. What this benchmark isolates is how well the model performs out-of-the-box when given only the raw question and retrieved schema, which helps compare the models' inherent SQL reasoning abilities on a level playing field. We'll make this clearer in the methodology section. Thanks for raising it.