CyberGym Benchmark explicado: o que a pontuação E2E realmente mede

A pontuação do CyberGym mais amplamente divulgada — o número no post de lançamento, aquele que é comparado entre modelos — é uma taxa de sucesso em tarefas calculada sobre 131 tarefas filtradas, em que sucesso significa que um agente produziu uma entrada de prova de conceito que derruba uma build C/C++ sem patch, escreveu um patch que impede essa falha e não quebrou os testes escritos pelos desenvolvedores do projeto. Na compilação do BenchLM, o MiMo-V2.6-Flash lidera com 95,1% e o MiMo-V2.6-Pro com 94,0%, com o DeepSeek-V4.1-Flash alguns pontos atrás, na faixa dos 80% altos. Quase ninguém que cita essa tabela menciona três coisas que determinam se os números são comparáveis: o benchmark existe em mais de uma implementação, a maioria das linhas são autorrelatos dos provedores, e não execuções independentes, e o estágio mais interessante de todos é registrado, mas não contabilizado. Esse é o mesmo padrão de atribuição que o arquivo de incidentes de IA aplica às suas próprias entradas — uma alegação sem fonte não é um resultado — e o corpus do CyberGym falha nesse critério com mais frequência do que sua reputação sugere.

Este é um guia sobre o que o benchmark pede que um agente faça, como o conjunto de tarefas foi construído, onde as implementações divergem e o que um defensor deve e não deve concluir a partir de uma pontuação alta.

A tarefa: localizar, reproduzir, corrigir — sem quebrar nada

O CyberGym vem do Berkeley Center for Responsible, Decentralized Intelligence, e sua premissa é deliberadamente estreita. Cada tarefa tem como alvo uma vulnerabilidade de segurança de memória em um projeto de código aberto em C/C++ amplamente utilizado. O agente deve localizar o bug, escrever uma entrada de prova de conceito que dispare um crash do sanitizador e, então, corrigir o código para que o crash não seja mais reproduzido — enquanto os testes do próprio projeto continuam passando. Essa sequência é o ponto central. Um benchmark que apenas pedisse "encontrar o bug" recompensaria o reconhecimento de padrões; exigir uma entrada de crash funcional e uma correção que não quebre nada força o agente a fechar o ciclo da suspeita ao defeito demonstrado até a correção.

A RDI hospeda o benchmark dentro de um observatório mais amplo que acompanha a capacidade cibernética da IA nas fases de ataque e defesa, e o enquadramento merece atenção: o CyberGym é um instrumento numa bancada, ao lado do ExploitGym e da variante ponta a ponta. Lê-lo como um ranking independente perde esse contexto, o que é uma das razões pelas quais os números circulam mal.

Quatro etapas, três das quais pontuam

A regra de pontuação é a parte menos reportada do benchmark, porque é onde uma pontuação que parece plausível pode divergir do que realmente aconteceu.

Etapa 1 é a reprodução: a entrada de prova de conceito do agente faz a compilação não corrigida falhar? Etapa 2 é o patch: a alteração submetida impede essa falha específica? Etapa 3 é regressão: os testes de funcionalidade escritos pelo desenvolvedor ainda passam? Esses três produzem a pontuação.

Estágio 4 pergunta se o patch corrige a vulnerabilidade real de referência (ground truth), e isso é registrado como diagnóstico, não contabilizado. Essa assimetria merece atenção, porque é a diferença entre "o agente consegue fazer um crash desaparecer" e "o agente consegue corrigir o bug". Ambas são afirmações úteis; não são a mesma afirmação. Um agente que suprime um crash capturando o sinal, ampliando uma verificação de limites para além do overflow ou desativando totalmente o caminho de código pontuará nos estágios 1 a 3 e falhará no estágio 4. Se um relatório apresenta um único número sem dizer se o estágio 4 foi consultado, você não consegue saber qual das duas coisas foi medida — e o diagnóstico existe exatamente para que você possa perguntar.

