Text-to-SQL: Vergleich der LLM-Genauigkeit

Ich setze seit 18 Jahren SQL für die Datenanalyse ein, beginnend in meiner Zeit als Berater. Die Übersetzung von Fragen in natürlicher Sprache in SQL macht Daten zugänglicher und ermöglicht es jedem, auch Personen ohne technische Fähigkeiten, direkt mit Datenbanken zu arbeiten.

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

Häufige Fehler bei von LLM generiertem SQL

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

Fehlerhafte Join-Logik

Modelle hatten oft Schwierigkeiten, die erforderlichen `JOIN`-Operationen zwischen Tabellen korrekt zu identifizieren und umzusetzen, wobei sie diese manchmal ganz wegließen oder weniger optimale Unterabfragen missbrauchten.

Der LLM konnte die `frpm`- und `schools`-Tabellen nicht korrekt über den `CDSCode` verknüpfen. Er halluzinierte zudem Spaltennamen (`Charter`) und Filterwerte (`County = ‘Fresno’`).

Fehler in der Join-Logik zerstören grundlegend den relationalen Aspekt der Abfrage und führen bei der Einbeziehung mehrerer Tabellen zu unvollständigen oder falschen Datenabrufen.

Aggregations- und Gruppierungsfehler

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

Der LLM erkannte korrekt, dass der Ausdruck „höchster Durchschnittswert“ eine Gruppierung der Daten nach Bezirk (GROUP BY dname) und die Verwendung einer Aggregatfunktion (AVG(AvgScrRead)) erfordert. Dieser Teil der Logik ist korrekt.

Der LLM versäumte es jedoch, einen kritischen Filter aus der Frage zu integrieren: das Wort „aktiv“. Um diese Anforderung zu erfüllen, musste die Abfrage die Tabelle `satscores` mit der Tabelle `schools` verknüpfen (JOIN) und die Ergebnisse dann mit einer `WHERE T1.StatusType = 'Active'`-Klausel filtern.

