NVIDIA leva a avaliação de agentes de IA além da precisão de chamadas de ferramentas

A NVIDIA está defendendo uma forma mais ampla de avaliar agentes de IA: medir se eles concluem tarefas de várias etapas em um ambiente executável, em vez de julgar chamadas de ferramentas isoladas ou a qualidade de uma resposta final.

Em um post técnico de blog, a NVIDIA argumenta que os agentes devem ser testados em sistemas vivos e com estado, nos quais selecionam ferramentas, fornecem argumentos, lidam com erros e deixam o ambiente no estado final pretendido. Essa abordagem importa à medida que os produtos de IA deixam de apenas responder perguntas e passam a alterar registros, encaminhar tickets, emitir reembolsos e executar outros fluxos de trabalho em nome do usuário.

O post é principalmente uma proposta de metodologia e um guia técnico, não um estudo independente do setor. Seu exemplo de desempenho — o Nemotron 3.5 Lightning alcançando 86% de precisão no PinchBench enquanto conclui tarefas 30% mais rápido que modelos comparáveis — é uma afirmação reportada pela NVIDIA e deve ser lida como tal.

Por que benchmarks de uma única chamada ficam aquém

Sistemas de avaliação anteriores muitas vezes tratavam a decisão de um modelo de chamar uma função, sua seleção de ferramenta e a formatação de seus argumentos como o principal teste de competência. A NVIDIA cita o Berkeley Function-Calling Leaderboard, ou BFCL, como um exemplo importante desse modelo. Esses testes podem estabelecer se um agente sabe como formar uma chamada de função válida em cenários de uma e várias interações.

Mas uma chamada válida não prova que o trabalho subjacente foi concluído. Um agente pode emitir uma solicitação issue_refund aparentemente correta e ainda assim deixar de realizar uma verificação de elegibilidade necessária, atualizar um registro de cliente de forma incorreta ou confirmar que o reembolso foi de fato registrado. Em um sistema de produção, essas omissões podem importar mais do que saber se os argumentos JSON originais estavam sintaticamente corretos.

O argumento central da NVIDIA é que chamar ferramentas é apenas o tecido conectivo do trabalho de um agente. A unidade significativa de avaliação é a tarefa executada por meio de uma cadeia de chamadas contra um ambiente cujo estado pode ser inspecionado depois.

Duas visões do mesmo rastro de execução

O framework proposto avalia um rastro de execução ordenado contendo a solicitação do usuário, as ações intermediárias do agente, os resultados das ferramentas e o estado em que a execução termina. A NVIDIA separa a pontuação em duas camadas.

A pontuação em nível de passo, ou de processo, pergunta se cada ação foi válida, relevante e útil dado o estado naquele momento. Ela pode revelar onde uma cadeia falhou, como uma escolha incorreta de ferramenta, argumento malformado, chamada desnecessária ou resposta ruim a um erro. Essas informações são úteis para depuração, seleção de dados e ajuste fino.

A pontuação de ponta a ponta verifica o resultado em vez do caminho. Ela pergunta se o estado final do ambiente corresponde ao objetivo — por exemplo, se um reembolso foi registrado ou se um ticket de suporte foi encaminhado corretamente. A NVIDIA diz que essa é a medida mais próxima da experiência do usuário e a mais adequada como critério de liberação para produção, enquanto os rastros em nível de passo continuam importantes para diagnóstico.

A distinção também evita que equipes otimizem para um comportamento apenas plausível. Um agente pode produzir uma sequência limpa de mensagens intermediárias e ainda assim falhar em mudar o sistema que deveria operar.

As métricas precisam de uma estrutura comum de relatório

A NVIDIA organiza a avaliação em uma hierarquia de benchmark, trial, task, turn e step. Um benchmark contém a avaliação geral; um trial é uma execução independente sob uma configuração fixa; uma task é uma instância de problema pontuável; um turn representa um limite de troca; e um step é uma ação atômica, como uma invocação de ferramenta, um plano ou uma resposta final.

O post agrupa as medições mais úteis em três eixos: precisão, verbosidade e custo. Precisão pode incluir sucesso da tarefa e qualidade do processo. Verbosidade captura quanta atividade um agente exige, enquanto custo reflete fatores como tempo de execução e uso de ferramentas. Relatar apenas uma única porcentagem de sucesso pode, portanto, ocultar compensações importantes.

A NVIDIA também recomenda relatórios pareados, como uma taxa de sucesso com faixas de consistência, em vez de apresentar um único número sem contexto. As comparações podem ser distorcidas pela complexidade da tarefa, pela quantidade de estado mantida por um ambiente e pela forma como o sucesso é verificado.

