Guía avanzada de trading con IA: La referencia completa de librerías, modelos y frameworks de ML para cuants

Los árboles de decisión con gradient boosting (GBDT), no las redes profundas, son la familia de modelos por defecto para cada tarea tabular de clasificación/regresión de este pipeline: meta-etiquetado, características de régimen, puntuación de factores. Una comparación de 2024 ampliamente citada sobre más de 100-300 benchmarks tabulares halló que los GBDT igualan o superan al deep learning en datos tabulares con mucho menos ajuste (arXiv:2402.03970). Los datos financieros tabulares son exactamente el régimen donde esto se cumple con más fuerza: baja relación señal-ruido, características mixtas continuas/categóricas/dispersas, fuerte no estacionariedad y tamaños de muestra efectivos pequeños, condiciones en las que la flexibilidad de las redes profundas compra sobre todo varianza, no señal.

Por qué los GBDT dominan en datos financieros tabulares

• Compromiso sesgo-varianza. Con unos pocos miles de filas efectivas (ponderadas por unicidad) y una señal débil y ruidosa, la baja sesgo de una red de alta capacidad tiene un coste de varianza que no puedes permitirte. Los árboles poco profundos con fuerte regularización (número de hojas, min-data-in-leaf, bagging) se sitúan en un punto mucho mejor de ese compromiso.
• Características mixtas y dispersas de forma nativa. Los árboles dividen sobre valores de características en bruto: sin escalado, sin estrategia de imputación, sin tabla de embeddings para categóricas poco pobladas (sector, exchange, indicador de proximidad al vencimiento). El esfuerzo de ingeniería de características va a la señal, no a la fontanería de preprocesamiento.
• Las restricciones monótonas codifican priores financieros directamente. LightGBM/XGBoost/CatBoost admiten todos monotone_constraints: p. ej. forzar que P(ganancia) sea no decreciente en la fuerza de la tendencia y no creciente en la volatilidad realizada. Esto regulariza hacia modelos con sentido de dominio y no está disponible, o es mucho más engorroso, en un MLP estándar.
• Valores faltantes y no estacionariedad. Los árboles enrutan los valores faltantes de forma nativa (sin imputación propensa a fugas ajustada sobre todo el conjunto de datos), y los árboles poco profundos y reentrenados con frecuencia se adaptan más rápido a los cambios de régimen que una red grande que necesita muchas épocas para desaprender patrones obsoletos.

*Los recuentos de estrellas son orientativos, comprobados a mediados de 2026: trátalos como "orden de magnitud", no como cifras exactas.

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")

Estas son las arquitecturas neuronales desde cero que entrenarías tú mismo (normalmente vía neuralforecast, Apache-2.0, que las implementa todas), a diferencia de los modelos base preentrenados de la §3. Todas ellas fueron evaluadas para su creación en M4/M3/electricity/traffic/ETT: ninguna se diseñó frente a series de retornos financieros, y el veredicto honesto por arquitectura lo refleja.

Los pronosticadores de series temporales preentrenados y zero-shot son reales y útiles, para la volatilidad, no para la dirección del precio. Un estudio de junio de 2026 construido específicamente para probar esto, "Pretrained Time-Series Foundation Models for Financial Return Forecasting" (Noguer i Alonso y Pereira Franklin, AI Finance Institute), evaluó TimeGPT, TimesFM-2.5, Moirai-2.0, Chronos y Chronos-2 frente a NBEATS/NHITS/PatchTST/iTransformer/KAN desde cero sobre cinco acciones estadounidenses líquidas (AAPL, AMZN, GOOG, JPM, META) con un protocolo de origen móvil frente a un benchmark de paseo aleatorio. El resultado: entre diez combinaciones de activo/tarea, solo dos mostraron un rendimiento superior estadísticamente significativo frente al paseo aleatorio: Chronos en AMZN y Moirai-2.0 en GOOG, y los autores afirman llanamente que "las ganancias sobre el benchmark de paseo aleatorio son pequeñas y escasas", concluyendo que los TSFM son "priores prácticos útiles que reducen los costes de desarrollo de modelos", pero explícitamente "no motores universales para la generación de alpha estadísticamente fiable". Trata cada modelo de abajo en consecuencia: motores excelentes, ejecutables en CPU, para entradas de volatilidad/pronóstico de vol a una capa de dimensionamiento; débiles frente al paseo aleatorio para la dirección del precio.

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])

