Resumo Técnico: SpecBench

Declaração do Problema

As atuais benchmarks de engenharia de software (SWE), como o SWE-Bench, avaliam principalmente o raciocínio no nível de implementação: a capacidade de um agente de gerar código que passa em testes dada uma especificação fixa, precisa e presumivelmente correta. Essa formulação negligencia uma fase crítica no desenvolvimento de software real: o design da especificação. Em sistemas complexos, propostas de design iniciais são frequentemente incompletas, ambíguas ou falhas, exigindo extensa revisão e revisão por especialistas antes que a implementação possa prosseguir. As benchmarks existentes não medem a capacidade de um agente de identificar essas deficiências ou de raciocinar sobre o design do sistema sem feedback de execução.

Metodologia

Os autores introduzem o SpecBench, uma benchmark projetada para avaliar o raciocínio no nível de especificação. A capacidade central medida é a habilidade de gerar especificações de sistema completas, não ambíguas, consistentes e corretas, identificando deficiências em propostas de design iniciais.

Construção do Conjunto de Dados

• Fonte: As tarefas são derivadas dos processos de Solicitação de Comentários (RFC) de cinco repositórios de código aberto diversos: Kubernetes, React, Rust, TVM e vLLM.
• Entrada: Para cada tarefa, um agente recebe:
  1. A proposta de design RFC inicial.
  2. A base de código do projeto (no commit anterior à proposta RFC).
  3. O histórico de discussões e decisões anteriores sobre RFCs.
  • Os agentes têm restrição de acesso a recursos da internet ou ao histórico do Git após a data da proposta.
• Tarefa: O agente deve identificar deficiências na especificação (omissões, ambiguidades, inconsistências ou suposições incorretas) na proposta inicial.
• Classificação de Deficiências: As deficiências são categorizadas com base no IEEE Std. 1028-1997 e em trabalhos anteriores em quatro classes:
  • Omissão: Informações necessárias ausentes.
  • Ambiguidade: Informações com múltiplas interpretações.
  • Inconsistência: Contradições dentro da proposta ou com o sistema existente.
  • Incorreta: Contradições com documentos ou informações anteriores.

Construção da Benchmark e Avaliação

• Conjunto Dourado: A verdade fundamental consiste nas deficiências levantadas pelos contribuidores originais durante discussões históricas de RFCs.
• Tratamento da Variância de Especialistas: Para abordar o ruído proveniente de prioridades diferentes entre especialistas, os autores utilizam um painel de especialistas baseado em LLM para classificar as deficiências extraídas em uma escala Likert de 5 pontos. As deficiências são rotuladas como "principais" (pontuação média ≥ 3,0 e ≥ 2/3 de endosso de especialistas) ou "estendidas". Itens principais recebem o dobro do peso na pontuação.
• Validação de Mundo Aberto: Diferentemente de suites de testes determinísticas, o espaço de lacunas de especificação válidas é aberto. Os autores adotam a metodologia de Recuperação de Informação (RI):
  • Previsões que correspondem ao conjunto dourado são verificadamente válidas.
  • Previsões não presentes no conjunto dourado são tratadas como não julgadas (não necessariamente incorretas) em vez de falsos positivos.
  • Um orçamento de previsão limitado é imposto ($N = \lceil 1,25 \times |G| \rceil$) para impedir que agentes inundem a avaliação com palpites de baixa qualidade.
• Mecanismo de Julgamento: Para lidar com a correspondência semântica entre previsões em texto livre e conjuntos dourados, um processo de duas etapas é utilizado:
  1. Decomposição Estruturada: As deficiências são decompostas em Sujeito (componente do sistema), Predicado (natureza da deficiência) e Impacto (consequência).
  2. Julgamento em Conjunto: Dois juízes LLM independentes (GPT-5.4 e Sonnet 4.6) realizam quatro tentativas por tarefa. Uma correspondência é aceita se aparecer em pelo menos 3 de 4 tentativas.

Principais Contribuições

1. Benchmark SpecBench: A primeira benchmark especificamente voltada para o raciocínio no nível de especificação, desacoplada da implementação de código.
2. Protocolo de Avaliação Novel: Uma metodologia para avaliar críticas de especificação de mundo aberto usando um orçamento de previsão limitado, pontuação ponderada baseada em consenso de especialistas e correspondência semântica estruturada (triplos SPI) para lidar com a variância linguística.
3. Baselines Empíricos: Avaliação de agentes SWE de última geração (incluindo variantes do Codex, Claude e Gemini) nesta nova tarefa, revelando lacunas significativas nas capacidades atuais.

Resultados

• Desempenho Geral: O agente de melhor desempenho, GPT-5.4 (referido como Codex-5.4 na seção de resultados), alcançou uma precisão de 44,4%. Todos os agentes avaliados permaneceram abaixo de 45%, indicando espaço substancial para melhoria.
• Principais vs. Estendidas: Os agentes desempenharam significativamente melhor em deficiências principais (alto consenso de especialistas) do que nas estendidas, alinhando-se com a construção do conjunto de dados.
• Variância entre Repositórios: O desempenho variou entre os repositórios, com o melhor agente mostrando a maior vantagem nas tarefas do React e vLLM.
• Confiabilidade do Juiz: A concordância entre juízes foi medida usando similaridade de Jaccard em pares, com planos para aumentar a diversidade de juízes em versões futuras.

Significado e Alegações

O artigo afirma que o SpecBench aborda uma lacuna crítica na avaliação de agentes SWE ao deslocar o foco da execução de requisitos claros para o design deles. Os autores argumentam que:

• A engenharia de software real exige que agentes compreendam valores da comunidade (por exemplo, segurança de memória do Rust versus estabilidade da API do React) e decisões de design históricas, não apenas a geração de código.
• As benchmarks atuais assumem "especificações perfeitas", o que não reflete a realidade de sistemas complexos onde propostas iniciais são frequentemente falhas.
• O SpecBench isola capacidades de raciocínio no nível de especificação, distintas do raciocínio no nível de implementação enfatizado em trabalhos anteriores como o SWE-Bench.

Os autores observam que esta é uma versão inicial da benchmark focada em identificar deficiências. Trabalhos futuros expandirão o SpecBench para incluir tarefas de revisão (corrigir as especificações) e incorporarão validação por especialistas humanos para estabelecer baselines de desempenho humano e medir o acordo entre humanos e LLMs.