🤖 AI

PluginEval: A Diagnostic Benchmark for Fine-Grained Error Attribution in Function Calling

Este artigo introduz o PluginEval, um benchmark de diagnóstico que utiliza uma estrutura de dois estágios combinando geração por LLM com execução de API determinística para abordar sistematicamente lacunas na distribuição de dados e a falta de testes adversários, permitindo, assim, a atribuição de erros detalhada para avaliar o roteamento de ferramentas em modelos de linguagem de grande escala.

Autores originais: Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

Publicado 2026-08-11

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está ensinando um mordomo robô muito inteligente e muito ávido a usar uma caixa de ferramentas gigante repleta de milhares de diferentes dispositivos. Você diz ao robô, "Estou com fome", e ele tem que decidir três coisas: primeiro, se ele realmente precisa usar uma ferramenta ou se pode apenas pensar em um lanche? Segundo, se ele precisa de uma ferramenta, qual dispositivo específico é o correto (um liquidificador, não um martelo)? E terceiro, se ele consegue realmente pegar esse dispositivo e usá-lo corretamente sem quebrá-lo? Este é o mundo da "chamada de função" (function calling) na Inteligência Artificial. É a habilidade que permite que os modelos de IA parem de apenas conversar e comecem a realmente fazer coisas, como reservar voos ou verificar a previsão do tempo. Mas aqui está a parte complicada: só porque um robô diz as palavras certas não significa que ele escolheu a ferramenta certa ou a usou corretamente. Precisamos de uma maneira de testar se o robô é verdadeiramente inteligente ou se é apenas sortudo.

É exatamente isso que os pesquisadores por trás deste artigo, o PluginEval, estão tentando consertar. Eles notaram que a maioria dos testes atuais para esses robôs de IA são como um teste de direção onde todos recebem um estacionamento vazio e fácil. Os testes não têm situações suficientemente complicadas, não detectam as formas específicas pelas quais os robôs falham e muitas vezes dependem de outros robôs para dar as notas, o que pode ser tendencioso. Assim, a equipe construiu um novo "teste de direção" muito mais rigoroso, especificamente para consultas em língua chinesa. Eles criaram um sistema que não olha apenas para a pontuação final, mas atua como um detetive, descobrindo exatamente por que um robô falhou: ele esqueceu de trazer uma ferramenta, pegou a ferramenta errada ou tentou usar a ferramenta certa, mas derramou os ingredientes?

O Kit de Ferramentas do Detetive: Como Eles Construíram o Teste

Para construir este novo benchmark, os autores não apenas escreveram um monte de perguntas e esperaram pelo melhor. Eles inventaram uma "Estrutura de Construção de Ciclo Fechado" (PCCF), que é uma forma elegante de dizer que construíram uma máquina autocorretiva para criar o teste.

Pense nisso como um designer de níveis de videogame que continua jogando o mesmo nível até que ele esteja perfeito.

Estágio Um (O Choque de Realidade): Primeiro, eles pegam uma pergunta (como "Encontre um voo barato para Tóquio") e pedem a vários modelos de IA para tentar resolvê-la. Mas aqui está a reviravolta: eles não confiam apenas na palavra da IA. Eles realmente executam o código. Se a IA disser "Vou chamar a API de voos", o sistema tenta fazer essa chamada. Se a API disser "Erro: Data ausente", o sistema sabe que a IA falhou. Isso separa a "ideia" da "realidade".
Estágio Dois (O Preenchimento de Lacunas): O sistema então analisa os resultados e pergunta: "Onde nos faltam perguntas complicadas?". Talvez o teste tenha muitas perguntas fáceis sobre o clima e não perguntas difíceis o suficiente sobre a reserva de viagens complexas. O sistema então gera novas perguntas, mais difíceis, especificamente para preencher esses buracos. Ele cria perguntas "adversariais" — armadilhas projetadas para enganar a IA e fazê-la cometer erros.
O Ciclo: Essas novas perguntas complicadas voltam para o Estágio Um para serem testadas novamente. Se forem fáceis demais, o sistema as torna mais difíceis. Se forem confusas demais, o sistema usa evidências de reconhecimento para fortalecer os exemplos negativos antes de verificá-los novamente. Este ciclo continua girando até que o teste cubra todas as maneiras possíveis pelas quais uma IA poderia ficar confusa, desde erros simples até armadilhas de lógica complexas.

O Veredito: O Que o Teste Revelou

