Roteamento de Consultas Inteligente para Assistente de SQL do AI: Como Reduzir Custos Sem Sacrificar a Qualidade

Imagine que seu assistente de SQL é um foguete, atravessando consultas complexas. Então, um dia, você percebe que está usando combustível de foguete para buscar uma lista de compras.

É emocionante, até que a conta de combustível chega. De repente, fica claro que tarefas simples não precisam de um foguete. O mesmo acontece quando todos os pedidos de SQL, desde uma busca básica até uma análise de múltiplos esquemas, são encaminhados para o mesmo modelo de IA poderoso.

O processo de obter um assistente de SQL do AI geralmente é o mesmo. No início, a produtividade aumenta: as consultas são feitas mais rapidamente, o código boilerplate some e os desenvolvedores gastam menos tempo escrevendo consultas de SQL rotineiras. À medida que mais equipes usam, o número de consultas aumenta. Quando a conta de infraestrutura chega, a economia muda.

O problema está na construção. Custa caro para executar modelos de IA Frontier que podem pensar em planos de execução, esquemas e lógica de consulta complexa. Esse preço faz sentido para tarefas difíceis, pois custa cerca de $0,03 por consulta. Quando usado para declarações de SELECT simples e operações de CRUD, torna-se desperdício em escala.

Mas a resposta não é diminuir o modelo. É enviar as consultas para o local certo. O roteamento de consultas inteligente classifica cada solicitação por dificuldade e a envia para o modelo de nível apropriado. Esse método pode reduzir os custos de inferência em 40–70% em cargas de trabalho de SQL sem diminuir a qualidade da saída.

Este artigo explica como essa arquitetura funciona: definindo níveis de complexidade de SQL, construindo pipelines de classificação e roteamento e medindo as verdadeiras trocas de custo-qualidade uma vez que o sistema está em execução. Esses padrões refletem lições aprendidas enquanto desenvolvíamos capacidades de IA conscientes de esquema no dbForge AI Assistant.

Por que um modelo não se ajusta a todas as tarefas de SQL

Não todas as consultas de SQL são iguais em termos de complexidade. Uma consulta que busca um usuário por chave primária e uma que reconstrói funis de sessão em vários esquemas com funções de janela são ambas SQL, mas o raciocínio necessário para gerá-las é muito diferente.

Se um sistema as trata da mesma forma, o resultado é previsível: desperdício de computação. Na maioria das cargas de trabalho de empresa, a maioria das consultas são rotineiras. Buscas simples, leituras de tabela única, inserções básicas, correções de sintaxe. Nada complicado. Enviar todas elas para um modelo de fronteira é como usar um elevador de carga para carregar um caderno.

Uma forma de pensar sobre o problema é dividir as consultas em níveis de complexidade:

A lacuna de custo entre os níveis é grande. Uma consulta de Nível 1 pode custar cerca de $0,001 em um modelo leve. A mesma consulta enviada para um modelo de fronteira custa cerca de $0,03. Em 10.000 consultas por dia, isso é $10 vs $300 em gastos diários. Uma diferença de 30 vezes, apenas por decisões de roteamento.

O conhecimento de esquema também importa aqui. As consultas de Nível 3 não precisam apenas de mais computação. Elas precisam de contexto: relacionamentos entre tabelas, chaves estrangeiras, índices, sintaxe específica do banco de dados. Esse contexto precisa ser injetado durante a inferência.

Executar uma consulta simples de Nível 1 por meio do mesmo caminho pesado desperdiça tokens, adiciona latência e não melhora o resultado.

Uma arquitetura prática para a seleção de modelo

Um sistema de roteamento geralmente tem quatro estágios: classificar, rotear, executar e validar. Cada estágio faz um trabalho diferente e cada um pode falhar de maneiras diferentes. Ajuda a pensar sobre eles separadamente antes de montar o pipeline completo.

A classificação é o passo mais importante. O classificador recebe a consulta de SQL bruta ou o prompt de linguagem natural que gerará uma e a atribui a um nível de complexidade. Existem três maneiras comuns de construir esse classificador.

Classificação baseada em regras depende de padrões de regex e parsing de árvore de sintaxe abstrata (AST) para detectar sinais estruturais: coisas como contagem de tabelas, profundidade de aninhamento, funções de janela, subconsultas ou operadores de agregação. Essa abordagem é rápida e previsível, com quase nenhum overhead. Funciona bem para casos óbvios: declarações de SELECT simples e DML básico geralmente podem ser identificados sem envolver um modelo. 

Modelos de classificador leves usam um pequeno modelo de linguagem treinado para estimar a complexidade do SQL. Isso adiciona um passo extra, mas é uma das decisões de ROI mais altas no pipeline. Uma chamada de classificador pode custar cerca de $0,0001, o que facilmente justifica evitar uma chamada de modelo de fronteira de $0,03. 

Em muitas configurações, esses modelos leves também podem ser executados localmente, efetivamente removendo o custo para consultas de usuário simples. Eles também podem classificar prompts de linguagem natural antes que o SQL seja gerado, o que é útil em fluxos de trabalho de assistentes onde a consulta ainda não existe. 

Classificação híbrida combina ambas as abordagens. A lógica baseada em regras lida com casos claros a zero custo, enquanto o classificador lida com o meio ambíguo: consultas que parecem moderadas, mas podem realmente exigir conhecimento de esquema e raciocínio para gerar corretamente. 

Roteamento acontece após a classificação. Mas o nível sozinho não é o único fator. Alguns outros fatores influenciam para onde uma consulta deve ir. Esses incluem:  

