Klausurzusammenfassung: Validation and Resampling

1. Überblick und klausurrelevanter Kern

Resampling-Methoden sind Verfahren, mit denen aus vorhandenen Daten mehrere Trainings- und Validierungssituationen erzeugt werden. Das Ziel ist nicht, magisch mehr unabhängige Daten zu erzeugen, sondern die Modellgüte robuster einzuschätzen und Entscheidungen wie Modellauswahl, Feature Selection oder Hyperparameterwahl ohne Blick auf den finalen Testdatensatz zu treffen.

Gliederung

1. Begriffe und Datenaufteilung
2. Hold-out Validation
3. K-fold Cross-Validation und LOOCV
4. Bootstrap
5. Datenleckage und falsche Validierung
6. Gesamtprozess nach dem Resampling
7. Auto-Daten-Beispiel
8. Typische Klausuraufgaben
9. Lerncheckliste und Klausurfragen
10. Folienabdeckung

2. Motivation, Fehlerbegriffe und Datenaufteilung

2.1 Trainingsfehler, Validierungsfehler und Testfehler

Der Trainingsfehler misst, wie gut ein Modell die Daten vorhersagt, auf denen es angepasst wurde. Er ist nützlich, um den Trainingsprozess zu beobachten, aber er ist keine verlässliche Aussage über neue Daten. Ein sehr kleiner Trainingsfehler kann durch Overfitting entstehen: Das Modell hat Muster oder Rauschen der Trainingsdaten gelernt, die außerhalb dieser Daten nicht stabil sind.

Der Testfehler schätzt die Leistung auf neuen, ungesehenen Daten. Er soll erst am Ende verwendet werden, wenn Modellklasse, Features, Hyperparameter und sonstige Entscheidungen feststehen. Sobald der Testdatensatz zur Auswahl oder Optimierung genutzt wird, ist er kein neutraler Test mehr.

Der Validierungsfehler ist die Vorabschätzung des Testfehlers innerhalb des Entwicklungsprozesses. Er darf für Entscheidungen verwendet werden, weil er nicht der finale Test ist. Er ist aber ebenfalls nur eine Schätzung und kann je nach Split stark schwanken.

2.2 Warum nicht nur Train/Test?

Eine einfache Zweiteilung in Training und Test ist nur dann sauber, wenn der Testdatensatz ausschließlich für die finale Bewertung genutzt wird. In realen Modellierungsprozessen müssen aber Entscheidungen getroffen werden: Welche Features werden genutzt? Welche Modellklasse? Welche Hyperparameter? Welcher Polynomgrad? Diese Entscheidungen dürfen nicht am Testdatensatz optimiert werden.

Ein zweites Problem ist die Unsicherheit der Bewertung: Ein einzelner Testdatensatz liefert nur eine einzige Beobachtung des Fehlers. Man sieht nicht, wie stark die Bewertung schwanken würde, wenn die Daten geringfügig anders gezogen worden wären.

2.3 Saubere Rollen: Training, Validierung, Test

Die Vorlesung nennt die nicht als Testdaten abgetrennten Daten Dev-Set oder Entwicklungsdaten. Das Dev-Set wird je nach Resampling-Verfahren wiederholt in Trainings- und Validierungsanteile zerlegt. Die Begriffe sind in der Literatur nicht einheitlich; für die Klausur ist entscheidend, die Rollen sauber zu trennen.

2.4 Varianz der Fehlerschätzung

Eine einzelne Validierung kann zufällig günstig oder ungünstig sein. Resampling erzeugt mehrere Validierungsbeobachtungen, sodass neben dem durchschnittlichen Fehler auch seine Streuung sichtbar wird. Das ist wichtig, um robuste Modelle zu erkennen: Zwei Modelle mit fast gleichem mittlerem Fehler können sich stark darin unterscheiden, wie stabil dieser Fehler über verschiedene Splits ist.

3. Hold-out Validation

3.1 Idee und Ablauf

Bei Hold-out Validation wird das Dev-Set zufällig in Trainingsdaten und Validierungsdaten geteilt. Das Modell wird auf dem Trainingsanteil angepasst und anschließend auf dem Validierungsanteil bewertet. Um die Abhängigkeit von einem einzelnen Split zu verringern, kann der Vorgang mehrfach mit verschiedenen zufälligen Splits wiederholt werden.

