🤖 machine learning

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Das Papier stellt SQLConductor vor, ein schrittweises Orchestrierungs-Framework, das Search-to-Policy Learning einsetzt, um ein Policy-Modell zu trainieren, welches SQL-Teilaufgaben basierend auf Zwischenfeedback dynamisch auswählt und dadurch im Vergleich zu festen Pipelines und direktem Backbone-Training eine überlegene Ausführungsgenauigkeit sowie Generalisierung bei komplexen Text-to-SQL-Benchmarks erreicht.

Ursprüngliche Autoren: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

Veröffentlicht 2026-06-23

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

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 versuchen, eine sehr spezifische Antwort aus einer riesigen, unordentlichen Bibliothek von Informationen (einer Datenbank) zu erhalten, indem Sie eine Frage in natürlicher Sprache stellen. Dies ist das „Text-to-SQL“-Problem: Eine menschliche Frage in einen Computerbefehl (SQL) umzuwandeln, den die Bibliothek versteht.

Lange Zeit versuchten Computer, dies zu lösen, indem sie einem strengen, vorgefertigten Rezept folgten. Egal, was Sie fragten, der Computer musste immer dieselben Schritte befolgen: Schritt 1, Schritt 2, Schritt 3, Schritt 4. Wenn Sie eine einfache Frage wie „Was ist die Hauptstadt von Frankreich?“ stellten, musste der Computer dennoch alle vier Schritte durchlaufen, was Zeit verschwendete und ihn manchmal verwirrte. Wenn Sie eine schwierige Frage stellten und der Computer in Schritt 2 einen Fehler machte, marschierte er mit diesem Fehler einfach weiter, was zu einer falschen Antwort führte.

SQLConductor ist ein neues System, das das Spiel verändert. Anstatt einem starren Rezept zu folgen, agiert es wie ein schlauer Projektmanager oder ein Dirigent, der entscheidet, was als Nächstes zu tun ist, basierend auf dem, was gerade passiert.

So funktioniert es, unter Verwendung einfacher Analogien:

1. Der Werkzeugkasten (Der Aktionsraum)

Stellen Sie sich vor, der Computer besitzt einen Werkzeugkasten mit verschiedenen spezialisierten Werkzeugen:

Der Brecher (The Breaker): Zerlegt eine große Frage in kleinere Teile.
Der Finder: Sucht nach spezifischen Zahlen oder Namen in der Datenbank.
Der Filter: Schneidet irrelevante Informationen heraus.
Der Schreiber (The Writer): Schreibt den eigentlichen Computerbefehl.
Der Editor: Korrigiert Fehler im Befehl.
Der Vollender (The Finisher): Sagt: „Wir sind fertig, hier ist die Antwort.“

Alte Systeme zwangen den Computer, die Werkzeuge in einer bestimmten Reihenfolge zu wählen (z. B. Brecher $\to$ Finder $\to$ Schreiber $\to$ Vollender). SQLConductor lässt den „Dirigenten“ das Werkzeug wählen, das gerade jetzt benötigt wird. Wenn der Finder merkt, dass er mehr Informationen benötigt, kann der Dirigent den Brecher erneut aufrufen. Wenn der Schreiber einen Fehler macht, kann der Dirigent sofort den Editor aufrufen.

2. Das Trainingslager (Search-to-Policy Learning)

Wie lernt der Dirigent, diese klugen Entscheidungen zu treffen? Er liest nicht einfach nur ein Handbuch; er durchläuft ein strenges Trainingslager namens Search-to-Policy Learning.

Die Simulation (MCTS): Stellen Sie sich einen Schachspieler vor, der gegen einen Computer trainiert. Der Computer probiert tausende verschiedene Spielpfade (Workflows) aus, um zu sehen, welche davon zum Sieg führen. SQLConductor macht das auch: Es simuliert Millionen verschiedener Wege, um eine Frage zu lösen, indem es verschiedene Kombinationen von Werkzeugen ausprobiert.
Der Stabilitätscheck: Nur weil ein Pfad einmal funktioniert hat, bedeutet das nicht, dass es eine gute Strategie ist; es könnte Glück gewesen sein. Das System prüft, welche Pfade konsistent funktionieren. Es ist wie ein Trainer, der sagt: „Kopiere nicht den einen Moment, in dem du durch Glück gewonnen hast; kopiere die Strategie, die in 9 von 10 Fällen gewinnt.“
Das „Curriculum“ (Schwierigere Probleme): Sobald der Dirigent die einfachen Probleme beherrscht, wirft das Trainingslager ihm schwierigere, kniffligere Fragen zu. Das System lernt gezielt, wie es die schwierigen Fälle bewältigt, bei denen es normalerweise scheitert.

