🤖 AI

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

SIRIUS-SQL is een nieuw Text-to-SQL-framework dat de nauwkeurigheid op complexe schema's verbetert door de beperkingen van bestaande multi-candidate systemen aan te pakken via een difficulty-smoothing RL-trainingsstrategie voor diverse generatie, een execution-grounded levenscyclus voor gerichte foutreparatie, en een confidence-gated hybride selector, waarmee het state-of-the-art prestaties bereikt op de BIRD- en SPIDER-benchmarks.

Oorspronkelijke auteurs: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Gepubliceerd 2026-06-02

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer specifieke, complexe instructie probele te geven aan een robotkok (de AI) om een maaltijd te bereiden (een SQL-query te schrijven) op basis van een enorm, rommelig receptenboek (de database).

Als je de robot vraagt om het gerecht slechts één keer te bereiden, maakt hij vaak fouten omdat het receptenboek verwarrend is, de ingrediënten vreemd benoemd zijn of de instructies vaag zijn.

De Oude Manier: Het "Crowd Vote"-probleem
Onlangs probeerden andere systemen dit op te lossen door de robot te vragen het gerecht 16 keer te bereiden in plaats van één keer. Vervolgens keken ze naar deze 16 gerechten en kozen ze het gerecht waar de meeste mensen het over eens waren (meerderheidsstemming).

De auteurs van dit paper, SIRIUS-SQL, zeggen dat deze "crowd vote"-aanpak drie grote problemen heeft:

De Echoput: Als je dezelfde robot 16 keer vraat om te koken, blijft hij dezelfde 16 fouten maken. Het is alsoer je één persoon vraagt om 16 keer een wachtwoord te raden; diegene zal waarschijnlijk steeds weer hetzelfde foute wachtwoord raden.
De "One-Size-Fits-All"-oplossing: Wanneer een gerecht mislukt, zeggen de oude systemen alleen maar: "O, het is mislukt, probeer het opnieuw," zonder te kijken naar hoe het misging. Is de pan aangebrand? Is het zout vergeten? Is de verkeerde pan gebruikt? Al deze zaken vereisen verschillende oplossingen, maar het oude systeem behandelt ze allemaal hetzelfde.
De Verkeerde Winnaar: Soms staat het juiste gerecht daadwerkelijk op de tafel tussen de 16 gerechten, maar stemt de menigte voor de verkeerde omdat ze naar de verkeerde dingen kijken (zoals de smaak versus de ingrediëntenlijst).

De SIRIUS-SQL Oplossing: Een Meesterkok en een Generalist
SIRIUS-SQL lost deze problemen op met een drieledige strategie:

1. De "Specialist" en de "Generalist" (Het oplossen van de Echoput)

In plaats van één robot 16 keer te vragen te koken, gebruiken ze twee verschillende chefs:

De Specialist (SIRIUS-32B): Dit is een robot die specifiek is getraind op koken (SQL). Deze is getraind met een speciaal "beloningssysteem" (Reinforcement Learning), waarbij de robot alleen een traktatie krijgt als het gerecht daadwerkelijk werkt. Hierdoor leert de robot veel verschillende versies van het juiste gerecht te maken, in plaats van steeds dezelfde fout te maken.
De Generalist: Dit is een superintelligente, veelzijdige robot (zoals een beroemd AI-model) die goed is in het begrijpen van lastige taal en vreemde instructies.
Het Resultaat: Door de diepe kennis van de Specialist te combineren met het brede begrip van de Generalist, krijgen ze een veel grotere variëteit aan pogingen. Het is alsof je een meester-sushichef en een creatieve Franse chef samen laatwerken; je hebt dan een grotere kans dat een van hen het recept perfect raakt.

2. Het "Triageverpleegkundige"-systeem (Het oplossen van de One-Size-Fits-All)

Wanneer een gerecht mislukt, zegt SIRIUS-SQL niet simpelweg "probeer het opnieuw." Het gedraagt zich als een triageverpleegkundige in een ziekenhuis en diagnosticeert precies wat er misging:

Runtime Error (De pan is aangebrand): De robot probeerde een hulpmiddel te gebruiken dat niet bestaat. Het systeem herstelt direct de syntaxis.
Timeout (Het fornuis is te traag): Het recept is te ingewikkeld en duurt te lang. Het systeem herschrijft het recept om het efficiënter te maken zonder de smaak te veranderen.
Empty Result (De pan is leeg): De robot volgde het recept perfect op, maar het resultaat is leeg omdat er naar het verkeerde ingrediënt werd gezocht. Het systeem probeert specifieke "structurele" verbeteringen om het juiste ingrediënt te vinden.

Pas nadat de robot deze specifieke reparaties heeft geprobeerd, krijgt hij de kans om het opnieuw te proberen. Dit bespaart tijd en voorkomt dat het systeem moeite verspilt aan onmogelijke oplossingen.

3. De "Slimme Rechter" (Het oplossen van de Verkeerde Winnaar)

Ten slotte, wanneer het tijd is om het beste gerecht uit de stapel te kiezen, gebruikt het systeem een tweestaps-stemproces:

