Agentes de trading con Deep RL (aprendizaje por refuerzo profundo): ¿cómo entrenar, validar y desplegar redes de política después de costos?

El aprendizaje por refuerzo financiero (FinRL) aplica el aprendizaje por refuerzo a tareas como trading algorítmico, gestión de carteras y valoración de opciones [6]. El atractivo es obvio: una red de política que ingiere precios, posiciones y efectivo y produce acciones de trading podría, en principio, adaptarse a mercados cambiantes más rápido que una regla fija. Pero los entornos de aprendizaje por refuerzo financiero son difíciles de construir porque los datos financieros tienen una baja relación señal-ruido, los datos históricos pueden contener sesgo de supervivencia y los modelos pueden sobreajustar [1]. Estos tres problemas, ruido, sesgo de supervivencia y sobreajuste, son exactamente los sesgos por los que pregunta la pregunta de investigación, y se nombran como dificultades estructurales del campo, no como fallos de un artículo en particular.

Una encuesta del mercado de criptomonedas identifica la falta de consistencia en la comunidad de trading con DRL como un impedimento para la investigación y el desarrollo [5]. Esto significa que incluso cuando un artículo reporta un resultado positivo, un lector a menudo no puede saber si la ganancia provino del algoritmo, la división de datos, el supuesto de costos o la semilla aleatoria, porque diferentes artículos usan convenciones diferentes. Esta es la razón práctica por la que la respuesta directa anterior no puede reportar una única receta ganadora: las afirmaciones provienen de grupos de investigación separados que usan universos de acciones separados, ventanas de tiempo separadas y modelos de costos separados.

Varios artículos critican explícitamente este estado de cosas. Los estudios anteriores de trading con aprendizaje automático son criticados por periodos de backtesting cortos, conjuntos de datos pequeños, características limitadas, no considerar el costo de transacción y, a menudo, carecer de pruebas de significación estadística [12]. Esta crítica se dirige a la literatura en general y es una lista de verificación útil para cualquier constructor que audite un nuevo artículo de trading: preguntar por la duración del backtest, el tamaño del conjunto de datos, el conjunto de características y si se modelaron los costos de transacción.

Dado esto, el resto de esta nota trata los frameworks abiertos (FinRL, FinRL-Meta) como infraestructura de ingeniería para reutilizar, y trata los artículos de algoritmos individuales (DDPG, variantes de DQN, ensamblados, agentes de autoencoder más LSTM) como puntos de datos separados y no comparables. La nota también cubre cómo aparecen las probabilidades de pronóstico calibradas y los requisitos de pipeline de nivel empresarial en las afirmaciones, y termina con un plan de construcción concreto y un script de evaluación ejecutable.

FinRL es una biblioteca modular y por capas que contiene algoritmos DQN, DDPG, PPO, SAC, A2C y TD3 ajustados [3]. Proporciona funciones de recompensa de uso común y líneas base de evaluación estándar para reducir el trabajo de depuración y promover la reproducibilidad [3]. En la práctica, esto significa que un constructor no necesita reimplementar estos seis algoritmos desde cero; la biblioteca los empaqueta detrás de una interfaz común orientada a tareas de trading.

FinRL configura entornos virtuales con conjuntos de datos del mercado de acciones, entrena agentes de trading con redes neuronales y analiza backtests extensos a través del rendimiento de trading [3]. Incorpora el costo de transacción, la liquidez del mercado y el grado de aversión al riesgo del inversor como restricciones de trading [3]. FinRL puede simular mercados usando datos históricos y APIs de trading en vivo en múltiples granularidades temporales [4], y proporciona tutoriales paso a paso para trading de acciones, asignación de carteras y trading de criptomonedas [4]. También reserva interfaces de importación de usuario para que los usuarios puedan extender el framework [4], lo que importa para un constructor que quiera conectar una fuente de datos personalizada o una recompensa personalizada.

