Robot comercial de bricolaje: más detalles, más matices

Qué datos tomar al inicio

Al principio, tiene tres clases principales de datos de mercado que se pueden recibir del intercambio a través de la API. La más comprensible y común son las velas OHLCV: apertura/alto/bajo/cierre más volumen por intervalo. Esta es una representación "comprimida" del precio, que es conveniente almacenar, almacenar en caché y transferir al modelo como una pieza estable de contexto (por ejemplo, las últimas N velas del período de tiempo seleccionado¹).

Si necesita ver lo que sucede dentro de una vela, conecte una cinta de operaciones (trades/cinta): el flujo de ejecuciones reales: precio, cantidad, tiempo (a veces lateral). Esta capa añade detalles a la actividad y los impulsos y normalmente se utiliza como una fuente más granulada que las velas japonesas.

La tercera opción es libro de pedidos (libro de pedidos): niveles de oferta/demanda y volúmenes en cada nivel. Se trata de datos sobre microestructura y liquidez: no sobre “lo que pasó”, sino sobre “lo que está en juego ahora”. Generalmente se toma como una capa separada del contexto cuando es necesario tener en cuenta la profundidad del mercado, el desequilibrio entre oferta y demanda y la reacción a los niveles.

Por ahora, centrémonos en la opción más sencilla: las velas OHLCV. En su implementación, puede agregar tanto transacciones como libro de órdenes, pero el propósito de este artículo es informativo y educativo: crear un marco claro y no atascarse en detalles.

Formato e historial de datos unificados

Tan pronto como empiezas a recibir cotizaciones de más de un lugar, surge una realidad desagradable: diferentes fuentes proporcionan los mismos datos en diferentes formatos. En algún lugar, una vela es una matriz de números, en algún lugar un objeto con campos, en algún lugar el tiempo es en milisegundos, en algún lugar en segundos, y los nombres y el orden de los campos pueden diferir incluso para API "similares"...

Si no introduce un formato unificado de su parte, el sistema rápidamente se convierte en un conjunto de muletas: cada nueva fuente trae consigo analizadores, excepciones y "casos especiales" separados. Por lo tanto, el módulo para obtener cotizaciones casi siempre requiere un formato interno común, que es mínimamente suficiente para un análisis posterior. Para nuestro nivel actual, esto suele ser: instrumento, marco de tiempo¹, marca de tiempo², Abrir/Alto/Bajo/Cerrar y Volumen.

También deberíamos hablar de datos históricos. “El estado actual del mercado” es bueno, pero sin historia no será posible ampliar el análisis, probar hipótesis o incluso explicar correctamente al usuario por qué la señal tiene el aspecto que tiene. Por lo tanto, incluso en una implementación simple, tiene sentido almacenar el historial de velas (o poder cargarlo rápidamente) y registrar qué datos formaron la base de una señal particular.

Límites de tarifas: por qué es importante

Casi todos los intercambios tienen restricciones en la frecuencia de las solicitudes: límites de tasas. La razón es simple: si permites que todos los clientes "cambien" las comillas sin cesar, la API fallará incluso sin DDoS.

En el contexto de un asesor, esto es doblemente importante. Las solicitudes no se ejecutan continuamente, sino según un cronómetro, y si elige la frecuencia incorrectamente o la multiplica por el número de instrumentos, rápidamente alcanzará el límite. El resultado suele ser el mismo: errores 429/ban por clave, agujeros en los datos y “silencio” del sistema precisamente cuando el mercado se mueve más.

El enfoque de trabajo aquí es pragmático: calcular el presupuesto de la solicitud por adelantado (frecuencia × herramientas × tipos de datos), almacenar en caché los resultados, no solicitar lo mismo dos veces y manejar los límites correctamente (retroceder/repetir después de una pausa en lugar de enviar solicitudes de spam).

Redes neuronales y de aviso: misma API, reglas diferentes

Hemos resuelto la adquisición de datos; ahora podemos pasar al siguiente nivel: indicaciones y trabajo con redes neuronales.

A primera vista, esto es muy similar a solicitar cotizaciones: nuevamente la API, nuevamente las restricciones de frecuencia, nuevamente debes pensar en los reintentos, los tiempos de espera y el caché. Sólo que en lugar de “dame una vela” tienes una petición como “aquí están los datos, aquí está el contexto, devuelve la señal y la explicación”.

Entonces comienzan las diferencias.. Para un intercambio, la respuesta es la estructura de datos; para un modelo, es el resultado de la interpretación. Por lo tanto, el aviso se convierte en un contrato, y no sólo en un “texto”, y debe tratarse de la misma manera que un formato de datos: versionado, verificado, limitado y registrado.

