Resumo Técnico: DexterSQL

Declaração do Problema

Sistemas de Text-to-SQL baseados em prompting (sem ajuste fino/fine-tuning), que dependem de Grandes Modelos de Linguagem (LLMs) sem modificar seus pesos, enfrentam três desafios persistentes que limitam sua precisão e robustez:

1. Compreensão de Esquema de Grão Grosso: Métodos existentes frequentemente dependem de informações de esquema de nível superficial (nomes de tabelas/colunas) ou amostras de valores, o que falha em distinguir colunas ambíguas com nomes semelhantes, mas papéis semânticos distintos (ex: um "diagnóstico final" vs. um "diagnóstico preliminar").
2. Falhas Recorrentes do Modelo: Os LLMs exibem padrões consistentes de erro (ex: divisão de inteiros em vez de ponto flutuante, falta de conversões de tipo/type casts) que são específicos da lógica de geração do modelo, e não do banco de dados. As abordagens atuais de poucos disparos (few-shot) recuperam exemplos com base em similaridade geral, mas falham em isolar e corrigir esses erros de formulação específicos e recorrentes.
3. Decomposição Ineficaz em Consultas Complexas: Ao decompor perguntas complexas de linguagem natural, os LLMs podem omitir, alucinar ou posicionar incorretamente condições e relacionamentos críticos, levando a um SQL executável que responde a uma pergunta diferente ou incompleta.

Metodologia

O DexterSQL é um sistema de Text-to-SQL sem ajuste fino projetado para enfrentar esses desafios por meio de um pipeline de quatro fases que separa a preparação offline da inferência online. O sistema opera sem atualizar os parâmetros do LLM, baseando-se, em vez disso, na gestão de contexto, exploração de esquema e correção baseada em regras.

Fase 1: Pré-processamento (Offline)

Esta fase prepara artefatos do banco de dados alvo ($D_{target}$) e de um banco de dados de treinamento disjunto ($D_{train}$) antes que qualquer consulta de linguagem natural seja recebida.

• Perfilador de Colunas (Column Profiler): Analisa o $D_{target}$ para construir perfis estatísticos para cada coluna, incluindo cardinalidade, contagens de nulos, valores distintos e amostras representativas.
• Gerador de Índice (Index Generator): Constrói dois índices vetoriais: um índice de perfil ($Index_{prof}$) para recuperação semântica de colunas baseada em suas descrições estatísticas, e um índice de valor ($Index_{val}$) para recuperar valores literais específicos.
• Explorador de Esquema Profundo (Deep Schema Explorator): Identifica pares de colunas genuinamente ambíguos (ex: colunas com nomes semelhantes ou distribuições de valores sobrepostas). Ele realiza uma investigação profunda em suas distribuições de dados individuais e conjuntas (via caminhos de junção/join paths) para calcular métis como cobertura, fan-out e concordância. Um LLM sintetiza essa evidência em notas de desambiguação concisas que explicam os papéis distintos de cada coluna.
• Criador de Regras (Rule Creator): Minera o $D_{train}$ para identificar incompatibilidades recorrentes entre o SQL gerado e o SQL de referência (gold SQL). Ele filtra erros específicos do banco de dados (ex: ligação incorreta de esquema) para isolar padrões de falha agnósticos ao banco de dados (ex: falta de conversões de tipo). Estes são agrupados e sintetizados em regras de correção reutilizáveis.

Fase 2: Ligação de Esquema (Online)

Para cada pergunta de linguagem natural (NLQ) recebida, o sistema constrói um esquema focado.

• Ele recupera colunas semanticamente relevantes usando o índice de perfil e combina valores literais usando o índice de valor.
• Realiza a ligação de esquema bidirecional para garantir que todas as tabelas e colunas necessárias para conectar o esquema sejam incluídas, refinando a seleção inicial para um subconjunto mínimo e relevante.

Fase 3: Geração de SQL (Online)

O DexterSQL emprega uma estratégia de geração de múltiplos caminhos para produzir diversos candidatos a SQL, reduzindo o risco de modos de falha compartilhados entre todos os candidatos.

1. Geração Baseada em Árvore de Dependência: O sistema analisa a NLQ em uma árvore de dependência para preservar as relações estruturais entre os elementos da pergunta. Ele mapeia esta árvore para um esqueleto de SQL intermediário, garantindo que nenhuma condição seja omitida ou alucinada durante a decomposição.
2. Aprendizado em Contexto de Poucos Disparos (Few-Shot In-Context Learning): Recupera exemplos de treinamento estruturalmente similares para guiar o LLM.
3. Dividir e Conquistar (Divide-and-Conquer): Decompõe perguntas complexas em sub-perguntas mais simples, gera SQLs parciais e os compõe.

