RECLAIM mide si los agentes de IA pueden reproducir resultados de investigación

Una prueba de reproducción, no una tarea de programación aislada

RECLAIM es un benchmark diseñado para medir si un agente de inteligencia artificial puede reproducir un resultado concreto descrito en un artículo de aprendizaje automático. El preprint presenta un conjunto de 100 artículos de NeurIPS 2025 y plantea una tarea por artículo: el agente debe trabajar con el texto del artículo y los materiales que hayan publicado sus autores, dentro de un presupuesto de horas de GPU fijado de antemano.

La diferencia con una prueba de programación convencional es el alcance del trabajo. Para llegar a un resultado, un agente puede tener que instalar software, resolver errores, entender el método, ejecutar experimentos y comprobar sus resultados. La evaluación intenta abarcar esa cadena de tareas, no solo determinar si el sistema genera código que parece correcto.

El planteamiento también fija por adelantado qué resultado se debe reproducir y qué condiciones cuentan como éxito. Es una decisión importante: sin un objetivo definido previamente, comparar agentes podría depender de valoraciones distintas sobre qué constituye una reproducción satisfactoria. El resumen del preprint no detalla las reglas exactas usadas para cada artículo, por lo que no permite reconstruir cómo se tradujo ese criterio a todos los casos.

Tres niveles según lo que hayan publicado los autores

RECLAIM clasifica las tareas por la disponibilidad de recursos. En el nivel Run están disponibles el código, los datos y los pesos del modelo. En Retrain faltan los pesos, de modo que el agente debe entrenar el modelo. En Reimplement no se dispone del código y el agente debe escribir una implementación. Según el preprint, es el material liberado por los autores el que determina el nivel de dificultad.

La clasificación ayuda a interpretar los resultados: no todas las tareas comienzan desde el mismo punto. Ejecutar un sistema ya preparado, reconstruir sus pesos mediante entrenamiento y volver a implementar un método exigen trabajos distintos. Por eso, una tasa de éxito conjunta sin separar niveles ocultaría diferencias relevantes.

La clasificación tampoco significa que cada tarea de un nivel tenga idénticas necesidades. Los artículos pueden plantear métodos y experimentos diferentes. El resumen disponible no enumera los recursos de cada uno ni indica cuánto varían sus requisitos; por tanto, los niveles describen la disponibilidad de ciertos materiales, no una equivalencia perfecta de dificultad.

Los resultados muestran una brecha entre los niveles

El preprint informa que se probaron cuatro agentes, una vez por artículo. El mejor agente de cada nivel reprodujo el 41 % de los artículos Run, el 27 % de los Retrain y el 15 % de los Reimplement. En ese conjunto y bajo el procedimiento descrito, el éxito disminuyó a medida que se retiraban recursos necesarios para reconstruir el sistema.

Estas cifras son resultados del benchmark, no una medida universal de la capacidad de cualquier agente. Tampoco deben leerse como una comparación directa entre agentes sin más información: el resumen identifica el mejor resultado por nivel, pero no proporciona los nombres de los cuatro sistemas, sus puntuaciones individuales ni detalles suficientes para reconstruir la variabilidad de los intentos.

El trabajo informa además que los intentos fallidos consumieron, en promedio, el 29 % del presupuesto asignado. La interpretación que propone el preprint es que muchos agentes terminaron con presupuesto todavía disponible. El dato sugiere que el límite de cómputo no explica por sí solo todos los fallos; no demuestra por sí mismo por qué se detuvo cada intento ni qué cambio habría bastado para lograr la reproducción.

Otro error frecuente fue implementar el método sin contrastar ninguna parte con los valores publicados en el artículo. El resumen lo registra en 63 de 400 ejecuciones. Esta observación apunta a una diferencia entre producir una implementación plausible y comprobarla contra evidencia: escribir el método no garantiza que el agente haya reproducido las condiciones relevantes.

Qué evalúa y qué queda fuera

RECLAIM evalúa si un agente puede alcanzar un resultado previamente seleccionado con los materiales disponibles y dentro de un presupuesto computacional. De acuerdo con el resumen, una instancia de un modelo de lenguaje distinto del agente juzga las ejecuciones a partir de los registros y las salidas, en lugar de basarse en el informe escrito por el agente. El objetivo es valorar lo que ocurrió en la ejecución, no solo lo que el sistema afirma haber hecho.

Eso delimita también el alcance de la conclusión. Reproducir un resultado concreto no verifica automáticamente todas las decisiones metodológicas de un artículo, la calidad de sus datos, la robustez de sus análisis ni la validez de sus conclusiones científicas. A la inversa, que una tarea no se complete dentro del benchmark no demuestra por sí solo que el resultado original sea incorrecto: puede haber causas técnicas, de implementación o de recursos que el resumen no desglosa.

Esta distinción importa para lectores y equipos que quieran usar el benchmark como señal de progreso. Una tasa baja puede revelar dificultades de los agentes para reconstruir experimentos con información incompleta; no debe convertirse sin evidencia adicional en un veredicto sobre el artículo evaluado.

La reproducibilidad de la evaluación también necesita detalles

Para comparar agentes de forma independiente, no basta con conocer el tamaño del benchmark y las tasas de éxito. Haría falta disponer de la selección de artículos, el resultado objetivo de cada tarea, el criterio operativo de éxito, los presupuestos concretos de GPU y las reglas de tiempo. También son relevantes los nombres y configuraciones de los agentes, las instrucciones que recibieron, los entornos, los materiales disponibles y los registros o salidas utilizados para calificar cada ejecución.

El resumen del preprint confirma que RECLAIM fija el resultado, el criterio de éxito y un presupuesto de horas de GPU para cada artículo, y que la evaluación se basa en registros y salidas. Sin embargo, la información aportada aquí no especifica los valores de esos presupuestos, el método de selección de los cien artículos, los nombres de los cuatro agentes ni si están publicados los entornos y scripts necesarios para repetir la evaluación. Esos puntos deben verificarse en el documento y sus materiales antes de hacer una comparación más detallada.

La presentación describe RECLAIM como un benchmark que puede reconstruirse cada año a partir de nuevas conferencias. Eso ofrece una posible vía para seguir cambios en la capacidad de los agentes, siempre que las futuras ediciones mantengan criterios comparables o documenten sus cambios. La comparabilidad entre años no se puede dar por supuesta si varían los artículos, los materiales o las reglas.

Una medida de capacidad, con un alcance acotado

La aportación central de RECLAIM es convertir una tarea amplia —reconstruir un resultado de investigación— en un benchmark con objetivos y recursos definidos de antemano. Sus tres niveles hacen visible cómo cambia el trabajo cuando se dispone de código, datos y pesos, cuando hay que entrenar o cuando se debe reimplementar. Los resultados publicados muestran que, en esta evaluación, la reproducción se vuelve menos frecuente en los niveles con menos recursos disponibles.

La lectura más sólida es también la más acotada: RECLAIM informa sobre el desempeño de cuatro agentes en cien tareas concretas, bajo criterios y presupuestos fijados por el benchmark. Para juzgar la amplitud de esa evidencia hacen falta los detalles completos de selección, evaluación y ejecución. Y para valorar la ciencia de los artículos se necesitan análisis distintos de la reproducción de un resultado.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.