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
Lity. Nuevo lenguaje de contrato inteligente
Actualmente hay más de 1.700 aplicaciones descentralizadas (DApps) publicadas en la red Ethereum y su número sigue aumentando. Y aunque todas las Dapps se basan en contratos inteligentes, la confiabilidad de los contratos inteligentes en sí es cuestionable: los ciberdelincuentes ya han ganado más de mil millones de dólares pirateándolos.
Apple publica nuevas reglas sobre aplicaciones de criptomonedas
Según TechCrunch, varios desarrolladores de Apple unieron fuerzas recientemente para crear la "Unión de Desarrolladores". El sindicato pidió a Apple que brindara a los usuarios de Apple Store la oportunidad de descargar pruebas gratuitas de sus aplicaciones. Esta es una de las primeras veces que los desarrolladores independientes de iOS intentan contraatacar las políticas de la Apple Store.
