Benchmark de RAG agêntico: roteamento entre 11 bancos de dados SQL

A precisão de roteamento é a porcentagem de perguntas pontuadas nas quais o modelo nomeia explicitamente o banco de dados correto em sua resposta final. O resultado principal usa as 184 perguntas marcadas como difíceis tanto por nosso teste de similaridade quanto por um júri de três LLMs. Declarações explícitas ausentes não recebem crédito.

Descobertas de roteamento de banco de dados

qwen3.8-max registrou 83,2% de precisão de roteamento em uma execução de US$ 25.14

O Qwen3.8-max respondeu corretamente a 153 de 184 perguntas difíceis de roteamento a um custo registrado de US$ 25.14. O claude-fable-5 respondeu 151 a US$ 121.55. Todas as 759 perguntas foram concluídas em ambas as execuções.

Essa diferença de duas perguntas é menor do que a variação medida na repetição do qwen3.8-max. Os custos registrados dependem da seleção do provedor e do uso de cache, portanto essa comparação não pode estabelecer um ranking duradouro de preço-desempenho.

A precisão final de roteamento aumentou para o Grok e o Opus, mas caiu para o Nova

Para o claude-opus-5, a precisão em perguntas difíceis aumentou 25.0 pontos percentuais entre a primeira sondagem de banco de dados e a declaração final. O grok-4.5 ganhou 38.0 pontos na própria execução. O gpt-5.4-mini não registrou ganho, enquanto o nova-lite-v1 perdeu 14.0 pontos.

Cada mudança compara o início e o fim de uma execução. Perguntas que tocaram vários bancos de dados na primeira rodada são excluídas porque não têm uma única primeira escolha.

Esta contagem usa o primeiro banco de dados na ordem de chamada registrada, incluindo primeiras rodadas com vários bancos de dados. As mudanças em pontos percentuais acima usam uma única primeira escolha.

Portanto, uma chamada de banco de dados não garante uma correção útil. O que importa é se o modelo usa as informações retornadas para chegar à escolha final correta. Esta é uma observação das trajetórias registradas, sem uma intervenção separada que isole o valor de chamadas extras.

Resultados de roteamento de banco de dados

Os modelos aparecem em ordem alfabética. A metodologia identifica diferenças no software usado para executá-los. Essas condições importam ao interpretar pequenas diferenças de pontuação.

Os intervalos estimam a incerteza da amostragem de perguntas. Os custos registrados cobrem os registros bem-sucedidos em cada execução. Eles refletem os provedores e as condições de cache usadas no momento da medição.

Modelos de decisão para roteamento de banco de dados

Comparamos o Jev, o Kev-9B, o Laya English e seis LLMs em 243 perguntas revisadas dos mesmos 11 bancos de dados. Cada modelo selecionou um banco de dados a partir das descrições fornecidas.

O Laya foi executado localmente em um Mac Apple M4. O Kev foi executado em um serviço A100 dedicado acessado por um túnel SSH. Os outros modelos usaram APIs hospedadas. A latência inclui a solicitação completa do cliente entre as respostas válidas. A precisão inclui todas as perguntas tentadas.

O Jev selecionou o banco de dados correto para 240 de 243 perguntas, em comparação com 123 do Laya English: 117 seleções corretas a mais, uma diferença de 48.1 ponto percentual. O Jev foi o modelo hospedado mais rápido por latência mediana nesta execução. A implantação local do Laya teve a menor latência mediana geral, junto com uma precisão substancialmente menor.

O Kev-9B selecionou 236 bancos de dados corretamente, quatro a menos que o Jev. Cinco de seus sete erros envolveram o banco de dados de cartão de débito de combustível. Sua resposta mediana levou 952 ms, incluindo a rede e o túnel SSH. A mediana do servidor registrada separadamente foi de 470 ms. Essa implantação do A100 usou FP32 e kernels de referência. Sua velocidade depende dessa configuração de serviço.

O Gemini 3.8 Flash e o Claude Opus 5 selecionaram o banco de dados correto em todas as perguntas. O Opus levou 1.72 vezes mais tempo na mediana e seu custo de API relatado foi 7.58 vezes o do Gemini para essas perguntas. A precisão foi igual para esses dois modelos neste conjunto.