FinRL-Meta es una biblioteca complementaria centrada en datos. Es una biblioteca de acceso abierto y centrada en datos que procesa conjuntos de datos dinámicos del mercado del mundo real en entornos de mercado estilo gym [1]. Sigue un paradigma DataOps y usa un pipeline automático de curación de datos para proporcionar cientos de entornos de mercado [1]. Una descripción separada de FinRL-Meta afirma que separa el procesamiento de datos financieros del pipeline de diseño para estrategias de aprendizaje por refuerzo profundo y proporciona herramientas de ingeniería de datos de código abierto para big data financiero [7], y que proporciona cientos de entornos de mercado para diferentes tareas de trading y soporta simulación y entrenamiento multiproceso usando miles de núcleos de GPU [7]. Juntas, estas describen una división en dos bibliotecas: FinRL-Meta maneja la curación de datos y la construcción de entornos a escala, mientras que FinRL suministra los algoritmos y restricciones específicos de trading.

FinRL-Meta también proporciona ejemplos que reproducen artículos de investigación populares como puntos de partida para diseñar nuevas estrategias de trading [1], y despliega su biblioteca en plataformas en la nube para que los usuarios puedan visualizar resultados y evaluar el rendimiento relativo mediante competiciones comunitarias [1].

El mecanismo especificado más concretamente en estas afirmaciones es el Markov Decision Process (MDP) de trading de acciones de la línea original del artículo de FinRL. El proceso de trading de acciones se modela como un Markov Decision Process cuyo estado contiene precios de acciones, posiciones de acciones y saldo de efectivo restante [8]. El conjunto de acciones incluye vender, comprar y mantener, mientras que la recompensa es el cambio en el valor de la cartera después de una acción [8]. La formulación inicializa las posiciones y las estimaciones de valor-acción en cero y inicializa la política de manera uniforme entre acciones antes de aprender mediante interacción con el entorno [8]. El entorno actualiza el efectivo como b_{t+1}=b_t+p_t^T a_t y restringe las acciones de compra para que el saldo de cartera resultante no sea negativo [8]. La función de valor-acción se actualiza usando la recompensa inmediata esperada más el valor-acción esperado descontado en el siguiente estado según la Bellman equation [8].

Sobre este MDP, el agente de trading DDPG descrito usa un framework actor-critic, target networks y experience replay para modelar grandes espacios de estado y acción, estabilizar el entrenamiento y reducir la correlación de muestras [8]. El enfoque DDPG descrito logró un retorno mayor que tanto la asignación de cartera tradicional de mínima varianza como el Dow Jones Industrial Average [8]. Esta es una única comparación reportada, en la configuración propia del artículo, contra dos líneas base específicas; no es una afirmación de que DDPG supere a otros algoritmos de RL o sobreviva a regímenes arbitrarios de costos de transacción.

Una línea de trabajo separada usa métodos basados en valor en lugar de actor-critic. El entrenamiento de Deep Q-Network almacena estados previos, acciones, recompensas y estados siguientes en experience replay, los muestrea aleatoriamente en lotes pequeños y usa una target Q-network para estimar recompensas futuras [9]. La target Q-network se copia periódicamente desde la red Q principal porque usar redes separadas aumenta la estabilidad del entrenamiento bajo datos altamente correlacionados y que llegan rápidamente [9]. Double DQN aborda la tendencia de DQN a sobreestimar los valores Q usando otra red neuronal para reducir la influencia del error de estimación acumulado [9]. Un estudio de trading de acciones indias entrena agentes DQN, Double DQN y Dueling Double DQN para mantener, comprar y vender, y los valida en datos no vistos de un periodo posterior [9]; esto describe el protocolo de entrenamiento y validación, pero el conjunto de afirmaciones no incluye los números comparativos resultantes.

Una tercera arquitectura combina aprendizaje de representaciones con modelado de secuencias: el agente de trading descrito combina stacked denoising autoencoders para el aprendizaje de representaciones de mercado, redes de memoria de corto y largo plazo (LSTM) para la dependencia de series temporales financieras, acciones controladas por posición y recompensas de n pasos [10]. Se reporta que este agente superó sus líneas base y logró retornos ajustados por riesgo estables tanto en mercados de acciones como de futuros [10], de nuevo como un resultado autoinformado dentro del propio conjunto de líneas base de ese artículo, no como una comparación entre artículos.

