IBM Research analisa onde agentes de IA falham com APIs, documentos e regras no VAKRA

A IBM Research publicou uma análise detalhada de por que até modelos de linguagem fortes ainda tropeçam em tarefas para sistemas agênticos. O novo estudo do benchmark VAKRA mostra que chamar uma única API com elegância não basta: os problemas começam quando é preciso percorrer várias etapas, escolher a fonte de dados certa e não violar as regras de uso das ferramentas.

Como funciona o VAKRA

O VAKRA é um benchmark executável para agentes corporativos. Em vez de chamadas de função de brinquedo, ele oferece aos modelos um ambiente de trabalho com mais de 8 mil APIs hospedadas 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 resposta, mas uma cadeia de 3–7 etapas: obter dados, escolher a ferramenta certa, extrair um fato de um documento, passar o resultado para a chamada seguinte e só então montar a resposta final.

A ideia central é que o VAKRA avalia não só a resposta final do modelo, mas toda a trajetória de ações. Nas tarefas complexas, o sistema primeiro verifica se o agente respeitou as restrições textuais de uso das ferramentas, depois reexecuta as chamadas no mesmo ambiente, compara os resultados intermediários com um gabarito e só então avalia a resposta final. Essa abordagem importa porque um agente pode acertar a conclusão por acaso, mas chegar a ela pelo caminho errado, o que em produção é quase inútil.

Quatro tipos de tarefas

Os autores dividem o VAKRA em quatro modos, e cada um testa uma camada distinta do comportamento agêntico. Juntos, cobrem desde o simples encadeamento de APIs até o raciocínio em várias etapas sobre APIs e documentos com restrições externas. Isso é relevante porque muitos agentes parecem seguros em chamadas isoladas, mas se perdem rápido quando precisam planejar etapas, alternar entre fontes, manter o contexto do diálogo e lembrar das regras de acesso às ferramentas ao mesmo tempo.

• Business Intelligence APIs: 2.077 tarefas em 54 domínios, em que o agente precisa chamar de 1 a 12 ferramentas em sequência e lidar com cuidado com parâmetros e filtragem de dados.
• Dashboard APIs: 1.597 tarefas em 17 domínios, em que a principal dificuldade é escolher o endpoint certo entre 6–328 ferramentas disponíveis.
• Multi-hop over APIs: 869 tarefas em 38 domínios, em que a resposta é montada por meio de vários saltos lógicos, de um a cinco.
• Multi-source + policies: 644 tarefas em 41 domínios, em que o agente alterna entre APIs e busca em documentos, considera o histórico do diálogo e cumpre regras textuais como "use apenas o retriever, não toque nas outras ferramentas".

Onde os agentes erram

A parte mais útil do artigo é a análise de onde exatamente os modelos falham. Os autores classificam os erros por estágio: escolha da ferramenta errada, omissão de argumentos necessários ou alucinações neles, valores de parâmetros incorretos e, por fim, resposta final errada mesmo depois de chamadas corretas.

No segmento de BI API, o melhor foi o GPT-OSS-120B: ele entendia visivelmente melhor os esquemas das ferramentas e errava menos nos nomes e no preenchimento de parâmetros. Mas mesmo ali, o sucesso em etapas isoladas não garantia um resultado end-to-end estável.

Nas tarefas com um grande conjunto de dashboard APIs, o Gemini-3-flash-preview se saiu melhor que os demais, o que faz sentido: ali o mais importante é a pré-seleção de ferramentas e a escolha precisa do endpoint.

À medida que a profundidade do raciocínio crescia, a qualidade caía em todos os modelos: perguntas de 2 saltos e, principalmente, de 3 ou mais saltos derrubavam bastante a precisão. Ficava ainda pior quando era preciso combinar APIs com recuperação de documentos. Os autores destacam uma falha reveladora: em parte das tarefas RAG de 1 salto, o GPT-OSS-120B às vezes não chamava o retriever e tentava responder "de memória", o que nesse benchmark conta como erro.

As políticas acrescentavam mais uma camada de dificuldade: os modelos ou violavam as restrições, ou as respeitavam, mas não reuniam a informação necessária para responder.

O que isso significa

O VAKRA mostra uma verdade desconfortável, mas útil, sobre sistemas agênticos: saber montar uma demo bonita com tool calling ainda não significa estar pronto para processos de negócio reais. Para equipes que escolhem um modelo para suporte, análise, compliance ou workflows internos, a pergunta principal agora não é "ele sabe chamar ferramentas?", mas "ele mantém uma cadeia de ações correta sob restrições, em várias fontes e sem atalhos presunçosos?"