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

Cet article analyse les défis de reproductibilité rencontrés lors de la tentative de reproduire les résultats d'un cadre d'apprentissage automatique de premier plan en science des matériaux, en identifiant quatre catégories clés de problèmes liés aux dépendances, au versionnage, à l'organisation du code et aux références manuscrites, et propose des solutions concrètes pour améliorer l'accessibilité et l'utilité du code pour la communauté de recherche.

L'essentiel

Imaginez que vous et un ami tentiez de préparer le gâteau le plus délicieux du monde. Votre ami, un boulanger célèbre, a publié un livre de recettes intitulé « Comment faire le gâteau parfait ». Il y a inclus une liste d'ingrédients, une photo du gâteau fini et quelques notes sur la manière de le mélanger. Vous décidez d'essayer de le faire vous-même pour voir s'il est aussi bon qu'ils le disent.

Cependant, lorsque vous commencez à cuisiner, vous vous heurtez à un mur. Voici ce qui s'est produit, d'après l'histoire racontée dans cet article :

Les Cartes de Recette Manquantes

Le boulanger célèbre vous a remis un « Script de Construction de Modèle », qui ressemble à une carte d'instruction de base sur la façon de mélanger la pâte. Mais la partie du livre montrant comment transformer cette pâte en gâteau final spécifique (l'« analyse d'extensibilité ») était complètement absente. Vous avez dû deviner comment terminer la recette en vous basant uniquement sur les descriptions vagues du livre.

Le Four Cassé (Dépendances)

Même lorsque vous avez essayé de suivre les instructions de base, vous avez découvert que le four nécessitait un type de gaz très spécifique et ancien qui n'existe plus. La recette disait : « Utilisez le Gaz Type 7 », mais ce gaz est discontinué et dangereux. Vous avez dû chasser un gaz légèrement différent (Type 8) pour faire fonctionner le four du tout. C'est ce que l'article appelle un « problème de dépendance » : les outils nécessaires pour exécuter le code sont obsolètes ou difficiles à trouver.

L'Ingrédient Secret (Aléatoire)

Une fois que vous avez enfin fait fonctionner le four et cuit le gâteau, il n'avait pas le bon goût. Le gâteau du boulanger était sucré et moelleux ; le vôtre était un peu dense. Vous avez essayé de le cuire dix fois de plus, sans rien changer sauf le moment exact où vous avez allumé le four (la « graine aléatoire »). À chaque fois, le gâteau s'est révélé légèrement différent.

L'article a découvert que le boulanger n'avait jamais noté quel moment précis il avait allumé le four. Sans ce détail minuscule, vous ne pourrez jamais recréer parfaitement leur gâteau. Dans le monde de l'informatique, cela signifie que même si vous avez le même code et les mêmes données, le « lancer de dés » interne de l'ordinateur peut modifier le résultat, rendant impossible l'obtention de la réponse exacte sans un enregistrement de ce lancer.

La Cible Mobile (Contrôle de Version)

Le boulanger a admis plus tard qu'il était encore en train d'ajuster ses outils de cuisine pendant qu'il écrivait le livre. Les outils qu'il a utilisés pour cuire le gâteau sur la photo pouvaient être différents de ceux qu'il vous a donnés dans la boîte. Comme il n'a pas tenu un journal de la version des outils utilisée quel jour, vous ne pouvez pas savoir si votre échec est dû à une erreur de votre part ou parce que ses outils ont changé.

Les Quatre Règles pour de Meilleures Recettes

Les auteurs de cet article suggèrent quatre règles simples pour éviter que cela ne se reproduise à l'avenir, en utilisant une analogie de « livre de recettes » :

1. Listez les Outils Exacts : Ne dites pas simplement « utilisez un four ». Dites « utilisez un modèle 2024 avec un adaptateur de gaz spécifique ». Si vous ne pouvez pas le faire, mettez toute la cuisine dans une boîte scellée (comme un « conteneur Docker ») afin que n'importe qui puisse l'ouvrir et utiliser exactement la même configuration.
2. Tenez un Journal de Version : Tenez un journal de chaque changement apporté à vos outils. Si vous changez un fouet ou un réglage du four, notez-le. De cette façon, si le gâteau a un goût différent plus tard, vous saurez exactement quel changement en est la cause.
3. Découpez la Recette en Étapes : Au lieu d'un seul paragraphe géant et confus d'instructions, décomposez la recette en petites étapes claires : « Étape 1 : Mélanger les œufs », « Étape 2 : Ajouter la farine ». Cela rend plus facile pour quiconque de suivre et de vérifier son travail à chaque étape.
4. Liez les Notes aux Étapes : Dans le livre, lorsque le boulanger dit « mélanger vigoureusement », placez un lien cliquable juste là qui vous amène directement à la ligne de code exacte où ce mélange se produit. Cela relie l'histoire au travail réel.

L'Essentiel

L'article conclut que, bien que le cadre original fût une excellente idée et ait aidé le domaine de la science des matériaux, l'absence de ces détails simples de « recette » a rendu impossible pour les autres de copier parfaitement les résultats. En suivant ces quatre règles, les scientifiques peuvent s'assurer que, lorsqu'ils partagent leurs découvertes, les autres peuvent réellement les construire sans se perdre dans un labyrinthe d'instructions manquantes et d'outils défectueux.

Résumé technique

Résumé technique : Reproductibilité en science computationnelle des matériaux