O resultado do DeepSeek inclui 19 falhas de serviço ou de saída: 16 respostas HTTP 429, duas respostas que quebraram o formato exigido de alias único e uma que esgotou o orçamento de saída. Ele selecionou o banco de dados correto em 211 de suas 224 respostas válidas, ou 94,2%. Contando todas as tentativas, obtém-se os 86,8% mostrados no gráfico e na tabela.

Custos de roteamento: preços de API e estimativas de hardware

O Jev selecionou o banco de dados correto em 98,8% das perguntas a um custo de API de US$ 0.0337 por 1.000 tentativas de roteamento. O Qwen3.8 Flash registrou 97,9% de precisão a US$ 0.0791, enquanto o Gemini 3.8 Flash alcançou 100,0% a US$ 0.5337. Escalonamos os custos a partir da mesma carga de trabalho de 243 perguntas, incluindo respostas incorretas e excluindo aquecimentos. O custo de API do Jev foi cerca de 1/120 do custo do Claude Opus 5 para as mesmas 243 tentativas de roteamento.

A estimativa de hardware do Laya foi de US$ 0.0141 por 1.000 tentativas com 50,6% de precisão. O Kev alcançou 97,1% a um custo estimado de US$ 0.1250. Ambas as estimativas pressupõem que a máquina alugada processa solicitações continuamente. Com 10% de utilização, cada solicitação carrega dez vezes o custo de aluguel, elevando o Laya para US$ 0.1405 e o Kev para US$ 1.2503 por 1.000 tentativas.

Para os cinco LLMs com registros completos de cobrança, dividimos as cobranças de API relatadas por 243 e multiplicamos por 1.000. O Jev cobra US$ 0.042 por milhão de tokens de entrada, com tokens de saída gratuito. Seus 194.882 tokens de entrada registrados custaram US$ 0.008185 em 243 tentativas, ou US$ 0.0337 por 1.000.¹

O custo de hardware por 1.000 tentativas é igual ao preço de aluguel por hora × segundos médios de processamento × 1.000 ÷ (3.600 × utilização). O Laya obteve média de 0.2006 segundos por solicitação em um Mac Apple M4. O Kev obteve média de 0.4734 segundos no servidor A100, excluindo a rede e o atraso do SSH. Aplicamos esses tempos a hardware correspondente nos provedores cotados. O desempenho e os totais de faturamento nesses provedores permanecem não medidos.

Para o Kev, usamos US$ 0.9508/hora para um A100 SXM de 80 GB na Vast.ai, a listagem sob demanda correspondente mais baixa em nossos dados do GPU índice de preços de aluguel.

Para o Laya, usamos o M4-S da Scaleway com 16 GB de memória a €0.22/hora. A conversão usa a taxa de 22 de setembro do BCE de US$ 1.1463 por euro. A Scaleway exige um aluguel mínimo de 24 horas, o que torna o aluguel mínimo de €5.28, ou cerca de US$ 6.05, mesmo para um trabalho curto.²³⁴

A página do modelo do Laya não listava nenhum Provedor de Inferência do Hugging Face. Nossa estimativa cobre o aluguel de uma máquina e a execução do modelo nela. Tempo de configuração, armazenamento, extras de rede, impostos e mão de obra operacional são excluídos de ambas as estimativas de hardware.⁵

Como os modelos de decisão escolhem um banco de dados

Para o Jev e o Laya, a aplicação fornece o contexto, uma pergunta e opções nomeadas com descrições. Suas interfaces Choice retornam uma opção selecionada, probabilidades sobre as opções e uma pontuação de confiança. O código da aplicação decide o que fazer com esse resultado. Para o roteamento, as opções são aliases de banco de dados como db_03 e db_07.⁶⁵

Esse formato torna a saída fácil de usar no código. Um modelo ainda pode escolher o banco de dados errado. Uma pontuação de confiança alta também precisa de validação em relação à correção observada antes que uma aplicação a use para pular a revisão ou acionar um fallback.

O checkpoint em inglês do Laya usa um codificador ModernBERT bidirecional com uma cabeça de decisão que pontua as opções fornecidas. As descrições das opções chegam com a solicitação, portanto a aplicação pode alterar suas opções disponíveis. O Jev expõe uma API Choice hospedada. Sua documentação coloca o controle do fluxo de trabalho e as ações no código da aplicação. A interface compartilhada não estabelece que os dois modelos tenham a mesma arquitetura interna.⁵⁷

