Resumo Técnico: Spider 2.0-AIFunc

Declaração do Problema

As principais plataformas de dados em nuvem (ex: Snowflake, BigQuery, Databricks) começaram a expor capacidades de Large Language Model (LLM) como funções SQL nativas. Essas funções "AI-nativas" permitem que analistas realizem operações semânticas — como classificação, análise de sentimento, busca de similaridade e extração de informações — diretamente dentro de consultas SQL padrão. No entanto, os benchmarks de Text-to-SQL existentes (ex: Spider 1.0, Spider 2.0, BIRD) avaliam apenas o SQL convencional sobre dados estruturados. Eles não fornecem sinal sobre a capacidade de um modelo em gerar SQL AI-nativo, o que requer não apenas a construção de consultas padrão, mas também a seleção, parametrização e integração corretas de chamadas de funções de IA.

Metodologia

Os autores introduzem o Spider 2.0-AIFunc, um benchmark projetado para avaliar capacidades de Text-to-SQL no contexto de fluxos de trabalho AI-nativos. A metodologia de construção e avaliação envolve três componentes principais:

1. Construção do Benchmark via Pipeline de Agentes

O benchmark é derivado de 513 instâncias do conjunto de dados Spider2-Snow (um subconjunto de nível empresarial do Spider 2.0 hospedado no Snowflake). Os autores utilizam um pipeline reutilizável baseado em agentes (usando Claude Opus 4.5) para transformar essas tarefas tradicionais em versões AI-nativas:

• Transformação: Agentes reescrevem o SQL alvo para incorporar as Funções de IA do Snowflake Cortex AI e, simultaneamente, refinam as instruções de linguagem natural para tornar o uso pretendido da IA explícito.
• Redução de Ambiguidade: Para tarefas com múltiplos SQLs de ouro válidos, as instruções são refinadas para especificar a função de IA exata e seus parâmetros (ex: conjuntos completos de rótulos de classe para classificação) para garantir uma única resposta correta.
• Processo de Duas Rodadas:
  • Rodada Principal: Agentes selecionam funções de IA livremente, resultando em uma distribuição dominada por AI_CLASSIFY, AI_FILTER e AI_SIMILARITY.
  • Rodada de Diversidade: Agentes são instruídos a priorizar funções sub-representadas (AI_SENTIMENT, AI_EXTRACT, AI_AGG) para garantir uma ampla cobertura dos seis tipos de funções de IA suportados.

2. Verificação de Determinismo

Um desafio crítico ao avaliar funções de IA é a determinismo de execução, uma vez que os outputs de LLMs podem exibir inconsistências menores mesmo em temperatura zero. Para abordar isso:

• Verificação de Múltiplas Passagens: Cada instância candidata passa por quatro passagens de execução (totalizando $\ge$35 execuções). Um agente de verificação repara instâncias com resultados inconsistentes ajustando o SQL, as instruções ou as configurações de avaliação.
• Estabilidade Temporal: As instâncias sobreviventes passam por uma verificação de estabilidade final envolvendo 30 execuções através de três janelas de tempo separadas temporalmente. Instâncias que produzem resultados inconsistentes através dessas janelas são descartadas.
• Dataset Final: O processo resulta em 465 instâncias verificadas em 125 bancos de dados reais.

3. Protocolo de Avaliação

• Métrica: Acurácia de Execução (EX). Diferente de benchmarks tradicionais onde os resultados de ouro são pré-computados e estáticos, o Spider 2.0-AIFunc exige que tanto o SQL de ouro ($S_n$) quanto o SQL previsto ($\hat{S}_n$) sejam executados dentro da mesma janela de tempo para garantir que sejam avaliados contra o mesmo estado subjacente do modelo.
• Lógica de Comparação: Os resultados são comparados usando correspondência de subconjunto de colunas (as colunas de ouro devem aparecer nos resultados previstos; as colunas previstas podem conter extras).
• Frameworks: Os modelos são avaliados usando o framework Spider-Agent com um conjunto mínimo de ferramentas (bash para exploração de esquema, execução de SQL e terminação de tarefa). A configuração inclui documentação de referência para as Funções de IA do Snowflake Cortex.

