Cost Trade-offs of Reasoning and Non-Reasoning Large Language Models in Text-to-SQL

Este artigo demonstra que, em ambientes de nuvem como o Google BigQuery, os modelos de linguagem com raciocínio reduzem significativamente os custos de execução de consultas Text-to-SQL ao processarem menos dados e evitarem padrões ineficientes, revelando que a otimização de tempo não garante eficiência financeira e fornecendo diretrizes para mitigar riscos em ambientes corporativos.

O essencial

Imagine que você tem um chef de cozinha muito inteligente (a Inteligência Artificial) e um armazém gigante de ingredientes (o banco de dados na nuvem, como o Google BigQuery).

O seu objetivo é pedir ao chef: "Faça uma salada com tomates e alfaces". O chef precisa escrever a receita (o código SQL) para buscar os ingredientes no armazém.

O problema é que, no mundo real das empresas, pagar pelo armazém não é pelo tempo que a receita leva para ser escrita, mas sim pelo peso dos ingredientes que você tira da prateleira. Se o chef tirar 100kg de tomates para fazer uma salada para duas pessoas, você paga por 100kg, mesmo que ele tenha feito isso em 1 segundo.

Este artigo é como um teste de cozinha para ver qual tipo de chef gasta menos dinheiro ao buscar ingredientes.

Os Dois Tipos de Chefes

Os pesquisadores testaram dois tipos de chefs de Inteligência Artificial:

1. Os "Pensadores" (Reasoning Models): São chefs que param um momento antes de começar. Eles pensam: "Espere, eu só preciso de tomates e alfaces. Não vou pegar o queijo, nem o bacon, nem o resto da despensa. Vou só pegar o que preciso." Eles têm um "tempo de raciocínio" extra antes de agir.
2. Os "Rápidos" (Non-Reasoning Models): São chefs muito velozes. Eles pegam o pedido e correm para a despensa imediatamente. Eles são rápidos, mas às vezes, na pressa, pegam tudo o que veem pela frente, pensando que podem precisar depois.

O Grande Descoberta: Velocidade não é Economia

O estudo descobriu uma coisa muito importante que vai contra o senso comum: Ser rápido não significa ser barato.

• A Ilusão da Velocidade: Um dos chefs "Rápidos" escreveu a receita em 2 segundos. Mas, como ele não pensou direito, ele levou 36.000 kg de ingredientes para a cozinha (o que custou uma fortuna).
• A Sabedoria do Pensador: O chef "Pensador" levou 3 segundos a mais para escrever a receita. Mas, como ele foi cuidadoso, ele só levou 1.800 kg de ingredientes.
• O Resultado: O "Pensador" foi 44,5% mais barato, mesmo tendo demorado um pouquinho mais para começar a cozinhar.

Os Erros Comuns (As Armadilhas)

O estudo mostrou que os chefs "Rápidos" cometem erros caros, como se fossem turistas desajeitados em um supermercado:

• **"Pegue Tudo" (SELECT ):* Em vez de pedir apenas "tomates", eles dizem "pegue tudo o que tem na prateleira". Isso faz o sistema carregar gigabytes de dados inúteis.
• Esquecer o Filtro: Se o pedido é "ingredientes de 2020", eles vão até a prateleira inteira (de 2008 a 2022) em vez de ir direto ao ano certo.
• Juntar Coisas que Não Combinam: Eles fazem conexões erradas entre tabelas, como se misturassem o estoque de doces com o de produtos de limpeza, gerando confusão e gasto extra.

Por que isso importa para o seu bolso?

Imagine que sua empresa usa essa tecnologia para responder a milhares de perguntas de clientes todos os dias.

• Se você usar o chef "Rápido" e ele cometer um erro de pegar 36GB de dados em uma única pergunta, você pode gastar o equivalente a 20 vezes mais do que o necessário.
• Se você usar o chef "Pensador", ele é mais consistente. Ele raramente comete erros gigantes e, no final do mês, a conta de luz (ou a conta da nuvem) será muito menor.