3. Das Ergebnis: Ein flexibler, effizienter Arbeiter

Nach dem Training wird der SQLConductor eingesetzt, um echte Fragen zu lösen.

Anpassungsfähigkeit: Wenn Sie eine einfache Frage stellen, könnte der Dirigent sagen: „Ich brauche den Editor und den Brecher nicht; ich werde nur den Schreiber und den Vollender nutzen.“ Das spart Zeit. Wenn Sie eine kompleuse Frage stellen, weiß er, dass er in die Schleife zurückkehren muss, um mehr Beweise zu sammeln und die Antwort zu verfeinern.
Effizienz: Da er nur die Werkzeuge nutzt, die er tatsächlich benötigt, verbraucht er weniger Rechenleistung und kostet weniger Geld als Systeme, die jede Frage durch eine lange, feste Pipeline zwingen.
Genauigkeit: In Tests lieferte dieses System häufiger die richtige Antwort als bisherige Methoden, selbst wenn die Fragen sehr schwierig oder die Datenbanken unordentlich waren.

Das große Ganze

Betrachten Sie alte Text-to-SQL-Systeme als ein Fließband in einer Fabrik: Jedes Teil durchläuft dieselben Maschinen, egal ob es sie braucht oder nicht. Wenn ein Teil auf dem Band kaputtgeht, bewegt sich die gesamte Linie weiter und produziert fehlerhafte Produkte.

SQLConductor ist wie ein geschickter Handwerker in einer Werkstatt. Er betrachtet das Objekt (die Frage), entscheidet, welche Werkzeuge er greift, führt einen Schritt aus, prüft das Ergebnis und entscheidet dann, was er als Nächstes tut. Wenn er einen Fehler macht, korrigiert er ihn sofort. Wenn die Aufgabe einfach ist, erledigt er sie schnell. Wenn sie komplex ist, nimmt er sich die Zeit, um es richtig zu machen.

Das Paper behauptet, dass das Lehren des Computers, wie ein geschickter Handwerker zu handeln – anstatt wie eine starre Maschine – es ihm ermöglicht, Datenbankfragen genauer, effizienter und mit besserer Anpassungsfähigkeit an verschiedene Arten von Problemen zu lösen.

Technisches Resümee: SQLConductor

1. Problemstellung

Echtzeitiges Text-to-SQL bleibt eine Herausforderung, da es eine koordinierte Argumentation über komplexe, heterogene Datenbankumgebungen erfordert. Bestehende Systeme lassen sich im Wesentlichen in zwei Kategorien unterteilen, die beide Defizite in der Adaptivität aufweisen:

Starre Pipelines: Diese verlassen sich auf vordefinierte, rigide Phasenabfolgen (z. B. Schema-Linking $\to$ Wertabruf $\to$ Generierung $\to$ Revision). Obwohl sie strukturiert sind, können sie frühere Entscheidungen nicht basierend auf zwischenzeitlichem Feedback oder Ausführungsfehlern revidieren, was zu einer Fehlerfortpflanzung führt.
Plan-then-Execute-Orchestrierung: Diese Methoden generieren einen vollständigen Workflow-Plan vor der Ausführung. Obwohl sie flexibler als starre Pipelines sind, verpflichten sie sich dennoch auf eine statische Sequenz, sobald die Ausführung beginnt, was verhindert, dass das System während des Lösungsprozesses auf Zwischenartefakte oder Ausführungsfeedback reagiert.

Die Kernherausforderung besteht darin, eine schrittweise Orchestrierungs-Policy zu erlernen, die in der Lage ist, die nächste Aktion basierend auf dem aktuellen Lösungskontext und zwischenzeitlichen Belegen dynamisch auszuwählen, ohne auf von Menschen handgefertigten Workflow-Daten zu beruhen oder prohibitive Kosten für die Online-Suche zur Inferenzzeit zu verursachen.

2. Methodik: SQLConductor

