Text-zu-SQL: Vergleich der LLM-Genauigkeit

Ich nutze SQL seit 18 Jahren für die Datenanalyse, angefangen in meiner Zeit als Berater. Die Übersetzung von natürlichsprachlichen Anfragen in SQL macht Daten zugänglicher und ermöglicht es jedem, auch ohne technische Vorkenntnisse, direkt mit Datenbanken zu arbeiten.

Wir haben unsere Text-zu-SQL-Benchmark-Methodik auf 34 große Sprachmodelle (LLMs) angewendet, um deren Leistung bei der Generierung von SQL-Befehlen zu bewerten:

Häufige Fehler in LLM-generiertem SQL

LLMs machen oft vier Arten von Fehlern: fehlerhafte Joins, Aggregationsfehler, fehlende Filter und Syntaxfehler.

Falsche Join-Logik

Die Modelle hatten oft Schwierigkeiten, die notwendigen `JOIN`-Operationen zwischen Tabellen korrekt zu identifizieren und zu implementieren, wobei sie diese manchmal ganz ausließen oder weniger optimale Unterabfragen verwendeten.

Das LLM konnte die Tabellen `frpm` und `schools` mithilfe des `CDSCode` nicht korrekt verknüpfen. Außerdem wurden Spaltennamen (`Charter`) und Filterwerte (`County = 'Fresno'`) fehlerhaft zugeordnet .

Fehler in der Join-Logik beeinträchtigen grundsätzlich den relationalen Aspekt der Abfrage und führen bei der Einbeziehung mehrerer Tabellen zu unvollständigen oder fehlerhaften Datenabrufen.

Aggregations- und Gruppierungsfehler

Die fehlerhafte Anwendung von Aggregatfunktionen (wie `MAX`, `AVG`, `COUNT`, `SUM`) oder `GROUP BY`-Klauseln war ein weiterer häufiger Fehlerpunkt, der zu Ergebnissen führte, die nicht der semantischen Absicht des Benutzers entsprachen.

Das LLM hat korrekt erkannt, dass für den Ausdruck „ höchster Durchschnittswert “ die Daten nach Bezirk gruppiert (GROUP BY dname) und eine Aggregatfunktion (AVG(AvgScrRead)) verwendet werden müssen. Dieser Teil der Logik ist korrekt.

Die LLM-Abfrage berücksichtigte jedoch nicht einen wichtigen Filter aus der Aufgabenstellung: das Wort „ aktiv “. Um diese Anforderung zu erfüllen, musste die Abfrage die Tabelle „satscores“ mit der Tabelle „schools“ verknüpfen und die Ergebnisse anschließend mit einer WHERE-Klausel „T1.StatusType = 'Active'“ filtern.

Dies verdeutlicht einen häufigen Fehler im LLM-Algorithmus: Die korrekte Ausführung einer primären, offensichtlichen Anweisung (Berechnung eines Durchschnitts) wird zwar durchgeführt, während eine sekundäre, aber ebenso wichtige Bedingung (Filterung nach Status) übersehen wird. Dies zeigt eine Schwäche bei der Synthese mehrerer Bedingungen zu einer einzigen, korrekten Abfrage.

Fehlende oder falsche Filter

Manchmal fehlten in den Modellen die notwendigen `WHERE`-Klauseln oder es wurden die falschen Spalten in der `SELECT`-Anweisung ausgewählt, sodass die Einschränkungen oder die in der Eingabeaufforderung explizit angeforderten Informationen nicht vollständig berücksichtigt wurden.

Der LLM hat die Logik zum Auffinden der Schule korrekt erkannt (`ORDER BY NumGE1500 DESC LIMIT 1`), konnte aber die angeforderte Telefonnummer nicht auswählen und hat den notwendigen Join mit der Tabelle `schools` zum Abrufen dieser Nummer ausgelassen.

Diese Fehler entstehen oft durch eine unvollständige Analyse der Benutzeranfrage oder dadurch, dass nicht alle Teile der Anfrage den endgültigen SQL-Abfragekomponenten zugeordnet werden konnten.

Syntaxfehler

Neben semantischen Fehlern traten auch regelrechte Syntaxfehler auf, wie die Verwendung falscher Tabellenaliase oder die Erstellung unvollständiger SQL-Anweisungen, die die Ausführung der Abfrage verhindern.

