Forschung nicht reproduzierbar? Ein praktischer Leitfaden

Dieses in allen Disziplinen dokumentierte Problem kann von Computerwissenschaftlern direkt angegangen werden, da in der Regel Software und nicht die Nasslabortechnik der Fehlerpunkt ist. Standards wie der 2019er Bericht der National Academies Reproducibility and Replicability in Science definieren das Arbeitsvokabular, und die praktischen Lösungen sind konkret: Versionskontrolle, fixierte Abhängigkeiten (pinned dependencies), Containerisierung und Build-Automatisierung.

• Reproduzierbarkeit und Replizierbarkeit sind unterschiedlich: Reproduzierbarkeit bedeutet, dieselbe Analyse mit denselben Daten erneut durchzuführen und dieselben Zahlen zu erhalten; Replizierbarkeit bedeutet, dass eine neue Studie zu einer konsistenten Schlussfolgerung kommt.
• Die meisten nicht reproduzierbaren computergestützten Untersuchungen gehen auf vier Ursachen zurück: fehlender oder mutierter Code, nicht fixierte Softwareumgebungen, undokumentierte Datenherkunft (provenance) und versteckte manuelle Schritte.
• Ein reproduzierbarer Build ist eine deterministische Transformation von Quelleingaben zu Ausgaben – dieselbe Idee wie reproduzierbare Builds in der Softwarepaketierung, angewendet auf Analysepipelines.
• Die minimal praktikable Lösung ist ein Repository mit einer Lockfile, einem einzigen Einstiegspunkt (make, Snakemake oder ein Skript) und einer README-Datei, der ein Fremder folgen kann, ohne Ihnen Fragen stellen zu müssen.
• Container (Docker, Apptainer/Singularity, Conda-Umgebungen) lösen das Problem des Environment Drift; sie lösen keine undokumentierte Datenbereinigung oder nichtdeterministische Algorithmen.
• Reproduzierbarkeit ist ein Spektrum, kein Binärsystem – streben Sie nach „ein kompetenter Fremder kann Ihre Abbildungen regenerieren“, nicht nach Perfektion.

Was „reproduzierbar“ tatsächlich bedeutet (und was nicht)

Reproduzierbare Forschung ist die Praxis, eine Studie so zu verpacken, dass ein unabhängiger Forscher ihre Ergebnisse aus den Originaldaten und dem Originalcode regenerieren kann. Das Wort hat eine spezifische technische Bedeutung, die sich vom alltäglichen Gebrauch unterscheidet: Im Sinne des Wörterbuchs bedeutet „reproduzierbar“ einfach die Fähigkeit, wieder hergestellt zu werden, aber in der Computerwissenschaft impliziert es Determinismus, Provenienz und eine ausreichende Dokumentation, sodass die Regeneration nicht vom impliziten Wissen der ursprünglichen Autoren abhängt.

Reproduzierbarkeit in der Forschung gehört zu einer Familie verwandter Begriffe, die häufig verwechselt werden. Die Konsensstudie der National Academies aus dem Jahr 2019 unterscheidet zwischen computergestützter Reproduzierbarkeit (gleiche Daten, gleicher Code, gleiche Ergebnisse) und Replizierbarkeit (neue Daten, konsistente Ergebnisse).

Statistiker ergänzen dies um die Wiederholbarkeit (repeatability), was bedeutet, dass derselbe Analyst zweimal dasselbe Ergebnis erhält. Eine Studie kann reproduzierbar, aber nicht replizierbar sein – der Code regeneriert originalgetreu ein Ergebnis, das ein neues Experiment nicht bestätigen kann – und diese Unterscheidung ist wichtig bei der Diagnose eines Fehlers.

Die abweichende Schreibweise „reproducable“ taucht häufig in Suchanfragen und informellen Texten auf, aber im Standardenglischen wird „reproducible“ verwendet. Das Suffix wird an die Wurzel „reproduce“ in der Form „-ible“ angehängt, entsprechend zu „producible“ und „deducible“. Styleguides und Wörterbücher listen nur „reproducible“; behandeln Sie „reproducable“ als Rechtschreibfehler, auch wenn Sie in alten Forenbeiträgen und in Manuskripten von Nicht-Muttersprachlern darauf stoßen.

Warum Forschung nicht reproduzierbar ist: Die vier Fehlermodi

