Resumo Técnico: UNIQL

Declaração do Problema

Os atuais benchmarks de text-to-SQL, como o Spider e o BIRD, são predominantemente centrados no dialeto SQLite. Essa dependência cria uma lacuna de avaliação significativa: permanece incerto se os grandes modelos de linguagem (LLMs) podem generalizar suas capacidades através de dialetos SQL heterogêneos. Sistemas de banco de dados do mundo real (ex: PostgreSQL, MySQL, Oracle, Hive) diferem substancialmente em sintaxe, funções integradas, sistemas de tipos e semânticas de execução. Consequentemente, a mesma intenção de linguagem natural frequentemente requer realizações de SQL específicas de cada dialeto. Os benchmarks existentes ou focam em um único dialeto ou cobrem múltiplos sistemas sem alinhar as mesmas intenções de linguagem natural entre eles, tornando impossível isolar a variação de dialeto das diferenças em esquemas ou tarefas. Essa limitação leva a uma superestimação da robustez e universalidade dos atuais sistemas de text-to-SQL.

Metodologia

Os autores introduzem o UNIQL, um benchmark executável e verificado por humanos, projetado para avaliação de text-to-SQL entre dialetos. A construção do UNIQL envolve um pipeline híbrido que estende o conjunto de desenvolvimento do BIRD para 16 dialetos SQL.

Pipeline de Construção do Conjunto de Dados

1. Migração de Banco de Dados: Os bancos de dados originais do BIRD (baseados em SQLite) são migrados para 15 sistemas de banco de dados alvo (incluindo ClickHouse, Doris, Drill, Druid, DuckDB, Hive, MySQL, Oracle, PostgreSQL, Presto, Spark, StarRocks, Teradata, Trino e T-SQL). Este processo envolve adaptação de esquema, mapeamento de tipos, normalização de identificadores e adaptação de namespace para garantir a executabilidade enquanto preserva a semântica dos dados.
2. Tradução e Verificação Automatizadas:
   • Tradução Baseada em Regras: Uma ferramenta determinística (SQLGlot) é usada para gerar consultas iniciais de dialetos alvo.
   • Verificação Guiada por Execução: As consultas traduzidas são executadas no banco de dados alvo. Uma consulta é aceita automaticamente apenas se for executada com sucesso e produzir resultados estritamente equivalentes à consulta SQLite de origem. O protocolo preserva a semântica de ordenação e a multiplicidade de duplicatas, evitando falsos positivos comuns em comparações de conjuntos não ordenados.
   • Tradução Baseada em LLM: Para consultas que falham na tradução baseada em regras, um LLM (GPT-5-mini) gera traduções condicionadas ao SQL de origem, ao esquema alvo e ao conjunto de regras atual.
   • Autorreflexão: Se as traduções do LLM falharem na verificação de equivalência, o modelo entra em um loop de autorreflexão limitado (até 3 rodadas) usando o feedback de execução (erros ou divergências de resultados) para refinar a consulta.
3. Evolução Iterativa de Regras: As traduções que falham são analisadas para abstrair padrões de erro recorrentes em regras de transformação de dialeto reutilizáveis. Essas regras são atualizadas iterativamente (usando Gemini-2.5-Pro) para lidar com problemas de cauda longa específicos de dialetos, como reescrita de funções, conversão de tipos e comportamento de agregação.
4. Verificação Humana: Casos que não podem ser resolvidos através de tradução automatizada, reflexão ou refinamento de regras são encaminhados para anotadores humanos. Dois anotadores independentes revisam a executabilidade e a consistência semântica, reescrevendo as consultas conforme necessário para garantir que correspondam à intenção original de linguagem natural.

Estatísticas do Benchmark

• Origem: 1.534 questões de linguagem natural do conjunto de desenvolvimento do BIRD.
• Cobertura: 16 dialetos SQL (1 de origem + 15 alvos).
• Total de Anotações: 24.544 consultas SQL executáveis e específicas de cada dialeto.
• Alinhamento: Todos os dialetos compartilham intenções de linguagem natural, esquemas e conteúdos de banco de dados idênticos.

