HyperFusion-WF

Prototipo académico para explorar representación multimodal, clasificación de tendencias y meta-labeling sobre datos EURUSD M15.

Important

Este repositorio documenta un experimento universitario. No es un sistema de trading, no ejecuta órdenes y sus resultados no demuestran rentabilidad real ni superioridad frente al estado del arte.

Estado del proyecto

Campo	Estado
Tipo	Proyecto académico exploratorio
Datos incluidos	EURUSD M15, desde 2013-01-01 hasta 2024-12-31 UTC
Evaluación publicada	Walk-forward experimental con XGBoost
Uso en vivo	No implementado
Reproducibilidad	Parcial; requiere correcciones y artefactos generados localmente
Auditoría metodológica	Pendiente antes de extraer conclusiones financieras

El valor principal del repositorio está en integrar distintas ideas de representación temporal y documentar un flujo experimental. Las métricas publicadas deben leerse como resultados de clasificación bajo una función de pago sintética.

Qué contiene

El proyecto explora cinco familias de características:

• representación temporal mediante un encoder tipo PatchTST;
• embeddings de un foundation model para series temporales;
• características de liquidez derivadas de OHLCV;
• tokens de patrones mediante K-Means;
• características espectrales y firmas geométricas.

Las etiquetas se generan con Trend Scanning sobre ventanas futuras de 20 a 100 velas. Después se prueban dos rutas diferentes:

1. una arquitectura neuronal multimodal experimental, denominada HyperFusion;
2. un pipeline walk-forward de XGBoost base más un meta-modelo que intenta estimar cuándo acertará el clasificador base.

Los archivos resultados_wf.csv, metricas_resumen.csv y las figuras publicadas corresponden a la segunda ruta, basada en XGBoost y features precomputadas. No constituyen una evaluación aislada de la arquitectura neuronal HyperFusion.

Orden experimental de los notebooks

1. encoder.ipynb: representación temporal con entrenamiento walk-forward.
2. datos.ipynb: exportación de embeddings temporales.
3. 01a_Foundation_Features.ipynb: embeddings del foundation model.
4. 01b_Liquidity_Features.ipynb: características de liquidez.
5. 01c_Semantic_Tokens.ipynb: tokenización K-Means.
6. 01d_Spectral_Features.ipynb: características espectrales.
7. 01e_Geometric_Signatures.ipynb: firmas de trayectoria.
8. 02_Trend_Scanning_Labels.ipynb: construcción de etiquetas.
9. 03_Main_Pipeline_WalkForward.ipynb: ensamblaje, modelos y evaluación.

Este orden todavía no constituye un pipeline reproducible de un solo comando. Hay rutas y nombres de artefactos que deben unificarse antes de poder ejecutar el proyecto de extremo a extremo sin intervención manual.

Cómo interpretar los resultados publicados

Resultado publicado	Valor	Interpretación correcta
Observaciones OOS	172.026	Observaciones etiquetadas; no son operaciones independientes
Acierto del modelo base	51,98 %	Exactitud sobre etiquetas de Trend Scanning
Actividad del filtro meta	48,9 %	Fracción de observaciones aceptadas por el umbral
Acierto tras el filtro	52,46 %	Exactitud condicional sobre observaciones aceptadas
Pago acumulado	2.454,62 R	Suma sintética de +1/-1 R menos 0,02 R por observación activa
Drawdown del filtro meta	-864,34 R	Caída en unidades sintéticas; no es un porcentaje de capital
Sharpe publicado	4,54	Anualización simplificada; no es comparable directamente con un Sharpe de trading real
Bloques walk-forward positivos	28 de 49	El resultado agregado oculta una variabilidad temporal considerable

La serie raw_pnl publicada presenta una autocorrelación de primer orden cercana a 0,81. Esto es coherente con etiquetas construidas sobre ventanas futuras solapadas y confirma que el número efectivo de observaciones independientes es mucho menor que 172.026.

Limitaciones y conflictos conocidos

1. La función de pago no usa retornos de mercado

El resultado asigna +1 R cuando el clasificador acierta la etiqueta y -1 R cuando falla. No calcula el retorno de una posición abierta y cerrada sobre precios reales. Por ello, retorno, drawdown, profit factor y Sharpe describen una simulación de clasificación, no una estrategia ejecutable.

2. Las observaciones se solapan

Trend Scanning utiliza ventanas futuras de hasta 100 velas y genera etiquetas para puntos consecutivos. Muchas observaciones comparten parte del mismo movimiento de precio, por lo que no deben tratarse como trades independientes. Esto afecta la significancia estadística y la anualización de métricas.