• Incorporador de Notas (Note Incorporator): Seleciona apenas as notas de desambiguação relevantes para a NLQ atual e as insere no prompt para guiar a seleção de colunas.

Fase 4: Correção e Seleção (Online)

• Correção: Os candidatos passam por verificações sintáticas determinísticas e análise de feedback de execução. Um LLM revisa os candidatos com base em relatórios de diagnóstico. Subsequentemente, o sistema aplica as regras de correção agnósticas ao banco de dados (da Fase 1) para corrigir erros de formulação recorrentes (ex: forçar divisão de ponto flutuante).
• Seleção: Os candidatos corrigidos são executados e agrupados por resultado. O sistema utiliza uma estratégia de seleção consciente de confiança: se uma grande fração dos candidatos concordar com um resultado, esse resultado é selecionado. Caso contrário, um LLM adjudica entre os principais candidatos com base na confiança de execução e consistência lógica com a NLQ.

Principais Contribuições

O artigo introduz três componentes inovadores que coletivamente melhoram o desempenho de Text-to-SQL sem ajuste fino:

1. Explorador de Esquema Profundo (Deep Schema Explorator): Uma ferramenta de análise offline que vai além dos nomes de esquema para analisar distribuições de dados e relações de junção, gerando notas de desambiguação específicas para colunas ambíguas.
2. Criador de Regras Agnóstico ao Banco de Dados (Database-Agnostic Rule Creator): Um mecanismo para minerar, agrupar e sintetizar falhas de geração de LLM recorrentes a partir de dados de treinamento em regras de correção generalizáveis, distintas de erros específicos do banco de dados.
3. Geração de SQL de Múltiplos Caminhos com Árvores de Dependência: Um framework de geração que combina uma representação intermediária determinística baseada em árvore de dependência com estratégias de poucos disparos e dividir e conquistar para garantir a cobertura abrangente dos elementos da pergunta.

Resultados Experimentais

O DexterSQL foi avaliado nos benchmarks BIRD-Dev e Spider-Test utilizando tanto modelos de pesos abertos (GPT-OSS-120B) quanto de pesos fechados (GPT-4o, GPT-5.2).

• Precisão: O DexterSQL alcançou o estado da arte em precisão de execução (EX) entre os métodos sem ajuste fino.
  • No BIRD-Dev com GPT-OSS-120B, atingiu 67,6% de EX, superando o baseline mais próximo (DeepEye-SQL) em 2,7%.
  • No BIRD-Dev com GPT-4o, atingiu 71,6% de EX, e com GPT-5.2, 72,2% de EX, excedendo os baselines mais fortes em pelo menos 0,9% a 2,5%.
  • No Spider-Test com GPT-OSS-120B, atingiu 84,4% de EX, uma melhoria de 2,5% sobre o melhor baseline.
• Ligação de Esquema: O DexterSQL demonstrou ligação de esquema superior, alcançando 97,09% de recall e 72,26% de precisão no BIRD-Dev, indicando que retém as colunas necessárias enquanto filtra o contexto irrelevante melhor do que outros métodos.
• Eficiência: Em termos de Pontuação de Eficiência Válida (VES), o DexterSQL alcançou as pontuações mais altas em todos os níveis de dificuldade, indicando que seus SQLs gerados não são apenas corretos, mas também eficientes.
• Estudos de Ablação: Remover qualquer um dos três novos componentes (Deep Schema Explorator, Rule Creator ou geração de Árvore de Dependência) resultou em uma queda mensurável na precisão, confirmando que cada componente contribui de forma única para o desempenho do sistema.

Significância

O artigo afirma que o DexterSQL demonstra que abordagens sem ajuste fino podem alcançar alta precisidade ao gerir efetivamente o contexto e corrigir erros sistemáticos do modelo, em vez de depender de atualizações de parâmetros. Sua significância reside em:

• Capacidade de Implantação (Deployability): Oferece uma solução que não requer ajuste fino caro ou grandes conjuntos de dados rotulados, facilitando a implantação para aplicações de dados sensíveis onde o envio de esquemas para serviços de terceiros é indesejável.
• Robustez: Ao modelar explicitamente as distribuições de dados e os padrões de erro recorrentes, o sistema aborda a natureza de "caixa preta" das falhas de LLM no Text-to-SQL, fornecendo uma maneira estruturada de melhorar a confiabilidade entre diferentes modelos e bancos de dados.
• Desempenho: Estabelece um novo benchmark para sistemas de Text-to-SQL baseados em prompting, provando que análises offline sofisticadas e raciocínio de múltiplos caminhos podem diminuir a lacuna de precisão com soluções ajustadas ou proprietárias.