Review Data Analysis

Datenanalyse reviewen

Eine Datenanalyse-Pipeline auf Korrektheit, Robustheit und Reproduzierbarkeit ueberpruefen.

Wann verwenden

• Review der Analyse-Notebooks oder Skripte eines Kollegen vor der Publikation
• Validierung einer Machine-Learning-Pipeline vor dem Produktionseinsatz
• Audit eines Analyseberichts fuer regulatorische oder geschaeftliche Entscheidungen
• Einschaetzung, ob eine Analyse ihre formulierten Schlussfolgerungen stuetzt
• Zweitanalysten-Review in einer regulierten Umgebung

Eingaben

• Erforderlich: Analysecode (Skripte, Notebooks oder Pipeline-Definitionen)
• Erforderlich: Analyseausgabe (Ergebnisse, Tabellen, Abbildungen, Modellmetriken)
• Optional: Rohdaten oder Datenlexikon
• Optional: Analyseplan oder Protokoll (vorab registriert oder ad-hoc)
• Optional: Zielgruppe und Entscheidungskontext

Vorgehensweise

Schritt 1: Datenqualitaet bewerten

Die Eingabedaten vor der Bewertung der Analyse ueberpruefen:

## Datenqualitaetsbewertung

### Vollstaendigkeit
- [ ] Fehlende Daten quantifiziert (% pro Spalte und pro Zeile)
- [ ] Mechanismus fehlender Daten beruecksichtigt (MCAR, MAR, MNAR)
- [ ] Imputationsmethode angemessen (falls verwendet) oder Vollfall-Analyse begruendet

### Konsistenz
- [ ] Datentypen entsprechen den Erwartungen (Datumsangaben sind Datum, Zahlen sind Zahlen)
- [ ] Werteranges sind plausibel (keine negativen Altersangaben, Zukunftsdaten in historischen Daten)
- [ ] Kategorische Variablen haben erwartete Auspraegungen (keine Tippfehler, einheitliche Kodierung)
- [ ] Einheiten sind ueber alle Datensaetze konsistent

### Eindeutigkeit
- [ ] Duplikate identifiziert und behandelt
- [ ] Primaerschluessel sind wo erwartet eindeutig
- [ ] Join-Operationen liefern erwartete Zeilenanzahl (kein Fan-out oder Verlust)

### Aktualitaet
- [ ] Datenvintage fuer die Analysefrage angemessen
- [ ] Zeitliche Abdeckung entspricht dem Studienzeitraum
- [ ] Kein Look-ahead-Bias in Zeitreihendaten

### Herkunft
- [ ] Datenquelle dokumentiert
- [ ] Extraktionsdatum/-version festgehalten
- [ ] Alle Transformationen zwischen Quelle und Analyseeingabe dokumentiert

Erwartet: Datenqualitaetsprobleme mit ihrem potenziellen Einfluss auf die Ergebnisse dokumentiert. Bei Fehler: Wenn die Daten fuer den Review nicht zugaenglich sind, die Qualitaet aus dem Code beurteilen (welche Pruefungen und Transformationen werden angewendet).

Schritt 2: Annahmen pruefen

Fuer jede verwendete statistische Methode oder jedes Modell:

## Ergebnisse der Annahmenprüfung
| Analyseschritt | Methode | Annahme | Geprueft? | Ergebnis |
|---------------|--------|------------|----------|--------|
| Primaermodell | Lineare Regression | Normalverteilung der Residuen | Ja | Q-Q-Plot zeigt leichte Abweichung — akzeptabel fuer n>100 |
| Primaermodell | Lineare Regression | Homoskedastizitaet | Nein | Nicht geprueft — Breusch-Pagan-Test empfohlen |

Erwartet: Jede statistische Methode hat ihre Annahmen explizit geprueft oder anerkannt. Bei Fehler: Wenn Annahmen verletzt sind, pruefen, ob die Autoren dies berucksichtigt haben (robuste Methoden, Transformationen, Sensitivitaetsanalyse).

Schritt 3: Data Leakage erkennen

Data Leakage tritt auf, wenn Informationen ausserhalb des Trainingssets das Modell beeinflussen und zu uebertrieben optimistischer Leistung fuehren:

Haeufige Leakage-Muster:

• Target Leakage: Feature, das die Zielvariable direkt kodiert (z. B. "treatment_outcome" zur Vorhersage von "treatment_success")
• Temporales Leakage: Zukuenftige Informationen zur Vorhersage der Vergangenheit (Features aus Daten, die zum Prognosezeitpunkt nicht verfuegbar waeren)
• Train-Test-Kontamination: Vorverarbeitung (Skalierung, Imputation, Feature-Selektion) auf dem gesamten Datensatz vor dem Aufteilen
• Gruppen-Leakage: Verwandte Beobachtungen (gleicher Patient, gleiches Geraet) auf Train- und Testsets aufgeteilt
• Feature-Engineering-Leakage: Aggregate ueber den gesamten Datensatz statt innerhalb des Trainingsfolds berechnet

## Leakage-Bewertung
| Pruefung | Status | Nachweis |
|-------|--------|----------|
| Target Leakage | Unbedenklich | Keine aus dem Ziel abgeleiteten Features |
| Temporales Leakage | BEDENKEN | Feature X verwendet 30-Tage-Vorwaertsanalyse |
| Train-Test-Kontamination | Unbedenklich | StandardScaler nur auf Train angepasst |
| Gruppen-Leakage | BEDENKEN | Patienten-IDs nicht fuer geschichtete Aufteilung verwendet |

