Wenn deine „besseren“ Features das Modell ruinieren

Wenn deine „besseren“ Features das Modell ruinieren

Kennst du das Gefühl? Du verbringst Tage damit, ein wunderschönes neues Feature zu bauen. Es fängt genau das Signal ein, das du wolltest. Du trainierst, evaluierst – und dein Class-2-F1 springt von 0,72 auf 0,78. Du grinst. Dann submittest du zum Leaderboard und dein Score ist gefallen. Was ist passiert? Du bist gerade in die Feature-Engineering-Falle getappt.

Eine Falle, in die fast jeder Data Scientist mindestens einmal tritt. Ich bin vor ein paar Monaten selbst reingefallen – und es hat mich eine solide Woche Debugging gekostet. Lass mich dir erklären, was da eigentlich unter der Haube passiert, warum deine cleveren manuellen Features nach hinten losgehen können und wie du einen Feature-Evaluation-Workflow baust, der dich nicht belügt.

Die klassische Falle: Der Sieg einer Metrik ist der Verlust einer anderen

Lass mich das exakte Szenario malen. Ich baute ein Multi-Class-Classification-Modell für einen Kunden. Baseline war okay. Dann fügte ich zwei handgefertigte Features hinzu: **Impact Severity** und **Energy Ratio**. Beide abgeleitet aus rohen Sensordaten, entworfen, um eine seltene Fehlerklasse zu erwischen. Machten physikalisch Sinn. Auf der Validierung verbesserte sich Class-2-F1 von 0,72 auf 0,78. Schön, oder?

Nicht so schnell. Als ich das Gesamtbild ansah, waren Class 0 und Class 1 F1 beide gefallen. Der Leaderboard – der einen gewichteten Durchschnitt über alle Klassen nutzte – war niedriger als meine Baseline. Das Modell hatte effektiv gelernt, die Mehrheitsklassen zu opfern, damit die Minderheitsklasse besser aussieht.

Das ist kein Pech. Das ist mathematische Realität eines geteilten Wahrscheinlichkeits-Budgets. In den meisten Multi-Class-Modellen reduziert das Erhöhen der Konfidenz für eine Klasse die einer anderen. Wenn deine neuen Features stark mit bestehenden korrelieren, fügst du keine Information hinzu – du verstärkst Rauschen und Schiefe.

Warum schlagen manuelle Features fehl?

Multikollinearität ist der stille Killer

Wenn dein neues Feature mit zwei oder drei bestehenden Features korreliert, teilt das Modell die Credits unter ihnen auf. In Baum-Modellen kann das wichtige Splits verstecken. In linearen Modellen bläht es Koeffizienten auf. Ergebnis? Weniger stabile Vorhersagen, besonders auf ungesehenen Daten.

Das Schlimmste: Multikollinearität schadet nicht immer der Training-Accuracy. Sie kann sogar helfen, Rauschen auswendig zu lernen. Aber sobald sich die Test-Verteilung nur leicht verschiebt, wird dein fancy neues Feature zur Liability.

Der Precision/Recall-Trade-off

Wenn du ein Feature gebaut hast, um Class 2 zu finden, erhöhst du wahrscheinlich Recall für Class 2, während du Precision für Class 1 zerstörst. Angenommen, dein Threshold verschiebt sich. Mehr Beispiele werden als Class 2 klassifiziert, aber viele davon sind eigentlich Class 1 oder Class 0. Dein Macro-Score fällt, obwohl deine „Zielklasse“ besser aussieht.

Das sehe ich ständig in Fraud Detection. Jemand baut ein Feature, das mehr Betrug erwischt – aber es flaggt auch massenhaft legitime Transaktionen. Recall für Fraud geht hoch, aber die False-Positive-Rate verdoppelt sich. In der echten Welt bedeutet das: verärgerte Kunden und ein sehr gestresstes Support-Team.

Leaderboard-Metriken sind meist aggregiert

Die meisten Leaderboards nutzen eine einzelne skalare Metrik – Accuracy, Macro-F1, Weighted Kappa oder Log Loss. Dieser Skalar versteckt den Per-Class-Breakdown. Wenn du für einen Slice optimierst, optimierst du nicht für das Ganze. Ein Fünf-Punkte-Gewinn bei Class-2-F1 kann durch einen Drei-Punkte-Verlust in zwei anderen Klassen aufgefressen werden, je nach Klassen-Gewichten.

Deshalb lese ich mittlerweile als allererstes die Competition- oder Projekt-Metrik extrem genau. Wenn es Weighted F1 ist, sind Verbesserungen in einer seltenen Klasse winzig. Wenn es Macro-F1 ist, zählt jede Klasse gleich – auch die, die dich nicht interessieren.

Ein Real-World-Walkthrough: Der Sensor-Daten-Fall