Principais Contribuições

1. Benchmark Spider 2.0-AIFunc: O primeiro benchmark especificamente para Text-to-SQL AI-nativo, cobrindo 465 instâncias verificadas, 125 bancos de dados e seis tipos de funções de IA (Classificação, Filtragem, Sentimento, Similaridade, Extração, Agregação).
2. Pipeline de Construção Baseado em Agentes: Um pipeline automatizado e inovador que transforma tarefas existentes de Text-to-SQL empresarial em versões AI-nativas, enquanto simultaneamente refina as instruções e verifica o determinismo de execução.
3. Análise Empírica de SQL AI-nativo: Uma avaliação abrangente de 10 modelos de última geração (5 proprietários, 5 de código aberto) e 3 frameworks de agentes, revelando modos de falha específicos e as limitações das estratégias tradicionais de Text-to-SQL neste novo cenário.

Resultados

A avaliação de 10 modelos no Spider 2.0-AIFunc produz as seguintes descobertas:

• Gap entre Modelos Proprietários e de Código Aberto: Modelos proprietários superam significativamente os modelos de código aberto.
  • Top Proprietário: Claude Opus 4.6 (70.3%), Claude Sonnet 4.6 (69.0%) e Gemini 3.1 Pro (67.1%).
  • Top Código Aberto: Kimi K2.5 (58.1%).
  • O gap é impulsionado principalmente por erros em especificação de predicados, ancoragem de esquema (schema grounding) e parametrização de funções de IA.
• Sucesso de Execução: A maioria dos modelos atinge altas taxas de "Exec." (90–99%), indicando que conseguem gerar SQL AI-nativo sintaticamente válido que executa sem erros. O gap de performance reside na correção semântica.
• Transferibilidade de Framework de Agentes: Frameworks de agentes projetados para desafios tradicionais de Text-to-SQL (ex: recuperação de esquema, seleção de tabela) não se transferem efetivamente para o SQL AI-nativo.
  • Frameworks complexos (AutoLink, ReFoRCE, DSR-SQL) igualaram, mas não excederam, o desempenho de uma configuração mínima do Spider-Agent ao usar o mesmo modelo base (Claude Sonnet 4.6).
  • Isso sugere que estratégias para scaffolding de SQL tradicional são menos críticas do que a capacidade de tomar decisões semânticas precisas em relação ao uso de funções de IA (ex: parametrização correta, ordem de filtragem).
• Comportamento de Interação: Modelos de código aberto exigem significativamente mais rodadas de interação (19–30 vs. 10–12 para proprietários) e mais tentativas de execução de SQL para alcançar um resultado correto, frequentemente falhando em terminar corretamente.

Significância e Alegações

O artigo afirma que o Spider 2.0-AIFunc representa uma evolução necessária na avaliação de Text-to-SQL, movendo-se de pura manipulação de dados estruturados para fluxos de trabalho AI-nativos que integram operações semânticas diretamente no SQL.

Os autores enfatizam que:

1. Benchmarks Atuais são Insuficientes: Benchmarks existentes falham em capturar a complexidade de integrar capacidades de LLM em pipelines de dados empresariais.
2. Determinismo é Crítico: O protocolo de verificação destaca que a avaliação de funções de IA requer verificações de estabilidade rigorosas devido à natureza não determinística inerente dos outputs de LLM, mesmo em ambientes controlados.
3. Mudança de Estratégia: O fracasso de frameworks de agentes complexos em superar configurações mínimas sugere que o principal gargalo no SQL AI-nativo não é a recuperação de esquema ou decomposição, mas sim a especificação e parametrização precisa de funções de IA. À medida que os modelos melhoram, o valor de scaffolds elaborados para componentes de SQL tradicional diminui em relação à necessidade de invocação precisa de funções semânticas.

O trabalho serve como um passo fundamental para avaliar e melhorar modelos capazes de construir fluxos de trabalho de análise de dados "AI-nativos", uma capacidade cada vez mais exigida por plataformas de dados empresariais.