O método de verificação mais forte no post é uma checagem executável do ambiente resultante. Avaliação baseada em referência e juízes baseados em grandes modelos de linguagem podem ser úteis em alguns cenários, mas a NVIDIA os apresenta como menos robustos do que verificar diretamente se o estado desejado foi alcançado. Essa preferência é especialmente relevante para fluxos de trabalho empresariais, nos quais o status de um ticket, um registro de banco de dados ou o estado de uma transação muitas vezes pode ser inspecionado de forma determinística.

O que a afirmação do benchmark mostra — e o que não mostra

A NVIDIA usa o Nemotron 3.5 Lightning para ilustrar o framework, relatando 86% de precisão no PinchBench e um tempo de conclusão 30% mais rápido que modelos comparáveis. O post, porém, não fornece, nas evidências apresentadas, detalhes suficientes para avaliar de forma independente o grupo de comparação, a configuração do teste, a distribuição da carga de trabalho ou a significância estatística.

Esses números, portanto, funcionam como um exemplo de como a NVIDIA quer que o desempenho de agentes seja discutido, e não como um ranking neutro do setor. Desenvolvedores que considerem o modelo precisariam revisar a documentação de reprodutibilidade e reproduzir a configuração publicada do benchmark antes de tirar conclusões de implantação. A NVIDIA também direciona os leitores para seu guia NIM de implantação em produção, reforçando que o post conecta metodologia de avaliação com sua própria pilha de serving de modelos.

Para compradores, a lição mais ampla é que rótulos de benchmark sozinhos não são suficientes. Um resultado em um benchmark público pode não prever o desempenho nas APIs, permissões, qualidade de dados, modos de falha ou exigências de aprovação de uma organização.

Implicações para builders e equipes corporativas

O framework oferece às equipes de produto uma razão prática para construir avaliações em torno de tickets de trabalho e APIs reais. Em vez de perguntar se um agente consegue chamar uma função de CRM, uma equipe poderia testar se ele consegue interpretar uma solicitação do cliente, recuperar a conta certa, aplicar a política, atualizar o registro e produzir um estado final auditável.

Essa abordagem também muda a gestão de releases. As equipes podem usar o sucesso de ponta a ponta como uma porta de implantação e, em seguida, inspecionar os rastros em nível de passo para determinar se as falhas vêm de planejamento, seleção de ferramentas, argumentos, recuperação de erros ou acesso ao ambiente. Isso apoia correções direcionadas sem confundir fluência intermediária com trabalho concluído.

Custo e confiabilidade passam a fazer parte da mesma decisão. Um agente que tem sucesso, mas faz chamadas em excesso, pode ser caro ou lento demais para um fluxo de alto volume. Por outro lado, um agente que é rápido, mas altera o estado correto de forma inconsistente, pode criar risco operacional. As avaliações devem expor ambas as dimensões sob permissões e transições de estado realistas.

Para os fornecedores de modelos, a mudança eleva a barra do design de benchmarks. A precisão em chamadas de ferramentas continua útil, mas comparações críveis exigem cada vez mais ambientes executáveis, definições de tarefas transparentes, configurações reproduzíveis e verificações que distingam um fluxo de trabalho concluído de uma transcrição convincente.

O que observar a seguir

O próximo sinal será ver se equipes independentes adotam avaliações executáveis e baseadas em estado para seus próprios sistemas de agentes, em vez de depender principalmente de pontuações em nível de chamada ou de julgamentos baseados em LLM. Detalhes de reprodutibilidade para o PinchBench e outros benchmarks também serão importantes, especialmente a mistura de tarefas, a configuração do ambiente e a definição de sucesso.

Desenvolvedores devem acompanhar avaliações que relatem sucesso junto com latência, volume de chamadas de ferramentas, consistência e custo. Compradores corporativos devem procurar testes específicos de domínio construídos a partir de tickets e APIs reais, com rastros de falha que possam ser auditados. Já os provedores de modelos enfrentarão pressão para publicar detalhes de configuração suficientes para que as alegações de benchmark possam ser reproduzidas fora de sua própria infraestrutura.

Perspectiva da Creati.ai

A contribuição mais útil da NVIDIA aqui não é a pontuação de destaque associada ao Nemotron 3.5 Lightning, mas a insistência de que a avaliação de agentes deve acompanhar o trabalho até suas consequências. Para os builders, o estado final de um sistema costuma ser mais importante do que uma cadeia elegante de saídas do modelo.

O framework não substitui testes cuidadosos de domínio, e as alegações de desempenho da NVIDIA continuam sendo reportadas pelo fornecedor. Mas a distinção entre diagnóstico de processo e conclusão ponta a ponta oferece uma base prática para equipes que decidem se um agente de IA está pronto para operar em sistemas reais, em vez de apenas demonstrar uso competente de ferramentas.