Tuning: n_estimators & Co.
Die gute Nachricht zuerst: Random Forests sind erstaunlich unempfindlich gegenüber ihren Hyperparametern — die Defaults sind selten weit vom Optimum. Tuning lohnt sich trotzdem, aber anders als bei der SVM: weniger Suche, mehr Verständnis.
Prioritätenliste: 1.
n_estimators hoch genug (kein Tuning, nur Budget), 2. max_features, 3. min_samples_leaf / max_depth. Der Rest ist meist Rauschen.Die Parameter, die zählen
| Parameter | Wirkung | Praxis-Empfehlung |
|---|---|---|
n_estimators | Mehr Bäume = stabiler, nie schlechter — nur teurer. Der Score steigt und erreicht ein Plateau. | 200–500. OOB-Score gegen Baumzahl plotten, ab dem Plateau ist Schluss. |
max_features | Weniger Features pro Split = stärker dekorrelierte Bäume, aber schwächere Einzelbäume. Der Trade-off-Regler des Waldes. | "sqrt" als Anker; 0.1–0.3 × n_features gegentesten. |
min_samples_leaf | Größere Blätter = glattere Vorhersagen, kleinere Bäume, weniger Overfitting und weniger RAM. | 1 (Default), 2, 5 vergleichen. |
max_depth | Harte Obergrenze fürs Baumwachstum — grober als min_samples_leaf, dafür planbarer Speicher. | Meist None lassen und über min_samples_leaf steuern. |
class_weight | Gewichtet seltene Klassen in der Impurity-Berechnung höher. | Bei PlantVillage "balanced" gegentesten, Effekt am macro-F1 messen. |
Tuning mit dem OOB-Score statt Grid + CV
Der Wald bringt sein Validation-Set mit (Out-of-Bag, siehe Ensemble-Lektion) — für die Parametersuche reicht oft eine simple Schleife ohne Cross-Validation:
PYTHONrf_tuning.py
from sklearn.ensemble import RandomForestClassifier
for mf in ["sqrt", 0.1, 0.2, 0.3]:
for msl in [1, 2, 5]:
wald = RandomForestClassifier(
n_estimators=300,
max_features=mf,
min_samples_leaf=msl,
oob_score=True,
n_jobs=-1,
random_state=42,
)
wald.fit(X_train, y_train)
print(f"max_features={mf!s:5} min_samples_leaf={msl} "
f"OOB={wald.oob_score_:.4f}")
# Beste Kombi → einmal final aufs Test-Set.
# 12 Trainings statt 12 x 3 CV-Folds — der Wald validiert sich selbst.Warum eigentlich? — Warum ist der Wald so robust gegen schlechtes Tuning?
Bei LogReg und SVM verschiebt ein falsches C die eine gelernte Grenze global. Beim Wald wirken die Parameter nur auf einzelne Bäume — und deren Fehler werden anschließend weggemittelt. Das Ensemble dämpft also nicht nur die Varianz der Daten, sondern auch die Varianz schlechter Hyperparameter-Entscheidungen. Die Kehrseite: Tuning kann den Wald auch nur begrenzt verbessern. Wer mehr Qualität will, investiert beim RF besser in Features als in Parameter.
Häufiger Denkfehler — n_estimators per Grid Search optimieren wollen
n_estimators in ein Grid zu stecken ist doppelt verschwendet: Der Score steigt mit der Baumzahl monoton bis zum Plateau — es gibt kein Optimum zu finden, nur ein „genug“. Und statt für jede Baumzahl neu zu trainieren, kann man mit warm_start=True Bäume an einen bestehenden Wald anbauen und den OOB-Score nach jedem Schub messen. Eine Trainingsserie, die komplette Kurve.Tiefer rein — Wenn der Wald nicht reicht: Gradient Boosting
Auf Feature-Vektoren ist der natürliche nächste Schritt nicht „mehr Wald“, sondern Gradient Boosting (XGBoost, LightGBM, sklearns
HistGradientBoostingClassifier): Bäume werden sequenziell gebaut, jeder auf die Residualfehler der bisherigen. Boosting senkt — anders als Bagging — auch den Bias und gewinnt auf Tabellendaten fast jede Kaggle-Competition. Der Preis: echte Overfitting-Gefahr, Lernrate und Baumzahl müssen gemeinsam getunt werden, Early Stopping ist Pflicht. Der Wald bleibt der robuste Allrounder, Boosting der getunte Sportler.