HLE-Verified: A Systematic Verification and Structured Revision of Humanity's Last Exam

1. O Problema

O Humanity's Last Exam (HLE) tornou-se um benchmark amplamente utilizado para avaliar modelos de linguagem de ponta (LLMs) em questões desafiadoras e multissetoriais. No entanto, análises posteriores da comunidade revelaram que o conjunto de dados original contém um número significativo de itens ruidosos, incluindo:

• Declarações de problemas ambíguas ou mal definidas.
• Respostas de referência incorretas.
• Racionalidades (explicações) inconsistentes com as respostas finais.

Esses erros introduzem um viés sistemático nas avaliações, distorcendo a comparação entre modelos. Quando itens estão próximos do limite de decisão do modelo, inconsistências menores podem impactar desproporcionalmente as métricas agregadas, fazendo com que o desempenho medido reflita artefatos de anotação em vez de capacidades reais de raciocínio.

2. Metodologia

Os autores desenvolveram o HLE-Verified, uma versão validada e revisada do HLE, utilizando um protocolo de verificação transparente e uma taxonomia de erros de alta granularidade. O processo de construção segue um fluxo de trabalho de duas etapas:

Estrutura do Pipeline

O conjunto de dados original (2.500 itens) é decomposto em três componentes verificáveis:

1. Problema (declaração e imagem).
2. Resposta Final (o alvo de avaliação).
3. Racionalidade (solução de referência, usada como sinal auxiliar).

Etapa I: Validação Binária e Construção do "Gold Subset"

• Objetivo: Determinar se um item é utilizável sem edições substanciais.
• Método: Combina revisão por especialistas em domínio e verificações cruzadas baseadas em modelos (pass@8 com solvers multimodais).
• Critério: Um item entra no conjunto "Gold" apenas se o problema e a resposta forem julgados corretos e sem ambiguidades de alto risco.
• Resultado: 668 itens verificados como corretos e mantidos inalterados.

Etapa II: Revisão Sistemática e Revalidação

• Objetivo: Corrigir itens identificados como defeituosos, mas reparáveis, preservando a intenção original de avaliação.
• Método:
  • Duas equipes de especialistas independentes propõem correções (Problema → Solução → Resposta).
  • Modelos auxiliam na geração de propostas e verificação de consistência.
  • Adjudicação final por especialistas internos para garantir a preservação do objetivo de teste.
• Restrição: As correções devem ser restaurativas, não criativas (não alteram o que o item pretende testar).
• Resultado: 1.143 itens revisados e revalidados.

Conjunto Incerto (Uncertain Subset)

• Itens onde a validade não pode ser determinada com confiança suficiente (devido a suposições não padrão, falta de referências externas ou desacordo entre especialistas).
• Resultado: 689 itens mantidos como um conjunto documentado com rótulos de incerteza e tags de expertise necessária, permitindo refinamento futuro pela comunidade.

Taxonomia de Defeitos

Foi criada uma taxonomia de 19 categorias de erros divididas por componente:

• Nível Problema (5 tipos): Erros semânticos, de conhecimento, informações faltantes, invalidade teórica e erros de formato.
• Nível Racionalidade (10 tipos): Violações de não redundância, raciocínio circular, inconsistências lógicas, aplicação incorreta de domínio, etc.
• Nível Resposta (4 tipos): Resposta incorreta, incompleta, ambígua e erros de formato.

3. Principais Contribuições

1. Lançamento do HLE-Verified: Um benchmark composto por 668 itens verificados, 1.143 itens revisados e um conjunto de 689 itens incertos documentados.
2. Protocolo de Auditoria Pós-Lançamento: Introdução de um framework sistemático de duas etapas para verificação e revisão de benchmarks após o lançamento, focando na integridade dos componentes.
3. Análise Empírica de Impacto: Demonstrar como a verificação altera as medições de desempenho e a relação entre confiança do modelo e erros no benchmark.
4. Metadados Estruturados: Liberação de dados com anotações detalhadas sobre tipos de erro, histórico de revisão e status epistêmico, facilitando a auditoria transparente.

4. Resultados Experimentais

Os autores avaliaram 8 modelos de última geração (incluindo GPT-5.2, Gemini3-Pro, Claude-Opus4.6, Qwen3, etc.) no HLE original vs. HLE-Verified.

• Ganhos de Precisão (Full Set): Houve um ganho médio absoluto de 7 a 10 pontos percentuais na precisão geral ao usar o HLE-Verified.
• Ganhos na Subconjunto Revisado: Nos itens que sofreram correção (onde o problema ou a resposta original estavam errados), o aumento de precisão foi dramático, variando de 30 a 40 pontos percentuais.
  • Exemplo: O modelo GPT-5.2 saltou de 33,35% para 52,48% no subconjunto revisado.
• Melhoria na Calibração: O erro de calibração diminuiu consistentemente após a revisão. Isso indica que os itens defeituosos do HLE original induziam os modelos a terem confiança incorreta (confiança alta em respostas erradas ou baixa em respostas corretas).
• Confiança como Diagnóstico: A análise mostrou que a confiança dos modelos aumenta significativamente após a correção de problemas com erros na declaração do problema. Isso sugere que a confiança do modelo pode ser um indicador útil para identificar itens ruidosos ou ambíguos.
• Variação por Domínio: As melhorias foram mais pronunciadas em Física e Biologia/Medicina, onde os erros originais afetavam frequentemente os campos de problema/resposta.

5. Significado e Conclusão

O trabalho demonstra que a confiabilidade de benchmarks de alta dificuldade depende da integridade de nível de componente (problema, resposta e racionalidade), e não apenas de uma verificação binária do item.

• Redução de Ruído: O HLE-Verified reduz o ruído de anotação, permitindo medições mais fiéis das capacidades dos modelos.
• Infraestrutura de Dados: Posiciona o conjunto de dados não apenas como uma tarefa de avaliação, mas como infraestrutura de confiabilidade metodológica.
• Sustentabilidade: Estabelece um precedente para a manutenção contínua de benchmarks científicos através de auditorias estruturadas e revisões transparentes, garantindo que as comparações entre modelos reflitam progresso real e não artefatos de dados.

Os dados e o código estão disponíveis publicamente no Hugging Face, permitindo que a comunidade continue a refinar e auditar o benchmark.