Nuestro recorrido por la inteligencia artificial.

Al principio queríamos preparar datos de mercado, entrenar modelos y obtener sus salidas en nuestro propio entorno Python. Con «nuestra propia IA» nos referíamos a modelos especializados en preguntas numéricas de mercado. No intentábamos entrenar desde cero un modelo de lenguaje general; eso exigiría otra escala de datos y computación.

El trabajo práctico nos obligó a concretar la pregunta. ¿Qué debía recibir el modelo: una vela, una secuencia o una tabla de variables calculadas? ¿Qué debía estimar: una dirección, un rango numérico u otra cosa? Tuvimos que definir objetivos, ordenar entradas y conservar las transformaciones antes de que un modelo guardado fuera útil.

Exploramos varias ramas. Las LSTM nos permitieron trabajar con secuencias; los modelos de árboles, con variables elaboradas; Prophet, con una formulación de serie temporal. Después usamos APIs de proveedores para enviar contexto a modelos de lenguaje ya entrenados y exploramos imágenes mediante visión artificial local. Cada herramienta respondía a preguntas distintas.

Nos quedó especialmente clara la importancia de describir la tarea. «Local» indica dónde se ejecuta un cálculo, no si el modelo aprende de números, interpreta texto o detecta objetos en una imagen. Mantenemos esas diferencias a lo largo de los capítulos.

Queríamos que el modelo observara cómo evolucionaban las mediciones, en lugar de tratar la última vela como un momento aislado. Esto nos llevó a las LSTM, que procesan observaciones en orden y mantienen un estado interno a lo largo de la secuencia. Preparamos ventanas móviles con una pequeña historia en cada entrada.

En los modelos de clasificación archivados, cada ventana contiene 30 observaciones y 689 variables por observación. Son dimensiones de modelos históricos de investigación, no presets operativos publicados. La preparación exigía mantener las columnas en el mismo orden y aplicar el escalado ajustado para ese modelo.

También tuvimos que definir el significado de las tres clases. La lectura prevista era bajista, neutral o alcista, pero el horizonte y las reglas de etiquetado daban sentido real a esos términos. Cambiar la definición de una etiqueta habría cambiado la pregunta, aunque la arquitectura de la red siguiera igual.

Trabajamos con una LSTM compacta y otra apilada de mayor tamaño. Ambas devolvían tres puntuaciones de clase. Las tratábamos como una descripción del modelo sobre la entrada, no como una trayectoria futura completa del precio. La lista de variables, el escalador y la definición del objetivo resultaron tan importantes como la red guardada.

Una etiqueta direccional dejaba parte de nuestra pregunta sin responder. Dos movimientos alcistas pueden tener tamaños muy distintos y recorridos diferentes. Exploramos la regresión para expresar cantidades, con dos valores de salida en lugar de tres puntuaciones de clase.

Las variantes archivadas utilizan 240 variables y ventanas de 30 o 60 observaciones, con LSTM apiladas y componentes de tipo atención. Esas estructuras permitían trabajar con distintas cantidades de historia y ponderaciones internas. Aun así, debíamos explicar el significado y la unidad de cada salida; una red más elaborada no lo hace por nosotros.

Trabajamos las transformaciones en ambos extremos: la entrada debía respetar la escala del entrenamiento y la salida regresar a sus unidades previstas. Otros scripts de inferencia empleaban un selector de variables guardado y una entrada LSTM de un solo paso. Conservamos esa formulación separada de los modelos de 30/60 pasos. Los informes colocaban diferencias máximas y mínimas observadas junto a sus predicciones.

El trabajo con rangos también nos hizo pensar en el orden. Un recorrido puede alcanzar primero el mínimo y después el máximo, o al revés, compartiendo los mismos extremos. La ilustración muestra esa diferencia. Estimar dos límites no reconstruye todo lo que ocurre entre ellos.

Nuestro trabajo no se limitó a redes neuronales. También usamos familias basadas en árboles, como XGBoost y CatBoost. Su manera de dividir los valores de las variables difiere de una LSTM que procesa una historia ordenada, aunque ambas partan de mediciones del mismo mercado.

Desarrollamos scripts de servicio que cargaban varias familias de modelos y ofrecían sus salidas mediante una interfaz común. Esto permitía examinarlas dentro de un mismo proceso. Mantuvimos aparte otra pregunta: hacer disponibles las salidas no demuestra cómo deben combinarse ni que un ensemble aporte valor.

Los cuantiles nos dieron otra forma de describir una salida. Una interfaz archivada utilizaba los percentiles 20, 50 y 80: una estimación inferior, la mediana y una superior. El intervalo entre el 20% y el 80% tiene una cobertura central nominal del 60% si los cuantiles están calibrados. No lo presentamos como una garantía de confianza del 80%.

Así ampliamos el lenguaje de la investigación. Una clase nombra un estado; una estimación puntual expresa una cantidad; una banda de cuantiles sitúa valores en una distribución condicional. Podíamos elegir la salida según la pregunta, sin tratar todas las puntuaciones como equivalentes.

Después de trabajar con matrices de variables y ventanas móviles, exploramos una formulación más directa de serie temporal. Nuestro script de Prophet utilizaba observaciones de XAUUSD cada 15 minutos y solicitaba cinco observaciones futuras. La atención se desplazó hacia la evolución de la propia serie.

Prophet ofrecía un marco con tendencia y componentes estacionales opcionales. También hacía sencillo explicar el horizonte: cinco pasos de 15 minutos son 75 minutos durante una sesión continua. Los cierres y los datos ausentes siguen importando; cinco filas no siempre equivalen a tiempo de reloj ininterrumpido.

