Fortgeschrittener KI-Trading-Leitfaden: Die vollständige Referenz zu ML-Bibliotheken, Modellen & Frameworks für Quants

Gradient-Boosted Decision Trees (GBDTs) — nicht tiefe neuronale Netze — sind die Standard-Modellfamilie für jede tabellarische Klassifikations-/Regressionsaufgabe in dieser Pipeline: Meta-Labeling, Regime-Features, Faktor-Scoring. Ein vielzitierter Vergleich von 2024 über 100–300+ tabellarische Benchmarks stellte fest, dass GBDTs Deep Learning auf tabellarischen Daten mit deutlich weniger Tuning erreichen oder übertreffen (arXiv:2402.03970). Tabellarische Finanzdaten sind genau das Regime, in dem dies am stärksten gilt: niedriges Signal-Rausch-Verhältnis, gemischte stetige/kategoriale/spärliche Features, ausgeprägte Nichtstationarität und kleine effektive Stichprobengrößen — Bedingungen, unter denen die Flexibilität tiefer Netze meist Varianz statt Signal einbringt.

Warum GBDTs bei tabellarischen Finanzdaten dominieren

• Bias-Varianz-Trade-off. Bei einigen Tausend effektiven (nach Eindeutigkeit gewichteten) Zeilen und einem schwachen, verrauschten Signal geht der niedrige Bias eines Netzes mit hoher Kapazität mit einem Varianzkosten einher, die Sie sich nicht leisten können. Flache Bäume mit starker Regularisierung (Blattanzahl, min-data-in-leaf, Bagging) liegen an einem deutlich besseren Punkt dieses Trade-offs.
• Gemischte und spärliche Features nativ. Bäume splitten anhand roher Feature-Werte — kein Skalieren, keine Imputationsstrategie, keine Embedding-Tabelle für selten befüllte Kategoriale (Sektor, Börse, Verfallsnähe-Flag). Der Aufwand im Feature Engineering fließt ins Signal, nicht in Preprocessing-Klempnerei.
• Monotonie-Constraints kodieren finanzielle Priors direkt. LightGBM/XGBoost/CatBoost unterstützen alle monotone_constraints: z. B. erzwingen, dass P(win) mit der Trendstärke nicht fällt und mit der realisierten Volatilität nicht steigt. Das regularisiert hin zu domänensinnvollen Modellen und ist in einem Standard-MLP nicht verfügbar oder weit umständlicher.
• Fehlende Werte und Nichtstationarität. Bäume leiten fehlende Werte nativ weiter (keine leakage-anfällige Imputation, die auf dem gesamten Datensatz gefittet wird), und flache, häufig neu trainierte Bäume passen sich an Regimewechsel schneller an als ein großes Netz, das viele Epochen braucht, um veraltete Muster zu verlernen.

*Star-Zahlen sind Richtwerte, geprüft Mitte 2026 — als „Größenordnung" zu verstehen, nicht als exakte Werte.

import lightgbm as lgb
from sklearn.model_selection import train_test_split

# X: one row per primary-strategy signal date. Columns e.g.
#   log_ret_5d, log_ret_20d, realized_vol_20d, atr_14, frac_diff_price,
#   ema_slope, rsi_14, bb_pctb, obv_z, dist_200ma
# y: triple-barrier label from mlfinpy -> 1 = profit barrier hit first, 0 = stop/time first
# w: sample weight from mlfinpy uniqueness/time-decay (NEVER plain 1s -- labels overlap)
X, y, w = features_df[feature_cols], labels_df["tb_label"], labels_df["sample_weight"]

X_train, X_val, y_train, y_val, w_train, w_val = train_test_split(
    X, y, w, test_size=0.2, shuffle=False              # never shuffle time series
)

params = {
    "objective": "binary", "metric": "auc",
    "num_leaves": 31, "learning_rate": 0.03,
    "feature_fraction": 0.7, "bagging_fraction": 0.7, "bagging_freq": 5,
    "min_data_in_leaf": 50,
    # financial priors: e.g. [trend, vol, ...] -> win-prob non-decreasing in trend,
    # non-increasing in realized vol, unconstrained (0) elsewhere
    "monotone_constraints": [1, 0, -1, 0, 0, 1, 0, 0, 0, -1],
    "verbosity": -1,
}
train_set = lgb.Dataset(X_train, label=y_train, weight=w_train)
val_set   = lgb.Dataset(X_val, label=y_val, weight=w_val, reference=train_set)

model = lgb.train(params, train_set, num_boost_round=2000,
                   valid_sets=[val_set], callbacks=[lgb.early_stopping(100)])

meta_label_proba = model.predict(X_new)  # P(this signal hits the profit barrier first)

pip install xgboost
# minimal use: xgboost.XGBClassifier(n_estimators=800, max_depth=4, learning_rate=0.03,
#   subsample=0.7, colsample_bytree=0.7, monotone_constraints="(1,0,-1,0,0,1,0,0,0,-1)")

pip install catboost
# CatBoostClassifier(cat_features=["sector","exchange"], iterations=1500,
#   depth=6, learning_rate=0.03, monotone_constraints="1:1,2:-1")

Dies sind die von Grund auf trainierten neuronalen Architekturen, die Sie selbst trainieren würden (typischerweise über neuralforecast, Apache-2.0, das sie alle implementiert), im Gegensatz zu den vortrainierten Foundation-Models in §3. Jede von ihnen wurde auf M4/M3/electricity/traffic/ETT in die Welt gebenchmarkt — keine wurde gegen Finanz-Renditereihen entworfen, und das ehrliche Urteil je Architektur spiegelt das wider.

