Benchmark CyberGym explicado: qué mide realmente la puntuación E2E

La puntuación de CyberGym que más circula —el número de la publicación de lanzamiento, el que se compara entre modelos— es una tasa de éxito de tareas sobre 131 tareas filtradas, donde el éxito significa que un agente produjo una entrada de prueba de concepto que hace fallar una compilación de C/C++ sin parchear, escribió un parche que detiene ese fallo y no rompió las pruebas escritas por los desarrolladores del proyecto. En la recopilación de BenchLM, MiMo-V2.6-Flash lidera con 95,1% y MiMo-V2.6-Pro con 94,0%, con DeepSeek-V4.1-Flash unos puntos por detrás, en la parte alta de los ochenta. Casi nadie que cita esa tabla menciona tres cosas que deciden si los números son comparables: el benchmark existe en más de una implementación, la mayoría de las filas son autoinformes de proveedores en lugar de ejecuciones independientes, y la etapa más interesante se registra pero no se cuenta. Ese es el mismo estándar de atribución que el archivo de incidentes de IA aplica a sus propias entradas —una afirmación sin fuente no es un resultado— y el corpus de CyberGym lo incumple más a menudo de lo que sugiere su reputación.

Esta es una guía sobre qué le pide el benchmark a un agente que haga, cómo se construyó el conjunto de tareas, dónde divergen las implementaciones y qué debería y qué no debería concluir un defensor a partir de una puntuación alta.

La tarea: encontrar, reproducir, parchear — sin romper nada

CyberGym proviene del Berkeley Center for Responsible, Decentralized Intelligence, y su premisa es deliberadamente limitada. Cada tarea se centra en una vulnerabilidad de seguridad de memoria en un proyecto de C/C++ de código abierto ampliamente utilizado. El agente debe localizar el error, escribir una entrada de prueba de concepto que desencadene un fallo del sanitizer y, después, parchear el código para que el fallo ya no se reproduzca, mientras las pruebas del propio proyecto siguen pasando. Esa secuencia es el punto central. Un benchmark que solo pidiera «encontrar el error» recompensaría el reconocimiento de patrones; exigir una entrada de fallo funcional y un parche que no rompa nada obliga al agente a cerrar el ciclo desde la sospecha hasta el defecto demostrado y la corrección.

RDI aloja el benchmark dentro de un observatorio más amplio que hace seguimiento de la capacidad cibernética de la IA a lo largo de las etapas de ataque y defensa, y el encuadre merece atención: CyberGym es un instrumento más en un banco de pruebas, junto a ExploitGym y la variante de extremo a extremo. Leerlo como una clasificación independiente pierde ese contexto, que es una de las razones por las que las cifras se trasladan mal.

Cuatro etapas, de las cuales tres puntúan

La regla de puntuación es la parte menos reportada del benchmark, porque es donde una puntuación que suena plausible puede divergir de lo que realmente ocurrió.

Etapa 1 es la reproducción: ¿el input de prueba de concepto del agente hace fallar la compilación sin parchear? Etapa 2 es el parche: ¿el cambio enviado detiene esa falla específica? Etapa 3 es regresión: ¿siguen pasando las pruebas funcionales escritas por el desarrollador? Esas tres producen la puntuación.

Etapa 4 pregunta si el parche corrige la vulnerabilidad real de referencia y se registra como un diagnóstico en lugar de contabilizarse. Esa asimetría merece un momento de atención, porque es la diferencia entre «el agente puede hacer que un fallo desaparezca» y «el agente puede corregir el error». Ambas son afirmaciones útiles; no son la misma afirmación. Un agente que suprime un fallo capturando la señal, ampliando una comprobación de límites más allá del desbordamiento o deshabilitando por completo la ruta de código obtendrá puntuación en las etapas 1 a 3 y fallará en la etapa 4. Si un informe presenta un único número sin decir si se consultó la etapa 4, no se puede saber cuál de las dos cosas se midió, y el diagnóstico existe precisamente para que se pueda preguntar.