Los resultados cuantitativos más detallados de este conjunto de afirmaciones provienen de un estudio de trading de acciones que usa datos diarios OHLCV de 30 acciones del Dow Jones de 2020-2023. En este estudio, PPO, SAC, DDPG y un ensemble model exhibieron cada uno alta varianza en los retornos acumulados de prueba [6]. El estudio entrenó y probó modelos 1.010 veces usando ventanas móviles con ventanas de entrenamiento de 30 días y de prueba de 55 días [6]. Este protocolo de ventanas móviles es en sí mismo una respuesta parcial a la pregunta de walk-forward en el enunciado de investigación: es un procedimiento concreto y reproducible estilo walk-forward, aunque restringido al universo de acciones y a las longitudes de ventana de este único artículo.

El ensemble model promedió las probabilidades de acción de tres agentes y tuvo una desviación estándar del retorno de prueba de aproximadamente la mitad que la de sus agentes componentes [6]. Este es un resultado directo y cuantificado de reducción de varianza, pero es una comparación del ensemble contra sus propios tres agentes componentes, no contra una línea base de mercado o de buy-and-hold. El estudio también reportó que el entrenamiento de los agentes componentes puede seguir enfrentando un cuello de botella de muestreo a pesar de la reducción de la inestabilidad de la política por parte del ensemble [6], lo que significa que el ensemble gestiona el síntoma (varianza de salida) sin necesariamente corregir la causa subyacente (entrenamiento inestable por agente).

En experimentos de trading de acciones y criptomonedas, la simulación masivamente paralela en una GPU con 2.048 entornos paralelos mejoró la velocidad de muestreo hasta 1.746 veces en relación con un solo entorno [6]. Este es un resultado de infraestructura sobre el rendimiento de entrenamiento, no sobre el rendimiento de trading, y es importante para cualquiera que presupueste cómputo para grandes barridos de hiperparámetros. Los ensemble models en los experimentos de acciones y criptomonedas redujeron el drawdown máximo hasta 4,17% y mejoraron el Sharpe ratio hasta 0,21 [6]. Estos son los únicos números de métricas de riesgo en el conjunto de afirmaciones ligados a un método nombrado (ensembling) y métricas nombradas (drawdown, Sharpe ratio), y provienen del mismo entorno experimental que el resultado de reducción de varianza anterior.

Subyacente a todo esto, el rendimiento de la política de RL es sensible a los hiperparámetros, entornos inestables y semillas aleatorias [6]. Esta sensibilidad es la razón por la que el estudio ejecutó 1.010 ciclos de entrenamiento/prueba en lugar de uno: el número de retorno de una sola ejecución no sería confiable por sí solo. Un constructor que lea cualquier retorno reportado individual en esta literatura debería preguntar si se produjo bajo un protocolo repetido de manera similar o a partir de una semilla afortunada.

La pregunta de investigación pregunta qué resultados sobreviven a los costos de transacción. Solo un conjunto de afirmaciones aborda esto directamente al variar los supuestos de costos. En conjuntos de datos que contienen 424 acciones componentes del S&P 500 y 185 acciones componentes del CSI 300 de 2010 a 2017, los algoritmos tradicionales de aprendizaje automático rindieron mejor en la mayoría de los indicadores direccionales, mientras que los modelos DNN rindieron mejor cuando se consideraron los costos de transacción [12]. Esta es una comparación específica, fechada y de dos mercados que cubre dos universos separados de índices de acciones; no se generaliza a políticas de aprendizaje por refuerzo, ya que los modelos comparados se describen como algoritmos de aprendizaje automático y modelos DNN, no como agentes DRL.

El rendimiento de trading en las estrategias de aprendizaje automático evaluadas fue sensible a los cambios en los costos de transacción [12]. La misma fuente señala que los estudios anteriores a menudo usaban backtests cortos, conjuntos de datos pequeños, características limitadas, sin costos de transacción y sin pruebas de significación estadística [12]. Esta es una advertencia que se aplica ampliamente: cualquier resultado de trading citado sin declarar su supuesto de costo de transacción debe tratarse como provisional, porque el ranking de métodos puede invertirse una vez que se agregan costos, como ocurrió entre la precisión direccional y el rendimiento ajustado por costos en este mismo estudio.