Vortrainierte, Zero-Shot-Zeitreihen-Forecaster sind real und nützlich — für Volatilität, nicht für die Kursrichtung. Eine Studie vom Juni 2026, eigens gebaut, um genau dies zu testen, „Pretrained Time-Series Foundation Models for Financial Return Forecasting" (Noguer i Alonso & Pereira Franklin, AI Finance Institute), benchmarkte TimeGPT, TimesFM-2.5, Moirai-2.0, Chronos und Chronos-2 gegen von Grund auf trainierte NBEATS/NHITS/PatchTST/iTransformer/KAN auf fünf liquiden US-Aktien (AAPL, AMZN, GOOG, JPM, META) mit einem Rolling-Origin-Protokoll gegen eine Random-Walk-Benchmark. Das Ergebnis: über zehn Asset-/Task-Kombinationen zeigten nur zwei eine statistisch signifikante Outperformance gegenüber dem Random Walk — Chronos bei AMZN und Moirai-2.0 bei GOOG — und die Autoren stellen unmissverständlich fest, dass „die Zugewinne gegenüber der Random-Walk-Benchmark klein und spärlich sind", und schließen, dass TSFMs „nützliche praktische Priors sind, die die Kosten der Modellentwicklung senken", aber ausdrücklich „keine universellen Maschinen zur statistisch verlässlichen Alpha-Generierung". Behandeln Sie jedes Modell weiter unten entsprechend: exzellente, auf CPU lauffähige Maschinen für Volatilitäts-/Vol-Forecast-Inputs in eine Sizing-Schicht; schwach bis Random-Walk für die Kursrichtung.

pip install chronos-forecasting torch

import torch
from chronos import BaseChronosPipeline

pipeline = BaseChronosPipeline.from_pretrained(
    "amazon/chronos-bolt-base",     # T5-style encoder-decoder, 205M params, Apache-2.0
    device_map="cpu",               # CPU is fine for daily-bar, small-batch inference
    torch_dtype=torch.bfloat16,
)

# Feed REALIZED VOLATILITY, not raw price -- this is a vol forecaster, not an oracle
context = torch.tensor(realized_vol_20d.values[-512:])

quantiles, mean = pipeline.predict_quantiles(
    context=context,
    prediction_length=10,                   # 10-day-ahead vol forecast
    quantile_levels=[0.1, 0.5, 0.9],
)
vol_forecast_median = quantiles[0, :, 1]    # feed straight into GARCH/vol-target sizing (see §10)

pip install timesfm
# tfm = timesfm.TimesFm(context_len=512, horizon_len=10, backend="cpu")
# tfm.load_from_checkpoint(huggingface_repo_id="google/timesfm-2.0-500m-pytorch")
# point_fc, quantile_fc = tfm.forecast([realized_vol_20d.values], freq=[0])

Finanz-Sentiment/NLP gehört in die Risikoschicht (ein Veto-/Regime-Feature), nicht in die Alpha-Schicht — laut der Quellenforschung aus §0 ist der eigenständige Vorteil aus Nachrichten-Sentiment weitgehend ein Look-Ahead-Artefakt, das Out-of-Sample verschwindet. Hier sind die drei Modelle, die man tatsächlich kennen sollte.

pip install transformers torch

from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

tok = AutoTokenizer.from_pretrained("ProsusAI/finbert")
model = AutoModelForSequenceClassification.from_pretrained("ProsusAI/finbert")
model.eval()

headlines = ["Company X beats earnings estimates, raises guidance",
             "Regulators open investigation into Company X"]

with torch.no_grad():
    inputs = tok(headlines, return_tensors="pt", padding=True, truncation=True)
    probs = torch.softmax(model(**inputs).logits, dim=-1)

# label order per config.id2label: 0=positive, 1=negative, 2=neutral
labels = ["positive", "negative", "neutral"]
scores = [dict(zip(labels, p.tolist())) for p in probs]
# aggregate to a daily sentiment score; use ONLY as a veto/regime feature, not alpha

RL ist der am meisten gehypte und am wenigsten verlässliche Posten auf dieser gesamten Seite für eine zentrale Trading-Engine. Das Tooling ist wirklich gut; das ehrliche Fazit, gestützt durch den eigenen Benchmark-Wettbewerb der RL-Community, lautet, es auf enge, streng validierte Teilprobleme (z. B. Ausführungs-Timing) zu beschränken, statt es als primäre oder portfolioweite Engine einzusetzen.

Die vier Algorithmus-Familien (je eine Zeile)

• PPO (Proximal Policy Optimization) — on-policy, diskrete oder kontinuierliche Aktionen; beschneidet den Policy-Update-Schritt, um nahe an der alten Policy zu bleiben, und tauscht etwas Stichprobeneffizienz gegen Trainingsstabilität. Die standardmäßige erste Wahl in den meisten FinRL-Beispielen.
• SAC (Soft Actor-Critic) — off-policy, ausschließlich kontinuierliche Aktionen; Maximum-Entropy-Ziel (belohnt Exploration explizit) mit einem Replay-Buffer, im Allgemeinen stichprobeneffizienter als PPO, aber empfindlicher gegenüber Hyperparametern.
• DQN (Deep Q-Network) — off-policy, ausschließlich diskrete Aktionen; lernt eine Aktionswertfunktion über einen Replay-Buffer und ein Target-Netzwerk. Benötigt einen diskretisierten Aktionsraum (z. B. buy/hold/sell), was schlecht zu kontinuierlichem Position-Sizing passt.
• A2C (Advantage Actor-Critic) — on-policy, diskret oder kontinuierlich; ein einfacherer, synchroner Verwandter von A3C, in FinRLs eigenen Benchmarks im Allgemeinen der schwächste der vier bei Finanzaufgaben.