SQLConductor ist ein Framework zum Erlernen einer schrittweisen Orchestrierung, das die Prozessorganisation (Orchestrierung) von der Subaufgaben-Ausführung (Argumentation/Reasoning) trennt. Es verwendet ein Search-to-Policy-Lernparadigma, welches die breite Offline-Workflow-Suche in eine einsetzbare Policy für effiziente Inferenz transformiert.

2.1 Aktionsraum

Das System definiert einen modularen Aktionsraum $\mathcal{A}$ , der aus sieben spezialisierten Modulen besteht, die von eingefrorenen Large Language Models (LLMs) aufgerufen werden:

Fragen-Dekomposition ( $a_{dec}$ ): Schreibt komplexe Fragen in feingliedrige Anforderungen um.
Relevante Wertextraktion ( $a_{val}$ ): Identifiziert Bedingungswerte für SQL-Prädikate.
Operations-Identifikation ( $a_{op}$ ): Erfasst erforderliche SQL-Operationen (z. B. Aggregation, Sortierung).
Schema-Pruning ( $a_{sch}$ ): Wählt relevante Tabellen und Spalten aus.
SQL-Abfrage-Generierung ( $a_{gen}$ ): Synthetisiert einen SQL-Kandidaten.
SQL-Abfrage-Verfeinerung ( $a_{ref}$ ): Korrigiert Syntax- oder Ausführungsfehler.
Terminierung und Ausgabe ( $a_{term}$ ): Beendet den Workflow und gibt das finale SQL zurück.

2.2 Search-to-Policy Learning

Der Trainingsprozess besteht aus einer Offline-Phase und einer Online-Deployment-Phase.

Phase 1: Offline Search-to-Policy Training

MCTS-basierte Workflow-Exploration:
- Für jede Trainingsinstanz führt SQLConductor eine Monte Carlo Tree Search (MCTS) über den Aktionsraum durch.
- Knoten repräsentieren Orchestrierungszustände; Kanten repräsentieren Aktionsauswahlen.
- Die Suche exploriert diverse Aktionskompositionen und Tiefen, geleitet durch Execution-Consistency-Belohnungen (die messen, ob generierte SQL-Abfragen über mehrere Stichproben hinweg konsistente Ergebnisse liefern).
- Dies generiert eine diverse Menge an Kandidaten-Trajektorien $\mathcal{X}(q, D)$ .
Workflow-Supervision-Kuratierung:
- Extraktion des Skeletts: Trajektorien werden nach ihren Aktionssequenzen (Workflow-Skeletten) gruppiert.
- Stabilitäts-Schätzung: Da der Suchraum kombinatorisch und verrauscht ist, schätzt SQLConductor die Stabilität jedes Workflows mittels der Laplace-Regel der Sukzession: $\hat{p}_\tau = \frac{s_\tau + 1}{n_\tau + 2}$ , wobei $s_\tau$ die Anzahl erfolgreicher Ausführungen und $n_\tau$ die Gesamtzahl ist.
- Selektion: Die Top- $k$ Workflows mit den höchsten Stabilitätswerten werden ausgewählt. Aus jeder Gruppe wird eine erfolgreiche Trajektorie als Repräsentant gezogen.
- Argumentations-Augmentierung: Ein eingesetztes LLM generiert eine schrittweise Begründung ( $e_t$ ), die erklärt, warum eine spezifische Aktion angesichts des aktuellen Kontextes gewählt wurde, wodurch eine augmentierte Trajektorie $\bar{\xi}$ entsteht.
Stabilitätsgewichtetes Supervised Fine-tuning (SFT):
- Das Policy-Modell wird auf den kuratierten, augmentierten Trajektorien trainiert.
- Maskierung: Die Loss-Funktion maskiert <results>-Token (Aktionsausgaben), um zu verhindern, dass die Policy lernt, Aktionsausgaben vorherzusagen, und konzentriert sich statstattdessen auf Orchestrierungsentscheidungen.
- Gewichtung: Trajektorien werden durch ihre Stabilitätswerte ( $\hat{p}_\tau$ ) gewichtet, um robuste Orchestrierungsmuster zu priorisieren und gleichzeitig Diversität zu bewahren.
Curriculum Reinforcement Learning (RL):
- Um schwierige Abfragen zu handhaben, bei denen erfolgreiche Trajektorien spärlich sind, konstruiert das System ein Curriculum-Set aus herausfordernden Instanzen (geringe MCTS-Erfolgsrate).
- Unter Verwendung von Group Relative Policy Optimization (GRPO) führt die Policy Self-Rollouts auf diesen schwierigen Fällen durch.
- Belohnungen: Die Belohnungsfunktion kombiniert Ausführbarkeit (valides SQL) und Ergebnisqualität (Execution F1 Score gegenüber der Ground Truth), was die Policy dazu ermutigt, Recovery-Strategien für komplexe Fälle zu erlernen.