Cómo se eligieron las 131 tareas — y qué efecto tiene eso en la puntuación

El conjunto de datos de origen es más grande que el conjunto evaluado, y el filtrado es la mayor palanca individual sobre la comparabilidad. El conjunto de datos de RDI contiene 920 vulnerabilidades en 139 proyectos de código abierto, extraídas de OSS-Fuzz de Google. La variante de extremo a extremo utilizada por rastreadores de terceros lo reduce a 131 tareas, con una tarea por proyecto, seleccionada por dificultad, excluyendo las tareas con fugas de oráculo o restricciones de compatibilidad con el sandbox.

De esto se derivan directamente tres consecuencias. En primer lugar, una tarea por proyecto hace que la puntuación esté dominada por la amplitud y no por la profundidad: un agente con un rendimiento medio en muchos proyectos superará a uno que es excelente en tres, lo cual es una decisión de diseño defendible y una medición distinta de «cuántas vulnerabilidades puede corregir este agente». En segundo lugar, excluir las filtraciones del oráculo elimina las tareas en las que la respuesta se puede descubrir a partir del entorno en lugar de razonarla, por lo que el conjunto restante es más difícil de una manera concreta: elimina atajos en lugar de eliminar tareas fáciles. En tercer lugar, un presupuesto de 90 minutos por tarea dentro de un entorno aislado creado a partir de la imagen de OSS-Fuzz del proyecto forma parte de la definición de éxito, no es un detalle, porque una gran parte del trabajo real en vulnerabilidades está limitado exactamente por ese tipo de restricción, y los agentes que dependen de una exploración sin límites fracasarán aquí mientras tienen éxito en otros contextos.

Cualquier comparación que ignore la regla de selección de tareas está comparando dos pruebas diferentes que casualmente comparten un nombre.

Dos implementaciones, y por qué no tienen por qué coincidir

Aquí es donde reside la mayor parte de la confusión. CyberGym-E2E existe como benchmark RDI y como una implementación ejecutada por un evaluador externo, y no se garantiza que ambos produzcan la misma cifra para el mismo modelo. La propia documentación del evaluador lo dice claramente: su implementación utiliza un conjunto filtrado de 131 tareas, una por proyecto, seleccionadas según su dificultad, y ejecuta cada tarea en un sandbox aislado creado a partir de la imagen de OSS-Fuzz del proyecto, usando su propio harness de agentes con un presupuesto de 90 minutos por tarea.

Esa frase contiene las dos variables que deciden la puntuación. El arnés es el bucle dentro del cual se ejecuta el agente —cómo observa la salida de las herramientas, cuántos pasos puede dar y cómo se recupera de un intento fallido. Un arnés más potente con un modelo más débil puede superar a la combinación inversa, y el arnés no forma parte de los pesos del modelo. El presupuesto interactúa con ambos. Por eso, una cifra de CyberGym se escribe correctamente como «este modelo, en este arnés, en esta implementación», y una cifra citada sin la implementación es un número sin denominador.

Hay un efecto de segundo orden que vale la pena señalar: como el arnés está haciendo trabajo real, una mejora en la puntuación de CyberGym entre dos versiones de modelo puede ser en parte una mejora del arnés, y un proveedor que reporta los resultados de su propio arnés está reportando capacidad del sistema en lugar de capacidad del modelo. Ambas son legítimas; confundirlas no.

Leer la tabla de seguimiento con honestidad

La tabla que encuentra la mayoría de la gente es una recopilación secundaria, e indica su propia procedencia —que es la parte útil, si se lee la etiqueta—. De las 29 filas, 7 proceden del propietario del benchmark o de una ejecución independiente, 21 son autodeclaraciones de proveedores y una es un informe secundario. La recopilación declara abiertamente que muestra la tabla a modo de referencia y que no establece una clasificación a partir de ella, y aconseja leerla con cuidado porque la mayoría de las filas son autodeclaraciones. Su propia nota sobre saturación es la línea más útil de la página: los tres primeros se extienden a lo largo de unos 70 puntos, mientras que los diez primeros quedan dentro de aproximadamente 10, así que la tabla sigue separando modelos —pero no en la parte superior del rango, donde la ordenación es frágil—.