A Lição Principal

O artigo nos ensina três lições simples:

1. Não olhe apenas para o relógio: Um sistema que responde rápido pode estar gastando uma fortuna por trás dos panos.
2. Pensar antes de agir vale a pena: Os modelos de IA que "pensam" (reasoning) geram receitas mais eficientes, economizando dinheiro real na nuvem.
3. Cuidado com os "Gigantes" escondidos: Às vezes, uma única pergunta mal feita pode custar o mesmo que 20 perguntas normais. É preciso ter regras (guardrails) para impedir que o chef pegue o armazém inteiro se não for necessário.

Em resumo: Na era da Inteligência Artificial nas empresas, a eficiência não é sobre quem responde mais rápido, mas sobre quem sabe exatamente o que precisa buscar para não desperdiçar dinheiro. Os "Pensadores" são, até agora, os melhores economistas da cozinha.

Resumo técnico

Título: Trade-offs de Custo entre Modelos de Linguagem Grandes (LLMs) de Raciocínio e Não-Raciocínio em Text-to-SQL

1. O Problema

Embora os sistemas de Text-to-SQL (conversão de linguagem natural para SQL) tenham alcançado alta precisão em benchmarks de pesquisa (como Spider e BIRD), existe uma lacuna crítica na avaliação de sua eficiência econômica em ambientes de produção.

• Foco Atual: A maioria das métricas de eficiência foca no tempo de execução (tempo de parede) ou em pontuações relativas em bancos de dados locais.
• A Realidade da Nuvem: Armazéns de dados em nuvem (como Google BigQuery, Snowflake, Amazon Redshift) utilizam modelos de precificação baseados no consumo (bytes processados/escaneados), e não apenas no tempo de execução.
• A Lacuna: O artigo demonstra que o tempo de execução tem uma correlação fraca com o custo real na nuvem ($r = 0,16$). Uma consulta rápida pode escanear terabytes de dados devido à falta de filtros ou joins ineficientes, gerando custos exorbitantes. Não há, até o momento, uma avaliação sistemática dos custos de computação em nuvem gerados por consultas SQL criadas por LLMs.

2. Metodologia

Os autores realizaram um experimento controlado para medir os custos de computação em nuvem de consultas geradas por LLMs.

• Plataforma de Avaliação: Google BigQuery (modelo de preços baseado em bytes processados).
• Dataset: StackOverflow público (230 GB), contendo tabelas complexas (posts, usuários, votos, etc.) para simular cargas de trabalho analíticas reais.
• Carga de Trabalho: 30 perguntas em linguagem natural divididas em três níveis de complexidade (Simples, Médio, Complexo), totalizando 180 execuções de consulta.
• Modelos Avaliados: 6 LLMs de ponta de três provedores (Anthropic, OpenAI, Google), divididos em duas categorias:
  • Modelos de Raciocínio: Possuem capacidades de "pensamento" explícito antes de gerar a resposta (ex: Opus 4.5R, GPT-5.2R, Gemini ProR).
  • Modelos Padrão (Não-Raciocínio): Otimizados para velocidade e latência sem etapas de raciocínio explícito (ex: Sonnet 4.5, GPT-5.1, Gemini Flash).
• Métricas Coletadas:
  • Precisão (Corretude sintática e semântica).
  • Bytes Processados (o principal driver de custo).
  • Bytes Transferidos (Shuffle), Dados despejados em disco, Tempo de execução e Slots consumidos.
  • Custo Estimado: Calculado com base na taxa do BigQuery ($6,25 por TB processado).
• Configuração: Prompting zero-shot (sem dicas de otimização explícitas) para avaliar a consciência de custo inerente aos modelos.

3. Principais Contribuições

