Discussione sull’articolo "Sviluppo di un robot in Python e MQL5 (parte 2): Selezione, creazione e addestramento del modello, tester personalizzato in Python" - pagina 2

Nuovo commento
 

I prezzi di fila risultano essere i migliori.

Prima ero scettico a causa della loro non stazionarietà. Ma dopo alcune manipolazioni ho iniziato a estrarre modelli decenti su queste caratteristiche.

Quindi dall'ignoranza nasce la conoscenza e dalla conoscenza l'ignoranza :)

 
Ivan Butko #:
Una buona motivazione quando ci sono dei risultati!
E, come ho capito, non si tratta di una settimana o di un mese, ma di un normale anno di lavoro.

Grazie mille! Sì, mi motiva molto! Continuerò a fare ricerche) È di nuovo notte, ho una tazza di caffè e idee di codice con me)))))

 
Maxim Dmitrievsky #:

Complessivamente, i prezzi di fila si rivelano le migliori patatine.

Prima ero scettico a causa della loro non stazionarietà. Ma dopo alcune manipolazioni ho iniziato a estrarre modelli decenti su queste caratteristiche.

Quindi dall'ignoranza nasce la conoscenza e dalla conoscenza nasce l'ignoranza :)

Ecco un tipo di prova di questo tipo, mia suocera è un trader con esperienza di oltre 15 anni, continua a dire che è necessario fare chip sui volumi))) https://www.mql5.com/it/code/50133

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

Questo è il genere di cose che ho provato, mia suocera è una trader con oltre 15 anni di esperienza, continua a dire che dovremmo fare i chip sui volumi))) https://www.mql5.com/it/code/50133

Sì, è vero che più spesso si aggiunge la volatilità (es. indicatore std), ma non dà molto. Oppure gli incrementi divisi per la volatilità.

 

Eugene, grazie ai tuoi articoli ho iniziato a studiare il ML in relazione al trading, ti ringrazio molto per questo.

Potresti spiegare i seguenti punti.

Dopo che la funzione label_data elabora i dati, il loro volume viene notevolmente ridotto ( otteniamo un insieme casuale di barre che soddisfano le condizioni della funzione). Quindi i dati passano attraverso diverse funzioni e vengono suddivisi in campioni di addestramento e di prova. Il modello viene addestrato sul campione di addestramento. Successivamente, le colonne ['etichette'] vengono rimosse dal campione di prova e cerchiamo di prevedere i loro valori per stimare il modello. Non ci sono sostituzioni di concetti nei dati di test? Dopotutto, per i test utilizziamo dati che hanno superato la funzione label_data (cioè un insieme di barre non sequenziali selezionate in anticipo da una funzione che tiene conto dei dati futuri). E poi nel tester c'è il parametro 10, che, a quanto ho capito, dovrebbe essere responsabile di quante barre chiudere l'operazione, ma poiché abbiamo un insieme di barre non sequenziali, non è chiaro cosa otteniamo.

Sorgono le seguenti domande: Dove sbaglio? Perché non vengono utilizzate tutte le barre >= FORWARD per i test? E se non utilizziamo tutte le barre >= AVANTI, come possiamo scegliere le barre necessarie per la previsione senza conoscere il futuro?

Grazie.

 
Ottimo lavoro, molto interessante, pratico e concreto. È difficile vedere un articolo così bello con esempi reali e non solo teoria senza risultati. Grazie mille per il tuo lavoro e la tua condivisione, seguirò e aspetterò con ansia questa serie.
 
Eric Ruvalcaba #:
Ottimo lavoro, molto interessante, pratico e concreto. È difficile vedere un articolo così bello con esempi reali e non solo teoria senza risultati. Grazie mille per il tuo lavoro e la tua condivisione, seguirò e aspetterò con ansia questa serie.

Grazie mille! Sì, ci sono ancora molte implementazioni di idee da fare, compresa l'espansione di questa con la traduzione in ONNX).

 
C'è qualche ragione particolare per utilizzare RandomForestClassifier per la selezione delle caratteristiche e XGBclassifier per la classificazione del modello?
 

Difetti critici:

  1. Problemi di prevenzione della perdita di dati:
    • La funzione augment_data() crea seri problemi di perdita di dati tra gli insiemi di allenamento e di test.
    • L'incremento mescola dati provenienti da periodi di tempo diversi
  2. Errori nella metodologia di valutazione delle prestazioni:
    • I test del modello non tengono conto delle reali condizioni di mercato.
    • Il modello viene addestrato su dati futuri e testato su dati storici, il che è inaccettabile.
  3. Problemi tecnici nel codice:
    • La funzione generate_new_features() crea le caratteristiche ma non le restituisce (restituisce i dati originali).
    • La funzione test_model() utilizza X_test.iloc[i]['close'], ma 'close' potrebbe essere mancante dopo la trasformazione delle caratteristiche.
  4. Elaborazione dei dati non coerente:
    • I dati sono etichettati due volte in modi diversi ( markup_data() e label_data() )
    • I risultati del clustering ( cluster ) non vengono utilizzati per l'addestramento successivo.
  5. Problemi metodologici nella strategia di trading:
    • Uscita statica dopo 10 barre invece di una strategia adattiva
    • Nessuna gestione del rischio (ad eccezione di un semplice stop-loss)
    • Nessuna considerazione dei costi di transazione (a parte il semplice spread)
  6. Validazione inefficace:
    • Nessuna convalida del modello sui dati storici considerando la struttura temporale (analisi walk-forward).
    • La convalida incrociata viene applicata alle serie temporali senza tenere conto della specificità delle serie temporali.

Raccomandazioni per il miglioramento:

  1. Eliminare le perdite di dati - segregare rigorosamente i dati nel tempo
  2. Implementare una corretta validazione walk-forward
  3. Implementare test più realistici, che tengano conto di slittamenti e commissioni.
  4. Finalizzare la logica di entrata/uscita dalle posizioni
  5. Utilizzare metodi specifici per le serie temporali
12
Nuovo commento