Função nativa ainda vence agente de IA em velocidade e acerto, mostra estudo

Todo time que está montando um agente de IA em 2026 enfrenta a mesma pergunta antes de escrever a primeira linha: isso precisa mesmo passar por um modelo de linguagem, ou uma função simples resolve? Um estudo publicado em 5 de outubro de 2026 no arXiv, assinado por Ritvik Garimella, Biplav Srivastava e Amit Sheth, tentou responder isso com números em vez de opinião.

O artigo, aceito no AAAI Fall Symposium sobre sistemas agênticos confiáveis, parte de uma tarefa deliberadamente chata: resolver 1.000 expressões aritméticas preservando a precedência de operadores (aquela regra de multiplicar antes de somar). É o tipo de problema que qualquer linguagem de programação resolve de forma determinística, o que torna a tarefa perfeita para medir quanto custa resolver algo simples com uma arquitetura baseada em IA.

O que foi comparado

Os autores rodaram a mesma tarefa em sete arquiteturas diferentes. De um lado, as abordagens determinísticas: uma função nativa em Python (chamada de função direta, sem rede), um microsserviço REST, um microsserviço SOAP e um microsserviço exposto via Model Context Protocol (MCP), o padrão que permite a um modelo de linguagem chamar ferramentas externas como se fossem funções.

Do outro lado, as abordagens baseadas em modelo de linguagem: resposta direta de LLMs (um via API em nuvem da Groq e cinco modelos rodando localmente via Ollama) e sistemas agênticos, em que esses mesmos cinco modelos locais usam uma ferramenta MCP para fazer a conta em vez de calcular por conta própria.

Os números que separam cada arquitetura

O resultado é direto. As quatro abordagens determinísticas (função nativa, REST, SOAP e MCP como microsserviço simples) chegaram a 100% de acerto com latência desprezível, porque não envolvem nenhum modelo de linguagem no caminho crítico.

A resposta direta do LLM (sem nenhuma ferramenta, só o modelo tentando calcular por conta própria) errou cerca de 1 a cada 14 contas no melhor caso, e ainda assim levou mais de 22 mil vezes mais tempo que a função nativa. Isso confirma um ponto que já aparecia em benchmarks anteriores: LLM não é calculadora, porque ele prevê o próximo token, não executa aritmética.

O dado mais interessante para quem já construiu um agente é o do agente com ferramenta MCP. Ele recupera quase toda a acurácia (99,9%, porque delega a conta real para a ferramenta), mas isso tem um preço: quase um milhão de vezes a latência da função nativa. O ganho de acerto vem do raciocínio do modelo decidindo quando e como chamar a ferramenta, e é exatamente esse raciocínio extra que explode o tempo de resposta.

Por que a conta de latência vira conta de infraestrutura

Esse gap de latência não é só um número acadêmico. Em produção, cada chamada de agente que leva segundos em vez de microssegundos reduz quantas requisições por segundo um servidor aguenta, o que se traduz direto em mais máquinas, mais créditos de API e mais tempo de espera para quem está do outro lado esperando uma resposta. Um fluxo que troca uma função de dez linhas por um agente completo paga esse preço toda vez que é chamado, não só na primeira execução.

Os próprios autores resumem o dilema de forma direta no abstract do artigo:

Nunca foi tão fácil, nem tão caro, fazer menos com mais.

Never has it been easier, or costlier, to do less with more.Ritvik Garimella, Biplav Srivastava e Amit Sheth, autores do estudo

O framework que os pesquisadores propõem

A conclusão do paper não é "nunca use agente". É que a escolha de arquitetura deveria ser uma decisão de engenharia, não um reflexo automático de usar IA em tudo. Os autores propõem um framework de decisão arquitetural (ADF, na sigla em inglês) baseado em dois eixos: qual acurácia a tarefa exige e qual throughput (volume de chamadas por segundo) o sistema precisa sustentar.

Na prática, isso dá uma régua simples para quem está desenhando um agente agora:

• Se a tarefa tem resposta exata e verificável (cálculo, validação de regra de negócio, consulta a um banco de dados), a recomendação é resolver com código determinístico, seja função nativa, REST, SOAP ou MCP como simples transporte de dados, sem nenhum modelo de linguagem decidindo o resultado.
• Se a tarefa exige interpretar linguagem natural ambígua, decidir qual ferramenta chamar, ou lidar com instrução que muda a cada conversa, aí o custo extra de latência do agente se justifica, porque nenhuma função determinística resolve isso sozinha.
• Se o sistema precisa das duas coisas (entender o pedido em linguagem natural e depois executar um cálculo exato), o desenho que o próprio estudo testou já aponta o caminho: usar o LLM só para interpretar a intenção e delegar a execução para uma ferramenta determinística via MCP, não pedir que o modelo calcule por conta própria.

O que fica de fora do teste

Vale notar os limites do próprio experimento. A tarefa escolhida (aritmética com precedência de operadores) é propositalmente um caso em que a solução determinística é trivial de construir e medir, o que favorece a comparação, mas não cobre tarefas em que não existe uma função pronta para substituir o agente, como triagem de um ticket de suporte ou resumo de um documento.

Os próprios autores reconhecem isso no artigo, e dizem que uma interação real com agente normalmente mistura tarefa de raciocínio com tarefa de linguagem, então a recomendação final não é abandonar agente, e sim escolher por tipo de tarefa em vez de aplicar IA como solução única para tudo.

Para quem está decidindo arquitetura de um sistema agora, o estudo funciona como um checklist antes de colocar um LLM no caminho crítico de algo que uma função já resolveria com 100% de acerto e latência que nem aparece no gráfico. Os autores disponibilizaram o código do benchmark junto com o artigo, o que permite reproduzir a comparação com os próprios modelos e medir o gap de latência na infraestrutura de cada time, em vez de confiar só no número publicado.

Fonte: arXiv cs.AI