Beyond Reproducible Research: Building a Formal Representation of a Data Analysis

Dieser Artikel stellt eine formale Repräsentation von Datenanalysen vor, die über die reine Reproduzierbarkeit hinausgeht, indem sie die logische Konstruktion und die zugrunde liegenden Annahmen des Analysten explizit macht, um eine datenunabhängige Bewertung, Visualisierung der Schlussfolgerungen und eine Sensitivitätsanalyse zu ermöglichen.

Das Wesentliche

Stellen Sie sich vor, Sie backen einen Kuchen und wollen Ihren Freunden beweisen, dass er wirklich so lecker ist, wie Sie sagen.

Das aktuelle Problem: Der "Rezept"-Ansatz
Heute ist es in der Wissenschaft üblich, einfach das Rezept (den Code) und die Zutatenliste (die Daten) zu veröffentlichen. Man sagt: "Hier ist die Liste der Schritte, die ich gemacht habe. Wenn ihr das Rezept nachkocht und den gleichen Kuchen bekommt, war meine Analyse korrekt."

Das Problem dabei ist: Ein Rezept sagt nur, was man tut (z. B. "2 Eier hinzufügen"), aber nicht warum man es tut oder was man erwartet.

• Was, wenn Sie versehentlich Salz statt Zucker genommen haben? Das Rezept sagt es nicht.
• Was, wenn Sie dachten, der Teig sei perfekt, obwohl er eigentlich noch flüssig war? Das Rezept zeigt es nicht.
• Was, wenn Sie eine geheime Zutat (eine Annahme) benutzt haben, die niemand kennt?

Wenn jemand das Rezept nachkocht, kann er vielleicht sehen, dass der Kuchen fertig ist, aber er versteht nicht die Logik dahinter. Er weiß nicht, ob der Bäcker wirklich wusste, was er tat, oder ob er einfach nur blindlings Zutaten in eine Schüssel geworfen hat.

Die Lösung des Papers: Der "Logische Bauplan"
Roger Peng schlägt vor, nicht nur das Rezept zu veröffentlichen, sondern einen formalen Bauplan, der die Gedanken des Analysten sichtbar macht.

Stellen Sie sich das wie einen Sicherheitscheck für einen Flug vor.

• Heute: Der Pilot sagt: "Ich habe den Motor gestartet, die Räder eingefahren und wir sind abgehoben." (Das ist der Code).
• Der neue Ansatz: Der Pilot muss vor jedem Schritt einen Checklisten-Eintrag bestätigen: "Ich habe den Motor gestartet, weil die Temperatur im grünen Bereich liegt und weil der Treibstandstand hoch genug ist. Nur wenn diese beiden Bedingungen erfüllt sind, darf der Motor starten."

In diesem Papier wird vorgeschlagen, Datenanalysen nicht als bloße Computerbefehle zu sehen, sondern als eine Kette von logischen Beweisen.

Wie funktioniert das? (Die Analogie der "Klassen" als Sicherheitsgürtel)
Der Autor nutzt eine Programmiermethode, die wie Sicherheitsgürtel oder Qualitätsstempel funktioniert.

1. Die Aussage (Der Stempel): Statt nur zu sagen "Der Durchschnittswert ist 4,6", definiert man eine "Sicherheitsklasse" namens Durchschnitt_ist_4,6.
2. Die Voraussetzungen (Die Gurte): Damit dieser Stempel gültig ist, müssen bestimmte Bedingungen erfüllt sein.
   • Bedingung A: Es gibt keine fehlenden Werte (keine Löcher im Gurtsystem).
   • Bedingung B: Es gibt keine extremen Ausreißer (keine Risse im Material).
   • Bedingung C: Die Verteilung sieht normal aus.

Nur wenn alle diese Bedingungen (die Gurte) sicher einrasten, darf der Computer den Stempel "Durchschnitt ist 4,6" drucken. Wenn eine Bedingung nicht erfüllt ist (z. B. ein fehlender Wert), weigert sich das System, den Stempel zu drucken, und gibt eine Fehlermeldung aus.

Warum ist das besser?

• Man muss nicht backen, um zu prüfen: Bei einem normalen Rezept muss man den Kuchen backen, um zu sehen, ob er gut ist. Bei diesem neuen Ansatz kann man den Bauplan lesen und sofort sehen: "Aha, hier wurde angenommen, dass keine Daten fehlen. Wenn die Daten aber Lücken haben, ist die ganze Schlussfolgerung ungültig." Man kann die Logik prüfen, ohne die Daten überhaupt zu sehen.
• Fehler finden, bevor sie passieren: Wenn Sie den Bauplan lesen, sehen Sie sofort: "Moment mal, dieser Bäcker hat keinen Sicherheitsgurt für 'Ausreißer' eingebaut!" Das hilft, Fehler zu finden, bevor jemand den falschen Kuchen isst.
• Verständnis statt Nachahmung: Es geht nicht darum, dass jemand anderes den Code 1:1 nachläuft (Reproduzierbarkeit), sondern darum, die Gedanken des Analysten zu verstehen. Warum hat er das gemacht? Was hat er erwartet?

