IBM Research analisou onde agentes de AI falham com APIs, documentos e regras no VAKRA

A IBM Research fez uma análise detalhada de por que até mesmo modelos de linguagem poderosos ainda falham em tarefas para sistemas de agentes. Uma nova análise do benchmark VAKRA mostra: fazer uma chamada de API elegante não é suficiente — os problemas começam quando você precisa passar por várias etapas, selecionar a fonte de dados certa e não violar as regras de uso de ferramentas.

Como o VAKRA é estruturado

VAKRA é um benchmark executável para agentes empresariais. Em vez de chamadas de função básicas, ele fornece aos modelos um ambiente de trabalho com mais de 8 mil APIs implantadas localmente, bancos de dados reais em 62 domínios e coleções de documentos para áreas temáticas específicas. Um cenário típico exige não uma única resposta, mas uma cadeia de 3–7 etapas: obter dados, selecionar a ferramenta certa, extrair um fato de um documento, passar o resultado para a próxima chamada e só então montar a resposta final.

A ideia-chave é que VAKRA avalia não apenas a resposta final do modelo, mas toda a sua trajetória de ações. Para tarefas complexas, o sistema primeiro verifica se o agente aderiu às restrições textuais no uso de ferramentas, depois reproduz suas chamadas no mesmo ambiente, compara resultados intermediários com o benchmark e só então avalia a resposta final. Essa abordagem é importante porque um agente pode adivinhar acidentalmente a conclusão final enquanto a alcança pelo caminho errado — e para produção, isso é quase inútil.

Quatro tipos de tarefas

Os autores dividem VAKRA em quatro modos, cada um testando uma camada separada do comportamento do agente. Juntos, eles cobrem o caminho desde encadeamento de API simples até raciocínio multi-etapa sobre APIs e documentos com restrições externas. Isso importa porque muitos agentes parecem confiantes em chamadas únicas, mas se perdem rapidamente quando precisam simultaneamente planejar etapas, alternar entre fontes, manter contexto de diálogo e lembrar regras de acesso a ferramentas.

• Business Intelligence APIs: 2.077 tarefas em 54 domínios, onde o agente precisa chamar sequencialmente 1–12 ferramentas e trabalhar cuidadosamente com parâmetros e filtragem de dados.
• Dashboard APIs: 1.597 tarefas em 17 domínios, onde a principal complexidade é selecionar o endpoint certo entre 6–328 ferramentas disponíveis.
• Multi-hop over APIs: 869 tarefas em 38 domínios, onde a resposta é montada através de várias transições lógicas, de uma a cinco.
• Multi-source + policies: 644 tarefas em 41 domínios, onde o agente alterna entre APIs e busca de documentos, leva em conta o histórico de diálogo e segue regras textuais como "use apenas retriever, não toque em outras ferramentas."

Onde os agentes falham

A parte mais útil do artigo é a análise de onde os modelos falham. Os autores dividem erros por estágio: escolher a ferramenta errada, pular argumentos necessários ou alucinar sobre eles, valores de parâmetros incorretos e, finalmente, uma resposta final incorreta mesmo após chamadas corretas. No segmento de API de BI, GPT-OSS-120B teve o melhor desempenho: entendeu notavelmente melhor os esquemas de ferramentas e cometeu menos erros em nomes e preenchimento de parâmetros.

Mas mesmo aí, o sucesso em etapas individuais não garantiu resultados estáveis de ponta a ponta. Em tarefas com um grande conjunto de APIs de dashboard, Gemini-3-flash-preview teve o melhor desempenho, o que faz sentido: lá a capacidade de fazer uma lista abreviada de ferramentas e selecionar precisamente um endpoint é mais importante. À medida que a profundidade do raciocínio crescia, a qualidade caia para todos os modelos: questões 2-hop e especialmente 3+ hop mostravam precisão notavelmente mais baixa.

Ficava ainda pior quando APIs tinham que ser combinadas com recuperação de documentos. Os autores apontam especificamente uma falha reveladora: em algumas tarefas RAG de 1-hop, GPT-OSS-120B às vezes nem chamava o retriever e tentava responder "de memória", o que em tal benchmark conta como erro. As políticas adicionavam outra camada de complexidade: os modelos violavam restrições ou as seguiam, mas falhavam em coletar as informações necessárias para a resposta.

O que isso significa

VAKRA mostra uma verdade desagradável mas útil sobre sistemas de agentes: a capacidade de fazer um demo elegante com tool calling não significa prontidão para processos de negócios reais. Para equipes que escolhem um modelo para suporte, análise, conformidade ou workflows internos, a pergunta principal agora não é "ele consegue chamar ferramentas", mas "ele mantém uma sequência correta de ações sob restrições, entre múltiplas fontes e sem atalhos excessivamente confiantes."