Fehlender oder mutierter Code ist für einen Großteil der fehlgeschlagenen Reproduktionsversuche verantwortlich. Ein häufiges Szenario: Der veröffentlichte Artikel beschreibt eine Analyse, der entsprechende Autor hat das Labor verlassen, und das Repository existiert entweder nicht, enthält eine veraltete Version oder verweist auf einen privaten Datensatz. Code, der „auf meinem Rechner funktioniert“, aber über keinen Versionsverlauf verfügt, kann nicht geprüft werden, und ohne einen Commit-Hash gibt es keine Möglichkeit zu wissen, welche Version die veröffentlichte Abbildung erzeugt hat.

Verwandte: Dataquest — Projektbasierte Data-Science-Pfade mit geführtem Terminal und realen Datensätzen.

Nicht fixierte Softwareumgebungen verhindern die Reproduktion stillschweigend. Eine mit Version 1.20 geschriebene NumPy-Pipeline kann unter 2.x unterschiedliche Gleitkommaergebnisse, Deprecation-Warnungen oder outright Fehler erzeugen.

Molekulardynamik-Trajektorien, die mit einem bestimmten GROMACS- oder LAMMPS-Build generiert wurden, können sich von einem anderen unterscheiden, wenn Compiler-Flags, FFT-Bibliotheken oder die parallele Zerlegung variieren. Die Lösung besteht darin, die exakten Versionen zu speichern – eine requirements.txt mit Hashes, ein conda env export, eine renv.lock für R oder ein Container-Image-Digest – und nicht nur eine Liste von Paketnamen.

Undokumentierte Datenherkunft ist der dritte Fehlermodus. Rohe Instrumentenausgaben, Simulations-Restart-Dateien und HDF5-Archive durchlaufen oft mehrere Bereinigungs- und Konvertierungsschritte, die im Methodenteil nie erwähnt werden.

Einen Blick wert: Coursera Plus — Ein Abonnement für von der Universität unterstützte Python- und Data-Science-Zertifikate.

Wenn ein Mitarbeiter Ausreißer manuell in einer Tabellenkalkulation gefiltert hat, ist dieser Schritt unsichtbar und nicht reproduzierbar. Provenienz bedeutet, aufzuzeichnen, woher jede Eingabe kam, welche Transformationen angewendet wurden und in welcher Reihenfolge.

Versteckte manuelle Schritte sind der vierte Punkt. Das Klicken durch eine GUI zum Exportieren eines Plots, das manuelle Umbenennen von Dateien oder das Kopieren von Zahlen zwischen Tools unterbricht die Automatisierung. Der Test ist einfach: Könnte jemand, der Sie noch nie getroffen hat, Ihre Pipeline ohne einen Telefonanruf von Anfang bis Ende ausführen? Wenn die Antwort nein lautet, sind die manuellen Schritte das Problem.

Wie man Forschung reproduzierbar macht: Ein praktischer Arbeitsablauf

Versionskontrolle ist das Fundament. Git (oder Mercurial für bestehende Projekte) verfolgt jede Änderung an Code, Manuskripten und kleinen Konfigurationsdateien.

Committen Sie frühzeitig, schreiben Sie aussagekräftige Commit-Messages und markieren Sie den exakten Commit, der mit einem eingereichten Artikel übereinstimmt. Für große binäre Artefakte (Trajektorien, HDF5-Dateien, trainierte Modellgewichte) verwenden Sie Git LFS, DVC oder Zenodo/figshare-Repositories mit DOIs, anstatt Gigabytes in das Repository zu committen.

Als Nächstes folgt das Fixieren von Abhängigkeiten. Python-Projekte müssen eine Lockfile (pip-compile, Poetry oder uv) bereitstellen; R-Projekte sollten „renv“ verwenden; Julia-Projekte nutzen „Project.toml“ und „Manifest.toml“.

Fixieren Sie transitive Abhängigkeiten, nicht nur direkte, da eine Änderung in der dritten Ebene die digitale Ausgabe verändern kann. Notieren Sie das Betriebssystem, den Compiler und alle hardwarespezifischen Bibliotheken (BLAS, CUDA), die die Ergebnisse beeinflussen.

Verwandte: O'Reilly Learning Platform — Eine umfassende technische Bibliothek mit Büchern, Videos und Live-Schulungen zum Thema wissenschaftliches Rechnen.

Ein einzelner Einstiegspunkt verwandelt einen Ordner mit Skripten in eine Pipeline. Das klassische Tool ist make: Ein Makefile deklariert Targets, Abhängigkeiten und Befehle, und make baut nur das neu, was sich geändert hat.

