NVIDIA publica guia para avaliar agentes de IA de ponta a ponta

Por que avaliar um LLM não basta para avaliar um agente

Em um artigo técnico, engenheiros da NVIDIA argumentam que benchmarks tradicionais de LLM foram desenhados para tarefas estáticas, com uma única saída a ser pontuada. Agentes quebram essa premissa: executam tarefas em múltiplas etapas, chamam ferramentas, lidam com erros e observam resultados, o que torna insuficiente avaliar uma string de saída. O Berkeley Function-Calling Leaderboard (BFCL) avançou ao medir a seleção de funções e a precisão dos argumentos, mas só avalia chamadas isoladas - uma chamada válida de reembolso ainda falha se etapas intermediárias forem puladas.

Da chamada ao ambiente

A avaliação agêntica madura exige um ambiente de execução completo, que execute cada chamada, acompanhe o estado entre etapas e leia o estado final para decidir se o trabalho foi feito. Sobre isso operam duas camadas de pontuação: a por etapa (process scoring), que indica onde a cadeia quebra e serve para depuração, e a de ponta a ponta (outcome scoring), que verifica apenas o estado final - como o reembolso efetuado ou o tíquete roteado. Ambas leem o mesmo objeto, o trace: o registro ordenado de uma tentativa.

O que uma rodada de benchmark mede

Um benchmark de chamada de ferramentas pontua três coisas: decidir usar uma ferramenta, selecionar a correta e preencher os argumentos. Os resultados se organizam numa hierarquia fixa: benchmark → trial → task → turn → step. As métricas se agrupam em três eixos - acurácia, verbosidade e custo - com pareamento obrigatório: taxa de sucesso sem faixa de consistência é uma estimativa pontual sobre um sistema estocástico (um modelo que alterna 90% e 74% é pior aposta que um que mantém 84%); precisão de chamadas sem acurácia de argumentos esconde falhas de preenchimento. Chamadas paralelas reduzem etapas e latência, mas não o número de chamadas.

Como comparar benchmarks

Três dimensões explicam a falta de comparabilidade entre benchmarks: complexidade das tarefas, presença de estado no ambiente e metodologia de verificação - verificações executáveis (o banco atualizou? os testes passaram?) são o padrão-ouro; LLM-as-a-judge deve ser tratado como provisório até validado contra avaliação humana. A contaminação hoje vai além de vazamentos de treino: agentes com busca na web podem recuperar gabaritos durante a avaliação, e conjuntos públicos são rapidamente reaproveitados em corpora de pré-treino.

Convergência para uso de ferramentas

Os autores observam que a fronteira entre "chamar ferramenta" e "completar tarefa" desapareceu: benchmarks de capacidade geral agora também medem uso de ferramentas, porque nenhum modelo é implantado sem elas. SWE-bench é o exemplo - resolver uma issue real envolve navegar o código, editar e passar testes, com a trajetória inteira composta de chamadas. Benchmarks acadêmicos medem o teto de capacidade; os corporativos respondem a pergunta mais útil: o modelo executa meus problemas, contra minhas APIs e políticas?

Nemotron 3.5 Lightning e recomendações

O artigo lê os resultados do Nemotron 3.5 Lightning como conclusão de tarefas, não acurácia isolada: 86% no PinchBench completando 10.000 tarefas 30% mais rápido que o Qwen3.6 35B em acurácia comparável. A recomendação para empresas: estabelecer um piso público com suítes agênticas publicadas, construir avaliações de domínio a partir de tíquetes e APIs reais, validar pelo estado do ambiente (linha no banco, PR mesclado, tíquete fechado), re-medir consistência, etapas e custo por sucesso e manter traces por etapa para depuração. Publicar pontuações públicas é sinal, não porta de liberação.