Feature-Selection im Trading weniger Features, mehr Signal.

Wer ein Trading-Modell baut, steht selten vor zu wenigen, sondern fast immer vor zu vielen Features. Hunderte Indikatoren, Lags, gleitende Mittel, Volatilitätsmaße und Cross-Asset-Signale sind schnell erzeugt — und die meisten davon sind Rauschen oder bloße Duplikate korrelierter Information. Mehr Features bedeuten dabei nicht mehr Signal, sondern mehr Möglichkeiten für das Modell, sich an Zufall zu überanpassen. Gerade bei den knappen, verrauschten Datenmengen der Finanzmärkte ist der Fluch der Dimensionalität real: Mit jeder zusätzlichen Eingangsgröße steigt die Gefahr, dass der Backtest glänzt und der Livebetrieb enttäuscht. Dieser Beitrag zeigt, wie man aus einem Wust von Kandidaten die wenigen Features herausschält, die out-of-sample wirklich tragen — mit Methoden wie Boruta, MRMR und Permutation Importance. Er benennt aber auch ehrlich, warum Feature-Selection bei Zeitreihen heikler ist als in Standardproblemen und an welcher Stelle sie selbst zur Overfitting-Quelle wird.

Warum mehr Features im Trading meist schaden.

Die Intuition vieler Einsteiger lautet: Je mehr potenziell relevante Information ich dem Modell gebe, desto besser. Bei Finanzdaten ist das Gegenteil oft der Fall. Marktdaten haben ein extrem niedriges Signal-Rausch-Verhältnis — die echten Zusammenhänge sind schwach und instabil, das Rauschen dominiert. In dieser Umgebung findet ein flexibles Modell mit hundert Features mühelos Scheinmuster, die im Trainingszeitraum perfekt passen und in der Zukunft nichts vorhersagen.

Hinzu kommt die starke Korrelation typischer technischer Features. Ein 20-Tage- und ein 25-Tage-Durchschnitt tragen fast dieselbe Information. RSI, Stochastik und Williams %R messen verwandte Dinge. Wer zwanzig solcher Indikatoren einspeist, gibt dem Modell nicht zwanzig unabhängige Signale, sondern drei oder vier Informationsdimensionen in zwanzigfacher Verkleidung — bei zwanzigfachem Overfitting-Risiko.

Weniger, aber unabhängig nützliche Features führen fast immer zu robusteren Out-of-Sample-Ergebnissen. Das Ziel von Feature-Selection ist nicht, die Trainings-Performance zu maximieren, sondern die Lücke zwischen Trainings- und Live-Performance zu schließen.

Drei Familien von Auswahlverfahren.

Feature-Selection-Methoden lassen sich grob in drei Familien einteilen, die unterschiedliche Stärken und Kosten haben:

Filter-Methoden — etwa Korrelation mit dem Ziel oder Mutual Information — sind schnell, ignorieren aber Wechselwirkungen zwischen Features. Wrapper-Methoden trainieren das Modell für verschiedene Feature-Mengen immer wieder und sind dadurch teuer, dafür berücksichtigen sie Interaktionen. Embedded-Methoden wie die L1-Regularisierung (Lasso) treffen die Auswahl direkt während des Trainings, indem sie unnütze Koeffizienten auf null drücken.

In der Praxis kombiniert man oft: ein grober Filter zur Vorauswahl, gefolgt von einem präziseren Wrapper- oder Embedded-Verfahren auf der reduzierten Menge. Das hält die Rechenkosten beherrschbar und nutzt die Stärken beider Welten.

Boruta — alle wirklich relevanten Features finden.

Boruta verfolgt eine andere Logik als die meisten Verfahren. Statt die besten Features zu suchen, sucht es alle relevanten — und das durch einen eleganten Trick. Für jedes echte Feature erzeugt Boruta eine durchgeschüttelte Kopie, ein sogenanntes Shadow-Feature, das per Konstruktion keinerlei Information über das Ziel enthält. Dann trainiert es wiederholt ein Random-Forest-Modell und prüft: Ist ein echtes Feature wichtiger als die wichtigste seiner Shadow-Kopien?

