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

Sintesi Tecnica: SIRIUS-SQL

Definizione del Problema

I sistemi Text-to-SQL faticano con schemi complessi in database reali, dove la generazione a passaggio singolo spesso fallisce a causa dell'eterogeneità dello schema, dei vincoli impliciti e dell'ambiguità dei riferimenti ai valori. Sebbene approcci recenti mitigino questo problema generando molteplici candidati SQL e utilizzando il voto per filtrare gli errori, il documento identifica tre debolezze strutturali accoppiate nelle pipeline multi- candidato esistenti:

1. Campionamento a Rendimenti Decrescenti (L1): Campionare più candidati da un singolo generatore produce output via via ridondanti perché la distribuzione del generatore è fissata dal suo addestramento. Semplicemente aumentare il budget di campionamento ($k$) non riesce a far emergere in modo affidabile nuove ipotesi corrette al di fuori della regione preferita dal generatore.
2. Segnale di Esecuzione Sprecato (L2): Le pipeline esistenti applicano una singola strategia di correzione generica a tutti i risultati di esecuzione non puliti. Tuttavia, diversi modi di fallimento — errori di runtime (errori di sintassi/mismatch di tipo), timeout (piani inefficienti) e risultati vuoti (drift semantico) — indicano diverse distanze dalla correttezza e richiedono strategie di riparazione distinte.
3. Gap Voto-Oracolo (L3): Anche quando l'SQL corretto esiste all'interno del pool di candidati, il voto a maggioranza spesso fallisce nel selezionarlo. Ciò accade perché la selezione richiede un giudizio congiunto in due spazi: lo spazio dei risultati (dove diversi SQL possono produrre output identici) e lo spazio della logica (dove la stessa intenzione ammette molte forme superficiali). I selettori esistenti operano tipicamente in uno solo di questi spazi.

Metodologia: SIRIUS-SQL

SIRIUS-SQL affronta queste limitazioni ancorando ogni fase della pipeline al feedback di esecuzione. Il sistema consiste di tre componenti principali:

1. Costruzione di Candidati Complementari alla Sorgente

Per superare i rendimenti decrescenti (L1), il sistema costruisce un pool iniziale di candidati da due fonti complementari:

• Specialista ($G_{sp}$): Un modello specializzato nel compito (SIRIUS-32B) addestrato con Reinforcement Learning from Verifiable Execution Rewards (RLVR). L'addestramento impiega una strategia di sintesi dei dati con smoothing della difficoltà per concentrarsi sugli istanze in cui la policy può migliorare, e uno schema DAPO a due stadi con regolarizzazione dell'entropia a soglia per prevenire il collasso dell'entropia pur mantenendo diversi candidati eseguibili.
• Generalista ($G_{ge}$): Un LLM forte e off-the-shelf (es. Qwen3-235B, Gemini-3.1) istruito tramite dimostrazioni few-shot per coprire espressioni a coda lunga e vincoli impliciti che lo specialista potrebbe mancare.
  L'unione di queste fonti assicura che i candidati espongano diversi modi di fallimento, riducendo la correlazione degli errori.

2. Ciclo di Vita del Candidato Ancorato all'Esecuzione

Inveve di trattare l'esecuzione come un controllo binario finale, il sistema utilizza gli esiti dell'esecuzione per guidare un ciclo di riparazione dinamico (L2):

• Screening Pre-esecuzione: Filtri deterministici basati su regole rimuovono SQL malformati (es. errori di sintassi, mismatch di schema) prima dell'esecuzione per risparmiare il budget di riparazione.
• Diagnosi e Tipizzazione: I candidati sopravvissuti vengono eseguiti e classificati in quattro categorie: puliti, errore di runtime, timeout e risultato vuoto.
• Riparazione Specifica per Tipo:
  • Errori di Runtime: Il testo dell'eccezione del motore viene fornito verbatim a un correttore.
  • Timeout: La riscrittura preserva l'intento ma ristruttura l'ordine dei join o le forme delle subquery per migliorare l'efficienza.
  • Risultati Vuoti: Viene utilizzato un approccio a due stadi: prima, operatori strutturali ad alta precisione (es. ri-legame di letterali, aggiustamento dei predicati) tentano il recupero locale; se ciò fallisce, viene attivato un fallback LLM condizionato dalla diagnosi.
