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

Dieser Beitrag analysiert die Herausforderungen der Reproduzierbarkeit, die beim Versuch auftreten, Ergebnisse eines prominenten Frameworks für maschinelles Lernen in den Materialwissenschaften zu replizieren, identifiziert vier Hauptkategorien von Problemen im Zusammenhang mit Abhängigkeiten, Versionsverwaltung, Codeorganisation und Manuskriptreferenzen und schlägt umsetzbare Lösungen vor, um die Zugänglichkeit und Nützlichkeit des Codes für die Forschungscommunity zu verbessern.

Das Wesentliche

Stellen Sie sich vor, Sie und ein Freund versuchen, den köstlichsten Kuchen der Welt zu backen. Ihr Freund, ein berühmter Bäcker, hat ein Rezeptbuch mit dem Titel „Wie man den perfekten Kuchen backt" veröffentlicht. Darin enthalten sind eine Liste der Zutaten, ein Foto des fertigen Kuchens und einige Notizen zur Zubereitung des Teigs. Sie entscheiden sich, es selbst zu versuchen, um zu sehen, ob es wirklich so gut schmeckt, wie behauptet.

Doch sobald Sie mit dem Backen beginnen, stoßen Sie auf eine Wand. Hier ist, was passiert ist, basierend auf der Geschichte in diesem Papier:

Die fehlenden Rezeptkarten

Der berühmte Bäcker gab Ihnen ein „Modell-Building-Skript", das wie eine grundlegende Anleitungskarte zum Anrühren des Teigs ist. Doch der Teil des Buches, der zeigte, wie man aus diesem Teig den spezifischen finalen Kuchen backt (die „Erweiterbarkeitsanalyse"), fehlte vollständig. Sie mussten raten, wie man das Rezept beendet, indem Sie nur die vagen Beschreibungen im Buch lasen.

Der defekte Ofen (Abhängigkeiten)

Selbst als Sie versuchten, den grundlegenden Anweisungen zu folgen, stellten Sie fest, dass der Ofen eine sehr spezifische, antike Gasart benötigte, die es nicht mehr gibt. Das Rezept sagte: „Verwenden Sie Gas Typ 7", doch dieses Gas wurde eingestellt und ist unsicher. Sie mussten nach einer leicht anderen Gasart (Typ 8) suchen, um den Ofen überhaupt zum Laufen zu bringen. Dies ist das, was das Papier als „Abhängigkeitsproblem" bezeichnet – die Werkzeuge, die zum Ausführen des Codes benötigt werden, sind veraltet oder schwer zu finden.

Die geheime Zutat (Zufälligkeit)