Uma vez que tiveram seu teste perfeito (que incluiu 3.000 perguntas verificadas por humanos em 54 ferramentas diferentes), eles colocaram cinco dos modelos de IA mais inteligentes do mundo à prova. Isso incluía grandes nomes como GPT-5.4, Claude 4.6 e Gemini 3.1 Pro.

Os resultados foram reveladores. Os autores descobriram que as pontuações agregadas (a nota final) são enganosas.

A Armadilha da Dificuldade: Quando o teste consistia principalmente de perguntas fáceis, todas as IAs pareciam gênios, pontuando acima de 80%. Mas assim que atingiam as perguntas "Difíceis", as pontuações despencavam. Para as perguntas mais difíceis, até a melhor IA acertava apenas cerca de 10%. Isso sugere que os modelos atuais são muito frágeis; eles funcionam muito bem em tarefas simples, mas desmoronam quando as coisas ficam complicadas.
Falhas Diferentes para Modelos Diferentes: O artigo não disse apenas "O Modelo A é melhor". Ele detalhou os erros como um mecânico verificando o motor de um carro.
- O GPT-5.4 foi o pior tanto em identificar ferramentas necessárias quanto em evitar chamadas desnecessárias, exibindo as maiores taxas de ambos os "erros de omissão" (esquecer de usar uma ferramenta necessária) e "erros de excesso" (usar uma ferramenta quando não deveria).
- O Claude Opus 4.6 foi o melhor em lembrar de usar ferramentas (menor "erro de omissão"), mas às vezes as usava quando não deveria (alto "erro de excesso").
- O Gemini 3.1 Pro teve o perfil de erro mais equilibrado, alcançando a menor taxa de "erro de excesso", o que o ajudou a manter uma precisão competitiva, apesar de ter uma taxa de lembrança menor que o Claude.
O Problema do "Tempo": Um tipo específico de erro se destacou para todos os modelos: Erros Temporais. Quer fosse perguntando sobre "próxima terça-feira" ou "mês passado", as IAs consistentemente tiveram dificuldade em acertar as datas e os horários. Este foi o maior motivo de falha em todos os casos.

Por Que Isso Importa

O artigo argumenta que não podemos apenas olhar para uma única porcentagem para julgar a capacidade de uma IA de usar ferramentas. Um modelo pode ter uma pontuação alta porque é bom em perguntas fáceis ou porque teve sorte. Ao usar seu novo sistema de julgamento "Ancorado em Ouro" — que compara a resposta da IA contra um "padrão ouro" verificado por humanos, em vez de apenas o palpite de outra IA — eles puderam identificar exatamente onde o robô falhou.

Os autores sugerem que, para criar agentes de IA verdadeiramente confiáveis, precisamos parar de tratá-los como caixas pretas que funcionam ou não. Em vez disso, precisamos diagnosticá-los como um médico: verificando se eles perderam um passo, se pegaram a ferramenta errada ou se apenas erraram o tempo. O trabalho deles mostra que, embora a IA de hoje seja poderosa, ela ainda possui pontos cegos significativos, especialmente quando a tarefa fica difícil ou quando o tempo é complicado. O artigo não afirma ter "resolvido" o uso de ferramentas pela IA, mas fornece o primeiro mapa real de onde os robôs estão tropeçando, para que possamos ajudá-los a aprender a caminhar com mais firmeza.

Resumo Técnico: PluginEval

Declaração do Problema

À medida que os Grandes Modelos de Linguagem (LLMs) funcionam cada vez mais como agentes autônomos, a avaliação confiável do roteamento de ferramentas (chamada de função) torna-se crítica. Os benchmarks atuais sofem de três limitações estruturais:

Viés de Distribuição de Dados: Distribuições de lei de potência deixam cenários raros e casos de borda sub-representados.
Falta de Rigor Adversário: A ausência de negativos difíceis obscurece as diferenças de desempenho entre os modelos.
Pipelines de Anotação Não Validados: Muitos benchmarks dependem de julgamentos de LLMs para anotação que não foram validados através de execução real, levando a potenciais erros semânticos, apesar da correção estrutural.

Além disso, os benchmarks existentes frequentemente focam em taxas de sucesso agregadas ou sintaxe de chamada, falhando em diagnosticar modos de falha específicos, como chamadas de ferramentas perdidas, chamadas espúrias ou erros de fundamentação de parâmetros. Há uma necessidade específica de um benchmark que combine anotação confiável, baseada em execução, com cobertura estruturada de fronteiras de gatilho e exclusão, particularmente para consultas em chinês, que costumam ser ambíguas ou dependentes de contexto.

