Tuning: C, Solver & Fallstricke

Logistic Regression hat erfreulich wenige Stellschrauben — aber die wenigen muss man verstehen. Und es gibt einen Fallstrick, der mehr Punkte kostet als jedes Tuning bringt: vergessenes Skalieren.

Wichtigster Knopf: C — die inverse Regularisierungsstärke. Kleines C = starke Regularisierung = einfacheres Modell. Großes C = das Modell darf den Trainingsdaten mehr glauben.

C verstehen statt raten

	C zu klein (z.B. 0.001)	C zu groß (z.B. 1000)
Effekt	Gewichte werden gegen 0 gedrückt	Regularisierung praktisch aus
Symptom	Train- UND Test-Score schlecht (Underfitting)	Train-Score top, Test-Score fällt ab (Overfitting)
Diagnose	Train- und Validation-Score gemeinsam über C plotten — die Lücke zwischen beiden Kurven erzählt die Geschichte

PYTHONtuning.py — Grid Search über C

from sklearn.model_selection import GridSearchCV
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

pipe = make_pipeline(
    StandardScaler(),
    LogisticRegression(max_iter=2000, n_jobs=-1),
)

suche = GridSearchCV(
    pipe,
    param_grid={"logisticregression__C": [0.01, 0.1, 1, 10, 100]},
    cv=3,                    # 3-Fold CV auf den Trainingsdaten
    scoring="f1_macro",      # NICHT accuracy — Klassen sind unbalanciert!
    n_jobs=-1,
)
suche.fit(X_train, y_train)
print(suche.best_params_, suche.best_score_)

Die übrigen Knöpfe

penalty — l2 (Default, alle Gewichte klein halten) oder l1 (Gewichte exakt auf 0 drücken — eingebaute Feature-Auswahl, braucht Solver saga).
solver — lbfgs für mittlere Datenmengen, saga für sehr viele Beispiele oder L1-Penalty. Für unsere 43.000 × 512-Matrix sind beide okay.
class_weight="balanced" — gewichtet seltene Klassen im Loss höher. Bei PlantVillage (150 vs. 5.500 Bilder pro Klasse) fast immer einen Versuch wert; prüfe den Effekt am macro-F1.

Der teuerste Fehler: unskalierte Features

Regularisierung bestraft große Gewichte. Wenn Feature A in [0, 1] lebt und Feature B in [0, 10.000], braucht A zwangsläufig viel größere Gewichte, um denselben Einfluss zu haben — und wird von der Regularisierung dafür bestraft. Das Modell bevorzugt dann Features nach Maßstab statt nach Nutzen.

TEXTDer Unterschied in Zahlen (typisch)

ohne StandardScaler:   Accuracy 0.61   + ConvergenceWarning
mit  StandardScaler:   Accuracy 0.84   konvergiert sauber

gleicher Code, gleiche Daten, gleiches Modell.

Warum eigentlich? — Warum heißt es C und nicht λ?

In Lehrbüchern steht die Regularisierung meist als λ·||w||² im Loss — größeres λ, stärkere Strafe. scikit-learn folgt der SVM-Konvention und parametrisiert invers: C = 1/λ sitzt vor dem Daten-Term. Merksatz: C wie Confidence in die Daten. Wer zwischen Frameworks wechselt (Keras nutzt λ-Stil), muss diese Umrechnung im Kopf haben, sonst tunt man in die falsche Richtung.

Häufiger Denkfehler — Auf Accuracy statt macro-F1 tunen

GridSearchCV optimiert per Default Accuracy. Bei 38 unbalancierten Klassen findet die Suche dann bevorzugt Parameter, die große Klassen weiter verbessern und kleine opfern — der Bericht sieht gut aus, die seltenen Krankheiten werden systematisch übersehen. scoring="f1_macro" ist bei PlantVillage die ehrlichere Zielgröße. Generell gilt: Die Tuning-Metrik muss dieselbe sein wie die, an der das Projekt gemessen wird.

Tiefer rein — L1 als Feature-Detektiv

Mit penalty="l1" drückt die Regularisierung unwichtige Gewichte auf exakt 0 — übrig bleibt eine sparse Lösung. Bei 512 Histogramm-Bins bleiben je nach C vielleicht 60 aktive Bins übrig: Das Modell verrät damit, welche Farbbereiche die Krankheiten wirklich unterscheiden. Das ist nicht nur Kompression, sondern Erkenntnis — und ein guter Startpunkt, um die Feature-Extraktion gezielt zu verbessern. (Mathematischer Hintergrund: Die L1-Kugel hat Ecken auf den Achsen, und Optima landen gern in Ecken.)

← Praxis: scikit-learn auf PlantVillage Intuition: die breiteste Straße →