1. Testdaten zuerst abtrennen und nicht verwenden.
2. Dev-Set zufällig in Trainings- und Validierungsteil splitten.
3. Modell nur auf dem Trainingssplit trainieren.
4. Fehler auf dem Validierungssplit berechnen.
5. Mehrfach wiederholen und Mittelwert sowie Streuung auswerten.

3.2 Formeln

3.3 Vorteile

• Einfach zu verstehen und leicht zu implementieren.
• Rechenaufwand ist überschaubar, besonders bei wenigen Wiederholungen.
• Gut geeignet als schneller erster Plausibilitätscheck.

3.4 Nachteile

• Die Fehlerschätzung kann stark vom zufälligen Split abhängen.
• Ein Teil des Dev-Sets wird nicht zum Training genutzt; dadurch ist das Modell schwächer als ein späteres Modell, das auf dem gesamten Dev-Set trainiert wird.
• Der Validierungsfehler neigt deshalb zur Überschätzung des späteren Testfehlers des finalen Modells.
• Bei kleinen Datensätzen ist die Streuung besonders problematisch.

4. K-fold Cross-Validation und LOOCV

4.1 Grundidee

Bei K-fold Cross-Validation wird das Dev-Set zufällig in k nicht überlappende, möglichst gleich große Teilmengen zerlegt. Jede Teilmenge ist genau einmal Validierungsfold; alle übrigen Teilmengen bilden in dieser Runde die Trainingsdaten. Am Ende werden die k Fehlerschätzungen aggregiert.

4.2 Formel für den Cross-Validation-Fehler

4.3 Bias-Variance-Tradeoff bei k

Jedes Trainingsset in K-fold Cross-Validation enthält den Anteil (k - 1) / k des Dev-Sets. Ein kleines k bedeutet kleinere Trainingssets und tendenziell pessimistischere Fehler, aber größere Validierungssets und oft stabilere Fold-Fehler. Ein großes k bedeutet größere Trainingssets und weniger Bias, aber kleinere Validierungssets und stärker korrelierte Modellschätzungen.

4.4 Leave-One-Out Cross-Validation

Leave-One-Out Cross-Validation ist der Spezialfall k = n_dev. Jeder Fold enthält genau eine Beobachtung, und es müssen grundsätzlich n_dev Modelle trainiert werden. Für manche Modelle existieren mathematische Abkürzungen, aber konzeptionell ist LOOCV teuer.

LOOCV kann nützlich sein, wenn extrem wenige Daten vorhanden sind. Es ist aber nicht automatisch besser: Die Trainingsmengen variieren kaum, und die Fehlerschätzungen können dadurch stark korreliert sein. Die Vorlesung betont deshalb die hohe Varianz als wichtiges Problem.

4.5 Praktische Wahl von k

Werte im Bereich k = 5 bis k = 10 sind häufig ein guter Kompromiss. Bei Millionen Datenpunkten und einfachen Modellen kann ein deutlich größeres k sinnvoll sein. Bei sehr wenigen Datenpunkten und komplexen Modellen kann sogar k = 5 bereits zu groß sein.

5. Bootstrap

5.1 Idee

Bootstrap ist eine Alternative zu Hold-out und K-fold Cross-Validation. Aus dem Dev-Set wird mit Zurücklegen eine Trainingsmenge gezogen, bis sie wieder die Größe des Dev-Sets hat. Einzelne Beobachtungen können mehrfach vorkommen, andere gar nicht. Die nicht gezogenen Beobachtungen können als Validierungsdaten verwendet werden.

Der Name meint im statistischen Kontext sinngemäß, dass man aus den vorhandenen Daten selbst eine Schätzung der Unsicherheit gewinnt. Das ist nicht dasselbe wie das Booten eines Computersystems.

5.2 Bootstrap-Prozess

1. Testdaten abtrennen und unangetastet lassen.
2. Aus dem Dev-Set mit Zurücklegen n_dev Beobachtungen ziehen.
3. Modell auf dieser Bootstrap-Trainingsmenge trainieren.
4. Nicht gezogene Beobachtungen als Validierungs- oder Out-of-Bag-Daten auswerten.
5. Den Prozess B-mal wiederholen und die Fehlerschätzungen aggregieren.

5.3 Eigenschaften

