💻 computer science

ReproScore: Separating Readiness from Outcome in Research Software Reproducibility Assessment

Die Arbeit stellt ReproScore vor, ein zweistufiges Framework, das die statische Repository-Bereitschaft von tatsächlichen Ausführungsergebnissen entkoppelt, um die „Vermischung von Bereitschaft und Ergebnis" bei der Bewertung von Forschungssoftware zu adressieren, und zeigt durch eine groß angelegte Evaluierung, dass statische Signale zwar strukturelle Unterschiede erfassen, aber den Erfolg der Ausführung nicht vorhersagen können, wodurch die Notwendigkeit dieser architektonischen Trennung in der digitalen Bibliothekskuration validiert wird.

Ursprüngliche Autoren: Sheeba Samuel, Daniel Mietchen, Jungsan Kim, Waqas Ahmed, Martin Gaedke

Veröffentlicht 2026-05-14

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Sheeba Samuel, Daniel Mietchen, Jungsan Kim, Waqas Ahmed, Martin Gaedke

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind Bibliothekar in einer riesigen digitalen Bibliothek. Jeden Tag bringen Tausende von Forschern Kisten mit „Forschungssoftware" (Code, Daten und Anweisungen) vorbei, in der Hoffnung, dass diese gespeichert und geteilt werden. Ihre Aufgabe besteht darin herauszufinden: Kann diese Software tatsächlich von jemandem genutzt werden, oder ist es nur eine kaputte Kiste mit Teilen?

Seit langem machen Bibliothekare und automatisierte Tools einen kritischen Fehler. Sie gehen davon aus, dass wenn eine Kiste von außen vollständig aussieht (sie hat ein schönes Etikett, eine Teileliste und eine Bedienungsanleitung), die Maschine im Inneren auch funktionieren muss. Die Autoren dieses Papiers nennen diesen Fehler die „Readiness–Outcome Conflation" (Vermischung von Bereitschaft und Ergebnis). Es ist so, als würde man ein Auto daran beurteilen, wie glänzend seine Lackierung ist, ohne jemals zu prüfen, ob der Motor tatsächlich anspringt.

Hier ist, wie das neue System des Papiers, ReproScore, dieses Problem löst.

Das Zwei-Ebenen-System: Die „Checkliste" versus die „Probefahrt"

ReproScore unterteilt die Bewertung in zwei verschiedene Ebenen, ähnlich wie beim Kauf eines Gebrauchtwagens:

1. Ebene 1: Der „Readiness"-Score (RRS) – Die Checkliste
Dies ist der Teil, der bevor Sie versuchen, die Software auszuführen, stattfindet. Es ist eine detaillierte statische Checkliste mit 26 Punkten in fünf Kategorien. Denken Sie daran wie an die Prüfung der Papiere und physischen Teile eines Autos, während es sich noch in der Garage befindet.