1. Requisitos de contexto de esquema. Algumas consultas precisam que o modelo entenda relacionamentos entre tabelas, índices ou outros detalhes estruturais. Essas consultas carregam mais contexto e geralmente precisam ser roteadas para um modelo de capacidade mais alta. 
2. Tolerância à latência. Recursos de interface do usuário, como autocompletar ou sugestões em linha, têm orçamentos de latência estritos. Tarefas em segundo plano geralmente não. Nesses casos, um modelo mais lento, mas mais capaz, pode ser aceitável. 
3. Limites de confiança. Às vezes, o classificador não tem certeza sobre o nível. Nesses casos, rotear para cima geralmente é a opção mais segura. Um downgrade errado pode produzir uma consulta ruim e desencadearar retries, o que geralmente custa mais do que usar o modelo mais forte desde o início. 

A camada de validação é executada após o código ter sido executado. O trabalho dela é pegar erros de roteamento antes que eles cheguem ao usuário. Após a execução, são feitas verificações para garantir que a sintaxe esteja correta, que os resultados sejam razoáveis (a consulta retornou as formas de linha certas?) e que o esquema seja consistente. Quando um resultado falha na validação, o sistema move para cima de um nível e executa a consulta novamente.

Na Devart, a coisa mais importante para obter a precisão do roteamento do dbForge AI Assistant foi construir contexto de esquema consciente na decisão de classificação. Sem contexto de esquema, as consultas que usavam nomes de tabelas ambíguos ou dependiam de relacionamentos implícitos sempre foram mal classificadas e enviadas para modelos mais baratos que não podiam lidar com elas. A solução foi dar ao classificador não apenas a estrutura da consulta, mas também alguns metadados de esquema.

Medindo o que importa: trocas de custo-qualidade na prática

O caso de negócios para o roteamento só se sustenta se a qualidade se mantém junto com ele. A redução de custos que causa saída degradada, aumenta os retries ou a desconfiança dos desenvolvedores não é uma economia, é uma transferência de custo da conta de infraestrutura para o tempo de engenharia. Três métricas determinam se um sistema de roteamento está realmente funcionando.

Custo por consulta por nível estabelece a linha de base. Acompanhe o gasto real em cada nível separadamente, não como uma média misturada. Misturar obscurece se o roteamento está funcionando; um sistema que roteia 50% das consultas para o nível errado ainda mostrará um custo médio mais baixo, enquanto produz resultados piores em silêncio. 

A pontuação de qualidade verifica a correção, a completude e o seguimento das melhores práticas de SQL. A taxa de escalonamento é o sinal mais direto. Ela diz quantas vezes um modelo de Nível 1 ou Nível 2 produz saída que não passa na validação e precisa ser enviada para um local diferente. Um sistema bem ajustado deve manter a escalonamento abaixo de 5%. O classificador precisa ser retreinado acima desse nível. Pode estar lendo sinais estruturais incorretamente ou pode não ter o contexto de esquema que precisa para distinguir entre moderado e complexo. 

Impacto na latência olha para quanto tempo leva para uma resposta se mover de um nível para o outro, incluindo qualquer tempo extra necessário para a classificação. Os usuários devem notar apenas um atraso de 50 a 100 milissegundos em interações que passam pela camada de roteamento. Se a classificação em si se tornar um problema, a abordagem híbrida (regras para casos claros, classificador apenas para casos incertos) resolve isso sem perder precisão. 

Na vida real, um sistema de roteamento bem ajustado pode reduzir os custos de inferência em 40–60%, manter a escalonamento abaixo de 5% e manter a qualidade da saída alta para consultas complexas. Para economizar 70% ou mais, você geralmente precisa fazer tarefas de Nível 1 sozinho com modelos menores. Isso pode funcionar, mas também complica as coisas, o que nem todas as equipes querem lidar.

O “imposto de escalonamento” é outra coisa que precisa ser considerada. Se o roteamento for muito duro nos modelos mais baratos, o sistema pode precisar fazer mais trabalho no geral: chamada de classificador, chamada de modelo inicial, falha na validação, roteamento e uma segunda chamada de modelo. Em alguns casos, isso custa mais do que enviar a pergunta para o modelo de fronteira desde o início.

Olhar apenas para o custo por chamada perde esse efeito. A taxa de escalonamento precisa ser rastreada junto com ele.

Dicas estratégicas para equipes de engenharia

Roteamento inteligente não é apenas um recurso desejável para implantações de SQL do AI maduras; é um requisito para as de longo prazo. As equipes que pulam isso trocam um problema de orçamento que não pode ser resolvido por um problema de arquitetura que pode ser. Os padrões estão lá; a única coisa que resta é decidir quais seguir primeiro.

Comece com o classificador, não com os modelos. A camada de roteamento decide se tudo mais funciona. Um classificador híbrido bem ajustado dará a você a maioria das economias de custo sem complicar as coisas.

Use o contexto de esquema da alimentação para ajudar a tomar decisões de classificação. Para cargas de trabalho de SQL que envolvem relacionamentos entre múltiplas tabelas ou raciocínio específico de esquema, a estrutura da consulta sozinha não é suficiente. Metadados de esquema parciais no momento da classificação aumentam muito a precisão do nível.

Use a taxa de escalonamento como o principal sinal de qualidade. Ela encontra a classificação errada mais rápido do que qualquer outra métrica e mostra exatamente onde o classificador precisa melhorar.

Antes do classificador, planeje a camada de validação. Saber como a falha parece e o que causa uma escalonamento torna a lógica de roteamento mais limpa e o sistema melhor capaz de lidar com casos de bordo.

O valor da camada de roteamento aumenta, não diminui, à medida que os modelos de código aberto melhoram e o custo da inferência local diminui. Modelos de Nível 1 mais baratos tornam a diferença de custo entre os níveis maior, o que torna a classificação correta mais valiosa. A arquitetura de roteamento construída hoje será útil por muito tempo, não apenas como uma solução rápida.