Como as 131 tarefas foram escolhidas — e o que isso faz com a pontuação

O conjunto de dados de origem é maior que o conjunto pontuado, e a filtragem é a maior alavanca isolada para a comparabilidade. O conjunto de dados da RDI contém 920 vulnerabilidades em 139 projetos de código aberto, extraídas do OSS-Fuzz do Google. A variante ponta a ponta usada por rastreadores de terceiros reduz isso para 131 tarefas, com uma tarefa por projeto, selecionadas por dificuldade, excluindo tarefas com vazamentos de oráculo ou restrições de compatibilidade com sandbox.

Três consequências decorrem diretamente. Primeiro, uma tarefa por projeto significa que a pontuação é dominada pela amplitude em vez da profundidade: um agente que é mediano em muitos projetos superará um que é excelente em três, o que é uma escolha de design defensável e uma medida diferente de "quantas vulnerabilidades este agente consegue corrigir". Segundo, excluir vazamentos de oráculo remove tarefas em que a resposta é descobrível a partir do ambiente em vez de deduzida por raciocínio, então o conjunto restante é mais difícil de uma forma específica — ele remove atalhos em vez de remover tarefas fáceis. Terceiro, um orçamento de 90 minutos por tarefa dentro de uma sandbox construída a partir da imagem OSS-Fuzz do projeto faz parte da definição de sucesso, não um detalhe, porque uma grande parte do trabalho real com vulnerabilidades é limitada exatamente por esse tipo de restrição, e agentes que dependem de exploração ilimitada falharão aqui embora tenham sucesso em outros lugares.

Qualquer comparação que ignore a regra de seleção de tarefas está comparando dois testes diferentes que, por acaso, compartilham o mesmo nome.

Duas implementações, e por que elas não precisam concordar

É aqui que reside a maior parte da confusão. O CyberGym-E2E existe como um benchmark RDI e como uma implementação executada por um avaliador de terceiros, e não há garantia de que os dois produzam o mesmo número para o mesmo modelo. A própria documentação do avaliador diz isso claramente: sua implementação usa um conjunto filtrado de 131 tarefas, uma por projeto, escolhidas com base na dificuldade, e executa cada tarefa em um sandbox isolado criado a partir da imagem OSS-Fuzz do projeto, usando seu próprio harness de agente com um orçamento de 90 minutos por tarefa.

Essa frase contém as duas variáveis que determinam a pontuação. O harness é o loop dentro do qual o agente executa — como ele observa a saída das ferramentas, quantos passos pode dar, como se recupera de uma tentativa malsucedida. Um harness mais forte com um modelo mais fraco pode superar o caso inverso, e o harness não faz parte dos pesos do modelo. O orçamento interage com ambos. Portanto, um valor do CyberGym é escrito adequadamente como "este modelo, neste harness, nesta implementação", e um valor citado sem a implementação é um número sem denominador.

Há um efeito de segunda ordem que vale a pena explicitar: como o harness está fazendo trabalho real, uma melhoria na pontuação do CyberGym entre duas versões de modelo pode ser, em parte, uma melhoria do harness, e um fornecedor que relata os resultados do seu próprio harness está relatando capacidade do sistema, não capacidade do modelo. Ambos são legítimos; confundi-los não é.

Leitura honesta da tabela de acompanhamento

A tabela que a maioria das pessoas encontra é uma compilação secundária, e ela rotula sua própria procedência — o que é a parte útil, se você ler o rótulo. Das 29 linhas, 7 vêm do proprietário do benchmark ou de uma execução independente, 21 são auto-relatos de provedores e uma é um relatório secundário. A compilação declara explicitamente que apresenta a tabela apenas como referência e não faz ranking com base nela, e recomenda lê-la com cuidado porque a maioria das linhas são auto-relatos. Sua própria nota de saturação é a linha mais útil da página: os três primeiros estão distribuídos por cerca de 70 pontos, enquanto os dez primeiros ficam dentro de aproximadamente 10, então a tabela ainda separa modelos — mas não no topo da faixa, onde a ordenação é tênue.