Das LLM verwendete falsche Aliase (`accounts` statt `account`) und enthielt ein unvollständiges String-Literal (`'POPLATEK PO OBRATU…'`), was zu einer ungültigen 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 LLM-Absolventen 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 mit spezifischen Strukturen können komplexe Aufgaben wie die SQL-Generierung effektiver bewältigen.
• Was es gelernt hat: Die zum Trainieren des LLM verwendeten Daten sind entscheidend. Wenn es viele Beispiele von Fragen sieht, die mit SQL-Antworten verknüpft sind, insbesondere solche mit komplexen Operationen wie Joins oder Berechnungen (SUMME, MITTELWERT), wird es wahrscheinlich bessere Ergebnisse erzielen.

2. Feinabstimmung für SQL-Aufgaben

• Modelle können gezielt für Text-zu-SQL-Aufgaben trainiert werden. Dieses „Feinabstimmen“ hilft ihnen, Datenbankstrukturen und SQL-Regeln besser zu verstehen als Modelle, die nur mit allgemeinem Text trainiert wurden. Auch das Training mit spezifischen Anweisungen ist hilfreich.

3. Fähigkeiten zum logischen Denken und zur Schemaabbildung

• Begründung: Wie gut kann der LLM aus einer manchmal vagen Frage die exakten notwendigen Schritte ableiten? Das Erstellen von SQL erfordert oft logische Schritte .
• Verständnis des Datenbankschemas: Manche LLMs sind besser darin, Konzepte in der Frage (wie „Kunden“ oder „Gesamtumsatz“) mit den tatsächlichen Tabellen- und Spaltennamen in der Datenbank zu verknüpfen, auch wenn die Namen nicht sofort ersichtlich sind.

Wie LLMs SQL generieren: Eine schrittweise Betrachtung

Um Faktoren wie „logisches Denken“ und „Schema-Mapping“ in der Praxis zu sehen, betrachten wir den schrittweisen Prozess, den ein Modell zur Generierung einer Abfrage durchläuft. Dieser gesamte Workflow basiert auf einer Technik namens Retrieval-Augmented Generation (RAG).

Phase 1: Erste Analyse und Datenbankauswahl

Bei der Beantwortung einer Frage analysiert das LLM zunächst die Absicht des Benutzers, um das relevanteste Datenbanktool auszuwählen.

• Frage: „Wie viele Konten haben eine Eigentümerverfügung und die Anforderung, dass bei einer Transaktion ein Kontoauszug erstellt wird?“
• LLMs Vorgehen: Das Modell identifiziert Schlüsselwörter wie „Konten“, „Verfügung“ und „Transaktion“. Es kommt zu dem Schluss, dass das Datenbanktool financial die richtige Wahl gegenüber anderen wie california_schools oder superhero ist.

Phase 2: Abrufen des Schemas über RAG

Sobald das Modell ein Werkzeug ausgewählt hat, benötigt es die Datenbankzuordnung zum Schema. Diese Information ist nicht gespeichert, sondern wird vom RAG-System in Echtzeit abgerufen.

1. Abfrage: Die Frage des Benutzers dient zur Suche in einer Vektordatenbank, die Schemainformationen speichert. Die Suche findet und ruft die relevantesten Schemadetails ab, beispielsweise die Definitionen der Tabellen accounts und disp.
2. Erweiterung: Dieser abgerufene Schematext wird automatisch zusammen mit der ursprünglichen Frage in die Eingabeaufforderung eingefügt.
3. Generation: Das LLM-Programm verfügt nun über den gesamten Kontext, den es für seine Durchführung benötigt.

Dieses RAG-Verfahren stellt sicher, dass das Modell nur die notwendigen Schemainformationen erhält, wodurch seine Aufgabe fokussierter und effizienter wird.

Phase 3: Schlussfolgerung und Abfrageerstellung

Anhand der Frage und des vom RAG-System bereitgestellten Schemas ordnet das Modell Konzepte aus der Benutzeranfrage den spezifischen Tabellen- und Spaltennamen zu, die es gerade erhalten hat.

LLMs innerer Monolog:

1. Ziel: Der Benutzer wünscht eine Anzahl, also beginne ich mit SELECT COUNT(...).
2. Bedingungen:
   • „…Verfügung des Eigentümers…“ -> Das Tabellenschema disp hat eine Spalte type. Ich benötige eine Klausel WHERE für type = 'OWNER'.
   • „…Anweisung, die bei einer Transaktion generiert wird…“ -> Das Tabellenschema accounts hat eine Spalte frequency. Der Filter sollte frequency = 'POPLATEK PO OBRATU' lauten.
