Recientemente, un conocido se me acercó (comercia con criptomonedas a nivel amateur) y me pidió que "escribiera un robot comercial". Es importante centrarse aquí en la terminología. En conversación, todo esto se llama robots, pero en la práctica, a menudo se necesita un asesor comercial.
Advisor analiza el mercado y da recomendaciones: dónde entrar, dónde detenerse, dónde es mejor no hacer nada.
El robot da el siguiente paso por usted y abre/cierra posiciones por sí solo.
Y es por eso que “consigamos un robot de inmediato” suele ser una mala idea. Hasta que se depure el algoritmo, el riesgo de perder dinero es máximo: un error en el análisis, un error en la lógica, procesamiento incorrecto de una vela/pedido, y el robot hará con calma exactamente lo que usted no haría manualmente.
Por tanto, una estrategia razonable es casi siempre la misma: primero un asesor (análisis + señales), luego automatización de la ejecución, y sólo si hay estadísticas y control de riesgos.
De qué trata el artículo: arquitectura de un asesor comercial
En este artículo, sin “señales millonarias” y sin promesas de rentabilidad, solo hay una teoría: de qué está hecho un asesor comercial, cómo es su arquitectura y por qué los límites de responsabilidad son importantes en él.
No profundizamos en los algoritmos de análisis; el propósito del artículo es diferente: mostrar qué componentes suele tener un asesor y cómo encajan entre sí.
Hoy en día, los servicios LLM ya preparados a menudo se eligen para el "cerebro" que interpreta los datos y formula conclusiones: ChatGPT, Gemini, Grok. Si lo desea, puede capacitarlos más o reemplazarlos con su propio modelo, pero para la arquitectura esto es secundario.
El matiz sigue siendo el mismo: la red neuronal no lee tus pensamientos. Necesita un indicador: claro, formalizado y repetible.
Pregunta es una instrucción de texto (y contexto) que usted pasa al modelo: qué tipo de datos hay frente a usted, qué se debe hacer exactamente y en qué formato devolver la respuesta.
Y también necesitamos datos con los que trabajaremos.
La pregunta principal aquí es: qué poner exactamente en el aviso (velas, indicadores, cartera de pedidos, transacciones, contexto de riesgo) y de qué forma.
Datos y API
Hablaremos del mensaje más adelante, pero ahora de los datos.
El nivel de entrada parece simple:
- Obtener datos sobre tarifas (cotizaciones).
- Ensamblarlos con el contexto de la solicitud.
- Pase esto al indicador de la red neuronal, a través de la misma API.
Casi todos los intercambios brindan acceso a cotizaciones mediante programación. Y sí, también vía API..
Hagamos una digresión por un momento y entendamos lo que incluso llamamos API, ya que la palabra ya ha aparecido varias veces y seguirá apareciendo constantemente.
API (Interfaz de programación de aplicaciones) es una interfaz para la interacción entre programas.
En la práctica, estas son las “reglas del juego”:
- qué solicitudes se pueden realizar (por ejemplo: obtener velas, obtener libro de pedidos);
- en qué formato enviar los datos (a menudo JSON);
- cómo se ve la respuesta (estructura de campos, errores, límites, autorización).
En pocas palabras: la API le permite utilizar las capacidades de un intercambio (o red neuronal) como un conjunto de funciones, sin entrar en la implementación.
Capa personalizada: cómo mostrar el resultado
Entonces, en esta etapa ya tenemos dos componentes básicos:
- datos (los tomamos del intercambio);
- analista (red neuronal a la que alimentamos datos y recibimos salida/señal).
Pero una aplicación que recibe datos y los analiza por sí misma es inútil hasta que una persona ve el resultado.
Entonces necesitamos un tercer componente: una interfaz.
La opción más simple y universal es la interfaz web: gráfico, señales más recientes, explicación de "por qué esto es así" y configuración de riesgo.
Como opción, notificaciones en mensajería instantánea (por ejemplo, Telegram): señal corta + enlace a detalles en la web.
Contexto sobre precio: noticias
Para la versión básica esto es suficiente, pero si quieres profundizar más, puedes añadir otra capa de contexto: noticias.
La idea es simple: recopilamos artículos de noticias relevantes y los agregamos al mensaje. Por lo general, no "materias primas", sino en forma de resúmenes breves (para no obstruir el contexto y no perderse en tokens).
Esta no es una parte obligatoria de la arquitectura, pero en algunos modos mejora significativamente la calidad del asesoramiento: el modelo comienza a tener en cuenta las razones del movimiento, y no solo la forma del gráfico.
Cómo unir todo
Bien, los módulos están claros. La pregunta ahora es práctica: cómo ensamblar esto en una sola aplicación.
En la práctica, casi siempre obtienes dos modos..
Análisis bajo demanda
El usuario presionó un botón (o presionó el punto final) → obtuvimos las últimas cotizaciones → recopilamos un mensaje → recibimos la respuesta del modelo → mostramos una señal.
- Ventajas: económico en términos de tokens/recursos, más fácil de depurar.
- Desventajas: se garantiza que se perderá algunos eventos entre solicitudes; también se perderán puntos de entrada.
Análisis periódicos según un cronograma
El usuario establece la frecuencia (por ejemplo, una vez cada 5 minutos/hora/día) → el propio sistema hace funcionar el transportador y envía el resultado.
- Ventajas: las señales llegan regularmente, puedes mantener el “pulso del mercado”, es más fácil recopilar estadísticas.
- Desventajas: más caro (tokens/infraestructura), necesita límites y protección contra la "ballesta" (límite de velocidad, rebanderas, deduplicación de señales), además se requiere monitoreo y registro; de lo contrario, no entenderá por qué a las 03:17 todo de repente se quedó en silencio.
En cualquiera de las modalidades, el conjunto de componentes básicos es el mismo:
- servidor web (interfaz y API para el usuario);
- módulo de datos de intercambio (cotizaciones, velas, si es necesario - cartera de pedidos/transacciones);
- Módulo LLM (colección del mensaje → llamar al modelo → analizar la respuesta);
- almacenamiento (configuración de usuario, historial de señales, caché de cotizaciones, resultados de análisis).
Y es necesario que haya un "pegamento" que lo una todo: una entidad a nivel de aplicación (llamémosla núcleo/servicio) que administre las dependencias, los ciclos de vida y los scripts (bajo demanda o programados).
Para el futuro, casi siempre es beneficioso adoptar un enfoque de complemento:
- complementos para fuentes de cotizaciones (agregamos un nuevo intercambio, no reescribimos el resto);
- Complementos para proveedores de LLM (ha aparecido un nuevo modelo / las tarifas han cambiado: cambiamos el adaptador, no la arquitectura).
Nota: Aquí se planea un diagrama de arquitectura (diagrama); no se incluye intencionalmente en esta versión del HTML.
Luego puede pasar a la implementación: ¿qué interfaces tienen los módulos, qué estructuras de datos y dónde está el límite entre un “asesor” y un “robot comercial”?
Basado en materiales de itprolab.dev
Leer también
Robot comercial de bricolaje: ¿qué hay en las cajas?
En las dos primeras partes recopilamos el esqueleto del asesor: cotizaciones, aviso, modelo, almacenamiento, núcleo. Ahora la pregunta principal es: ¿de qué forma se puede recolectar?
EthBackNode: ¿por qué su aplicación necesita un “espaciador” entre ella y el nodo Ethereum?
Si alguna vez ha intentado escribir una billetera criptográfica, una pasarela de pago o simplemente un "backend que pueda enviar y recibir ETH", rápidamente queda claro algo desagradable: el nodo Ethereum no es su backend.