O Kev-9B usa um adaptador LoRA e uma cabeça de ponteiro sobre o Qwen3.5-9B-Base. Ele pontua as opções fornecidas e retorna suas probabilidades sem gerar texto de resposta. Usamos seu endpoint Choice compatível com a mesma pergunta e descrições de banco de dados.⁸

Condições que afetam a seleção de banco de dados

Bancos de dados semelhantes reduziram a precisão de roteamento em cerca de 20 pontos

Testamos o método de seleção de banco de dados em um experimento separado com 128 perguntas. Cada pergunta manteve seu banco de dados correto, enquanto os outros 10 candidatos vieram do nosso grupo selecionado ou de um sorteio aleatório.

No subconjunto difícil, o claude-opus-4.8 marcou 71,3% com candidatos semelhantes e 92,0% com candidatos aleatórios. O gemini-3.5-flash marcou 77,0% e 96,6%. Ambas as diferenças tiveram valores-p abaixo de 0.001 em testes pareados.

Esse experimento usou descrições e uma resposta do modelo por pergunta, sem o loop de ferramentas agêntico. Ele sustenta a descoberta mais restrita de que selecionar candidatos semelhantes torna a escolha do banco de dados mais difícil. A diferença medida não deve ser apresentada como o efeito da exploração agêntica.

Apenas os nomes produziram 68,8% e 71,1% de precisão em um piloto

Em outro piloto com 128 perguntas, o claude-opus-4.8 selecionou o banco de dados correto 68,8% das vezes apenas com nomes. Sua pontuação com nomes e descrições foi de 67,2%. O gemini-3.5-flash marcou 71,1% com nomes e 75,0% com o catálogo completo.

Nomes como california_schools e toxicology revelam o assunto diretamente. Para o benchmark principal, substituímos os nomes dos bancos de dados por aliases de db_01 a db_11. As descrições ainda explicam o domínio de cada banco de dados, e as respostas das ferramentas expõem seus nomes de tabelas e colunas.

Confiabilidade das comparações de roteamento e custo

Execuções repetidas alteraram a precisão de roteamento em 1.6 a 2.7 pontos

O claude-opus-5 selecionou o banco de dados correto para 156 de 184 perguntas difíceis em sua primeira execução e 151 na repetição. Sua precisão caiu de 84,8% para 82,1%. O qwen3.8-max passou de 153 respostas corretas para 150, uma queda de 83,2% para 81,5%.

Ambas as repetições usaram as mesmas perguntas, anonimização, temperatura e configurações de provedor das execuções originais. O qwen3.8-max mudou sua resposta em 13 perguntas difíceis, embora seu total tenha variado em três. Melhorias em algumas perguntas cancelaram erros em outras.

Essas repetições mostram que pequenas diferenças de pontuação podem desaparecer em outra execução. Uma repetição por modelo não pode estabelecer uma distribuição de resultados, e os outros 35 modelos não têm medição repetida.

Os custos registrados dependem do provedor e das configurações de cache

O cache de prompt reutiliza entradas processadas anteriormente para reduzir os custos faturados de entrada. A execução do claude-opus-5 custou US$ 62.78, em comparação com um valor estimado de US$ 105.54 nas tarifas de tabela sem cache para o mesmo uso registrado. Essa estimativa implica uma economia de 40,5%. É uma comparação contábil, sem uma execução separada de precisão sem cache.

RAG agêntico e seleção de banco de dados

O RAG agêntico dá ao modelo o controle sobre as decisões de recuperação. Ele pode escolher uma fonte, inspecionar a resposta e fazer outra solicitação. Um RAG pipeline simples recupera contexto por meio de uma sequência predeterminada antes de gerar uma resposta.

Este benchmark testa a seleção de fontes por meio de ferramentas de banco de dados SQL. Ele não contém índice de documentos, trechos recuperados ou pontuação de fundamentação de resposta. Portanto, os resultados descrevem uma parte de um sistema de recuperação agêntico. A busca de documentos é coberta separadamente em nosso benchmark de busca agêntica.

Um modelo começa com descrições curtas de banco de dados. Ele pode solicitar listas de tabelas, inspecionar colunas, executar SQL e mudar de banco de dados. Sua resposta final contém uma escolha de banco de dados e uma consulta. Nosso text-to-SQL benchmark relata a precisão de SQL e duas pontuações de revisão complementares.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Metodologia do benchmark de RAG agêntico

