Resumen Técnico: ReproScore: Separando la Preparación del Resultado en la Evaluación de la Reproducibilidad del Software de Investigación

1. Declaración del Problema

Las bibliotecas digitales (por ejemplo, Zenodo, Software Heritage) curan millones de artefactos de software de investigación, pero carecen de infraestructura escalable para evaluar si estos artefactos son realmente ejecutables. Las herramientas de evaluación automatizada existentes adolecen de un defecto crítico: confunden la preparación (completitud estática del repositorio, como la presencia de un README o un requirements.txt) con el resultado (éxito de la ejecución real).

Esta "confusión preparación–resultado" conduce a una suposición falsa de que un repositorio con documentación estática completa es probable que se ejecute. En realidad, un repositorio puede poseer señales estáticas perfectas y aún así fallar debido a conflictos de dependencias transitivas, datos inaccesibles o problemas del entorno de ejecución que el análisis estático no puede detectar. Las herramientas actuales dependen o bien del análisis estático (ignorando la ejecución) o bien requieren una ejecución costosa en entornos aislados impulsada por expertos (careciendo de escalabilidad). Existe la necesidad de un marco que distinga explícitamente entre el potencial de reproducibilidad (preparación) y el resultado real de la ejecución (resultado), proporcionando a los curadores información de diagnóstico en lugar de una predicción binaria de aprobado/reprobado.

2. Metodología: La Arquitectura de ReproScore

ReproScore es un marco de dos niveles diseñado para separar la preparación para la reproducibilidad del resultado de la ejecución, combinándolos en una puntuación compuesta adaptativa a la cobertura.

Nivel 1: Puntuación de Preparación para la Reproducibilidad (RRS)

El RRS es una métrica estática, siempre disponible, calculada mediante un análisis determinista y basado en reglas de un repositorio clonado localmente. No requiere la ejecución del código.

• Estructura: El RRS comprende 26 submétricas atómicas agrupadas en cinco categorías:
  1. Entorno (E, peso 0.30): Especificación de dependencias, contenedorización y versiones de ejecución.
  2. Datos (A, peso 0.25): Accesibilidad, punteros y métodos de adquisición para los datos de entrada.
  3. Documentación (D, peso 0.20): Presencia de instrucciones de ejecución, puntos de entrada y ejemplos de uso.
  4. Portabilidad del Código (C, peso 0.15): Ausencia de rutas absolutas, credenciales codificadas y importaciones irresolubles.
  5. Señales de Reproducibilidad (S, peso 0.10): Señales de determinismo como la gestión de semillas y el orden de ejecución.
• Lógica de Puntuación:
  • Función de Puerta: Una función de puerta de ley de potencia $g(x, \tau, k)$ penaliza las puntuaciones por debajo del umbral de forma no lineal. Las puntuaciones por debajo de un umbral $\tau$ se comprimen, reflejando una política de curación donde las deficiencias graves (por ejemplo, especificación de entorno faltante) son desproporcionadamente dañinas.
  • Penalizaciones: Se aplican penalizaciones estrictas por la ausencia completa de especificaciones de entorno o artefactos de datos ($P_{hard}$), y por operaciones estocásticas sin gestión de semillas ($P_{seed}$).
  • Fórmula: $RRS = 100 \cdot \sum (w_i \cdot g(x_i)) - \text{penalizaciones}$.

Nivel 2: Puntuación de Resultado de la Reproducibilidad (ROS)

El ROS es una métrica opcional basada en la ejecución, calculada cuando está disponible un entorno aislado (por ejemplo, repo2docker, nbconvert).

