Dafny aceita 99,1% do código do Opus 4.7 no HumanEval, mas só 1,9% está vinculado à especificação

Quando um pipeline de geração de código informa que “N% das soluções foram verificadas”, esse número pode esconder uma garantia quase vazia. Prasenjit Dey, Ashish Jagmohan e Ravi Kokku publicaram no arXiv o trabalho “Verified but Vacuous”. Eles propõem decompor o conceito de “código verificado escrito por LLM” em três níveis medidos de forma independente e mostram, com dados, que esses níveis divergem muito. Em um dos experimentos, o verificador Dafny aceitou 99,1% das soluções do HumanEval, mas só 1,9% tinham uma pós-condição vinculada à especificação.

Três superfícies de falha

Os autores as chamam de superfícies A, B e C. A superfície A é a aceitação da prova pelo verificador (no Dafny, código de retorno zero). É a condição necessária, mas a mais fraca. A superfície B pergunta se o enunciado provado se liga a algo com significado: pelo menos uma pós-condição (ensures) precisa referenciar um predicado ou uma função da especificação pareada. A superfície C verifica se a própria especificação reflete o requisito original do usuário.

A auditoria segue em cadeia: a B é calculada sobre as amostras que passaram na A, e a C, sobre as que passaram na B. Os autores ressalvam que se trata de amostras condicionais, e não de uma hierarquia lógica de propriedades.

Para a superfície B, eles propuseram o ensures-binding gate, uma varredura estática da AST que leva milissegundos por componente. Para a superfície C, usam a verificação Post2Exe do benchmark VeriContest: a pós-condição é compilada em um predicado executável e rodada contra testes positivos e negativos. Se o predicado deixa passar uma resposta que um teste negativo deveria rejeitar, a especificação está incompleta.

Dois exemplos com a tarefa “retornar o máximo de um array” mostram a diferença. O método r := 0 sem ensures é aceito pelo verificador: simplesmente não há garantia funcional. Já se o ensures referencia o predicado r >= 0, o vínculo existe formalmente, mas a especificação é fraca demais, e só uma checagem comportamental detecta isso.

O que mostrou a reprodução de Li et al.

A equipe reproduziu com o Claude Opus 4.7 o pipeline de Li et al., em que o Dafny serve como representação intermediária. Foram testados três benchmarks Python de tarefas no nível do LeetCode: HumanEval, LeetCodeDataset e LiveCodeBench v6. O verificador aceitou de 92% a 99% das amostras, e a fatia com vínculo a um predicado da especificação ficou muito pequena. No HumanEval, foi de 1,9%. Outras 3,4% das amostras tinham pós-condição, mas ela não referenciava nenhum predicado da especificação. Pela estimativa dos autores, a distância entre aceitação e vínculo é de cerca de quarenta vezes.

A fatia de amostras com pós-condição cresce junto com a dificuldade: de 5,3% no HumanEval para 10,61% no LiveCodeBench v6 (1 032 de 9 731; 10,9% no subconjunto de 9 448 amostras que passaram nos testes). O modelo escreve mais pós-condições nas tarefas difíceis, mas isso não aumenta o número das que estão vinculadas à especificação.

Os autores enfatizam que isso não é um defeito do pipeline de Li et al. O prompt few-shot do artigo deles contém um método sem corpo e sem pós-condição, além de uma fixture que checa as expectativas em tempo de execução. Com esse formato de entrada, a aceitação pelo verificador indica apenas que as demais obrigações estáticas estão corretas, não que o código esteja funcionalmente correto. O erro, segundo eles, está na forma como esse tipo de pipeline costuma ser descrito.

Mesmo por construção, verificado não significa correto

O pipeline próprio dos autores, o VCG, funciona de outro jeito: o Planner divide a tarefa, o SpecAgent escreve as especificações em Dafny, o ImplementationAgent escreve as implementações, e o ProverAgent executa o ciclo de verificação e correção com o ensures-gate. Os componentes verificados são transpilados para Rust. O vínculo com a especificação vale para 100% dos componentes por construção. Mesmo assim, 11,48% das amostras no MBPP-Rust e 14,82% no recorte LC do VeriContest falharam nos testes ocultos. Os autores descrevem isso como uma aproximação operacional da conformidade com os requisitos, e não como um diagnóstico exato de erro de especificação.

No recorte LC do VeriContest, a métrica ponta a ponta End2End do VCG é de 7,79% (535 de 6 870). Os números externos publicados são 5,51% para o GPT-5.5 e 1,88% para uma execução única do Opus 4.7. Isso dá uma diferença de 2,3 pontos percentuais e de 4,14 vezes. Mas os orçamentos por tarefa, o número de tentativas de correção e os arneses de teste diferem (o VCG usa dez amostras por tarefa, e a comparação externa, uma), então os autores não afirmam superioridade comparável.

Limitações e conclusão prática

O trabalho traz estimativas pontuais, sem intervalos de confiança. O próprio ensures-gate é grosseiro: pode rejeitar uma pós-condição inline com significado e deixar passar uma tautologia com nome imponente. Os 27% de falhas estruturais declarados na auditoria pré-lançamento do VCG e os 98% do Li@Opus não foram checados por anotação independente de vacuidade semântica.

A recomendação prática é objetiva. Todo pipeline que emite certificados deve publicar, junto com a aceitação do verificador, pelo menos uma das métricas B ou C, e de preferência as duas. Só a B deixa um ponto cego semântico, como no VCG. Só a C deixa um ponto cego sintático, como no Li@Opus. Para equipes que pretendem levar à produção código com “verificação formal” feita por LLM, é um checklist pronto do que perguntar ao fornecedor.