Praktischer Anwendungsrahmen, falls Sie RL überhaupt einsetzen: ein enges Teilproblem mit einem naturgemäß MDP-förmigen Reward (z. B. Order-Ausführungs-Timing innerhalb einer festen Parent-Order, VWAP-Tracking), evaluiert mit derselben PBO-/DSR-Disziplin wie alles andere in §14 — niemals als primäre Entry-/Exit-/Sizing-Engine.

Qlib kommt einer schlüsselfertigen KI-Quant-Forschungsplattform im Open Source am nächsten — eine Datenschicht, eine Feature-Engineering-DSL, ein Model Zoo und ein Walk-Forward-Backtest-/Portfolioanalyse-Harness, über YAML-Workflow-Configs miteinander verdrahtet. MIT-lizenziert (microsoft/qlib), Zehntausende GitHub-Stars, MIT seit dem Open-Sourcing im September 2020, aktiv veröffentlicht (v0.9.7, August 2025) und nun mit Microsofts RD-Agent für automatisierte Forschungsschleifen-Experimente gekoppelt.

Alpha158 vs. Alpha360 — die zwei integrierten Feature-Sets

Workflow-/Config-System und integrierter Model Zoo

Qlib-Experimente werden typischerweise durch eine einzige YAML-Datei gesteuert, die von der qrun-CLI konsumiert wird und den Data Handler (Alpha158/360 oder benutzerdefiniert), das Modell, den Datensatz-Split, die Portfoliostrategie und die Backtest-Parameter deklariert — dies macht das Austauschen von LightGBM gegen einen GRU oder einen TFT-Wrapper zu einer einzeiligen Config-Änderung statt zu einer Neuimplementierung. Der integrierte Model Zoo umfasst klassische und Deep-Ansätze: LGBModel (LightGBM), XGBModel, CatBoostModel, MLP, GRU/LSTM/ALSTM (rekurrent), Transformer, TFT-Wrapper, TabNet, HIST, IGMTF sowie mehrere Graph-/Attention-Forschungsmodelle (GATs, KRNN, Localformer) — alle über dasselbe Workflow-Harness trainiert und evaluiert, mit einem gemeinsamen Walk-Forward-Backtest-/IC-Analyse-Report.

qlib_init:
  provider_uri: "~/.qlib/qlib_data/custom_nse"   # see note below on pointing Qlib at NSE data
  region: in                                       # generic region tag; India isn't a stock Qlib region out of the box

market: &market custom_nse_500
benchmark: &benchmark NIFTY500

data_handler_config: &data_handler_config
  start_time: 2010-01-01
  end_time: 2025-12-31
  fit_start_time: 2010-01-01
  fit_end_time: 2019-12-31
  instruments: *market

task:
  model:
    class: LGBModel
    module_path: qlib.contrib.model.gbdt
    kwargs:
      loss: binary
      num_leaves: 31
      learning_rate: 0.03
      monotone_constraints: [1, 0, -1, 0]
  dataset:
    class: DatasetH
    module_path: qlib.data.dataset
    kwargs:
      handler:
        class: Alpha158
        module_path: qlib.contrib.data.handler
        kwargs: *data_handler_config
      segments:
        train: [2010-01-01, 2019-12-31]
        valid: [2020-01-01, 2021-12-31]
        test:  [2022-01-01, 2025-12-31]

# run with:  qrun this_config.yaml

López de Prados Toolkit aus Advances in Financial Machine Learning bedeutete früher eine kostenpflichtige mlfinlab-Lizenz — das ist nicht mehr der Fall. Zwei kostenlose, permissiv lizenzierte Pakete decken nun Triple-Barrier-Labeling, Meta-Labeling, fraktionale Differenzierung, Sample-Uniqueness-Gewichtung, CPCV und HRP ab.

pip install mlfinpy

from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol

# causal, EWMA-based daily volatility -- uses data strictly up to t, no leakage
daily_vol = get_daily_vol(close=prices, lookback=50)

vertical_barriers = add_vertical_barrier(
    t_events=signal_dates, close=prices, num_days=10       # time-limit barrier
)

triple_barrier_events = get_events(
    close=prices,
    t_events=signal_dates,             # your primary (Pine) strategy's signal dates
    pt_sl=[2.0, 1.5],                  # profit-take / stop-loss as multiples of daily_vol
    target=daily_vol,
    min_ret=0.0005,
    num_threads=4,
    vertical_barrier_times=vertical_barriers,
)

labels = get_bins(triple_barrier_events, prices)
# labels['bin']    -> 1 = profit barrier hit first, 0 = stop/time barrier hit first
# labels['ret']    -> realized return at the barrier that was hit
# labels['t1']     -> the barrier-touch timestamp (needed for purging downstream)

pip install skfolio

from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
import lightgbm as lgb

meta_label_pipeline = Pipeline([
    ("model", lgb.LGBMClassifier(num_leaves=31, learning_rate=0.03,
                                  min_child_samples=50)),
])

# n_folds=10, n_test_folds=2  ->  C(10,2) = 45 combinatorial train/test paths
# purged_size / embargo_size sized to the max holding horizon (t1 - t0), NOT a flat 1%
cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2,
                            purged_size=10, embargo_size=10)

# returns an empirical DISTRIBUTION of out-of-sample paths, not one score --
# use it to compute PBO and the Deflated Sharpe Ratio, not a single train/test split
oos_paths = cross_val_predict(estimator=meta_label_pipeline, X=X, y=y,
                               cv=cv, sample_weight=w)

Was jede Technik Ihnen bringt