Sobald Sie den Ofen endlich zum Laufen gebracht und den Kuchen gebacken hatten, schmeckte er nicht richtig. Der Kuchen des Bäckers war süß und fluffig; Ihrer war etwas dicht. Sie versuchten, ihn zehn weitere Male zu backen, wobei Sie nichts änderten außer dem exakten Moment, zu dem Sie den Ofen einschalteten (den „Zufallssamen"). Jedes Mal kam der Kuchen etwas anders heraus.

Das Papier entdeckte, dass der Bäcker nie aufschrieb, welchen spezifischen Moment er den Ofen einschaltete. Ohne dieses winzige Detail können Sie seinen Kuchen niemals perfekt nachbilden. In der Welt der Informatik bedeutet dies, dass selbst bei identischem Code und denselben Daten der interne „Würfelwurf" des Computers das Ergebnis verändern kann, was es unmöglich macht, exakt dasselbe Ergebnis zu erzielen, ohne eine Aufzeichnung dieses Wurfs zu haben.

Das sich bewegende Ziel (Versionskontrolle)

Der Bäcker gab später zu, dass er seine Küchenwerkzeuge noch während des Schreibens des Buches feilte. Die Werkzeuge, die er zum Backen des Kuchens auf dem Foto verwendete, könnten von den Werkzeugen unterschieden haben, die er Ihnen im Karton mitgab. Da er kein Tagebuch darüber führte, welche Version der Werkzeuge er an welchem Tag verwendete, können Sie nicht wissen, ob Ihr Misserfolg darauf zurückzuführen ist, dass Sie etwas falsch gemacht haben, oder weil sich seine Werkzeuge geändert haben.

Die vier Regeln für bessere Rezepte

Die Autoren dieses Papiers schlagen vier einfache Regeln vor, um dies in Zukunft zu verhindern, unter Verwendung einer Analogie zum „Rezeptbuch":

1. Listen Sie die genauen Werkzeuge auf: Sagen Sie nicht nur „Verwenden Sie einen Ofen". Sagen Sie „Verwenden Sie ein Modell von 2024 mit einem spezifischen Gasadapter". Wenn Sie das nicht können, stellen Sie die gesamte Küche in einen versiegelten Karton (wie einen „Docker-Container"), damit jeder ihn öffnen und exakt dasselbe Setup verwenden kann.
2. Führen Sie ein Versionsprotokoll: Führen Sie ein Tagebuch über jede Änderung, die Sie an Ihren Werkzeugen vornehmen. Wenn Sie einen Schneebesen oder eine Ofeneinstellung ändern, schreiben Sie es auf. Auf diese Weise wissen Sie genau, welche Änderung dafür verantwortlich ist, falls der Kuchen später anders schmeckt.
3. Teilen Sie das Rezept in Schritte auf: Anstatt eines einzigen großen, verwirrenden Absatzes mit Anweisungen, unterteilen Sie das Rezept in kleine, klare Schritte: „Schritt 1: Eier mischen", „Schritt 2: Mehl hinzufügen". Dies macht es für jeden einfacher, mitzuhalten und ihre Arbeit in jedem Stadium zu überprüfen.
4. Verknüpfen Sie die Notizen mit den Schritten: Im Buch, wenn der Bäcker sagt „kräftig mischen", setzen Sie genau dort einen anklickbaren Link, der Sie direkt zur exakten Codezeile springen lässt, in der dieses Mischen stattfindet. Dies verbindet die Geschichte mit der eigentlichen Arbeit.

Das Fazit

Das Papier kommt zu dem Schluss, dass das ursprüngliche Framework zwar eine großartige Idee war und dem Bereich der Materialwissenschaft half, doch das Fehlen dieser einfachen „Rezept"-Details es für andere unmöglich machte, die Ergebnisse perfekt zu kopieren. Durch die Befolgung dieser vier Regeln können Wissenschaftler sicherstellen, dass andere ihre Entdeckungen tatsächlich weiterentwickeln können, ohne sich in einem Labyrinth aus fehlenden Anweisungen und defekten Werkzeugen zu verirren.

Technische Zusammenfassung

Technisches Fazit: Reproduzierbarkeit in der rechnergestützten Werkstoffwissenschaft

Problemstellung
Trotz der raschen Integration von maschinellem Lernen (ML) in die Materialentdeckung und des gleichzeitigen Trends zu Open-Source-Daten bleibt eine signifikante Hürde bestehen: das Fehlen reproduzierbarer Praktiken bei den Entwicklern von Werkzeugen. Diese Studie untersucht die spezifischen Herausforderungen, die beim Versuch auftreten, Ergebnisse aus einer wegweisenden Arbeit, „A general-purpose machine learning framework for predicting properties of inorganic materials" von Ward et al. (2016), zu reproduzieren. Obwohl die ursprünglichen Autoren Rohdaten und ein Skript für den Modellbau bereitstellten, war das ergänzende Material (SI) unvollständig. Insbesondere fehlten die für die „Erweiterbarkeitsanalyse" erforderlichen Skripte – die praktische Anwendung des Frameworks zur Identifizierung neuer Solarzellenmaterialien. Darüber hinaus enthielten die bereitgestellten Dokumentationen irreführende Anforderungen an Abhängigkeiten, und die Codebasis verfügte über keine Versionskontrolle, was es unmöglich machte, festzustellen, ob die verteilte Software mit der Version übereinstimmte, die zur Generierung der ursprünglichen Ergebnisse verwendet wurde.

Methodik
Die Autoren versuchten, den Teil der „Erweiterbarkeitsanalyse" der Studie von Ward et al. zu replizieren, der die Identifizierung neuer ternärer Verbindungen mit geeigneten Bandlücken für Solarzellen umfasste. Die Methodik umfasste:

1. Umgebungswiederherstellung: Versuch, die Magpie-Software (ein Java-basierter Deskriptorgenerator) und ihre Abhängigkeiten zu installieren. Die Autoren stießen auf Inkompatibilitäten zwischen der dokumentierten Java-7-Anforderung und modernen Java-Versionen, was die Nutzung von Java 8 erforderlich machte.
2. Skripterstellung: Da die Skripte für die Erweiterbarkeitsanalyse im SI fehlten, rekonstruierten die Autoren diese auf Basis ungenauer Beschreibungen im Manuskript und durch Konsultation eines ursprünglichen Autors.
3. Datenverarbeitung: Die Autoren nutzten den bereitgestellten Trainingsdatensatz (OQMD v1.0, ~300.000 Verbindungen) und behandelten die fünf spezifischen Kandidatenverbindungen, die in Tabelle 1 des Originalpapiers aufgeführt sind, als Testdatensatz, da die Daten des ursprünglichen Suchraums nicht verfügbar waren.
4. Replikation und Sensitivitätstests: Die Autoren trainierten die hierarchischen REPTree-Modelle mit den rekonstruierten Skripten neu. Um Diskrepanzen zwischen ihren Ergebnissen und den ursprünglichen Vorhersagen zu untersuchen, führten sie einen Stabilitätstest für den Zufallssamen durch, bei dem zehn Modelle mit unterschiedlichen Zufallssamen (einschließlich des Standard-Weka-Samenwerts) generiert wurden, um die Sensitivität der Vorhersagen gegenüber der Initialisierung zu bewerten.

Hauptergebnisse
Der Replikationsversuch ergab, dass die ursprünglichen Ergebnisse nicht reproduziert werden konnten:

• Vorhersageabweichung: Die von den replizierten Modellen vorhergesagten Bandlückenenergien wichen signifikant von den im Originalpapier berichteten Werten ab.
• Sensitivität gegenüber dem Zufallssamen: Der Stabilitätstest für den Zufallssamen zeigte, dass die Vorhersagen hochsensitiv gegenüber dem Zufallssamen waren. Die ursprünglichen Vorhersagen lagen für mehrere Verbindungen (z. B. Hf4S11Cl2) außerhalb der Verteilung der replizierten Vorhersagen, und in einigen Fällen lagen die ursprünglichen Werte am extremen Rand der Verteilung oder sogar außerhalb des gesamten Streubereichs.
• Ursachenanalyse: Die Unfähigkeit zur Replikation wurde auf das Fehlen eines aufgezeichneten Zufallssamens, das Fehlen von Zwischen Daten (Deskriptoren, Modelle) zur Validierung und die Wahrscheinlichkeit zurückgeführt, dass die Magpie-Codebasis während der Durchführung der ursprünglichen Studie aktiv weiterentwickelt wurde. Die in den SI bereitgestellte Softwareversion unterschied sich wahrscheinlich von der Version, die zur Generierung der veröffentlichten Ergebnisse verwendet wurde.

Hauptbeiträge und Empfehlungen
Basierend auf diesen Ergebnissen schlägt das Papier vier konkrete Maßnahmen vor, um die Reproduzierbarkeit zukünftiger Open-Source-Werkzeuge in der Werkstoffinformatik zu verbessern:

1. Verbreitung von Abhängigkeiten: Entwickler sollten über textbasierte Abhängigkeitslisten hinausgehen. Die Autoren empfehlen Containerisierungsstrategien (z. B. Docker oder Singularity), um die Rechenumgebung zu kapseln und sicherzustellen, dass Softwareabhängigkeiten über die Zeit hinweg kompatibel und zugänglich bleiben.
2. Wartung und Verfolgung von Versionen: Die Studie unterstreicht die Notwendigkeit einer rigorosen Versionskontrolle (z. B. Git) und des Trackings von Machine-Learning-Operationen (MLOps) (z. B. MLFlow). Diese Tools ermöglichen die systematische Protokollierung von Codeversionen, Parametern und Metriken, wodurch die Rückverfolgbarkeit der Modellherkunft und die Möglichkeit gewährleistet werden, zu bestimmten experimentellen Zuständen zurückzukehren.
3. Nutzung sequenzieller Codierungspraktiken: Anstelle von monolithischen, komplexen Eingabeskripten sollten Entwickler sequenzielle Codierungspraktiken wie Jupyter-Notebooks annehmen. Die Aufteilung von Workflows in diskrete, in sich geschlossene Zellen mit beschreibendem Markdown verbessert die Klarheit, senkt die Lernkurve und ermöglicht es Benutzern, Ausgaben an distincten Kontrollpunkten zu validieren.
4. Verbesserung der Codeklarheit in Manuskripten: Die Autoren schlagen vor, innerhalb des Manuskripttextes anklickbare Verknüpfungen einzufügen, die direkt auf bestimmte Dateien oder Codezeilen im Repository verweisen. Dies schließt die Lücke zwischen der schriftlichen Methodik und der praktischen Umsetzung und reduziert Mehrdeutigkeiten.

Bedeutung
Das Papier kommt zu dem Schluss, dass das von Ward et al. vorgeschlagene Framework zwar erfolgreich einen generalisierten Ansatz für die Werkstoffinformatik demonstrierte, die Studie jedoch als warnende Lehre dient: Reproduzierbarkeit erfordert eine bewusste, strukturierte Anstrengung. Ohne proaktive Maßnahmen im Bereich des Dependency-Managements, des Versionstrainings und der Codeorganisation können auch gut gemeinte Initiativen für offene Wissenschaft nicht reproduzierbar sein. Durch die Übernahme der empfohlenen Praktiken kann die Gemeinschaft mehr Vertrauen, Transparenz und Einfachheit bei der Einführung von Werkzeugen für die rechnergestützte Werkstoffforschung fördern.