Reproducibility in Computational Materials Science: Lessons from 'A General-Purpose Machine Learning Framework for Predicting Properties of Inorganic Materials'

Este artículo analiza los desafíos de reproducibilidad encontrados al intentar replicar resultados de un marco de aprendizaje automático destacado en ciencia de materiales, identificando cuatro categorías clave de problemas relacionados con dependencias, versionado, organización del código y referencias del manuscrito, y propone soluciones accionables para mejorar la accesibilidad y utilidad del código para la comunidad investigadora.

Lo esencial

Imagina que tú y un amigo intentan hornear el pastel más delicioso del mundo. Tu amigo, un panadero famoso, publicó un libro de recetas titulado "Cómo hacer el pastel perfecto". Incluyó una lista de ingredientes, una foto del pastel terminado y algunas notas sobre cómo mezclarlo. Decides intentar hacerlo tú mismo para ver si sabe tan bien como dicen.

Sin embargo, cuando empiezas a cocinar, te topas con un muro. Esto es lo que sucedió, basado en la historia de este documento:

Las tarjetas de receta faltantes

El panadero famoso te dio un "Script de construcción de modelos", que es como una tarjeta de instrucciones básica sobre cómo mezclar la masa. Pero la parte del libro que mostraba cómo tomar esa masa y hornear el pastel final específico (el "análisis de extensibilidad") estaba completamente ausente. Tuviste que adivinar cómo terminar la receta solo leyendo las descripciones vagas del libro.

El horno roto (dependencias)

Incluso cuando intentaste seguir las instrucciones básicas, descubriste que el horno requería un tipo de gas muy específico y antiguo que ya no existe. La receta decía: "Usa Gas Tipo 7", pero ese gas está discontinuado y es inseguro. Tuviste que buscar un gas ligeramente diferente (Tipo 8) para que el horno funcionara en absoluto. Esto es lo que el documento llama un "problema de dependencia": las herramientas necesarias para ejecutar el código están desactualizadas o son difíciles de encontrar.

El ingrediente secreto (aleatoriedad)

Una vez que finalmente hiciste funcionar el horno y horneaste el pastel, no sabía bien. El pastel del panadero era dulce y esponjoso; el tuyo estaba un poco denso. Intentaste hornearlo diez veces más, sin cambiar nada excepto el momento exacto en que encendiste el horno (la "semilla aleatoria"). Cada vez, el pastel resultó ligeramente diferente.

El documento descubrió que el panadero nunca escribió cuál momento específico encendieron el horno. Sin ese pequeño detalle, nunca puedes recrear perfectamente su pastel. En el mundo de la informática, esto significa que incluso si tienes el mismo código y datos, el "lanzamiento de dados" interno de la computadora puede cambiar el resultado, haciendo imposible obtener exactamente la misma respuesta sin un registro de ese lanzamiento.

El objetivo móvil (control de versiones)

El panadero admitió más tarde que aún estaba ajustando sus utensilios de cocina mientras escribía el libro. Las herramientas que usó para hornear el pastel de la foto podrían haber sido diferentes de las herramientas que te entregó en la caja. Como no mantuvieron un diario de qué versión de las herramientas usaron qué día, no puedes saber si tu fracaso se debe a que hiciste algo mal o porque sus herramientas cambiaron.

Las cuatro reglas para mejores recetas

Los autores de este documento sugieren cuatro reglas simples para evitar que esto suceda en el futuro, utilizando una analogía de "libro de recetas":

1. Lista las herramientas exactas: No digas solo "usa un horno". Di "usa un modelo de 2024 con un adaptador de gas específico". Si no puedes hacerlo, pon toda la cocina en una caja sellada (como un "contenedor Docker") para que cualquiera pueda abrirla y usar exactamente la misma configuración.
2. Mantén un registro de versiones: Lleva un diario de cada cambio que hagas en tus herramientas. Si cambias un batidor o una configuración del horno, anótalo. De esta manera, si el pastel sabe diferente más tarde, sabrás exactamente qué cambio lo causó.
3. Divide la receta en pasos: En lugar de un solo párrafo gigante y confuso de instrucciones, divide la receta en pasos pequeños y claros: "Paso 1: Mezclar huevos", "Paso 2: Añadir harina". Esto hace que sea más fácil para cualquiera seguir y verificar su trabajo en cada etapa.
4. Vincula las notas con los pasos: En el libro, cuando el panadero dice "mezclar vigorosamente", coloca un enlace clicable justo allí que te lleve a la línea exacta del código donde ocurre esa mezcla. Esto conecta la historia con el trabajo real.

La conclusión

El documento concluye que, aunque el marco original fue una gran idea y ayudó al campo de la ciencia de materiales, la falta de estos detalles simples de "receta" hizo imposible que otros copiaran perfectamente los resultados. Siguiendo estas cuatro reglas, los científicos pueden asegurar que, cuando compartan sus descubrimientos, otros realmente puedan construir sobre ellos sin perderse en un laberinto de instrucciones faltantes y herramientas rotas.

Resumen técnico

Resumen Técnico: Reproducibilidad en la Ciencia Computacional de Materiales

