🤖 AI

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

O SIRIUS-SQL é um novo framework de Text-to-SQL que melhora a precisão em esquemas complexos ao abordar as limitações de sistemas de múltiplos candidatos existentes por meio de uma estratégia de treinamento de RL de suavização de dificuldade para geração diversificada, um ciclo de vida baseado em execução para reparo de erros direcionado e um seletor híbrido com portão de confiança, alcançando desempenho de estado da arte nos benchmarks BIRD e SPIDER.

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

Publicado 2026-06-02

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

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

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando dar uma instrução muito específica e complexa a um robô chef (a IA) para cozinhar uma refeição (escrever uma consulta SQL) com base em um livro de receitas enorme e bagunçado (o banco de dados).

Se você pedir ao robô para cozinhar apenas uma vez, ele frequentemente comete erros porque o livro de receitas é confuso, os ingredientes têm nomes estranhos ou as instruções são vagas.

O Jeito Antigo: O Problema do "Voto da Multidão"
Recentemente, outros sistemas tentaram corrigir isso pedindo ao robô para cozinhar a refeição 16 vezes em vez de apenas uma. Depois, eles olhavam para os 16 pratos e escolhiam aquele em que a maioria concordava (votação por maioria).

Os autores deste artigo, SIRIUS-SQL, dizem que essa abordagem de "voto da multidão" tem três grandes problemas:

A Câmara de Eco: Se você pedir ao mesmo robô para cozinhar 16 vezes, ele continuará cometendo os mesmos 16 erros. É como pedir a uma única pessoa para adivinhar uma senha 16 vezes; ela provavelmente errará a mesma coisa repetidamente.
A Correção "Tamanho Único": Quando um prato sai errado, os sistemas antigos apenas dizem: "Ah, está quebrado, tente novamente", sem olhar para como ele quebrou. A panela queimou? Esqueceram o sal? Usaram a panela errada? Todos esses problemas precisam de correções diferentes, mas o sistema antigo trata todos da mesma forma.
O Vencedor Errado: Às vezes, o prato correto está de fato na mesa, no meio dos 16, mas a multidão vota no errado porque está olhando para as coisas erradas (como o sabor versus a lista de ingredientes).

A Solução SIRIUS-SQL: Um Mestre Chef e um Generalista
O SIRIAS-SQL corrige esses problemas com uma estratégia de três partes:

1. O "Especialista" e o "Generalista" (Corrigindo a Câmara de Eco)

Em vez de pedir a um robô para cozinhar 16 vezes, eles usam dois chefs diferentes:

O Especialista (SIRIUS-32B): Este é um robô treinado especificamente para cozinhar (SQL). Ele foi ensinado usando um sistema especial de "recompensa" (Aprendizado por Reforço) onde só ganha um agrado se o prato realmente funcionar. Ele aprende a fazer muitas versões diferentes do prato correto, não apenas o mesmo erro.
O Generalista: Este é um robô superinteligente e de uso geral (como um modelo de IA famoso) que é bom em entender linguagens complicadas e instruções estranhas.
O Resultado: Ao combinar o conhecimento profundo do Especialista com a compreensão ampla do Generalista, eles obtêm uma variedade muito maior de tentativas. É como ter um mestre sushiman e um chef francês criativo trabalhando juntos; você tem uma chance melhor de um deles acertar a receita.

2. O Sistema de "Enfermeira de Triagem" (Corrigindo o "Tamanho Único")

Quando um prato sai errado, o SIRIUS-SQL não diz apenas "tente novamente". Ele age como uma enfermeira de triagem em um hospital, diagnosticando exatamente o que deu errado:

Erro de Execução (A Panela Queimou): O robô tentou usar uma ferramenta que não existe. O sistema corrige a sintaxe imediatamente.
Tempo Limite/Timeout (O Fogão é Muito Lento): A receita é complicada demais e leva muito tempo. O sistema reescreve a receita para torná-la mais eficiente sem mudar o sabor.
Resultado Vazio (A Panela está Vazia): O robô seguiu a receita perfeitamente, mas o resultado foi vazio porque ele procurou pelo ingrediente errado. O sistema tenta correções "estruturais" específicas para encontrar o ingrediente certo.

Somente após o robô tentar essas correções específicas é que ele recebe permissão para tentar novamente. Isso economiza tempo e evita que o sistema desperdice esforço em correções impossíveis.

3. O "Juiz Inteligente" (Corrigindo o Vencedor Errado)

Finalmente, quando chega a hora de escolher o melhor prato do monte, o sistema usa um processo de votação de duas etapas:

Passo 1: O Teste de Sabor: Ele olha para os resultados reais. Se 10 pratos tiverem o mesmo sabor, eles recebem uma pontuação alta.
Passo 2: O Desempate: Se dois grupos de pratos tiverem a mesma pontuação de sabor, o sistema não apenas adivinha. Ele olha para o projeto (a estrutura) das receitas. Ele pergunta: "Vários chefs diferentes (o Especialista e o Generalista) chegaram independentemente a este mesmo projeto?". Se sim, esse projeto é provavelmente o verdadeiro vencedor.

Os Resultados
Ao usar esta equipe de "Especialista + Generalista", o sistema de reparo "Enfermeira de Triagem" e o "Juiz Inteligente", o SIRIUS-SQL tornou-se o melhor sistema em seu trabalho.

No teste BIRD (um teste difícil com dados reais bagunçados), ele obteve 75,88% de precisão, superando o sistema anterior mais avançado.
No teste SPIDER (um teste padrão), ele obteve 91,20% de precisão.

Em resumo, o SIRIUS-SQL para de confiar em um único robô adivinhando 16 vezes. Em vez disso, ele utiliza uma equipe de diferentes especialistas, diagnostica erros específicos para corrigi-los adequadamente e usa um sistema de votação inteligente de múltiplas etapas para encontrar a única resposta verdadeira.

Resumo Técnico: SIRIUS-SQL

Declaração do Problema

Sistemas de Text-to-SQL enfrentam dificuldades com esquemas complexos em bancos de dados do mundo real, onde a geração de passagem única frequentemente falha devido à heterogeneidade do esquema, restrições implícitas e referências de valores ambíguas. Embora abordagens recentes mitiguem isso gerando múltiplos candidatos SQL e utilizando votação para filtrar erros, o artigo identifica três fraquezas estruturais acopladas em pipelines de múltiplos candidatos existentes:

Amostragem de Retornos Decrescentes (L1): A amostragem de mais candidatos de um único gerador produz saídas cada vez mais redundantes porque a distribuição do gerador é fixa pelo seu treinamento. Simplesmente aumentar o orçamento de amostras ( $k$ ) não revela de forma confiável novas hipóteses corretas fora da região preferida do gerador.
Sinal de Execução Desperdiçado (L2): Pipelines existentes aplicam uma estratégia de correção única e genérica a todos os resultados de execução não limpos. No entanto, diferentes modos de falha — erros de tempo de execução (erros de sintaxe/tipos), timeouts (planos ineficientes) e resultados vazios (deriva semântica) — indicam diferentes distâncias da correção e exigem estratégias de reparo distintas.
Lacuna Votação–Oráculo (L3): Mesmo quando o SQL correto existe dentro do pool de candidatos, a votação por maioria frequentemente falha em selecioná-lo. Isso ocorre porque a seleção requer um julgamento conjunto em dois espaços: o espaço do resultado (onde diferentes SQLs podem gerar saídas idênticas) e o espaço da lógica (onde a mesma intenção admite muitas formas superficiais). Seletores existentes operam tipicamente em apenas um desses espaços.

Metodologia: SIRIUS-SQL

O SIRIUS-SQL aborda essas limitações ancorando cada estágio do pipeline na retroalimentação (feedback) de execução. O sistema consiste em três componentes principais:

1. Construção de Candidatos Complementares de Origem

Para superar os retornos decrescentes (L1), o sistema constrói um pool inicial de candidatos a partir de duas fontes complementares:

Especialista ( $G_{sp}$ ): Um modelo especializado na tarefa (SIRIUS-32B) treinado com Aprendizado por Reforço com Recompensas de Execução Verificáveis (RLVR). O treinamento utiliza uma estratégia de síntese de dados com suavização de dificuldade para focar em instâncias onde a política pode melhorar, e um cronograma DAPO de dois estágios com regularização de entropia controlada por limiar para evitar o colapso da entropia enquanto mantém candidatos diversos e executáveis.
Generalista ( $G_{ge}$ ): Um LLM forte e pronto para uso (ex: Qwen3-235B, Gemini-3.1) orientado por demonstrações de poucos disparos (few-shot) para cobrir frases de cauda longa e restrições implícitas que o especialista possa perder.
A união dessas fontes garante que os candidatos exponham diferentes modos de falha, reduzindo a correlação de erros.

2. Ciclo de Vida de Candidato Baseado em Execução

Em vez de tratar a execução como uma verificação binária final, o sistema usa os resultados da execução para impulsionar um loop de reparo dinâmico (L2):