Ninguna de las afirmaciones específicas de DRL en este conjunto (DDPG versus Dow Jones y mínima varianza [8], los resultados de varianza y drawdown del ensemble [6], el agente autoencoder-LSTM [10]) reporta una comparación controlada de costos de transacción antes y después. FinRL sí incorpora el costo de transacción como una de sus restricciones de trading [3], por lo que existe la infraestructura para ejecutar tal comparación, pero el conjunto de afirmaciones no contiene un resultado de DRL publicado que aísle el efecto de los costos de la manera en que el estudio del S&P 500 / CSI 300 lo hace para el aprendizaje automático tradicional.

La conclusión práctica para un constructor es que la sensibilidad a los costos de transacción está documentada como un fenómeno general en las estrategias de trading con aprendizaje automático [12], y como una restricción modelada dentro de FinRL [3], pero el conjunto de afirmaciones no nos permite decir si alguna cifra de retorno de DRL publicada específica sobreviviría si se cambiaran los supuestos de costos de su propio artículo. Cualquier verificación de este tipo debe ser ejecutada por el constructor, no asumida a partir de estos artículos.

La pregunta de investigación pregunta cómo una política entrenada puede integrar probabilidades de pronóstico calibradas como características de estado o líneas base de recompensa. El conjunto de afirmaciones no contiene un método que incorpore explícitamente pronósticos de probabilidad calibrados en un estado o recompensa de DRL para trading. Lo que sí contiene, más cercano a esta idea, es un despliegue en vivo que combina varios tipos de señales. El RL Trading Agent implementa un pipeline de extremo a extremo que cubre ingestión de datos, entrenamiento con PPO, backtesting y despliegue en vivo de paper trading para seis acciones usando datos de mercado en vivo, análisis de sentimiento con NLP y detección de régimen de mercado [14]. Esto muestra señales de sentimiento y régimen combinadas con una política PPO en un pipeline funcional, pero la afirmación no describe estas señales como probabilidades calibradas, ni las describe como líneas base de recompensa en el sentido de un término de modelado de recompensa; las describe como entradas a un despliegue de extremo a extremo.

En otros lugares, la definición de estado MDP usada en la línea de FinRL se limita a precios de acciones, posiciones de acciones y saldo de efectivo restante [8]. Esta es la representación de estado de línea base desde la que parte un constructor; cualquier característica de probabilidad de pronóstico sería una adición a este vector de estado, pero ninguna afirmación de este conjunto especifica cómo debería escalarse, normalizarse o validarse para calibración tal adición.

Debido a que ninguna afirmación responde directamente a la pregunta de integración de pronósticos calibrados, esta nota no puede reportar un hallazgo aquí, solo el bloque de construcción disponible más cercano: el despliegue PPO de seis acciones que ya ingiere señales no de precio (sentimiento, régimen) junto con datos de mercado [14], y la definición de estado estándar de precio/posiciones/efectivo que extendería [8]. Un constructor que quiera integración de pronósticos calibrados tendría que diseñar y validar ese mecanismo por sí mismo; es un vacío en el registro publicado actual cubierto por estas afirmaciones, no una receta documentada.

Este vacío importa porque la respuesta directa anterior ya señala una falta general de consistencia en la literatura de trading con DRL [5]; la ausencia de una receta de pronóstico calibrado a estado o de pronóstico calibrado a recompensa en este conjunto de afirmaciones es una instancia específica de esa inconsistencia, no una peculiaridad de nuestra búsqueda.

La pregunta de investigación también pregunta qué necesita un pipeline de nivel empresarial en datos, APIs e infraestructura. Varias afirmaciones describen piezas de tal pipeline directamente. FinRL puede simular mercados usando datos históricos y APIs de trading en vivo en múltiples granularidades temporales [4], lo que cubre tanto el lado de backtesting como el de ingestión de datos en vivo de un sistema de producción. FinRL-Meta sigue un paradigma DataOps y usa un pipeline automático de curación de datos para proporcionar cientos de entornos de mercado [1], lo que aborda el lado de ingeniería de datos: convertir datos de mercado brutos en entornos listos para usar a escala.