El sentimiento/PLN financiero pertenece a la capa de riesgo (una característica de veto/régimen), no a la capa de alpha: según la investigación fuente de la §0, la ventaja del sentimiento de noticias por sí sola es en gran medida un artefacto de anticipación que muere fuera de muestra. Aquí están los tres modelos que realmente vale la pena conocer.

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

El RL es el elemento más sobrevalorado y menos fiable de toda esta página para un motor de trading principal. El instrumental es genuinamente bueno; el veredicto honesto, respaldado por el propio concurso de benchmark de la comunidad de RL, es confinarlo a subproblemas estrechos y estrictamente validados (p. ej. el momento de ejecución) en lugar de un motor principal o a nivel de cartera.

Las cuatro familias de algoritmos (una línea cada una)

• PPO (Proximal Policy Optimization): on-policy, acciones discretas o continuas; recorta el paso de actualización de la política para mantenerse cerca de la política anterior, sacrificando algo de eficiencia de muestra por estabilidad de entrenamiento. La primera opción por defecto en la mayoría de ejemplos de FinRL.
• SAC (Soft Actor-Critic): off-policy, solo acciones continuas; objetivo de máxima entropía (premia explícitamente la exploración) con un búfer de repetición, generalmente más eficiente en muestra que PPO pero más sensible a los hiperparámetros.
• DQN (Deep Q-Network): off-policy, solo acciones discretas; aprende una función de valor de acción mediante un búfer de repetición y una red objetivo. Necesita un espacio de acción discretizado (p. ej. comprar/mantener/vender), lo que encaja mal con el dimensionamiento continuo de posición.
• A2C (Advantage Actor-Critic): on-policy, discreto o continuo; un primo más simple y síncrono de A3C, generalmente el más débil de los cuatro en tareas financieras en los propios benchmarks de FinRL.

Alcance práctico, si usas RL en absoluto: un subproblema estrecho con una recompensa naturalmente en forma de MDP (p. ej. el momento de ejecución de órdenes dentro de una orden padre fija, seguimiento de VWAP), evaluado con la misma disciplina de PBO/DSR que todo lo demás en la §14, nunca como el motor principal de entrada/salida/dimensionamiento.

Qlib es lo más parecido a una plataforma de investigación IA-cuant llave en mano en código abierto: una capa de datos, un DSL de ingeniería de características, un zoo de modelos y un arnés de backtest walk-forward/análisis de cartera, conectados entre sí mediante configuraciones de flujo de trabajo YAML. Licencia MIT (microsoft/qlib), decenas de miles de estrellas en GitHub, MIT desde su apertura en septiembre de 2020, con lanzamientos activos (v0.9.7, agosto de 2025) y ahora emparejado con RD-Agent de Microsoft para experimentación automatizada de bucles de investigación.

Alpha158 vs. Alpha360: los dos conjuntos de características integrados

Sistema de flujo de trabajo/configuración y zoo de modelos integrado

Los experimentos de Qlib se conducen normalmente mediante un único archivo YAML consumido por la CLI qrun, que declara el manejador de datos (Alpha158/360 o personalizado), el modelo, la división del conjunto de datos, la estrategia de cartera y los parámetros de backtest: esto hace que cambiar LightGBM por un GRU o un wrapper de TFT sea un cambio de configuración de una línea, no una reescritura. El zoo de modelos integrado abarca enfoques clásicos y profundos: LGBModel (LightGBM), XGBModel, CatBoostModel, MLP, GRU/LSTM/ALSTM (recurrentes), Transformer, wrapper de TFT, TabNet, HIST, IGMTF y varios modelos de investigación de grafos/atención (GATs, KRNN, Localformer), todos entrenados y evaluados a través del mismo arnés de flujo de trabajo con un informe compartido de backtest walk-forward/análisis de IC.

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

