NL2SQLBench: A Modular Benchmarking Framework for LLM-Enabled NL2SQL Solutions

1. Problemstellung

Die Technologie zur Umwandlung von natürlicher Sprache in SQL (NL2SQL) ermöglicht es Nicht-Experten, relationale Datenbanken abzufragen. Obwohl Large Language Models (LLMs) die Leistung von NL2SQL-Algorithmen erheblich verbessert haben, hinkt die systematische Evaluation hinterher. Es gibt folgende kritische Lücken:

• Fehlende Granularität: Bestehende Benchmarks (wie Spider oder BIRD) bewerten nur das Endergebnis (z. B. Execution Accuracy), nicht aber die Effektivität und Effizienz der einzelnen Kernmodule (Schema Selection, Candidate Generation, Query Revision).
• Vernachlässigte Kosten: Die hohen Rechenkosten und Latenzen durch LLM-Aufrufe werden oft ignoriert, was die praktische Einsatzfähigkeit einschränkt.
• Mängel in den Daten: Es gibt Hinweise auf ungenaue Gold-SQL-Annotationen in bestehenden Datensätzen und zu strenge Evaluierungsregeln, die semantisch äquivalente, aber syntaktisch unterschiedliche SQL-Abfragen fälschlicherweise als falsch bewerten.
• Fehlender Vergleich: Es gibt kein einheitliches Framework, um verschiedene Strategien für einzelne Module unter gleichen experimentellen Bedingungen fair zu vergleichen.

2. Methodik: NL2SQLBench

Die Autoren stellen NL2SQLBench vor, das erste modulare Benchmarking-Framework für LLM-gestützte NL2SQL-Lösungen.

A. Modularer Ansatz

Das Framework zerlegt NL2SQL-Systeme in drei Kernmodule:

1. Schema Selection: Auswahl der relevanten Tabellen und Spalten aus dem Datenbankschema.
2. Candidate Generation: Generierung von Kandidaten-SQL-Abfragen basierend auf der natürlichen Sprache.
3. Query Revision: Verfeinerung der Kandidaten-Abfragen zur Korrektur von Fehlern und zur Optimierung.

B. Neue Metriken

Statt nur das Endergebnis zu betrachten, führen die Autoren feingranulare Metriken pro Modul ein:

• Für Schema Selection: Precision, Recall und F1-Score (getrennt für Tabellen und Spalten).
• Für Candidate Generation:
  • Correct Rate (CR): Anteil korrekt ausgeführter Abfragen.
  • Incorrect Rate (IR): Anteil syntaktisch korrekter, aber semantisch falscher Abfragen.
  • Error Rate (ER): Anteil Abfragen mit Laufzeitfehlern.
  • Pass@k: Wahrscheinlichkeit, dass mindestens eine von $k$ generierten Abfragen korrekt ist.
• Für Query Revision:
  • Correctness Improvement (CI): Wie stark verbessert sich die Genauigkeit?
  • I2C / E2C: Wie viele falsche/fehlerhafte Abfragen werden korrigiert?
  • C2I / C2E: Wie viele ursprünglich korrekte Abfragen werden fälschlicherweise verschlechtert (Regression)?
• Effizienzmetriken: Anzahl der Tokens und Anzahl der LLM-Aufrufe pro Aufgabe.

C. Multi-Agenten-Framework

Das Framework besteht aus drei Agenten:

1. Result Collecting Agent: Sammelt Zwischenergebnisse (Schema, Kandidaten, finale SQL) und Nutzungsstatistiken.
2. Postprocessing Agent: Führt SQL-Abfragen aus, vergleicht Ergebnisse mit dem Gold-Standard und kategorisiert Fehler.
3. Benchmarking Agent: Berechnet die definierten Metriken und erstellt detaillierte Berichte.

3. Experimente und Ergebnisse

Die Autoren evaluierten 10 repräsentative Open-Source-Methoden (z. B. DIN-SQL, MAC-SQL, CHESS, TA-SQL) auf zwei Datensätzen (BIRD und ScienceBenchmark) mit zwei LLMs (DeepSeek-V3 und GPT-4o mini).

Wichtige Erkenntnisse:

• Modulare Leistung:
  • Schema Selection: Multi-Stage Pruning und Preliminary-SQL-Ansätze (z. B. CHESS, TA-SQL) liefern die besten Ergebnisse, sind aber oft teuer. Few-Shot CoT (DIN-SQL) bietet einen guten Kompromiss aus Genauigkeit und Kosten.
  • Candidate Generation: Der dominierende Fehlermodus ist nicht der Syntaxfehler, sondern die semantische Fehlausrichtung (syntaktisch gültig, aber falsche Logik). Die Leistung variiert stark je nach verwendetem LLM und Datensatz.
  • Query Revision: Aktuelle Revision-Strategien verbessern die Genauigkeit nur begrenzt (oft < 26% Verbesserung). Ein Hauptproblem ist, dass Revisionen oft ursprünglich korrekte Abfragen verschlechtern (C2I), ohne die falschen zu beheben.
• Kosten-Nutzen-Abwägung: Methoden, die viele LLM-Aufrufe und Token verbrauchen (z. B. durch Multi-Candidate-Generierung), erreichen zwar höhere Genauigkeit, sind aber für den produktiven Einsatz oft zu teuer und zu langsam. Es gibt keine „One-Size-Fits-All"-Lösung; die beste Methode hängt vom Datensatz und dem LLM ab.
• Pass@k vs. Revision: Die Pass@k-Metriken zeigen ein hohes theoretisches Genauigkeitspotenzial (Upper Bound), das durch die aktuellen Query-Revision-Module jedoch nicht erreicht wird. Das Revision-Modul ist ein Engpass.
• Datenqualitätsprobleme: Die Analyse deckte auf, dass ein signifikanter Teil der Fragen im BIRD-Datensatz mit falschen Gold-SQL-Abfragen versehen ist. Zudem sind die Evaluierungsregeln zu streng (keine Berücksichtigung semantischer Äquivalenz), was die Bewertung von NL2SQL-Systemen verzerrt.

4. Hauptbeiträge

1. Umfassende Übersicht: Detaillierte Analyse der drei Kernmodule und der darin eingesetzten Strategien (Few-Shot, CoT, Pruning, Unit-Tests etc.).
2. Neue Metriken: Einführung eines Satz feingranularer Metriken, die Effektivität und Effizienz einzelner Module isoliert messen.
3. NL2SQLBench Framework: Entwicklung eines flexiblen, Multi-Agenten-Benchmarks, der eine faire und reproduzierbare Evaluation verschiedener Ansätze ermöglicht.
4. Empirische Evaluation: Umfassende Benchmarking-Studie von 10 Methoden, die erhebliche Verbesserungspotenziale sowohl bei der Genauigkeit als auch bei der Recheneffizienz aufzeigt.
5. Kritische Analyse von Benchmarks: Identifikation von Mängeln in bestehenden Datensätzen (fehlerhafte Annotationen, semantische Mehrdeutigkeit) und Vorschläge für robustere Evaluierungsstandards.
6. Praktische Leitfäden: Ableitung konkreter Handlungsempfehlungen für Entwickler, wie sie Engpässe diagnostizieren und Trade-offs zwischen Genauigkeit und Kosten managen können (z. B. adaptive Schema-Auswahl, konservative Revision).

5. Bedeutung und Ausblick

NL2SQLBench füllt eine kritische Lücke in der Forschung, indem es den Fokus von reinem Endergebnis-Vergleich auf eine tiefgehende, modulare Analyse verschiebt. Die Arbeit zeigt, dass die aktuelle NL2SQL-Entwicklung durch ineffiziente Prozesse und mangelhafte Evaluierungsstandards behindert wird.

Die Ergebnisse unterstreichen, dass für den realen Einsatz nicht nur die höchste Genauigkeit, sondern auch die Recheneffizienz entscheidend ist. Zudem fordert die Studie die Community auf, die Qualität von Benchmark-Datensätzen zu verbessern und Evaluierungsregeln zu lockern, um semantische Äquivalenz zu berücksichtigen. Das Framework dient als Referenz für faire Vergleiche und als Leitfaden für die Entwicklung robuster, skalierbarer NL2SQL-Systeme in der Industrie.

Der Code und das Framework sind unter https://github.com/neurdb/NL2SQLBench open-sourced.