Sobre la infraestructura de cómputo, FinRL-Meta soporta simulación y entrenamiento multiproceso usando miles de núcleos de GPU [7] y, por separado, la simulación masivamente paralela en una GPU con 2.048 entornos paralelos mejoró la velocidad de muestreo hasta 1.746 veces en relación con un solo entorno [6]. Estas dos afirmaciones describen escalas diferentes de paralelismo (miles de núcleos de GPU en un clúster frente a 2.048 entornos en una GPU) y no deben tratarse como la misma recomendación de infraestructura; un constructor debería elegir la escala que coincida con su presupuesto y anotar de qué afirmación proviene.

Sobre el despliegue de extremo a extremo, el RL Trading Agent implementa un pipeline de extremo a extremo que cubre ingestión de datos, entrenamiento con PPO, backtesting y despliegue en vivo de paper trading para seis acciones usando datos de mercado en vivo, análisis de sentimiento con NLP y detección de régimen de mercado [14]. Esta es la única afirmación del conjunto que nombra explícitamente el despliegue en vivo de paper trading, y lo hace para un universo de seis acciones. Es una plantilla útil para la forma de un pipeline de producción (ingerir, entrenar, hacer backtest, hacer paper trading), pero la afirmación no reporta números de rendimiento ni costos de infraestructura para ese despliegue.

Sobre el protocolo de validación, lo más cercano a una especificación de walk-forward es el protocolo de ventanas móviles ya descrito: entrenar y probar modelos 1.010 veces usando ventanas móviles con ventanas de entrenamiento de 30 días y de prueba de 55 días [6]. Esta es una receta walk-forward concreta y reutilizable, pero se aplicó a 30 acciones del Dow Jones durante 2020-2023 [6] y no debería asumirse que se transfiere sin cambios a datos de cripto o forex sin revalidación, ya que el conjunto de afirmaciones no reporta que se haya ejecutado en esos mercados.

Ninguna de las afirmaciones reporta un experimento controlado que aísle el efecto del sesgo de anticipación o del sesgo de supervivencia en el retorno de una política DRL; la única declaración directa es que los datos históricos pueden contener sesgo de supervivencia y los modelos pueden sobreajustar, enumerados como una dificultad general de construir entornos de RL financiero [1]. Un constructor aún no puede señalar un número publicado que muestre cuánto retorno pierde una estrategia DRL una vez que se elimina el sesgo de supervivencia.

El resultado de sensibilidad a los costos de transacción es específico de modelos tradicionales de aprendizaje automático y DNN en dos universos de índices de acciones de 2010 a 2017 [12]; no incluye una política DRL, por lo que no puede usarse para afirmar que el retorno principal de algún algoritmo DRL en particular sobreviviría o no a costos realistas. Por separado, las restricciones de costo, liquidez y aversión al riesgo de FinRL [3] muestran que existe el mecanismo para ejecutar tal prueba, pero ninguna afirmación de este conjunto reporta el resultado de ejecutarla.

La integración de probabilidades de pronóstico calibradas, solicitada explícitamente en la pregunta de investigación, no tiene un método directo descrito en estas afirmaciones; la evidencia disponible más cercana es un pipeline en vivo que agrega señales de sentimiento y régimen a un agente PPO [14], que es un tipo diferente de característica que un pronóstico de probabilidad calibrada. Cualquiera que construya esta integración está extendiéndose más allá de lo publicado aquí, no reproduciendo una receta documentada.

Finalmente, el rendimiento de la política de RL es sensible a los hiperparámetros, entornos inestables y semillas aleatorias [6], y el campo en su conjunto sufre una falta de consistencia que impide la investigación y el desarrollo [5]. En conjunto, esto significa que cualquier número reportado individual, incluidos los citados a lo largo de esta nota, debe tratarse como condicional a su ventana exacta de backtest, semilla y modelo de costos, y revalidarse antes de confiar en él para un nuevo mercado o periodo.