• Fraktionale Differenzierung (mlfinpy.features.frac_diff / Fixed-Width-FFD-Variante) — findet die minimale Differenzierungsordnung d (oft 0,2–0,5), die einen ADF-Stationaritätstest besteht und dabei eine Korrelation >0,9 zur Level-Reihe beibehält, was einen stationären Input liefert, der Gedächtnis bewahrt — strikt besser für Baum-/lineare Modelle als Rohrenditen (kein Gedächtnis) oder Rohpreise (nicht-stationär).
• Sample-Uniqueness-Gewichtung — Triple-Barrier-Labels überlappen sich zeitlich (eine 10-tägige Halteperiode bedeutet, dass benachbarte Signale Label-Fenster teilen), was die IID-Annahme verletzt, auf die sich die meiste ML-Theorie stützt. Gewichten Sie jede Stichprobe nach ihrer durchschnittlichen Uniqueness (Kehrwert der Anzahl gleichzeitiger Labels) zuzüglich Time-Decay, sonst ist Ihre effektive Stichprobengröße nur ein Bruchteil Ihrer Zeilenanzahl und jeder nachgelagerte Signifikanztest ist überzeichnet.
• Combinatorial Purged CV (CPCV) — erzeugt viele Train-/Test-Pfad-Kombinationen (nicht einen einzigen Walk-Forward-Pfad), purged Trainingszeilen, deren Label-Fenster den Test-Fold überlappt, und verhängt ein Embargo als Puffer nach jedem Test-Fold. Erzeugt eine vollständige Verteilung der Out-of-Sample-Sharpe-Ratios (als Input für PBO und DSR) statt einer einzelnen Punktschätzung — deshalb ist es strukturell verlässlicher als einfaches Walk-Forward.
• HRP (Hierarchical Risk Parity) (skfolio.optimization.HierarchicalRiskParity) — allokiert über hierarchisches Clustering der Korrelationsmatrix, statt eine verrauschte Kovarianzmatrix zu invertieren (wie es die Mean-Variance-Optimierung tut), was es weit robuster gegenüber Schätzfehlern bei einem Korb korrelierter Aktien macht.

Dies ist der Abschnitt, in dem der mit Abstand häufigste stille Leakage-Bug beim Retail-Regime-Gating steckt — und in dem es nützlicher ist, das falsche Muster neben dem richtigen zu zeigen, als es in Prosa zu beschreiben.

from hmmlearn.hmm import GaussianHMM

model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=1000)
model.fit(X_full)                    # fit on the ENTIRE history -- future leaks into the fit
regimes = model.predict(X_full)      # Viterbi = globally-smoothed decode over the whole path
# regimes[t] used information from t+1 ... T. This is look-ahead bias.
# Any backtest of a regime gate built this way is invalid and will not reproduce live.

from hmmlearn.hmm import GaussianHMM
import numpy as np

regime_at_t = np.full(len(X), np.nan)
model, refit_every, min_train = None, 63, 500     # e.g. refit quarterly

for t in range(min_train, len(X)):
    if model is None or t % refit_every == 0:
        model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        model.fit(X[:t])                          # ONLY data strictly before t

    # forward-algorithm FILTERED posterior using data up to and including t --
    # no smoothing, no future information, no re-fit on data that includes t's label use
    posteriors = model.predict_proba(X[:t + 1])
    regime_at_t[t] = posteriors[-1].argmax()       # today's regime, knowable today

# regime_at_t is safe to merge into the feature frame for both backtest and live use.
# Expect a MUCH smaller, laggier drawdown benefit than the full-sample-smoothed version --
# that gap IS the size of the leakage bug you just closed.

ruptures ist das ergänzende Werkzeug, wenn du Changepoints statt eines persistenten Regime-Zustands suchst — etwa um einen Volatilitätsregime-Bruch in einer EWMA-Reihe zu markieren und damit einen HMM-Refit auszulösen, oder als alternativen Regime-Grenzdetektor zur Gegenprüfung der HMM-Übergänge. Pelt (exakte Suche mit linearer Laufzeit, unbekannte Anzahl an Bruchpunkten, benötigt einen Penalty-Parameter) ist der Standard; Binseg tauscht Exaktheit gegen Geschwindigkeit bei längeren Reihen; fensterbasierte Verfahren sind am günstigsten, aber bei subtilen Brüchen am wenigsten präzise. Wie das HMM solltest du es für den Live-Einsatz in einem expandierenden/rollierenden Fenster ausführen — die Standard-API von ruptures ist ebenfalls standardmäßig ein Offline-Verfahren über die gesamte Reihe.

Keine einzelne Engine ist für jede Phase die richtige. Nutze eine vektorisierte Engine, um Tausende von Parameterkombinationen vorzusortieren, und validiere anschließend jeden Überlebenden erneut auf einer ereignisgesteuerten Engine mit realistischen Fills, bevor du Kapital riskierst — die beiden Phasen zu vermischen (einem Backtest der vektorisierten Engine als endgültige Antwort zu vertrauen) ist ein häufiger, teurer Fehler.

Warum die Architektur von NautilusTrader tatsächlich zählt

Die meisten Fälle von „großartiger Backtest, enttäuschender Live-Betrieb“ sind keine Modellfehler — es sind Bugs durch Research/Production-Skew: Deine Backtest-Engine und dein Live-Ausführungscode sind zwei getrennte Codebasen, die still auseinanderdriften (hier eine Fill-Preis-Annahme, dort ein Off-by-one-Bug beim Bar-Timing), und nichts erzwingt ihre Konsistenz. Das Rust-Core-, ereignisgesteuerte Design von NautilusTrader führt denselben Strategiecode — dieselben Klassen, dieselben Event-Handler — im Backtest-, Paper- und Live-Modus aus; nur die Daten-/Ausführungsadapter ändern sich. Diese architektonische Entscheidung eliminiert eine ganze Klasse von Bugs konstruktiv statt durch Disziplin, und genau deshalb ist es das richtige Werkzeug für die Rolle der „finalen Re-Validierung mit realistischen Fills und Brücke zur Produktion“ und nicht bloß ein Nice-to-have.