Umgebung: Stellt der Besitzer eine spezifische Liste der benötigten Kraftstoff- und Ölsorten bereit? (z. B. eine requirements.txt-Datei).
Daten: Ist der Kraftstofftank voll, oder gibt es eine klare Karte, wo der Kraftstoff zu finden ist?
Dokumentation: Gibt es eine klare Anleitung, wie man den Motor startet?
Portabilität: Sind die Teile allgemein genug, um in jeder Garage zu funktionieren, oder sind sie auf den spezifischen Boden der Einfahrt des Besitzers geklebt?
Signale: Hat der Besitzer versprochen, den Motor jedes Mal reibungslos laufen zu lassen (z. B. durch Setzen eines „Seed"-Werts für Zufallszahlen)?

Die große Erkenntnis: Das Papier stellt fest, dass ein „perfekter" Checklisten-Score nicht garantiert, dass das Auto startet. Sie können eine Kiste mit jeder einzelnen aufgelisteten Komponente und einer perfekten Anleitung haben, aber wenn die Teile die falsche Größe haben (ein Versionskonflikt), wird der Motor nicht anspringen. Umgekehrt kann eine Kiste mit einer chaotischen Anleitung trotzdem zufällig funktionieren.

2. Ebene 2: Der „Outcome"-Score (ROS) – Die Probefahrt
Dies ist die eigentliche „Probefahrt". Wenn die Bibliothek die Ressourcen hat, die Software in einer sicheren, isolierten Sandbox (wie einer Teststrecke) auszuführen, versuchen sie, sie zu starten.

Ist der Motor gestartet?
Ist er ohne Absturz gelaufen?
Hat er jedes Mal das gleiche Ergebnis geliefert?

Dieser Score ist nur verfügbar, wenn die Bibliothek den Code tatsächlich ausführt. Er ist optional und ressourcenintensiv.

Der „Composite Score" (RCS): Die Verschmelzung der beiden

Das Papier stellt eine clevere Methode vor, diese beiden Scores zu einer einzigen finalen Zahl zu kombinieren, die Composite Score (RCS) genannt wird.

Stellen Sie sich eine Waage vor, die die „Checkliste" und die „Probefahrt" ausbalanciert.

Wenn Sie nur die Checkliste haben (keine Probefahrt), basiert Ihr Score zu 100 % auf der Checkliste.
Wenn Sie die Probefahrt durchführen, verschiebt sich der Score langsam dahin, dass er mehr auf die Probefahrt vertraut.
Entscheidend: Das Papier argumentiert, dass selbst wenn das Auto die Probefahrt perfekt besteht, die Checkliste immer noch wichtig ist. Ein Auto, das einmal läuft, aber keine Anleitung oder Kraftstoffkarte hat, ist immer noch eine schlechte Einlagerung für eine Bibliothek. Das System stellt sicher, dass die „Checkliste" (Bereitschaft) niemals vollständig verschwindet, selbst wenn die „Probefahrt" (Ergebnis) perfekt ist.

Die „Community Rubric": Das Regelbuch

Eines der Hauptmerkmale des Papiers ist, dass verschiedene Bibliotheken unterschiedliche Dinge priorisieren könnten.

Eine Bioinformatik-Bibliothek könnte am meisten Wert auf die richtigen Daten (Kraftstoff) legen.
Eine Software-Bibliothek könnte am meisten Wert auf die Portabilität des Codes (allgemeine Teile) legen.

ReproScore ermöglicht es diesen Bibliotheken, ihr eigenes „Regelbuch" (eine einfache YAML-Datei) einzutauschen. Dies ändert die Gewichtung der Checklistenpunkte. Es ist so, als würde man sagen: „Für unsere Bibliothek ist die Kraftstoffkarte 40 % des Gesamtscores wert, während sie für Ihre Bibliothek nur 25 % wert ist." Dies macht die Bewertung transparent und anpassbar.

Was die Experimente zeigten

Die Autoren testeten dies an 423 realen Software-Repositories (meist Python/Jupyter-Notebooks). Sie fanden zwei überraschende Dinge:

Die Kategorie „Umgebung" ist ein Detektiv: Der Checklisten-Score für „Umgebung" war hervorragend darin, zu sagen, welche Art von Problem ein Repository hatte.
- Wenn ein Repository einen hohen Umgebungs-Score hatte, aber dennoch scheiterte, bedeutete dies normalerweise einen Versionskonflikt (die Teile waren da, passten aber nicht zusammen).
- Wenn ein Repository einen niedrigen Umgebungs-Score hatte, bedeutete dies normalerweise fehlende Teile (keine Liste der Abhängigkeiten überhaupt).
- Analogie: Ein hoher Score hier sagt Ihnen: „Der Besitzer hat versucht, präzise zu sein, aber die spezifischen Teile, die er ausgewählt hat, sind inkompatibel." Ein niedriger Score sagt: „Der Besitzer hat nicht einmal aufgeschrieben, welche Teile benötigt werden."
Bereitschaft sagt keinen Erfolg voraus: Die wichtigste Erkenntnis ist, dass ein hoher „Bereitschaft"-Score (eine perfekte Checkliste) fast keine Korrelation damit hatte, ob die Software tatsächlich lief.
- Analogie: Sie können ein Auto mit einem perfekten Handbuch des Besitzers, einem vollen Tank und einer sauberen Motorhaube haben, aber wenn die Zündkerzen aus einem anderen Jahrzehnt stammen, wird das Auto nicht starten. Die Checkliste sieht perfekt aus, aber das Ergebnis ist ein Misserfolg.

Das Fazit

Das Papier kommt zu dem Schluss, dass wir aufhören müssen, „bereit auszusehen" und „tatsächlich zu funktionieren" als dasselbe zu behandeln.

Für Bibliothekare: Nutzen Sie den „Bereitschaft"-Score zur Triage. Wenn eine Kiste einen niedrigen Score hat, wissen Sie genau, was Sie vom Forscher korrigieren lassen müssen (z. B. „Bitte fügen Sie eine Abhängigkeitsliste hinzu"). Sie müssen keine Zeit damit verschwenden, kaputten Code auszuführen.
Für Forscher: Ein hoher Score auf der Checkliste bedeutet nicht, dass Sie fertig sind. Sie müssen immer noch überprüfen, ob der Code tatsächlich läuft.