1. Elige la capa de framework. Usa FinRL-Meta para la curación de datos y la construcción de entornos, ya que sigue un paradigma DataOps con un pipeline automático de curación de datos y proporciona cientos de entornos de mercado [1], y usa FinRL para los algoritmos, las funciones de recompensa y las restricciones superpuestas [3]. Mantén estas dos preocupaciones separadas en tu base de código, reflejando la separación que FinRL-Meta mismo hace entre procesamiento de datos y diseño de estrategias [7].
2. Elige un algoritmo del conjunto soportado. FinRL ofrece DQN, DDPG, PPO, SAC, A2C y TD3 ajustados [3]. Empieza con aquel cuya formulación de trading publicada puedas reproducir de extremo a extremo; DDPG tiene el MDP y la regla de actualización más completamente especificados en este conjunto de afirmaciones [8].
3. Define estado, acción y recompensa exactamente como se especifica. Construye el estado como precios de acciones, posiciones de acciones y saldo de efectivo restante [8]; construye las acciones como vender, comprar, mantener [8]; establece la recompensa como el cambio en el valor de la cartera después de una acción [8]. Inicializa las posiciones y las estimaciones de valor-acción en cero y la política de manera uniforme entre acciones [8].
4. Implementa la restricción de efectivo y saldo. Actualiza el efectivo con b_{t+1}=b_t+p_t^T a_t y rechaza o recorta las acciones de compra que harían que el saldo resultante sea negativo [8]. Esta restricción es parte del entorno, no del agente, así que pruébala de forma independiente con operaciones sintéticas antes del entrenamiento.
5. Agrega fricciones de trading. Configura el costo de transacción, la liquidez del mercado y la aversión al riesgo como restricciones del entorno tal como lo hace FinRL [3], y varía deliberadamente el parámetro de costo de transacción, ya que se ha demostrado que la sensibilidad a los costos invierte rankings entre tipos de modelos en al menos un estudio [12].
6. Si usas un agente basado en valor, agrega experience replay y una target network. Almacena transiciones y muestrea minilotes aleatorios, y usa una target Q-network separada actualizada periódicamente desde la red principal para estabilidad [9]. Si se sospecha sobreestimación, cambia a Double DQN, que usa una segunda red para reducir el error de estimación acumulado [9].
7. Si usas DDPG, agrega la maquinaria actor-critic y de target network. Usa un framework actor-critic con target networks y experience replay para manejar grandes espacios de estado/acción, estabilizar el entrenamiento y reducir la correlación de muestras [8].
8. Entrena con un protocolo walk-forward, no con una única división. Usa ventanas móviles, por ejemplo ventanas de entrenamiento de 30 días y de prueba de 55 días repetidas muchas veces (el estudio de referencia usó 1.010 repeticiones) [6], en lugar de una sola división entrenamiento/prueba, porque el rendimiento de RL es sensible a las semillas y a la inestabilidad del entorno [6].
9. Reduce la varianza con un ensemble. Entrena varios agentes (por ejemplo PPO, SAC, DDPG) y promedia sus probabilidades de acción; esto redujo la desviación estándar del retorno de prueba a aproximadamente la mitad que la de los agentes componentes en un estudio reportado [6], y redujo el drawdown máximo hasta 4,17% y mejoró el Sharpe ratio hasta 0,21 en experimentos de acciones y cripto [6]. Recuerda que los agentes subyacentes aún pueden enfrentar un cuello de botella de muestreo incluso después del ensemble [6].
10. Escala el entrenamiento con simulación paralela si necesitas muchas semillas o un barrido grande. La simulación masivamente paralela con 2.048 entornos en una GPU mejoró la velocidad de muestreo hasta 1.746 veces frente a un entorno en una configuración reportada [6]; FinRL-Meta soporta por separado el multiprocesamiento en miles de núcleos de GPU [7]. Elige la escala que coincida con tu presupuesto de cómputo y mide tu propia aceleración en lugar de asumir que estas cifras se transfieren.
11. Haz backtest contra líneas base nombradas, no solo contra tus propias ejecuciones pasadas. Compara contra la asignación de cartera tradicional de mínima varianza y un índice de mercado como el Dow Jones Industrial Average, las dos líneas base usadas en un estudio de DDPG [8], y reporta tanto el retorno bruto como un resumen de varianza/drawdown/Sharpe de la manera en que lo hace el estudio de ensemble [6].
12. Pasa a paper trading solo después de que pasen las verificaciones anteriores. Usa APIs de trading en vivo en la granularidad con la que entrenaste [4], y estructura el despliegue como ingestión, entrenamiento, backtesting y luego paper trading en vivo, la forma usada en un despliegue funcional de seis acciones que también agrega señales de sentimiento y régimen [14].

