Investigación ReproRepo: auditoría masiva de reproducibilidad usando issues de GitHub
Un nuevo marco, ReproRepo, convierte los issues de GitHub en datos de entrenamiento para evaluar agentes LLM en la detección estática de bloqueos de reproducibilidad en 1.149 papers de ML.
Reproducir los resultados de un artículo científico sigue siendo una tarea costosa. La mayoría de los benchmarks existentes requieren que expertos redacten preguntas, inyecten errores o revisen manualmente cada caso, lo que limita su alcance a unas pocas docenas de papers. El estudio presentado por Shanda Li y colaboradores propone ReproRepo, una infraestructura que extrae de forma automática los problemas reportados por usuarios en los issues de GitHub asociados a los repositorios de código de los artículos. Cada issue se trata como una evidencia real de un bloqueo de reproducibilidad, con su estado (abierto o cerrado), timestamps y, cuando está disponible, los commits de solución.
El proceso de construcción de datos parte de los papers aceptados en conferencias principales de machine learning (NeurIPS 2022, NeurIPS 2024 y ICLR 2026). Para cada paper se localiza el enlace al repositorio en GitHub, se descartan los que no disponen de código y se recolectan todos los issues relacionados. Un modelo de LLM actúa como filtro para eliminar los que no describen un problema de reproducibilidad. Luego se generan instantáneas del código: para issues abiertos se toma la rama principal en el momento de la recolección; para issues cerrados se usa el estado del repositorio justo antes de la apertura del issue, garantizando que el agente solo vea la versión que el usuario había encontrado.
Con este benchmark, los autores evalúan cuatro configuraciones de agentes LLM (Claude Code + DeepSeek‑V4‑Pro, Claude Code + Claude Opus 4.7, Codex + GPT‑5.4‑Mini y Codex + GPT‑5.5). Los agentes trabajan en modo estático: inspeccionan el PDF del paper y la instantánea del repositorio sin ejecutar código ni acceder a internet. Cada agente genera una lista ordenada de posibles bloqueos, simulando cómo un usuario redactaría un issue. La salida se compara con los issues ocultos mediante un juez LLM que clasifica cada coincidencia como "exact match", "semantic match" o "none".
Los resultados revelan que, aun sin ejecutar el código, los agentes pueden identificar al menos un problema semánticamente relacionado en cerca del 90 % de los papers. El mejor desempeño lo alcanza Codex con GPT‑5.5, que logra una tasa de coincidencia semántica de 89.7 % a nivel de paper y una coincidencia exacta de 59.7 %. Los modelos más económicos, como DeepSeek‑V4‑Pro, obtienen resultados similares en coincidencia semántica (≈89 %) pero a un costo de token apenas el 23 % del más caro, lo que los hace atractivos para etapas de triage a gran escala.
El análisis muestra que los agentes son especialmente buenos detectando fallos visibles (por ejemplo, scripts faltantes, imports rotos o configuraciones incorrectas) y en localizar la región semántica del problema, pero tienen dificultades para pinpointar la causa exacta o errores que sólo aparecen en ejecución tardía. Las categorías de fallo más comunes son "silent wrong setup" y "crash immediate", mientras que "silent wrong number" y "crash late" resultan menos recuperables con auditoría estática.
ReproRepo también incluye métricas de falsos positivos al probar los agentes sobre instantáneas post‑fix de los issues cerrados. La tasa de falsos positivos se mantiene bajo (máximo 3.5 %), lo que indica que los hallazgos no son meras alertas genéricas sino reflejos de evidencias estáticas reales.
Para las organizaciones que dependen de repositorios externos para reproducir investigaciones, el marco aporta dos ventajas operativas claras: primero, permite monitorear de forma continua la salud de los artefactos publicados sin necesidad de costosos procesos de ejecución; segundo, brinda una base de datos actualizable automáticamente a medida que se generan nuevos issues, reduciendo la carga de curación manual. La implementación de ReproRepo como pipeline interno puede servir para priorizar revisiones de código, asignar recursos de ingeniería a los bloqueos más críticos y, en última instancia, mejorar la confianza en los resultados reproducidos antes de invertir en entrenamientos a gran escala.
En resumen, la estrategia de convertir los issues de GitHub en supervisión natural abre una vía escalable para evaluar y mejorar la capacidad de los agentes LLM en la auditoría de reproducibilidad, aunque la precisión en la localización exacta sigue siendo un reto que necesitará modelos más avanzados o la integración de análisis de ejecución.