O conjunto de perguntas é um subconjunto congelado do BIRD-SQL, que emparelha perguntas em linguagem natural com consultas de referência em SQL.⁹

Dois sinais definem a dificuldade. O teste de similaridade conta quantos dos 20 vizinhos mais próximos de uma pergunta pertencem a outros bancos de dados. Três LLMs avaliam se a pergunta é confusa entre bancos de dados. A participação no grupo mais difícil exige pelo menos cinco vizinhos de bancos de dados diferentes e um rótulo de júri confuso.

O roteamento usa o banco de dados nomeado no campo explícito selected_database. Uma rota inferida de prosa é excluída do resultado principal. A correção de SQL é pontuada separadamente e não determina o crédito de roteamento.

O harness é o software que apresenta ferramentas e registra as respostas dos modelos. O painel principal contém 36 execuções do OpenRouter e uma execução do Codex CLI. Entre as execuções via API, 19 usaram a v3, 15 usaram uma versão anterior e duas combinaram registros de ambas as versões. Na v3, uma camada de recuperação analisa formatos alternativos suportados de chamada de ferramenta. Para o llama-4-maverick, a participação registrada de formato não nativo foi de 97,9%, portanto esse resultado depende muito do adaptador. O minimax-m2.7 foi excluído porque não fez as chamadas de ferramenta de banco de dados exigidas pela tarefa.

O GPT-6 Astra foi executado dentro do Codex CLI, cujo identificador de harness registrado é codex_cli_transcript_v1. Como a configuração é diferente, as diferenças de pontuação não podem ser atribuídas apenas ao modelo. O GPT-6 Astra concluiu todas as 759 perguntas. Ele selecionou o banco de dados correto em 155 de 184 perguntas difíceis e registrou 95,3% de precisão de roteamento em todo o conjunto. Sua execução não informou custos em dólares.

Benchmark de roteamento de modelos de decisão

O experimento de roteamento separado usou 243 perguntas inalteradas selecionadas de 394 candidatas após reservar 17 perguntas de desenvolvimento. O conjunto de consultas continha 204 perguntas originalmente fáceis e 39 originalmente difíceis. Esses rótulos de dificuldade não foram revalidados para esta tarefa, e a seleção não foi uma avaliação cega com dados separados.

Quatro descrições de banco de dados foram corrigidas usando esquemas de origem e texto da pergunta antes de coletar as previsões medidas. As outras sete mantiveram suas descrições compactas. Todos os modelos receberam a mesma pergunta, 11 aliases e descrições, e a mesma ordem de opções para aquela pergunta. O SQL de referência, os rótulos de origem e as evidências complementares foram omitidos. O Jev e o Laya usaram sua interface Choice nativa. Os LLMs foram instruídos a retornar um alias. Os modelos não tinham ferramentas de banco de dados.

Executamos o Jev 1.13.0 por meio de sua API hospedada e o checkpoint fixado do Laya English localmente com Apple M4 MPS, 16 GiB de memória e quatro threads Torch. O limite de 404 tokens do contexto do Laya e o limite de 48 tokens por opção não produziram truncamento de entrada. Seis LLMs foram executados pelo OpenRouter com provedores fixos e configurações de raciocínio. O raciocínio solicitado foi baixo para o Gemini 3.8 Flash, mínimo para o Gemini 3.5 Flash Lite e alto para o Opus. Foi desativado para o DeepSeek, o Qwen e o Haiku. Cada modelo teve um aquecimento excluído, uma solicitação em andamento e nenhuma repetição. A ordem de envio dos modelos foi rotacionada entre as perguntas.

O Kev-9B foi adicionado em 22 de setembro em uma execução separada, preservando os oito resultados originais. Seus payloads de 243 solicitações corresponderam exatamente às entradas originais do Jev, incluindo a ordem das opções. Fixamos a revisão do checkpoint 2629c06a e usamos um A100 SXM de 80 GB com FP32, atenção SDPA e LoRA não mesclado. O pré-processamento de datas e o cache de prefixo estavam desativados. Após verificar a API nas 17 perguntas de desenvolvimento reservadas, executamos um aquecimento excluído e 243 solicitações seriais sem repetições. O serviço foi reservado para nosso uso. Todas as respostas confirmaram que a entrada completa foi mantida. Os tempos do servidor incluem tokenização e inferência sincronizada. O gráfico usa os tempos do cliente, incluindo SSH e sobrecarga de rede.

