Discusión sobre el artículo "Desarrollo de un robot en Python y MQL5 (Parte 2): Selección, creación y entrenamiento de modelos, simulador personalizado en Python" - página 2

Nuevo comentario
 

Aún así, los precios de las filas resultan ser las mejores fichas.

Antes era escéptico debido a su no estacionariedad. Pero después de algunas manipulaciones también empecé a extraer modelos decentes sobre estas características.

Así que de la ignorancia nace el conocimiento, y del conocimiento nace la ignorancia :)

 
Ivan Butko #:
¡Buena motivación cuando hay resultados!
Y, como me he dado cuenta, no es una semana por delante, ni un mes, sino un año normal de trabajo

Muchas gracias. Sí, me motiva mucho. Voy a seguir investigando) Es de noche otra vez, tengo una taza de café y las ideas de código conmigo)))))

 
Maxim Dmitrievsky #:

En conjunto, los precios en fila resultan ser las mejores fichas.

Antes era escéptico debido a su no estacionariedad. Pero después de algunas manipulaciones también empecé a extraer modelos decentes sobre estas características.

Así que de la ignorancia nace el conocimiento, y del conocimiento nace la ignorancia :)

Aquí es un tipo de tal intentado, mi suegra es un comerciante con experiencia de 15 + años, ella sigue diciendo que es necesario hacer fichas en los volúmenes))) https://www.mql5.com/es/code/50133

Индикатор Price / Volume
Индикатор Price / Volume
  • www.mql5.com
Одна из простых фич для машинного обучения
 
Yevgeniy Koshtenko #:

Este es el tipo de cosas que he intentado, mi suegra es un comerciante con 15 + años de experiencia, ella sigue diciendo que debemos hacer fichas en los volúmenes))) https://www.mql5.com/es/code/50133

Sí, es cierto que más a menudo se añade la volatilidad (por ejemplo, indicador std), pero no da mucho. O incrementos divididos por volatilidad.

 

Eugene, a partir de tus artículos empecé a estudiar ML en relación con el trading, muchas gracias por ello.

Me podrías explicar los siguientes puntos.

Después de que la función label_data procesa los datos, su volumen se reduce significativamente ( obtenemos un conjunto aleatorio de barras que satisfacen las condiciones de la función). A continuación, los datos pasan por varias funciones y los dividimos en muestras de entrenamiento y de prueba. El modelo se entrena con la muestra de entrenamiento. Después, las columnas ['labels'] se eliminan de la muestra de prueba e intentamos predecir sus valores para estimar el modelo. ¿No hay sustitución de conceptos en los datos de prueba? Al fin y al cabo, para las pruebas utilizamos datos que han pasado la función label_data (es decir, un conjunto de barras no secuenciales seleccionadas de antemano por una función que tiene en cuenta los datos futuros). Y luego en el probador existe el parámetro 10, que, según tengo entendido, debería ser el responsable de cuántas barras cerrar el trato, pero como tenemos un conjunto no secuencial de barras, no está claro qué obtenemos.

Surgen las siguientes preguntas: ¿En qué me equivoco? ¿Por qué no se utilizan todas las barras >= FORWARD para las pruebas? Y si no utilizamos todas las barras >= FORWARD, ¿cómo podemos elegir las barras necesarias para la predicción sin conocer el futuro?

Gracias.

 
Gran trabajo, muy interesante, práctico y con los pies en la tierra. Es difícil ver un artículo tan bueno con ejemplos reales y no sólo teoría sin resultados. Muchas gracias por su trabajo y compartir, voy a seguir y mirar hacia adelante esta serie.
 
Eric Ruvalcaba #:
Gran trabajo, muy interesante, práctico y con los pies en la tierra. Es difícil ver un artículo tan bueno con ejemplos reales y no sólo teoría sin resultados. Muchas gracias por vuestro trabajo y por compartirlo, seguiré y estaré atento a esta serie.

Muchas gracias. Sí, todavía hay un montón de implementaciones de ideas por delante, incluyendo la expansión de este con la traducción a ONNX)

 
¿Hay alguna razón en particular para utilizar RandomForestClassifier para la selección de características y XGBclassifier para la clasificación de modelos?
 

Fallos críticos:

  1. Problemas para evitar la fuga de datos:
    • La función augment_data() crea graves problemas de fuga de datos entre los conjuntos de entrenamiento y prueba
    • El aumento mezcla datos de distintos periodos de tiempo.
  2. Errores en la metodología de evaluación del rendimiento:
    • Las pruebas del modelo no tienen en cuenta las condiciones reales del mercado
    • El modelo se entrena con datos futuros y se prueba con datos históricos, lo cual es inaceptable.
  3. Problemas técnicos en el código:
    • La función generate_new_features() crea características pero no las devuelve (devuelve los datos originales)
    • La función test_model() utiliza X_test.iloc[i]['close'] , pero puede faltar 'close' después de transformar las características.
  4. Procesamiento de datos incoherente:
    • Los datos se etiquetan dos veces de formas distintas ( markup_data() y label_data() )
    • Los resultados de la agrupación ( cluster ) no se utilizan en el entrenamiento posterior
  5. Problemas metodológicos en la estrategia de negociación:
    • Salida estática después de 10 barras en lugar de estrategia adaptativa
    • No hay gestión del riesgo (salvo un simple stop-loss)
    • No se tienen en cuenta los costes de transacción (salvo un simple spread)
  6. Validación ineficaz:
    • No se valida el modelo sobre datos históricos teniendo en cuenta la estructura temporal (análisis walk-forward)
    • La validación cruzada se aplica a series temporales sin tener en cuenta la especificidad de las series temporales

Recomendaciones de mejora:

  1. Eliminar la fuga de datos: separar estrictamente los datos en el tiempo
  2. Aplicar una validación cruzada adecuada
  3. Realizar pruebas más realistas, teniendo en cuenta los desvíos y las comisiones.
  4. Finalizar la lógica de entrada y salida de posiciones.
  5. Utilizar métodos específicos para series temporales
12
Nuevo comentario