El conjunto de herramientas de Advances in Financial Machine Learning de López de Prado solía significar una licencia de pago de mlfinlab: ya no. Dos paquetes gratuitos y con licencia permisiva cubren ahora el etiquetado de triple barrera, el meta-etiquetado, la diferenciación fraccional, la ponderación de unicidad de muestras, CPCV y HRP.

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)

Qué te aporta cada técnica

• Diferenciación fraccional (mlfinpy.features.frac_diff / variante FFD de ancho fijo): halla el orden mínimo de diferenciación d (a menudo 0,2-0,5) que pasa un test de estacionariedad ADF conservando una correlación >0,9 con la serie de niveles, dando una entrada estacionaria que conserva memoria: estrictamente mejor para modelos de árbol/lineales que los retornos en bruto (memoria cero) o el precio en bruto (no estacionario).
• Ponderación de unicidad de muestras: las etiquetas de triple barrera se solapan en el tiempo (un periodo de mantenimiento de 10 días significa que señales adyacentes comparten ventanas de etiqueta), violando la suposición IID en la que se basa la mayoría de la teoría de ML. Pondera cada muestra por su unicidad media (inverso del recuento de etiquetas concurrentes) más decaimiento temporal, o tu tamaño de muestra efectivo será una fracción de tu recuento de filas y cada test de significancia posterior estará sobrestimado.
• Validación cruzada purgada combinatoria (CPCV): genera muchas combinaciones de rutas train/test (no una sola ruta walk-forward), purga las filas de entrenamiento cuya ventana de etiqueta se solapa con el fold de test, y aplica un embargo de margen tras cada fold de test. Produce una distribución completa de ratios de Sharpe fuera de muestra (que alimenta PBO y DSR) en lugar de una estimación puntual: por eso es estructuralmente más fiable que el walk-forward simple.
• HRP (Hierarchical Risk Parity) (skfolio.optimization.HierarchicalRiskParity): asigna mediante agrupamiento jerárquico de la matriz de correlación en lugar de invertir una matriz de covarianza ruidosa (lo que hace la optimización media-varianza), lo que lo hace mucho más robusto al error de estimación en una cesta de acciones correlacionadas.

Esta es la sección donde vive el error de fuga silenciosa más común en el gating de régimen minorista, y donde mostrar el patrón equivocado junto al correcto es más útil que describirlo en prosa.

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 es la herramienta complementaria cuando quieres puntos de cambio en lugar de un estado de régimen persistente, p. ej. señalar una ruptura de régimen de volatilidad en una serie EWMA para disparar un reajuste del HMM, o como detector alternativo de límites de régimen para contrastar las transiciones del HMM. Pelt (búsqueda exacta de coste lineal, número desconocido de puntos de ruptura, necesita un parámetro de penalización) es el predeterminado; Binseg sacrifica exactitud por velocidad en series más largas; los métodos basados en ventana son los más baratos pero los menos precisos en rupturas sutiles. Como el HMM, ejecútalo en una ventana expansiva/móvil para uso en vivo: la API estándar de ruptures también es un método offline de serie completa por defecto.

Ningún motor único es el adecuado para cada etapa. Usa un motor vectorizado para cribar miles de combinaciones de parámetros, y luego revalida cada superviviente en un motor basado en eventos con ejecuciones realistas antes de arriesgar capital: confundir las dos etapas (confiar en un backtest de motor vectorizado como tu respuesta final) es un error común y caro.

Por qué la arquitectura de NautilusTrader realmente importa

