Discussão do artigo "Desenvolvimento de robô em Python e MQL5 (Parte 2): Escolha do modelo, criação e treinamento, testador customizado Python" - página 2

Novo comentário
 

Ainda assim, os preços em linha acabam sendo as melhores fichas.

Eu costumava ser cético por causa de sua não estacionariedade. Mas depois de algumas manipulações, também comecei a extrair modelos decentes com base nesses recursos.

Portanto, da ignorância vem o conhecimento, e do conhecimento vem a ignorância :)

 
Ivan Butko #:
É uma boa motivação quando há resultados!
E, como percebi, não se trata de uma semana, nem de um mês, mas de um ano normal de trabalho

Muito obrigado! Sim, isso me motiva muito! Vou continuar pesquisando) É noite novamente, tomo uma xícara de café e tenho ideias de código comigo)))))

 
Maxim Dmitrievsky #:

No geral, os preços em linha acabam sendo as melhores fichas.

Eu costumava ser cético por causa de sua não estacionariedade. Mas, depois de algumas manipulações, também comecei a extrair modelos decentes sobre esses recursos.

Portanto, da ignorância vem o conhecimento, e do conhecimento vem a ignorância :)

Aqui está um tipo de tentativa: minha sogra é uma trader com mais de 15 anos de experiência, e ela sempre diz que é necessário fazer fichas sobre volumes))) https://www.mql5.com/pt/code/50133

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

Foi esse tipo de coisa que tentei fazer, minha sogra é uma trader com mais de 15 anos de experiência, ela vive dizendo que deveríamos fazer fichas sobre volumes))) https://www.mql5.com/pt/code/50133

Sim, é verdade que a volatilidade é adicionada com mais frequência (por exemplo, indicador std), mas não dá muito resultado. Ou incrementos divididos pela volatilidade.

 

Eugene, a partir de seus artigos, comecei a estudar o ML em relação à negociação, muito obrigado por isso.

Você poderia explicar os seguintes pontos.

Depois que a função label_data processa os dados, seu volume é significativamente reduzido (obtemos um conjunto aleatório de barras que satisfazem as condições da função). Em seguida, os dados passam por várias funções e os dividimos em amostras de treinamento e teste. O modelo é treinado na amostra de treinamento. Depois disso, as colunas ['labels'] são removidas da amostra de teste e tentamos prever seus valores para estimar o modelo. Não há substituição de conceitos nos dados de teste? Afinal, para os testes, usamos dados que passaram pela função label_data (ou seja, um conjunto de barras não sequenciais selecionadas antecipadamente por uma função que leva em conta dados futuros). E então, no testador, há o parâmetro 10, que, pelo que entendi, deve ser responsável por quantas barras devem ser fechadas, mas como temos um conjunto não sequencial de barras, não está claro o que obtemos.

Surgem as seguintes perguntas: Onde estou errando? Por que nem todas as barras >= FORWARD são usadas para os testes? E se não usarmos todas as barras >= FORWARD, como podemos escolher as barras necessárias para a previsão sem conhecer o futuro?

Obrigado.

 
Ótimo trabalho, muito interessante, prático e direto ao ponto. É difícil ver um artigo tão bom com exemplos reais e não apenas teoria sem resultados. Muito obrigado por seu trabalho e compartilhamento, estarei acompanhando e aguardando ansiosamente essa série.
 
Eric Ruvalcaba #:
Ótimo trabalho, muito interessante, prático e direto ao ponto. É difícil ver um artigo tão bom com exemplos reais e não apenas teoria sem resultados. Muito obrigado por seu trabalho e compartilhamento, estarei acompanhando e aguardando ansiosamente essa série.

Muito obrigado! Sim, ainda há muitas implementações de ideias pela frente, incluindo a expansão desta com a tradução para ONNX)

 
Há algum motivo específico para usar o RandomForestClassifier para a seleção de recursos e o XGBclassifier para a classificação do modelo?
 

Falhas críticas:

  1. Problemas para evitar o vazamento de dados:
    • A função augment_data() cria sérios problemas de vazamento de dados entre os conjuntos de treinamento e teste
    • O aumento mistura dados de diferentes períodos de tempo
  2. Erros na metodologia de avaliação de desempenho:
    • O teste do modelo não leva em conta as condições reais do mercado
    • O modelo é treinado em dados futuros e testado em dados históricos, o que é inaceitável
  3. Problemas técnicos no código:
    • A função generate_new_features() cria recursos, mas não os retorna (retorna os dados originais)
    • A função test_model() usa X_test.iloc[i]['close'] , mas 'close' pode estar faltando após a transformação dos recursos
  4. Processamento de dados inconsistente:
    • Os dados são rotulados duas vezes de maneiras diferentes ( markup_data() e label_data() )
    • Os resultados de agrupamento ( cluster ) não são usados em treinamento posterior
  5. Problemas metodológicos na estratégia de negociação:
    • Saída estática após 10 barras em vez de estratégia adaptativa
    • Nenhum gerenciamento de risco (exceto por um simples stop-loss)
    • Nenhuma consideração dos custos de transação (exceto um simples spread)
  6. Validação ineficaz:
    • Não há validação do modelo em dados históricos considerando a estrutura temporal (análise walk-forward)
    • A validação cruzada é aplicada a séries temporais sem levar em conta a especificidade da série temporal

Recomendações para aprimoramento:

  1. Eliminar o vazamento de dados - segregar estritamente os dados ao longo do tempo
  2. Implementar a validação adequada de walk-forward
  3. Implementar testes mais realistas, levando em conta a derrapagem e as comissões
  4. Finalizar a lógica de entrada/saída de posições
  5. Usar métodos específicos de séries temporais
12
Novo comentário