Nur Features, die diesen Test über viele Durchläufe statistisch bestehen, gelten als bestätigt relevant. Der Charme: Die Shadow-Features liefern eine empirische Nullverteilung dafür, wie wichtig ein nutzloses Feature rein zufällig erscheinen kann. Das ist deutlich ehrlicher als willkürliche Schwellen auf der Feature-Importance.

Die Grenzen: Boruta ist rechenintensiv, weil es das Modell vielfach trainiert, und es ist auf baumbasierte Modelle zugeschnitten. Bei stark korrelierten Features kann es zudem Gruppen gemeinsam als relevant markieren, ohne innerhalb der Gruppe zu unterscheiden. Für die Vorauswahl in einer Trading-Pipeline ist es trotzdem ein verlässliches Arbeitspferd.

MRMR — Relevanz ja, Redundanz nein.

Das Kürzel MRMR steht für Minimum Redundancy, Maximum Relevance, und genau das ist sein Versprechen. Viele Verfahren wählen die individuell relevantesten Features — und landen bei einem Set hochkorrelierter Indikatoren, die dieselbe Information mehrfach liefern. MRMR balanciert zwei Ziele gleichzeitig: hohe Relevanz zum Ziel und geringe Redundanz untereinander.

Praktisch wählt MRMR Features iterativ aus. Im ersten Schritt nimmt es das relevanteste. In jedem weiteren Schritt sucht es das Feature, das maximale zusätzliche Relevanz bei minimaler Überschneidung mit dem bereits Gewählten bietet. Das Ergebnis ist ein kompaktes Set, in dem jedes Feature einen eigenen Informationsbeitrag leistet.

Gerade für Trading-Features mit ihrer notorischen Korrelation ist das wertvoll. Aus zwanzig Momentum-Varianten wählt MRMR vielleicht zwei, die unterschiedliche Zeithorizonte abdecken, und lässt den Rest weg. Wichtig ist, MRMR nicht als allein selig machend zu verstehen: Es trifft seine Entscheidungen meist paarweise und kann komplexe Interaktionen zwischen drei oder mehr Features übersehen. Als Werkzeug gegen Redundanz ist es dennoch schwer zu schlagen.

Permutation Importance — und ihre Tücke bei Korrelation.

Permutation Importance misst die Wichtigkeit eines Features, indem sie es zerstört und beobachtet, was passiert. Konkret: Man durchmischt die Werte eines Features zufällig — die Verteilung bleibt, der Zusammenhang zum Ziel verschwindet — und misst, wie stark die Modell-Performance einbricht. Bricht sie stark ein, war das Feature wichtig. Ändert sich nichts, war es überflüssig.

Der große Vorteil: Permutation Importance ist modellagnostisch und misst Wichtigkeit dort, wo sie zählt — auf einem Validierungsset, nicht auf den Trainingsdaten. Damit deckt sie auch Features auf, die das Modell zwar nutzt, die aber nur im Training tragen und out-of-sample versagen.

Die zentrale Tücke liegt bei korrelierten Features. Wenn zwei Features dieselbe Information enthalten, kann das Modell beim Permutieren des einen auf das andere ausweichen — beide erscheinen dann fälschlich unwichtig, obwohl ihre gemeinsame Information entscheidend ist. Hier hilft, korrelierte Features vor der Messung zu clustern und gruppenweise zu permutieren. Bei Zeitreihen kommt erschwerend hinzu, dass die Validierung über eine saubere zeitliche Trennung mit Purging und Embargo laufen muss, sonst misst man Leakage statt Wichtigkeit.

Der Leakage-Fallstrick bei Zeitreihen.

Feature-Selection bei Finanzzeitreihen scheitert am häufigsten nicht an der Methode, sondern an der Validierung. Jede Auswahl, die auf der Performance eines Modells beruht, ist nur so gut wie das Bewertungsschema dahinter. Und bei überlappenden Labels und autokorrelierten Daten ist eine naive Kreuzvalidierung gefährlich optimistisch.

