💬 NLP

ACE-SQL: Adaptive Co-Optimization via Empirical Credit Assignment for Text-to-SQL

ACE-SQL ist ein Reinforcement-Learning-Framework, das die Schema-Retrieval und die SQL-Generierung gemeinsam optimiert, indem es Ausführungs-Feedback nutzt, um adaptive, On-Policy-Retrieval-Ziele abzuleiten, wodurch eine hohe Genauigkeit bei komplexen Text-to-SQL-Aufgaben bei effizienter Token-Nutzung erreicht wird.

Ursprüngliche Autoren: Xiaobing Chen, Ai Jian, Eryu Guo, Zhiqi Pang

Veröffentlicht 2026-06-05

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Xiaobing Chen, Ai Jian, Eryu Guo, Zhiqi Pang

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, einen Bibliothekar (die KI) zu bitten, ein bestimmtes Buch in einer riesigen, chaotischen Bibliothek (der Datenbank) zu finden. Die Bibliothek hat tausende von Regalen, Millionen von Büchern und verwirrende Beschriftungen.

Das Problem: Das „Alles-oder-Nichts“-Dilemma
Aktuelle Methoden, um den Bibliothekar zu fragen, machen meistens eines von zwei Dingen, und beide haben Mängel:

Der „Alles-Hinklatschen“-Ansatz: Sie übergeben dem Bibliothekar den gesamten Bibliothekskatalog (alle Tabellen und Spalten) und sagen: „Finde das.“ Der Bibliothekar muss dann raten, welche Regale wichtig sind, während er versucht, die Anfrage zu formulieren. Es ist, als würde man versuchen, eine Nadel im Heuhaufen zu finden, während der Heuhaufen brennt.
Der „Statische Landkarten“-Ansatz: Sie geben dem Bibliothekar eine vorgefertigte Karte, die genau zeigt, auf welche Regale er schauen soll. Aber der Haken dabei ist: Die Karte wurde von einem Menschen gezeichnet, der vielleicht einen Pfad gewählt hat, den der Bibliothekar nicht wirklich mag oder auf dem er nicht gut navigieren kann. Wenn der Bibliothekar das Buch über eine andere Gasse besser finden würde, zwingt ihn die Karte dazu, sich an die „korrekte“ (aber ineffiziente) Route zu halten, was zum Scheitern führt.

Die Lösung: ACE-SQL (Das „Coaching“-System)
Das Paper stellt ACE-SQL vor, eine neue Art, den Bibliothekar mithilfe einer Technik namens Reinforcement Learning (Bestärkendes Lernen) zu trainieren. Anstatt eine statische Karte zu verwenden oder die gesamte Bibliothek hinzuklatschen, setzt ACE-SQL eine dynamische Coaching-Schleife zwischen zwei Rollen ein, die von derselbe KI gespielt werden:

Der Scout (Retriever): Dieser Teil der KI schaut sich die Frage an und wählt eine kleine, relevante Liste von Regalen (Spalten) aus, die betrachtet werden sollen.
Der Schreiber (Generator): Dieser Teil nutzt diese kurze Liste, um die eigentliche Anfrage (SQL-Query) zu schreiben.

Wie die Magie geschieht: Die „Credit Assignment“-Schleife
Die Genialität von ACE-SQL liegt darin, wie es lernt. Es verlässt sich nicht auf eine vom Menschen erstellte „perfekte“ Karte. Stattdessen nutzt es Versuch und Irrtum:

Der Rollout: Die KI versucht, eine Frage zu beantworten. Der Scout wählt eine Liste von Regalen aus, und der Schreiber versucht, eine Abfrage zu schreiben.
Der Test: Das System führt die Abfrage tatsächlich in der Datenbank aus. Wurde die richtige Antwort gefunden?
Die Belohnung:
- Wenn die Abfrage funktioniert, sagt das System: „Gute Arbeit! Die Liste der Regale, die der Scout gewählt hat, war nützlich.“
- Wenn sie fehlschlägt, sagt das System: „Versuch es noch einmal.“
Der Clou (Adaptive Co-Optimization):
- Normalerweise wird der Scout darauf trainiert, die „menschengeprüften“ Regale zu wählen. Aber ACE-SQL ändert die Regeln. Wenn der Schreiber die Antwort erfolgreich mit einem anderen Satz an Regalen findet als die menschliche Karte, aktualisiert das System das Training des Scouts.
- Analogie: Stellen Sie sich einen Trainer vor, der zu einem Läufer sagt: „Du musst den Weg laufen, den die Karte vorgibt.“ Aber wenn der Läufer eine Abkürzung findet, die ihn schneller ans Ziel bringt, sagt der Trainer: „Okay, beim nächsten Mal trainieren wir dich so, dass du genau diese Abkürzung nimmst.“ Die Karte (Retriever) und der Läufer (Generator) lernen, sich in Echtzeit aneinander anzupassen.

