🤖 AI

Agent-Agnostic Evaluation of SQL Accuracy in Production Text-to-SQL Systems

Dieser Beitrag stellt STEF vor, ein schemaneutrales Evaluierungsframework, das eine kontinuierliche, produktionsnahe Überwachung von Text-to-SQL-Systemen ermöglicht, indem es interpretierbare Genauigkeitswerte aus natürlichen Spracheingaben und generierten SQL-Abfragen erzeugt, ohne dass Datenbankschemata oder Ground-Truth-Abfragen erforderlich sind.

Ursprüngliche Autoren: Taslim Jamal Arif, Kuldeep Singh

Veröffentlicht 2026-05-01

📖 5 Min. Lesezeit🧠 Tiefgang

CC0 1.0

Ursprüngliche Autoren: Taslim Jamal Arif, Kuldeep Singh

Originalarbeit unter CC0 1.0 der Gemeinfreiheit gewidmet (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen sehr intelligenten Roboter-Assistenten, der „Human" spricht (wie „Zeigen Sie mir die Umsätze des letzten Jahres") und dies in „Datenbank-Sprache" (SQL-Code) übersetzt, um Informationen aus den Aufzeichnungen eines Unternehmens zu beziehen.

Das große Problem, das diese Arbeit angeht, lautet: Wie wissen Sie, ob der Roboter eine gute Arbeit leistet, wenn er für echte Menschen in einem echten Unternehmen arbeitet?

Der alte Weg: Das „Lösungsschlüssel"-Problem

In der Vergangenheit nutzten Forscher zur Prüfung dieser Roboter eine Methode, die dem Bewerten eines Mathe-Tests mit einem Lösungsschlüssel glich.

Das Szenario: Sie geben dem Roboter eine Frage, er liefert eine Antwort, und Sie vergleichen sie mit einer „Goldstandard"-Antwort, die von einem menschlichen Experten verfasst wurde.
Der Fehler: In der realen Welt haben Sie keinen Lösungsschlüssel für jede einzelne Frage, die ein Kunde stellt. Zudem ist die Datenbank des Unternehmens oft geheim, verändert sich ständig oder ist zu komplex, um sie mit dem Testteam zu teilen.
Das Ergebnis: Sobald der Roboter in einem echten Büro eingesetzt wird, weiß niemand, ob er im Laufe der Zeit schlechter wird. Es ist wie das Fahren mit einem kaputten Tacho; Sie merken nicht, ob Sie zu schnell fahren, bis Sie einen Unfall bauen.