Hier wird „Drawdown-Kontrolle“ tatsächlich umgesetzt — als deterministische Mathematik, die Volatilitätsprognosen und Meta-Label-Konfidenz verarbeitet, nicht als weitere Vorhersageaufgabe.

pip install arch

from arch import arch_model
import numpy as np

returns_pct = 100 * log_returns.dropna()      # arch expects % returns for numerical stability
# GJR-GARCH(1,1,1) with Student-t errors -- captures the leverage effect (vol reacts more to
# negative returns than positive ones), which plain GARCH(1,1) misses
am = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t")
res = am.fit(disp="off", last_obs=train_end_date)   # fit only on data up to the current date

fcast = res.forecast(horizon=10, reindex=False)
vol_forecast_daily = np.sqrt(fcast.variance.values[-1]) / 100   # back to decimal daily vol

target_vol_daily = 0.10 / (252 ** 0.5)        # ~10% annualized portfolio vol target
position_scale = target_vol_daily / vol_forecast_daily[0]
position_size = base_size * min(position_scale, max_leverage_cap)   # always cap leverage

from pypfopt import HRPOpt
hrp = HRPOpt(returns=daily_returns_df)   # NOT prices -- pass returns
weights = hrp.optimize()                 # hierarchical-clustering-based, no covariance inversion

import riskfolio as rp
port = rp.Portfolio(returns=daily_returns_df)
port.assets_stats(method_mu="hist", method_cov="hist")
weights = port.optimization(model="Classic", rm="CVaR", obj="MinRisk", rf=0, l=0)

Bevor du irgendeinem GBDT- oder Foundation-Model-Ergebnis vertraust, benchmarke es gegen die langweilige Baseline. Diese beiden Bibliotheken decken die automatisierte Feature-Extraktion und die klassischen Prognose-Baselines ab, die du niemals überspringen solltest.

pip install tsfresh
from tsfresh import extract_relevant_features

# long-format df: columns [id, time, value]; y indexed by id (e.g. triple-barrier label)
features = extract_relevant_features(
    long_format_df, y=labels_by_id, column_id="id", column_sort="time",
    fdr_level=0.01,           # false-discovery-rate control -- do NOT skip this on financial data
)
# re-run the relevance filter INSIDE each CV fold in production, never on the full dataset

pip install statsforecast
from statsforecast import StatsForecast
from statsforecast.models import AutoARIMA, AutoETS

sf = StatsForecast(models=[AutoARIMA(), AutoETS()], freq="D", n_jobs=-1)
sf.fit(train_df)
baseline_forecast = sf.predict(h=10)
# your GBDT / foundation-model forecast must beat THIS, net of cost, or there is no edge

MLOps-Tooling geht hier nicht um Skalierung — es geht um Ehrlichkeit. Die mit Abstand tragendste MLOps-Funktion in diesem gesamten Stack ist die Disziplin bei der Trial-Anzahl für die Deflated Sharpe Ratio: jede Backtest-Konfiguration, die du jemals ausprobierst, für immer protokolliert, damit die Korrektur für multiples Testen gegen deine echte Trial-Anzahl berechnet wird und nicht gegen die schmeichelhafte Teilmenge, an die du dich erinnerst.

pip install mlflow
import mlflow

with mlflow.start_run(run_name="lgbm_meta_label_v37"):
    mlflow.log_params(params)                                   # every hyperparameter tried
    mlflow.log_param("cv_scheme", "CombinatorialPurgedCV(10,2)")
    mlflow.log_param("feature_set_hash", feature_set_hash)       # so re-used feature sets don't double count
    mlflow.log_metric("oos_sharpe_median", oos_sharpe_median)    # across the CPCV path distribution
    mlflow.log_metric("pbo", pbo_value)
    mlflow.log_metric("trial_number_in_family", trial_counter)   # THIS feeds the Deflated Sharpe N
    mlflow.lightgbm.log_model(model, "model")

# Query the full run history to compute N for the Deflated Sharpe Ratio -- include prior
# Pine-Script optimization trials too (see §14), not just the ML runs.

Über die Modell-Hubs hinaus führt der Datasets Hub von Hugging Face eine wachsende Sammlung finanzrelevanter Datensätze, die sich für Prototyping und Sentiment-Arbeit lohnen — behandle sie allesamt als Prototyping-/Backup-Quellen, nicht als survivorship-bias-freie Produktionsdaten (siehe die Data-Plan-Disziplin im zugrunde liegenden Research-Report).

Numerai — ein anderes Spiel, keine Datenquelle für dein eigenes System

Numerai versteht man am besten als Marktplatz für Modellierungs-Skill, nicht als Datensatz, den du in deine eigene Pipeline einbindest. Das Kern-Turnier liefert kostenlose, vorab aufbereitete, obfuskierte Features — PCA-transformiert, z-standardisiert und zeitlich segmentiert, sodass du erstklassige Finanzdaten modellieren kannst, ohne jemals zu wissen, welche Aktien oder Daten du betrachtest (jede wöchentliche „Era“ hat IDs, die sich per Design nicht über Eras hinweg zuordnen lassen). Numerai Signals ist das komplementäre Produkt: Du reichst Vorhersagen auf deinem eigenen Universum/deinen eigenen Features ein und zielst auf Signale ab, die orthogonal zu dem sind, was Numerais bestehender Modell-Stack bereits erfasst. Alle eingereichten Modelle speisen ein stake-gewichtetes Meta-Modell, das wiederum Numerais eigenen Hedgefonds steuert. Rahme es als Optionalität zur Monetarisierung von Modellierungs-Skill ein — bewertet anhand mehrjähriger, drawdown-inklusiver Performance, nicht als schneller Weg zu Einkommen — und als interessantes benachbartes Ökosystem statt als Komponente der Pipeline in §14.

