- O recurso de Text-to-SQL baseado no Gemini está sendo usado em todo o Google Cloud para aumentar a produtividade de desenvolvedores e usuários não técnicos
- Em ambientes reais, é difícil gerar SQL com precisão devido à falta de contexto de negócio, dificuldade para interpretar a intenção do usuário e diferenças entre dialetos SQL
- Para resolver isso, o Google introduz técnicas como busca inteligente de dados, aprendizado com base em contexto e criação de camadas semânticas
- As limitações do próprio modelo são superadas com geração múltipla seguida de seleção da melhor opção (self-consistency), validação com novo prompt e treinamento por dialeto SQL
- A avaliação e a medição de melhorias incluem benchmarks próprios e técnicas que usam o LLM como juiz, aumentando a viabilidade de aplicação em ambientes reais
Techniques for improving text-to-SQL
Da conversão de texto para SQL: a situação atual no Google Cloud
- As organizações usam SQL para obter insights de dados com rapidez e precisão
- O Gemini oferece o recurso de text-to-SQL, que gera SQL diretamente a partir de linguagem natural
- Esse recurso é útil não apenas para desenvolvedores, mas também para usuários não técnicos
- Atualmente, esse recurso está disponível no BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI e outros
Principais desafios da tecnologia Text-to-SQL
1. Dificuldade em fornecer contexto de negócio
- Para escrever SQL com precisão, é necessário fornecer ao LLM contexto suficiente, como a estrutura do banco de dados, o significado das colunas e o conteúdo real dos dados
- O contexto inclui tanto informações explícitas (schema, informações de colunas etc.) quanto implícitas (como o significado de negócio de determinados dados)
- Manter o treinamento contínuo (fine-tuning) do LLM para acompanhar mudanças na estrutura do banco, transformações no dataset e alterações de schema é, na prática, muito caro
- Muitas vezes, o conhecimento de negócio ou as informações semânticas não estão organizados adequadamente, e também é difícil convertê-los em dados de treinamento
- Exemplo: se um DBA não souber o significado de
cat_id2 = 'Footwear' na tabela pcat_extension, ele também não conseguirá escrever um SQL para consultar vendas de calçados — com o LLM acontece o mesmo, e a falta de contexto pode levar à geração de consultas imprecisas
2. Problemas na interpretação da intenção do usuário
- Consultas em linguagem natural frequentemente têm menos clareza do que o SQL
- Na prática, analistas de dados ou engenheiros podem fazer perguntas adicionais quando uma solicitação é ambígua, mas o LLM tende a gerar uma resposta imediatamente com base na pergunta recebida, o que traz risco de informação incorreta (hallucination)
- Em uma pergunta como “Qual foi o calçado mais vendido?”, detalhes como o critério de “mais vendido” (número de pedidos, faturamento etc.) ou a quantidade de resultados desejada são ambíguos
- Usuários com conhecimento técnico podem usar um SQL aproximado como ponto de partida, mas, para não especialistas, o mais importante é um SQL que funcione corretamente
- Para funcionar de forma eficaz, o LLM precisa oferecer recursos de perguntas de acompanhamento, explicação do raciocínio e orientação ao usuário para entender claramente a intenção
3. Limitações de geração do LLM
- LLMs são fortes em tarefas como resumo de documentos e extração de informações, mas têm fragilidades quando se trata de sintaxe SQL exata ou recursos SQL menos usados
- A sintaxe varia conforme o dialeto SQL, e até pequenas diferenças exigem alto nível de precisão
- Exemplo: no BigQuery usa-se
EXTRACT(MONTH FROM timestamp_column), enquanto no MySQL deve-se usar MONTH(timestamp_column)
- Gerar SQL de forma consistente seguindo especificações complexas continua sendo um desafio para os LLMs
Técnicas do Google Cloud para melhorar Text-to-SQL
Problema: schema e contexto de negócio
- Busca e ranking baseados em semântica
- Aprendizado em contexto
- Amostragem e conexão de dados
- Construção de camadas semânticas
- Análise de padrões de uso e histórico
Problema: interpretação da intenção do usuário
- Esclarecimento por meio de LLM
- Identificação de entidades, verificação de informações relacionadas e indução de perguntas de acompanhamento apropriadas
Problema: superando as limitações do LLM
- Self-consistency para gerar múltiplas consultas e selecionar a melhor
- Validação e novo prompt
- Aprendizado em contexto com exemplos de dialetos SQL
- Fine-tuning do modelo
Exemplos de aplicação das principais técnicas
Modelo SQL-aware
- O Gemini usa várias versões com fine-tuning para gerar SQL de alta qualidade
- Para garantir precisão por dialeto SQL, são feitas combinações de versões de modelo e ajustes personalizados
Esclarecimento da pergunta do usuário (Disambiguation)
- Quando a pergunta é ambígua, são geradas perguntas de esclarecimento
- Exemplo: "Qual é o calçado mais vendido?" → “Você quer dizer por número de pedidos ou por faturamento?”
Busca semântica e construção de contexto
- Busca vetorial baseada em correspondência semântica em múltiplas etapas para identificar tabelas e colunas relevantes
- O prompt é montado incluindo histórico de consultas do usuário, exemplos de regras de negócio etc.
- O suporte a janelas de contexto longas permite lidar com schemas grandes
Validação e regeneração
- Erros explícitos são detectados por meio de parsing, dry-run e outros métodos aplicados à consulta gerada pelo LLM
- Quando um erro é detectado, um novo prompt orienta a correção
Self-consistency
- Em vez de uma única consulta, são geradas várias consultas de formas diferentes
- Quando vários modelos recomendam a mesma consulta, a precisão aumenta
Avaliação e medição de desempenho
- Benchmarks existentes (como BIRD-bench) são úteis, mas têm limitações para refletir schemas reais
- O Google construiu seu próprio conjunto de benchmarks sintéticos
Estratégia de avaliação
- Cobertura de dialetos SQL e funcionalidades por engine: inclui não apenas consultas, mas também DDL, DML e tarefas administrativas
- Métricas de avaliação: reação do usuário, métricas offline, LLM-as-a-judge
- Avaliação contínua: permite verificar rapidamente a eficácia de novos modelos e técnicas de prompt
Encerramento
1 comentários
Comentários do Hacker News
Há uma reflexão sobre o objetivo final da conversão de texto para SQL: se a ideia é criar um assistente para analistas de dados ou obter insights de negócio sem passar por um analista. Se for a segunda opção, existe o problema de que, por mais sofisticado que seja, é impossível para um não especialista julgar a correção e a suficiência do SQL. Perguntas como “por que ontem as transações de e-commerce ficaram em 80%?”, “por que o custo de aquisição de clientes está subindo?” e “por que a campanha de Nova York foi pior do que a de San Francisco?” estão fora do escopo de text2sql
Na prática, parece mais próximo do segundo objetivo, mas o resultado fica aquém do esperado. Nas empresas, querem alterar relatórios no fim do processo, mas por falta de analistas não conseguem obter a informação desejada no momento certo. Tenta-se resolver isso com “velocidade infinita”, mas o problema real vem de não pensar o suficiente sobre as métricas. Os dados são complexos, o conhecimento de negócio fica implicitamente armazenado fora do sistema e a infraestrutura de dados é insuficiente, então a análise leva muito tempo. Líderes de análise inteligentes estão usando a onda da IA para investir na infraestrutura básica
Eu diria que as perguntas acima nem são problemas que podem ser resolvidos com SQL em primeiro lugar. SQL responde principalmente ao “o quê (what)”, não ao “por quê (why)”. O objetivo de text2sql é reduzir o tempo que o analista gasta para chegar ao “o quê”, ajudando-o a se concentrar no “por quê”
Faz sentido, mas na minha visão texto em linguagem natural pode ser a entrada universal para sistemas com LLM. Text2sql pode servir como base de recuperação de informação para compor respostas a perguntas mais complexas. No curto prazo, é uma função de apoio ao trabalho, mas no longo prazo o objetivo é construir a base para automação, comparação de resultados e integração em fluxos de trabalho maiores. O ponto principal é preparar a base para responder a esse tipo de pergunta. Ainda há muito trabalho pela frente
Qualquer algoritmo pode ser criado e testado se um humano consegue fazer a tarefa. Se há 10 analistas, todos terão níveis diferentes de entendimento do banco de dados, do negócio e de habilidade. A automação fornece um padrão que garante um nível mínimo de competência e conhecimento. Mesmo um analista novo consegue entregar resultados melhores de imediato. É um objetivo útil desenvolver o sistema em colaboração com especialistas, testando-o e fazendo a IA interpretar trade-offs, bugs e comparações com os resultados esperados. Insight ou “taste” é difícil de automatizar, mas um especialista de domínio pode ir muito longe se tiver uma automação bem projetada e senso de quais resultados são razoáveis. Não é perfeito, mas esse é o meu objetivo
Compartilhamento de experiência com o modelo OpenAI 4o: foram incluídas no prompt diretrizes de negócio, termos do setor e descrições de tabelas e chaves estrangeiras. Com isso, ele gera até consultas complexas com joins e retorna os resultados. O objetivo era fornecer resultados para usuários que não conhecem SQL, mas o SQL em si também é mostrado como referência
A IA não precisa gerar SQL perfeito. No meu caso, mesmo que a saída seja validada por código, eu não copio e uso diretamente por causa do risco de pequenas diferenças semânticas. Em vez disso, se a IA me mostra uma abordagem, eu uso aquilo como referência e escrevo o SQL do zero por conta própria
Relato de uso da versão mais recente do Gemini no Google AI Studio: é impressionante e inovador a ponto de surpreender. Os resultados de código do Claude e do ChatGPT parecem coisa de outro século. Até um mês atrás eu achava o Claude incrível, mas agora não sei como continuaria programando sem o Google Gemini. O Gemini AI Studio é um salto gigantesco para programação
Surpreende que tanta gente ainda não tenha percebido essa mudança. O Claude também lida bem com tarefas pequenas, mas quando evolui para problemas complexos o Gemini fica muito à frente. A capacidade de lidar com contexto é especialmente impressionante. Eu o uso não só como agente de código, mas também para leitura beta de um manuscrito de 85.000 palavras, recebendo quase em tempo real relatórios de feedback em nível profissional
Nesta semana tive a sensação de que desativaram o modo de raciocínio no Gemini Pro gratuito. Se você impedir que ele pare logo antes de escrever código ou que generalize demais, ele é bastante útil. Ainda assim, o Gemini tende a escrever código em excesso. A forma como mais gosto de usá-lo é para exploração de design, sem ficar preso à implementação do código. Em um caso como criar um serviço de assinatura com Stripe, por exemplo, consegui receber em contexto dados já existentes adaptados à minha stack e ao meu caso de uso e mudar a direção do design antes mesmo de escrever uma única linha de código
A resposta é “usar semantic layer”. É a forma mais eficaz de passar o contexto correto e o ponto ideal para intervenção humana direta. Se uma pessoa definir claramente todos os indicadores principais, o LLM poderá usá-los a qualquer momento. Por exemplo, se MAU estiver definido, o LLM gerará a consulta com base nessa definição. Se a consulta for escrita em JSON em vez de SQL, o LLM produz resultados muito mais consistentes. Nós usamos cube, que é a melhor semantic layer open source. Também existem opções proprietárias na Naver. Minha antiga empresa já tinha escrito até um blog sobre isso, mas hoje a empresa proprietária parou de hospedar
É arriscado usar IA para criar SQL no trabalho real. Uma pessoa que não conhece SQL pode escrever uma consulta errada e causar impacto sério no servidor. No nosso time, o banco de dados é grande para os padrões da maioria dos desenvolvedores, mas não é gigantesco de verdade. Às vezes pedimos à IA para melhorar ainda mais consultas já otimizadas, mas ela nunca deu uma resposta melhor. Em alguns casos a IA fala bobagem ou faz sugestões inúteis na prática. Parece um papagaio burro repetindo algo que ouviu antes
Acho que seria muito conveniente se existisse uma função de IA para converter texto em regex
De todas as ferramentas de IA que já usei, a mais decepcionante foi o Gemini embutido no BigQuery. Os nomes das colunas eram claros e também havia boas descrições, mas ele não chegou nem perto de resolver o problema
A linguagem em que mais escrevi consultas até hoje foi SQL. Mesmo quando peço para a IA escrever consultas, levo muito mais tempo refinando o resultado do que levaria se tivesse escrito eu mesmo. Em paralelo, eu gostaria que existisse uma função que me permitisse escrever SQL muito mais rápido. A DSL da nossa empresa tem um operador que faz join automático com base em chaves estrangeiras, e isso é extremamente conveniente. A parte mais irritante de escrever SQL é ter de escrever manualmente 10, 20 ou mais joins. Comparado a isso, o resto nem é tão difícil
Pela minha experiência, quase tudo se resolve quando há restrições claras e chaves estrangeiras bem definidas. Cada tabela precisa ter restrições claras para que a IA consiga entender corretamente toda a estrutura de conexões. SQL tem uma especificação muito precisa, mas justamente por isso, se as restrições e chaves estrangeiras não estiverem bem definidas, a IA não consegue dar respostas corretas
Em todos os foundation models isso já ficou bem simples. Se o schema das tabelas tiver bons comentários, pedir geração de consulta é algo simples
Se você montar um scaffolding em volta do modelo com a biblioteca smolagents, fica bem conveniente. Também há textos dizendo que text2sql parece simples em demo, mas é muito difícil aplicar isso a casos reais complexos
Step 1: o schema tem milhares de tabelas e quase não há comentários. Step 2...
Concordo totalmente. Agora já não existe mais tanta mágica assim. O DDL de criação da tabela é uma descrição precisa da tabela, então na prática quase não é preciso mais nada. Se você explicar bem a consulta necessária, praticamente qualquer LLM consegue gerá-la com facilidade
No post "Show HN: We open sourced our entire text-to-SQL product" (2024), há ótimas referências mencionadas, como awesome-Text2SQL e Awesome-code-llm > Benchmarks > Text to SQL