Das Chaos stabilisieren
Da der Scout und der Schreiber gemeinsam lernen, können sie sich manchmal gegenseitig im Weg stehen (wie zwei Personen, die gleichzeitig versuchen, ein Boot zu steuern). Das Paper verwendet zwei „Stabilisatoren“, um sie in Einklang zu halten:

Das „Abstimmungssystem“: Der Scout wählt nicht nur einen Pfad; er probiert viele aus und wählt den populärsten, um dem Schreiber einen stabilen Startpunkt zu geben.
Die „Graduelle Übergabe“: Zu Beginn übernimmt der Scout den Großteil der schweren Arbeit. Wenn der Schreiber besser wird, gibt das System ihm langsam mehr Verantwortung, um zu verhindern, dass das Team während der Lernphase auseinanderbricht.

Die Ergebnisse
Das Paper hat dies auf einem schwierigen Benchmark namens BIRD getestet, der reale, unordentliche Datenbanken simuliert.

Leistung: ACE-SQL erreichte eine Erfolgsquote von 65,3 % und schlug damit andere Top-Methoden.
Effizienz: Es erreichte dies bei 70 % weniger Wörtern (Tokens) als sein engster Konkurrent.
- Analogie: Während andere Systeme lange, ausschweifende Essays schrieben, um die Antwort zu finden, schrieb ACE-SQL eine prägnante, präzise Notiz und erledigte die Aufgabe schneller und genauer.

Zusammenfassend
ACE-SQL ist ein System, das aufhört, die KI dazu zu zwingen, einer starren, menschengemachten Karte zu folgen. Stattdessen lässt es die KI verschiedene Wege erkunden, belohnt sie für das Finden irgendeines funktionierenden Weges und lehrt dann den „Kartenzeichner“, die Pfade zu zeichnen, die der „Läufer“ tatsächlich zu nehmen weiß. Dies schafft ein Team, das gemeinsam klüger und effizienter wird, anstatt gegen ein statisches Handbuch zu kämpfen.

Technisches Resümee: ACE-SQL

Problemstellung

Text-to-SQL-Systeme stehen vor einem kritischen Engpass beim Schema-Linking, insbesondere beim Umgang mit modernen Datenbanken, die große und komplexe Schemata enthalten. Bestehende Ansätze lassen sich im Wesentlichen in zwei Kategorien unterteilen, die beide unter einem Generator-konditionierten Überwachungs-Mismatch (Supervision Mismatch) leiden:

Vollständige Schema-Generierung: Diese Methoden lernen die Schema-Selektion implizit innerhalb der End-to-End-SQL-Generierung. Dies lässt das Schema-Linking jedoch innerhalb eines massiven Suchraums zurück, was oft zu einer geringeren Ausführungsgenauigkeit im Vergleich zur Verwendung von Gold-Spalten (Ground-Truth) führt.
Retriever-Generator-Pipelines: Diese Systeme verwenden einen separaten Retriever, der auf statischen Gold-Spalten-Annotationen trainiert wurde, um explizit Schema-Komponenten vor der Generierung auszuwählen. Die Einschränkung hierbei ist, dass der Retriever an feste „Gold“-Ziele gebunden ist. Wie in der Arbeit gezeigt wird, beruhen ein erheblicher Teil (19,1 % bis 42,3 %) der ausführlich korrekten SQL-Vorhersagen auf Nicht-Gold-Spaltensätzen (alternativen ausführbaren Routen). Ein Retriever, der strikt auf statischen Gold-Labels trainiert wurde, bestraft diese validen, vom Generator bevorzugten Routen, was zu einer suboptimalen Policy für den aktuellen Generator führt.