1. Metodologia de Avaliação Nativa na Nuvem: Introdução de um framework que mede bytes processados, utilização de slots e custo estimado diretamente em infraestrutura de produção, superando as limitações de benchmarks locais.
2. Comparação Empírica de Arquiteturas: Demonstração de que modelos com capacidades de raciocínio geram consultas significativamente mais baratas do que modelos padrão, mantendo a mesma precisão.
3. Análise de Variância de Custo: Identificação de que modelos padrão apresentam alta variância de custo (até 3,4x de diferença entre o melhor e o pior), com consultas "outliers" que escaneiam volumes massivos de dados.
4. Caracterização de Padrões de Ineficiência: Mapeamento de anti-padrões comuns em SQL gerado por LLMs, como falta de filtros de partição, seleção de colunas desnecessárias (SELECT *) e joins cruzados acidentais.

4. Resultados Chave

• Eficiência de Custo (Raciocínio vs. Padrão):
  • Modelos de Raciocínio processaram 44,5% menos bytes em comparação aos modelos Padrão (média de 2.140 MB vs. 3.857 MB).
  • Isso resultou em uma redução de custo de $0,0134 para $0,0241 por consulta.
  • A diferença é estatisticamente significativa ($p = 0,003$) com um tamanho de efeito médio ($d = 0,52$).
• Precisão:
  • 5 dos 6 modelos alcançaram 100% de corretude. O GPT-5.1 (padrão) teve 96,7%.
  • Conclusão: Como a precisão é alta em ambos os grupos, a eficiência de custo torna-se o principal diferenciador.
• Correlação Tempo vs. Custo:
  • A correlação entre tempo de execução e bytes processados foi extremamente baixa ($r = 0,16$).
  • Implicação: Otimizar para velocidade não otimiza para custo. Consultas rápidas podem ser extremamente caras se escanearem muitos dados.
• Variância e Outliers:
  • O modelo GPT-5.1 (Padrão) exibiu a maior variância, com consultas outliers escaneando até 36 GB (mais de 20x a média do melhor modelo).
  • Modelos de raciocínio mostraram comportamentos de custo mais previsíveis e consistentes.
• Padrões de Ineficiência Identificados:
  • Faltando Filtros de Partição: Até 50% das consultas aplicáveis não usaram filtros de partição (crucial em tabelas particionadas por data), forçando varreduras de tabela completa.
  • *SELECT : Modelos da OpenAI tendiam a selecionar todas as colunas, aumentando o escaneamento desnecessário.
  • Joins Cruzados: Ocorreram quando condições de join foram omitidas, gerando produtos cartesianos.

5. Significado e Implicações Práticas

O estudo fornece diretrizes críticas para a implantação de sistemas Text-to-SQL em ambientes corporativos sensíveis a custos:

1. Preferência por Modelos de Raciocínio: Para cargas de trabalho analíticas, o custo adicional de inferência (latência) dos modelos de raciocínio é compensado pela redução massiva nos custos de execução na nuvem (44,5% mais barato).
2. Guardrails de Custo: As organizações devem implementar estimativas de custo e limites de rejeição antes da execução da consulta. Não confiar apenas no tempo de execução como proxy de custo.
3. Detecção de Anti-padrões: Ferramentas automatizadas devem ser usadas para detectar e corrigir padrões como SELECT *, falta de filtros de partição e joins cruzados antes que a consulta seja enviada ao banco de dados.
4. Mudança de Paradigma nos Benchmarks: Futuros benchmarks de Text-to-SQL devem incluir métricas de custo de nuvem (bytes processados) em vez de focar apenas na corretude ou tempo de execução local.

Conclusão Final:
À medida que os sistemas Text-to-SQL migram para a produção sob modelos de preços baseados em consumo, a escolha da arquitetura do modelo (Raciocínio vs. Padrão) e a mitigação de ineficiências no SQL gerado são fatores determinantes para a viabilidade financeira da solução. Modelos de raciocínio oferecem um equilíbrio superior entre precisão e eficiência econômica.