Phase 2: Online Deployment

Das trainierte Policy-Modell koordiniert die eingefrorenen Aktionsmodule Schritt für Schritt.
An jedem Schritt generiert die Policy eine Begründung und wählt die nächste Aktion basierend auf dem aktuellen Zustand (akkumulierter Beleg und Feedback).
Der Workflow wird während der Ausführung dynamisch konstruiert und passt sich den spezifischen Anforderungen der Abfrage an.

3. Kernbeiträge

Schrittweise Orchestrierungs-Framework: SQLConductor führt ein Framework ein, das die Prozessorganisation von der Subaufgaben-Ausführung entkoppelt und so abfragespezifische Workflows mit adaptiven Tiefen und Modulkompositionen ermöglicht, im Gegensatz zu starren Pipelines oder Plan-then-Execute-Ansätzen.
Search-to-Policy Learning: Das Paper schlägt einen Mechanismus vor, um eine adaptive Orchestrierungs-Policy zu trainieren, ohne auf von Menschen handgefertigte Workflow-Daten angewiesen zu sein. Es nutzt MCTS zur Exploration, Stabilitäts-Schätzung zur Kuratierung und eine Kombination aus Stabilitäts-gewichtetem SFT und Curriculum RL für das Training.
Empirische Leistung und Generalisierung:
- BIRD-Dev: SQLConductor erreicht eine Execution Accuracy (EX) von 73,2 % auf dem BIRD-Dev Benchmark und übertrifft damit bisherige Methoden, die vergleichbare oder größere Text-to-SQL-Backbones direkt trainieren.
- Parametereffizienz: Es erzielt diese Ergebnisse durch das Training einer kompakten Orchestrierungs-Policy (z. B. 8B Parameter), die größere, eingefrorene Aktionsmodelle (z. B. 32B) koordiniert, was eine überlegene Genauigkeit pro trainiertem Parameter demonstriert.
- Generalisierung: Das Modell zeigt eine starke Generalisierung auf Out-of-Distribution (OOD) Datensätze (Spider-Test, KaggleDBQA, ScienceBenchmark) ohne datensatzspezifisches Re-Training.
- Effizienz: Es reduziert den Token-Verbrauch bei der Inferenz und die API-Kosten signifikant (ca. 8-mal günstiger als Baselines wie CHESS), während es eine höhere Genauigkeit beibehält.

4. Bedeutung und Ansprüche

Das Paper behauptet, dass gelerntes Orchestrieren parametereffizienter und effektiver ist als das weitere Training eines monolithischen Text-to-SQL-Modells.

Adaptivität vs. Brute Force: Die Ergebnisse zeigen, dass die Leistungssteigerung nicht einfach durch die Erhöhung der Workflow-Länge oder der Modellgröße erzielt wird, sondern durch die Fähigkeit der Policy, den Orchestrierungsaufwand adaptiv zuzuweisen. Die trainierte Policy weist anspruchsvollen Abfragen mehr Schritte zu, während sie einfache Abfragen effizient hält.
Robustheit: Die Stabilitäts-gewichtete Kuratierung stellt sicher, dass die Policy robuste Muster lernt und keine zufälligen Erfolge, was es ihr ermöglicht, komplexe, verrauschte und domänenspezialisierte Abfragen effektiv zu handhaben.
Skalierbarkeit: Durch die Trennung der Orchestrierungs-Policy von den Aktionsmodulen ermöglicht das Framework die Integration größerer oder spezialisierter Aktionsmodelle, ohne das gesamte System neu trainieren zu müssen, was einen skalierbaren Weg für komplexe Text-to-SQL-Aufgaben bietet.

Zusammenfassend lässt sich sagen, dass SQLConductor die Starrheit bestehender Text-to-SQL-Systeme durch das Erlernen einer dynamischen, schrittweisen Orchestrierungs-Policy adressiert, die auf zwischenzeitliche Belege reagiert und dabei eine State-of-the-Art-Leistung bei deutlich geringeren Rechenkosten erzielt.