Dies verdeutlicht einen häufigen LLM-Fehler: die korrekte Ausführung einer primären, offensichtlichen Anweisung (Berechnung eines Durchschnitts), während eine sekundäre, aber ebenso wichtige Bedingung (Filterung 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, erforderliche `WHERE`-Klauseln einzufügen oder die falschen Spalten in der `SELECT`-Anweisung auszuwählen, wodurch die im Prompt explizit angeforderten Einschränkungen oder Informationen nicht vollständig adressiert wurden.

Der LLM erkannte die Logik zur Ermittlung der Schule korrekt (`ORDER BY NumGE1500 DESC LIMIT 1`), versäumte es jedoch, die angeforderte `Phone`-Nummer auszuwählen und die notwendige Verknüpfung mit der `schools`-Tabelle zum Abruf zu unterlassen.

Diese Fehler resultieren oft aus einer unvollständigen Analyse der Benutzeranfrage oder dem Versäumnis, alle Teile der Anfrage auf die endgültigen SQL-Abfragekomponenten abzubilden.

Syntaxfehler

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

Der LLM verwendete falsche Aliasse (`accounts` statt `account`) und enthielt einen unvollständigen String-Literal (`’POPLATEK PO OBRATU…’`), was zu einer ungültigen SQL-Syntax führte.

Diese Syntaxprobleme verdeutlichen Herausforderungen bei der Generierung von Code, der strikt der SQL-Grammatik und datenbankspezifischen Konventionen folgt.

Warum einige LLMs besser in SQL sind

Einige Schlüsselfaktoren bestimmen, wie gut ein LLM (LLM) eine einfache Frage in englischer Sprache 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 Daten, mit denen der LLM trainiert wurde, sind entscheidend. Wenn er viele Beispiele für Fragen sieht, die mit SQL-Antworten verknüpft sind, insbesondere solche, die komplexe Operationen wie Joins oder Berechnungen (SUM, AVG) beinhalten, wird er wahrscheinlich besser abschneiden.

2. Feinabstimmung für SQL-Aufgaben

• Modelle können zusätzliches Training erhalten, das speziell auf Text-to-SQL-Aufgaben ausgerichtet ist. Diese „Feinabstimmung" hilft ihnen, Datenbankstrukturen und SQL-Regeln effektiver zu verstehen als Modelle, die nur auf allgemeinen Texten trainiert wurden. Training mit spezifischen Anweisungen hilft ebenfalls.

3. Schlussfolgerungs- und Schema-Mapping-Fähigkeiten

• Schlussfolgerung: Wie gut kann der LLM die genauen Schritte ermitteln, die für eine manchmal vage Frage erforderlich sind? Die Erstellung von SQL erfordert oft logische Schritte.
• Verstehen der Datenbankkarte (Schema): Einige 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, selbst wenn die Namen nicht sofort offensichtlich sind.

Wie LLMs SQL generieren: Ein Schritt-für-Schritt-Einblick

Um Faktoren wie „Schlussfolgerung" und „Schema-Mapping" in Aktion zu sehen, gehen wir den schrittweisen Prozess durch, den ein Modell zur Generierung einer Abfrage durchläuft. Dieser gesamte Workflow wird durch eine Technik namens Retrieval-Augmented Generation (RAG) angetrieben.

Phase 1: Initiale Analyse und Datenbankauswahl

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

• Frage: „Wie viele Konten haben eine Inhaber-Disposition und eine Anfrage zur Generierung eines Auszugs bei einer Transaktion?"
• LLM-Aktion: Das Modell identifiziert Schlüsselwörter wie „accounts", „disposition" und „transaction". Es kommt zu dem Schluss, dass das financial-Datenbanktool die richtige Wahl ist im Vergleich zu anderen wie california_schools oder superhero.

Phase 2: Abruf des Schemas über RAG

Sobald das Modell ein Tool ausgewählt hat, benötigt es die „Karte" der Datenbank, das Schema. Diese Informationen sind nicht im Gedächtnis gespeichert. Stattdessen wird das RAG-System diese Informationen in Echtzeit abrufen.

1. Abruf: Die Frage des Benutzers wird verwendet, um eine Vektordatenbank zu durchsuchen, die Schema-Informationen speichert. Die Suche findet und ruft die relevantesten Schema-Details ab, wie z. B. die Definitionen für die accounts- und disp-Tabellen.
2. Erweiterung: Dieser abgerufene Schema-Text wird automatisch zusammen mit der ursprünglichen Frage in den Prompt eingefügt.
3. Generierung: Der LLM hat nun den gesamten Kontext, den er für die Fortsetzung benötigt.

Dieser RAG-Prozess stellt sicher, dass das Modell nur die erforderlichen Schema-Informationen erhält, was seine Aufgabe fokussierter und effizienter macht.

Phase 3: Schlussfolgerung und Abfrageerstellung

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.

Interne Monolog des LLM:

1. Ziel: Der Benutzer möchte eine Anzahl, also beginne ich mit SELECT COUNT(...).
2. Bedingungen:
   • „…Inhaber-Disposition…" -> Das disp-Tabellenschema hat eine type-Spalte. Ich benötige eine WHERE-Klausel für type = 'OWNER'.
   • „…Auszug zur Generierung bei einer Transaktion…" -> Das accounts-Tabellenschema hat eine frequency-Spalte. Der Filter sollte frequency = 'POPLATEK PO OBRATU' sein.
3. Joins: Die Informationen sind auf die accounts- und disp-Tabellen aufgeteilt. Das Schema zeigt, dass sie durch account_id verknüpft sind, also muss ich sie JOIN.

Phase 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:

1. Schlussfolgerungsfähigkeit: Die Fähigkeit des Modells, die Benutzeranfrage logisch mit dem bereitgestellten Schema zu verknüpfen.
2. 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 abgebildet werden kann, muss der LLM eine fundierte Vermutung anstellen, was zu den Fehlern führen kann, die wir zuvor analysiert haben.

Was ist Text-to-SQL?

Text-to-SQL ist eine Technologie zur Verarbeitung natürlicher Sprache, die Alltagssprache in eine SQL-Abfrage in strukturierter Abfragesprache umwandelt. Anstatt manuell SQL-Code zu schreiben, stellt ein Benutzer eine Frage in natürlicher Sprache, und das System generiert eine SQL-Anweisung, die in 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 schreiben müssen, zu verringern. Dies ist besonders relevant für nicht-technische Benutzer und Datenanalysten, die den Geschäftskontext verstehen, aber möglicherweise nicht mit dem Schreiben von SQL-Syntax von Grund auf vertraut sind.

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."

Das System übersetzt diese Anfrage in eine generierte SQL-Abfrage, die die richtigen Spalten auswählt, Zeilen unter Verwendung von 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 für folgende Bereiche angemessen gut:

• Erstellung von Entwurfsabfragen, die Datenanalysten überprüfen und anpassen können.
• Unterstützung der explorativen Datenanalyse, bei der Geschwindigkeit wichtiger ist als Präzision.
• Ermöglichung des Zugriffs nicht-technischer Benutzer auf einfache Daten über vordefinierte Schemata.
• Unterstützung von SQL-Benutzern durch Verringerung des Bedarfs, wiederholte Abfragen zu schreiben.

In diesen Fällen fungiert Text-to-SQL als unterstützendes KI-Tool und nicht als autonomes System. Die menschliche Überprüfung bleibt Teil des Workflows, insbesondere wenn Korrektheit wichtig ist.

Wie funktioniert Text-to-SQL?

Moderne Text-to-SQL-Systeme basieren auf großen Sprachmodellen, die auf Paaren von Fragen in natürlicher Sprache 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:

• Identifizierung dessen, wonach der Benutzer fragt (z. B. Summen, Filter, Vergleiche)
• Extrahieren relevanter Bedingungen wie Zeiträume, Standorte oder Kategorien
• Interpretieren mehrdeutiger Phrasen, die möglicherweise Geschäftskontext erfordern

Fehler in diesem Stadium führen häufig zu einer korrekt aussehenden SQL-Abfrage, die die falsche Frage beantwortet.

Schema-Mapping

Danach ordnet das System Begriffe aus der Frage dem Datenbankschema zu. Dies umfasst:

• Abgleichen von Konzepten in der Frage mit Tabellennamen und Spalten
• Verstehen von Beziehungen zwischen Tabellen
• Einhaltung von Datentypen wie Daten, numerischen Feldern oder Kategorien

Das Schema-Mapping wird schwieriger, wenn die Anzahl der Tabellen zunimmt oder wenn Spaltennamen nicht eng mit der Art und Weise übereinstimmen, wie Benutzer Daten in Fragen in natürlicher Sprache beschreiben.

SQL-Abfrageerstellung

Sobald Absicht und Schema-Elemente identifiziert sind, erstellt das System die SQL-Abfrage. Dies kann beinhalten:

• Auswählen der richtigen Tabellen und Spalten
• Hinzufügen von Joins über alle erforderlichen Tabellen hinweg
• Anwenden von Filtern, Aggregationen und Gruppierungslogik
• Erstellen syntaktisch gültigen SQL-Codes für Systeme wie MySQL oder PostgreSQL

In diesem Stadium kann das System leicht gültige, aber logisch falsche SQL-Anweisungen erzeugen, beispielsweise 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 versuchen, eine begrenzte Optimierung durchzuführen oder Nachfragen 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 zeigt die reale Nutzung mehrere Einschränkungen, die nicht ignoriert werden können.

Zuverlässigkeit und Korrektheit

Sogar leistungsstarke Modelle scheitern daran, für einen signifikanten Anteil komplexer Abfragen korrektes SQL zu erzeugen. Eine Fehlerrate von 20 % oder höher bedeutet:

• Ein von fünf generierten Abfragen kann irreführende Ergebnisse zurückgeben
• Fehler sind oft semantischer und nicht syntaktischer Natur
• Falsche Joins, Filter oder Aggregationen können unbemerkt bleiben

Dies ist besonders riskant bei Berichten, Prognosen 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:

• Benutzer können einer falschen Abfrage vertrauen, weil sie erfolgreich ausgeführt wird
• Fehler können sich in Dashboards, Berichten oder nachgelagerten Systemen ausbreiten
• Die Verantwortlichkeit wird unklar, wenn Entscheidungen auf KI-generierten Ausgaben basieren

Text-to-SQL beseitigt nicht den Bedarf an SQL-Expertise; es verlagert nur, wo diese Expertise angewendet wird.

Komplexitätsgrenze

Mit zunehmender Komplexität der Abfrage sinkt die Leistung stark. Modelle haben Schwierigkeiten mit:

• Mehreren Joins über viele Tabellen hinweg
• Geschachtelter Logik und Unterabfragen
• Domänenspezifischen Berechnungen
• Abfragen, die tiefes Wissen über das Datenbankschema erfordern

Benchmarks wie BIRD-SQL zeigen, dass komplexe Abfragen auch für fortschrittliche Modelle der Hauptfehlerpunkt bleiben.

Modellvariabilität

Leistungsunterschiede zwischen Modellen sind signifikant. Einige Sprachmodelle schneiden angemessen gut ab, während andere häufig beim selben Datensatz versagen. Dies bedeutet:

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

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

Datengovernance und Datenschutz

Text-to-SQL-Systeme bringen zusätzliche Zugriffsrisiken mit sich:

• Benutzer können sensible Tabellen abfragen, ohne die Implikationen zu verstehen
• Generiertes SQL kann Metadaten über das Datenbankschema offenlegen
• Datenschutzkontrollen müssen außerhalb des Sprachmodells durchgesetzt werden

Ohne starke Zugriffskontrollen kann Text-to-SQL bestehende Governance-Praktiken schwächen.

Entdecken Sie weitere unserer Benchmarks und datengestützten Erkenntnisse in der Google-Suche.

Als bevorzugte Quelle hinzufügen

Benchmark-Methodik für Text-to-SQL

Dieser Benchmark teilt sich sein Evaluierungsframework mit unserem agentic RAG-Benchmark, der die Datensatzerstellung, Agentenarchitektur, Herausforderung der semantischen Mehrdeutigkeit und das vollständige Bewertungsraster im Detail beschreibt.

Beide Benchmarks verwenden denselben 500-Fragen-BIRD-SQL¹ -Teilbereich, agentic Pipeline, ChromaDB-unterstützte Schema-Abruf und LLM-als-Richter-Evaluierung 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 geleitet hat 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 bewertet.

Weiterführende Literatur

Entdecken Sie weitere RAG-Benchmarks, wie:

• Embedding-Modelle: OpenAI vs Gemini vs Cohere
• Top Vector-Datenbank 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

Änderungsprotokoll

20. April 2026

1 neues Modell zum Benchmark hinzugefügt:

• Anthropic: Claude Opus 4.7 (anthropic/claude-opus-4.7)

20. Februar 2026

2 neue Modelle zum Benchmark hinzugefügt:

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

10. Februar 2026

2 neue Modelle zum Benchmark hinzugefügt:

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

FAQs

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 LLM-Genauigkeit}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Abgerufen am 30. Juni 2026}
}

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. Kommentare werden in ihrer Originalsprache belassen.

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