Die zentrale Herausforderung besteht darin, dass Schema-Linking und SQL-Generierung gekoppelt sind: Der Retriever definiert die Input-Verteilung des Generators, während die erfolgreichen Outputs des Generators bestimmen, welche Schema-Konfigurationen gültig sind. Eine gemeinsame Optimierung führt zu einer zirkulären Abhängigkeit und Gradienten-Interferenz, während eine Entkopplung zu dem beschriebenen Supervision-Mismatch führt.

Methodik: ACE-SQL

Die Autoren schlagen ACE-SQL (Adaptive Co-Optimization via Empirical Credit Assignment) vor, ein Reinforcement Learning (RL) Framework, das Schema-Retrieval und SQL-Generierung unter einer gemeinsamen Policy ( $\pi_\theta$ ) gemeinsam optimiert. Das Framework operiert in zwei Phasen:

1. Supervised Fine-Tuning (Cold Start)

Um sicherzustellen, dass die Retriever-Generator-Pipeline vor dem RL funktionsfähig ist, führen die Autoren eine Self-Distillation-SFT-Phase unter Verwendung des Qwen3-8B Modells durch.

Source Filtering: Samples werden bas aus dem SynSQL-2.5M Datensatz basierend auf Komplexität und Schema-Diversität gefiltert.
Paired Self-Distillation: Das Modell generiert Retriever-Outputs (Spaltensätze) mittels Self-Consistency-Voting. Diese definieren die beschnittenen (pruned) Schemata für den Generator. Es werden nur Paare beibehalten, bei denen die Ausführung des Generators mit dem Gold-SQL übereinstimmt.
Mixed SFT: Die Retriever- und Generator-Samples werden gemeinsam trainiert, um die gemeinsame Policy zu initialisieren.

2. Gemeinsames GRPO-Training (Reinforcement Learning)

Die Kerninnovation liegt im Joint Group Relative Policy Optimization (GRPO) Training, welches statische Gold-Ziele durch adaptive, On-Policy-Ziele ersetzt, die aus dem Ausführungs-Feedback abgeleitet werden.

Bidirektionale Adaptation:
- Retriever $\to$ Generator: Der Retriever sampelt $N$ Spaltensätze, die mittels Majority Voting aggregiert werden, um ein beschnittenes Schema ( $\hat{S}$ ) zu erstellen. Dieses Schema konditioniert den Input des Generators.
- Generator $\to$ Retriever: Der Generator produziert $N$ SQL-Queries. Erfolgreiche Ausführungen (Übereinstimmung mit dem Gold-Ergebnis) werden verwendet, um einen Empirical Column-Set Pool zu aktualisieren.
Empirical Credit Assignment:
- Anstatt auf einen festen Gold-Spaltensatz abzuzielen, wird das Ziel des Retrievers dynamisch auf den häufigsten Spaltensatz ( $S^\star(q)$ ) aktualisiert, der im empirischen Pool der ausführungs-korrekten Rollouts beobachtet wurde.
- Dieser Pool wird mit High-Recall-Unionen von Spaltensätzen initialisiert und online mit einem Zerfallsfaktor ( $\gamma=0.5$ ) aktualisiert, um neuere Evidenzen zu priorisieren und gleichzeitig erfolgreiche Routen beizubehalten.
Reward-Konstruktion:
- Beide Rollen erhalten spärliche (sparse) Rewards, die durch die Korrektheit der Ausführung gesteuert werden (für den Generator) oder durch die exakte Übereinstimmung mit dem empirischen Ziel $S^\star(q)$ (für den Retriever).
- Eine geclippte Längenstrafe (clipped length penalty) wird angewendet, um übermäßig lange Outputs zu verhindern, aber nur, wenn der Output die Bedingung des spärlichen Rewards erfüllt.
Stabilisierungsmechanismen:
- PCGrad (Gradient Surgery): Um Gradienten-Interferenzen zwischen den Verlustfunktionen von Retriever und Generator zu mildern, wenden die Autoren PCGrad an, um kollidierende Gradienten zu projizieren.
- Generator-Weight Schedule: Der Beitrag des Generators zum gemeinsamen Verlust wird über die ersten 25 % der RL-Schritte linear von 0 auf 1 gesteigert. Dies ermöglicht es den empirischen Retriever-Zielen, sich zu stabilisieren, bevor der Generator vollen Einfluss ausübt.

Zentrale Beiträge

