AWS mostra como baratear o text-to-SQL com Amazon Nova Micro e Bedrock

A AWS mostrou como obter text-to-SQL para bancos de dados internos sem pagar pela hospedagem permanente e cara de um modelo. A empresa ajustou o Amazon Nova Micro para dialetos SQL fora do padrão e o implantou no Amazon Bedrock, pagando apenas pelas requisições reais.

Por que isso importa

Em cenários corporativos, um modelo genérico muitas vezes não basta: ele escreve SQL padrão razoavelmente bem, mas começa a errar quando a empresa tem convenções próprias, funções raras, esquemas de tabelas específicos e regras de domínio. Por isso, a consulta em texto do usuário precisa ser adaptada a um dialeto e a uma estrutura de banco de dados concretos, o que exige treinar o modelo com exemplos próprios. Isso é especialmente visível em sistemas de BI e chats analíticos internos, onde um erro de sintaxe quebra todo o fluxo de imediato.

O problema é que o ajuste fino costuma trazer também custos permanentes de infraestrutura. Se o modelo personalizado fica em servidores dedicados, a empresa paga mesmo quando não há consultas. Na sua análise, a AWS propõe outra opção: ajustar o Amazon Nova Micro com LoRA e executá-lo no Amazon Bedrock em modo de inferência on-demand, em que a cobrança é por token, e não por capacidade reservada de forma permanente.

As duas abordagens da AWS

A AWS descreve dois cenários para a mesma tarefa.

O primeiro é o ajuste fino gerenciado dentro do Amazon Bedrock. Serve a equipes que valorizam simplicidade, início rápido e o mínimo de trabalho com infraestrutura de ML. Os dados são enviados ao S3, o job de fine-tuning é iniciado pelo console ou pela API, e depois a AWS gerencia o treinamento e a implantação da versão personalizada do Nova Micro. Essa opção é voltada mais a uma equipe de aplicações do que a uma plataforma de ML dedicada.

O segundo caminho é o treinamento via Amazon SageMaker AI. É mais complexo, mas dá mais controle sobre a receita de treinamento: dá para alterar o tamanho do lote, o dropout, os parâmetros do otimizador, a janela de contexto, as configurações de LoRA e a estratégia de warmup do learning rate. No exemplo, a AWS usou o dataset sql-create-context, montado a partir de WikiSQL e Spider, e converteu os pares pergunta-SQL para o formato bedrock-conversation-2024 para treinamento e validação. O preço é uma configuração mais complexa e um trabalho mais explícito com a infraestrutura.

É assim que as opções se diferenciam na prática:

• Bedrock: menos carga operacional e caminho mais rápido até um protótipo funcional
• SageMaker AI: mais controle sobre hiperparâmetros e integração com MLOps
• Os dois esquemas usam o mesmo pipeline de preparação de dados e depois são implantados no Bedrock
• A inferência final roda em modelo serverless com pagamento por tokens, sem hospedagem permanente

Preço e latência

A AWS apresenta números concretos. No ajuste gerenciado do Bedrock, o custo de treinamento é calculado a US$ 0,001 por 1.000 tokens por época: no exemplo com 2.000 amostras, cinco épocas e cerca de 800 tokens por registro, o total foi de cerca de US$ 8. A variante com SageMaker usou uma instância ml.g5.48xlarge a US$ 16,288 por hora; o treinamento com um dataset de 20.000 linhas levou cerca de quatro horas e custou aproximadamente US$ 65,15.

A tese central do artigo não é o preço pontual do treinamento, mas o custo de operação. A AWS estimou uma carga de produção de exemplo de 22.000 requisições por mês, ou 100 usuários com 10 consultas por dia ao longo de 22 dias úteis. Com tamanho médio de 800 tokens de entrada e 60 de saída, a inferência mensal desse modelo text-to-SQL personalizado ficou em US$ 0,80. Isso é possível porque o Nova Micro personalizado no Bedrock é tarifado igual ao modelo base, sem acréscimo pela implantação serverless.

Há um compromisso em velocidade, mas moderado. Em cold start, o tempo médio até o primeiro token subiu para 639 ms, 34% acima do modelo base. Em operação normal, o TTFT médio foi de 380 ms em 50 chamadas, apenas 7% pior que o da base. A latência total de geração ficou em cerca de 477 ms, e a velocidade de saída se manteve em 183 tokens por segundo. A AWS avaliou a qualidade não só pela latência, mas também com LLM-as-a-Judge, comparando o SQL gerado com respostas de referência.

O que isso significa

Para equipes que querem embutir text-to-SQL em produtos analíticos, ferramentas internas de BI ou interfaces de chat para bancos de dados, o caso da AWS parece prático: é possível ter um gerador de SQL personalizado sem custos permanentes de infraestrutura dedicada. Se a velocidade de lançamento pesa mais, o lógico é olhar para o Bedrock; se é preciso controle total sobre o treinamento, a combinação com o SageMaker AI parece mais forte.