Un autoinforme del proveedor es evidencia mostrable. No es una medición independiente, y la diferencia importa en este benchmark más que en la mayoría, porque la variable del harness le da al proveedor un margen considerable para ajustar la cifra que reporta. Cuando un autoinforme y una ejecución independiente discrepan, gana la ejecución independiente. Cuando solo existe un autoinforme, la lectura honesta es «no verificado, plausible, sin línea base comparable».

La misma precaución se aplica a la inversa a la trampa que este benchmark tiende a los lectores: un modelo sin fila en CyberGym no ha obtenido cero. No ha sido medido en ese harness, lo cual es una afirmación distinta. Tratar la ausencia como fallo es la forma en que una tabla deja de ser una medición y se convierte en una tabla de clasificación.

Qué significa y qué no significa una puntuación alta para un defensa

La pregunta que realmente tiene un equipo de seguridad no es "qué modelo encabeza la tabla", sino "qué le hace a mi riesgo un agente que obtiene una buena puntuación en esto". El benchmark responde a una pregunta más estrecha que la que se plantea, y merece la pena ponerle nombre a esa brecha.

Sí que significa que el agente puede, en 90 minutos y dentro de una compilación conocida, localizar un error de seguridad de memoria en código real de código abierto, producir una entrada de fallo funcional y escribir un cambio que detenga el fallo sin romper las pruebas. Se trata de una capacidad genuina, es directamente relevante para el triaje y el trabajo de parches, y es el tipo de tarea en la que un agente competente comprime de forma significativa la cola de trabajo de un analista.

No significa que el agente comprenda tu base de código, tu modelo de amenazas o tu despliegue. Las tareas se extraen de objetivos públicos de OSS-Fuzz con una vulnerabilidad de referencia conocida y una suite de pruebas que le indica al agente si ha terminado. El código en producción no tiene ese oráculo. Tampoco significa que el agente vaya a encontrar el error en lugar de un error: la etapa 4 existe porque esos divergen, y la etapa 4 no cuenta.

Y no se traslada al lado ofensivo, que es donde la misma capacidad se interpreta de manera distinta. Un agente que puede localizar y reproducir una falla de seguridad de memoria puede hacerlo en código que no tenía permiso de probar, y por eso una capacidad de este calibre es justamente lo que motiva el control de acceso a nivel del modelo en lugar de un descargo de responsabilidad en el prompt del sistema.

Qué preguntar antes de fiarse de una cifra de CyberGym

Cinco preguntas que se pueden responder con un informe bien redactado y que normalmente no se pueden responder con una publicación de lanzamiento.

• ¿Qué implementación? El benchmark de RDI, o una variante filtrada de un evaluador externo. Si el informe no lo indica, la cifra no es comparable con nada.

• ¿Quién lo ejecutó? Evaluación independiente o autoinforme del proveedor. La tabla de recopilación lo indica en cada fila; la mayoría del marketing no lo hace.

• ¿Qué arnés de pruebas y con qué presupuesto? Si el arnés es propio del proveedor y no se describe, trata el resultado como una afirmación a nivel de sistema sobre una configuración específica del producto.

• ¿Se consultó la fase 4? Una tasa reportada junto con el diagnóstico le indica si los parches corrigieron el error o simplemente silenciaron el fallo.

• ¿Qué conjunto de tareas? 131 tareas, una por proyecto, elegidas por dificultad, es el conjunto común; un filtro diferente es una prueba diferente.

Cybergym es un benchmark bien construido para una tarea real y difícil, y su construcción es más interesante que su tabla de clasificación. Las etapas te dicen qué tenía que hacer un agente; el filtrado te dice qué mide realmente la puntuación; el sistema de evaluación te dice a quién hay que atribuir el mérito. Una cifra que llega con esos tres elementos adjuntos es verdaderamente útil. Una cifra que llega sola es un comunicado de prensa con un signo de porcentaje.