Lass mich ein konkretes Beispiel geben. Stell dir eine Fertigungsanlage mit Sensoren vor, die Temperatur, Vibration und Druck messen. Baseline-Modell: 0,85 Macro-F1 über drei Fehlerklassen.

Ich erstellte einen **Energy Ratio** = Vibrationsamplitude / Druckvarianz. Machte physikalisch Sinn. High-Energy-Impacts sollten harte Fehler anzeigen. Auf dem Trainingsset sprang Class-2-F1 auf 0,81. Aber in der Cross-Validation hielt der Gain nicht. Warum? Der Energy Ratio war hoch korreliert mit roher Vibration und Druck – Multikollinearität wieder. In Testdaten ließ Sensor-Rauschen bei niedrigem Druck den Ratio explodieren und schickte das Modell in falsche Class-2-Vorhersagen.

Der Fix war kontraintuitiv: Statt den rohen Ratio hinzuzufügen, nutzte ich ein Residual-Feature – den Teil der Vibration, der *nicht* durch Druck erklärt wurde. Dieses orthogonale Signal fügte tatsächlich neue Information hinzu, und der Leaderboard-Score verbesserte sich über alle Klassen. Lektion: Frag nicht „Macht mein Feature Sinn?“, sondern „Liefert mein Feature Information, die mein aktuelles Modell noch nicht hat?“

Noch ein Beispiel: E-Commerce Churn Prediction

Ich arbeitete mit einem Subscription-Box-Unternehmen. Das Marketing-Team wollte einen **Customer Engagement Score**, der Login-Frequenz, Support-Tickets und Social-Media-Mentions kombinierte. Klang super. Aber der Score war nur eine gewichtete Summe existierender Features. Als ich ihn zum Modell hinzufügte, mischten sich die Feature-Importance-Rankings, aber AUC blieb flach. Schlimmer: Kalibrierung wurde für Low-Engagement-User schlechter, weil der Score den Loss dominierte.

Wir ersetzten den handgefertigten Score am Ende durch eine simple Zählung distinkter Feature-Kategorien, die in den letzten sieben Tagen kontaktiert wurden. Dieses kleine, weniger korrelierte Feature gab einen echten Lift. Die Lektion wiederholte sich: Manchmal ist das unauffälligste Feature das beste.

Wie man Features evaluiert, ohne reingelegt zu werden

1. Baue einen Multi-Metric-Scorecard

Track nicht nur F1 für Class 2. Baue einen Scorecard, der enthält:

- Macro-F1 und Weighted-F1
- Precision und Recall für jede Klasse
- Log Loss oder Brier Score (für Kalibrierung)
- Ein Vermerk, ob Per-Class-Metriks in dieselbe Richtung gegangen sind

Das drucke ich nach jedem Experiment meist aus:

| Metric | Baseline | Neues Feature | Verdict |
|---|---|---|---|
| Class 0 F1 | 0,88 | 0,84 | Schlecht |
| Class 1 F1 | 0,82 | 0,79 | Schlecht |
| Class 2 F1 | 0,72 | 0,78 | Gut |
| Macro-F1 | 0,81 | 0,80 | Schlecht |

Ein Blick – und die Story ist klar. Das schicke neue Feature half einer Klasse, schadete aber den anderen. Ohne diesen Scorecard hätte ich das Modell submittet und eine böse Überraschung erlebt.

2. Führe einen Correlation Audit durch

Bevor du ein manuelles Feature hinzufügst, check seine Korrelation mit bestehenden Features. Nutz pandas `df.corr()` und such nach Absolutwerten über 0,7. Wenn dein neues Feature bestehenden zu ähnlich ist, überleg:

- Einen der redundanten Features zu droppen
- Residualisierung zu nutzen (neues Feature auf alte Features regressieren, Residuum nehmen)
- Feature Selection via scikit-learns `SelectKBest` oder `RFECV`

Scikit-learns offizieller Feature-Selection-Guide ist voll mit praktischen Ansätzen: https://scikit-learn.org/stable/modules/feature_selection.html

3. Nutze SHAP, um Directional Effects zu verstehen

Nach dem Training: Berechne SHAP Values, um genau zu sehen, wie dein neues Feature jede Klasse beeinflusst. Manchmal ist ein Feature nützlich für Class 2, aber aktiv schädlich für Class 1. Ein SHAP Summary Plot zeigt dir das sofort. Die Library ist Open Source und gut gepflegt unter https://github.com/shap/shap.

Ich habe schon mehrere „großartige“ Features erwischt, die starke positive SHAP Values für eine Klasse hatten, aber noch stärkere negative für eine andere. Das ist der Trade-off, den du *vor* dem Submit sehen musst.

4. Mach Ablations