Metodologia: O Framework de Construção de Ciclo Fechado PluginEval (PCCF)

O artigo apresenta o PluginEval, um benchmark construído via um framework de ciclo fechado de dois estágios (PCCF) projetado para separar a confiabilidade da anotação dos requisitos de cobertura.

Formulação da Tarefa

O roteamento de ferramentas é formulado como uma hierarquia de três decisões:

Necessidade ( $f_1$ ): Uma ferramenta é necessária?
Relevância ( $f_2$ ): O plugin alvo é relevante?
Invocação ( $f_3$ ): A requisição pode ser fundamentada em uma invocação válida com argumentos corretos, ou deve ser rejeitada?

Estágio I: Anotação de Conjunto Baseada em Execução

Este estágio foca em estabelecer anotações confiáveis tanto para consultas reais quanto sintéticas.

Geração: Múltiplos geradores propõem independentemente invocações completas.
Verificação: As propostas passam por um processo de verificação de múltiplas etapas:
- Validação Determinística de Esquema: Verifica a validade estrutural.
- Avaliação de Argumentos: Um avaliador LLM verifica se os argumentos são suportados pela consulta e consistentes com a semântica do plugin.
- Execução: As propostas são executadas via MCP (Model Context Protocol).
- Avaliação de Resultado: Um avaliador separado verifica se a resposta da execução satisfaz a requisição do usuário.
Loop de Refinamento: Propostas que falham na verificação (devido a violações de esquema, erros de execução ou incompatibilidades semânticas) são retidas como rastros (traces). Esses rastros, juntamente com pontuações de avaliadores independentes, são retroalimentados aos geradores para refinamento. Este processo se repete por um máximo de $R_{max}$ rodadas até que uma proposta atinja um limiar de confiança $\tau$ ou seja rejeitada como uma abstenção justificada.

Estágio II: Síntese Baseada em Cenários e Calibração de Comportamento

Este estágio aborda lacunas de cobertura e calibração de dificuldade.

Decomposição de Cenários: Os plugins são decompostos em cenários de gatilho (requisições suportadas) e cenários de exclusão (requisições que exigem nenhuma ferramenta, outras ferramentas ou excedem as capacidades).
Síntese Direcionada: O sistema identifica unidades sub-cobertas (combinações de capacidade, intenção e fronteira) e sintetiza novas consultas para preencher essas lacunas.
Calibração de Dificuldade:
- Exemplos Positivos: A dificuldade é baseada na profundidade de inferência (0, 1 ou $\ge$ 2 passos).
- Exemplos Negativos: A dificuldade é calibrada com base em evidência comportamental. Um roteador de referência congelado avalia o negativo sintetizado $K$ vezes. Se o roteador falha consistentemente em rejeitar o negativo (alta taxa de falso positivo), o exemplo é considerado "Difícil". Se é facilmente rejeitado, é "Fácil".
Ciclo Fechado: Exemplos sintetizados são retornados ao Estágio I para verificação. O loop continua até que os orçamentos de cobertura sejam atendidos ou ocorra um platô de melhoria.

Framework de Avaliação: Juiz Ancorado em Ouro (Gold-Anchored Judge)

Para ir além da precisão agregada, o artigo emprega um Juiz LLM Ancorado em Ouro:

Entrada: Chamadas previstas, chamadas de ouro verificadas por humanos e a consulta do usuário.
Restrição: O juiz trata a lista de chamadas de ouro como a única âncora. Ele não pode estender ou sobrepor as especificações de ouro.
Verificação Hierárquica:
1. Alinhamento de Ferramenta: Corresponde aos nomes das ferramentas entre a previsão e o ouro.
2. Filtragem de Argumentos: Garante conjuntos de argumentos não vazios e comparáveis.
3. Verificação Semântica: Determina se os argumentos previstos são semanticamente equivalentes aos argumentos de ouro sob a intenção da consulta (permitindo aliases e variações de formatação, mas avaliando estritamente escopos temporais).
Atribuição de Erro: As falhas são classificadas em categorias mutuamente exclusivas:
- Miss Recall (Esquecimento): Falta de ferramentas necessárias.
- Erro de Parâmetro: Argumentos semanticamente incorretos (subclassificados em erros temporais, argumentos ausentes, valores incorretos).
- Over Recall (Excesso de Chamada): Ativação espúria de ferramenta em consultas negativas.