3. Verknüpfungen: Die Informationen sind auf die Tabellen accounts und disp verteilt. Das Schema zeigt, dass sie über account_id verknüpft sind, daher muss ich sie mit JOIN verknüpfen.

Phase 4: Generierung des endgültigen SQL-Codes

Schließlich fügt das Modell diese logischen Bausteine zu einer syntaktisch korrekten SQL-Abfrage zusammen. Die Qualität dieses Ergebnisses hängt von folgenden Faktoren ab:

1. Schlussfolgerungsfähigkeit: Die Fähigkeit des Modells, die Anfrage des Benutzers logisch mit dem bereitgestellten Schema zu verknüpfen.
2. SQL-Kenntnisse aus der Schulung: 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 eindeutig zugeordnet werden kann, muss das LLM eine fundierte Annahme treffen, was zu den zuvor analysierten Fehlern führen kann.

Was ist Text-zu-SQL?

Text-to-SQL ist eine Technologie zur Verarbeitung natürlicher Sprache, die Alltagssprache in eine SQL-Abfrage in strukturierter Abfragesprache (SQL) umwandelt. Anstatt SQL-Code manuell zu schreiben, stellt der Benutzer eine Frage in natürlicher Sprache, und das System generiert eine SQL-Anweisung, die in einer Datenbank ausgeführt werden kann.

Der Hauptzweck der Text-zu-SQL-Konvertierung besteht darin, die Kluft zwischen dem menschlichen Verständnis von Daten und den Anforderungen von Datenbankabfragen zu verringern. Dies ist insbesondere für Anwender ohne technische Vorkenntnisse und Datenanalysten relevant, die zwar den Geschäftskontext verstehen, sich aber möglicherweise nicht sicher fühlen, SQL-Syntax von Grund auf selbst zu schreiben.

Ganz grundlegend, wenn ein Benutzer eine Frage stellt wie:

• „Zeige alle Kunden aus New York an, die im letzten Monat Einkäufe getätigt haben.“

Das System übersetzt diese Anfrage in eine generierte SQL-Abfrage, die die korrekten Spalten auswählt, Zeilen anhand von Datums- und Ortsbeschränkungen filtert und die erforderlichen Datenbanktabellen verknüpft. Die Qualität des Ergebnisses hängt davon ab, ob das System präzise Abfragen generieren kann, die sowohl die Benutzerabsicht als auch das Datenbankschema widerspiegeln.

Wo Text-zu-SQL heute nützlich ist

Text-to-SQL funktioniert recht gut für:

• Generieren Sie Entwurfsabfragen, die Datenanalysten überprüfen und anpassen können.
• Unterstützung explorativer Datenanalysen, bei denen Geschwindigkeit wichtiger ist als Präzision.
• Ermöglichen Sie es auch technisch nicht versierten Benutzern, über vordefinierte Schemata auf einfache Daten zuzugreifen.
• Unterstützen Sie SQL-Benutzer, indem Sie die Notwendigkeit, sich wiederholende Abfragen zu schreiben, reduzieren.

In diesen Fällen fungiert Text-zu-SQL eher als unterstützendes KI-Werkzeug denn als autonomes System. Die menschliche Überprüfung bleibt Teil des Arbeitsablaufs, insbesondere wenn es auf Korrektheit ankommt.

Wie funktioniert Text-zu-SQL?

Moderne Text-zu-SQL-Systeme basieren auf großen Sprachmodellen, die mit Paaren aus natürlichsprachlichen Fragen und SQL-Abfragen trainiert werden. Diese Modelle lernen Muster, die Alltagssprache mit SQL-Strukturen, Tabellennamen, Spalten und Beziehungen verknüpfen. Der Prozess folgt typischerweise einer Abfolge von Schritten:

Natürliches Sprachverständnis

Das System analysiert zunächst die Benutzereingabe, um Absicht, Einschränkungen und Entitäten zu ermitteln. Dieser Schritt umfasst Folgendes:

• Ermitteln, was der Benutzer anfordert (z. B. Summen, Filter, Vergleiche)
• Relevante Bedingungen wie Zeiträume, Orte oder Kategorien extrahieren
• Interpretation mehrdeutiger Formulierungen, die möglicherweise einen geschäftlichen Kontext erfordern.

