cas-pml/SL/aufgaben/workshop6

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.