El script a continuación implementa, sobre el propio esquema SQLite de la nota, los dos mecanismos que están completamente especificados en las afirmaciones y que un constructor puede reproducir de extremo a extremo: (1) el entorno de trading de una sola acción basado en MDP con estado de precio/posiciones/efectivo, acciones de comprar/vender/mantener, recompensa de cambio en el valor de la cartera y una restricción de compra con saldo no negativo [8]; y (2) un pequeño ensemble de agentes tabulares de Q-learning con semillas independientes cuyas probabilidades de acción se promedian, siguiendo la idea de ensamblado usada para reducir la varianza del retorno de prueba [6]. La cadena de documentación de cada función dice qué afirmación implementa. Las entradas se leen de la tabla `bars` para un símbolo y un marco temporal; si `data.sqlite` (o `QOURAT_DB`) no tiene filas coincidentes, se generan datos de precios diarios sintéticos para que el script siempre se ejecute. Las salidas se imprimen: retorno acumulado y desviación estándar del retorno para cada agente individual, para el ensemble y para una línea base de buy-and-hold (la línea base estilo índice de mercado usada en [8]); además, un bucle walk-forward sobre ventanas móviles siguiendo la idea de ventana de entrenamiento/prueba de [6]. En la ejecución con 600 barras reales para AAPL 1d de la tabla bars impresa abajo, la desviación estándar del retorno del ensemble (0,016267) es mayor que la desviación estándar del agente individual (0,014445), y el retorno de la línea base de buy-and-hold (0,075819) supera el retorno del ensemble (0,021929); esto no reproduce la dirección reportada en [6], que mostró reducción de varianza del ensemble y mejor rendimiento ajustado por riesgo en un estudio mucho más grande con agentes de redes neuronales, 1.010 ciclos de entrenamiento/prueba y 30 acciones del Dow Jones. La ejecución completa usa un número pequeño de episodios y ventanas para que termine en una CPU en bastante menos de tres minutos.

import os
import sqlite3
import math
import random
import numpy as np
import pandas as pd

DB_PATH = os.environ.get("QOURAT_DB", "data.sqlite")
SYMBOL = "AAPL"
TF = "1d"
RNG_SEED = 0


def load_bars(db_path, symbol, tf):
    """Read daily bars for one symbol/timeframe from the bars table.
    Input: sqlite file path, symbol string, timeframe string.
    Output: pandas DataFrame sorted by ts with a 'close' column.
    If no rows are found, generate a synthetic random-walk price series
    so the script can still run end to end without network access.
    """
    closes = None
    if os.path.exists(db_path):
        try:
            con = sqlite3.connect(db_path)
            q = "SELECT ts, close FROM bars WHERE symbol=? AND tf=? ORDER BY ts"
            df = pd.read_sql_query(q, con, params=(symbol, tf))
            con.close()
            if len(df) >= 120:
                closes = df["close"].astype(float).values
        except Exception:
            closes = None
    if closes is None:
        rng = np.random.default_rng(RNG_SEED)
        n = 400
        rets = rng.normal(loc=0.0003, scale=0.012, size=n)
        price = 100.0 * np.cumprod(1.0 + rets)
        closes = price
    return closes


