Dein Modell sieht im Notebook stark aus, aber im echten Betrieb bricht die Performance ein. Nicht, weil dein Algorithmus „zu simpel“ ist, sondern weil die Features nicht tragen. Genau hier entscheidet sich, ob Data Science in der Praxis Ergebnisse liefert oder nur schöne Metriken in einer Testumgebung. Feature Engineering ist der Maschinenraum: unspektakulär, aber entscheidend. Und Feature Selection ist die Disziplin, die verhindert, dass du dein Modell mit Datenmüll fütterst.
Wenn du bessere Modelle willst, fang nicht beim Modell an. Fang bei den Features an.
Warum Feature Engineering der größte Performance-Hebel ist (und warum viele Teams ihn unterschätzen)
Viele Data-Science-Projekte starten mit der Frage: Welches Modell sollen wir nehmen? XGBoost, Random Forest, Neural Net, irgendwas mit Transformer. Das ist verständlich, aber in der Praxis oft die falsche Priorität.
Hier ist der Kern: Ein mittelmäßiges Modell mit guten Features schlägt häufig ein starkes Modell mit schlechten Features. Denn Features sind die Übersetzung deiner Realität in eine Form, die ein Modell verarbeiten kann. Wenn diese Übersetzung falsch, unvollständig oder instabil ist, hilft dir auch das beste Training nicht.
Warum wird das unterschätzt?
- Feature Engineering fühlt sich weniger „innovativ“ an als Modellwahl.
- Es ist näher an Domänenwissen und Datenqualität, also an den „unangenehmen“ Teilen.
- Es kostet Abstimmung mit Fachbereichen, Data Engineering und oft auch IT.
Aber es zahlt direkt auf die Dinge ein, die im Betrieb zählen: Robustheit, Generalisierung, Wartbarkeit, Erklärbarkeit.
Hier ist der Punkt, an dem es praktisch wird: Feature Engineering ist keine Bastelarbeit. Es ist Produktentwicklung für Modelle.
Feature Selection: Weniger Variablen, mehr Signal
Feature Selection klingt nach „wir reduzieren Spalten“. In Wirklichkeit ist es Risikomanagement. Jedes zusätzliche Feature kann helfen, aber jedes zusätzliche Feature kann auch schaden:
- Es erhöht die Gefahr von Overfitting.
- Es bringt Leakage-Risiken (du nutzt Informationen, die im echten Einsatz nicht verfügbar sind).
- Es macht das Modell fragiler bei Datenänderungen.
- Es erhöht die Komplexität der Pipeline, damit die Fehlerwahrscheinlichkeit.
Warum ist „weniger“ oft besser?
Weil viele Features nur scheinbar informativ sind. Sie korrelieren mit dem Target in historischen Daten, aber nicht aus einem stabilen, kausalen Grund. Sobald sich Prozesse ändern (neue Preise, neue Lieferketten, neue Kundensegmente, neue Sensoren), kippt der Zusammenhang.
Praktische Heuristiken für Feature Selection, die in Projekten funktionieren
Verfügbarkeit im Produktionszeitpunkt prüfen
- Frage: Ist dieses Feature zum Zeitpunkt der Vorhersage wirklich bekannt?
- Typischer Fehler: Features, die aus späteren Prozessschritten stammen (z. B. „finaler Status“, „nachträgliche Korrektur“, „abgeschlossene Reklamation“).
Stabilität über Zeit testen
- Nutze Time-based Splits statt zufälliger Splits, wenn dein Problem zeitlich getrieben ist.
- Prüfe, ob ein Feature in mehreren Zeitfenstern ähnlich wichtig bleibt.
Redundanz reduzieren
- Stark korrelierte Features sind oft doppelt gemoppelt.
- Ziel: Weniger Features, die jeweils eine klare, unterschiedliche Information tragen.
Kosten des Features berücksichtigen
- Manche Features sind teuer: Sie benötigen externe Daten, aufwendige Berechnungen oder komplexe Join-Logik.
- Wenn ein Feature nur marginal hilft, aber die Pipeline deutlich komplizierter macht, ist es selten ein guter Deal.
Interpretierbarkeit als Auswahlkriterium nutzen
- Gerade im Mittelstand ist „Warum?“ oft genauso wichtig wie „Wie gut?“.
- Features, die sich fachlich erklären lassen, sind leichter zu verteidigen, zu warten und zu verbessern.
Warum das zählt: Feature Selection ist nicht nur Statistik. Es ist eine Entscheidung über Betriebssicherheit.
Feature Engineering: So entsteht aus Rohdaten ein lernbares Signal
Feature Engineering bedeutet: Du formst Rohdaten so um, dass sie die Struktur des Problems abbilden. Das kann simpel sein (z. B. fehlende Werte sinnvoll behandeln) oder anspruchsvoll (z. B. Ereignisse zu Sequenzen verdichten).
Wichtig ist: Feature Engineering ist immer problem-spezifisch. Trotzdem gibt es Muster, die sich in vielen industriellen Use Cases wiederholen.
1) Zeitfeatures: Wenn die Zeit der heimliche Treiber ist
Viele Probleme haben eine zeitliche Komponente, selbst wenn sie nicht als „Time Series“ gelabelt sind: Nachfrage, Ausfälle, Churn, Bearbeitungszeiten, Wartung.
Typische Zeitfeatures:
- Wochentag, Monat, Feiertagsnähe
- Zeit seit letztem Ereignis (z. B. letzter Kauf, letzte Wartung)
- Rolling Windows (z. B. Durchschnitt der letzten 7 Tage)
- Trends und Saisonalität (z. B. Veränderungsraten)
Achtung: Rolling Features sind prädestiniert für Leakage, wenn du sie falsch berechnest. Du musst sicherstellen, dass du nur Informationen bis zum Vorhersagezeitpunkt nutzt.
2) Aggregationen: Aus Ereignislisten werden Muster
In der Praxis liegen Daten oft als Ereignisse vor: Bestellungen, Klicks, Tickets, Maschinensignale. Ein Modell braucht daraus verdichtete Signale.
Beispiele:
- Anzahl Ereignisse in den letzten X Tagen
- Durchschnittlicher Warenkorbwert pro Kunde
- Varianz einer Messgröße (Instabilität ist oft ein Signal)
- Anteil bestimmter Kategorien (z. B. Reklamationsgründe)
Das ist der Moment, in dem viele Projekte gewinnen: Aggregationen bringen Struktur hinein, die ein Modell sonst nicht sieht.
3) Kategorien und Text: Vorsicht vor Feature-Explosion
Kategorische Variablen (Produktgruppen, Standorte, Fehlercodes) sind in Unternehmen überall. Du hast mehrere Optionen:
- One-Hot-Encoding (gut bei wenigen Kategorien)
- Target Encoding (stark, aber Leakage-Risiko, sauber validieren)
- Embeddings (bei sehr vielen Kategorien oder in Deep-Learning-Setups)
Text (Freitextfelder, Ticketbeschreibungen) kann extrem wertvoll sein, aber die Pipeline wird schnell komplex. Wenn du Text nutzt, brauchst du:
- klare Preprocessing-Regeln
- stabile Tokenisierung
- Monitoring für Drift (Sprache ändert sich)
4) Fehlende Werte: Nicht nur „auffüllen“, sondern verstehen
Missing Values sind selten zufällig. Manchmal sind sie selbst ein Signal:
- Messwert fehlt, weil ein Sensor ausfällt
- Feld bleibt leer, weil ein Prozessschritt übersprungen wurde
- Daten fehlen in bestimmten Regionen oder Schichten
Praktische Regel: Baue oft ein Missing-Indicator-Feature zusätzlich zur Imputation. So kann das Modell lernen, dass „fehlt“ eine Bedeutung hat.
5) Interaktionen: Wenn 1 + 1 mehr als 2 ist
Manche Effekte entstehen erst durch Kombination:
- Preis x Kundensegment
- Temperatur x Laufzeit
- Standort x Wochentag
Viele Modelle können Interaktionen automatisch lernen, aber gute, gezielte Interaktionsfeatures können Performance und Stabilität verbessern, besonders bei linearen Modellen oder wenn Daten knapp sind.
Der häufigste Fehler: Features bauen, die du später nicht betreiben kannst
Ein Feature ist nur dann „gut“, wenn du es im Betrieb zuverlässig berechnen kannst. Genau hier scheitern Projekte, obwohl die Offline-Metrik gut war.
Typische Ursachen:
- Features basieren auf Datenquellen, die nicht in Echtzeit verfügbar sind.
- Die Berechnung ist zu langsam oder zu teuer.
- Die Definition ist nicht stabil (z. B. „aktuelle Kundenklasse“, die sich historisch verändert).
- Train und Serve nutzen unterschiedliche Logik (Trainingspipeline weicht von Produktionspipeline ab).
So vermeidest du das:
- Definiere Features als Produkte: Name, Definition, Quelle, Update-Frequenz, Owner.
- Baue eine einheitliche Feature-Berechnung für Training und Inferenz.
- Versioniere Features, wenn sich Definitionen ändern.
- Miss Feature-Qualität im Betrieb (Nullrate, Verteilung, Ausreißer).
Warum das zählt: Ein Modell ist kein Artefakt, es ist ein System. Und Features sind dessen Versorgung.
Feature Engineering als Team-Sport: Data Science, Fachbereich, Data Engineering
Feature Engineering gelingt selten im Alleingang. Du brauchst:
- Fachbereich, um zu verstehen, welche Größen wirklich die Realität treiben.
- Data Engineering, um Datenzugriff, Qualität, Aktualität und Performance sicherzustellen.
- Data Science, um Hypothesen zu testen, Features zu bewerten und Modellrisiken zu steuern.
Wenn diese Rollen getrennt arbeiten, entstehen typische Symptome:
- Features, die fachlich plausibel sind, aber technisch nicht lieferbar.
- Features, die technisch leicht sind, aber fachlich keinen Sinn ergeben.
- Modelle, die in der Entwicklung gut aussehen, aber im Betrieb nicht stabil sind.
Ein praktischer Prozess, der sich bewährt:
- Feature-Ideen gemeinsam sammeln (Fachbereich führt, DS strukturiert).
- Machbarkeit und Kosten klären (DE bewertet).
- Kleine Feature-Sets testen, nicht sofort 200 Features bauen.
- Nur Features „promoten“, die stabil, verfügbar und messbar nützlich sind.
Das bringt Ruhe in den Maschinenraum.
Was du ab morgen anders machen solltest (konkret und umsetzbar)
Starte jedes Modellprojekt mit einem Feature-Review
- Welche Features sind zum Vorhersagezeitpunkt verfügbar?
- Welche sind potenziell Leakage?
- Welche sind teuer oder instabil?
Baue zuerst 10 richtig gute Features statt 100 mittelmäßige
- Fokus auf Zeit, Aggregationen, Prozesssignale und fehlende Werte als Information.
Validiere zeitlich korrekt
- Wenn dein Problem zeitabhängig ist, nutze Time-based Splits und prüfe Stabilität.
Mach Feature Engineering betriebssicher
- Gleiche Logik für Training und Inferenz.
- Monitoring für Feature-Verteilungen und Nullraten.
Dokumentiere Features wie ein Produkt
- Definition, Quelle, Update-Frequenz, Verantwortlichkeit, Version.
Wenn du diese fünf Punkte ernst nimmst, wirst du zwei Dinge sehen: Deine Offline-Metriken werden ehrlicher, und deine Produktionsmodelle werden besser. Genau das ist der Unterschied zwischen Data Science als Experiment und Data Science im Maschinenraum.
