🤖 AI

SIRIUS-SQL: Anchoring Multi-Candidate Text-to-SQL in Execution Feedback

SIRIUS-SQL ist ein neuartiges Text-to-SQL-Framework, das die Genauigkeit bei komplexen Schemata verbessert, indem es die Einschränkungen bestehender Multi-Kandidaten-Systeme durch eine mittels Schwierigkeitsglättung (difficulty-smoothing) optimierte RL-Trainingsstrategie für diverse Generierung, einen ausführungsbasierten Lebenszyklus für gezielte Fehlerreparatur und einen vertrauensbasierten Hybrid-Selektor adressiert und damit eine State-of-the-Art-Leistung auf den BIRD- und SPIDER-Benchmarks erzielt.

Ursprüngliche Autoren: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Veröffentlicht 2026-06-02

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

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, einem Roboter-Koch (der KI) eine sehr spezifische, komplexe Anweisung zu geben, um eine Mahlzeit zu kochen (einen SQL-Query zu schreiben), basierend auf einem massiven, unordentlichen Rezeptbuch (der Datenbank).

Wenn Sie den Roboter bitten, das Gericht nur einmal zu kochen, macht er oft Fehler, weil das Rezeptbuch verwirrend ist, die Zutaten seltsam benannt sind oder die Anweisungen vage sind.

Der alte Weg: Das „Mehrheitsvotum“-Problem
Kürzlich versuchten andere Systeme, dies zu lösen, indem sie den Roboter baten, das Gericht 16 Mal zu kochen (statt nur einmal). Dann schauten sie sich die 16 Gerichte an und wählten dasjenige aus, bei dem die meisten Leute sich einig waren (Mehrheitsentscheidung).

Die Autoren dieser Arbeit, SIRIUS-SQL, sagen, dass dieser „Mehrheitsvotum“-Ansatz drei große Probleme hat:

Die Echokammer: Wenn man denselben Roboter bittet, 16 Mal zu kochen, macht er auch dieselben 16 Fehler. Es ist, als würde man dieselbe Person bitten, 16 Mal dasselbe Passwort zu erraten; sie wird wahrscheinlich immer wieder dasselbe falsche Passwort raten.
Die „Einheitslösung“: Wenn ein Gericht falsch zubereitet wurde, sagen die alten Systeme einfach: „Oh, es ist kaputt, versuch es nochmal“, ohne zu prüfen, wie es kaputtgegangen ist. Ist der Topf angebrannt? Wurde das Salz vergessen? Wurde die falsche Pfanne verwendet? All diese Fehler erfordern unterschiedliche Korrekturen, aber das alte System behandelt sie alle gleich.
Der falsche Gewinner: Manchmal liegt das korrekte Gericht tatsächlich in dem Stapel von 16 Gerichten, aber die Menge stimmt für das falsche Gericht, weil sie auf die falschen Dinge achten (wie etwa den Geschmack im Vergleich zur Zutatenliste).

Die SIRIUS-SQL Lösung: Ein Chefkoch und ein Generalist
SIRIUS-SQL löst diese Probleme mit einer dreiteiligen Strategie:

1. Der „Spezialist“ und der „Generalist“ (Das Problem der Echokammer lösen)

Anstatt denselben Roboter 16 Mal kochen zu lassen, setzen sie zwei verschiedene Köche ein:

Der Spezialist (SIRIUS-32B): Dies ist ein Roboter, der speziell auf das Kochen (SQL) trainiert wurde. Er wurde mittels eines speziellen „Belohnungssystems“ (Reinforcement Learning) trainiert, bei dem er nur dann eine Belohnung erhält, wenn das Gericht tatsächlich gelingt. Er lernt, viele verschiedene Versionen des korrekten Gerichts zu erstellen, nicht nur denselben Fehler zu wiederholen.
Der Generalist: Dies ist ein superintelligenter, vielseitiger Roboter (wie ein berühmtes KI-Modell), der gut darin ist, schwierige Sprache und seltsame Anweisungen zu verstehen.
Das Ergebnis: Durch die Kombination des tiefen Fachwissens des Spezialisten mit dem breiten Verständnis des Generalisten erhalten sie eine viel größere Vielfalt an Versuchen. Es ist, als würde man einen Meister-Sushi-Koch und einen kreativen französischen Koch zusammenbringen; man hat eine bessere Chance, dass einer von ihnen das Rezept perfekt trifft.

2. Das „Triage-Pflegekraft“-System (Das Problem der Einheitslösung lösen)