Principais Contribuições

Benchmark PluginEval: Um benchmark de chamada de função em chinês com 3.000 instâncias verificadas por humanos, cobrindo 54 plugins, 63 ferramentas e 9 domínios. Apresenta cenários de gatilho/exclusão explícitos, três tipos de negativos de fronteira e dificuldade calibrada pelo comportamento.
Framework PCCF: Um método de construção de ciclo fechado que desacopla a confiabilidade da anotação (via verificação baseada em execução) dos requisitos de cobertura (via síntese de cenários). Utiliza validação de esquema, avaliação independente e execução de ferramentas para reparar anotações.
Atribuição de Erro Granular: Um framework de avaliação que atribui falhas a causas específicas (miss recall, erros de parâmetro, over recall) em vez de depender de métricas de sucesso agregadas.
Análise Empírica: Avaliação de cinco LLMs de fronteira (incluindo modelos proprietários e de pesos abertos) revelando que as pontuações agregadas são altamente sensíveis à composição de dificuldade e que os modelos exibem perfis de falha distintos.

Resultados

O artigo avalia cinco modelos: GPT-5.4, Claude 4.6, Gemini 3.1 Pro, DeepSeek-V4-Pro e Qwen3-235B-A22B.

Sensibilidade de Desempenho: O desempenho agregado é altamente dependente da distribuição de dificuldade. Na distribuição original (40% Fácil, 40% Médio, 20% Difícil), o Claude Opus 4.6 alcançou o melhor desempenho (67,60% de Recall, 68,17% de Acurácia). No entanto, o desempenho cai significamente em instâncias Difíceis (o Recall cai para 2,8%–10,8% entre os modelos).
Impacto da Dificuldade: Mudar a distribuição para ser ponderada por Fáceis (60% Fácil) melhorou substancialmente todos os modelos (o Recall aumentou em ~15–21 pontos), demonstrando que os benchmarks atuais podem superestimar as capacidades se não forem rigorosamente calibrados.
Comparação com Benchmarks Existentes: Os modelos geralmente performaram pior no PluginEval do que no BFCL, APIBench ou NexusRaven. Por exemplo, o Recall do Claude Opus 4.6 caiu de 73,04% no BFCL para 67,60% no PluginEval. Isso sugere que o PluginEval captura cenários mais desafiadores, realistas e adversários.
Perfis de Erro:
- GPT-5.4: Exibiu o maior Miss Recall (33,72%) e o maior Over Recall (33,20%), indicando dificuldade substancial tanto em identificar ferramentas necessárias quanto em evitar chamadas desnecessárias.
- Claude Opus 4.6: Teve o menor Miss Recall (13,95%), mas um alto índice de Over Recall (29,10%), que permanece superior ao do Gemini, mas inferior ao do GPT-5.4.
- Gemini 3.1 Pro: Alcançou o menor Over Recall (18,55%), contribuindo para uma acurácia competitiva, apesar do recall menor.
- Erros Temporais: Em todos os modelos, erros de fundamentação temporal foram o subtipo de erro de parâmetro mais frequente, indicando uma fraqueza compartilhada no tratamento de restrições de tempo.
Confiabilidade: Auditorias humanas confirmaram alta concordância (Fleiss' $\kappa$ até 0,9451) nas anotações de referência e nas atribuições do juiz, validando a confiabilidade do benchmark.

Significância e Alegações

O artigo alega que o PluginEval aborda a lacuna crítica na avaliação diagnóstica para roteamento de ferramentas. Ao ir além das taxas de sucesso agregadas, ele revela que:

Pontuações agregadas obscurecem modos de falha distintos: Modelos com pontuações gerais semelhantes podem falhar por razões inteiramente diferentes (ex: seleção de ferramenta vs. fundamentação de parâmetros).
A composição de dificuldade importa: Rankings de desempenho podem mudar com base na proporção de exemplos fáceis e difíceis, necessitando de rótulos de dificuldade calibrados derivados do comportamento do modelo.
A execução é essencial para a confiança: Validar anotações através da execução real de APIs e verificações de esquema é necessário para garantir a correção semântica, não apenas a validade sintática.

Os autores concluem que a atribuição de erro estruturada é necessária para guiar o desenvolvimento de sistemas de agentes mais robustos, e que seu framework de ciclo fechado fornece um método reproduzível para construir tais benchmarks diagnósticos.