💬 NLP

Test-Time Verification for Text-to-SQL via Outcome Reward Models

Dieses Paper stellt GradeSQL vor, ein Framework, das Outcome Reward Models (ORMs) als gelernte semantische Scorer nutzt, um die Zuverlässigkeit von Text-to-SQL zu verbessern, wobei es demonstriert, dass die ORM-basierte Verifizierung traditionelle heuristische Methoden wie das exekutionsbasierte Best-of-N und Majority Voting auf den BIRD- und Spider-Benchmarks signifikant übertrifft.

Ursprüngliche Autoren: Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

Veröffentlicht 2026-07-01

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.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 bitten einen sehr intelligenten, aber manchmal übermütigen Koch (die KI), ein bestimmtes Gericht basierend auf einem Rezept zuzubereiten, das Sie in einfacher Sprache beschreiben. Der Koch weiß zwar, wie man kocht, aber manchmal verwendet er die falschen Zutaten oder bringt die Schritte durcheinander.

In der Welt der Computer wird dies Text-to-SQL genannt: die Übersetzung einer menschlichen Frage in eine Datenbankabfrage (eine Reihe von Anweisungen für eine Computerdatenbank). Das Problem ist, dass, wenn der Koch auch nur einen winzigen Fehler macht, der Computer Ihnen entweder das falsche Ergebnis liefert oder gar nichts liefert.

Der alte Weg: „Raten und Prüfen“

Normalerweise bittet das System den Koch, wenn er sich unsicher ist, das Gericht 32 Mal zu kochen (indem es 32 verschiedene SQL-Abfragen generiert). Dann muss es das beste auswählen.

Die alten Methoden, um den Gewinner zu ermitteln, sind wie folgt:

Mehrheitsentscheidung: „Wer hat das Gericht am häufigsten gekocht?“ Wenn 20 Köche sagen „Salz hinzufügen“ und 12 sagen „Zucker hinzufügen“, nimmt das System an, dass „Salz“ richtig ist. Aber was ist, wenn das Rezept eigentlich Zucker benötigt hätte und die Mehrheit denselben Fehler gemacht hat?
Ausführungserfolg: „Wer hat die Pfanne tatsächlich zum Laufen gebracht?“ Wenn eine Abfrage ohne Absturz durchläuft, wählt das System sie aus. Aber eine Abfrage kann perfekt durchlaufen und Ihnen trotzdem die falschen Daten liefern (wie zum Beispiel einen Kuchen zu servieren, wenn Sie eigentlich nach Suppe gefragt haben).

Diese Methoden verlassen sich auf einfache, oberflächliche Hinweise (Heuristiken), anstatt wirklich zu verstehen, ob das Gericht korrekt ist.

Der neue Weg: Der „GradeSQL“-Feinschmecker

Dieses Paper stellt ein neues System namens GradeSQL vor. Anstatt nur Stimmen zu zählen oder zu prüfen, ob die Pfanne funktioniert, trainieren sie einen spezialisierten Feinschmecker (einen sogenannten Outcome Reward Model oder ORM).

So funktioniert das GradeSQL-System Schritt für Schritt:

1. Die Kochklasse (Training)
Zuerst muss das System dem Feinschmecker beibringen, was „gut“ und „schlecht“ bedeutet.

Es nimmt eine Frage und bittet den Hauptkoch (die KI), 32 verschiedene Versionen des Gerichts zu kochen.
Dann lässt es alle 32 Gerichte gegen den „Goldstandard“ (die korrekte Antwort) laufen.
Wenn ein Gericht exakt wie der Goldstandard schmeckt, gibt der Feinschmecker eine hohe Punktzahl. Wenn es anders schmeckt, erhält es eine niedrige Punktzahl.
Der Feinschmecker lernt aus diesen Beispielen, den Geschmack einer korrekten Abfrage zu erkennen, und nicht nur, ob sie abgestürzt ist.

2. Die Verkostung (Inferenz)
Wenn nun ein echter Benutzer eine Frage stellt:

Kocht der Chef 32 neue Versionen.
Anstatt nur zu prüfen, ob sie laufen, probiert der Feinschmecker jedes einzelne Gericht.
Der Feinschmecker gibt jedem Gericht eine Punktzahl bas thereof, wie gut es mit der Absicht der Frage übereinstimmt.
Das System wählt das Gericht mit der höchsten Punktzahl aus.

Warum ist das besser?

Das Paper hat dies an zwei riesigen Datenbanken von Fragen (genannt BIRD und Spider) getestet. Sie fanden heraus, dass der Feinschmecker viel besser darin war, die richtige Antwort zu finden, als die alten Methoden („Stimmen zählen“ oder „ist es abgestürzt?“).

Die Analogie: Stellen Sie sich einen Multiple-Choice-Test vor. Die alte Methode wählt die Antwort aus, die am häufigsten vorkommt oder keinen Tippfehler hat. Die neue Methode (GradeSQL) liest tatsächlich die Frage und die Antwort und prüft, ob sie zusammen Sinn ergeben.
Die Ergebnisse: Bei schwierigen Fragen half der Feinschmecker dem System, die richtige Antwort etwa 4 % häufiger im BIRD-Datensatz und 2 % häufiger im Spider-Datensatz zu finden. Während 2–4 % klein klingen mögen, ist dies in der Welt der KI eine enorme Verbesserung, besonders für die schwierigsten Fragen, bei denen die alten Methoden normalerweise aufgeben würden.

Wichtigste Erkenntnisse

Ein „gelernter“ Richter: Der Feinschmecker folgt nicht einfach nur Regeln; er hat gelernt, wie eine korrekte SQL-Abfrage aussieht, indem er an tausenden Beispielen geübt hat.
Kein Mensch nötig: Das System hat sich selbst beigebracht, ein Kritiker zu sein, indem es automatisch prüfte, welche Antworten funktionierten, sodass keine Menschen die Hausaufgaben manuell bewerten mussten.
Es skaliert: Je mehr Optionen (Kandidaten) der Chef generiert, desto besser arbeitet der Feinschmecker. Die alten Methoden bleiben stecken und verbessern sich nicht weiter, aber der Feinschmecker wird immer klüger, wenn er mehr Auswahlmöglichkeiten hat.

Kurz gesagt: GradeSQL ist so, als würde man einen professionellen Feinschmecker engagieren, um das beste Gericht aus einer Auswahl von 32 zu wählen, anstatt nur die Menge zu fragen oder zu prüfen, ob der Herd an ist. Es macht die KI zuverlässiger, wenn die Fragen knifflig werden.

Technisches Resümee: Testzeit-Verifizierung für Text-to-SQL via Outcome Reward Models

Problemstellung

Die Zuverlässigkeit von Large Language Models (LLMs) bei strukturierten Reasoning-Aufgaben, insbesondere Text-to-SQL, bleibt eine kritische Herausforderung. Obwohl LLMs signifikante Fortschritte gemacht haben, haben sie oft Schwierigkeiten mit komplexen Abfragen, die Multi-Table-Joins, verschachtelte Subqueries und subtile Constraints beinhalten. Aktuelle Strategien zur Inferenz zur Testzeit, wie etwa Best-of-N (BoN) Sampling und Majority Voting, versuchen dies zu mildern, indem sie mehrere Kandidaten-SQL-Abfragen generieren und die beste auswählen. Diese Methoden verlassen sich jedoch auf heuristische Signale – primär auf den Ausführungsfolg (läuft die Abfrage ohne Fehler durch?) oder die Ausgabefrequenz (liefern mehrere Abfragen dasselbe Ergebnis?).