Un momento que simplifica enormemente la vida durante la integración: en un mensaje puedes prefijar la estructura de la respuesta. Por ejemplo, pídale al modelo que devuelva el resultado estrictamente en JSON, con campos como signal, confidence y reasons. Esto no es "mágico", pero al menos disciplina el formato y, en el lado de la aplicación, permite analizar y validar respuestas automáticamente en lugar de analizar texto libre.

MCP (Model Context Protocol) merece una mención especial: es un enfoque/protocolo que ayuda a estandarizar cómo los modelos reciben contexto y cómo se conectan las fuentes de datos y herramientas externas. Incluso si actualmente utiliza llamadas directas a una API específica, tener en mente una capa similar a MCP es útil: disciplina la arquitectura y facilita la extensibilidad.

Y sí, en el futuro, el “analista” no tiene por qué ser un servicio externo. Si aparecen recursos y motivación, este módulo se puede reemplazar con su propio modelo (o uno de código abierto previamente entrenado) sin reescribir el resto del sistema, siempre que las interfaces estén inicialmente separadas correctamente.

Almacenamiento: más fácil de lo que parece

En esta etapa, ya tenemos al menos dos "conjuntos" de datos: velas de mercado y resultados de análisis. Y si mira un poco hacia adelante, se agregará un historial de noticias (y su resumen), además de guardar las indicaciones/respuestas del modelo para depurar y volver a analizar. En otras palabras, hay bastantes datos y aparecen en diferentes lugares del proceso.

Por lo tanto, tiene sentido pensar de antemano en el almacenamiento unificado. La especificidad de dichos datos a menudo hace posible no arrastrar un esquema SQL completo: en muchos casos, una base de datos integrada y un enfoque simple de clave-valor son suficientes.

El almacenamiento KV (clave-valor) es un modelo en el que los datos se almacenan como pares “clave → valor”: utilizando la clave puede recuperar rápidamente el objeto deseado (por ejemplo, velas para un instrumento y período de tiempo¹ para un período, o el resultado de un análisis para una solicitud específica)..

Interfaz: el mínimo sin el cual el asesor es inútil

Y finalmente, la interfaz. No vamos a entrar en UI/UX en este momento, pero déjame recordarte la idea básica de la primera parte: como mínimo, necesitas una interfaz web y, como buen complemento, notificaciones en Telegram.

A nivel práctico, el usuario sólo necesita unas pocas cosas. Primero, vea las señales y alertas actuales (y comprenda rápidamente lo que “está sucediendo ahora”). En segundo lugar, podrá solicitar análisis a pedido: obtenga los datos y la señal más recientes con un solo clic. Y en tercer lugar, configure el sistema: seleccione herramientas y fuentes de datos, administre claves API y, lo que es importante, edite indicaciones y parámetros de análisis sin entrar en el código.

Núcleo: el “anillo” que lo conecta todo

Tolkien tenía “un anillo para gobernarlos a todos... y unirlos en la oscuridad”. La arquitectura del asesor también tiene este anillo, solo que sin patetismo: el núcleo del sistema, que mantiene unidos todos los módulos.

El kernel no es responsable del análisis como tal, sino del ciclo de vida: inicio/parada de la aplicación, inicialización de dependencias, programador de tareas, enrutamiento de solicitudes (bajo demanda y según programación) y apagado correcto. Es aquí donde se decide qué se lanza y cuándo, dónde se escriben los datos y cómo los componentes se comunican entre sí sin enredarse.

Si desea agregar nuevas fuentes de citas, cambiar el proveedor de LLM, conectar noticias y no reescribir todo cada vez, el núcleo debe ser simple pero estricto: módulos - por interfaces, dependencias - explícitamente, configuración - centralizada y ciclo de vida - predecible.

En este punto puedes detenerte y decir honestamente: el “esqueleto” del asesor ya es visible. Llegan los datos, se recopila el mensaje, el modelo responde, el resultado se guarda y se muestra al usuario, y todo esto depende del kernel, que gestiona el ciclo de vida. En el próximo artículo bajaré un nivel: veremos los detalles técnicos de la implementación: cómo se ve una interfaz unificada de fuentes de cotizaciones, cómo organizar un caché y bandejas, dónde almacenar el historial, cómo validar las respuestas del modelo (incluido el formato JSON) y qué hacer para que el sistema no se rompa debido a límites, tiempo y errores "raros"...

Notas al pie

El período de tiempo es la duración de una vela (intervalo de agregación de datos): por ejemplo, 1 m, 5 m, 1 h, 1 d. Determina exactamente cómo se “comprime” el flujo de precios en OHLCV. La marca de tiempo es la marca de tiempo (generalmente en UTC) con la que está asociada la vela/comercio. Un error clásico: mezclar segundos y milisegundos (o hora local y UTC), después de lo cual los datos “se desplazan” y el análisis falla.