Por que os "recordes" em Text-to-SQL são perigosos
Todos os meses surgem novas alegações de que mais uma LLM quase se igualou aos humanos em benchmarks de SQL. Mas, se olharmos de perto, por trás desses números se escondem condições muito diferentes: alguns usam um prompt simples sem acesso ao banco de dados, outros permitem que o modelo execute consultas em iterações, e outros ainda incorporaram o raciocínio diretamente nos pesos do modelo. Comparar esses resultados diretamente é como colocar lado a lado um carro com um mecânico e um veículo autônomo que se conserta sozinho durante o trajeto.
Os autores de um preprint recente no arXiv (2608.15389) chamaram a atenção justamente para esse problema. Eles propõem não medir mais o "progresso" pela altura abstrata na tabela de classificação, mas primeiro registrar honestamente quanta autonomia o sistema tinha ao gerar SQL. Sem essa ressalva, qualquer comparação entre trabalhos se torna instável: mudar o benchmark, o modelo base ou até mesmo um protocolo de inferência ligeiramente diferente pode alterar as conclusões.
O eixo da autonomia: de prompts a agentes autossuficientes
Em vez de simplesmente reunir todos os números em uma única tabela, os pesquisadores redefinem o próprio campo de Text-to-SQL como uma "agregação de leaderboard". Eles coletam métricas que os autores dos sistemas relatam por conta própria e as distribuem ao longo do eixo de autonomia da inferência. O resultado são cinco níveis:
- Constrained generation — o modelo apenas escolhe uma resposta dentro de um espaço rigidamente limitado de consultas permitidas, muitas vezes com verificação externa de sintaxe.
- In-context generation — o SQL é construído em uma única passagem pelo contexto, com exemplos e descrição do esquema.
- Iterative generation — o sistema pode fazer várias tentativas, refinando a consulta com base nos resultados da execução ou na resposta do SGBD.
- Agentic generation — o modelo atua como um agente: ele mesmo explora o esquema do banco, executa consultas, reage a erros e planeja os próximos passos.
- Reasoning-internalized generation — o "raciocínio" é pré-incorporado ao modelo, portanto, na inferência, ele emite a consulta diretamente, sem orquestrações externas ou etapas intermediárias.
Essa escala não diz que um nível é "melhor" que outro. Ela apenas estabelece as condições para uma comparação justa: um sistema com raciocínio interno não pode ser contraposto em pé de igualdade a uma saída single-shot pura, assim como um circuito agêntico com o direito de executar consultas não deve ser comparado a um modelo ao qual esse direito não foi concedido.
É importante que, para cada célula desse leaderboard, seja preservada a proveniência rastreável da métrica. Isso significa que o leitor sempre pode entender qual configuração exata produziu o resultado, em vez de tentar adivinhar a partir de fragmentos da seção experimental.
O que o experimento no Spider e além dele mostrou
Para ancorar a agregação de métricas na realidade, os autores conduziram um estudo direcionado no benchmark Spider. Eles compararam modelos abertos de 8B — com e sem supervisão CoT — contra baselines few-shot baseados em DeepSeek V3 e GLM-4. Curiosamente, foram usados protocolos few-shot, e não versões totalmente fine-tuned, portanto a comparação ficou bastante limpa.
Do experimento, destacam-se quatro padrões importantes para profissionais da área.
Em primeiro lugar, as melhorias obtidas no Spider se transferem de forma desigual para BIRD e Spider 2.0. Um modelo pode mostrar um belo ganho em um conjunto de consultas e quase não se mover em outro. Isso confirma mais uma vez: a busca cega por uma pontuação única em um benchmark popular cria a ilusão de progresso geral.
Em segundo lugar, a autonomia adiciona robustez, mas a um custo não trivial. Circuitos agênticos realmente lidam melhor com tarefas de múltiplas etapas e ambíguas, porém os custos de tokens e tempo de execução crescem visivelmente. Se, para um analista interativo, esse custo é justificável, para o processamento em lote ele pode consumir todo o ganho obtido com erros menos frequentes.
Em terceiro lugar, o modo reasoning internalized ocupa uma posição intermediária inesperada. Ele fica entre a decodificação "burra" da resposta sem raciocínio e os agentes orquestrados externamente. Para várias tarefas, esse modo oferece qualidade quase de agente, mas sem a necessidade de construir um circuito complexo com ferramentas. Embora não haja "almoço grátis" universal: o raciocínio incorporado também tem suas limitações.
Em quarto lugar, os ganhos da supervisão CoT se concentram em consultas dos níveis Hard e Extra-Hard. Em perguntas simples, a diferença é quase imperceptível ou até negativa — por que o modelo deveria raciocinar em voz alta quando a resposta é óbvia? Já em tarefas complexas de múltiplas etapas, a capacidade de verbalizar os passos oferece uma vantagem notável. Esse é um sinal importante para quem constrói assistentes SQL: o poder computacional adicional deve ser focado em consultas de alta complexidade, e não desperdiçado em casos simples e típicos.
Como usar essa escala na prática
A consequência mais útil do trabalho não é nem a taxonomia em si, mas o harness público em Python que os autores lançaram junto com o preprint. O harness reproduz o eixo de autonomia e permite adicionar novos métodos ao leaderboard sem reescrever todo o ambiente. Se você está desenvolvendo mais uma abordagem de Text-to-SQL, basta indicar em qual nível de autonomia ela opera — e a comunidade poderá comparar você com sistemas anteriores em condições de igualdade.
É claro que agregações baseadas em métricas autorrelatadas ainda devem ser vistas com cautela. Nem todos têm orçamento para repetir experimentos alheios, mas uma anotação unificada já é um grande passo à frente. Por enquanto, ao ler mais um "state-of-the-art", tenha em mente uma pergunta simples: o que exatamente o modelo podia fazer durante a geração da consulta? Se a resposta a essa pergunta estiver ausente, então o número do artigo é apenas um belo valor sem base sólida.
