Resumo Técnico: O que Prediz a Correção em Text-to-SQL? Um Estudo de Predição Seletiva

Definição do Problema

O artigo aborda o problema da predição seletiva em sistemas text-to-SQL: determinar quando uma consulta SQL gerada é correta o suficiente para ser executada e quando o sistema deve se abster. A correção é definida no sentido padrão de benchmark: a consulta gerada deve retornar o mesmo conjunto de resultados que uma consulta de referência escrita por um humano ao ser executada contra o banco de dados. O objetivo é estimar a probabilidade de correção ($P(\text{correto})$) para permitir que um sistema escolha entre responder ou recusar, em vez de iterativamente melhorar a consulta (autocorreção).

Metodologia

O estudo avalia vários sinais para prever a correção em tarefas de text-to-SQL de múltiplas tabelas "difíceis" usando dois benchmarks: BIRD (800 perguntas, 8 bancos de dados) e Spider (490 perguntas, 20 bancos de dados).

Sinais Avaliados

Os autores categorizam os sinais em dois grupos:

1. Sinais Estatísticos de Caixa-Preta: Estes dependem das estatísticas de saída do gerador sem raciocínio externo.
   • Autoconsistência: Agrupamento por string (consultas idênticas), estrutural (estrutura canônica) e de execução (conjunto de resultados).
   • Relevância do Esquema: Similaridade de embedding entre a pergunta e as tabelas/colunas utilizadas.
   • Executabilidade: Se a consulta roda e retorna linhas.
   • Log-Probabilidade de Caixa-Branca: A média da log-probabilidade da sequência da consulta gerada.
2. Sinais Baseados em Verificação: Envolvem um modelo separado (juiz LLM) inspecionando a pergunta, o esquema, a evidência e a consulta candidata para julgar a correção.
   • Juízes: GPT-4o-mini, GPT-4o e Claude-Sonnet-4.6.
   • Ensemble: Uma combinação das pontuações do GPT-4o e do Claude.
   • Verificadores Treinados: Modelos encoder e generativos ajustados (Qwen2.5-1.5B/7B) em pares rotulados por execução.

Métricas de Avaliação

• AUROC: Área sob a curva ROC, medindo a capacidade de classificar consultas corretas acima das incorretas.
• Calibração: Erro de Calibração Esperada (ECE).
• Predição Seletiva: Fronteiras de risco-cobertura (taxa de erro entre perguntas respondidas vs. fração de perguntas respondidas).
• Significância Estatística: Intervalos de confiança de bootstrap pareado (2.000 amostras) para determinar se as diferenças entre os sinais são significativas.

Resultados Principais

1. O Teto da Caixa-Preta

Os sinais estatísticos de caixa-preta e a log-probabilidade de caixa-branca estagnam em uma faixa de desempenho estreita, falhando em distinguir de forma confiável consultas corretas de incorretas em tarefas de múltiplas tabelas difíceis.

• Faixa de Desempenho: AUROC entre 0,61 e 0,68.
• Sinal de Caixa-Preta Mais Forte: Autoconsistência de string (AUROC 0,675).
• Log-Probabilidade: Semelhante à autoconsistência (0,669), sem diferença significativa.
• Executabilidade: Essencialmente o acaso (0,500), pois consultas incorretas frequentemente executam com sucesso.
• Conclusão: Esses sinais medem consistência interna ou alinhamento de esquema, mas falham em detectar erros lógicos de computação ou composição.

2. A Verificação Rompe o Teto

Sinais baseados em verificação superam significativamente os baselines de caixa-preta ao raciocinar sobre se a lógica do SQL corresponde à pergunta.

• Juízes Individuais:
  • GPT-4o-mini: 0,724 AUROC.
  • GPT-4o: 0,770 AUROC.
  • Claude-Sonnet-4.6: 0,776 AUROC.