Enunciado del Problema
A pesar de la rápida integración del aprendizaje automático (ML) en el descubrimiento de materiales y la tendencia concurrente hacia datos de código abierto, persiste una barrera significativa: la falta de prácticas reproducibles entre los desarrolladores de herramientas. Este estudio investiga los desafíos específicos encontrados al intentar reproducir resultados de un trabajo seminal, "A general-purpose machine learning framework for predicting properties of inorganic materials" de Ward et al. (2016). Aunque los autores originales proporcionaron datos crudos y un script para la construcción del modelo, la información suplementaria (SI) estaba incompleta. Específicamente, faltaban los scripts requeridos para el "análisis de extensibilidad"—la aplicación práctica del marco para identificar nuevos materiales para celdas solares. Además, la documentación proporcionada contenía requisitos de dependencias engañosos, y la base de código carecía de control de versiones, lo que hacía imposible determinar si el software distribuido coincidía con la versión utilizada para generar los resultados originales.

Metodología
Los autores intentaron replicar la parte del "análisis de extensibilidad" del estudio de Ward et al., que implicaba identificar nuevos compuestos ternarios con bandgaps adecuados para celdas solares. La metodología involucró:

1. Reconstrucción del Entorno: Intentar instalar el software Magpie (un generador de descriptores basado en Java) y sus dependencias. Los autores encontraron incompatibilidad entre el requisito documentado de Java 7 y las versiones modernas de Java, lo que hizo necesario el uso de Java 8.
2. Recreación de Scripts: Dado que los scripts del análisis de extensibilidad estaban ausentes en la SI, los autores los reconstruyeron basándose en descripciones imprecisas en el manuscrito y consultando con un autor original.
3. Manejo de Datos: Los autores utilizaron el conjunto de entrenamiento proporcionado (OQMD v1.0, ~300,000 compuestos) y trataron los cinco compuestos candidatos específicos listados en la Tabla 1 del artículo original como el conjunto de prueba, ya que los datos del espacio de búsqueda original no estaban disponibles.
4. Replicación y Pruebas de Sensibilidad: Los autores reentrenaron los modelos jerárquicos REPTree utilizando los scripts reconstruidos. Para investigar las discrepancias entre sus resultados y las predicciones originales, realizaron una prueba de estabilidad de la semilla aleatoria, generando diez modelos con diferentes semillas aleatorias (incluida la semilla predeterminada de Weka) para evaluar la sensibilidad de las predicciones a la inicialización.

Resultados Clave
El esfuerzo de replicación reveló que los resultados originales no podían reproducirse:

• Desviación de Predicción: Las energías de bandgap predichas por los modelos replicados se desviaron significativamente de los valores reportados en el artículo original.
• Sensibilidad a la Semilla Aleatoria: La prueba de estabilidad de la semilla aleatoria demostró que las predicciones eran altamente sensibles a la semilla aleatoria. Las predicciones originales cayeron fuera de la distribución de las predicciones replicadas para varios compuestos (por ejemplo, Hf4S11Cl2), y en algunos casos, los valores originales se encontraban en la cola extrema de la distribución o fuera de la dispersión por completo.
• Análisis de la Causa Raíz: La incapacidad de replicar se atribuyó a la falta de una semilla aleatoria registrada, la ausencia de datos intermedios (descriptores, modelos) para validación, y la probabilidad de que la base de código de Magpie estuviera en desarrollo activo durante la ejecución del estudio original. La versión del software proporcionada en la SI probablemente difería de la versión utilizada para generar los resultados publicados.

Contribuciones y Recomendaciones Clave
Basándose en estos hallazgos, el artículo propone cuatro elementos de acción tangibles para mejorar la reproducibilidad de futuras herramientas de código abierto en la informática de materiales:

1. Difundir Dependencias: Los desarrolladores deben ir más allá de las listas de dependencias basadas en texto. Los autores recomiendan estrategias de contenedorización (por ejemplo, Docker o Singularity) para encapsular el entorno computacional, asegurando que las dependencias de software permanezcan compatibles y accesibles con el tiempo.
2. Mantener y Rastrear Versiones: El estudio destaca la necesidad de un control de versiones riguroso (por ejemplo, Git) y el seguimiento de Operaciones de Aprendizaje Automático (MLOps) (por ejemplo, MLFlow). Estas herramientas permiten el registro sistemático de versiones de código, parámetros y métricas, asegurando la trazabilidad del linaje del modelo y la capacidad de revertir a estados experimentales específicos.
3. Utilizar Prácticas de Codificación Secuencial: En lugar de scripts de entrada monolíticos y complejos, los desarrolladores deben adoptar prácticas de codificación secuencial, como cuadernos Jupyter. Dividir los flujos de trabajo en celdas discretas y autocontenidas con markdown descriptivo mejora la claridad, reduce la curva de aprendizaje y permite a los usuarios validar salidas en puntos de control distintos.
4. Mejorar la Claridad del Código en los Manuscritos: Los autores sugieren incorporar punteros clicables dentro del texto del manuscrito que enlacen directamente a archivos específicos o líneas de código en el repositorio. Esto cierra la brecha entre la metodología escrita y la implementación práctica, reduciendo la ambigüedad.

Significado
El artículo concluye que, aunque el marco propuesto por Ward et al. demostró exitosamente un enfoque generalizado para la informática de materiales, el estudio sirve como una lección de advertencia: la reproducibilidad requiere un esfuerzo deliberado y estructurado. Sin medidas proactivas en cuanto a la gestión de dependencias, el seguimiento de versiones y la organización del código, incluso las iniciativas de ciencia abierta bien intencionadas pueden fallar en ser reproducibles. Al adoptar las prácticas recomendadas, la comunidad puede fomentar una mayor confianza, transparencia y facilidad de adopción para las herramientas de investigación en ciencia computacional de materiales.