Dies ist die Essenz reproduzierbarer Forschung mit Make – der Build-Graph dokumentiert den Workflow und erzwingt die Reihenfolge. Moderne Alternativen sind Snakemake, Nextflow und targets (für R). Jedes davon ist besser als eine README, in der steht: „Führen Sie script1.py aus, dann script2.py, dann…“.

Containerisierung erfasst die gesamte Umgebung. Docker-Images, Apptainer/Singularity-Images (häufig auf HPC-Clustern, wo Docker nicht verfügbar ist) und Conda-Umgebungen lösen jeweils das Problem des Environment Drift.

Wenn Sie einkaufen: DataCamp — Interaktive Python- und Data-Science-Kurse, bei denen Sie direkt im Browser programmieren.

Ein Container mit einem fixierten Digest ist die stärkste Garantie dafür, dass Ihre Analyse auf einem Laptop, einem Cluster und dem Rechner eines Reviewers identisch läuft. Der Kompromiss liegt in der Image-Größe und Build-Zeit; ein schlankes Basis-Image und Multi-Stage-Builds halten beides handhabbar.

Die Dokumentation schließt den Kreis. Eine README sollte die Softwareanforderungen, den exakten Befehl zur Reproduktion jeder Abbildung, die erwartete Ausführungszeit und das erwartete Ergebnis angeben. Eine CITATION.cff-Datei oder eine codemeta.json hilft anderen, Software korrekt zu zitieren. Wenn ein Schritt wirklich interaktiv ist, beschreiben Sie ihn so spezifisch, dass ein Leser ihn wiederholen kann.

Reproduzierbare Forschung mit R: Ein konkretes Beispiel

R verfügt über eines der ausgereiftesten Ökosysteme für Reproduzierbarkeit, weshalb „reproducible research in R“ eine häufige Suchanfrage ist. Das Paket renv erstellt Snapshots der Paketversionen in einer Lockfile, sodass renv::restore() exakt die Bibliothek wiederherstellt, gegen die ein Projekt entwickelt wurde. R Markdown und Quarto verweben Code, Ausgabe und Prosa in einem einzigen Dokument, das beim „Knitten“ regeneriert wird, wodurch Copy-Paste-Fehler zwischen Analyse und Manuskript eliminiert werden.

Eine minimale R-Projektstruktur sieht so aus: eine renv.lock für Abhängigkeiten, ein R/-Verzeichnis für Funktionen, ein data-raw/-Verzeichnis für Ingestions-Skripte, ein data/-Verzeichnis für verarbeitete Objekte und ein Makefile oder _targets.R, das den Build orchestriert. Das Paket targets erweitert die make-artige Abhängigkeitsverfolgung auf R und überspringt Schritte, deren Eingaben sich nicht geändert haben. Für eine tiefergehende Behandlung ist das Buch Reproducible Research with R and RStudio von Christopher Gandrud eine Standardreferenz, und R Programming for Data Science von Roger Peng sowie die Kursmaterialien zur Reproduzierbarkeit von Johns Hopkins decken den Workflow von Anfang bis Ende ab.

Die gleichen Prinzipien gelten für Python. Eine pyproject.toml mit fixierten Abhängigkeiten, ein Makefile- oder Snakemake-Workflow und ein Quarto- oder Jupyter Book-Manuskript bieten das Äquivalent zum R-Stack. Die Werkzeuge unterscheiden sich; die Disziplin nicht.

Was sind reproduzierbare Builds?

Reproduzierbare Builds sind eine Software-Engineering-Praxis, bei der das Kompilieren desselben Quellcodes mit derselben Toolchain eine Byte-für-Byte identische Binärdatei ergibt. Das Konzept stammt aus der Free-Software-Welt – die Debian- und Tor-Projekte waren Pioniere – und ist heute ein formaler Standard, der vom Reproducible Builds-Projekt gepflegt wird. Die Motivation ist Vertrauen: Wenn jeder eine Binärdatei neu bauen und denselben Hash erhalten kann, kann verifiziert werden, dass die verteilte Binärdatei mit dem veröffentlichten Quellcode übereinstimmt und keine versteckten Modifikationen enthält.

Die Analogie zu wissenschaftlichen Pipelines ist direkt. Ein reproduzierbarer Analyse-Build nimmt Quelleingaben (Rohdaten, Code, Konfiguration) und erzeugt deterministisch Ausgaben (Abbildungen, Tabellen, Statistiken).