Wie ein fortgeschrittener Nutzer jede der obigen Bibliotheken durchgängig zu einer Pipeline verdrahtet. Datenaufnahme → Qlib/tsfresh-Features → fraktionale Differenzierung (mlfinpy) → LightGBM-Meta-Label-Modell, validiert mit verschachtelter Combinatorial Purged CV (skfolio) → kausales hmmlearn-Regime-Gate → GARCH-basierte (arch) vol-getargetete Positionsgrößenbestimmung → NautilusTrader-Backtest → MLflow-Logging → PickMyTrade-Webhook zur Ausführung.

"""
Reference pipeline skeleton: data ingestion -> PickMyTrade execution.
Every preprocessing step is fit INSIDE the CPCV training fold only -- never on
the full dataset. Illustrative structure; wire in your own data store / config.
"""
import numpy as np
import pandas as pd
import lightgbm as lgb
import mlflow
import requests
from hmmlearn.hmm import GaussianHMM
from arch import arch_model
from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol
from mlfinpy.features import frac_diff_ffd
from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
from qlib.contrib.data.handler import Alpha158
from tsfresh import extract_relevant_features
from nautilus_trader.backtest.engine import BacktestEngine
from nautilus_trader.trading.strategy import Strategy


# 1. DATA INGESTION -- point-in-time, survivorship-bias-free universe only
def load_point_in_time_universe(as_of_date, min_adv_usd=2_500_000):
    """Never filter by TODAY's liquidity -- that imports survivorship bias."""
    raw = data_store.query_asof(as_of_date=as_of_date)          # Parquet/DuckDB store
    return raw[raw["adv_20d_asof"] > min_adv_usd]


# 2. FEATURES -- Qlib Alpha158 for technicals, tsfresh + mlfinpy for the rest
def build_features(prices: pd.DataFrame) -> pd.DataFrame:
    alpha158 = Alpha158(instruments=prices["symbol"].unique().tolist(),
                         start_time=prices.index.min(), end_time=prices.index.max())
    tech_features = alpha158.fetch()

    tsfresh_features = extract_relevant_features(
        prices.reset_index(), y=None, column_id="symbol", column_sort="date", fdr_level=0.01,
    )

    d = find_min_ffd_order(prices["close"], adf_pvalue=0.05, min_corr=0.9)   # search d in [0.1, 1.0]
    frac_diff_price = frac_diff_ffd(prices["close"], d=d, threshold=1e-4)    # stationary, RETAINS memory

    return tech_features.join(tsfresh_features, how="inner").assign(frac_diff_price=frac_diff_price)


# 3. LABELS -- causal EWMA vol -> ATR-scaled triple barrier (mlfinpy)
def label_events(prices: pd.Series, signal_dates: pd.DatetimeIndex) -> pd.DataFrame:
    daily_vol = get_daily_vol(close=prices, lookback=50)
    vertical_barriers = add_vertical_barrier(t_events=signal_dates, close=prices, num_days=10)
    events = get_events(close=prices, t_events=signal_dates, pt_sl=[2.0, 1.5], target=daily_vol,
                         min_ret=0.0005, num_threads=4, vertical_barrier_times=vertical_barriers)
    return get_bins(events, prices)          # -> bin (0/1), ret, t1 (needed for purging)


# 4. META-LABEL MODEL -- LightGBM inside nested Combinatorial Purged CV
def train_meta_label_model(X: pd.DataFrame, y: pd.Series, w: pd.Series, trial_counter: int):
    pipeline = Pipeline([("model", lgb.LGBMClassifier(
        num_leaves=31, learning_rate=0.03, min_child_samples=50,
        monotone_constraints=MONO_CONSTRAINTS))])

    cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2, purged_size=10, embargo_size=10)
    oos_paths = cross_val_predict(estimator=pipeline, X=X, y=y, cv=cv, sample_weight=w)

    pbo = compute_pbo(oos_paths)
    dsr = compute_deflated_sharpe(oos_paths, n_trials=get_trial_count_from_mlflow() + trial_counter)
    if pbo > 0.50 or dsr.p_value > 0.05:
        raise ValueError(f"Model rejected: PBO={pbo:.2f}, DSR p={dsr.p_value:.3f}")

    final_model = pipeline.fit(X, y, model__sample_weight=w)
    return final_model, pbo, dsr


# 5. REGIME GATE -- causal, walk-forward, FILTERED (never smoothed) HMM posterior
def causal_regime_state(vol_return_features: np.ndarray, t: int, model_cache: dict,
                         refit_every: int = 63, min_train: int = 500) -> int:
    if t < min_train:
        return 1  # default "calm" until enough history exists
    if t % refit_every == 0 or "model" not in model_cache:
        hmm = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        hmm.fit(vol_return_features[:t])                       # only data strictly before t
        model_cache["model"] = hmm
    posteriors = model_cache["model"].predict_proba(vol_return_features[: t + 1])
    return int(posteriors[-1].argmax())                        # filtered state at t, no look-ahead


# 6. VOL-TARGETED SIZING -- GJR-GARCH forecast -> fractional-Kelly-scaled size
def size_position(returns_pct: pd.Series, meta_label_confidence: float, regime_state: int,
                   target_vol_annual: float = 0.10, kelly_fraction: float = 0.5,
                   max_leverage: float = 1.5) -> float:
    if regime_state == 0:                                       # 0 = "stormy" -- stand aside
        return 0.0
    res = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t").fit(disp="off")
    vol_fc = np.sqrt(res.forecast(horizon=1, reindex=False).variance.values[-1, 0]) / 100
    vol_scale = (target_vol_annual / (252 ** 0.5)) / vol_fc
    kelly_scale = kelly_fraction * max(2 * meta_label_confidence - 1, 0)   # confidence -> edge proxy
    return float(np.clip(vol_scale * kelly_scale, 0, max_leverage))


