AWS mostra Text-to-SQL no Amazon Bedrock para traduzir perguntas de negócio em SQL

A AWS publicou um detalhamento completo de uma solução Text-to-SQL no Amazon Bedrock, que traduz perguntas de negócios em linguagem natural para consultas SQL e retorna imediatamente a resposta de forma compreensível. Este não é um novo produto separado, mas uma arquitetura prática para empresas que possuem dados, mas ainda carecem de respostas rápidas a perguntas de negócios.

Por Que o BI Falha

A AWS explica o problema de forma simples: mesmo em empresas com análises robustas, os usuários ainda enfrentam um gargalo esperando por analistas ou lidam com as limitações dos dashboards pré-construídos. Se uma pergunta vai além de um relatório pré-montado, você precisa de joins, fatias de tempo, métricas calculadas e conhecimento da lógica interna das tabelas. Para vendas, finanças ou operações, isso significa perder horas ou até dias em uma consulta única que não justifica um desenvolvimento separado por si só.

De acordo com a AWS, é aqui que o BI self-service padrão começa a falhar. A linguagem natural em interfaces de BI funciona bem com camadas semânticas pré-preparadas, mas tem dificuldades com tabelas brutas, terminologia interna e métricas que são calculadas de forma diferente em cada empresa. É por isso que a AWS propõe construir não apenas um gerador de SQL, mas um sistema que compreenda o contexto de negócios: o que é receita, como o pipeline é calculado e quais tabelas podem ser unidas.

Como o Pipeline Funciona

No núcleo da arquitetura está o Amazon Bedrock como camada de inferência e orquestração, mais um grafo de conhecimento para contexto de negócios e um armazém analítico para execução de consultas. O AgentCore Runtime desempenha um papel central: ele recebe a pergunta, decide se ela precisa ser dividida em subtarefas, chama a busca de contexto, dispara a geração de SQL e retorna a resposta final. Para as empresas, isso é importante porque a lógica não está codificada em um único prompt: ela pode ser dividida em etapas separadas e controlada em cada fase.

• classificação da pergunta como simples ou complexa
• busca de contexto de negócios através do GraphRAG
• geração de SQL em formato estruturado
• validação determinística da consulta antes da execução
• síntese da resposta em linguagem natural com base nos resultados da consulta

Para o contexto, a AWS usa uma combinação de Amazon Neptune e OpenSearch: o grafo armazena relacionamentos entre tabelas, colunas, métricas, termos e hierarquias dentro da empresa. Em seguida, o sistema realiza uma busca vetorial nas descrições e valores, percorre os relacionamentos do grafo e fornece ao modelo apenas tabelas, campos, caminhos de join e regras de negócios relevantes. Para perguntas complexas, a arquitetura pode executar múltiplos agentes em paralelo e selecionar o resultado mais confiável por votação por maioria.

Produção e Controle

A parte mais prática do artigo não é sobre LLM, mas sobre camadas de proteção. A AWS enfatiza especificamente que prompts sozinhos não podem captar de forma confiável SQL semanticamente incorreto: uma consulta pode ser sintaticamente válida, mas entregar um resultado perigoso ou simplesmente falso. Portanto, após a geração de SQL, ela é verificada com validadores determinísticos em nível AST.

Se o sistema detectar um risco—por exemplo, uma varredura muito ampla, agregação incorreta ou filtros necessários ausentes—ele corrige automaticamente a consulta e tenta novamente. O segundo tópico é latência e acessos. De acordo com os dados da AWS, consultas SQL simples nesse esquema são tipicamente geradas em cerca de 3 a 5 segundos, embora o tempo total dependa do modelo, do tamanho do grafo de conhecimento e da velocidade do armazém.

Para manter a interatividade, a AWS recomenda paralelizar subtarefas, economizar tokens e não inflar o contexto do agente. Paralelamente, a arquitetura inclui imediatamente filtros Row-Level Security para que os usuários vejam apenas as linhas às quais já têm acesso de acordo com as regras corporativas.

O Que Isto Significa

A AWS efetivamente demonstra que Text-to-SQL deixa de ser uma demonstração em sandbox e se torna um padrão de engenharia para cenários reais de BI. A principal conclusão não é que LLM consegue escrever SQL, mas que um sistema funcional exige um grafo de conhecimento, verificações, orquestração e controle de acesso. Para equipes que desejam dar ao negócio uma interface de chat para dados, este é um bom ponto de referência: menos magia, mais infraestrutura e regras.