ReproScore ist ein Werkzeug, das digitalen Bibliotheken hilft, das Chaos der Forschungssoftware zu bewältigen, indem es klar trennt, was vorhanden ist und was funktioniert, und sicherstellt, dass Kuratoren genau wissen, welche Art von Hilfe ein Stück Software benötigt.

Technische Zusammenfassung: ReproScore: Trennung von Bereitschaft und Ergebnis bei der Bewertung der Reproduzierbarkeit von Forschungssoftware

1. Problemstellung

Digitale Bibliotheken (z. B. Zenodo, Software Heritage) kuratieren Millionen von Forschungssoftware-Artefakten, verfügen jedoch nicht über eine skalierbare Infrastruktur, um zu bewerten, ob diese Artefakte tatsächlich ausführbar sind. Bestehende automatisierte Bewertungswerkzeuge leiden unter einem kritischen Mangel: Sie vermischen Bereitschaft (statische Vollständigkeit des Repositories, wie das Vorhandensein einer README- oder requirements.txt-Datei) mit dem Ergebnis (tatsächlicher Ausführungserfolg).

Diese „Vermischung von Bereitschaft und Ergebnis" führt zu der falschen Annahme, dass ein Repository mit vollständiger statischer Dokumentation wahrscheinlich ausführbar ist. In der Realität kann ein Repository über perfekte statische Signale verfügen, dennoch aufgrund von transitiven Abhängigkeitskonflikten, unzugänglichen Daten oder Laufzeitumgebungsproblemen scheitern, die eine statische Analyse nicht erkennen kann. Aktuelle Werkzeuge verlassen sich entweder auf statische Analysen (unter Vernachlässigung der Ausführung) oder erfordern teure, von Experten gesteuerte Ausführung in sandgeboxten Umgebungen (ohne Skalierbarkeit). Es besteht Bedarf an einem Framework, das explizit zwischen dem Potenzial für Reproduzierbarkeit (Bereitschaft) und dem tatsächlichen Ergebnis der Ausführung (Ergebnis) unterscheidet und Kuratoren diagnostische Informationen liefert, anstatt eine binäre Bestehens-/Nicht-Bestehens-Vorhersage zu treffen.

2. Methodik: Die ReproScore-Architektur

ReproScore ist ein zweistufiges Framework, das entwickelt wurde, um die Bereitschaft zur Reproduzierbarkeit vom Ausführungsergebnis zu trennen und diese zu einem anpassungsfähigen, abdeckungsbasierten Composite-Score zu kombinieren.

Stufe 1: Reproduzierbarkeits-Bereitschaftsscore (RRS)

Der RRS ist eine statische, stets verfügbare Metrik, die durch deterministische, regelbasierte Analyse eines lokal geklonten Repositories berechnet wird. Er erfordert keine Codeausführung.

Struktur: Der RRS besteht aus 26 atomaren Untermetriken, die in fünf Kategorien gruppiert sind:
1. Umgebung (E, Gewicht 0,30): Spezifikation von Abhängigkeiten, Containerisierung und Laufzeitversionen.
2. Daten (A, Gewicht 0,25): Zugänglichkeit, Verweise und Beschaffungsmethoden für Eingangsdaten.
3. Dokumentation (D, Gewicht 0,20): Vorhandensein von Ausführungsinstruktionen, Einstiegspunkten und Anwendungsbeispielen.
4. Code-Portabilität (C, Gewicht 0,15): Fehlen absoluter Pfade, hartkodierte Zugangsdaten und nicht auflösbarer Imports.
5. Reproduzierbarkeitssignale (S, Gewicht 0,10): Determinismus-Signale wie Seed-Verwaltung und Ausführungsreihenfolge.
Bewertungslogik:
- Gate-Funktion: Eine Potenzgesetz-Gate-Funktion $g(x, \tau, k)$ bestraft unterhalb der Schwelle liegende Scores nichtlinear. Scores unterhalb einer Schwelle $\tau$ werden komprimiert, was einer Kuratierungspolitik entspricht, wonach schwere Mängel (z. B. fehlende Umgebungs-Spezifikation) unverhältnismäßig schädlich sind.
- Strafen: Harte Strafen werden für das vollständige Fehlen von Umgebungs-Spezifikationen oder Datenartefakten ( $P_{hard}$ ) sowie für stochastische Operationen ohne Seed-Verwaltung ( $P_{seed}$ ) verhängt.
- Formel: $RRS = 100 \cdot \sum (w_i \cdot g(x_i)) - \text{Strafen}$ .