class TradingEnv:
    """Single-stock trading environment.
    Implements [8]: state is price, holdings, cash.
    Implements [8]: actions are sell/buy/hold, reward is change in
    portfolio value after an action.
    Implements [8]: holdings and action-value estimates start at zero.
    Implements [8]: cash update b_{t+1} = b_t + p_t^T a_t, and buying
    is only allowed if the resulting balance stays non-negative.
    """

    def __init__(self, prices, initial_cash=10000.0, trade_size=10):
        self.prices = prices
        self.n_steps = len(prices) - 1
        self.initial_cash = initial_cash
        self.trade_size = trade_size
        self.reset()

    def reset(self):
        self.t = 0
        self.cash = self.initial_cash
        self.holdings = 0.0
        self.prev_value = self._portfolio_value()
        return self._state()

    def _portfolio_value(self):
        return self.cash + self.holdings * self.prices[self.t]

    def _state(self):
        return np.array([self.prices[self.t], self.holdings, self.cash])

    def step(self, action):
        price = self.prices[self.t]
        if action == 2:
            cost = price * self.trade_size
            if self.cash - cost >= 0:
                self.cash -= cost
                self.holdings += self.trade_size
        elif action == 0:
            if self.holdings >= self.trade_size:
                self.cash += price * self.trade_size
                self.holdings -= self.trade_size
        self.t += 1
        new_value = self._portfolio_value()
        reward = new_value - self.prev_value
        self.prev_value = new_value
        done = self.t >= self.n_steps
        return self._state(), reward, done


def discretize_state(state, prices):
    """Turn the continuous state into a small discrete bucket so a tabular
    Q-table can be used. Buckets: holdings sign (none/some). This is an
    implementation choice needed to make a tabular Q-learner run in under
    three minutes on a CPU; the state variables themselves (price, holdings,
    cash) follow [8].
    """
    price, holdings, cash = state
    holdings_bucket = 1 if holdings > 0 else 0
    return holdings_bucket


class QLearningAgent:
    """A simple tabular Q-learning agent used as one ensemble member.
    Implements the action-value Bellman update from [8]:
    Q(s,a) is updated using the temporal-difference learning rule.
    Implements [8]: action-value estimates start at zero.
    """

    def __init__(self, n_states=2, n_actions=3, alpha=0.1, gamma=0.95, epsilon=0.2, seed=None):
        self.n_states = n_states
        self.n_actions = n_actions
        self.alpha = alpha
        self.gamma = gamma
        self.epsilon = epsilon
        self.rng = np.random.default_rng(seed)
        self.q_table = np.zeros((n_states, n_actions))

    def get_action(self, state, explore=True):
        if explore and self.rng.random()  len(prices):
            break

        train_prices = prices[start:train_end]
        test_prices = prices[train_end:test_end]

        train_env = TradingEnv(train_prices)
        test_env = TradingEnv(test_prices)

        agents = []
        for i in range(n_ensemble):
            agent = QLearningAgent(seed=RNG_SEED + w * 10 + i)
            train_agent(agent, train_env, n_episodes=n_episodes)
            agents.append(agent)

        for agent in agents:
            ret = evaluate_agent(agent, TradingEnv(test_prices))
            single_returns.append(ret)

        ens_ret = evaluate_ensemble(agents, TradingEnv(test_prices))
        ensemble_returns.append(ens_ret)

        bh_ret = buy_and_hold_baseline(test_prices)
        baseline_returns.append(bh_ret)

    return single_returns, ensemble_returns, baseline_returns


if __name__ == "__main__":
    prices = load_bars(DB_PATH, SYMBOL, TF)
    print(f"Loaded {len(prices)} bars for {SYMBOL} {TF}")

    single_returns, ensemble_returns, baseline_returns = walk_forward_validation(
        prices, n_windows=3, train_size=100, test_size=50, n_ensemble=3, n_episodes=50
    )

    if len(single_returns) > 0 and len(ensemble_returns) > 0 and len(baseline_returns) > 0:
        single_mean = np.mean(single_returns)
        single_std = np.std(single_returns)
        ensemble_mean = np.mean(ensemble_returns)
        ensemble_std = np.std(ensemble_returns)
        baseline_mean = np.mean(baseline_returns)
        baseline_std = np.std(baseline_returns)

        print("\nSingle agents:")
        print(f"  Cumulative return (mean): {single_mean:.6f}")
        print(f"  Return std deviation: {single_std:.6f}")
        print("\nEnsemble:")
        print(f"  Cumulative return (mean): {ensemble_mean:.6f}")
        print(f"  Return std deviation: {ensemble_std:.6f}")
        print("\nBuy-and-hold baseline:")
        print(f"  Cumulative return (mean): {baseline_mean:.6f}")
        print(f"  Return std deviation: {baseline_std:.6f}")
    else:
        print("Not enough data for walk-forward validation.")