Erwartet: Alle haeufigen Leakage-Muster mit klar/Bedenken-Status geprueft. Bei Fehler: Wenn Leakage gefunden wird, dessen Auswirkung abschaetzen, indem ohne das durchgesickerte Feature neu ausgewertet wird (wenn moeglich), oder fuer den Analysten zur Untersuchung markieren.

Schritt 4: Modellleistung validieren

Fuer Prognosemodelle:

• Angemessene Metriken fuer das Problem (nicht nur Genauigkeit — Praezision, Recall, F1, AUC, RMSE, MAE beruecksichtigen)
• Kreuzvalidierungs- oder Holdout-Strategie beschrieben und angemessen
• Leistung auf Trainings- vs. Test-/Validierungsset verglichen (Overfitting-Pruefung)
• Baseline-Vergleich angegeben (naives Modell, Zufallszufall, frueherer Ansatz)
• Konfidenzintervalle oder Standardfehler fuer Leistungsmetriken
• Leistung auf relevanten Untergruppen bewertet (Fairness, Grenzfaelle)

Fuer inferenzielle/erklaerende Modelle:

• Modellanpassungsstatistiken berichtet (R², AIC, BIC, Devianz)
• Koeffizienten korrekt interpretiert (Richtung, Groesse, Signifikanz)
• Multikollinearitaet bewertet (VIF < 5–10)
• Einflussreiche Beobachtungen identifiziert (Cook's Distanz, Leverage)
• Modellvergleich wenn mehrere Spezifikationen getestet

Erwartet: Modellvalidierung angemessen fuer den Anwendungsfall (Prognose vs. Inferenz). Bei Fehler: Wenn die Testset-Leistung verdaechtig nah an der Trainingsleistung ist, potenzielles Leakage markieren.

Schritt 5: Reproduzierbarkeit bewerten

## Reproduzierbarkeits-Checkliste
| Punkt | Status | Anmerkungen |
|------|--------|-------|
| Code laeuft fehlerfrei | [Ja/Nein] | Getestet auf [Umgebungsbeschreibung] |
| Zufallsseeds gesetzt | [Ja/Nein] | Zeile [N] in [Datei] |
| Abhaengigkeiten dokumentiert | [Ja/Nein] | requirements.txt / renv.lock vorhanden |
| Datenladen reproduzierbar | [Ja/Nein] | Pfad ist [relativ/absolut/URL] |
| Ergebnisse stimmen mit berichteten Werten ueberein | [Ja/Nein] | Verifiziert: Tabelle 1 ✓, Abbildung 2 ✗ (geringfuegige Abweichung) |
| Umgebung dokumentiert | [Ja/Nein] | Python 3.11 / R 4.5.0 angegeben |

Erwartet: Reproduzierbarkeit durch erneute Ausfuehrung der Analyse verifiziert (oder aus dem Code bewertet, wenn Daten nicht verfuegbar sind). Bei Fehler: Wenn sich Ergebnisse nicht exakt reproduzieren lassen, bestimmen, ob Unterschiede innerhalb der Gleitkomma-Toleranz liegen oder auf ein Problem hinweisen.

Schritt 6: Das Review verfassen

## Datenanalyse-Review

### Gesamtbewertung
[1-2 Saetze: Ist die Analyse solide? Stuetzt sie die Schlussfolgerungen?]

### Datenqualitaet
[Zusammenfassung der Datenqualitaetsbefunde, Auswirkungen auf die Ergebnisse]

### Methodische Bedenken
1. **[Titel]**: [Beschreibung, Stelle im Code/Bericht, Vorschlag]
2. ...

### Staerken
1. [Was gut gemacht wurde]
2. ...

### Reproduzierbarkeit
[Stufenbewertung: Gold/Silber/Bronze/Undurchsichtig mit Begruendung]

### Empfehlungen
- [ ] [Spezifische Handlungsaufgaben fuer den Analysten]

Erwartet: Review liefert umsetzbare Rueckmeldungen mit spezifischen Verweisen auf Codestellen. Bei Fehler: Bei Zeitdruck Datenqualitaet und Leakage-Prüfungen vor Stilproblemen priorisieren.

Validierung

• Datenqualitaet in Bezug auf Vollstaendigkeit, Konsistenz, Eindeutigkeit, Aktualitaet, Herkunft bewertet
• Statistische Annahmen fuer jede verwendete Methode geprueft
• Data Leakage systematisch bewertet
• Modellleistung mit angemessenen Metriken und Baselines validiert
• Reproduzierbarkeit bewertet (Code laeuft, Ergebnisse stimmen ueberein)
• Rueckmeldungen sind spezifisch und verweisen auf Codezeilen oder Berichtsabschnitte
• Ton ist konstruktiv und kollaborativ

Haeufige Stolperfallen

• Nur den Code reviewen: Analyseplan und Schlussfolgerungen sind ebenso wichtig wie die Implementierung.
• Datenqualitaet ignorieren: Anspruchsvolle Modelle auf schlechten Daten liefern selbstsichere falsche Antworten.
• Korrektheit aus Komplexitaet annehmen: Ein Random Forest mit 95% Genauigkeit koennte Data Leakage haben; ein einfacher t-Test koennte der richtige Ansatz sein.
• Den Code nicht ausfuehren: Wenn irgend moeglich, den Code ausfuehren, um die Reproduzierbarkeit zu verifizieren. Das Lesen von Code reicht nicht.
• Den Wald vor lauter Baeumen nicht sehen: Nicht in Codestilproblemen verlieren und dabei einen grundlegenden Analysefehler uebersehen.

Verwandte Skills

• review-research — breitere Forschungsmethodik und Manuskript-Review
• validate-statistical-output — Doppelprogrammierungs-Verifikationsmethodik
• generate-statistical-tables — publikationsreife statistische Tabellen
• review-software-architecture — Codestruktur- und Design-Review