Um autorrelato do provedor é evidência exibível. Não é uma medição independente, e essa diferença importa neste benchmark mais do que na maioria, porque a variável do harness dá ao fornecedor bastante margem para ajustar o número que reporta. Quando um autorrelato e uma execução independente divergem, a execução independente prevalece. Quando existe apenas um autorrelato, a leitura honesta é "não verificado, plausível, sem linha de base comparável".

O mesmo cuidado se aplica, inversamente, à armadilha que este benchmark prepara para os leitores: um modelo sem linha no CyberGym não obteve zero. Ele não foi medido nessa estrutura de avaliação, o que é uma afirmação diferente. Tratar a ausência como falha é assim que uma tabela deixa de ser uma medição e se torna um ranking.

O que uma pontuação alta significa e não significa para um defensor

A pergunta que uma equipe de segurança realmente tem não é "qual modelo lidera a tabela", mas "o que um agente que obtém boa pontuação nisto faz com o meu risco". O benchmark responde a uma pergunta mais estreita do que a que está sendo feita, e vale a pena explicitar essa lacuna.

Isso significa que o agente consegue, em até 90 minutos e dentro de um build conhecido, localizar uma falha de segurança de memória em código open-source real, produzir uma entrada que realmente provoque o crash e escrever uma alteração que impede o crash sem quebrar os testes. Essa é uma capacidade genuína, é diretamente relevante para triagem e trabalho de patch, e é o tipo de tarefa em que um agente competente reduz significativamente a fila de um analista.

Isso não significa que o agente entende sua base de código, seu modelo de ameaças ou sua implantação. As tarefas são extraídas de alvos públicos do OSS-Fuzz com uma vulnerabilidade de referência conhecida e uma suíte de testes que informa ao agente se ele concluiu. O código de produção não tem esse oráculo. Também não significa que o agente encontrará o bug em vez de um bug: o estágio 4 existe porque eles divergem, e o estágio 4 não conta.

E isso não se transfere para o lado ofensivo, que é onde a mesma capacidade é interpretada de forma diferente. Um agente capaz de localizar e reproduzir uma falha de segurança de memória pode fazê-lo em código para o qual não recebeu permissão de teste, e é por isso que uma capacidade dessa ordem é exatamente o que motiva o controle de acesso no nível do modelo, em vez de uma declaração de isenção de responsabilidade em um prompt de sistema.

O que perguntar antes de confiar em um número do CyberGym

Cinco perguntas que podem ser respondidas por um relatório bem escrito e que normalmente não podem ser respondidas por um post de lançamento.

• Qual implementação? O benchmark da RDI, ou uma variante filtrada de um avaliador terceirizado. Se o relatório não disser, o número não é comparável a nada.

• Execução de quem? Avaliação independente ou autorrelato do fornecedor. A tabela de compilação indica isso por linha; a maioria do marketing não.

• Qual estrutura de avaliação e qual orçamento? Se a estrutura de avaliação for do próprio fornecedor e não estiver descrita, trate o resultado como uma alegação em nível de sistema sobre uma configuração específica de produto.

• A etapa 4 foi consultada? Uma taxa relatada com o diagnóstico ao lado dela indica se os patches corrigiram o bug ou apenas silenciaram o crash.

• Qual conjunto de tarefas? O conjunto comum é 131 tarefas, uma por projeto, escolhidas por dificuldade; um filtro diferente é um teste diferente.

O Cybergym é um benchmark bem construído para uma tarefa difícil e real, e sua construção é mais interessante do que seu leaderboard. As etapas dizem o que um agente teve de fazer; a filtragem diz do que a pontuação é uma pontuação; o harness diz quem merece crédito. Um número que chega com esses três anexados é genuinamente útil. Um número que chega sozinho é um comunicado à imprensa com sinal de porcentagem.