FrontierCS 2 evaluó a 12 agentes de IA en tareas de I+D: el mejor aprobó el 58%

El benchmark FrontierCS 2 plantea una pregunta que la industria suele esquivar: ¿puede un agente basado en LLM no solo resolver un ejercicio académico, sino hacer una aportación digna de un artículo científico? El conjunto consta de 48 tareas abiertas en 13 áreas. De los 12 agentes evaluados, el mejor, Claude Opus 5.5, supera el 58% de sus ejecuciones. En 16 tareas no aprobó ninguna ejecución, es decir, en un tercio del conjunto el resultado es nulo.

Cómo se convierte un artículo en un examen

El diseño es sencillo y bastante exigente. Los autores toman un artículo científico y el código que sus creadores publicaron en abierto, y eliminan del repositorio justo el código que implementa la contribución del trabajo. La parte retirada se convierte en la referencia humana: el listón no lo marca un umbral abstracto, sino lo que realmente idearon los investigadores.

El agente recibe un repositorio funcional sin la pieza clave y debe reconstruirla o superarla. Las tareas abarcan 13 dominios: sistemas de machine learning, computación de alto rendimiento, bases de datos, seguridad, robótica y otros. Además de las 48 tareas publicadas, FrontierCS 2 cuenta con un conjunto cerrado de más de 100 tareas que se anunciará más adelante. Es una protección contra el sobreajuste al benchmark público: lo que el agente no ha visto no se puede afinar de antemano.

Un entorno de investigación en lugar de un único intento

Los benchmarks abiertos anteriores solían entregar al agente el enunciado de la tarea y evaluaban un solo programa al terminar la ejecución. FrontierCS 2 cambia el formato: el agente trabaja dentro de un entorno de investigación y puede enviar un parche en cualquier momento. Por cada parche, el juez devuelve una puntuación sobre el conjunto de desarrollo (development), una señal con la que se puede mejorar la solución de forma iterativa, como hace una persona.

El propio evaluador, el conjunto final de pruebas reservado y la solución de referencia siguen cerrados. El envío final se comprueba en un conjunto oculto y se compara con la referencia. El agente puede ajustar la solución a la métrica visible, pero se le evaluará con datos que no ha observado.

Una puntuación alta no es un aprobado

Lo más interesante de los resultados está en la diferencia entre puntuación y aprobado, más que en la cifra del 58%. La mayoría de las ejecuciones que superaron a la referencia en la puntuación final total no aprobaron igualmente: fallaron en una métrica concreta o en una carga de trabajo concreta. En el trabajo con sistemas es una situación típica. Una optimización de una base de datos o de un kernel de HPC que acelera un escenario y rompe otro no sirve en producción, y el benchmark lo tiene en cuenta.

Los autores también construyeron una escala común de capacidades para agentes y tareas. La tarea mediana resultó tener una dificultad similar a la que puede resolver el agente más potente. El conjunto no es demasiado fácil, porque entonces los resultados chocarían con el techo, ni inalcanzable de antemano. Deja margen para medir el progreso de los próximos modelos.

Parámetros clave

• 48 tareas abiertas en 13 dominios, más un conjunto cerrado de más de 100 tareas
• 12 agentes evaluados
• Mejor resultado: Claude Opus 5.5, con un 58% de ejecuciones aprobadas
• 16 tareas en las que no aprobó ninguna ejecución
• El agente puede enviar parches en cualquier momento y recibe una puntuación sobre el conjunto de desarrollo
• El evaluador, el conjunto final de pruebas y la referencia están ocultos para el agente

Qué deben mirar los equipos que construyen agentes

Para quienes desarrollan agentes de programación y pipelines de investigación, el benchmark deja tres conclusiones prácticas. Primera: hay que evaluar con un conjunto de métricas y cargas de trabajo, no con un único número agregado, porque la mejora media oculta regresiones. Segunda: conviene comprobar por separado la capacidad de iterar con la retroalimentación del conjunto de desarrollo y de mantenerse en pie en el conjunto oculto, porque ahí es donde un agente se distingue de un generador de código. Tercera: el fracaso en 16 tareas muestra dónde está el techo. Son tareas que exigen, además de habilidades de programación, intuición investigadora, y el conjunto cerrado permitirá ver si esa intuición avanza en las próximas generaciones de modelos.