Protocolo de Avaliação

O artigo avalia modelos usando Acurácia de Execução (EX). Ao contrário de benchmarks anteriores que convertem saídas em conjuntos não ordenados, o protocolo do UNIQL preserva a ordenação quando cláusulas ORDER BY explícitas existem e mantém a multiplicidade de duplicatas para saídas não ordenadas. Os modelos são avaliados em um cenário de apenas inferência, sem ajuste fino específico da tarefa, seleção de poucos disparos (few-shot) ou adaptação específica de dialeto.

Principais Resultados

Os autores avaliaram um amplo conjunto de LLMs de código aberto (ex: Qwen3, Llama-3, DeepSeek) e de código fechado (ex: GPT-5, Gemini, Claude).

1. Universalidade de Dialeto Limitada: Mesmo os modelos mais fortes (ex: Claude-4.5-Sonnet) alcançam uma acurácia de execução média de apenas ~54,63%. Isso indica que a geração de text-to-SQL entre dialetos executáveis está longe de estar saturada.
2. Viés Centrado em SQLite: O desempenho no SQLite não prevê de forma confiável o desempenho em outros dialetos. Por exemplo, um modelo pode alcançar 59,84% no SQLite, mas apenas 37,74% no Teradata. Benchmarks de dialeto único falham em capturar essas interações significativas entre modelo e dialeto.
3. Efeitos de Escala: Modelos maiores dentro de famílias (ex: Qwen3-1.7B para Qwen3-32B) mostram desempenho melhorado, mas o escalonamento impulsiona principalmente a capacidade geral, em vez de eliminar as fraquezas específicas de dialetos. Dialetos difíceis como Druid, Presto e Teradata permanecem desafiadores mesmo para modelos maiores.
4. Familiaridade com o Dialeto: O desempenho correlaciona-se com a familiaridade do modelo. O Oracle, que possui abundância de documentação pública e exposição de treinamento, gera uma acurácia maior do que o Teradata ou Druid, que podem ser sub-representados em corpora de pré-treinamento e envolvem funções complexas específicas do sistema.
5. Consistência Entre Dialetos: Uma alta acurácia média não implica correção universal de dialeto. Para o melhor modelo, apenas ~20% das questões são respondidas corretamente em todos os 16 dialetos. Além disso, o sucesso na realização em SQLite de uma intenção não garante o sucesso em outros dialetos (por exemplo, apenas ~33% das questões corretas no SQLite permanecem corretas em todos os outros dialetos para o Claude-4.5-Sonnet).

Significância e Contribuições

O artigo apresenta três contribuições primárias:

1. Benchmark UNIQL: A introdução de um benchmark executável e verificado por humanos que alinha as mesmas intenções de linguagem natural com realizações SQL em 16 dialetos, permitindo uma avaliação controlada da generalização de dialetos.
2. Framework de Construção: Um novo framework de tradução SQL integrando tradução baseada em ferramentas, tradução baseada em LLM, verificação baseada em execução, autorreflexão, evolução iterativa de regras e validação humana para construir conjuntos de dados de alta qualidade entre dialetos.
3. Avaliação Diagnóstica: Avaliação abrangente mostrando que os atuais LLMs lutam com a geração de text-to-SQL universal de dialeto. Os achados destacam que a consulta robusta entre sistemas requer avaliação explícita e modelagem da robustez entre dialetos, em vez de depender apenas de benchmarks centrados em SQLite.

Os autores concluem que, embora os modelos atuais mostrem potencial, eles ainda não são universalmente compatíveis com dialetos. A variação substancial de desempenho entre sistemas de banco de dados ressalta a necessidade de benchmarks alinhados entre dialetos e o desenvolvimento de métodos de text-to-SQL mais conscientes de dialetos.