# 7. BACKTEST -- NautilusTrader (same strategy class runs backtest AND live)
class MetaLabelStrategy(Strategy):
    def __init__(self, model, hmm_cache, config):
        super().__init__(config)
        self.model, self.hmm_cache = model, hmm_cache

    def on_bar(self, bar):
        feats = self.build_live_features(bar)                   # same code path as build_features()
        confidence = self.model.predict_proba(feats)[:, 1][0]
        regime = causal_regime_state(self.vol_history, self.clock.timestamp_ns, self.hmm_cache)
        size = size_position(self.returns_pct_history, confidence, regime)
        if confidence > 0.55 and size > 0:
            self.submit_bracket_order(side="BUY", size=size, sl_atr_mult=1.5, tp_atr_mult=2.0)


def run_backtest(historical_bars, final_model, strat_config):
    engine = BacktestEngine()
    engine.add_data(historical_bars)
    engine.add_strategy(MetaLabelStrategy(model=final_model, hmm_cache={}, config=strat_config))
    return engine.run()      # the SAME strategy object later promotes to paper/live -- adapters swap only


# 8. MLFLOW LOGGING -- every trial, forever (feeds the Deflated Sharpe trial count)
def log_run(params, pbo, dsr, backtest_results, final_model, trial_counter):
    with mlflow.start_run(run_name=f"pipeline_v{trial_counter}"):
        mlflow.log_params(params)
        mlflow.log_metric("pbo", pbo)
        mlflow.log_metric("dsr_p_value", dsr.p_value)
        mlflow.log_metric("backtest_sharpe", backtest_results.sharpe_ratio)
        mlflow.log_metric("backtest_max_dd", backtest_results.max_drawdown)
        mlflow.log_metric("trial_number_in_family", trial_counter)
        mlflow.lightgbm.log_model(final_model, "meta_label_model")


# 9. EXECUTION -- PickMyTrade webhook JSON (paper first, then tiny live)
def send_to_pickmytrade(symbol, side, qty, sl_price, tp_price, webhook_url, secret):
    payload = {
        "secret": secret, "symbol": symbol, "action": side,     # "buy" / "sell"
        "quantity": qty, "stopLoss": sl_price, "takeProfit": tp_price, "orderType": "market",
    }
    resp = requests.post(webhook_url, json=payload, timeout=5)
    resp.raise_for_status()
    return resp.json()

Claude Fable ist Anthropics Frontier-Modell (Modell-ID claude-fable-5), verfügbar über die Claude-App und Claude Code. Bei einem derart tiefen Stack liegt sein Wert nicht in „schreib mir einen Trading-Bot“ — sondern in der unglamourösen, fehleranfälligen Mitte: die CPCV-Fold-Arithmetik korrekt hinzubekommen, eine kausale (nicht leaky) HMM-Decoding-Schleife im ersten Anlauf zu schreiben, einen Qlib-Data-Handler für einen Markt zu verdrahten, den es nicht von Haus aus mitbringt, und eine mehrstufige Pipeline durchgängig auf das eine Leak zu lesen, das sonst erst Monate später als Live-/Backtest-Diskrepanz zutage träte.

Wo es sich am spezifischen Stack dieser Seite bezahlt macht:

• CPCV-Fold-Logik — Purge-/Embargo-Größen aus deinem Label-Horizont und dem langsamsten Feature-Lookback (§7) ableiten, statt sie zu raten und aus einem aufgeblähten Backtest-Sharpe zu erfahren.
• Kausale Regime-Inferenz — die Walk-forward-Schleife auf Basis der gefilterten Posterior schreiben statt des leaky decode()/Viterbi-Aufrufs über die gesamte Stichprobe, wie er als „falsches“ Beispiel in §8 gezeigt wird.
• Qlib-Konfiguration — Alpha158/Alpha360-Workflow-YAML für einen Data-Handler generieren und anpassen, für eine Region, die Qlib nicht mitbringt, wie das NSE-Beispiel in §6.
• Pipeline-weites Leakage-Review — das §14-Skelett Phase für Phase auf einen Fit-außerhalb-des-Folds-Bug lesen, bevor es jemals Kapital berührt.
• Pine Script → Python-Konvertierung — die Entry-Logik einer TradingView-Strategie in die Primärsignal-Funktion portieren, die das Meta-Labeling-Modell speist.
• Ausführungs-Glue — den in §14.6 behandelten Webhook-Payload-/Idempotency-Key-Code entwerfen sowie das MLflow-Logging, das deine Deflated-Sharpe-Trial-Anzahl ehrlich hält (§12).

Sofort anpassbare Prompts für jeden dieser Punkte — spezifisch für den Stack dieser Seite, keine generischen „bau mir einen Bot“-Anfragen:

Review this skfolio CombinatorialPurgedCV setup [paste code]: 10 folds, 2 test folds, on triple-barrier-labeled
signals where barriers can resolve up to 10 trading days after the signal (get_events num_days=10). Check whether
purged_size and embargo_size are large enough to cover that full label-resolution window plus my slowest feature's
lookback. Flag any fold where a training sample's resolution window overlaps a test sample's, explain the leak, and
give me corrected purge/embargo values with the reasoning shown.

Here is my hmmlearn regime-detection code [paste code]. Confirm it only calls predict_proba on data up to and
including index t when producing the label used AT time t, and that it never calls hmm.decode() or reads a Viterbi
path computed over the full series. If it's using the full-sample smoothed posterior, rewrite it as a walk-forward
loop that refits every N bars on strictly past data and returns the filtered (not smoothed) posterior at each step,
matching the causal pattern, not the leaky one.

