DIN-SQL: Aprendizado em Contexto Decomposto para Text-to-SQL

Na semana passada, abordei o BIRD, o benchmark que revelou como os LLMs tropeçam quando o text-to-SQL passa de bancos de dados de brinquedo selecionados para esquemas do mundo real com nomenclaturas confusas, conhecimento de domínio e restrições de eficiência. O DIN-SQL é o artigo que eu deveria ter lido primeiro: ele definiu o que um pipeline de prompts de LLM cuidadosamente decomposto pode realmente alcançar no Spider e no BIRD, e chegou ao NeurIPS 2023 por Mohammadreza Pourreza e Davood Rafiei exatamente quando o GPT-4 se tornou amplamente disponível. Lê-lo agora — depois que o BIRD expôs o teto — torna as forças e os limites muito mais fáceis de ver com clareza.

O artigo

O DIN-SQL (arXiv:2304.11015) aborda uma lacuna de desempenho acentuada. No início de 2023, os melhores modelos com ajuste fino — RESDSQL-3B+NatSQL — atingiram 79,9% de precisão de execução no conjunto de testes Spider, enquanto o GPT-4 com prompting few-shot ingênuo conseguiu apenas 67,4% no conjunto de desenvolvimento. A hipótese de Pourreza e Rafiei é que essa lacuna é principalmente um problema de interface: os LLMs são capazes o suficiente, mas gerar SQL em uma única passagem exige que eles resolvam a vinculação de esquema, a classificação de complexidade e a síntese de consulta de uma só vez. Decomponha essas tarefas em subtarefas sequenciais e forneça cada solução como contexto, e a história muda.

O pipeline deles tem quatro estágios: (1) um módulo de vinculação de esquema que usa prompts de cadeia de pensamento para mapear a pergunta em linguagem natural para colunas e valores específicos no esquema; (2) um módulo de classificação e decomposição que categoriza a consulta em fácil (tabela única, sem junções), complexa não aninhada (junções, mas sem subconsultas) ou complexa aninhada (junções, subconsultas, operações de conjunto) e, para consultas aninhadas, decompõe o problema em subconsultas; (3) um módulo de geração de SQL que combina a estratégia de prompting com a classe de complexidade — few-shot simples para o nível fácil, representação intermediária NatSQL para não aninhadas, cadeia de pensamento de várias etapas para aninhadas; e (4) um módulo de autocorreção que pede ao modelo para revisar sua própria saída em busca de erros menores, como DISTINCT ausente ou DESC mal posicionado.

Principais ideias

• O GPT-4 + DIN-SQL atinge 85,3% de precisão de execução no conjunto de testes de retenção do Spider, um salto de +5,4 pontos em relação ao SOTA de ajuste fino da época, RESDSQL-3B+NatSQL (79,9%), sem quaisquer dados de treinamento específicos da tarefa.
• No Spider dev, o pipeline de decomposição move o GPT-4 de 67,4% (baseline few-shot) para 74,2% — um ganho líquido de +6,8 pontos. O CodeX Davinci move-se de 61,5% para 69,9%.
• A ablação confirma que cada estágio contribui: remover apenas a vinculação de esquema faz o CodeX cair de 69,9% para 65,9%; remover a classificação faz cair ainda mais para 63,1%.
• Os ganhos estão concentrados em consultas fáceis e médias. Em consultas "extra difíceis", mesmo o pipeline completo DIN-SQL + GPT-4 atinge apenas 43,4% no Spider dev — a decomposição não resolve a complexidade, apenas reduz erros evitáveis em consultas tratáveis.
• A autocorreção é sensível ao modelo: o GPT-4 responde a prompts "gentis" que pedem melhorias potenciais; o CodeX responde melhor a prompts "genéricos" que assumem que o SQL está errado. Isso sugere que o módulo está fazendo uma limpeza estilística, não uma verificação semântica real.
• No BIRD dev, o DIN-SQL + GPT-4 marca 50,72% contra um baseline de GPT-4 puro de 46,35% — uma melhoria de +4,4 pontos, substancialmente menor do que os ganhos no Spider, ponto ao qual voltarei.

O que se sustenta — e o que não

O resultado principal é real. Decompor o text-to-SQL em subtarefas explícitas melhora o desempenho, e os estudos de ablação são claros o suficiente para acreditar nas contribuições individuais de cada módulo. A vinculação de esquema é o que mais importa para consultas difíceis, o que faz sentido: o modelo não consegue gerar JOINs corretos se não tiver identificado primeiro corretamente a quais tabelas e colunas a pergunta se refere.