Fehler in dieser Phase führen oft zu einer korrekt aussehenden SQL-Abfrage, die die falsche Frage beantwortet.

Schema-Zuordnung

Anschließend ordnet das System die Begriffe aus der Frage dem Datenbankschema zu. Dies umfasst:

• Zuordnung der Konzepte aus der Frage zu Tabellennamen und Spalten
• Beziehungen zwischen Tabellen verstehen
• Beachtung von Datentypen wie Datumsangaben, numerischen Feldern oder Kategorien

Die Schema-Abbildung wird umso schwieriger, je größer die Anzahl der Tabellen wird oder wenn die Spaltennamen nicht genau der Art und Weise entsprechen, wie Benutzer Daten in natürlichsprachlichen Fragen beschreiben.

SQL-Abfragekonstruktion

Sobald Absicht und Schemaelemente identifiziert sind, erstellt das System die SQL-Abfrage. Dies kann Folgendes umfassen:

• Auswahl der richtigen Tabellen und Spalten
• Hinzufügen von Joins über alle benötigten Tabellen
• Anwenden von Filtern, Aggregationen und Gruppierungslogik
• Erzeugung von syntaktisch gültigem SQL-Code für Systeme wie MySQL oder PostgreSQL

In diesem Stadium kann das System leicht gültigen, aber logisch falschen SQL-Code erzeugen, beispielsweise durch die Verwendung der falschen Join-Bedingung oder Aggregation.

Validierung und Ausführung

Manche Systeme beinhalten Validierungsebenen, die überprüfen, ob die generierte SQL-Abfrage ausgeführt werden kann und Ergebnisse liefert. Fortgeschrittenere Tools versuchen unter Umständen eine begrenzte Optimierung oder stellen Nachfragen, wenn die Abfrage mehrdeutig ist.

Allerdings garantiert die Validierung selten ein korrektes Ergebnis. Eine Abfrage kann erfolgreich ausgeführt werden und dennoch in subtiler Hinsicht fehlerhaft sein.

Einschränkungen und praktische Risiken

Trotz starker Benchmark-Ergebnisse zeigen sich in der Praxis mehrere Einschränkungen, die nicht ignoriert werden können.

Zuverlässigkeit und Korrektheit

Selbst leistungsstarke Modelle liefern bei einem erheblichen Anteil komplexer Abfragen keinen korrekten SQL-Code. Eine Fehlerrate von 20 % oder höher bedeutet:

• Eine von fünf generierten Abfragen kann irreführende Ergebnisse liefern.
• Fehler sind oft eher semantischer als syntaktischer Natur.
• Fehlerhafte Verknüpfungen, Filter oder Aggregationen können unbemerkt bleiben.

Dies birgt ein besonderes Risiko bei Berichts-, Prognose- oder Entscheidungsunterstützungssystemen, bei denen die Benutzer davon ausgehen, dass die Ausgabe korrekt ist.

Abhängigkeit von menschlicher Aufsicht

Angesichts der aktuellen Performance muss der generierte SQL-Code von jemandem überprüft werden, der SQL und Datenbanken versteht. Ohne diese Überprüfung:

• Nutzer könnten einer fehlerhaften Abfrage vertrauen, weil sie erfolgreich ausgeführt wird.
• Fehler können sich auf Dashboards, Berichte oder nachgelagerte Systeme auswirken.
• Die Verantwortlichkeit wird unklar, wenn Entscheidungen auf KI-generierten Ergebnissen beruhen.

Text-to-SQL beseitigt nicht die Notwendigkeit von SQL-Kenntnissen; es verlagert lediglich den Anwendungsbereich dieser Kenntnisse.

Komplexitätsobergrenze

Mit zunehmender Komplexität der Abfragen sinkt die Leistung rapide. Modelle haben Schwierigkeiten mit:

• Mehrere Joins über viele Tabellen hinweg
• Verschachtelte Logik und Unterabfragen
• Domänenspezifische Berechnungen
• Abfragen, die tiefgreifende Kenntnisse des Datenbankschemas erfordern

Benchmarks wie BIRD-SQL verdeutlichen, dass komplexe Abfragen auch bei fortgeschrittenen Modellen die Hauptursache für Fehler darstellen.

Modellvariabilität

Die Leistungsunterschiede zwischen den Modellen sind signifikant. Einige Sprachmodelle erzielen recht gute Ergebnisse, während andere bei demselben Datensatz häufig versagen. Das bedeutet:

• Die Modellauswahl hat einen direkten Einfluss auf die Genauigkeit.
• Feinabstimmung und Trainingsdaten sind wichtig
• Allgemeine Modelle funktionieren möglicherweise nicht gut ohne Domänenanpassung.

Es gibt keine universelle Lösung, die für alle Datenbanken und Anwendungsfälle gleichermaßen gut funktioniert.

Datenverwaltung und Datenschutz

Text-zu-SQL-Systeme bergen zusätzliche Zugriffsrisiken:

• Benutzer fragen möglicherweise sensible Tabellen ab, ohne die Konsequenzen zu verstehen.
• Generierter SQL-Code kann Metadaten über das Datenbankschema offenlegen.
• Datenschutzmaßnahmen müssen außerhalb des Sprachmodells durchgesetzt werden.

Ohne strenge Zugriffskontrollen kann die Text-zu-SQL-Konvertierung bestehende Governance-Praktiken schwächen.

Benchmark-Methodik für Text-zu-SQL

Dieser Benchmark teilt seinen Bewertungsrahmen mit unserem agentenbasierten RAG-Benchmark , der die Erstellung des Datensatzes, die Agentenarchitektur, die Herausforderung der semantischen Mehrdeutigkeit und die vollständige Bewertungsmatrix detailliert beschreibt.

Beide Benchmarks verwenden denselben BIRD-SQL-Fragebogen mit 500 Fragen. ¹ Teilmenge, agentenbasierte Pipeline, Schemaabruf mit ChromaDB und LLM-as-Judge-Evaluierung mit Claude 4 Sonnet. Die hier angegebene Metrik, die Rate korrekter SQL-Befehlsgenerierung, ist der Prozentsatz der Fragen, bei denen das Modell sowohl die richtige Datenbank ansprach als auch eine semantisch korrekte SQL-Abfrage generierte. Alle Modelle wurden unter identischen Zero-Shot-Bedingungen mit Temperatur 0 und ohne domänenspezifische Hinweise evaluiert.

Weiterführende Literatur

Erkunden Sie weitere RAG-Benchmarks, wie zum Beispiel:

• Einbettungsmodelle: OpenAI vs Gemini vs Cohere
• Top-Vektordatenbank 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 Einbettungsmodelle für RAG

Änderungsprotokoll

20. Februar 2026

Dem Benchmark wurden 2 neue Modelle hinzugefügt:

• Google: Gemini 3.1 Pro Vorschau (google/gemini-3.1-pro-preview)
• Anthropic: Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)

10. Februar 2026

Dem Benchmark wurden 2 neue Modelle hinzugefügt:

• Claude Opus 4.6 (anthropic/claude-opus-4.6)
• Kimi K2.5 (moonshotai/kimi-k2.5)

FAQs

Referenzlinks

1.

[2305.03111] Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 55 % der Fortune 500. Cems Arbeit wurde von führenden globalen Publikationen wie Business Insider, Forbes und der Washington Post, von globalen Unternehmen wie Deloitte und HPE sowie von NGOs wie dem Weltwirtschaftsforum und supranationalen Organisationen wie der Europäischen Kommission zitiert. Weitere namhafte Unternehmen und Ressourcen, die AIMultiple referenziert haben, finden Sie hier. Im Laufe seiner Karriere war Cem als Technologieberater, Technologieeinkäufer und Technologieunternehmer tätig. Über ein Jahrzehnt lang beriet er Unternehmen bei McKinsey & Company und Altman Solon in ihren Technologieentscheidungen. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung. Bei einem Telekommunikationsunternehmen leitete er die Technologiestrategie und -beschaffung und berichtete direkt an den CEO. Darüber hinaus verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von null auf einen siebenstelligen jährlichen wiederkehrenden Umsatz und eine neunstellige Unternehmensbewertung kam. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider gewürdigt. Er ist ein gefragter Redner auf internationalen Technologiekonferenzen. Cem absolvierte sein Studium der Informatik an der Bogazici-Universität und besitzt einen MBA der Columbia Business School.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

Vollständiges Profil anzeigen

Kommentare 1

Teilen Sie Ihre Gedanken

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten

PFJ Rofgowski

Dec 10, 2025 at 20:04

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 .

Antworten

Ekrem Sarı

Feb 10, 2026 at 08:46

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.

Antworten