Die neue Lösung: STEF (Der „intelligente Übersetzer"-Prüfer)

Die Autoren haben ein neues System namens STEF (Schema-agnostisches Text-zu-SQL-Evaluierungsframework) entwickelt. Stellen Sie sich STEF als einen superintelligenten Redakteur vor, der weder das Originalbuch noch die Datenbank benötigt, um zu prüfen, ob die Übersetzung gut ist.

So funktioniert STEF, unter Verwendung einfacher Analogien:

1. Die „Kein-Referenz"-Regel

STEF benötigt weder die „Goldstandard"-Antwort noch die Datenbankkarte. Es betrachtet nur drei Dinge:

Was der Mensch gefragt hat.
Wie der Roboter diese Frage intern umformuliert hat.
Den Code, den der Roboter geschrieben hat.
Es ist wie ein Übersetzer, der prüft, ob ein französischer Satz auf Englisch Sinn ergibt, ohne den ursprünglichen spanischen Quelltext zu kennen.

2. Die „Zerlegung" (Die Suppe auseinandernehmen)

Anstatt den Code einfach Zeichen für Zeichen zu vergleichen (was so wäre, als würde man prüfen, ob zwei Sätze exakt dieselben Buchstaben haben), zerlegt STEF die Anfrage in Zutaten:

Wonach suchen wir? (Die Spalten)
Was zählen oder addieren wir? (Die Mathematik)
Was filtern wir aus? (Der Teil „nur aktive Benutzer anzeigen")
Wie gruppieren wir es? (Nach Land, nach Jahr usw.)

STEF prüft, ob der Roboter die richtigen Zutaten enthalten hat. Wenn der Mensch nach „Aktiven Benutzern" fragte und der Roboter vergaß, die „Inaktiven" herauszufiltern, erkennt STEF das fehlende Element sofort.

3. Der „menschliche" Richter (Das LLM)

STEF nutzt eine andere KI (einen „Richter"), um die Zutaten zu betrachten und zu entscheiden: „Beantwortet dieser Code tatsächlich die Frage?"

Der Konfidenzwert: Der Richter sagt nicht einfach nur „Ja" oder „Nein". Er sagt: „Ich bin zu 90 % sicher, dass dies richtig ist" oder „Ich bin nur zu 50 % sicher".
Die Strafe: Wenn der Richter unsicher ist, erhält die Endpunktzahl eine kleine Strafe. Dies verhindert, dass dem System eine perfekte Punktzahl für eine Vermutung verliehen wird.

4. Die „Realitätsnahe" Regel (Normalisierung)

Dies ist der cleverste Teil. In der realen Welt fügen Roboter manchmal zusätzliche Schritte hinzu, die tatsächlich hilfreich und nicht falsch sind. STEF weiß das.

Die „Sortier"-Regel: Wenn ein Roboter die Ergebnisse von höchstem zu niedrigstem Wert sortiert (auch wenn der Mensch dies nicht gefragt hat), sagt STEF: „Das ist eine nette Geste, kein Fehler."
Die „Sicherheit"-Regel: Wenn ein Roboter eine Begrenzung hinzufügt wie „Zeigen Sie mir die Top-10.000-Ergebnisse", nur um zu verhindern, dass der Computer abstürzt, sagt STEF: „Gut gemacht, das ist sicher", anstatt „Falsch, Sie haben nicht nach 10.000 gefragt."
Die „Gruppier"-Regel: Wenn die Mathematik eine Gruppierung der Daten erfordert, um Sinn zu ergeben, akzeptiert STEF dies, auch wenn der Mensch nicht ausdrücklich „nach Gruppen sortieren" gesagt hat.

5. Die „Unternehmensspezifische" Anpassung (Das Regelbuch)

Jedes Unternehmen ist anders. Ein Unternehmen könnte eine Spalte „Region" nennen, während ein anderes sie „Gebiet" nennt.
STEF verfügt über ein konfigurierbares Regelbuch. Sie können STEF sagen: „Hey, in diesem Unternehmen bedeuten 'Region' und 'Gebiet' dasselbe" oder „Ignorieren Sie immer den 'Status'-Filter, da er automatisch hinzugefügt wird." Dies ermöglicht es STEF, sich an jedes Unternehmen anzupassen, ohne neu programmiert werden zu müssen.

Die Endpunktzahl

STEF gibt eine Punktzahl von 0 bis 100 aus.

90–100: Ausgezeichnet. Der Roboter ist einsatzbereit.
50–75: Marginal. Der Roboter rät zu viel; Menschen sollten ihn überprüfen.
Unter 50: Schlecht. Der Roboter versagt und benötigt sofortige Hilfe.

Warum das wichtig ist

Vor STEF flogen Unternehmen mit ihren KI-Assistenten blind. Sie konnten nicht feststellen, ob die KI langsam dümmer wurde oder ob sie gefährliche Fehler machte. STEF fungiert als kontinuierlicher Gesundheitsmonitor für diese KI-Agenten. Es ermöglicht Unternehmen, Probleme zu beheben, bevor sie echte Geschäftsentscheidungen beeinflussen, und das alles, ohne in die geheime Datenbank hineinzuschauen oder für jede Frage neue Lösungsschlüssel zu schreiben.

1. Problemstellung

Das Papier adressiert eine kritische Lücke beim Einsatz von Text-to-SQL (T2SQL)-Systemen in Produktionsumgebungen. Während akademische Benchmarks (z. B. Spider, BIRD) für die Evaluierung auf Ground-Truth-SQL-Abfragen und feste Datenbankschemata zurückgreifen, stehen reale Produktionssysteme vor anderen Herausforderungen:

Keine Ground Truth: Benutzerabfragen treffen dynamisch ein, ohne vorab annotierte „Goldstandard"-SQL-Abfragen.
Schema-Abhängigkeit: Produktionsdatenbanken sind oft proprietär, multi-tenant oder unterliegen häufigen Schema-Änderungen, was den statischen Schema-Zugang zu einem Risiko macht.
Evaluierungsvakuum: Ohne Referenzabfragen oder Schema-Zugriff können Entwickler nach dem Deployment die Genauigkeit nicht systematisch überwachen, Qualitätsverschlechterungen erkennen oder Agenten-Versionen vergleichen. Dies führt zu einer „stille Qualitätskorrosion", bei der Fehler unentdeckt bleiben.

Bestehende Methoden (String-Matching oder ausführungsbasierte Genauigkeit) versagen in diesem Kontext, da sie Referenzabfragen oder einen live abfragbaren Datenbank-Snapshot erfordern, die in Unternehmensumgebungen oft nicht verfügbar oder unpraktisch sind.

2. Methodik: Das STEF-Framework

Die Autoren schlagen STEF (Schema-agnostic Text-to-SQL Evaluation Framework) vor, ein produktionsnahes System, das T2SQL-Agenten unter Verwendung ausschließlich natürlicher Spracheingaben und der generierten SQL-Abfrage bewertet, ohne Datenbankschemata oder Referenzabfragen zu benötigen.

Das Framework arbeitet durch eine Pipeline aus fünf Stufen:

A. Eingabespezifikation

STEF akzeptiert vier Eingaben pro Abfrage-Instanz:

$Q_u$ : Die ursprüngliche Benutzerfrage.
$Q_e$ : Die vom Agenten angereicherte/neu formulierte Frage (Ausgabe der Vorverarbeitung).
$S$ : Die generierte SQL-Abfrage.
$R_{app}$ : Eine JSON-Konfiguration für anwendungsspezifische Regeln (z. B. Spaltenzuordnungen, harmlose Filter).

B. Semantische Merkmalsextraktion und Normalisierung

Das System extrahiert strukturierte semantische Spezifikationen sowohl aus der natürlichen Sprache ( $Q_u, Q_e$ ) als auch aus dem SQL ( $S$ ) unabhängig voneinander.

Dimensionen: Es zerlegt Abfragen in Projektionen (Spalten), Aggregationen (SUM, AVG), Filter (WHERE-Klauseln) und Gruppierungen (GROUP BY).
Normalisierung: Um Variationen in der Oberflächenform zu handhaben, normalisiert STEF Daten während der Extraktion:
- Auflösen von SQL-Aliases zu semantischen Bedeutungen.
- Normalisieren von Filterwerten (Groß-/Kleinschreibung, Leerzeichen).
- Abbilden natürlicher Sprachbegriffe (z. B. „total") auf SQL-Funktionen (z. B. SUM).
- Anwenden anwendungsspezifischer Spaltenzuordnungen aus $R_{app}$ .

C. Spezifikationsausrichtung und Filterklassifizierung

Die extrahierten Merkmale werden ausgerichtet, um den Filter-Ausrichtungsstatus zu bestimmen. Das System klassifiziert die Ausrichtung in vier Kategorien:

Vollständig angewendet: Alle erforderlichen Filter vorhanden, keine Extras.
Vollständig angewendet mit Extras: Erforderliche Filter vorhanden, aber es existieren zusätzliche Filter (geprüft gegen „harmlose" Regeln).
Teilweise angewendet: Einige Filter fehlen oder sind falsch.
Nicht angewendet: Kritische Filter fehlen.

D. LLM-basiertes semantisches Urteil

Ein LLM-Evaluator fungiert als „Richter", um eine ganzheitliche semantische Ausrichtung zu bewerten, die regelbasierte Logik nicht erfassen kann (z. B. komplexe Datumsarithmetik, implizite Äquivalenzen von Metriken).

Urteilsskala: Das LLM gibt eine 4-stufige ordinale Punktzahl aus: Korrekt, Wahrscheinlich korrekt, Potenziell inkorrekt, Inkorrekt.
Konfidenzbewertung: Das LLM liefert einen Konfidenzwert ( $\gamma \in [0, 1]$ ), um seine Sicherheit zu quantifizieren, was entscheidend für den Umgang mit der Varianz des Evaluators ist.

E. Produktions-Normalisierungsregeln

Um False Negatives bei strukturell korrekten, aber idiomatisch unterschiedlichen SQL-Abfragen zu verhindern, wendet STEF vier universelle Normalisierungsregeln an:

Erforderliche GROUP BY-Infferenz: Wenn ein SELECT Aggregationen und Nicht-Aggregationen mischt, wird die notwendige GROUP BY als korrekt angenommen, auch wenn sie nicht explizit angefordert wurde.
Harmlose GROUP BY: Das Gruppieren nach einer Spalte, die durch eine WHERE-Klausel bereits auf einen einzigen Wert eingeschränkt ist, wird ignoriert.
ORDER BY-Toleranz: Standard-Sortierung (z. B. nach aggregierter Metrik absteigend) wird akzeptiert, wenn der Benutzer keine Sortierreihenfolge explizit angefordert hat.
LIMIT-Toleranz: LIMITs mit hoher Kardinalität (z. B. LIMIT 10000), die als Sicherheitsvorkehrungen verwendet werden, werden nicht als Top-k-Einschränkungen bestraft, es sei denn, sie wurden explizit angefordert.

3. Komposite Bewertungsmethode

STEF erzeugt eine einzelne interpretierbare Punktzahl ( $\Phi$ ) auf einer Skala von 0–100. Die Punktzahl wird berechnet als:
$\Phi = \frac{B}{10} \times 100 \times \Gamma$
Wobei:

$B$ (Basis-Punktzahl): Summe aus Filter-Ausrichtungs-Punktzahl (0–5) und Semantischem Urteil (0–5), plus einem Nachsichtigkeits-Boost (+1), wenn zusätzliche Filter als harmlos bestätigt werden.
$\Gamma$ (Konfidenz-Multiplikator): Ein Straf-Faktor basierend auf der Konfidenz des LLM ( $\gamma$ $γ$ ).
- $\gamma \ge 0.85 \rightarrow \Gamma = 1.0$
- $0.65 \le \gamma < 0.85 \rightarrow \Gamma = 0.8$
- $\gamma < 0.65 \rightarrow \Gamma = 0.5$
- Bedeutung: Dies wandelt die Unsicherheit des Evaluators in ein Bewertungssignal um und bestraft Bewertungen mit geringer Konfidenz, um False Positives zu verhindern.

4. Hauptbeiträge

Schema-agnostische Evaluierung: Das erste Framework, das die Genauigkeit von T2SQL in der Produktion bewertet, ohne Datenbankschemata, Referenzabfragen oder Ausführungsinfrastruktur zu benötigen.
Angereicherte Fragenvalidierung: Behandelt die interne Neuformulierung der Benutzerfrage durch den Agenten als erstklassiges Signal für die Evaluierung.
Konfigurierbare Regel-Injektion: Ermöglicht es Unternehmen, deploymentspezifische Logik (Spaltenzuordnungen, harmlose Filter) über Prompt-Templating einzufügen, ohne Code-Änderungen oder Modell-Neu-Training.
Produktionsrobuste Normalisierung: Handhabt explizit gängige Produktions-SQL-Idiome (GROUP BY-Infferenz, Standard-ORDER BY, Sicherheits-LIMITs), um False Negatives zu reduzieren.
Konfidenz-kalibrierte Bewertung: Integriert die LLM-Uncertainty direkt in die endgültige Genauigkeitspunktzahl und liefert so eine zuverlässigere Metrik für die kontinuierliche Überwachung.

5. Ergebnisse

Empirische Ergebnisse (Abschnitt 7) demonstrieren die Viabilität des Frameworks über drei Produktions-Agenten hinweg:

Agent-A: Mittlere Punktzahl 87,4, P90-Punktzahl 96,2, Abdeckung 98,7 %.
Agent-B: Mittlere Punktzahl 82,1, P90-Punktzahl 93,5, Abdeckung 97,2 %.
Agent-C: Mittlere Punktzahl 91,3, P90-Punktzahl 98,1, Abdeckung 99,1 %.
Die hohe Abdeckung und die Punktzahlen zeigen, dass STEF die Leistung von Agenten in einer Live-Umgebung effektiv überwachen und differenzieren kann.

6. Bedeutung

Diese Arbeit schließt die Lücke zwischen akademischer T2SQL-Forschung und industrieller Realität. Durch die Beseitigung der Abhängigkeit von Ground-Truth-Daten und statischen Schemata ermöglicht STEF:

Kontinuierliche Verbesserung: Organisationen können die Agentenqualität in Echtzeit überwachen und Regressionen identifizieren.
Agentenvergleich: Unterschiedliche Modellversionen oder Agenten können allein basierend auf ihrer Ausgabequalität objektiv verglichen werden.
Skalierbarkeit: Das Framework ist ohne Modifikation über heterogene Datenbanktechnologien und Multi-Tenant-Umgebungen hinweg einsetzbar.

Einschränkungen: Die Autoren stellen fest, dass eine verbleibende Varianz des LLM-Evaluators bei Grenzfällen bestehen bleibt und dass tief verschachtelte Unterabfragen oder komplexe Fensterfunktionen weiterhin herausfordernd bleiben, was eine zukünftige Richtung hin zu hybriden symbolisch-neuralen Parsings nahelegt.