Nichtdeterminismus macht dies zunichte und führt dazu, dass Forschung nicht reproduzierbar ist: nicht fixierte Zufallssamen (random seeds), parallele Reduktionen, die in variierender Reihenfolge summieren, in Ausgabedateien eingebettete Zeitstempel und Gleitkommaoperationen, die von der Thread-Anzahl abhängen, verursachen alle Variationen von Lauf zu Lauf. Das Fixieren von Seeds, das Sortieren vor der Reduktion und das Entfernen von Zeitstempeln sind Standardlösungen.

Nicht alle Quellen des Nichtdeterminismus können eliminiert werden. Molekulardynamik mit GPU-Beschleunigung kann auf unterschiedlicher Hardware aufgrund unterschiedlicher Gleitkommarundungen leicht verschiedene Trajektorien erzeugen, und Monte-Carlo-Methoden sind inhärent stochastisch. Der ehrliche Ansatz besteht darin, die erwartete Variation zu dokumentieren, sie zu berichten und sicherzustellen, dass die wissenschaftliche Schlussfolgerung robust gegenüber dieser Variation ist – anstatt eine Identität auf Bitebene zu behaupten, die man nicht liefern kann.

Kriterien zur Beurteilung, ob eine Studie reproduzierbar ist

Kriterium	Schwach	Stark
Codeverfügbarkeit	„Auf Anfrage erhältlich“	Öffentliches Repository mit getaggtem Release und DOI
Umgebung	Nur Paketnamen	Lockfile oder Container mit fixiertem Digest
Einstiegspunkt	Nummerierte Skripte, manuelle Reihenfolge	make, Snakemake oder targets-Workflow
Datenherkunft	Methodenabsatz	Dokumentierte Ingestions-Skripte und Prüfsummen
Determinismus	Unfixierte Zufälligkeit	Fixierte Seeds, dokumentierte erwartete Variation
Dokumentation	Setzt Autorenwissen voraus	Fremder kann jede Abbildung regenerieren

Nutzen Sie dies als Selbstprüfung vor der Einreichung, um sicherzustellen, dass Ihre Forschung reproduzierbar ist. Die meisten Zeitschriften und Geldgeber verlangen mittlerweile eine Erklärung zur Daten- und Codeverfügbarkeit, und einige – darunter mehrere AGU-, PLOS- und Nature-Portfolio-Zeitschriften – verlangen, dass der Code in einem Repository mit einem DOI hinterlegt wird. Das Erreichen der Spalte „Stark“ ist zunehmend eine Bedingung für die Veröffentlichung, kein Bonus.

Gemeinsame Einwände und ehrliche Kompromisse

Der Zeitaufwand ist der am häufigsten genannte Einwand, und er ist real. Das ordnungsgemäße Verpacken einer Pipeline kann bei einem bereits „fertigen“ Projekt Tage dauern.

Das Gegenargument ist, dass die Kosten für das Nichtstun später bezahlt werden, oft durch einen Studenten oder Mitarbeiter, der Wochen damit verbringt, eine Analyse per Reverse Engineering zu rekonstruieren. Ein pragmatischer Mittelweg: Investieren Sie sofort in Versionskontrolle und eine Lockfile und containerisieren Sie nur Projekte, von denen Sie erwarten, dass andere sie wiederverwenden.

Sensible oder eingeschränkte Daten erschweren das Teilen. Klinische, proprietäre und bestimmte Instrumentendaten können nicht öffentlich veröffentlicht werden. In diesen Fällen bedeutet Reproduzierbarkeit, den Code, das Schema und eine synthetische oder anonymisierte Probe zusammen mit einer klaren Beschreibung des Zugriffsverfahrens zu veröffentlichen. Das Ziel ist, dass ein qualifizierter Forscher mit legitimem Zugriff die Ergebnisse regenerieren kann.

Legacy-Code ist eine weitere Einschränkung. Fortran- und C-Simulationen aus den 1990ern lassen sich auf modernen Systemen möglicherweise nicht ohne Patches kompilieren. Sie in einem Container mit einer alten Toolchain zu kapseln, ist oft einfacher als sie neu zu schreiben, und es bewahrt die ursprüngliche Numerik. Dokumentieren Sie, welche Patches Sie angewendet haben und warum.

Schließlich ist Reproduzierbarkeit nicht dasselbe wie Korrektheit. Eine Pipeline kann perfekt reproduzierbar und trotzdem falsch sein – ein originalgetreu reproduzierter Bug ist immer noch ein Bug. Reproduzierbarkeit ist eine Voraussetzung für die Prüfung, kein Ersatz für sie. Peer-Review, unabhängige Replikation und Sensitivitätsanalysen bleiben notwendig, um sicherzustellen, dass die Forschung nicht nur in ihren Fehlern reproduzierbar ist.

