Resumo Técnico: Benchmarking de Text-to-Python contra Text-to-SQL

Declaração do Problema

Embora o Text-to-SQL seja o paradigma dominante para a interação com bancos de dados, a análise de dados no mundo real exige cada vez mais a flexibilidade de linguagens de programação de propósito geral, como Python, para gerenciar dados baseados em arquivos (ex: CSV, Excel) e fluxos de trabalho procedimentais complexos. Apesar das vantagens teóricas do Text-to-Python, sua confiabilidade na recuperação de dados essenciais permanece subexplorada em comparação ao ecossistema maduro do Text-to-SQL. Existe uma lacuna crítica em avaliar sistematicamente se o Text-to-Python pode efetivamente substituir o Text-to-SQL, particularmente dadas as diferenças fundamentais entre a natureza declarativa do SQL (que depende de comportamentos implícitos do DBMS) e a exigência de lógica procedural explícita do Python. Este artigo investiga se a lacuna de desempenho entre os dois paradigmas decorre de limitações inerentes na geração de código ou da sensibilidade do Python à intenção do usuário subespecificada e ao contexto de domínio ausente.

Metodologia

1. Construção do Benchmark: BIRD-Python

Para permitir uma comparação justa entre paradigmas, os autores construíram o BIRD-Python, um benchmark derivado do conjunto de dados BIRD.

• Transformação de Dados: Bancos de dados relacionais foram convertidos em formatos de arquivo autônomos (CSV), e os objetivos originais de SQL foram mapeados para lógica de execução Python equivalente.
• Purificação do Conjunto de Dados: Os autores identificaram um ruído de anotação significativo no conjunto de dados BIRD original, onde saídas válidas de modelos eram penalizadas devido a imprecisões de SQL de referência. Eles implementaram um pipeline de purificação de dois estágios:
  • Verificação Automatizada: O consenso entre três LLMs de última geração (Qwen3-238B, DeepSeek-R1, Qwen-Max) verificou 1.193 consultas.
  • Revisão por Especialistas: Revisão cega dupla de especialistas corrigiu 259 inconsistências lógicas e confirmou 82 anotações originais.
• Conversão SQL-para-Python: Para garantir que a semântica de execução estivesse alinhada, a equipe reconstruiu a lógica SQL em Python, implementando explicitamente comportamentos implícitos de DBMS (ex: tratamento de nulos, estabilidade de ordenação) e abordando diferenças de segurança de tipo.
• Métrica de Avaliação: A Acurácia de Execução (EX) padrão foi suplementada com um Validador Semântico baseado em LLM ($V_{sem}$). Este validador determina a equivalência semântica entre os resultados previstos e o ground truth, mitigando falsos negativos causados por discrepâncias superficiais (ex: ordem de colunas, representação de tipos de dados).

2. O Framework de Completamento de Lógica (LCF)

Para isolar o impacto da ambiguidade da capacidade de geração de código, os autores propuseram o Framework de Completamento de Lógica (LCF). Este paradigma de três fases separa o raciocínio das deficiências de informação:

• Fase 1 (Sondagem de Lógica): O modelo alvo (Sujeito) analisa a entrada (Esquema, Pergunta, Conhecimento Externo) para identificar ambiguidades e gera uma consulta de esclarecimento ($Q_{ambiguity}$) sem gerar código.
• Fase 2 (Injeção de Ground Truth): Um modelo Oráculo (simulando um especialista de domínio com acesso ao ground truth) traduz a lógica de ouro em dicas de linguagem natural ($C_{logic}$). Esta etapa suplementa o conhecimento de domínio latente sem vazar a sintaxe do código.
• Fase 3 (Execução): O Sujeito gera o programa final condicionado ao contexto aumentado ($S, Q, K, C_{logic}$).

Principais Contribuições

1. Benchmark BIRD-Python: O primeiro benchmark dedicado para avaliar Text-to-Python em consultas de dados baseados em arquivos, permitindo uma análise comparativa detalhada com Text-to-SQL.
2. Insight de Divergência de Paradigma: O estudo revela que o principal gargalo na análise flexível não é a escolha do paradigma (SQL vs. Python), mas a necessidade de formulação de lógica explícita. A exigência do Python por definições procedimentais passo a passo torna-o significativamente mais sensível à falta de contexto de domínio e à intenção ambígua do usuário do que o SQL.
3. Framework de Completamento de Lógica (LCF): Uma metodologia prática que suplementa explicitamente o conhecimento de domínio latente. O framework demonstra que, quando a ambiguidade é resolvida, o Text-to-Python atinge paridade de desempenho com o Text-to-SQL.

Resultados Experimentais

Os autores avaliaram vários LLMs de código aberto e proprietários (incluindo as famílias Qwen, DeepSeek e StarCoder) tanto no conjunto de dados BIRD original quanto no refinado.

• Lacuna de Desempenho: Modelos menores exibiram uma queda significativa de desempenho ao mudar de SQL para Python (ex: Qwen2.5-Coder 7B caiu de 52,93% para 35,95%). Isso valida a hipótese de que a lógica procedural explícita cria uma barreira de raciocínio mais alta para modelos menores.
• Escalabilidade do Modelo: Modelos maiores e com raciocínio aprimorado (ex: Qwen3-Max, DeepSeek-R1) mostraram lacunas de desempenho menores. O Qwen3-Max alcançou 63,43% de acurácia em Python, comparável ao seu desempenho em SQL.
• Impacto da Qualidade dos Dados: Os modelos performaram significativamente melhor no conjunto de dados "Verificado" (limpo) em comparação ao original, indicando que o ruído de anotação no BIRD original havia suprimido artificialmente as pontuações.
• Análise de Erros:
  • Erros Compartilhados: Ambos os paradigmas sofreram mais com Erros de Condição de Filtro (~32%), impulsionados pelo mal-entendido da intenção da linguagem natural.
  • Erros Específicos de Paradigma: A geração de Python exibiu uma taxa muito maior de Erros de Lógica (17,5% vs. 0,3% em SQL), refletindo a dificuldade de definir explicitamente os passos de execução. Erros de SQL foram mais comuns em Seleção de Linha/Coluna.
• Eficácia do LCF: Aplicar o LCF melhorou significativamente a acurácia em todos os modelos. Para o Qwen3-7B, a acurácia subiu de 53,19% para 71,19% em Python. Crucialmente, sob o LCF, a lacuna de desempenho entre a geração de SQL e Python quase desapareceu (ex: Qwen3-32B alcançou 72,49% para Código vs. 72,75% para SQL), provando que o déficit de desempenho era devido a lacunas de informação, não a limitações inerentes de geração.

Significância e Alegações

O artigo alega que o Text-to-Python é uma base viável e flexível para agentes analíticos, desde que os sistemas possam fundamentar entradas de linguagem natural ambíguas em especificações lógicas executáveis.

Os autores argumentam que a superioridade percebida do Text-to-SQL nos benchmarks atuais é, em parte, um artefato da capacidade do SQL de abstrair detalhes procedimentais, mascarando a incapacidade do modelo de resolver ambiguidades. Ao mudar o foco de "capacidade de geração de código" para "fundamentação de conhecimento contextual", o estudo sugere que o caminho a seguir para interfaces de linguagem natural reside em suplementar os modelos com contexto de domínio adequado (via frameworks como o LCF) em vez de confiar apenas em mudanças de paradigma. Isso estabelece que, com especificação precisa, o Python pode igualar as capacidades de recuperação de dados essenciais do SQL, oferecendo simultaneamente uma flexibilidade superior para fluxos de trabalho analíticos complexos baseados em arquivos.