On-Policy Credit Assignment: Die Arbeit formuliert das Schema-Retrieval als On-Policy Credit Assignment Problem. Anstatt sich auf statische Gold-Annotationen zu verlassen, leitet ACE-SQL adaptive Retrieval-Ziele aus den eigenen, ausführungs-korrekten Rollouts des Generators ab.
Bidirektional adaptives Framework: ACE-SQL schafft einen geschlossenen Kreislauf, in dem der Retriever an die ausführbaren Präferenzen des Generators angepasst wird und der Generator an die sich entwickelnden Schema-Selektionen des Retrievers, beides fundiert durch die Ausführungsgenauigkeit.
Stabilisierte gemeinsame Optimierung: Die Autoren führen eine Kombination aus einem empirischen Spaltensatz-Pool, PCGrad und einem Generator-Weight-Schedule ein, um den nicht-stationären und gekoppelten Optimierungsprozess zu stabilisieren.
Effizienz und Leistung: Die Methode erreicht eine hohe Performance mit signifikant weniger Output-Tokens im Vergleich zu bestehenden RL-basierten Baselines.

Experimentelle Ergebnisse

Evaluierung auf den BIRD Dev und Spider Benchmarks unter Verwendung des Qwen3-8B Backbones:

BIRD Dev: ACE-SQL erreicht 65,3 % Greedy Execution Accuracy (EX) und übertrifft damit alle gelisteten Open-Source-Baselines (z. B. SQL-R1-7B mit 63,7 %, MTIR-SQL-8B mit 63,6 %).
Spider: Erreicht 87,2 % EX auf dem Testset und 79,5 % auf der anspruchsvollen Spider-Realistic Variante.
Effizienz: ACE-SQL verwendet pro Query auf BIRD Dev nur 0,93k Output-Tokens. Dies sind etwa 3,3 $\times$ weniger Tokens als SQL-R1-7B (3,10k) und 2,2 $\times$ weniger als MTIR-SQL-8B (2,00k), trotz höherer Genauigkeit.
Ablationsstudien:
- Das Entfernen von PCGrad oder des Generator-Weight-Schedules führt zu Leistungsabfällen, was die Notwendigkeit dieser Stabilisatoren für das gemeinsame RL bestätigt.
- Die Verwendung statischer Gold-Ziele für den Retriever führt zu einer geringeren Performance (64,7 % vs. 65,3 %) und höherer Instabilität, was den Nutzen des Empirical Credit Assignment validiert.
- Sparse Rewards schneiden in diesem gemeinsamen Setting besser ab als Dense Rewards, da Dense Rewards zu einer Gradienten-Dominanz durch den Retriever und zu Reward-Hacking führen können.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass ACE-SQL eine praktische Richtung für den Aufbau effizienter und robuster Text-to-SQL-Systeme für komplexe, reale Datenbanken bietet. Durch die Abkehr von statischer Supervision und die Hinwendung zu bidirektionaler Adaptation löst das Framework das Spannungsverhältnis zwischen Schema-Retrieval und SQL-Generierung auf.

Die Autoren betonen, dass ihr Ansatz eine neue Perspektive auf das Upstream-Downstream Credit Assignment in mehrstufigen LLM-Pipelines bietet. Sie argumentieren, dass ausführungs-ausgerichtete Signale (execution-aligned signals) überlegene Metriken als statische Annotationen sind, um On-Policy ausführbare Routen zu verfolgen, wodurch das Modell in der Lage ist, seine eigenen gelernten Reasoning-Muster zu nutzen, anstatt durch potenziell suboptimale Gold-Labels eingeschränkt zu werden. Die Arbeit legt nahe, dass explizites Schema-Retrieval, wenn es gemeinsam mit der Generierung optimiert wird, sowohl die Inferenzqualität als auch die Effizienz verbessern kann, ohne auf massive Token-Generierung angewiesen zu sein.

Limitierungen: Die Autoren merken an, dass die Experimente auf ein einzelnes 8B-Modell (Qwen3-8B) beschränkt sind und auf synthetischen Trainingsdaten (SynSQL-2.5M) basieren. Sie räumen ein, dass eine Skalierung auf größere Modelle oder die Verwendung von realen Query-Datenbank-Paaren unterschiedliche Dynamiken offenlegen könnte, und dass die Initialisierung des empirischen Pools aus einem SFT-Checkpoint die ursprünglichen Präferenzen des Basismodells möglicherweise unterexploriert.