• Trainingsmengen haben formal dieselbe Größe wie das Dev-Set, enthalten aber Duplikate.
• Validierungsdaten entstehen als nicht gezogene Beobachtungen und sind deshalb je Wiederholung unterschiedlich groß.
• Bootstrap wird nicht nur zur Modellvalidierung genutzt, sondern auch zur Schätzung von Unsicherheit statistischer Kennzahlen und in Ensemble-Methoden wie Bagging oder Random Forests.
• Im Auto-Beispiel liegt Bootstrap hinsichtlich Bias und Varianz zwischen Hold-out und Cross-Validation.

6. Falsche Validierung und Datenleckage

6.1 Das Beispiel aus der Vorlesung

Das Skript zeigt ein binäres Klassifikationsproblem mit 100 Datenpunkten und 5000 Features. Die Klassenlabels werden zufällig erzeugt. Es gibt also keinen echten Zusammenhang zwischen Features und Klasse. Trotzdem wird zuerst über alle Daten die Korrelation jedes Features mit dem Label berechnet, dann werden die 100 am stärksten korrelierten Features ausgewählt, und erst danach wird 5-fold Cross-Validation mit Random Forest durchgeführt.

Das Ergebnis wirkt spektakulär gut: Die Validierung meldet ungefähr 97 % Accuracy. Das ist offensichtlich falsch, weil rein zufällige Daten keine stabile Vorhersage erlauben. Die Ursache ist Datenleckage.

6.2 Warum ist das falsch?

Die Feature Selection hat bereits alle Labels gesehen, auch die späteren Validierungslabels. Damit steckt Information aus den Validierungsdaten in der Feature-Auswahl. Die Cross-Validation validiert nur den Modellfit nach der Feature-Auswahl, aber nicht den gesamten Modellierungsprozess.

6.3 Der richtige Weg

Für jeden Fold muss die Feature-Auswahl ausschließlich auf den Trainingsdaten dieses Folds durchgeführt werden. Danach wird dieselbe ausgewählte Feature-Menge auf die Validierungsdaten angewendet. Erst dann wird der Fold-Fehler berechnet.

Für jeden Fold:
  1. Trainings- und Validierungsteil festlegen.
  2. Feature Selection nur auf dem Trainingsteil fitten.
  3. Modell nur mit diesen Trainingsfeatures fitten.
  4. Genau diese Feature-Auswahl auf den Validierungsteil anwenden.
  5. Validierungsfehler berechnen.

In der Praxis sollte man dafür Pipelines oder Workflow-Objekte verwenden, die Vorverarbeitung und Modelltraining gemeinsam resamplen. Die Vorlesung warnt ausdrücklich, dass komfortable Softwarefunktionen zu falscher Reihenfolge verleiten können.

6.4 Nicht nur künstliche Daten

Das Problem tritt besonders häufig bei hochdimensionalen Daten auf, etwa in Genexpressions- oder Microarray-Analysen. Die Folien nennen Ambroise und McLachlan (2002) als Beispiel für Selection Bias bei der Genextraktion. Der zentrale Punkt für die Klausur ist nicht die konkrete Studie, sondern das Muster: Je mehr Features geprüft werden, desto wahrscheinlicher findet man zufällige Scheinkorrelationen.

6.5 Lab-Aufgabe aus dem Skript

Die Lab-Aufgabe fordert, experimentell zu zeigen, dass das scheinbar sehr gute Modell in Wirklichkeit schlecht ist. Eine saubere Lösung wäre: Einen frischen Testdatensatz mit demselben Zufallsmechanismus erzeugen oder den kompletten Prozess korrekt innerhalb der Cross-Validation wiederholen. Erwartet wird dann ungefähr Zufallsniveau, also bei balancierter binärer Klassifikation etwa 50 % Accuracy.

7. Gesamtprozess nach dem Resampling

7.1 Welches Modell nimmt man nach vielen Resampling-Läufen?

Nach Resampling wurden viele Modelle trainiert und validiert. Diese Modelle dienen in erster Linie der Schätzung und Auswahl. Sobald die Modellklasse, Hyperparameter, Features und sonstigen Entscheidungen feststehen, wird das finale Modell möglichst auf dem gesamten Dev-Set trainiert. Dadurch gehen keine Validierungsdaten für das finale Training verloren.

1. Testdaten zu Beginn abtrennen.
2. Resampling nur auf dem Dev-Set durchführen.
3. Mit Validierungsfehlern Modellentscheidungen treffen.
4. Finales Modell mit der gewählten Konfiguration auf dem gesamten Dev-Set trainieren.
5. Einmalig auf dem Testdatensatz auswerten.

7.2 Unsicherheit des Testfehlers