Énoncé du problème
Malgré l'intégration rapide de l'apprentissage automatique (ML) dans la découverte de matériaux et la tendance concomitante vers des données open source, un obstacle majeur persiste : l'absence de pratiques reproductibles parmi les développeurs d'outils. Cette étude examine les défis spécifiques rencontrés lors de la tentative de reproduire les résultats d'un travail fondateur, « A general-purpose machine learning framework for predicting properties of inorganic materials » de Ward et al. (2016). Bien que les auteurs originaux aient fourni les données brutes et un script pour la construction du modèle, les informations complémentaires (IC) étaient incomplètes. Plus précisément, les scripts requis pour l'« analyse d'extensibilité » — l'application pratique du cadre pour identifier de nouveaux matériaux de cellules solaires — étaient absents. De plus, la documentation fournie contenait des exigences de dépendance trompeuses, et la base de code manquait de contrôle de version, rendant impossible de déterminer si le logiciel distribué correspondait à la version utilisée pour générer les résultats originaux.

Méthodologie
Les auteurs ont tenté de reproduire la partie « analyse d'extensibilité » de l'étude de Ward et al., qui consistait à identifier de nouveaux composés ternaires avec des bandes interdites adaptées aux cellules solaires. La méthodologie comprenait :

1. Reconstruction de l'environnement : Tentative d'installation du logiciel Magpie (un générateur de descripteurs basé sur Java) et de ses dépendances. Les auteurs ont rencontré une incompatibilité entre l'exigence de Java 7 documentée et les versions modernes de Java, nécessitant l'utilisation de Java 8.
2. Recréation des scripts : Les scripts d'analyse d'extensibilité étant absents des IC, les auteurs les ont reconstitués à partir de descriptions imprécises dans le manuscrit et en consultant un auteur original.
3. Traitement des données : Les auteurs ont utilisé l'ensemble de données d'entraînement fourni (OQMD v1.0, ~300 000 composés) et ont traité les cinq composés candidats spécifiques listés dans le Tableau 1 du document original comme ensemble de test, les données de l'espace de recherche original n'étant pas disponibles.
4. Répétition et tests de sensibilité : Les auteurs ont réentraîné les modèles hiérarchiques REPTree en utilisant les scripts reconstitués. Pour investiguer les écarts entre leurs résultats et les prédictions originales, ils ont effectué un test de stabilité de la graine aléatoire, générant dix modèles avec différentes graines aléatoires (incluant la graine Weka par défaut) afin d'évaluer la sensibilité des prédictions à l'initialisation.

Résultats clés
L'effort de réplication a révélé que les résultats originaux ne pouvaient pas être reproduits :

• Déviation des prédictions : Les énergies de bande interdite prédites par les modèles répliqués s'écartaient significativement des valeurs rapportées dans l'article original.
• Sensibilité à la graine aléatoire : Le test de stabilité de la graine aléatoire a démontré que les prédictions étaient hautement sensibles à la graine aléatoire. Les prédictions originales se situaient en dehors de la distribution des prédictions répliquées pour plusieurs composés (par exemple Hf4S11Cl2), et dans certains cas, les valeurs originales se trouvaient à l'extrémité de la distribution ou totalement en dehors de l'étendue.
• Analyse des causes racines : L'impossibilité de reproduire les résultats a été attribuée à l'absence de graine aléatoire enregistrée, à l'absence de données intermédiaires (descripteurs, modèles) pour validation, et à la probabilité que la base de code Magpie soit en développement actif pendant l'exécution de l'étude originale. La version du logiciel fournie dans les IC différait probablement de celle utilisée pour générer les résultats publiés.

Contributions clés et recommandations
Sur la base de ces constatations, l'article propose quatre actions concrètes pour améliorer la reproductibilité des futurs outils open source en informatique des matériaux :

1. Diffuser les dépendances : Les développeurs doivent aller au-delà des listes de dépendances basées sur le texte. Les auteurs recommandent des stratégies de conteneurisation (par exemple Docker ou Singularity) pour encapsuler l'environnement computationnel, garantissant que les dépendances logicielles restent compatibles et accessibles au fil du temps.
2. Maintenir et suivre les versions : L'étude souligne la nécessité d'un contrôle de version rigoureux (par exemple Git) et d'un suivi des opérations d'apprentissage automatique (MLOps) (par exemple MLFlow). Ces outils permettent l'enregistrement systématique des versions de code, des paramètres et des métriques, assurant la traçabilité de la lignée des modèles et la capacité de revenir à des états expérimentaux spécifiques.
3. Utiliser des pratiques de codage séquentielles : Au lieu de scripts d'entrée monolithiques et complexes, les développeurs devraient adopter des pratiques de codage séquentielles, telles que les notebooks Jupyter. Décomposer les flux de travail en cellules discrètes et autonomes avec du markdown descriptif améliore la clarté, réduit la courbe d'apprentissage et permet aux utilisateurs de valider les sorties à des points de contrôle distincts.
4. Améliorer la clarté du code dans les manuscrits : Les auteurs suggèrent d'intégrer des liens cliquables dans le texte du manuscrit qui pointent directement vers des fichiers spécifiques ou des lignes de code dans le dépôt. Cela comble le fossé entre la méthodologie écrite et l'implémentation pratique, réduisant l'ambiguïté.

Signification
L'article conclut que, bien que le cadre proposé par Ward et al. ait démontré avec succès une approche généralisée de l'informatique des matériaux, l'étude sert de leçon de prudence : la reproductibilité exige un effort délibéré et structuré. Sans mesures proactives concernant la gestion des dépendances, le suivi des versions et l'organisation du code, même les initiatives de science ouverte les mieux intentionnées peuvent échouer à être reproductibles. En adoptant les pratiques recommandées, la communauté peut favoriser une plus grande confiance, une transparence accrue et une facilité d'adoption pour les outils de recherche en science computationnelle des matériaux.