• Ensemble: Combinar GPT-4o e Claude (que cometem erros diferentes, correlação $r=0,43$) produz o melhor sinal: 0,822 AUROC com excelente calibração (ECE 0,031).
• Robustez: Este padrão se mantém em diferentes geradores (GPT-4o-mini vs. GPT-4.1-mini) e benchmarks (BIRD e Spider).

3. Verificadores Treinados: In-Distribution vs. Transferência

O estudo investiga se um verificador mais barato e ajustado pode substituir o juiz LLM congelado.

• In-Distribution: Modelos ajustados (encoders e juízes generativos) performam bem em esquemas vistos, atingindo 0,77–0,80 AUROC.
• Transferência de Esquema (Cross-Schema): Quando testados em bancos de dados não vistos (Leave-One-Database-Out), o desempenho cai significativamente para ~0,66 AUROC.
• Escalabilidade e Destilação: Aumentar o tamanho do modelo (1.5B para 7B), adicionar diversidade de esquema, destilar racionalidades ou treinamento entre benchmarks falhou em fechar a lacuna de transferência.
• Conclusão: Verificadores ajustados capturam regularidades superficiais específicas do esquema em vez de um raciocínio robusto entre esquemas. Para configurações abertas/cross-schema, um grande modelo de raciocínio congelado continua sendo superior.

4. Predição Seletiva e Abstenção

• Autoconsistência: Não consegue formar um subconjunto de baixo risco válido; mesmo suas previsões mais confiantes são propensas demais a erros para uma abstenção segura.
• Ensemble de Verificação: Permite uma abstenção útil. Por exemplo, em um risco alvo de 0,30, o ensemble responde 27% das perguntas com um risco seletivo retido de 0,24.
• Baseline de Autocorreção: Uma única rodada de autocorreção mal melhora a precisão (0,451 para 0,468) e produz uma confiança severamente descalibrada (média 0,97, ECE 0,501), confirmando que a regeneração não substitui a necessidade de um verificador calibrado.

5. Análise de Erros

O artigo identifica que os principais modos de falha em text-to-SQL difícil são computação e composição (razões, porcentagens, lógica condicional, agrupamento, aninhamento), não o link de esquema ou contagem de joins.

• Scores de relevância de esquema são fracos porque os geradores frequentemente identificam as tabelas corretas, mas falham na lógica.
• Verificadores se destacam porque avaliam a computação expressa pelo SQL contra a pergunta.
• A vantagem do verificador é mais pronunciada em questões aritméticas (AUROC 0,813) e consultas simples onde a autoconsistência é frequentemente errônea apesar de confiante.

Significância e Alegações

O artigo afirma que para tarefas de text-to-SQL difíceis:

1. A incerteza de correção é real, mas não é capturada por sinais baratos. Concordância de amostragem, consistência estrutural e log-probabilidade são insuficientes para implantação de alto risco.
2. O raciocínio é necessário. Os únicos sinais que rompem o teto de performance são aqueles que explicitamente raciocinam sobre a lógica da consulta (verificação).
3. Os regimes de implantação diferem.
   • Fixo/In-Domain: Um verificador ajustado é uma ferramenta de custo-benefício e precisão para abstenção.
   • Aberto/Cross-Schema: Um grande modelo de raciocínio congelado (juiz LLM) é atualmente necessário para generalização confiável.
4. Ensembles melhoram a confiabilidade. Combinar juízes independentes (provedores diferentes) produz o sinal mais calibrado e discriminativo, sugerindo que a incerteza de verificação não é um artefato de uma única família de modelos.
5. Autocorreção não é um substituto. Mesmo sistemas que regeneram consultas precisam de um verificador calibrado ao final do pipeline para decidir se confiam no output final.

O estudo conclui que, se um sistema deve decidir se pode confiar em um SQL gerado, ele deve investir em um verificador consciente da lógica e calibrá-lo para predição seletiva, em vez de confiar na confiança de amostragem.