Nuestro archivo también incluye un informe etiquetado como ARIMAX, con tiempos y diferencias máximas/mínimas observadas y predichas. ARIMAX combina una estructura autorregresiva con variables explicativas externas. El informe conserva esa rama del trabajo, aunque no revela todas sus decisiones de modelado. No reconstruimos lo que falta a partir del nombre del archivo.

Alternar enfoques cambió nuestras preguntas. En una red secuencial elegimos la historia ordenada de variables que presentamos. En una serie temporal, la estructura del tiempo forma parte de la formulación. Ambas nos obligan a precisar a qué momento pertenece una observación y qué significa «hacia delante».

Cuando empezamos a utilizar APIs de modelos de lenguaje, trabajábamos con modelos que los proveedores ya habían entrenado. Nuestra contribución estaba en el proceso que los rodeaba: reunir información, decidir qué incluir y plantear una pregunta que pudiéramos registrar y revisar.

Nuestro flujo Python reunía velas de MT5 en M5, M15 y M30, un tick actual y publicaciones públicas de analistas con fecha y hora. Tratábamos los precios como observaciones y los comentarios como interpretaciones. Conservar sus fuentes y tiempos importaba, porque afirmaciones seguras pueden referirse a momentos distintos o discrepar sobre el mismo mercado.

Pedíamos un plan en JSON con escenarios, condiciones, invalidación y una opción de no operar. La estructura facilitaba pasarlo a software y revisarlo después. Pero pedir JSON no resolvía la validez de su contenido. El script guardaba e imprimía la respuesta: era un proceso de contexto y respuesta, no evidencia de un controlador completo de ejecución.

Esta vía nos enseñó algo diferente del entrenamiento local. No necesitábamos atribuirnos la autoría del modelo de lenguaje para realizar un trabajo importante a su alrededor. Elegir la evidencia, formular la petición y conservar la respuesta eran partes esenciales del uso del servicio.

Al mirar un gráfico reconocemos relaciones espaciales: grupos de velas, movimientos y estructuras marcadas. Queríamos explorar directamente esa representación, por lo que nuestro recorrido incluyó una vía local basada en YOLOv8 para imágenes de gráficos.

La tarea cambiaba. Un detector localiza y clasifica objetos visibles, normalmente mediante cajas y puntuaciones. Tuvimos que pensar qué estructuras podían etiquetarse con consistencia y qué contaba como ejemplo. Detectar una forma visible no es explicar una captura en lenguaje, ni tampoco predecir un precio futuro.

La propia imagen planteaba preguntas. El zoom, el recorte, la anchura de las velas, los colores y las anotaciones modifican los píxeles. Por eso distinguimos las decisiones de presentación de la información de mercado que queríamos representar. También importan los ejemplos sin la estructura buscada: no deberíamos esperar que el detector la encontrara en cada gráfico.

Finalmente, el detector expresa posiciones en píxeles y el trabajo de trading utiliza precio y tiempo. Relacionarlos exige conocer la escala y las coordenadas del gráfico. Por eso consideramos la visión una rama propia, con su preparación y su interpretación.

Las observaciones de mercado y la lógica de los sistemas estaban en MT5, mientras Python aportaba bibliotecas de modelos y herramientas de investigación. Conectarlos exigía más que enviar una lista de números: debíamos acordar qué cruzaba esa frontera y qué significaban los valores devueltos.

Desarrollamos varias versiones de servicios de inferencia que cargaban combinaciones de LSTM, árboles y modelos de cuantiles. Preparaban los datos recibidos y devolvían salidas mediante una interfaz común. Era una tarea de ingeniería distinta del entrenamiento: cada modelo esperaba una organización concreta de observaciones y variables.

Los archivos complementarios cobraron importancia. Una lista conservaba el significado y orden de las columnas; un escalador de entrada mantenía la transformación del entrenamiento; otro de salida restauraba las unidades de regresión. Teníamos que interpretar juntos la versión, la longitud de secuencia, el instrumento y el marco temporal. Recibir una respuesta solo probaba que la petición había sido atendida.

Este trabajo nos hizo mirar el paquete completo del modelo. Explicamos su arquitectura pública, manteniendo privadas las direcciones de servicios, conexiones de cuentas y configuraciones operativas. La parte útil de la historia es cómo encajan las piezas y qué información permite interpretar de forma consistente una observación nueva.

Es fácil señalar una red guardada o una predicción. Gran parte de nuestro esfuerzo estaba antes y después. Preparamos tablas amplias de variables con tiempo y OHLC, objetivos separados, utilidades de extracción y exportaciones de predicciones para trabajar de forma coherente en las distintas ramas.

En los scripts de predicción, una ruta recargaba un selector guardado antes de dar forma a la entrada LSTM; otra recuperaba la lista de variables de XGBoost. Ambas mantenían tiempo y un campo de referencia junto a dos predicciones. Una utilidad aparte extraía una parte acotada de un conjunto de datos. Estas herramientas pequeñas nos ayudaban a identificar qué usaba cada cálculo.

Usamos exportaciones CSV y Excel para revisar el trabajo fuera del código de entrenamiento. Algunas contenían predicciones con sus tiempos; otras comparaban diferencias máximas y mínimas observadas y predichas. Incluso la codificación requirió atención: había datos UTF-16 y UTF-8. Explicamos la estructura sin publicar filas privadas ni deducir tasas de éxito de las etiquetas.

Al recorrer el archivo encontramos un hilo común: conservar suficiente contexto para entender de dónde venía una respuesta. Con un modelo local incluye datos y transformaciones; con un servicio de lenguaje, fuentes, petición y respuesta. Las herramientas cambian, pero ambas exigen preservar el razonamiento alrededor de la salida.