Stufe 2: Reproduzierbarkeits-Ergebnisscore (ROS)

Der ROS ist eine optionale, ausführungsbasierte Metrik, die berechnet wird, wenn eine sandgeboxte Umgebung (z. B. repo2docker, nbconvert) verfügbar ist.

Komponenten: Er aggregiert bis zu sechs Proben: Erfolg bei der Installation ( $I$ ), Erfolg bei der Ausführung ( $X$ ), Determinismus der Ausgabe ( $\Delta$ ), Notebook-Ausführungsrate ( $N$ ), Erfolgsrate bei Imports ( $E'$ ) und Durchlaufrate von Tests ( $T$ ).
Normalisierung: Der ROS ist eine gewichtete Summe verfügbarer Komponenten, sodass der Score auch berechnet werden kann, wenn nur teilweise Ausführungsdaten vorliegen.

Composite-Score (RCS)

Der ReproScore Composite (RCS) mischt RRS und ROS basierend auf der Menge der gesammelten Ausführungsnachweise.

Abdeckungsgewicht ( $\alpha$ ): Ein Parameter, der von 0 (keine Ausführung) bis zu einem Maximum von 0,70 skaliert. Er stellt sicher, dass die statische Bereitschaft niemals vollständig von Ausführungsergebnissen dominiert wird, und anerkennt, dass ein erfolgreicher Lauf die Dokumentation oder Portabilität nicht validiert.
Formel: $RCS = (1 - \alpha) \cdot RRS + \alpha \cdot ROS$ . Liegen keine Ausführungsdaten vor, gilt $RCS = RRS$.

Community-Rubrik-Mechanismus

ReproScore externalisiert Bewertungsprioritäten über ein versioniertes YAML-Profil. Dies ermöglicht es verschiedenen Communities (z. B. Bioinformatik vs. allgemeine Software), Standardgewichte und Gate-Schwellenwerte zu überschreiben, ohne den Quellcode zu ändern. Dies macht Kuratierungspolitiken explizit, überprüfbar und über Institutionen hinweg portabel.

3. Hauptbeiträge

Konzeptionelle Trennung: Eine formale zweistufige Architektur (RRS/ROS/RCS), die statische Bereitschaft vom Ausführungsergebnis entkoppelt und die Vermischung von Bereitschaft und Ergebnis in Workflows digitaler Bibliotheken adressiert.
Bereitschaftsmodell: Ein 5-Kategorien-, 26-Untermetriken-Modell (RRS) mit experteninformierten Gewichten, nichtlinearer Gate-Funktion und Nachweisbarkeit auf Dateiebene.
Governance-Mechanismus: Ein Community-Rubrik-System, das es ermöglicht, Bewertungsprioritäten als zitierbare, versionierte Artefakte zu definieren.
Empirische Validierung: Eine Evaluation an 423 GitHub-Repositories (Python/Jupyter), die zeigt, dass statische Bereitschaft stark zwischen Fehlermodi diskriminiert, aber eine nahezu null Korrelation mit dem binären Ausführungserfolg aufweist.

4. Evaluierungsergebnisse

Das Framework wurde an einer geschichteten Stichprobe von 423 Repositories aus einem Ground-Truth-Korpus evaluiert, die in fünf Fehlermodi kategorisiert wurden: Erfolg, Installations-Abhängigkeitsfehler, Fehlende Module, Fehlende Daten und Codefehler.

Diskriminierung von Fehlermodi: Die Kategorie Umgebung (E) zeigte die stärkste Fähigkeit zur Diskriminierung zwischen Fehlermodi (Kruskal-Wallis $H = 96,89, p < 0,001$ $H = 96, 89, p < 0, 001$ ).
- Das Detektionsparadoxon: Repositories mit Installations-Abhängigkeitsfehlern (install_dep) erzielten die höchsten Werte bei der Umgebung (Mittelwert 22,8), da sie Umgebungen explizit spezifizierten, scheiterten jedoch aufgrund von Versionskonflikten. Umgekehrt erzielten erfolgreiche Repositories niedrigere Werte (Mittelwert 10,3), da ihnen oft explizite Spezifikationen fehlten. Dies bestätigt, dass der RRS beschreibt, welche Art von Problem existiert, nicht ob es erfolgreich sein wird.
Binäre Korrelation: Die Korrelation zwischen RRS und binärem Ausführungserfolg war nahezu null ( $r_{pb} = -0,014$ ). Dies quantifiziert empirisch die Lücke zwischen Bereitschaft und Ergebnis: Ein hoher statischer Score sagt keinen erfolgreichen Lauf voraus.
Robustheit:
- Gewichtsstabilität: Die Rankings der Repositories blieben stabil ( $\tau \ge 0,911$ ), selbst wenn die Gewichte um $\pm 50\%$ gestört wurden.
- Gate-Unempfindlichkeit: Die Gate-Funktion hatte einen vernachlässigbaren Einfluss auf die binäre Vorhersage (AUC-Bereich $\approx 0,008$ ), was ihre Rolle als normatives Politikinstrument und nicht als prädiktiver Mechanismus bestätigt.
- Leave-One-Category-Out: Das Entfernen der Kategorien Umgebung oder Daten verbesserte tatsächlich den binären AUC, was weiter beweist, dass diese Kategorien dazu dienen, Fehlertypen zu charakterisieren und nicht den binären Erfolg vorherzusagen.
Composite-Validierung: Bei der teilweisen ROS-Validierung rangierte der RCS Repositories korrekt neu. So hatten install_dep-Repositories einen moderaten RRS (26,8), aber einen nahezu null ROS (13,5), was zu einem niedrigen RCS (19,8) führte und ihren Ausführungsmisserfolg trotz statischer Vollständigkeit genau widerspiegelte.

5. Bedeutung und Behauptungen

Die Arbeit positioniert ReproScore als diagnostisches Instrument für Kuratoren digitaler Bibliotheken und nicht als binären Erfolgsprädiktor.

Architektonische Notwendigkeit: Die Studie validiert, dass die Trennung von Bereitschaft und Ergebnis sowohl notwendig als auch nicht-trivial ist. Statische Signale erfassen bedeutende strukturelle Unterschiede (z. B. Unterscheidung zwischen einem fehlenden Modul und einem Versionskonflikt), die binäre Erfolgsmetriken verschleiern.
Kuratorischer Nutzen: Durch die Bereitstellung eines Profils auf Kategoriesebene ermöglicht ReproScore gezielte Abhilfemaßnahmen. Ein niedriger Umgebungs-Score deutet auf die Notwendigkeit des Pinning von Abhängigkeiten hin; ein niedriger Daten-Score deutet auf fehlende Verweise hin. Dies ist handlungsrelevanter als ein einzelner „Reproduzierbarkeits"-Score.
Skalierbarkeit: Der statische Erstansatz (RRS) ermöglicht es Bibliotheken, Millionen von Einreichungen zu triagieren, ohne die Rechenkosten sandgeboxter Ausführung, und reserviert Ausführungsressourcen für Artefakte, die vielversprechend sind oder eine spezifische Validierung erfordern.
Politiktransparenz: Der Community-Rubrik-Mechanismus verwandelt Bewertungsheuristiken von undurchsichtigem Code in überprüfbare, zitierbare Politiken und erleichtert den institutionenübergreifenden Vergleich und die domänenspezifische Anpassung (z. B. Priorisierung der Datenzugänglichkeit in der Bioinformatik).

Die Autoren schließen, dass ein Framework, das die Lücke zwischen Bereitschaft und Ergebnis explizit benennt, für Kuratierungsworkflows informativer ist als eines, das sie zusammenführt. ReproScore bietet die Infrastruktur, um diese Lücke zu verwalten, und unterstützt die OAIS-Entitäten „Ingest" und „Archival Storage" mit berechenbaren, skalierbaren Metriken.