記事「PythonとMQL5でロボットを開発する（第2回）：モデルの選択、作成、訓練、Pythonカスタムテスター」についてのディスカッション - ページ 2

[削除済み]

それでも列の価格は最高のチップスであることが判明した。

以前は、その非定常性に懐疑的だった。しかし、いくつかの操作の後、これらの特徴からまともなモデルを抽出することもできるようになった。

つまり、無知から知識が生まれ、知識から無知が生まれるということだ :)

[Yevgeniy Koshtenko]

Ivan Butko #:
結果が出るといいモチベーションになる！

そして、気づいたことだが、それは1週間先でもなく、1カ月先でもなく、普通に1年分の仕事だ

ありがとうございます！そうですね、モチベーションが上がります！また夜になってしまったので、コーヒーとコードのアイデアを持っています。）

[Yevgeniy Koshtenko]

Maxim Dmitrievsky #:

全体として、列の価格は最高のチップスであることが判明した。

以前は、その非定常性に懐疑的だった。しかし、いくつかの操作の後、これらの特徴からまともなモデルを抽出することもできるようになった。

つまり、無知から知識が生まれ、知識から無知が生まれるということだ :)

私の義母は15年以上の経験を持つトレーダーですが、出来高でチップを作る必要があると言い続けています))https://www.mql5.com/ja/code/50133

[削除済み]

Yevgeniy Koshtenko #:

義母は15年以上の経験を持つトレーダーで、出来高でチップを作るべきだと言い続けている。))https://www.mql5.com/ja/code/50133

たしかに、ボラティリティが追加されることが多い（例えばstdインディケータ）。または、ボラティリティで割った増分。

[Milksad]

ユージン、あなたの記事を読んで、MLについて勉強し始めました。

以下の点について教えてください。

label_data 関数がデータを処理した後、その量は大幅に減少します（関数の条件を満たすバーのランダムな セットを取得します）。その後、データはいくつかの関数を経て、訓練サンプルとテストサンプルに分けられます。モデルは訓練サンプルで学習される。その後、テストサンプルから['labels']列を取り除き、その値を予測してモデルを推定します。テストデータには概念の置き換えはないのでしょうか？結局のところ、テストにはlabel_data 関数を通過したデータ（つまり、将来のデータを考慮する関数によって事前に選択された非連続バーのセット）を使用します。そして、テスターにはパラメータ10があり、私が理解するところでは、何本のバーで取引を終了させるかを担当するはずですが、非連続的なバーのセットを持っているため、何が得られるかは明らかではありません。

次のような疑問が生じます：どこが間違っているのか？なぜすべてのバー >= FORWARD をテストに使用しないのですか?また、すべてのバー >= FORWARD を使用しない場合、将来を知らずに予測に必要なバーをどのように選択できますか?

ありがとうございます。

[Eric Ruvalcaba]

とても興味深く、実践的で地に足の着いた素晴らしい仕事だ。結果が伴わない理論だけでなく、これほど優れた実例が掲載された記事はなかなかお目にかかれない。あなたの仕事と分かち合いに感謝します。

[Yevgeniy Koshtenko]

Eric Ruvalcaba #:
とても興味深く、実践的で地に足の着いた素晴らしい仕事だ。結果が伴わない理論だけでなく、これほど優れた実例が掲載された記事はなかなかお目にかかれない。あなたの仕事と分かち合いに心から感謝します。

本当にありがとう！そうですね、ONNXへの翻訳を含む今回のアイデアの拡張を含め、この先もまだ多くのアイデアが実装されることでしょう)

[Damjan Cvetanovski]

RandomForestClassifierを特徴選択に、XGBclassifierをモデル分類に使用する特別な理由はありますか？

[Andy An]

重大な欠陥

1. データ漏洩防止の問題：
   • augment_data()関数は、トレーニングセットとテストセットの間で深刻なデータ漏洩問題を引き起こす。
   • 異なる期間のデータが混在してしまう。
2. 性能評価方法の誤り：
   • モデルのテストは実際の市場状況を考慮していない
   • モデルは将来のデータで学習され、過去のデータでテストされる。
3. コードの技術的問題：
   • generate_new_features()関数は特徴を作成するが、それを返さない（元のデータを返す）。
   • test_model()はX_test.iloc[i]['close']を使用するが、特徴量を変換した後に'close'が欠落している可能性がある。
4. データ処理に一貫性がない：
   • データが異なる方法で2回ラベル付けされる ( markup_data() と label_data() )
   • クラスタリングの結果( cluster )が更なるトレーニングで使用されない。
5. 取引戦略における方法論的問題：
   • 適応的戦略の代わりに、10小節後に静的に終了する。
   • リスク管理なし（単純なストップロスを除く）
   • 取引コストを考慮しない（単純なスプレッド以外）
6. 非効率的な検証：
   • 時間構造（ウォークフォワード分析）を考慮したヒストリカルデ ータでのモデルの検証なし。
   • クロス検証は、時系列の特異性を考慮することなく、時系列に適用される。

改善のための提言

1. データ漏れをなくす - 時系列データを厳密に分離する
2. 適切なウォークフォワード検証の実施
3. スリッページと手数料を考慮した、より現実的なテストの実施
4. ポジションのエントリー／エグジットのロジックを確定する。
5. 時系列に特化した手法を使用する