A precisão divide as escolhas corretas e válidas por todas as 243 perguntas planejadas, incluindo falhas de serviço e de saída. A latência mediana mede a solicitação completa não transmitida do cliente entre as respostas válidas, excluindo o aquecimento. Os custos de LLM API relatados cobrem as solicitações medidas. Os custos de hardware do Laya e de aluguel do Kev não foram medidos, e a estimativa de preço de tabela do Jev é uma base contábil diferente. A comparação descreve este conjunto curado e essas condições de implantação. Dados de origem públicos, revisões de descrição, julgamento do revisor, datas de medição diferentes e a ausência de repetições limitam a generalização.

Limitações

O subconjunto difícil concentra-se em comércio. Quatro bancos de dados contribuem com 171 de suas 184 perguntas, ou 92,9%. Cinco dos 11 bancos de dados não contribuem com nenhuma. Isso sustenta conclusões sobre a escolha entre bancos de dados semelhantes dentro de um domínio, com evidências limitadas para outras combinações de domínios.

Sete execuções contêm menos de 759 registros pontuados após erros do provedor. Cinco também têm menos de 184 registros de perguntas difíceis. Os denominadores de suas tabelas mostram as perguntas que foram concluídas. Registros ausentes são excluídos, o que pode favorecer um modelo se as perguntas omitidas eram mais difíceis.

Os intervalos de Wilson cobrem a incerteza da amostragem sob um modelo de nível de pergunta. Eles omitem a variação entre execuções repetidas, a dependência entre perguntas do mesmo banco de dados e a incerteza introduzida pelo harness. Mudanças de provedor e recuperação de chamadas de ferramenta também limitam as comparações entre execuções.

Dados públicos de benchmark podem ter aparecido no treinamento dos modelos. Controles usando 138 paráfrases validadas e 65 perguntas recém-criadas não encontraram declínio de precisão nos modelos de menor custo testados. Sua cobertura foi limitada a seis e três bancos de dados, respectivamente. Eles não resolvem a contaminação para o painel completo, e nenhum controle usou bancos de dados lançados após o corte de treinamento dos modelos.

O truncamento de esquema pode ocultar tabelas úteis. Em works_cycles, o limite de 4.000 caracteres deixa 26 de 66 tabelas visíveis na listagem inicial do esquema. O modelo pode solicitar mais detalhes, mas a visão inicial está incompleta.

Leitura adicional

• Text-to-SQL: Comparação da precisão de LLM
• RAG Frameworks: LangChain vs LangGraph vs LlamaIndex
• Melhores RAG Tools, Frameworks, and Libraries
• Busca agêntica em 2026: Benchmark 8 APIs de busca para agentes

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark de RAG agêntico: roteamento entre 11 bancos de dados SQL}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Acessado em 25 setembro 2026}
}

Registro de alterações

16 atualizações

Todas16Geral13Metodologia3

202620252024

1. 11 ago

   A seção 'O que torna uma pergunta difícil neste benchmark?' foi atualizada com novo conteúdo.

2. 11 ago

   A metodologia foi atualizada para esclarecer como as perguntas mais difíceis são distribuídas entre os bancos de dados.

3. 7 ago

   A seção de metodologia de benchmark RAG Agentic foi substituída por uma nova que abrange 36 LLMs e 11 bancos de dados.

4. 29 jun

   Adicionados novos modelos ao benchmark: Claude Fable 5, Claude Opus 4.8, Gemini 3.5 Flash, Grok 4.3, Claude Opus 4.7.

5. 20 fev

   A seção de metodologia foi atualizada com novos detalhes sobre o ambiente do banco de dados, a arquitetura do agente e o processo de avaliação.

6. 23 jan

   Adicionada uma seção sobre modelos de contexto longo versus RAG agêntico.

7. 23 jan

   Métricas agenticas adicionais removidas da metodologia.

Links de referência

1.

Models - TypeSafe AI

Mintlify

2.

Apple Silicon Pricing | Scaleway

3.

Euro exchange rates charts

4.

Apple silicon M4 as-a-Service. Cloud Mac | Scaleway

5.

convaiinnovations/laya · Hugging Face

6.

Choice - TypeSafe AI

Mintlify

7.

How to build with TypeSafe - TypeSafe AI

Mintlify

8.

jaredpalmer/kev-9b · Hugging Face

9.

BIRD-bench

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário