Por que benchmarks tradicionais não bastam mais
Quando você coloca um agente de IA em produção, a pergunta central é se ele consegue executar uma cadeia de trabalho com dezenas de chamadas de ferramenta em sequência contra um ambiente real — e se recuperar quando uma etapa falha. Avaliar se o modelo “soa correto” diz muito pouco sobre se o trabalho de fato terminou.
Os harnesses de avaliação originais foram construídos para tarefas estáticas, com uma única resposta. Os agentes quebraram essa premissa: ao operar em tarefas de múltiplas etapas, um agente chama ferramentas, lida com erros e observa resultados ao longo do caminho. O Berkeley Function-Calling Leaderboard (BFCL) surgiu para avaliar seleção de função e precisão de argumentos, mas ele só olha chamadas individuais — uma chamada issue_refund válida ainda falha se as verificações subjacentes foram puladas. Precisão de chamada é necessária, mas não suficiente.
De pontuar chamadas a pontuar o ambiente
A avaliação agentic completa exige um ambiente de execução real: um que executa cada chamada de ferramenta, rastreia o estado ao longo das etapas e lê o mundo depois para decidir se o trabalho foi feito. Sobre esse ambiente, duas camadas de pontuação:
- Nível de etapa (process scoring): a chamada foi válida, relevante e útil dado o estado naquele ponto?
- Fim a fim (E2E, outcome scoring): ignora o caminho e verifica só o estado final — o reembolso foi lançado? O chamado foi roteado?
O nível de etapa mostra onde a cadeia quebra (útil para depurar); o E2E colapsa uma falha na etapa 1 e na etapa 9 no mesmo “tarefa falhou”. O E2E é o que o usuário realmente vivencia, por isso a maioria das avaliações de produção trava o lançamento nele e mantém o rastreio de etapas por baixo para depuração.
As métricas que importam, em três eixos
| Métrica | Eixo | Por que existe |
|---|---|---|
| Taxa de sucesso | Acurácia | O portão de lançamento: o ambiente atingiu o estado-alvo? |
| Consistência (faixa entre 3–5 trials) | Acurácia | 90% num run e 74% noutro não é 84% — reporte a faixa, não o ponto |
| Precisão de chamada de ferramenta | Acurácia | Nomes alucinados e chamadas extras aparecem aqui |
| Precisão de argumentos | Acurácia | Separa “API errada” de “API certa, preenchida errado” |
| Passos por sucesso | Verbosidade | Quão longa a trajetória quando a tarefa termina |
| Custo por sucesso | Custo | A unidade econômica: tokens só importam por tarefa bem-sucedida |
Um trace real: SWE-bench Verified
No exemplo do artigo, o agente resolve uma issue real do pytest (o EncodedFile reportava modo binário rb+ mas o write() só aceitava str). O trace mostra quatro passos: localizar o arquivo, visualizar o arquivo inteiro (redundante), afunilar com grep (recuperou a ineficiência) e apontar a causa raiz. Resultado: E2E aprovado (testes passaram), pontuação de etapa 3/4 — uma das etapas foi redundante — e precisão de argumentos 4/4.
Nemotron 3.5 Lightning sob essa lente
O artigo defende ler os números do NVIDIA Nemotron 3.5 Lightning como conclusão de tarefa e tempo-para-terminar, não como acurácia isolada de chamada. No PinchBench, o modelo atinge 86% de acurácia concluindo 10.000 tarefas 30% mais rápido que o Qwen3.6 35B com acurácia comparável. Um modelo que termina com eficiência vence um que pontua mais em acurácia isolada enquanto queima mais passos e tokens.
Como avaliar sua própria carga
- Estabeleça um piso público rodando uma suíte agentic publicada e registre a taxa de sucesso e sua faixa em 3–5 trials.
- Construa uma avaliação de domínio com tickets, traces e APIs reais — trave no estado do ambiente (linha no banco, PR mergeado, ticket fechado), não na opinião de um juiz sobre a mensagem final.
- Adapte modelo e harness a essa distribuição e re-meça sucesso, consistência, passos e custo por sucesso.
Para times no Brasil que ainda avaliam agentes pela “qualidade da resposta final”, a lição é direta: sem ambiente executável e rastreio de etapas, você está otimizando texto, não trabalho concluído.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
