feautre(workshops): add workshop 6

2026-06-04 15:26:57 +02:00
parent 6d6cc9f917
commit d1872712c4
10 changed files with 10309 additions and 0 deletions
@@ -0,0 +1,102 @@
+# Workshop 06 — RandomForestClassifier: Parameter Tuning
+
+## Aufgabe
+
+Drei Tuning-Parameter des `RandomForestClassifier` auf die erreichte Accuracy
+untersuchen (vorbereiteter Bank-Datensatz, identisch zu WS5), je über einen
+vorgegebenen Wertebereich:
+
+| Parameter              | Wertebereich              | Typ   |
+|------------------------|---------------------------|-------|
+| `n_estimators`         | `range(100, 500, 50)`     | int   |
+| `max_features`         | `range(1, 11)`            | int   |
+| `min_impurity_decrease`| `np.arange(0, 0.1, 0.01)` | float |
+
+Zusätzlich: Wirkung von `random_state` einordnen, und (Zusatzfrage) bestimmen,
+welche der übrigen Parameter keine Tuning-Parameter sind.
+
+## Vorgehen
+
+Wiederverwendung des Sweep-/Plot-Gerüsts aus WS5. Die einzige Anpassung war die
+Generalisierung der Sweep-Funktion auf einen frei wählbaren Parameternamen
+(`set_params` per dict-Unpacking), womit sich alle drei Parameter mit derselben
+Funktion abdecken lassen. Jeder Sweep hält die übrigen Parameter auf den
+Defaults und variiert nur den untersuchten.
+
+Pro Sweep: Liniendiagramm (Parameter vs. Accuracy) mit markiertem Maximum sowie
+Konsolenausgabe von bestem Score und zugehörigem Parameterwert.
+
+`n_jobs=-1` gesetzt — bei bis zu 450 Bäumen pro Fit und mehreren Fits pro Sweep
+ist die Parallelisierung über alle Cores hier praktisch zwingend, nicht
+optional. `n_jobs` ist dabei reiner Performance-Schalter ohne Einfluss auf das
+Resultat.
+
+## Resultate
+
+| Parameter              | bester Score | bei Wert |
+|------------------------|--------------|----------|
+| `n_estimators`         | 0.8792       | 400      |
+| `max_features`         | 0.8780       | 6        |
+| `min_impurity_decrease`| 0.8750       | 0.0      |
+
+Interpretation der einzelnen Verläufe:
+
+**`n_estimators`** — die Kurve bewegt sich über den gesamten Bereich nur
+zwischen 0.875 und 0.879. Diese Schwankung liegt im Bereich des Seed-Rauschens
+und ist kein echtes Optimum. Die belastbare Aussage lautet: Plateau ab ~150
+Bäumen, danach reine Rechenzeit ohne Mehrwert. Der nominelle „Peak" bei 400 ist
+nicht als optimaler Wert zu interpretieren.
+
+**`max_features`** — hier liegt echtes Signal vor: Anstieg von ~0.857 (bei 1)
+auf ein breites Maximum ab ~4 Features. Der beste Wert (6) liegt nahe am
+sklearn-Default `sqrt(n_features)` für Klassifikation, was den Default bestätigt.
+Zu kleine Werte machen die einzelnen Bäume zu zufällig (Underfit); zu grosse
+Werte erhöhen die Korrelation zwischen den Bäumen und schmälern den
+Ensemble-Vorteil.
+
+**`min_impurity_decrease`** — bestes Resultat bei 0 (kein Pruning), danach
+monotoner Abfall auf ein Plateau bei ~0.757. Das ist das aufschlussreichste
+Ergebnis des Workshops und der direkte Kontrast zu WS5: beim einzelnen
+DecisionTree hat Pre-Pruning das Overfitting reduziert und die Test-Accuracy
+verbessert. Beim Random Forest übernimmt das Bagging diese Varianzkontrolle
+bereits auf Ensemble-Ebene — Pruning der einzelnen Bäume nimmt ihnen die
+gewollte Varianz und kann die Accuracy daher praktisch nur verschlechtern.
+
+## Wirkung von `random_state`
+
+Der Random Forest hat zwei Zufallsquellen: das Bootstrap-Sampling (welche Zeilen
+jeder Baum sieht) und die Random Feature Selection (welche Features pro Split zur
+Wahl stehen). `random_state` seedet beide und macht den Lauf reproduzierbar.
+
+Der Effekt des konkreten Seeds nimmt mit steigendem `n_estimators` ab: bei wenig
+Bäumen schwankt die Accuracy je nach Seed merklich, bei vielen Bäumen mittelt
+sich das aus. Ein Teil der Zacken im `n_estimators`-Verlauf ist genau diese
+Seed-Variation und nicht echtes Signal — siehe Interpretation oben.
+
+## Zusatzfrage: Nicht-Tuning-Parameter
+
+Kriterium: ein Tuning-Parameter verschiebt den Bias-Varianz-Tradeoff bzw. die
+Kapazität des Modells. Parameter, die nur Infrastruktur, Reproduzierbarkeit,
+Logging, Workflow oder Reporting steuern, sind keine Tuning-Parameter. Aus
+`model.get_params()` betrifft das:
+
+- `random_state` — Seed (Reproduzierbarkeit)
+- `n_jobs` — Parallelisierung (Performance)
+- `verbose` — Logging-Ausgabe
+- `warm_start` — Workflow-Schalter für inkrementelles Fitten
+- `oob_score` — schaltet nur die Out-of-Bag-Schätzung als Reporting an, ändert
+  das gefittete Modell nicht
+
+Grenzfälle wie `bootstrap`, `class_weight` oder `max_samples` beeinflussen das
+Modell hingegen sehr wohl und zählen damit zu den Tuning-Parametern.
+
+## Caveats / Deviations
+
+- **One-at-a-time-Tuning**: jeder Parameter wurde einzeln bei Defaults der
+  übrigen variiert. Damit werden Wechselwirkungen zwischen Parametern nicht
+  erfasst; das gemeinsame Optimum kann von der Kombination der drei
+  Einzelbestwerte abweichen. Eine gemeinsame Suche (`GridSearchCV`, vgl. WS4)
+  wäre dafür das richtige Werkzeug.
+- **Optimistic Bias**: wie in WS4/WS5 wird direkt gegen das Test-Set getunt. Die
+  berichteten Bestwerte sind dadurch optimistisch verzerrt; sauber wäre ein
+  Validierungs-Split bzw. Cross-Validation.