AIM-Text-to-SQL-Benchmark: SQL-Genauigkeit bei über 60+ LLMs
We evaluated SQL answers from 70+ LLMs on a 759-question BIRD-SQL subset. Each model selected a database from 11 candidates, then produced a query.
SQL-Genauigkeit ist der Prozentsatz der bewerteten Abfragen, die das Referenzergebnis zurückgeben. Falsche Routen und als fehlerhaft markierte Referenzen werden ausgeschlossen. Eine Referenzabfrage ist das als erwartete Antwort bereitgestellte SQL.
Jedes Modell erreicht einen anderen Satz von SQL-Fragen, da die Bewertung von seinen Datenbankwahlen abhängt. Unterschiede in diesen Teilmengen und im Ausführungssetup schränken Vergleiche ein.
Text-to-SQL-Erkenntnisse
Opus 5.5 erzielte 87,8 % SQL-Genauigkeit
claude-opus-5.5 erreichte das Referenzergebnis bei 444 von 506 bewerteten Fragen. gemini-3.8-flash folgte mit 77,2 % (342 von 443), dann claude-sonnet-5.5 mit 73,8 % (368 von 499). Dies waren die drei höchsten SQL-Genauigkeitswerte im 72 Modelle umfassenden Panel.
Die Bewertung schließt falsche Datenbankwahlen und als fehlerhaft markierte Referenzen aus. Opus 5.5 lief über Claude Code. Gemini 3.8 Flash und Sonnet 5.5 verwendeten OpenRouter. Die Rangfolge spiegelt sowohl die Ausführungsbedingungen als auch Unterschiede in den Fragen wider, die jedes Modell korrekt geroutet hat.
Gemini 3.7 und 3.8 Flash kehrten die Reihenfolge zwischen Routing und SQL um
gemini-3.7-flash erzielte 85,3 % bei schweren Routing-Fragen und 72,5 % bei der SQL-Genauigkeit. gemini-3.8-flash verzeichnete 69,0 % bzw. 77,2 %.
Die Routing-Genauigkeit deckt hier die schwersten Fragen ab. Die SQL-Genauigkeit umfasst die korrekt gerouteten Fragen jedes Modells über alle Schwierigkeitsgruppen hinweg, nach Ausschluss markierter Referenzen. Die beiden Kennzahlen verwenden unterschiedliche Frageteilmengen.
Der agentische RAG-Benchmark berichtet die Datenbankauswahl separat.
SQL-Genauigkeitsergebnisse
Vor der Referenzprüfung wird die exakte Ergebnisübereinstimmung bei allen korrekt gerouteten Fragen gemessen. Nach der Antwortprüfung wird eine Gutschrift für von der Jury akzeptierte Antworten hinzugefügt. Beide Vergleichsspalten verwenden den ursprünglichen Nenner, während die SQL-Genauigkeit markierte Referenzen ausschließt.
Bedingungen, die SQL-Genauigkeit beeinflussen
BIRDs Hinweise erhöhten Gemini Flashs SQL-Genauigkeit um 8.7 Punkte
Wir wiederholten gemini-3-flash-preview mit BIRDs ergänzenden Hinweisen. Bei Fragen, die in beiden Bedingungen korrekt geroutet wurden, stieg die SQL-Genauigkeit von 67,5 % auf 76,2 %. Die strikte Genauigkeit vor der Referenzprüfung stieg von 55,0 % auf 61,6 %.
Dies war ein Experiment mit einem einzelnen Modell. Es begründet keinen gemeinsamen Anstieg für das 49 Modelle umfassende Panel. Das Hauptpanel hält die Hinweise zurück, da sie auch verraten können, welche Datenbank auszuwählen ist.
Modelle erreichten unterschiedliche Sätze von SQL-Fragen
Die Datenbankwahlen jedes Modells bestimmen, welche Fragen in die SQL-Bewertung gelangen. Für claude-opus-5 enthält der strikte Nenner 717 Fragen, darunter 156 aus der schwersten Routing-Gruppe. Für nova-lite-v1 enthält er 285 Fragen, darunter 22 aus dieser Gruppe. Die Anteile betragen 21,8 % und 7,7 %.
Ihre SQL-Prozentsätze kombinieren daher die Abfrageerstellungsleistung mit der Schwierigkeit der Fälle, die Bewertung erreichten. Ein kontrollierter SQL-Vergleich würde jedem Modell die korrekte Datenbank für dieselben Fragen liefern. Dieses Experiment wurde nicht durchgeführt.
Die Fragenauswahl ist auch wichtig, wenn KI-Benchmarks verglichen werden, die unterschiedliche Schemata, Hinweise oder Tool-Budgets bieten.
Erkenntnisse aus der Referenz- und Antwortprüfung
Die Referenzprüfung markierte 236 von 759 Abfragen
Fünf Modelle bewerteten jede Referenzabfrage anhand ihrer Frage und der verfügbaren Schemainformationen. Sie sahen keine Kandidatenantwort eines Modells. Eine Mehrheit von mindestens drei markierte 236 Referenzen als fehlerhaft, das sind 31,1 % des Satzes.
Nach der Prüfung überprüfte der Benchmark-Eigentümer die Markierungen. Unabhängige menschliche Annotatoren haben diese Überprüfung nicht wiederholt. Diese Prozentsätze beschreiben die geprüfte Teilmenge. Sie sollten nicht auf den gesamten BIRD verallgemeinert werden.
Äquivalente Antworten brachten 22.7 Punkte zusätzlich für claude-sonnet-5s Punktzahl
claude-sonnet-5 bestand 211 von 679 strikt bewerteten Fragen, das sind 31,1 %. Eine Jury akzeptierte weitere 154 Antworten als äquivalent zur Referenz. Diese trugen 22.7 Prozentpunkte bei.
Weitere 117 Antworten erhielten eine Gutschrift, weil die Jury die Abfrage des Modells akzeptierte und die Referenz ablehnte. Diese trugen 17.2 Punkte bei. Together erhöhten die beiden Kategorien die Punktzahl auf 71,0 %, ein Anstieg um 39.9 Punkte.
Äquivalente Antworten können die angeforderte Information mit einer zusätzlichen Spalte oder einer anderen Projektion zurückgeben. Der strikte Vergleich kann dieses Ergebnis ablehnen, selbst wenn ein Prüfer es als Antwort auf die Frage akzeptiert. Von dem Anstieg stammen 22.7 Punkte aus den Entscheidungen der Jury zu diesen Fällen. Referenzfehler machen die verbleibenden 17.2 Punkte aus.
Methodik des Text-to-SQL-Benchmarks
Questions and execution
BIRD-SQL liefert natürlichsprachliche Fragen, SQL-Referenzen und Datenbankinhalte.1 Wir verwendeten eine eingefrorene Auswahl von 759 Fragen aus 11 Datenbanken, die 560 Trainings- und 199 Dev-Beispiele abdeckt.
Die Modelle erhielten kurze Datenbankbeschreibungen und Werkzeuge zum Auflisten von Tabellen, zum Lesen von Spaltendefinitionen und zum Ausführen von SQL. Pro Frage waren bis zu neun Aufrufe mit Werkzeugen und eine abschließende Antwort mit der gewählten Datenbank und dem SQL erlaubt. Das Schema-Vorschau-Limit lag bei 4.000 Zeichen, und Abfragevorschauen wurden auf 50 Zeilen begrenzt.
Die endgültige Kandidatenabfrage und die Referenz wurden gegen dieselbe Datenbankdatei ausgeführt. Die strikte Bewertung verglich ihre Ergebnisse, einschließlich eines ordnungsempfindlichen Modus für Fragen, die eine geordnete Antwort verlangen. Fehlende, fehlerhafte und bei der Ausführung scheiternde Kandidatenabfragen erhielten keine strikte Gutschrift für ansonsten infrage kommende, korrekt geroutete Fragen.
Für die 46 OpenRouter-Läufe forderten wir Temperatur 0 an. Neunundzwanzig nutzten die v3-Werkzeugaufruf-Wiederherstellungsschicht, 15 lagen davor, und zwei kombinierten Datensätze aus beiden Versionen. GPT-6 Astra lief über Codex CLI. Opus 5.5 und Fable 5.1 verwendeten Claude Code. Alle drei CLI-Läufe nutzten mittleren Reasoning-Aufwand. Die Läufe mit GPT-6 Luna, Luna Pro, Sol und Sol Pro sowie GPT-5.2 verwendeten OpenRouter. Diese Ausführungsunterschiede verhindern, dass eine Punktelücke allein dem Modell zugeschrieben werden kann.
Sieben Läufe schlossen weniger als 759 Fragen ab. Fehlende Datensätze fehlen in den Bewertungsnennern. Die Tabelle gibt die tatsächlichen Stichprobengrößen für die Haupt- und Zusatzwerte an. Die zehn API-Ergänzungen schlossen nach Wiederholungen fehlgeschlagener Anfragen jeweils alle 759 Fragen ab und behielten frühere erfolgreiche Antworten bei.
SQL-Bewertung
Der Hauptwert schließt markierte Fragen sowohl aus dem Zähler als auch aus dem Nenner aus. Drei als unsicher markierte Referenzen bleiben in der Berechnung. Die Ergebnisdateien bezeichnen diese Kennzahl als ex_gold_clean.
Zwei ergänzende Werte zeigen, wie die Prüfung das Ergebnis verändert:
Vor der Referenzprüfung misst der strikte Wert die exakte Ausführungsübereinstimmung bei allen korrekt gerouteten Fragen. Er umfasst auch Fragen mit markierten Referenzen.
Nach der Antwortprüfung fügt der Wert eine Gutschrift hinzu, wenn eine separate Jury eine infrage kommende verpasste Antwort akzeptiert. Er verwendet denselben Nenner wie der strikte Wert. Die Ergebnisdateien nennen dies adjuzierte Genauigkeit.
Die Stichprobengröße (n) ist die Zahl der bewerteten Fragen. Der Hauptwert verwendet eine kleinere Teilmenge als die beiden ergänzenden Werte.
Bei claude-sonnet-5 reduzierte der Ausschluss markierter Referenzen die akzeptierten Antworten von 211 auf 180 und die bewerteten Fragen von 679 auf 468. Seine SQL-Genauigkeit betrug 38,5 %.
Der Ausschluss verändert beide Zählungen. Die Antwortprüfung behält stattdessen den ursprünglichen Nenner bei und fügt Gutschrift für akzeptierte Fehlversuche hinzu.
Referenz- und Antwortprüfung
Die Prüfung von Referenzen und die Überprüfung von Kandidatenantworten erfordern unterschiedliche Eingaben.
Die Referenzprüfer waren claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5 und deepseek-v4-pro. Die Kandidatenantworten wurden zurückgehalten, um die Markierungen unabhängig vom bewerteten Modell zu halten.
Die Antwort-Adjudizierung verwendete drei Juroren aus Modellfamilien, die sich von der des Kandidaten unterscheiden. Die Referenz- und Kandidatenabfragen erschienen in randomisierten A/B-Positionen ohne Beschriftungen, die ihre Rollen verraten. Mehrdeutige Fälle und Fälle mit unzureichenden gültigen Stimmen erhielten keine zusätzliche Gutschrift.
Die Prüfabdeckung ist asymmetrisch. Strikte Bestehen bleiben akzeptiert, während infrage kommende Fehlversuche eine erneute Bewertung erhalten. Folglich kann die Adjudizierung falsch positive Ergebnisse aus der strikten Bewertung beibehalten und eigene falsch positive hinzufügen. Sie ist eine ergänzende Schätzung, weder mit garantierter Korrektheit noch mit einer garantierten Obergrenze für die tatsächliche Genauigkeit.
Ein Fehlversuch qualifizierte sich für die Adjudizierung, wenn die Kandidatenabfrage ausgeführt wurde und die F1-Überlappung zwischen ihren Ergebniszeilen und der Referenz unter 0.5 lag. F1 kombiniert den Anteil der in der Referenz gefundenen Kandidatenzeilen mit dem Anteil der vom Kandidaten wiedergefundenen Referenzzeilen.
Zum Beispiel hatte gemini-3.5-flash-lite 346 strikte Fehlversuche. Davon qualifizierten sich 314 für die Überprüfung. Die Jury akzeptierte den Kandidaten in 144 Fällen: 92 mit abgelehnter Referenz und 52 mit beiden akzeptierten Antworten. Sie klassifizierte 105 als Modellfehler und ließ 65 mehrdeutig. Die übrigen 32 Fehlversuche umfassten 27 mit höherer Ergebnisüberlappung und fünf Ausführungsfehler.
Die 144 akzeptierten Fälle sind 45,9 % der überprüften Fehlversuche, nicht aller fehlgeschlagenen Antworten.
Als bevorzugte Quelle hinzufügenEinschränkungen
Referenzfehler bleiben unsicher. Die Prüfung mit fünf Modellen untersuchte Spalten aus Tabellen, die von jeder Referenzabfrage verwendet wurden, sodass sie eine Antwort in einer anderen Tabelle übersehen kann. Die Prüfung kann auch eine gültige Referenz ablehnen. Eine wiederholte Überprüfung durch unabhängige menschliche Annotatoren ist erforderlich, um beide Fehlerarten zu schätzen.
Die Urteile der Jury hängen von der Interpretation durch LLM ab. Keine unabhängige menschliche Überprüfung verifizierte alle Adjudikationsurteile. In der nova-lite-v1-Kontrolle stieg die Genauigkeit von 18,9 % unter strikter Bewertung auf 31,6 % nach der Adjudizierung, was zeigt, dass die Überprüfung nicht automatisch eine hohe Punktzahl erzeugte. Diese Kontrolle allein kann die Genauigkeit der Jury nicht belegen.
Der strikte Vergleich kann in beide Richtungen fehlschlagen. Zusätzliche Spalten oder eine andere Spaltenreihenfolge können eine nützliche Antwort ablehnen. Die Normalisierung der Groß-/Kleinschreibung und das Runden von Gleitkommawerten auf sechs signifikante Stellen können Unterschiede akzeptieren, die von Bedeutung sind.
Fragenstichprobenintervalle sind für strikte Werte und die SQL-Genauigkeit im Ergebnisexport verfügbar. Sie lassen die Unsicherheit der Referenzkennzeichnung, Juryfehler und Schwankungen zwischen wiederholten SQL-Läufen außer Acht. Hier wird keine wiederholte SQL-Analyse berichtet.
Dies sind Ergebnisse für eine ausgewählte, hinweis-free Arbeitslast mit einer Datenbank-Routing-Anforderung. Sie sind nicht direkt mit der BIRD-Bestenliste vergleichbar. Die öffentlichen Trainingsdaten bergen zudem ein Risiko der Überlappung mit Trainingsdaten, wie im Routing-Artikel erörtert.
Fazit
claude-opus-5.5 führte bei der SQL-Genauigkeit mit 87,8 %, gefolgt von gemini-3.8-flash mit 77,2 % und claude-sonnet-5.5 mit 73,8 %.
Jeder SQL-Wert spiegelt die Fragen wider, die das Modell korrekt geroutet hat, sowie die nach der Prüfung beibehaltenen Referenzen. Ein kontrollierter SQL-Vergleich würde jedem Modell dieselben Fragen und Datenbankinformationen geben, mit unabhängigen Prüfungen der Referenzkennzeichnungen und Juryentscheidungen.
Weiterführende Literatur
- Agentischer RAG-Benchmark: Multi-Datenbank-Routing
- 800+ Führende KI-Benchmarks
- HALC-Bench: LLM-Halluzination beim Long-Context-Retrieval-Benchmark
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{sari2026,
author = {Sarı, Ekrem},
title = {{AIM-Text-to-SQL-Benchmark: SQL-Genauigkeit bei über 60+ LLMs}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Abgerufen am 1. Oktober 2026}
}Ergebnisse und Zeitstempel von 1.4 Tausend Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 4 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
9 AktualisierungenText-to-SQL-Benchmarkergebnisse durch ein 36-Modell-Panel mit strict-, gold-clean- und adjudicated-Execution-Match-Bewertung ersetzt.
Ein Änderungsprotokoll wurde zum Abschnitt „Agentic RAG Benchmark: Multi-Datenbank-Routing und Abfragegenerierung“ hinzugefügt.
Der Methodik-Abschnitt wurde durch eine Zusammenfassung und einen Verweis auf einen anderen Artikel ersetzt.
Referenzlinks
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.