La mayoría de los fracasos de "gran backtest, real decepcionante" no son fallos del modelo: son bugs de sesgo entre investigación y producción: tu motor de backtest y tu código de ejecución en vivo son dos bases de código separadas que se separan silenciosamente (una suposición de precio de ejecución aquí, un bug de timing de vela por uno allá), y nada las obliga a mantenerse consistentes. El diseño basado en eventos con núcleo en Rust de NautilusTrader ejecuta el mismo código de estrategia (las mismas clases, los mismos manejadores de eventos) en modo backtest, paper y en vivo; solo cambian los adaptadores de datos/ejecución. Esa elección arquitectónica elimina toda una clase de bugs por construcción en lugar de por disciplina, por lo que es la herramienta adecuada para el papel de "revalidación final con ejecución realista y puente a producción" en lugar de un lujo prescindible.

Aquí es donde el "control de drawdown" se implementa realmente: como matemática determinista que consume pronósticos de volatilidad y confianza de meta-etiqueta, no como otra tarea de predicción.

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)

Antes de fiarte de cualquier resultado de GBDT o de un modelo base, compáralo con la línea base aburrida. Estas dos librerías cubren la extracción automatizada de características y las líneas base de pronóstico clásicas que nunca deberías saltarte.

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

El instrumental de MLOps aquí no va de escala: va de honestidad. La función de MLOps más determinante de todo este stack es la disciplina de recuento de pruebas para el Deflated Sharpe Ratio: cada configuración de backtest que hayas probado, registrada, para siempre, de modo que la corrección por pruebas múltiples se calcule frente a tu recuento de pruebas real, no el subconjunto halagador que recuerdas.

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.

Más allá de los hubs de modelos, el Datasets Hub de Hugging Face alberga un conjunto creciente de datasets relevantes para las finanzas que vale la pena conocer para prototipado y trabajo de sentimiento: trátalos todos como fuentes de prototipado/respaldo, no como datos de producción libres de sesgo de supervivencia (véase la disciplina del Plan de Datos en el informe de investigación fuente).

Numerai: un juego diferente, no una fuente de datos para tu propio sistema

Numerai se entiende mejor como un mercado de habilidad de modelado, no como un dataset para enchufar a tu propio pipeline. El torneo principal ofrece características gratuitas, preprocesadas y ofuscadas: con PCA, z-scored y segmentadas en el tiempo para que puedas modelar datos financieros de clase mundial sin saber nunca qué acciones o fechas estás mirando (cada "era" semanal tiene IDs que no se corresponden entre eras, por diseño). Numerai Signals es el producto complementario: envías predicciones sobre tu propio universo/características, buscando señales ortogonales a lo que el stack de modelos existente de Numerai ya captura. Todos los modelos enviados alimentan un meta-modelo ponderado por stake que a su vez impulsa el propio hedge fund de Numerai. Enmárcalo como opcionalidad para monetizar la habilidad de modelado (evaluado sobre rendimiento plurianual e inclusivo de drawdown, no como una vía rápida hacia ingresos) y como un ecosistema adyacente interesante en lugar de un componente del pipeline de la §14.

Cómo un usuario avanzado conecta cada librería anterior en un solo pipeline, de principio a fin. Ingesta de datos → características de Qlib/tsfresh → diferenciación fraccional (mlfinpy) → modelo de meta-etiqueta LightGBM validado con validación cruzada purgada combinatoria anidada (skfolio) → compuerta de régimen causal con hmmlearn → dimensionamiento con objetivo de vol basado en GARCH (arch) → backtest con NautilusTrader → registro con MLflow → webhook de PickMyTrade para la ejecución.