No entanto, várias coisas me deixam pensativo. A discrepância de 74,2% no dev vs. 85,3% no teste é suspeita. Os conjuntos de desenvolvimento costumam ser mais difíceis ou pelo menos tão difíceis quanto os de teste, porque os modelos são implicitamente ajustados em relação a eles; um salto de +11 pontos do dev para o teste é incomum. Os autores não explicam isso, e isso me faz perguntar se o conjunto de testes tem uma distribuição diferente de dificuldades de consulta, ou se há algo sobre como o teste de retenção é avaliado (através do servidor oficial de classificação do Spider) que difere da avaliação do conjunto de desenvolvimento deles. Eu não citaria 85,3% sem essa ressalva.

A lacuna do BIRD (50,72% dev) é notavelmente menor do que os ganhos do Spider. Os bancos de dados do BIRD possuem esquemas confusos do mundo real com nomes de colunas abreviados, terminologia específica de domínio e valores ambíguos. O módulo de vinculação de esquema do DIN-SQL foi projetado com os esquemas relativamente limpos do Spider em mente; quando os esquemas ficam mais sujos, a precisão da vinculação cai e o restante do pipeline se degrada junto. Isso é exatamente o que o artigo do BIRD mediu, e o DIN-SQL não resolve isso.

Os números de custo e latência são um problema para qualquer sistema de produção: cerca de US$ 0,50 e 60 segundos por pergunta com o GPT-4. Isso é aceitável para um analista de dados que executa dez consultas por dia, mas completamente inviável para uso interativo. O artigo apresenta isso como uma limitação conhecida, mas não propõe um caminho para reduzi-la. O DAIL-SQL (arXiv:2308.15363), que apareceu alguns meses depois, mostraria que uma melhor seleção de exemplos, em vez de decomposição explícita, poderia atingir 86,6% no Spider — superando o DIN-SQL com um custo significativamente menor.

O módulo de autocorreção é a parte mais fraca. Os autores admitem que ele detecta erros "menores". O que ele não consegue fazer é detectar erros semânticos — casos em que o SQL gerado é sintaticamente válido e até executa, mas responde à pergunta errada. Esse é o modo de falha mais difícil para usuários reais.

Por que isso é importante para a IA financeira

O Beanquery (BQL) é uma linguagem de consulta semelhante ao SQL sobre dados do livro-razão Beancount. Ele tem sua própria estrutura de tabelas — transactions, postings, balance, prices — com hierarquias de contas, etiquetas e campos de metadados que em nada se parecem com esquemas de bancos de dados genéricos. Uma interface de linguagem natural para BQL é algo real e útil (já existe um servidor experimental beanquery-mcp implementando exatamente isso via MCP), e a estratégia de decomposição do DIN-SQL é o ponto de partida correto.

A vinculação de esquema sobre BQL é o problema análogo à vinculação de esquema sobre tabelas relacionais, mas com duas complicações extras: os nomes das contas são caminhos hierárquicos como Assets:US:Checking:Bank, e o esquema relevante depende do tipo de consulta que o usuário está fazendo (demonstração de resultados, balanço patrimonial, fluxo de caixa). O módulo de classificação do DIN-SQL sugere uma adaptação direta: classificar a intenção da consulta (saldo vs. fluxo vs. busca de preço) primeiro e, em seguida, direcionar para diferentes templates de prompt.

A descoberta do benchmark BIRD de que a confusão do mundo real prejudica o text-to-SQL com LLMs é diretamente relevante. Um livro-razão Beancount também é "confuso" — nomes de contas definidos pelo usuário, símbolos de commodities inconsistentes, chaves de metadados personalizadas. A melhoria de 4,4 pontos no BIRD vs. a melhoria de 6,8 pontos no Spider me diz que o regime de esquemas estruturados e limpos superestima o quanto a decomposição ajudará em consultas BQL reais. Espere ganhos menores na prática.

A restrição de custo é real, mas menos impeditiva aqui. Um usuário de finanças pessoais que executa 10 a 20 consultas por dia pode tolerar de US$ 5 a US$ 10/dia em custos de API se a interface for genuinamente útil. A latência (60 segundos) é mais um problema para uso interativo; o processamento em lote de consultas analíticas pode contornar isso.

O que ler a seguir

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — estudo sistemático de estratégias de engenharia de prompt; atinge 86,6% no Spider concentrando-se na seleção de exemplos em vez de decomposição arquitetural, um contraponto útil ao DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — o baseline de ajuste fino que o DIN-SQL superou; entender o que a abordagem de ajuste fino faz bem esclarece onde o prompting ainda falha.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — estende a ideia de decomposição em várias etapas para um pipeline multi-agente explícito com um Seletor, Decompositor e Refinador; atinge 59,59% no BIRD com o GPT-4 e é a abordagem mais centrada em agentes na área.