I want Microsoft Qlib's Alpha158 handler running on NSE (India) equities, not one of Qlib's built-in regions.
Here's my current workflow YAML [paste config]. Write a custom data handler/provider that points Alpha158's feature
computation at my own point-in-time OHLCV store instead of Qlib's default region data, keeping the Alpha158 feature
set intact. Explain specifically what breaks -- calendar, instrument universe, trading-day alignment -- if I just
change the region tag without supplying compatible replacements.

Here is my end-to-end pipeline: data ingestion, feature engineering, triple-barrier labeling, LightGBM meta-label
training inside CombinatorialPurgedCV, HMM regime gate, GARCH-based sizing, and NautilusTrader backtest [paste code].
Walk it stage by stage and flag every point where a transform -- scaler, feature selector, frac-diff order search, HMM
fit -- is fit on data outside the current CV training fold, or a feature could see information unavailable at signal
time. Rank findings by how much each would inflate the backtest Sharpe if left uncorrected.

Here is my TradingView Pine Script strategy [paste script]. Convert its entry logic into a Python function that
takes a pandas DataFrame of OHLCV bars and returns a boolean signal series, matching the Pine version bar-for-bar on
identical historical data. This becomes the primary-model signal feeding my meta-labeling filter, so flag anything --
security() calls with lookahead, use of the current bar's close before it closes -- that would make the two versions
diverge.

Write a Python function that takes a meta-label confidence score, ATR-based stop/target multiples, and a
position size from my vol-targeted sizing calc, and builds the JSON payload for a PickMyTrade webhook POST -- symbol,
side, quantity, stopLoss, takeProfit. Add a deterministic idempotency key (hash of symbol + signal timestamp + bar
index) as a payload field, and wrap the POST in retry-with-backoff logic that treats a timeout as "unknown, reconcile
before retrying" rather than blindly resubmitting.

Dieselbe Build-vs-Buy-Entscheidung, die jedes Systems-Team trifft, angewendet auf den letzten Sprung der §14-Pipeline: Fließen Ihre knappen Engineering-Stunden in die Order-Routing-Verrohrung oder in die Modellschichten, die tatsächlich Ihre eigenen sind? Dieser Abschnitt macht den Fall dafür, die Live-Ausführung als eingekaufte Abhängigkeit mit schmaler Schnittstelle zu behandeln — und zeigt, wie diese Schnittstelle von der Seite der Pipeline aus aussieht.

Wo dies in der §14-Pipeline einzuordnen ist

Die Referenz-Pipeline endet bei "MLflow-Logging → PickMyTrade-Webhook zur Ausführung", weil das die natürliche Vertrauensgrenze ist. Ihr Modell gibt ein Signal aus → ein TradingView-Alert wird ausgelöst, oder — da ein fortgeschrittenes Setup TradingView vollständig überspringen kann — Ihr eigener Python-Dienst konstruiert das JSON und POSTet es direkt an den Webhook-Endpunkt von PickMyTrade → PickMyTrade übernimmt die OCO-Bracket-Platzierung, die broker-spezifische Order-Übersetzung, das Multi-Account-Fan-out und die Reconnect-/Retry-Schleife gegen das Venue, zu dem Sie auch immer routen. Diese Arbeitsteilung bedeutet, dass Ihr Dienst nur bis zu "einen idempotenten HTTP-POST senden" zuverlässig sein muss — er muss nie eine zustandsbehaftete, mehrwöchige Verbindung zur Session-API eines Brokers aufrechterhalten, Auth-Tokens nach Zeitplan erneuern oder den Order-Zustand nach einer Netzwerkpartition abgleichen. Diese gesamte Problemkategorie wandert von Ihrem Tisch.

{
  "idempotencyKey": "SIG-MES-2026-07-03T14:32:00Z-000481",
  "symbol": "MES",
  "side": "buy",
  "quantity": 2,
  "orderType": "market",
  "stopLoss": 5320.25,
  "takeProfit": 5364.75,
  "meta": {
    "metaLabelConfidence": 0.62,
    "atr14": 14.8,
    "slAtrMult": 1.5,
    "tpAtrMult": 2.0,
    "regimeState": 1
  }
}

Bewusst generisch — kein verifiziertes PickMyTrade-Schema (siehe den funktionierenden send_to_pickmytrade()-Aufruf in §14 für die Feldnamen, die in der Referenz-Pipeline dieser Seite bereits verwendet werden). quantity kommt direkt aus der vol-getargeteten Sizing-Berechnung aus §11/§14; stopLoss/takeProfit sind Einstieg ± ATR × die Barrier-Multiplikatoren, die bereits im Triple-Barrier-Labeling (§7) validiert wurden; idempotencyKey — im minimalen §14-Beispiel nicht vorhanden — ist das, was aus einer At-least-once-Webhook-Zustellung eine effektiv-einmalige Order macht.

Eine einzige Nachschlagetabelle für "Ich muss… → nutze dies → weil…".

Jedes auf dieser Seite behandelte Werkzeug und Modell, mit seiner Lizenz und einer klaren Kennzeichnung. Sicher = permissiv, keine nennenswerte Einschränkung für kommerzielle/Live-Trading-Nutzung. Vorsicht = nutzbar, aber lesen Sie die Bedingungen (Copyleft-Verpflichtungen, Source-available-aber-eingeschränkte Klauseln oder eher ein Wartungsstatus-Bedenken als ein lizenzrechtliches). Eingeschränkt = ein echter Blocker für ein uneingeschränktes kommerzielles/Live-System ohne gesonderte Vereinbarung.

↑ Zurück nach oben