"""
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 es el modelo de vanguardia de Anthropic (id de modelo claude-fable-5), disponible a través de la app de Claude y de Claude Code. En un stack tan profundo, su valor no es "escríbeme un bot de trading": es el punto intermedio poco glamuroso y propenso a errores: acertar la aritmética de los folds de CPCV, escribir un bucle de decodificación de HMM causal (no con fugas) a la primera, cablear un manejador de datos de Qlib para un mercado que no viene de fábrica, y leer un pipeline multietapa de principio a fin en busca de la única fuga que de otro modo solo saldría a la luz como una brecha entre real y backtest meses después.

Dónde se gana el sueldo en el stack específico de esta página:

• Lógica de folds de CPCV: derivar los tamaños de purga/embargo a partir del horizonte de tu etiqueta y del lookback de característica más lento (§7), en lugar de adivinarlos y descubrirlo por un Sharpe de backtest inflado.
• Inferencia de régimen causal: escribir el bucle de posterior filtrada, walk-forward, en lugar de la llamada con fugas a decode()/Viterbi de muestra completa mostrada como el ejemplo "incorrecto" en la §8.
• Configuración de Qlib: generar y adaptar el YAML de flujo de trabajo Alpha158/Alpha360 a un manejador de datos personalizado para una región que Qlib no incluye, como el ejemplo de NSE en la §6.
• Revisión de fugas en todo el pipeline: leer el esqueleto de la §14 etapa por etapa en busca de un bug de ajuste fuera del fold antes de que llegue a tocar capital.
• Conversión de Pine Script → Python: portar la lógica de entrada de una estrategia de TradingView a la función de señal primaria que alimenta el modelo de meta-etiquetado.
• Pegamento de ejecución: redactar el código del payload del webhook / clave de idempotencia cubierto en la §14.6, y el registro con MLflow que mantiene honesto tu recuento de pruebas del Deflated Sharpe (§12).

Prompts listos para adaptar para cada uno de esos, específicos del stack de esta página, no peticiones genéricas de "constrúyeme un bot":

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.

La misma decisión de construir vs. comprar que toma cualquier equipo de sistemas, aplicada al último salto del pipeline de la §14: ¿tus escasas horas de ingeniería van a la fontanería de enrutamiento de órdenes, o a las capas de modelo que sí son tuyas? Esta sección defiende tratar la ejecución en vivo como una dependencia comprada de interfaz estrecha, y muestra cómo se ve la interfaz desde el lado del pipeline.

Dónde encaja esto en el pipeline de la §14

El pipeline de referencia termina en "registro con MLflow → webhook de PickMyTrade para la ejecución" porque ese es el límite de confianza natural. Tu modelo emite una señal → se dispara una alerta de TradingView, o (dado que una configuración avanzada puede saltarse TradingView por completo) tu propio servicio Python construye y hace POST del JSON directamente al endpoint del webhook de PickMyTrade → PickMyTrade se encarga de la colocación de brackets OCO, la traducción de órdenes específica del bróker, el fan-out multicuenta y el bucle de reconexión/reintento contra el mercado al que enrutes. Esa división del trabajo significa que tu servicio solo tiene que ser fiable hasta "enviar un POST HTTP idempotente": nunca tiene que mantener una conexión con estado, de varias semanas, a la API de sesión de un bróker, refrescar tokens de autenticación según un horario ni reconciliar el estado de las órdenes tras una partición de red. Toda esa categoría de problema se retira de tu plato.

{
  "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
  }
}

Deliberadamente genérico — no es un esquema verificado de PickMyTrade (consulta la llamada operativa send_to_pickmytrade() en §14 para los nombres de campo que ya se usan en el pipeline de referencia de esta página). quantity sale directamente del cálculo de sizing con objetivo de volatilidad de §11/§14; stopLoss/takeProfit son la entrada ± ATR × los múltiplos de barrera ya validados en el etiquetado de triple barrera (§7); idempotencyKey — ausente del ejemplo mínimo de §14 — es lo que convierte una entrega de webhook «al menos una vez» en una orden «efectivamente una vez».

Una única tabla de consulta para «necesito… → usa esto → porque…».

Cada herramienta y modelo tratado en esta página, con su licencia y un indicador claro. Segura = permisiva, sin restricción significativa para el uso comercial o de trading en vivo. Precaución = usable, pero lee los términos (obligaciones de copyleft, cláusulas de código disponible pero restringido, o una preocupación por el estado de mantenimiento más que por la licencia). Restringida = un obstáculo real para un sistema comercial o en vivo sin restricciones si no media un acuerdo aparte.

↑ Volver arriba