Ablation heißt: Feature entfernen und schauen, was passiert. Erstaunlich selten in manuellem Feature Engineering. Ich fahre immer drei Experimente:

- Baseline mit alten Features
- Baseline + neues Feature
- Baseline + neues Feature, minus ein altes korreliertes Feature

Wenn das dritte Experiment das zweite schlägt, hast du ein Multikollinearitäts-Problem gelöst. Wenn das zweite schlechter ist als das erste, Feature raus. Wenn das zweite besser ist, aber der Leaderboard-Eval etwas anderes sagt, grab in deinem Validation-Setup.

Ein drittes Beispiel: Medical Triage Classification

Ich arbeitete mal an einem Symptom-Checker-Prototyp. Ziel: Patienten in drei Dringlichkeitslevel triagieren. Ich baute einen **Comorbidity Score**, indem ich die Anzahl vorliegender Erkrankungen summierte. Er verbesserte die Detektion von High-Urgency-Patienten – aber er ließ das Modell die Schwere des *aktuellen* Symptoms ignorieren. Ein Patient mit einem milden Symptom und einer Komorbidität wurde als High Urgency klassifiziert, obwohl sein eigentliches Risiko niedrig war.

Das Problem: Mein Feature war zu dominant. Das Modell lutschte sich daran fest, weil es leicht zu splitten war, und ignorierte die reicheren, nuancierteren Text-Features. Das ist ein weiterer Key-Trade-off: **Feature Dominance**. Ein starkes handgefertigtes Feature kann schwächere, aber informativere Features verdrängen. Regularisierung und Feature-Interactions können helfen, aber simpler ist oft besser.

Die größere Lektion: Features sind nicht kostenlos

Jedes Feature, das du hinzufügst, erhöht Modellkomplexität, Trainingszeit und Overfitting-Gefahr. Regularisierung kann helfen, aber sie kann ein fundamental redundantes Feature nicht fixen. Du musst jedes Feature als Wette sehen: Es muss seinen Platz rechtfertigen, indem es neues, stabiles Signal über mehrere Metriken hinweg liefert.

Ich habe auch gelernt: Wenn ein Leaderboard nach Feature-Addition fällt, ist die Ursache fast nie „die Metrik ist falsch“. Es ist, dass ich ein lokales Optimum gejagt habe. Das Modell ist nicht dumm – es macht genau das, worum ich gebeten habe. Ich habe nur nach dem Falschen gefragt.

FAQ

Warum ging mein F1 auf einer Klasse hoch, aber mein gesamter Leaderboard-Score runter?

Weil der Leaderboard wahrscheinlich einen gewichteten oder Macro-Durchschnitt nutzt. Dein Modell opfert vielleicht Precision oder Recall auf anderen Klassen, um auf der einen Klasse zu gewinnen, auf die du fokussiert warst.valuer immer die volle Confusion Matrix, bevor du dich freust.

Was ist der beste Weg, mit multikollinearen Features umzugehen?

Check erst die Korrelation. Wenn zwei Features hoch korrelieren, droppe eins oder nutze eine residualisierte Version des neuen Features. Regularisierung wie L1 oder L2 kann das Modell stabilisieren, aber Redundanz zu entfernen ist meist effektiver, als zu versuchen, sie mit Penalties zu fixen.

Ist manuelles Feature Engineering in modernem ML noch nützlich?

Ja – aber nur, wenn es Domain Knowledge encodiert, das nicht schon im Modell steckt. Wenn ein Feature nur eine mathematische Kombination existierender Features ist, hilft es meist nicht. Wenn es ein genuin neues Signal einfängt, kann es mächtig sein. Der Schlüssel: Verifizieren, dass es tatsächlich unabhängige Information hinzufügt.

Wie weiß ich, ob ein Feature wirklich hilft?

Vergleiche Baseline-Modell und Modell mit Feature über mehrere Metriken und Cross-Validation. Mach eine Ablation. Schau dir Feature Importance und SHAP Values an. Wenn die Verbesserung inkonsistent über Folds oder Metriks ist, overfittet es wahrscheinlich nur Rauschen.

Final Thoughts

Ich kenne den Thrill, das perfekte Feature zu bauen. Es fühlt sich an, als hättest du den Code geknackt. Aber der Leaderboard ist der ultimative Schiedsrichter. Je früher du Multi-Metric-Evaluation in deinen Workflow einbaust, desto weniger Zeit verschwendest du an Features, die nur einen Slice des Problems helfen.

Nächstes Mal, wenn du kurz davor bist, das clevere „Impact Severity“-Feature zu shippsten, halt an. Frag dich: „Fügt das neue Information hinzu – oder verstärke ich nur ein Signal, das ich schon habe?“ Dein zukünftiges Ich – und dein Leaderboard-Ranking – werden es dir danken.