Triagem Pré-execução: Filtros determinísticos baseados em regras removem SQL malformado (ex: erros de sintaxe, incompatibilidade de esquema) antes da execução para economizar o orçamento de reparo.
Diagnóstico e Tipagem: Os candidatos sobreviventes são executados e classificados em quatro categorias: limpo, erro de tempo de execução, timeout e resultado vazio.
Reparo Específico por Tipo:
- Erros de Tempo de Execução: O texto da exceção do motor é alimentado literalmente para um corretor.
- Timeouts: A reescrita preserva a intenção, mas reestrutura ordens de junção (join) ou formas de subconsulta para melhorar a eficiência.
- Resultados Vazios: Uma abordagem de dois estágios é utilizada: primeiro, operadores estruturais de alta precisão (ex: revinculação de literais, ajuste de predicados) tentam a recuperação local; se isso falhar, um fallback de LLM condicionado ao diagnóstico é acionado.
Consolidação do Pool: Candidatos reparados são reexecutados e readmitidos no pool. Se o pool colapsar, um gerador de recuperação usa feedback negativo condensado para regenerar candidatos.

3. Seleção Híbrida com Controle de Confiança

Para preencher a lacuna votação-oráculo (L3), o sistema emprega um seletor de dois estágios que combina sinais de nível de resultado e de nível de lógica:

Estágio 1 (Pontuador de Nível de Resultado): Calcula uma pontuação bruta ( $S_{coarse}$ $S_{co a r se}$ ) somando:
- Consenso de Nível de Tupla ( $S_{maj}$ ): Frequência de triplas de nível de célula através do conjunto de candidatos.
- Preferência Pareada Desenviesada de Posição ( $S_{rm}$ ): Um juiz LLM compara representantes de classes de equivalência de assinatura de resultado para classificar a qualidade da lógica.
Estágio 2 (Reclassificador de Suporte Estrutural): Um mecanismo de controle de confiança. Se os principais candidatos estiverem empatados em todos os sinais (baixa margem), um reclassificador determinístico, livre de LLM, intervém. Ele analisa a assinatura estrutural do nível de AST (tabelas, projeções, agregações) e seleciona o candidato apoiado pelo maior número de grupos de proveniência distintos (concordância entre geradores). Isso atua como um desempate de custo zero.

Principais Contribuições

Receita de RL com Suavização de Dificuldade: Uma metodologia de treinamento para o SIRIUS-32B que produz uma distribuição de candidatos ampla, porém validada por recompensa, mitigando efetivamente os retornos decrescentes na amostragem.
Ciclo de Vida Baseado em Execução: Um framework de reparo que classifica resultados de execução e aplica reparos direcionados e específicos por tipo (tempo de execução, timeout, vazio) antes de readmitir candidatos, maximizando a utilidade dos sinais de execução.
Seletor Híbrido com Controle de Confiança: Um mecanismo de seleção que funde o consenso de tupla com a preferência pareada de SQL, escalando apenas casos ambíguos para uma verificação estrutural determinística, resolvendo assim a lacuna votação-oráculo sem custos computacionais excessivos.

Resultados

O SIRIUS-SQL alcança desempenho de estado da arte em benchmarks padrão:

BIRD Dev: 75,88% de acurácia de execução (usando SIRIUS-32B + Gemini-3.1 Pro), superando o sistema de múltiplos candidatos publicado mais forte, Agentar-Scale-SQL (74,90%), por 0,98 pontos percentuais. Também mostra ganhos significativos sobre baselines de passagem única (ex: +11,54% sobre Qwen3-Coder).
SPIDER Test: 91,20% de acurácia de execução, demonstrando forte generalização sem ajuste específico da tarefa.
Estudos de Ablação:
- A síntese de dados com suavização de dificuldade melhorou as recompensas de validação em 1,8 pp no BIRD e 0,5 pp no SPIDER durante o treinamento.
- A construção de candidatos complementares (Especialista + Generalista) superou o escalonamento de fonte única, provando que modos de falha diversos são mais valiosos do que o simples aumento da contagem de amostras.
- O ciclo de vida específico por tipo superou estratégias de correção unificadas em 0,13–0,71 pp.
- O seletor híbrido (fusão + controle) proporcionou um ganho de 0,20 pp sobre seletores de sinal único, principalmente ao resolver empates de baixa margem.

Significância

O artigo argumenta que o principal gargalo no Text-to-SQL de múltiplos candidatos não é a geração de mais candidatos, mas a utilização sistemática insuficiente dos sinais de execução durante o treinamento, reparo e seleção. Ao ancorar todo o pipeline na retroalimentação de execução — treinando um especialista para produzir candidatos executáveis diversos, reparando falhas com base em tipos específicos de erro e selecionando com base em um híbrido de consenso de resultado e lógica estrutural — o SIRIUS-SQL demonstra que o refinamento baseado em execução é um alavancador crítico para melhorar a confiabilidade em esquemas complexos. A capacidade do sistema de superar baselines fortes com dois de três emparelhamentos generalistas sugere uma arquitetura robusta e agnóstica a parceiros para aplicações de Text-to-SQL de alto risco.