Die Autoren argumentieren, dass diese Heuristiken lediglich grobe Proxys für semantische Korrektheit sind. Wenn die Kandidatenmengen wachsen, sättigen sich diese Signale oft und versagen dabei, zwischen semantisch validen und invaliden Abfragen zu diskriminieren – insbesondere dann, wenn mehrere inkorrekte Abfragen erfolgreich ausgeführt werden, aber falsche Ergebnisse liefern, oder wenn semantisch äquivalente Abfragen unterschiedliche syntaktische Strukturen aufweisen. Es besteht ein Bedarf an einem gelernten Verifizierungsmechanismus, der Kandidaten basierend auf der aufgabenspezifischen semantischen Übereinstimmung bewertet, anstatt auf oberflächlichen Ausführungsmetriken.

Methodik: Das GradeSQL-Framework

Um den Mangel an annotierten Daten zu adressieren, die für das Training von Verifizern in strukturierten Aufgaben erforderlich sind, führen die Autoren GradeSQL ein, ein skalierbares Framework für das Training von Outcome Reward Models (ORMs). Im Gegensatz zu Process Reward Models (PRMs), die Zwischenschritte bewerten, ordnen ORMs den finalen Ausgaben einen Skalarwert zu. Das Framework operiert in drei Stufen:

Kandidatengenerierung: Gegeben eine natürliche Sprachfrage und ein Datenbank-Schema, produziert ein Generator-LLM eine diverse Menge von $N$ Kandidaten-SQL-Abfragen mittels stochastischer Dekodierungsstrategien. Diese Diversität ist entscheidend, um den Verifizierer einer breiten Palette von korrekten Formulierungen und „Near-Miss“-Fehlern auszusetzen.
Automatisierte Datenlabeling: Anstatt manueller Annotation labelt das Framework Kandidaten via Ausführungsäquivalenz. Jeder Kandidat wird gegen die Datenbank ausgeführt. Wenn das Ergebnisset mit dem der Goldstandard-Abfrage übereinstimmt ( $R(c_j) = R(y_{gold})$ ), wird der Kandidat als „Korrekt“ gelabelt; andernfalls als „Inkorrekt“. Abfragen, die zu Ausführungsfehlern führen, werden verworfen. Dies erzeugt einen groß angelegten, automatisch gelabelten Datensatz für das Verifizierer-Training.
Supervised Fine-Tuning (SFT): Ein Verifizierer-LLM wird (mittels LoRA) als binärer autoregressiver Klassifikator feinjustiert. Der Input besteht aus dem Schema, der Frage und einer Kandidaten-Abfrage, und das Modell wird darauf trainiert, die Wahrscheinlichkeit des „Yes“-Tokens (was Korrektheit anzeigt) vorherzusagen.

Inferenz-Pipeline: Zur Testzeit produziert der Generator $N$ Kandidaten. Das trainierte ORM bewertet jeden Kandidaten basierend auf der Wahrscheinlichkeit des „Yes“-Tokens. Der Kandidat mit dem höchsten Score wird ausgewählt, wodurch die heuristische Selektion durch semantische Bewertung ersetzt wird.

Kernbeiträge

Die Arbeit leistet drei primäre Beiträge:

ORM-basierte Verifizierung für Text-to-SQL: Die Studie adaptiert Outcome Reward Models als gelernte semantische Scorers für die Auswahl von Kandidaten zur Testzeit in der strukturierten Abfragegenerierung und demonstriert deren Anwendbarkeit über ihren traditionellen Einsatz in Alignment und Reasoning hinaus.
Skalierbare Datencurating-Pipeline: Die Autoren schlagen GradeSQL vor, ein automatisiertes Framework, das Kandidaten-SQL-Abfragen via Ausführungsäquivalenz generiert und labelt. Dies ermöglicht das Training aufgabenspezifischer ORMs ohne den Bedarf an teurer manueller Annotation.
Empirische Analyse der Testzeit-Verifizierung: Eine systematische Evaluierung über mehrere Open-Source-LLM-Familien (einschließlich Qwen, Granite, Llama und OmniSQL) und Benchmarks (BIRD und Spider) zeigt, dass die ORM-basierte Selektion heuristische Baselines konsistent übertrifft.

Experimentelle Ergebnisse