Das Kernproblem: Trading-Labels überlappen typischerweise in der Zeit — das Label eines Tages hängt von Kursen ab, die auch in das Label des Folgetags einfließen. Eine zufällige Aufteilung in Trainings- und Testfalten verteilt dann eng verwandte Beobachtungen auf beide Seiten und lässt Information durchsickern. Das Modell sieht im Training quasi den Test, und jede Feature-Wichtigkeit ist verzerrt.

Die Abhilfe heißt Purged Cross-Validation mit Embargo: Beobachtungen, deren Labels zeitlich mit dem Testfenster überlappen, werden aus dem Training entfernt, und um das Testfenster wird eine Sperrzone gelegt. Nur so misst man Feature-Wichtigkeit ehrlich. Wer diesen Schritt überspringt, selektiert verlässlich Features, die Leakage ausnutzen — und baut ein System, das im Backtest brilliert und live verliert.

Wann Feature-Selection selbst overfittet.

Eine unbequeme Wahrheit: Feature-Selection ist selbst eine Form des Lernens und kann selbst überanpassen. Wer aus zweihundert Kandidaten die zwanzig besten auswählt und diese Auswahl auf demselben Datensatz trifft, den er später zur Bewertung nutzt, hat eine zweite, versteckte Optimierungsschleife eingebaut. Das Set sieht im Backtest hervorragend aus — weil es auf genau diesen Backtest selektiert wurde.

Der Effekt ist subtil und gefährlich. Schon das wiederholte Ausprobieren verschiedener Feature-Mengen frisst Freiheitsgrade auf. Bei genug Versuchen findet man immer eine Kombination, die rein zufällig gut performt. Das ist dieselbe Mechanik wie beim Überoptimieren von Strategieparametern, nur eine Ebene höher.

Schutz bietet ein strikt getrennter, nie für Selektion verwendeter Datenblock — ein finales Out-of-Sample-Fenster, das erst ganz am Ende einmal angefasst wird. Zusätzlich sollte die Feature-Selektion innerhalb der Kreuzvalidierung stattfinden, nicht davor: In jeder Falte neu auswählen und beobachten, ob dieselben Features stabil auftauchen. Features, die nur in einzelnen Falten erscheinen, sind verdächtig. Stabilität über die Falten hinweg ist ein besseres Gütekriterium als jeder einzelne Performance-Wert.

Eine robuste Pipeline für die Praxis.

In Projekten hat sich ein gestuftes Vorgehen bewährt, das Geschwindigkeit und Ehrlichkeit verbindet:

• Grobfilter zuerst. Offensichtlich redundante und nahezu konstante Features mit einfachen Korrelations- und Varianzschwellen entfernen — das reduziert die Kandidatenmenge billig.
• Redundanz mit MRMR brechen. Aus korrelierten Gruppen je einen Vertreter behalten, sodass jedes verbleibende Feature einen eigenen Beitrag leistet.
• Relevanz mit Boruta oder purged Permutation Importance bestätigen, immer auf sauber zeitlich getrennten Daten mit Embargo.
• Stabilität über Falten prüfen. Nur Features behalten, die über mehrere Kreuzvalidierungs-Folds konsistent auftauchen.
• Final-Set einmal out-of-sample testen, auf einem Block, der für keine dieser Entscheidungen verwendet wurde.

Realistisch landet man bei Trading-Modellen oft bei einer einstelligen bis niedrig zweistelligen Zahl an Features — nicht bei Hunderten. Diese Reduktion fühlt sich anfangs nach Verlust an, ist aber meist der größte einzelne Hebel für robuste Out-of-Sample-Performance. Weniger Features, mehr Signal ist im Trading keine Floskel, sondern eine Konsequenz aus dem niedrigen Signal-Rausch-Verhältnis der Märkte.

Ihr Modell läuft mit Dutzenden Features stark im Backtest, bricht aber im Livebetrieb ein? Unverbindlich anfragen — wir schauen gemeinsam auf Feature-Redundanz, Selektionsschema und Leakage-Risiken und reduzieren auf das, was out-of-sample wirklich trägt.