Häufig gestellte Fragen

Was bedeutet es, wenn Forschung nicht reproduzierbar ist?

Forschung ist nicht reproduzierbar, wenn ein unabhängiger Forscher unter Verwendung derselben Daten und desselben Codes die veröffentlichten Ergebnisse nicht regenerieren kann. Die Ursache ist meist fehlender Code, eine nicht fixierte Softwareumgebung, undokumentierte Datenverarbeitung oder manuelle Schritte, die nie automatisiert wurden. Dies ist eine Eigenschaft der Artefakte und kein Urteil über die Ehrlichkeit der ursprünglichen Autoren.

Was ist der Unterschied zwischen Reproduzierbarkeit und Replizierbarkeit?

Reproduzierbarkeit bedeutet, dass dieselbe Analyse mit denselben Daten erneut durchgeführt wird und dasselbe Ergebnis erzielt wird. Replizierbarkeit bedeutet, eine neue Studie durchzuführen – neue Daten, neue Proben – und zu einer konsistenten Schlussfolgerung zu gelangen. Der Bericht der National Academies von 2019 behandelt diese Konzepte als separate Konzepte, und eine Studie kann reproduzierbar sein, auch wenn sie nicht repliziert werden kann.

Wie mache ich meine Forschung reproduzierbar?

Beginnen Sie mit der Versionskontrolle (Git) und markieren Sie den Commit, der Ihrem Artikel entspricht. Pinnen Sie Abhängigkeiten mit einer Sperrdatei oder einem Container-Image. Stellen Sie einen einzigen Einstiegspunkt bereit, z. B. einen „Makefile-“, Snakemake- oder „Targets“-Workflow. Dokumentieren Sie die Datenherkunft und die erwarteten Ergebnisse in einer README-Datei. Testen Sie alles auf einer sauberen Maschine, bevor Sie es einreichen.

Ist „reproducable“ eine korrekte Schreibweise?

Nein. Im Standardenglisch wird das Wort „reproducible“ geschrieben, gebildet aus „reproduce“ und dem Suffix „-ible“. Wörterbücher und Styleguides führen nur „reproducible“ auf. Die Variante „reproducable“ kommt in informellen Texten und einigen nicht-muttersprachlichen Texten vor, wird jedoch in formellen wissenschaftlichen Texten nicht akzeptiert.

Was sind reproduzierbare Builds im wissenschaftlichen Rechnen?

Reproduzierbare Builds sind Builds, die identische Ausgaben aus identischen Eingaben erzeugen, ein vom Reproducible Builds-Projekt für Softwarepaketierung formalisierter Standard. In der Wissenschaft gilt das gleiche Prinzip für Analyse-Pipelines: Feste Zufalls-Seeds, deterministische Reduktionen und fixierte Toolchains ermöglichen eine exakte Regenerierung der Ergebnisse. Wenn hardwareabhängige Gleitkommaschwankungen unvermeidbar sind, dokumentieren Sie den erwarteten Bereich.

Erfordert die Reproduzierbarkeit die Weitergabe aller meiner Daten?

Nicht immer. Eingeschränkte, klinische oder proprietäre Daten können durch die Veröffentlichung von Code, Schemata und synthetischen Proben zusammen mit einem dokumentierten Zugriffsverfahren verwaltet werden. Viele Geldgeber und Zeitschriften verlangen eine Datenverfügbarkeitserklärung statt offener Daten. Der Test besteht darin, ob ein qualifizierter Forscher mit legitimem Zugriff Ihre Ergebnisse neu generieren kann.

Weiterführende Literatur und Tools

Reproducibility and Replicability in Science (2019) der National Academies ist die maßgebliche konzeptionelle Referenz für den Fall, dass Forschung nicht reproduzierbar ist. Das Reproducible Builds-Projekt dokumentiert den Software-Engineering-Standard. Informationen zu Workflow-Tools finden Sie in der Dokumentation für GNU Make, Snakemake, Nextflow, „targets“, „renv“ und Quarto. „The Turing Way“ ist ein offenes Community-Handbuch, das reproduzierbare Forschungspraktiken in allen Disziplinen abdeckt, und das Software Sustainability Institute veröffentlicht praktische Anleitungen für Forschungssoftware-Ingenieure.