VerifierBench: 19 LLMs escreveram verificadores, e o melhor fez apenas 62,1 pontos

Agentes precisam de um jeito de saber se resolveram a tarefa corretamente. Sem isso, não dá para concluir o trabalho nem filtrar dados sintéticos para treinamento. A equipe por trás do VerifierBench avaliou como as LLMs se saem nessa tarefa sozinhas: com base em uma instrução e no ambiente disponível, o agente escreve um verificador executável, que precisa aceitar qualquer solução correta e rejeitar qualquer solução incorreta. O benchmark inclui 222 tarefas de seis benchmarks de agentes e 4993 casos de teste ocultos. Em 19 modelos, a acurácia balanceada normalizada ficou na faixa de 10,6 a 62,1.

O que exatamente o VerifierBench avalia

A tarefa é formulada de maneira rigorosa. O verificador recebe as mesmas informações que o agente que resolve o problema: o texto da tarefa e o ambiente. A partir disso, ele precisa produzir um programa que dê um veredito sobre a solução de outra pessoa. As tarefas cobrem três tipos de verificação: chamadas de ferramentas (tool-call), verificação do estado final do ambiente (state-based) e verificação de código.

Os testes ocultos foram montados para pegar mais do que erros óbvios. Cada tarefa tem, em média, cerca de 22 casos. Entre eles estão soluções válidas alternativas, isto é, outras formas de chegar ao resultado correto, e ataques que tentam enganar a verificação. Os próprios verificadores originais e os conjuntos de teste passam por uma auditoria do Verifier4Verifier (V4V), composta por seis verificações. Assim, a referência não se torna fonte dos próprios erros.

Principais parâmetros do trabalho:

• 222 tarefas de seis benchmarks de agentes
• 4993 casos de teste ocultos, incluindo soluções alternativas e ataques
• 19 modelos em um mesmo harness de agentes
• normalized balanced accuracy: de 10,6 a 62,1
• a página do projeto e o dataset são públicos

O verificador que não deixa ninguém passar

O ponto mais interessante dos resultados é o desequilíbrio. Os verificadores gerados rejeitam soluções incorretas de forma consistente melhor do que aceitam as corretas. À primeira vista, isso parece uma qualidade: uma verificação rígida, em tese, seria segura. Os autores mostram que o quadro é outro. A maior parte das recusas indevidas nos registros analisados vem de verificadores que não aceitam nenhuma das soluções testadas para a tarefa. Esse verificador, formalmente, faz bem metade do trabalho e falha por completo na outra metade.

Para pipelines, isso é um problema sério. Se o verificador filtra dados sintéticos, o excesso de rigor descarta trajetórias corretas sem avisar. Se ele serve de sinal de sucesso para o agente em tempo de execução, o agente pode refazer indefinidamente um resultado que já está certo.

A análise de casos individuais mostra de onde vem esse rigor. Os verificadores embutem suposições não verificadas sobre o formato da solução, sobre quais ferramentas devem ser chamadas e sobre como o código deve ficar após as alterações. Qualquer solução estruturada de modo diferente do que o autor da verificação imaginou é rejeitada, mesmo que resolva a tarefa.

Por que a autoverificação não pega o erro

Seria de esperar que o próprio agente notasse o defeito ao rodar seu verificador em soluções de teste. Na prática, os erros sobrevivem à autoverificação, e os autores apontam duas causas. A primeira: o agente testa soluções que partilham as mesmas suposições equivocadas do próprio verificador. Ele escreve a verificação para um único modelo de resposta, depois gera a resposta seguindo o mesmo modelo, e tudo bate. A segunda: parte dos agentes entrega o verificador sem sequer confirmar que pelo menos uma solução correta passa por ele.

Como testar os próprios verificadores

A conclusão dos autores é prática: não basta checar se o verificador aceita uma solução correta. É preciso checar também se ele aceita as outras soluções que a tarefa admite. Para equipes que constroem pipelines de agentes ou montam datasets sintéticos, isso leva a alguns passos.

Primeiro, cada verificador gerado precisa de pelo menos um exemplo comprovadamente correto que passe na verificação; do contrário, ele pode virar uma "parede maciça". Segundo, o conjunto de testes deve conter soluções corretas alternativas, com outro formato, outra ordem de chamadas e outra forma de alterar o código. Terceiro, vale acompanhar separadamente a taxa de recusas indevidas, e não apenas a acurácia total: o viés para o excesso de rigor é fácil de esconder na métrica geral. Por fim, a própria referência deve ser auditada, e a abordagem V4V oferece um esquema pronto para isso.

A variação de 10,6 a 62,1 também indica que a geração de verificadores está longe de ser um problema resolvido. Mesmo o melhor resultado deixa uma margem de erro considerável. Por isso, ainda é cedo para confiar na avaliação feita por agentes sem controle independente, e o dataset público dá às equipes uma forma prática de comparar modelos justamente nessa habilidade.