Zusammenfassung
Das Paper sagt im Grunde: "Hören wir auf, nur die Zutatenliste zu zeigen. Zeigen wir stattdessen den Sicherheitsplan, der beweist, dass wir wissen, warum wir diese Zutaten auswählen und was passieren würde, wenn etwas schiefgeht."

Es verwandelt die Datenanalyse von einem "Zauberkasten" (hier ist der Code, hier ist das Ergebnis) in einen transparenten, logischen Beweis, bei dem jeder Schritt durch eine klare Regel untermauert wird. So wird die Wissenschaft nicht nur reproduzierbar, sondern auch verständlich und überprüfbar in ihrer Logik.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Beyond Reproducible Research: Building a Formal Representation of a Data Analysis" von Roger D. Peng auf Deutsch.

1. Problemstellung

Das Paper adressiert die Grenzen des aktuellen Paradigmas der reproduzierbaren Forschung (Reproducible Research). Obwohl die Veröffentlichung von Code und Daten es ermöglicht, Ergebnisse nachzuvollziehen, reicht dies nicht aus, um die logische Struktur und die Begründung einer Datenanalyse zu verstehen.

• Mangel an Kontext: Herkömmlicher Code ist imperativ (eine Abfolge von Befehlen). Er zeigt was getan wurde, aber nicht warum bestimmte Annahmen getroffen wurden oder welche Erwartungen der Analyst an die Daten hatte.
• Fehlende Beweisführung: Datenanalyse-Aussagen (z. B. „Der Mittelwert beträgt 4,6") werden in der wissenschaftlichen Literatur oft als wahr vorausgesetzt, ohne dass ein formaler Beweis für die Gültigkeit dieser Aussage vorliegt.
• Limitationen der Reproduzierbarkeit:
  • Reproduzierbarkeit ist oft ein dynamischer Prozess (Code muss ausgeführt werden), was ressourcenintensiv ist.
  • Sie setzt voraus, dass die Daten verfügbar sind (Problem bei sensiblen Daten).
  • Sie verhindert keine Fehler während der Analyse, sondern diagnostiziert sie nur nachträglich.
  • Ein fehlerfreier Programmablauf garantiert nicht, dass die analytische Logik korrekt ist.

Das Ziel des Papers ist es, eine formale, statische Repräsentation einer Datenanalyse zu entwickeln, die die logische Konstruktion und die Beweisführung externalisiert, ähnlich wie ein mathematischer Beweis.

2. Methodik

Der Autor schlägt ein System vor, das Datenanalyse-Aussagen als logische Konstrukte behandelt, die durch eine Hierarchie von Beweisen (Prämissen) gestützt werden. Die Implementierung erfolgt in der Programmiersprache R unter Verwendung des S4-Klassensystems.

Kernprinzipien:

1. Datenanalyse-Aussagen als Klassen-Definitionen:

   • Eine Aussage über die Daten (z. B. „Der Mittelwert ist 4,6") wird als S4-Klasse definiert.
   • Die Existenz eines gültigen Objekts dieser Klasse beweist, dass die Aussage wahr ist.
   • Jede Klasse verfügt über eine validity-Methode, die prüft, ob die zugrundeliegenden Daten die Definition erfüllen.

2. Prämissen als Klassenerweiterungen:

   • Um eine Hauptaussage zu stützen, werden unterstützende Prämissen (andere Datenanalyse-Aussagen) als Slots in der Hauptklasse integriert.
   • Dies erzeugt eine Hierarchie: Eine Hauptklasse (Konklusion) enthält Slots für Unterklassen (Prämissen), die wiederum eigene Prämissen haben können.
   • Dies zwingt den Analysten, explizit zu definieren, welche Bedingungen (z. B. „keine fehlenden Werte", „keine Ausreißer") erfüllt sein müssen, damit die Konklusion gilt.

3. Statische Analyse und Verifikation:

   • Da die Logik in den Klassendefinitionen kodiert ist, kann die Analyse statisch geprüft werden, ohne dass die Daten tatsächlich geladen oder der Code ausgeführt werden muss.
   • Man kann die Gültigkeit der Argumentationskette allein durch das Lesen des Codes (der Klassendefinitionen) nachvollziehen.

Implementierungsdetails:

• S4-Validierung: Die validity-Funktion einer Klasse wirft einen Fehler, wenn die Daten die Definition nicht erfüllen. Nur wenn keine Fehler auftreten, wird das Objekt erstellt.
• Beispiel (Mittelwert): Um zu beweisen, dass der Mittelwert 4,6 ist, wird eine Klasse mean_1st_col_df_is_4.6_WITH_premise definiert. Diese Klasse enthält Slots für Prämissen wie:
  • df_1st_col_no_missing: Die erste Spalte hat keine fehlenden Werte.
  • median_close_to_4.6: Der Median liegt nahe bei 4,6 (schließt Verschiebungen der Verteilung aus).
  • fivenum_no_outliers: Es gibt keine signifikanten Ausreißer.
• Visualisierung: Die Hierarchie der Prämissen kann als Baumdiagramm visualisiert werden, wobei Kindknoten durch logisches „UND" mit dem Elternknoten verknüpft sind.

3. Wichtige Beiträge

1. Formalisierung der Datenanalyse: Der Vorschlag, Datenanalyse nicht als bloßen Programmablauf, sondern als eine Kette von beweisbaren Aussagen zu betrachten, die durch logische Prämissen gestützt werden.
2. Externalisierung von Annahmen: Das System zwingt Analysten, ihre Erwartungen, Annahmen und Definitionen (z. B. was ist ein „Ausreißer"?) explizit im Code zu hinterlassen, anstatt sie implizit zu lassen.
3. Statische Evaluierung: Die Möglichkeit, die Qualität und Logik einer Analyse zu bewerten, ohne die Daten zu besitzen oder den Code auszuführen. Dies ist besonders wertvoll für sensible Daten oder zur Vorab-Prüfung von Analyseplänen.
4. Fehlervermeidung (Silent Errors): Das System hilft, „stille Fehler" zu erkennen, wie z. B. falsche Zusammenführungen von Datenframes aufgrund von Inkonsistenzen in Bezeichnungen (z. B. „US" vs. "USA"), da die Validierungsmethode der Zielklasse sofort einen Fehler meldet, wenn die erwartete Struktur (z. B. 3 Zeilen, keine NA-Werte) nicht erreicht wird.
5. Sensitivitätsanalyse: Durch die explizite Definition von Prämissen kann simuliert werden, wie robust die Schlussfolgerungen gegenüber unerwarteten Datenmerkmalen (z. B. starke Schiefe, Ausreißer) sind.

4. Ergebnisse und Beispiele

Das Paper demonstriert das Konzept an zwei Hauptbeispielen:

• Berechnung des Mittelwerts:

  • Traditioneller Code berechnet einfach den Mittelwert.
  • Der formale Ansatz definiert eine Klasse, die nur existiert, wenn der Mittelwert 4,6 ist UND wenn bewiesen ist, dass keine fehlenden Werte vorliegen, der Median nahe bei 4,6 liegt und keine Ausreißer existieren.
  • Die Visualisierung zeigt klar die logische Abhängigkeit: Die Konklusion ist nur wahr, wenn alle untergeordneten Prämissen wahr sind.

• Einfache lineare Regression:

  • Statt nur den Koeffizienten zu melden, wird eine Klasse definiert, die den Koeffizienten (z. B. 1,79) mit einer Reihe von Modellannahmen verknüpft (keine Nichtlinearität in den Residuen, keine Ausreißer, akzeptable Residuenplots).
  • Ein interessanter Aspekt ist die manuelle Bestätigung von Grafiken: Der Analyst muss interaktiv bestätigen, dass ein Residuenhistogramm „in Ordnung" aussieht, bevor das Objekt erstellt wird. Dies formalisiert den oft intuitiven Prozess der visuellen Überprüfung.

Ein Vergleich mit herkömmlichem Code zeigt, dass der formale Ansatz zwar mehr Codezeilen erfordert, aber deutlich mehr semantische Information über die Absicht und Gültigkeit der Analyse liefert.

5. Bedeutung und Fazit

Das Paper stellt einen Paradigmenwechsel dar: Von der Reproduzierbarkeit (Können wir das Ergebnis nachrechnen?) hin zur Verifizierbarkeit (Können wir die Logik und Gültigkeit der Argumentation beweisen?).

• Wissenschaftliche Qualität: Das System ermöglicht eine kritischere Bewertung von Datenanalysen, da die Annahmen und die Beweisführung transparent und überprüfbar sind.
• Verbindung zu anderen Feldern:
  • Es knüpft an das Prinzip „Propositions as Types" aus der Informatik an (die Existenz eines Objekts beweist die Wahrheit einer Aussage).
  • Die Baumstrukturen der Prämissen ähneln Fehlerbäumen (Fault Trees) aus dem Systems Engineering, wobei hier jedoch der Fokus auf dem Nachweis des Erfolgs (Wahrheit) liegt, nicht auf dem Nachweis des Versagens.
• Herausforderungen: Die aktuelle Implementierung mit S4-Klassen ist sehr ausführlich (verbose) und könnte den Arbeitsaufwand erhöhen. Das Paper schlägt vor, effizientere Systeme oder DSLs (Domain Specific Languages) zu entwickeln, um diese Logik leichter anwendbar zu machen.

Zusammenfassend argumentiert Peng, dass eine formale Repräsentation von Datenanalysen notwendig ist, um die Qualität der analytischen Argumentation zu sichern, die oft hinter dem bloßen Ausführen von Code verloren geht. Es ist ein Werkzeug zur Darstellung der Denkweise des Analysten, nicht nur ein Werkzeug zur Durchführung der Analyse.