Stap 1: De Proeverij: Het kijkt naar de werkelijke resultaten. Als 10 gerechten hetzelfde smaken, krijgen ze een hoge score.
Stap 2: De Beslissende Factor: Als twee groepen gerechten dezelfde smaakscore hebben, gokt het systeem niet zomaar. Het kijkt naar het blauwdruk (de structuur) van de recepten. Het stelt de vraag: "Hebben meerdere verschillende chefs (de Specialist en de Generalist) onafhankelijk van elkaar dezelfde blauwdruk bedacht?" Zo ja, dan is die blauwdruk waarschijnlijk de echte winnaar.

De Resultaten
Door dit team van "Specialist + Generalist", het "Triageverpleegkundige" reparatiesysteem en de "Slimme Rechter" te gebruiken, is SIRIX-SQL de beste in zijn vak geworden.

Op de BIRD-test (een moeilijke test met echte, rommelige data) behaalde het een nauwkeurigheid van 75,88%, waarmee het het vorige beste systeem versloeg.
Op de SPIDER-test (een standaardtest) behaalde het een nauwkeurigheid van 91,20%.

Kortom, SIRIUS-SQL vertrouwt niet langer op één robot die 16 keer gokt. In plaats daarvan zet het een team van verschillende experts in, diagnosticeert specifieke fouten om ze goed te herstellen, en gebruikt een slim, meerstaps stemproces om het ene ware antwoord te vinden.

Technische Samenvatting: SIRIUS-SQL

Probleemstelling

Text-to-SQL-systemen worstelen met complexe schema's in real-world databases, waarbij single-pass generatie vaak faalt door schema-heterogeniteit, impliciete restricties en ambigue waarde-referenties. Hoewel recente benaderingen dit mitigeren door meerdere SQL-kandidaten te genereren en stemmen te gebruiken om fouten te filteren, identificeert het artikel drie gekoppelde structurele zwakheden in bestaande multi-kandidaat-pipelines:

Diminishing-Return Sampling (L1): Het samplen van meer kandidaten uit een enkele generator levert steeds redundantere outputs op omdat de distributie van de generator vaststaat door zijn training. Het simpelweg verhogen van het sample-budget ( $k$ ) levert niet betrouwbaar nieuwe, correcte hypothesen op buiten de geprefereerde regio van de generator.
Wasted Execution Signal (L2): Bestaande pipelines passen een enkele, generieke correctiestrategie toe op alle niet-schone executieresultaten. Echter, verschillende foutmodi—runtime errors (syntax/type mismatches), timeouts (inefficiënte plannen) en lege resultaten (semantische drift)—wijzen op verschillende afstanden tot correctheid en vereisen onderscheidende herstelstrategieën.
Voting–Oracle Gap (L3): Zelfs wanneer de correcte SQL aanwezig is binnen de kandidaat-pool, faalt majority voting vaak bij de selectie. Dit komt doordat selectie een gezamenlijk oordeel vereist in twee ruimtes: de resultaatruimte (waar verschillende SQL's identieke outputs kunnen opleveren) en de logicaruimte (waar dezelfde intentie vele oppervlaktevormen toelaat). Bestaande selectors opereren doorgaans slechts in één van deze ruimtes.

Methodologie: SIRIUS-SQL

SIRIUS-SQL pakt deze beperkingen aan door elke fase van de pipeline te verankeren in executie-feedback. Het systeem bestaat uit drie kerncomponenten:

1. Source-Complementary Candidate Construction

Om de verminderde meeropbrengst (L1) te overwinnen, construeert het systeem een initiële kandidaat-pool vanuit twee complementaire bronnen:

Specialist ( $G_{sp}$ ): Een taakspecifiek model (SIRIUS-32B) getraind met Reinforcement Learning from Verifiable Execution Rewards (RLVR). De training maakt gebruik van een difficulty-smoothed data synthesis strategie om te focussen op instanties waar de policy kan verbeteren, en een two-stage DAPO schedule met threshold-gated entropie-regularisatie om entropy collapse te voorkomen terwijl diverse, uitvoerbare kandidaten behouden blijven.
Generalist ( $G_{ge}$ ): Een krachtig off-the-shelf LLM (bijv. Qwen3-235B, Gemini-3.1) geprompt met few-shot demonstraties om long-tail formuleringen en impliciete restricties te dekken die de specialist mogelijk mist.
De unie van deze bronnen zorgt ervoor dat kandidaten verschillende foutmodi blootleggen, waardoor de foutcorrelatie wordt verminderd.

2. Execution-Grounded Candidate Lifecycle

In plaats van executie te behandelen als een finale binaire controle, gebruikt het systeem executie-uitkomsten om een dynamische reparatieloop aan te sturen (L2):

Pre-execution Screening: Deterministische regelgebaseerde filters verwijderen malafide SQL (bijv. syntaxfouten, schema mismatches) vóór executie om het reparatiebudget te sparen.
Diagnose & Typing: Overlevende kandidaten worden uitgevoerd en geclassificeerd in vier categorieën: clean, runtime error, timeout, en empty result.
Type-Specifieke Reparatie:
- Runtime Errors: De exception-tekst van de engine wordt letterlijk meegegeven aan een corrector.
- Timeouts: De rewrite behoudt de intentie maar restructureert de join-ordes of subquery-vormen om de efficiëntie te verbeteren.
- Empty Results: Een twee-fasen aanpak wordt gebruikt: eerst proberen high-precision structurele operatoren (bijv. literal re-binding, predicate adjustment) lokale herstelacties; als dat faal, wordt een diagnose-geconditioneerde LLM fallback getriggerd.
Pool Consolidatie: Gerepareerde kandidaten worden opnieuw uitgevoerd en opnieuw toegevoegd aan de pool. Als de pool instort, gebruikt een recovery generator gecondenseerde negatieve feedback om kandidaten te regenereren.

3. Confidence-Gated Hybrid Selection

Om de voting-oracle gap (L3) te overbruggen, gebruikt het systeem een twee-fasen selector die zowel resultaat- als logica-signalen combineert:

Fase 1 (Result-Level Scorer): Berekent een grove score ( $S_{coarse}$ $S_{co a r se}$ ) door het sommeren van:
- Tuple-level Consensus ( $S_{maj}$ ): Frequentie van cel-niveau triples over de kandidaat-set.
- Position-Debiased Pairwise Preference ( $S_{rm}$ ): Een LLM-judge vergelijkt representanten van resultaat-signatuur equivalentieklassen om de kwaliteit van de logica te rangschikken.
Fase 2 (Structural-Support Reranker): Een confidence-gated mechanisme. Indien de top-kandidaten een gelijkheid vertonen over alle signalen (lage marge), grijpt een deterministische, LLM-vrije reranker in. Deze analyseert de AST-level structurele signatuur (tabellen, projecties, aggregaties) en selecteert de kandidaat die ondersteund wordt door de meeste distincte provenance-groepen (cross-generator overeenstemming). Dit fungeert als een zero-cost tie-breaker.

Belangrijkste Bijdragen

Difficulty-Smoothed RL Recipe: Een trainingsmethodologie voor SIRIUS-32B die een brede maar reward-gevalideerde kandidaat-distributie produceert, wat de diminishing returns in sampling effectief mitigeert.
Execution-Grounded Lifecycle: Een reparatie-framework dat executie-uitkomsten classificeert en gerichte, type-specifieke reparaties toepast (runtime, timeout, empty) voordat kandidaten opnieuw worden toegelaten, waardoor het nut van executie-signalen wordt gemaximaliseerd.
Confidence-Gated Hybrid Selector: Een selectiemechanisme dat tuple-niveau consensus fuseert met pairwise SQL-preferentie, waarbij alleen ambigue gevallen worden geëscaleerd naar een deterministische structurele check, waardoor de voting-oracle gap wordt opgelost zonder excessieve computationele kosten.

Resultaten

SIRIUS-SQL behaalt state-of-the-art prestaties op standaard benchmarks:

BIRD Dev: 75.88% executie-accuratesse (gebruikmakend van SIRIUS-32B + Gemini-3.1 Pro), waarmee het het sterkste gepubliceerde multi-kandidaat systeem, Agentar-Scale-SQL (74.90%), met 0.98 procentpunt overtreft. Het laat ook significante winst zien ten opzichte van single-pass baselines (bijv. +11.54% over Qwen3-Coder).
SPIDER Test: 91.20% executie-accuratesse, wat sterke generalisatie demonstreert zonder taakspecifieke hertuning.
Ablatie-studies:
- De difficulty-smoothed data synthesis verbeterde de validatie-rewards met 1.8 pp op BIRD en 0.5 pp op SPIDER tijdens de training.
- Complementaire kandidaat-constructie (Specialist + Generalist) presteerde beter dan single-source scaling, wat bewijst dat diverse foutmodi waardevoller zijn dan louter het verhogen van het aantal samples.
- De type-specifieke lifecycle presteerde beter dan uniforme correctiestrategieën met 0.13–0.71 pp.
- De hybride selector (merge + gate) leverde een winst op van 0.20 pp ten opzichte van single-signal selectors, primair door het oplossen van low-margin ties.

Betekenis

Het artikel betoogt dat de primaire bottleneck in multi-kandidaat Text-to-SQL niet het genereren van méér kandidaten is, maar de systematische onderbenutting van executie-signalen tijdens training, reparatie en selectie. Door de gehele pipeline te verankeren in executie-feedback—het trainen van een specialist om diverse uitvoerbare kandidaten te produceren, het repareren van fouten op basis van specifieke fouttypen, en het selecteren op basis van een hybride van resultaat-consensus en structurele logica—demonstreert SIRIUS-SQL dat execution-grounded verfijning een cruciale hefboom is voor het verbeteren van betrouwbaarheid op complexe schema's. Het vermogen van het systeem om sterke baselines te overtreffen met twee van de drie generalist-combinaties suggereert een robuuste, partner-agnostische architectuur voor high-stakes Text-to-SQL applicaties.