Auch die finale Testauswertung ist nur eine Beobachtung des Fehlers. Die Vorlesung nennt erneutes Resampling von Dev/Test-Splits als unüblich, kompliziert und aufwendig. Praktischer ist häufig ein Bootstrap des Testdatensatzes zur Streuung des Fehlers, wobei nur die Testfehlerwerte resampled werden; das Modell wird dabei nicht neu trainiert.

7.3 Datenstruktur beachten

Resampling darf die Datenstruktur nicht zerstören. Bei Zeitreihen ist zufälliges Ziehen einzelner Beobachtungen oft falsch, weil zeitliche Abhängigkeiten verloren gehen und Zukunftsinformation in die Vergangenheit gelangen kann. Dann braucht man zeitbasierte Splits oder blockweises Ziehen.

8. Auto-Daten-Beispiel: Hold-out, CV und Bootstrap

8.1 Fragestellung und Metrik

Im Zusatzbeispiel wird untersucht, welcher Polynomgrad d ∈ {1, 2, 3, 4, 5, 6, 7} für ein lineares polynomielles Modell der Auto-Daten geeignet ist. Modelliert wird mpg über weight, acceleration und year. Das Skript trennt zunächst Testdaten und Dev-Set und bewertet dann für jeden Polynomgrad Trainings-, Validierungs- und Testfehler.

8.2 Hold-out im Auto-Beispiel

Für jeden Polynomgrad werden wiederholt zufällige Trainings- und Validierungssplits aus dem Dev-Set erzeugt. Die Ergebnisse zeigen hohe Streuung in Trainings- und Validierungsfehlern. Der Validierungsfehler überschätzt den Testfehler besonders bei größeren Polynomgraden.

8.3 Cross-Validation im Auto-Beispiel

Mit k = 20 wird jeder Fold einmal als Validierung verwendet. Die Varianz des Validierungsfehlers ist deutlich geringer als bei Hold-out. In diesem Beispiel unterschätzt der Validierungsfehler den Testfehler.

8.4 Bootstrap im Auto-Beispiel

Beim Bootstrap werden für jeden Polynomgrad Trainingsdaten mit Zurücklegen gezogen. Die nicht gezogenen Beobachtungen dienen als Validierungsdaten. Im Beispiel überschätzt Bootstrap den Testfehler, aber weniger stark als Hold-out, und die Varianz ist geringer als bei Hold-out. Insgesamt liegt Bootstrap hier zwischen Hold-out und Cross-Validation.

8.5 Diagrammdeutung für die Klausur

• Trainingsfehler sinkt bei flexibleren Modellen oft, ist aber kein Beweis für gute Generalisierung.
• Große Streuung der Validierungsfehler bedeutet unsichere Modellwahl.
• Der Vergleich von Validierungs- und Testfehler zeigt, ob die Validierung in diesem Beispiel pessimistisch oder optimistisch war.
• Die beste Modellkomplexität sollte nicht nur nach minimalem Validierungsfehler, sondern auch nach Stabilität und Plausibilität beurteilt werden.

9. Methodenvergleich

10. Typische Klausuraufgaben und Rechenwege

10.1 K-fold-Fehler berechnen

10.2 Trainingsanteil bei K-fold bestimmen

10.3 Bootstrap-Out-of-Bag-Anteil erklären

10.4 Datenleckage identifizieren

10.5 Geeignete Methode begründen

11. Häufige Fehler und Prüfungsfallen

• Testdaten für Entscheidungen nutzen: macht den Testfehler optimistisch und nicht mehr final.
• Feature Selection vor Cross-Validation: erzeugt Datenleckage, besonders gefährlich bei vielen Features und wenigen Beobachtungen.
• Vorverarbeitung außerhalb der Folds fitten: auch Skalierung, Imputation und PCA müssen innerhalb des Trainingsanteils gelernt werden.
• Ein Fold-Modell als finales Modell nehmen: Nach der Auswahl wird das finale Modell auf dem gesamten Dev-Set trainiert.
• Fold-Fehler falsch mitteln: Ungleich große Folds brauchen Gewichtung.
• LOOCV pauschal als beste Methode darstellen: LOOCV hat oft hohe Varianz und hohen Rechenaufwand.
• Zeitreihen zufällig shuffeln: zerstört zeitliche Struktur und kann Zukunftsinformation leaken.
• Validierungsfehler als echten Testfehler verkaufen: Validierung ist eine Schätzung für Entscheidungen, nicht die finale Generalisierungsprüfung.