3. La protección contra leakage no es uniforme

El notebook de tokens contiene una primera versión que ajusta K-Means con todo el historial y una segunda versión que crea market_tokens_honest.h5 usando solo el 60 % inicial. Sin embargo, el ensamblaje neuronal referencia market_tokens.h5, la variante ajustada con todo el historial.

El pipeline XGBoost final aplica un embargo externo de 150 observaciones, mayor que el horizonte máximo de etiqueta, pero el split interno entre modelo base y meta-modelo no incorpora una purga equivalente. La ruta neuronal inicial tampoco purga las fronteras train/validation/test.

4. Los resultados no aíslan el aporte de HyperFusion

El CSV final se genera con XGBoost sobre features concatenadas. No existe una ablación que compare, bajo exactamente los mismos folds, HyperFusion neuronal, XGBoost simple, cada modalidad individual y combinaciones de modalidades. Por tanto, no puede atribuirse el desempeño publicado a la arquitectura completa.

5. Selección de umbral en la misma muestra de entrenamiento

El meta-modelo se entrena y el umbral se selecciona sobre el mismo bloque meta. Falta un bloque separado de calibración o validación para elegir el umbral sin optimismo in-sample.

6. Costos y ejecución simplificados

Se descuenta un costo fijo de 0,02 R. No se modelan spread variable, slippage, latencia, tamaño de posición, turnover, horario, rollover, margen ni restricciones de ejecución. Tampoco existe integración con broker o paper trading.

7. Baselines limitados

Los baselines publicados son variaciones del mismo vector de aciertos: operar siempre, filtrar aleatoriamente u operar con un umbral alto. No incluyen reglas de mercado independientes, modelos estadísticos simples ni comparaciones reproducidas con trabajos publicados. En consecuencia, no puede afirmarse superioridad frente al estado del arte.

8. Reproducibilidad incompleta

• Los artefactos HDF5 y checkpoints requeridos no están versionados.
• Las rutas esperadas por algunos notebooks no coinciden entre sí.
• requirements.txt no fija versiones y omite imports usados por los notebooks, entre ellos chronos, pywt, scipy e iisignature.
• No hay pruebas automatizadas, CI ni script único de ejecución.
• El repositorio contiene un solo commit, por lo que la evolución experimental no queda documentada.

9. Procedencia y licencia de datos

El archivo EURUSD_M15_all.parquet está incluido, pero el repositorio todavía debe documentar su proveedor, método de descarga y permiso de redistribución. No se debe asumir que un dataset de mercado puede redistribuirse sin revisar su licencia.

Trabajo pendiente prioritario

1. Reemplazar todas las referencias a market_tokens.h5 por una variante ajustada únicamente con datos pasados y regenerar resultados.
2. Aplicar purged splits y embargo en todas las fronteras, incluido el split base/meta/calibración.
3. Separar entrenamiento del meta-modelo, calibración del umbral y evaluación final.
4. Convertir etiquetas en eventos no solapados o estimar incertidumbre con métodos que respeten la dependencia temporal.
5. Construir un backtest sobre retornos y posiciones reales, con costos, turnover y reglas de entrada/salida explícitas.
6. Ejecutar ablaciones de modalidades y comparar contra baselines temporales simples bajo los mismos folds.
7. Reportar intervalos de confianza, estabilidad por período y sensibilidad a semillas e hiperparámetros.
8. Unificar rutas, fijar dependencias, agregar tests y proporcionar un flujo reproducible de extremo a extremo.
9. Documentar la procedencia del dataset y definir una licencia para el código.

Requisitos actuales

El archivo requirements.txt enumera una base mínima, pero todavía no representa un entorno reproducible. Antes de ejecutar se deben añadir las dependencias faltantes, fijar versiones compatibles y documentar la versión de CUDA/PyTorch utilizada.

Alcance y uso responsable

Este código se publica con fines educativos y de investigación. No debe utilizarse para operar capital real ni interpretarse como asesoría financiera. Cualquier conclusión posterior requiere una nueva evaluación con metodología corregida, datos cuya procedencia esté documentada y un holdout final que no se haya usado durante el desarrollo.

Autores

• Cristóbal Césped
• Boris Sagredo

Universidad Técnica Federico Santa María — proyecto académico, diciembre de 2025.

Licencia

El repositorio no incluye actualmente un archivo LICENSE. No asumas permiso de reutilización o redistribución hasta que los autores incorporen una licencia explícita.