• Consolidamento del Pool: I candidati riparati vengono rieseguiti e ri-ammessi al pool. Se il pool collassa, un generatore di recupero utilizza feedback negativi condensati per rigenerare i candidati.

3. Selezione Ibrida con Soglia di Confidenza

Per colmare il gap voto-oracolo (L3), il sistema impiega un selettore a due stadi che combina segnali a livello di risultato e a livello di logica:

• Fase 1 (Scorer a Livello di Risultato): Calcola un punteggio grossolano ($S_{coarse}$) sommando:
  • Consenso a Livello di Tupla ($S_{maj}$): Frequenza delle triple a livello di cella attraverso il set di candidati.
  • Preferenza a Coppie Debiased sulla Posizione ($S_{rm}$): Un giudice LLM confronta i rappresentanti delle classi di equivalenza della firma del risultato per classificare la qualità della logica.
• Fase 2 (Reranker di Supporto Strutturale): Un meccanismo a soglia di confidenza. Se i candidati in cima sono in parità tra tutti i segnali (basso margine), interviene un reranker deterministico, privo di LLM. Esso analizza la firma strutturale a livello di AST (tabelle, proiezioni, aggregazioni) e seleziona il candidato supportato dal maggior numero di gruppi di provenienza distinti (accordo tra generatori). Questo funge da elemento di spareggio a costo zero.

Contributi Chiave

1. Ricetta RL con Smoothing della Difficoltà: Una metodologia di addestramento per SIRIUS-32B che produce una distribuzione di candidati ampia ma validata dai reward, mitigando efficacemente i rendimenti decrescenti nel campionamento.
2. Ciclo di Vita Ancorato all'Esecuzione: Un framework di riparazione che classifica gli esiti dell'esecuzione e applica riparazioni mirate e specifiche per tipo (runtime, timeout, vuoto) prima di riammettere i candidati, massimizzando l'utilità dei segnali di esecuzione.
3. Selettore Ibrido con Soglia di Confidenza: Un meccanismo di selezione che fonde il consenso a livello di tupla con la preferenza pairwise dell'SQL, elevando solo i casi ambigui a un controllo strutturale deterministico, risolvendo così il gap voto-oracolo senza costi computazionali eccessivi.

Risultati

SIRIUS-SQL raggiunge prestazioni allo stato dell'arte sui benchmark standard:

• BIRD Dev: 75.88% di accuratezza di esecuzione (usando SIRIUS-32B + Gemini-3.1 Pro), superando il più forte sistema multi- candidato pubblicato, Agentar-Scale-SQL (74.90%), di 0.98 punti percentuali. Mostra anche guadagni significativi rispetto ai baseline a passaggio singolo (es. +11.54% rispetto a Qwen3-Coder).
• SPIDER Test: 91.20% di accuratezza di esecuzione, dimostrando una forte generalizzazione senza retuning specifico per il compito.
• Studi di Ablazione:
  • La sintesi dei dati con smoothing della difficoltà ha migliorato i reward di validazione di 1.8 pp su BIRD e 0.5 pp su SPIDER durante l'addestramento.
  • La costruzione di candidati complementari (Specialista + Generalista) ha superato la scalabilità a singola sorgente, provando che modi di fallimento diversi sono più preziosi di un semplice aumento del numero di campioni.
  • Il ciclo di vita specifico per tipo ha superato le strategie di correzione unificate di 0.13–0.71 pp.
  • Il selettore ibrido (merge + gate) ha fornito un guadagno di 0.20 pp rispetto ai selettori a singolo segnale, principalmente risolvendo i pareggi a basso margine.

Significato

Il paper sostiene che il collo di bottiglia primario nel multi- candidato Text-to-SQL non sia la generazione di più candidati, ma l'uso sistematico insufficiente dei segnali di esecuzione durante l'addestramento, la riparazione e la selezione. Ancorando l'intera pipeline al feedback di esecuzione — addestrando uno specialista per produrre candidati eseguibili diversificati, riparando i fallimenti in base ai tipi specifici di errore e selezionando sulla base di un ibrido tra consenso dei risultati e logica strutturale — SIRIUS-SQL dimostra che il raffinamento ancorato all'esecuzione è un leva critica per migliorare l'affidabilità su schemi complessi. La capacità del sistema di superare i forti baseline con due delle tre combinazioni con generalisti suggerisce un'architettura robusta e agnostica rispetto al partner per applicazioni Text-to-SQL ad alto rischio.