AIM-Text-to-SQL-Benchmark: SQL-Genauigkeit bei über 70 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 die SQL, die als erwartete Antwort angegeben wird.
Jedes Modell erreicht eine andere Menge an SQL-Fragen, weil die Bewertung von seinen Datenbankentscheidungen abhängt. Unterschiede in diesen Teilmengen und im Ausführungssetup schränken Vergleiche ein.
Text-to-SQL-Ergebnisse
Opus 5.5 erzielte 87,8 % SQL-Genauigkeit
claude-opus-5.5 stimmte bei 444 von 506 bewerteten Fragen mit dem Referenzergebnis überein. gemini-4-argon folgte mit 78,6 % (407 von 518), dann gemini-3.8-flash mit 77,2 % (342 von 443). Dies waren die drei höchsten SQL-Genauigkeitswerte im Panel mit 79 Modellen. Muse Wonder erzielte 56,4 % (285 von 505). GPT-6.1 Terra erzielte 56,6 % (280 von 495). MiniMax M3.1 Flash erzielte 36,5 % (177 von 485). Kimi K3.1 Pro erzielte 52,3 % (257 von 491).
Der Score schließt falsche Datenbankentscheidungen und als fehlerhaft markierte Referenzen aus. Opus 5.5 verwendete Claude Code. Gemini 4 Argon und Gemini 3.8 Flash verwendeten OpenRouter. Das Ranking spiegelt sowohl die Ausführungsbedingungen als auch Unterschiede bei den Fragen wider, die jedes Modell korrekt geroutet hat.
Drei Pro-Varianten schnitten schlechter ab als ihre Basismodelle
gpt-6.1-sol-pro erzielte 63,6 % SQL-Genauigkeit, verglichen mit 65,1 % für gpt-6.1-sol. gpt-6-sol-pro erzielte 53,6 % gegenüber 53,8 % für gpt-6-sol. gpt-6-luna-pro erzielte 44,2 % gegenüber 45,4 % für gpt-6-luna.
Alle sechs Modelle verwendeten OpenRouter. Diese Werte stammen aus einem Lauf pro Modell und unterschiedlichen Teilmengen korrekt gerouteter Fragen. Wiederholte Läufe mit denselben SQL-Fragen wären erforderlich, um zu bewerten, ob die kleinen Abstände bestehen bleiben.
Kosten vs. SQL-Genauigkeit
Die Laufkosten decken die beibehaltenen Routing- und SQL-Antworten aus dem Benchmark-Lauf jedes Modells ab. Das Ziel waren 759 Fragen. Sieben Läufe haben weniger beibehaltene Antworten. Separate Smoke-Tests, verworfene Wiederholungsversuche und Jury-Aufrufe sind ausgeschlossen. Die SQL-Genauigkeit verwendet die korrekt gerouteten Fragen jedes Modells, nachdem als fehlerhaft markierte Referenzen ausgeschlossen wurden.
gemini-3-flash-preview erzielte 67,7 % SQL-Genauigkeit zu $7,67 pro Lauf. gemini-3.8-flash erreichte 77,2 % zu $26.48. Opus 5.5 erzielte einen 87,8 %-Wert, der mit geschätzten API-äquivalenten Kosten von $188,71 verbunden ist. Gemini 4 Argon erreichte 78,6 % zu $41,41 an beibehaltenen Laufkosten. Muse Wonder erreichte 56,4 % zu $77,44 an beibehaltenen Laufkosten. GPT-6.1 Terra erreichte 56,6 % zu $7,19 an beibehaltenen Laufkosten. MiniMax M3.1 Flash erreichte 36,5 % zu $2,30 an beibehaltenen Laufkosten. Kimi K3.1 Pro erreichte 52,3 % zu $27,14 an beibehaltenen Laufkosten.
Die 76 API-Modelle verwenden verbrauchsabhängige Kosten. Opus 5.5, Fable 5.1 und GPT-6 Astra haben separat gekennzeichnete Schätzungen auf Basis ihrer aufgezeichneten CLI-Tokens und der am 1. Oktober 2026 geprüften OpenRouter-Preise, wobei die aufgezeichnete Cache-Nutzung erhalten bleibt.
Die Kosten umfassen die Datenbankexploration, und die SQL-Scores decken unterschiedliche Frageteilmengen ab. Dieser Vergleich beschreibt daher die Kosten und die Genauigkeit des kombinierten Benchmark-Workflows. Isolierte Kosten für die SQL-Generierung wurden nicht gemessen. Der Agentic-RAG-Benchmark berichtet die Datenbankauswahl separat.
SQL-Genauigkeitsergebnisse
Vor der Referenzprüfung wird die exakte Ergebniskongruenz bei allen korrekt gerouteten Fragen gemessen. Nach der Antwortprüfung werden Antworten, die von der Jury akzeptiert wurden, zusätzlich angerechnet. 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 für Gemini Flash die SQL-Genauigkeit um 8.7 Punkte
Wir wiederholten gemini-3-flash-preview mit den ergänzenden Hinweisen von BIRD. 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 keine gemeinsame Verbesserung für das Panel mit 79 Modellen. Das Hauptpanel hält die Hinweise zurück, da sie auch verraten können, welche Datenbank auszuwählen ist.
Modelle erreichten unterschiedliche Mengen an SQL-Fragen
Die Datenbankentscheidungen 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 schwierigsten 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 Abfrageerstellung mit der Schwierigkeit der Fälle, die in die Bewertung gelangten. Ein kontrollierter SQL-Vergleich würde jedem Modell für dieselben Fragen die richtige Datenbank liefern. Dieses Experiment wurde nicht durchgeführt.
Die Fragenauswahl ist auch beim Vergleich von KI-Benchmarks wichtig, die unterschiedliche Schemata, Hinweise oder Tool-Budgets bereitstellen.
Erkenntnisse aus Referenz- und Antwortprüfung
Die Referenzprüfung kennzeichnete 236 von 759 Abfragen
Fünf Modelle bewerteten jede Referenzabfrage anhand der Frage und der verfügbaren Schemainformationen. Sie sahen keine Kandidatenantwort eines Modells. Eine Mehrheit von mindestens drei markierte 236 Referenzen als fehlerhaft, also 31,1 % des Satzes.
Nach der Prüfung überprüfte der Benchmark-Eigentümer die Markierungen. Unabhängige menschliche Annotatoren haben diese Prüfung nicht wiederholt. Diese Prozentsätze beschreiben die geprüfte Teilmenge. Sie sollten nicht auf den gesamten BIRD-Datensatz verallgemeinert werden.
Äquivalente Antworten brachten 22.7 Punkte zum Score von claude-sonnet-5 hinzu
claude-sonnet-5 bestand 211 von 679 strikt bewerteten Fragen, also 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 den Score auf 71,0 %, eine Steigerung um 39.9 Punkte.
Äquivalente Antworten können die gewünschten Informationen mit einer zusätzlichen Spalte oder einer anderen Projektion zurückgeben. Ein strikter Vergleich kann dieses Ergebnis ablehnen, selbst wenn ein Prüfer es als Antwort auf die Frage akzeptiert. Von der Steigerung stammen 22.7 Punkte aus den Entscheidungen der Jury zu diesen Fällen. Referenzfehler machen die verbleibenden 17.2 Punkte aus.
Text-to-SQL-Benchmark-Methodik
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 abdecken.
Die Modelle erhielten kurze Datenbankbeschreibungen und Werkzeuge zum Auflisten von Tabellen, zum Lesen von Spaltendefinitionen und zum Ausführen von SQL. Jede Frage erlaubte bis zu neun Aufrufe mit Werkzeugen und eine finale Antwort, die gewählte Datenbank und SQL enthielt. Das Schema-Preview-Limit betrug 4.000 Zeichen, und Abfrage-Previews waren 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 ordnungssensitiven Modus für Fragen, die eine geordnete Antwort verlangen. Fehlende, fehlerhafte und nicht ausführbare Kandidatenabfragen erhielten bei ansonsten infrage kommenden, korrekt gerouteten Fragen keine strikte Gutschrift.
Für die 76 OpenRouter-Läufe forderten wir Temperatur 0 an. Neunundfünfzig verwendeten die v3-Tool-Call-Recovery-Schicht, 15 lagen davor, und zwei kombinierten Aufzeichnungen aus beiden Versionen. GPT-6 Astra lief über die Codex-CLI. Opus 5.5 und Fable 5.1 verwendeten Claude Code. Alle drei CLI-Läufe verwendeten mittleren Reasoning-Aufwand. Die Läufe für GPT-6 Luna, Luna Pro, Sol und Sol Pro sowie GPT-5.2 verwendeten OpenRouter. Diese Ausführungsunterschiede verhindern, dass eine Wertlücke allein dem Modell zugeschrieben wird.
Sieben Läufe haben weniger als 759 Fragen abgeschlossen. Fehlende Datensätze fehlen in den Bewertungsnennern. Die Tabelle gibt die tatsächlichen Stichprobengrößen für die Haupt- und Ergänzungswerte an. GPT-6.1 Terra, MiniMax M3.1 Flash und Kimi K3.1 Pro schlossen jeweils alle 759 Fragen über OpenRouter am 27. Oktober ab. Frühere erfolgreiche Antworten wurden über die Messphasen hinweg beibehalten.
SQL-Bewertung
Der Hauptscore 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 nennen diese Metrik ex_gold_clean.
Zwei ergänzende Scores zeigen, wie die Prüfung das Ergebnis verändert:
Vor der Referenzprüfung misst der strikte Score die exakte Übereinstimmung der Ausführung bei allen korrekt gerouteten Fragen. Er schließt Fragen mit markierten Referenzen ein.
Nach der Antwortprüfung fügt der Score eine Gutschrift hinzu, wenn eine separate Jury eine infrage kommende verpasste Antwort akzeptiert. Er verwendet denselben Nenner wie der strikte Score. Die Ergebnisdateien nennen dies adjudizierte Genauigkeit.
Die Stichprobengröße (n) ist die Anzahl der bewerteten Fragen. Der Hauptscore verwendet eine kleinere Teilmenge als die beiden ergänzenden Scores.
Für claude-sonnet-5 reduzierte der Ausschluss markierter Referenzen die akzeptierten Antworten von 211 auf 180 und die bewerteten Fragen von 679 auf 468. Die SQL-Genauigkeit betrug 38,5 %.
Der Ausschluss verändert beide Zählwerte. Die Antwortprüfung behält stattdessen den ursprünglichen Nenner bei und fügt für akzeptierte verpasste Antworten eine Gutschrift hinzu.
Referenz- und Antwortprüfung
Das Prüfen von Referenzen und das Überprüfen von Kandidatenantworten erfordern unterschiedliche Eingaben.
Referenzprüfer waren claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5 und deepseek-v4-pro. Kandidatenantworten wurden zurückgehalten, um die Markierungen unabhängig vom bewerteten Modell zu halten.
Die Antwortadjudikation verwendete drei Juroren aus Modellfamilien, die sich von der des Kandidaten unterschieden. 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. GPT-6.1 Terra, MiniMax M3.1 Flash und Kimi K3.1 Pro hatten für jeden infrage kommenden Fall mindestens zwei gültige Jurorenstimmen. Einzelne fehlgeschlagene Stimmen bleiben in den Prüfprotokollen. Eine abgeschnittene GPT-6.1 Terra-Juryantwort wurde mit einem Ausgabelimit von 4.000 Token vervollständigt, das von 1.200 erhöht wurde. Das Jury-Modell, der Prompt und die Bewertungsregeln blieben unverändert.
Die Prüfabdeckung ist asymmetrisch. Strikte Treffer bleiben akzeptiert, während infrage kommende verpasste Antworten eine weitere Bewertung erhalten. Folglich kann die Adjudikation falsch-positive Ergebnisse aus der strikten Bewertung beibehalten und eigene falsch-positive hinzufügen. Es handelt sich um eine ergänzende Schätzung, die weder garantierte Korrektheit noch eine garantierte Obergrenze für die tatsächliche Genauigkeit bietet.
Ein Fehlversuch kam für die Adjudikation infrage, 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 Kandidatenzeilen, die in der Referenz gefunden wurden, mit dem Anteil der Referenzzeilen, die vom Kandidaten wiederhergestellt wurden.
Zum Beispiel hatte gemini-3.5-flash-lite 346 strikte Fehlversuche. Davon kamen 314 für die Überprüfung infrage. 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 Jury akzeptierte 45,9 % der 314 überprüften Fehlversuche.
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 erneute Prüfung durch unabhängige menschliche Annotatoren ist erforderlich, um beide Fehlerarten abzuschätzen.
Jury-Urteile hängen von der LLM-Interpretation ab. Keine unabhängige menschliche Prüfung hat alle Adjudikationsurteile verifiziert. In der nova-lite-v1-Kontrolle stieg die Genauigkeit von 18,9 % unter strikter Bewertung auf 31,6 % nach der Adjudikation, was zeigt, dass die Prüfung nicht automatisch einen hohen Score 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 Fließkommawerten auf sechs signifikante Stellen können Unterschiede akzeptieren, die von Bedeutung sind.
Frage-Stichprobenintervalle sind für strikte Scores und die SQL-Genauigkeit im Ergebnis-Export verfügbar. Sie lassen die Unsicherheit der Referenzkennzeichnungen, Juryfehler und die Variation zwischen wiederholten SQL-Läufen aus. Hier wird keine SQL-Wiederholungsanalyse berichtet.
Dies sind Ergebnisse für eine ausgewählte, hint-free Arbeitslast mit einer Datenbank-Routing-Anforderung. Sie sind nicht direkt mit der BIRD-Bestenliste vergleichbar. Die öffentlichen Trainingsdaten bergen außerdem das Risiko einer Überlappung der Trainingsdaten, wie im Routing-Artikel erörtert.
Fazit
claude-opus-5.5 führte die SQL-Genauigkeit mit 87,8 % an, gefolgt von gemini-4-argon mit 78,6 % und gemini-3.8-flash mit 77,2 %.
Jeder SQL-Score 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 Jury-Entscheidungen.
Weiterführende Literatur
- Agentic-RAG-Benchmark: Multi-Datenbank-Routing
- 800+ führende KI-Benchmarks
- HALC-Bench: LLM-Halluzination bei 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 70 LLMs}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Abgerufen am 30. Oktober 2026}
}Ergebnisse und Zeitstempel von 1.5 Tausend Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 5 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.