Wenn ein Gericht falsch zubereitet wurde, sagt SIRIUS-SQL nicht einfach nur „versuch es nochmal“. Es agiert wie eine Triage-Pflegekraft in einem Krankenhaus und diagnostiziert genau, was schiefgelaufen ist:

Laufzeitfehler (Der Topf ist angebrannt): Der Roboter hat versucht, ein Werkzeug zu benutzen, das nicht existiert. Das System korrigiert die Syntax sofort.
Timeout (Der Herd ist zu langsam): Das Rezept ist zu kompliziert und dauert zu lange. Das System schreibt das Rezept effizienter um, ohne den Geschmack zu verändern.
Leeres Ergebnis (Die Pfanne ist leer): Der Roboter hat das Rezept perfekt befolgt, aber das Ergebnis ist leer, weil er nach der falschen Zutat gesucht hat. Das System versucht spezifische „strukturelle“ Korrekturen, um die richtige Zutat zu finden.

Erst nachdem der Roboter diese spezifischen Korrekturen durchgeführt hat, darf er es erneut versuchen. Dies spart Zeit und verhindert, dass das System Mühe mit unmöglichen Korrekturen verschwendet.

3. Der „Kluge Richter“ (Das Problem des falschen Gewinners lösen)

Schließlich, wenn es an der Zeit ist, das beste Gericht aus dem Stapel auszuwählen, nutzt das System einen zweistufigen Abstimmungsprozess:

Schritt 1: Die Geschmacksprüfung: Es betrachtet die tatsächlichen Ergebnisse. Wenn 10 Gerichte denselben Geschmack haben, erhalten sie eine hohe Punktzahl.
Schritt 2: Der Tie-Breaker (Entscheidung bei Gleichstand): Wenn zwei Gruppen von Gerichten die gleiche Geschmacksbewertung haben, rät das System nicht einfach. Es betrachtet den „Bauplan“ (die Struktur) der Rezepte. Es fragt: „Haben mehrere verschiedene Köche (der Spezialist und der Generalist) unabhängig voneinander denselben Bauplan erstellt?“ Wenn ja, ist dieser Bauplan höchstwahrscheinlich der wahre Gewinner.

Die Ergebnisse
Durch den Einsatz dieses „Spezialist + Generalist“-Teams, des „Triage-Pflegekraft“-Reparatursystems und des „Klugen Richters“ wurde SIRIUS-SQL zum Besten in seinem Fach.

Beim BIRD-Test (einem schwierigen Test mit echten, unordentlichen Daten) erreichte es eine Genauigkeit von 75,88 % und schlug damit das bisher beste System.
Beim SPIDER-Test (einem Standardtest) erreichte es eine Genauigkeit von 91,20 %.

Kurz gesagt: SIRIUS-SQL verlässt sich nicht mehr darauf, dass ein einzelner Roboter 16 Mal rät. Stattdessen setzt es ein Team aus verschiedenen Experten ein, diagnostiziert spezifische Fehler, um sie richtig zu beheben, und nutzt ein kluges, mehrstufiges Abstimmungssystem, um die eine wahre Antwort zu finden.

Technisches Resümee: SIRIUS-SQL

Problemstellung

Text-to-SQL-Systeme haben Schwierigkeiten mit komplexen Schemata in realen Datenbanken, da die Generierung in einem einzigen Durchgang aufgrund von Schema-Heterogenität, impliziten Constraints und mehrdeutigen Wert-Referenzen oft fehlschlägt. Während jüngere Ansätze dies durch die Generierung mehrerer SQL-Kandidaten und die Verwendung von Voting zur Filterung von Fehlern mildern, identifiziert das Paper drei gekoppelte strukturelle Schwächen bestehender Multi-Kandidaten-Pipelines:

Abnehmender Grenznutzen beim Sampling (L1): Das Sampling von mehr Kandidaten aus einem einzelnen Generator liefert zunehmend redundante Ausgaben, da die Verteilung des Generators durch sein Training fixiert ist. Die bloße Erhöhung des Sample-Budgets ( $k$ ) führt nicht zuverlässig dazu, neue, korrekte Hypothesen außerhalb der bevorzugten Region des Generators aufzuspüren.
Verschwendetes Ausführungssignal (L2): Bestehende Pipelines wenden eine einzige, generische Korrekturstrategie auf alle nicht-sauberen Ausführungsergebnisse an. Unterschiedliche Fehlermodi – Laufzeitfehler (Syntax-/Typ-Mismatch), Timeouts (ineffiziente Pläne) und leere Ergebnisse (semantische Drift) – deuten jedoch auf unterschiedliche Distanzen zur Korrektheit hin und erfordern distinkte Reparaturstrategien.
Voting–Oracle-Gap (L3): Selbst wenn der korrekte SQL innerhalb des Kandidatenpools existiert, scheitert das Mehrheits-Voting oft bei der Auswahl. Dies geschieht, weil die Selektion eine gemeinsame Beurteilung in zwei Räumen erfordert: dem Ergebnisraum (wo verschiedene SQLs identische Ausgaben liefern können) und dem Logikraum (wo dieselbe Intention viele Oberflächenformen zulässt). Bestehende Selektoren operieren typischerweise nur in einem dieser Räume.

Methodik: SIRIUS-SQL

SIRIUS-SQL adressiert diese Limitationen, indem es jede Stufe der Pipeline in der Ausführungsrückmeldung verankert. Das System besteht aus drei Kernkomponenten:

1. Komplementäre Kandidatenkonstruktion aus Quellen

Um den abnehmenden Grenznutzen (L1) zu überwinden, konstruiert das System einen initialen Kandidatenpool aus zwei komplementären Quellen:

Spezialist ( $G_{sp}$ ): Ein auf die Aufgabe spezialisiertes Modell (SIRIUS-32B), das mittels Reinforcement Learning from Verifiable Execution Rewards (RLVR) trainiert wurde. Das Training nutzt eine schwierigkeitsgeglättete Datensynthese-Strategie, um sich auf Instanzen zu konzentrieren, bei denen die Policy sich verbessern kann, sowie ein Zweistufen-DAPO-Schema mit schwellenwertgesteuerter Entropie-Regularisierung, um einen Entropie-Kollaps zu verhindern und gleichzeitig diverse, ausführbare Kandidaten beizubehalten.
Generalist ( $G_{ge}$ ): Ein leistungsstarkes Standard-LLM (z. B. Qwen3-235B, Gemini-3.1), das mittels Few-Shot-Demonstrationen gepromptet wird, um Long-Tail-Formulierungen und implizite Constraints abzudecken, die der Spezialist möglicherweise übersieht.
Die Vereinigung dieser Quellen stellt sicher, dass die Kandidaten unterschiedliche Fehlermodi offenlegen, was die Fehlerkorrelation reduziert.

2. Ausführungsbasierter Kandidaten-Lebenszyklus

Anstatt die Ausführung lediglich als finalen binären Check zu behandeln, nutzt das System Ausführungsergebnisse, um eine dynamische Reparaturschleife voranzutreiben (L2):

Pre-execution Screening: Deterministische regelbasierte Filter entfernen fehlerhaftes SQL (z. B. Syntaxfehler, Schema-Mismatches) vor der Ausführung, um das Reparatur-Budget zu schonen.
Diagnose & Typisierung: Überlebende Kandidaten werden ausgeführt und in vier Kategorien klassifiziert: clean (sauber), runtime error (Laufzeitfehler), timeout (Zeitüberschreitung) und empty result (leeres Ergebnis).
Typspezifische Reparatur:
- Runtime Errors: Der Exception-Text der Engine wird unverändert an einen Korrektor übergeben.
- Timeouts: Das Rewrite bewahrt die Intention, restrukturiert jedoch Join-Reihenfolgen oder Subquery-Formen, um die Effizienz zu steigen.
- Empty Results: Ein zweistufiger Ansatz wird verwendet: Zuerst versuchen hochpräzise strukturelle Operatoren (z. B. Literal-Re-Binding, Prädikat-Anpassung) eine lokale Rekonstruktion; falls dies fehlschlägt, wird ein diagnosebedingter LLM-Fallback ausgelöst.
Pool-Konsolidierung: Reparierte Kandidaten werden erneut ausgeführt und wieder in den Pool aufgenommen. Falls der Pool kollabiert, nutzt ein Recovery-Generator kondensiertes negatives Feedback, um Kandidaten neu zu generieren.

3. Vertrauens-gesteuerter Hybrid-Selektor

Um den Voting–Oracle-Gap (L3) zu schließen, setzt das System einen zweistufigen Selektor ein, der Ergebnis- und Logiksignale kombiniert:

Stufe 1 (Ergebnis-basiertes Scoring): Berechnet einen groben Score ( $S_{coarse}$ $S_{co a r se}$ ) durch Summation von:
- Tupel-basierter Konsens ( $S_{maj}$ ): Häufigkeit von zellweisen Tripeln über den Kandidatensatz hinweg.
- Positions-debiasierter paarweiser Präferenz ( $S_{rm}$ ): Ein LLM-Judge vergleicht Repräsentanten von Ergebnis-Signatur-Äquivalenzklassen, um die Logikqualität zu ranken.
Stufe 2 (Struktureller Support-Reranker): Ein Vertrauens-gesteuerter Mechanismus. Wenn die Top-Kandidaten über alle Signale hinweg Gleichstand aufweisen (geringe Marge), greift ein deterministischer, LLM-freier Reranker ein. Er analysiert die AST-basierte strukturelle Signatur (Tabellen, Projektionen, Aggregationen) und wählt den Kandidaten aus, der von den meisten distinkten Provenienz-Gruppen unterstützt wird (Cross-Generator-Agreement). Dies dient als kostenloser Tie-Breaker.

Zentrale Beiträge

Difficulty-Smoothed RL Recipe: Eine Trainingsmethodik für SIRIUS-32B, die eine breite, aber reward-validierte Kandidatenverteilung erzeugt und somit den abnehmenden Grenznutzen beim Sampling effektiv mildert.
Execution-Grounded Lifecycle: Ein Reparatur-Framework, das Ausführungsergebnisse klassifiziert und gezielte, typspezifische Reparaturen (Runtime, Timeout, Empty) anwendet, bevor Kandidaten wieder zugelassen werden, wodurch der Nutzen der Ausführungssignale maximiert wird.
Confidence-Gated Hybrid Selector: Ein Selektionsmechanismus, der Tupel-Konsens mit paarweiser SQL-Präferenz fusioniert und nur ambivalente Fälle an einen deterministischen strukturellen Check eskaliert, wodurch der Voting–Oracle-Gap ohne übermäßigen Rechenaufwand gelöst wird.

Ergebnisse

SIRIUS-SQL erreicht State-of-the-Art Performance auf Standard-Benchmarks:

BIRD Dev: 75,88 % Execution Accuracy (unter Verwendung von SIRIUS-32B + Gemini-3.1 Pro), womit es das stärkste veröffentlichte Multi-Kandidaten-System, Agentar-Scale-SQL (74,90 %), um 0,98 Prozentpunkte übertrifft. Es zeigt zudem signifikante Gewinne gegenüber Single-Pass-Baselines (z. B. +11,54 % gegenüber Qwen3-Coder).
SPIDER Test: 91,20 % Execution Accuracy, was eine starke Generalisierung ohne aufgabenspezifisches Retuning demonstriert.
Ablationsstudien:
- Die schwierigkeitsgeglättete Datensynthese verbesserte die Validierungs-Rewards während des Trainings um 1,8 pp auf BIRD und um 0,5 pp auf SPIDER.
- Die komplementäre Kandidatenkonstruktion (Spezialist + Generalist) übertraf das Scaling einzelner Quellen, was beweist, dass diverse Fehlermodi wertvoller sind als die reine Anzahl der Samples.
- Der typspezifische Lebenszyklus übertraf vereinheitlichte Korrekturstrategien um 0,13–0,71 pp.
- Der Hybrid-Selektor (Merge + Gate) lieferte einen Gewinn von 0,20 pp gegenüber Single-Signal-Selektoren, primär durch die Lösung von Low-Margin-Tie-Breaks.

Bedeutung

Das Paper argumentiert, dass der primäre Flaschenhals bei Multi-Kandidaten-Text-to-SQL nicht die Generierung von mehr Kandidaten ist, sondern die systematische Unterausnutzung von Ausführungssignalen in Training, Reparatur und Selektion. Durch die Verankerung der gesamten Pipeline in der Ausführungsrückmeldung – das Training eines Spezialisten zur Erzeugung diverser ausführbarer Kandidaten, die Reparatur von Fehlern basierend auf spezifischen Fehlertypen und die Selektion basierend auf einem Hybrid aus Ergebnis-Konsens und struktureller Logik – zeigt SIRIUS-SQL, dass die ausführungsbasierte Verfeinerung ein entscheidender Hebel zur Verbesserung der Zuverlässigkeit bei komplexen Schemata ist. Die Fähigkeit des Systems, starke Baselines mit zwei von drei Generalisten-Paarungen zu übertreffen, deutet auf eine robuste, partner-agnostische Architektur für hochsensible Text-to-SQL-Anwendungen hin.