Der Ansatz wurde auf den Benchmarks BIRD und Spider unter Verwendung mehrerer Generator-Modelle evaluiert. Die wichtigsten Erkenntnisse sind:

Leistungssteigerungen: Die ORM-basierte Selektion erreichte konsistent eine höhere Execution Accuracy (EX) als Majority Voting und die ausführungsbasierte Best-of-N.
- Auf BIRD dev erreichte das ORM 68,90 %, einen Gewinn von +5,01 % gegenüber der Baseline ( $N=1$ ) und übertraf damit Majority Voting (+3,06 %) und das ausführungsbasierte BoN (+2,15 %).
- Auf Spider test erreichte das ORM 87,47 % und übertraf damit Majority Voting (85,47 %) und das ausführungsbasierte BoN (85,14 %).
Skalierung mit Kandidatenmengen: Im Gegensatz zu heuristischen Methoden, die früh sättigen, verbesserte sich die ORM-Leistung kontinuierlich, während die Größe des Kandidatenpools ( $N$ ) zunahm, und näherte sich der Oracle-Obergrenze an, die durch Pass@N definiert ist. Dies deutet darauf hin, dass ORMs die erhöhte Rechenleistung zur Testzeit effektiv nutzen.
Robustheit: Die Methode zeigte konsistente Verbesserungen über verschiedene Generator-Familien und Modellskalen hinweg. Die Vorteile der ORM-basien Selektion blieben auch bei der Verwendung größerer Generatoren (bis zu 32B Parametern) bestehen.
Trainingsdynamik:
- Datensatz-Imbalance: Obwohl die generierten Datensätze imbalanciert waren (z. B. ~69 % korrekt in Spider), führte das Training auf balancierten Teilmengen (50/50) nicht zu einer Verschlechterung der Leistung, sondern verbesserte sie in einigen Fällen sogar bei gleichzeitig reduzierten Trainingskosten.
- Modellgröße: Eine Erhöhung der ORM-Größe über 7B Parameter hinaus brachte nur marginale und inkonsistente Verbesserungen, was darauf hindeutet, dass leichtgewichtige ORMs ein günstiges Leistungs-Effizienz-Verhältnis bieten.
- Prompt-Design: Prompts, die dem Verifizierer die SQL-Struktur direkt offenlegen („SQL-Only“), lieferten die besten Ergebnisse im Vergleich zu Instruktions- oder Daten-basierten Prompts.

Bedeutung und Behauptungen

Das Paper behauptet, dass die gelernte Verifizierung eine einfache, effektive und skalierbare Alternative zu heuristischen Selektionsstrategien zur Testzeit für Text-to-SQL darstellt. Die Bedeutung dieser Arbeit liegt in der Demonstration, dass:

Ausführungsbasiertes Labeling ausreichend ist, um effektive Verifizierer für strukturierte Aufgaben zu trainieren, wodurch die Barriere der manuellen Annotation entfällt.
Semantische Diskriminierung zur Inferenzzeit möglich ist, ohne den Generator zu modifizieren oder zusätzlichen Interaktionen mit der Umgebung über die initiale Kandidatengenerierung hinaus zu benötigen.
ORMs besonders effektiv für komplexe Abfragen sind, bei denen heuristische Signale versagen, da sie einen prinzipienbasierten Weg bieten, die inhärente Ambiguität und strukturelle Komplexität von Text-to-SQL zu handhaben.

Die Autoren bewahren einen bescheidenen Ton und räumen ein, dass die absoluten Gewinne moderat sind (2–5 %) und dass der Ansatz auf Ausführungsäquivalenz als Proxy für semantische Korrektheit beruht, was möglicherweise nicht zwischen semantisch äquivalenten, aber syntaktisch unterschiedlichen Abfragen unterscheidet oder bei irreführenden Treffern (Spurious Matches) versagt. Die Arbeit konzentriert sich auf die Verbesserung der Selektion von Kandidaten und nicht auf die Generierungsfähigkeit selbst.