• Componentes: Agrega hasta seis sondas: Éxito de instalación ($I$), Éxito de ejecución ($X$), Determinismo de salida ($\Delta$), Tasa de ejecución de cuadernos ($N$), Tasa de éxito de importación ($E'$) y Tasa de aprobación de pruebas ($T$).
• Normalización: El ROS es una suma ponderada de los componentes disponibles, lo que permite calcular la puntuación incluso si solo están disponibles datos de ejecución parciales.

Puntuación Compuesta (RCS)

La Puntuación Compuesta ReproScore (RCS) combina el RRS y el ROS basándose en la cantidad de evidencia de ejecución recopilada.

• Peso de Cobertura ($\alpha$): Un parámetro que escala desde 0 (sin ejecución) hasta un máximo de 0.70. Asegura que la preparación estática nunca sea dominada completamente por los resultados de la ejecución, reconociendo que una ejecución exitosa no valida la documentación ni la portabilidad.
• Fórmula: $RCS = (1 - \alpha) \cdot RRS + \alpha \cdot ROS$. Si no existen datos de ejecución, $RCS = RRS$.

Mecanismo de Rúbrica Comunitaria

ReproScore externaliza las prioridades de evaluación mediante un perfil YAML versionado. Esto permite que diferentes comunidades (por ejemplo, bioinformática frente a software general) anulen los pesos y umbrales de puerta predeterminados sin modificar el código fuente. Esto hace que las políticas de curación sean explícitas, auditables y portátiles entre instituciones.

3. Contribuciones Clave

1. Separación Conceptual: Una arquitectura formal de dos niveles (RRS/ROS/RCS) que desacopla la preparación estática del resultado de la ejecución, abordando la confusión preparación–resultado en los flujos de trabajo de las bibliotecas digitales.
2. Modelo de Preparación: Un modelo de 5 categorías y 26 submétricas (RRS) con pesos informados por expertos, enrutamiento no lineal y procedencia de evidencia a nivel de archivo.
3. Mecanismo de Gobernanza: Un sistema de rúbrica comunitaria que permite definir las prioridades de evaluación como artefactos citables y versionados.
4. Validación Empírica: Una evaluación en 423 repositorios de GitHub (Python/Jupyter) que demuestra que la preparación estática discrimina fuertemente entre modos de fallo, pero exhibe una correlación cercana a cero con el éxito de ejecución binario.

4. Resultados de la Evaluación

El marco se evaluó en una muestra estratificada de 423 repositorios de un corpus de verdad fundamental, categorizados en cinco modos de fallo: Éxito, Errores de Dependencia de Instalación, Módulos Faltantes, Datos Faltantes y Errores de Código.

• Discriminación de Modos de Fallo: La categoría Entorno (E) mostró la mayor capacidad para discriminar entre modos de fallo (Kruskal-Wallis $H = 96.89, p < 0.001$).
  • La Paradoja de la Detección: Los repositorios con errores de dependencia de instalación (install_dep) obtuvieron las puntuaciones más altas en Entorno (media 22.8) porque especificaban explícitamente los entornos, sin embargo, fallaron debido a conflictos de versiones. Por el contrario, los repositorios exitosos obtuvieron puntuaciones más bajas (media 10.3) porque a menudo carecían de especificaciones explícitas. Esto confirma que el RRS caracteriza qué tipo de problema existe, no si tendrá éxito.
• Correlación Binaria: La correlación entre el RRS y el éxito de ejecución binario fue cercana a cero ($r_{pb} = -0.014$). Esto cuantifica empíricamente la brecha preparación–resultado: una puntuación estática alta no predice una ejecución exitosa.
• Robustez:
  • Estabilidad de Pesos: Las clasificaciones de los repositorios permanecieron estables ($\tau \ge 0.911$) incluso cuando los pesos se perturbaban en $\pm 50\%$.
  • Insensibilidad de la Puerta: La función de puerta tuvo un impacto negligible en la predicción binaria (rango AUC $\approx 0.008$), confirmando su papel como herramienta de política normativa en lugar de un mecanismo predictivo.
  • Dejar Una Categoría Fuera: Eliminar las categorías Entorno o Datos en realidad mejoró el AUC binario, demostrando aún más que estas categorías están diseñadas para caracterizar tipos de fallo, no para predecir el éxito binario.
• Validación Compuesta: En la validación parcial del ROS, el RCS reordenó correctamente los repositorios. Por ejemplo, los repositorios install_dep tuvieron un RRS moderado (26.8) pero un ROS cercano a cero (13.5), resultando en un RCS bajo (19.8), reflejando con precisión su fallo de ejecución a pesar de la completitud estática.

5. Significado y Afirmaciones

El artículo posiciona a ReproScore como un instrumento de diagnóstico para los curadores de bibliotecas digitales en lugar de un predictor binario de éxito.

• Necesidad Arquitectónica: El estudio valida que separar la preparación del resultado es tanto necesario como no trivial. Las señales estáticas capturan diferencias estructurales significativas (por ejemplo, distinguir un módulo faltante de un conflicto de versiones) que las métricas de éxito binario oscurecen.
• Utilidad Curatorial: Al proporcionar un perfil a nivel de categoría, ReproScore permite una remediación dirigida. Una puntuación baja en Entorno sugiere que se necesita fijación de dependencias; una puntuación baja en Datos sugiere punteros faltantes. Esto es más accionable que una sola puntuación de "reproducibilidad".
• Escalabilidad: El enfoque estático primero (RRS) permite a las bibliotecas triar millones de depósitos sin el costo computacional de la ejecución en entornos aislados, reservando los recursos de ejecución para artefactos que muestran promesa o requieren validación específica.
• Transparencia de Políticas: El mecanismo de rúbrica comunitaria transforma las heurísticas de puntuación de código opaco en políticas auditables y citables, facilitando la comparación interinstitucional y la adaptación específica de dominio (por ejemplo, priorizando la accesibilidad de datos en bioinformática).

Los autores concluyen que un marco que nombra explícitamente la brecha entre la preparación y el resultado es más informativo para los flujos de trabajo de curación que uno que los colapsa. ReproScore proporciona la infraestructura para gestionar esta brecha, apoyando a las entidades de Ingesta y Almacenamiento Archivístico del OAIS con métricas computables y escalables.