EAの汎化性能を上げるには

この投稿文は次の言語で読めます: 日本語

投稿から随分日が空いてしまいました。

本業に追われ続け、EA開発は隙間時間で細々と対応してきましたが、ようやく実装が終わり検証工程に入りました。

前回EAの反省を踏まえ、様々な機能の改修を繰り返し、ようやく検証結果をまとめる段階になりましたが、

運用成績に直結する運用パラメータ選出のための手順(パラメータの最適化~最終候補確定)について従来の進め方に問題を感じていましたので、再検討してみました。

何が問題?

汎化性能が低い

ナンピン系EAのパラメータ最適化を行う際、厄介な問題があり、単純にMT5の遺伝的最適化によって優良なパラメータセットを得たとしても問題が残ります。

ナンピン系EAはある程度の含み損を覚悟し、それを資金量の大きさで耐えながら利確を行い更に残高を増やしていくことになるのですが、

10年など長期でバックテストをした場合、前半で積み上がった確定利益があったがゆえに、後半の含み損に耐えられ、トータルでは良好な成績に見えてしまうケースが散見されます。

つまり、2009/01/01~2020/12/31で最適化したパラメータを、2020/01/01~2020/12/31 の期間で運用した場合、 2020/01/01時点の資金量の違いがあるため

前者は含み損に耐え良好な結果に見える(=訓練時の性能は高い)一方で、後者はロスカットに到達してしまう(=汎化性能が低い)というケースがあります。

この問題は、以前から認識していたものの、バックテストの残高推移グラフから目視確認で汎化性能が低いケースを除外する程度だったので、

その対応品質(量、質)が不十分だったと考えられます。

スポンサーリンク

どうすれば改善できる?

蓄積した資金量による挙動の違いが問題になるため、同一パラメータを異なる開始日からスタートして、それらの結果も含めて総合的に判断することで、従来よりは汎化性能を上げられるのでは、と考えました。

イメージとしてはウォークフォワードテストのようなものです。(厳密な定義は異なると思いますが)

従来

  • 2009/01/01~2020/12/31でパラメータ最適化を行い、上位数十件の良好なパラメータを選出する
    • 4通貨ペア x 売買(2ケース) x  6期間足 に対して、各最適化(1最適化あたり約15,000パターン(遺伝的最適化)) = 720,000パターンのテストを実施し、スコアはカスタム指標生成、上位パラメータを絞り込む

追加手順

  • 選出した各パラメータに対し、運用期間を変更したパターン(12年間、11年間、10年間、・・・・1年間)のバックテストを実行する
    • 4通貨ペア x 売買(2ケース) x  6期間足 の上位パラメータ各30件選出 x 評価期間12パターン = 17,280パターン

従来、この17,280パターンを目視確認することが難しかったために主観に頼っていたのですが、これの自動化を行い客観的に評価をしてみます。

レポートフロー改修

以前、バックテスト最適化~単体バックテスト自動実行~自動レポート のようなフローを構築していましたので、

これの一部を改修して、同一の最適化パスに対し期間のみ変更したバックテストを12回行うように変更しました。

スポンサーリンク

分析レポート作成

データフロー概略

最適化結果、pass別パラメータ、個別バックテスト結果は出力結果ファイルを AWS S3 へ連携し、 Athenaを介して標準SQLによる照会ができるようにしつつ、

個別バックテストレポートイメージやMT5にインポート可能なパラメータファイルはConfluenceに自動ページ作成、ファイルアップロードし使用性を担保しています。

→従来、Confluenceに自動ページ作成する件数は手順の問題もありせいぜい数百件程度だったのですが、今回は17,000件ということで数十倍のオーダーになりました。

これだけページ数が増えるとページツリーの読み込みだけでもかなり時間がかかる上に、全文検索では意図したページを特定しきれない問題が発生・・・

ページを探す手順も再検討が必要になりました。

ビジュアル化

Tableau は異なるデータセットを単一ダッシュボードに読み込んだり、関連付けて使用することができるため、

S3~Athenaの情報と Confluenceページを関連付けて閲覧できるようにしました。

  • 箱ヒゲ図(左上)は値の分布と中央値確認用。 各最適化結果の上澄部分を同じ件数抜き出しても、
    同一通貨ペアでも買い中心エントリと売り中心エントリで成績に大きく差があったりしますので、全体的な傾向を掴むために表示しています。
  • ヒートマップ(左下)は、同じ最適化パスを行でまとめ、テスト期間の違いを列方向に並べています。
    右端の総計は、期間別12パターンをまとめたものですが、その数値自体の意味合いを問うわけではなく、全体的なスコアの良し悪しをみるためのソート順程度の意味合いです。
    ヒートマップ内の1セルが1バックテストの扱いになりますので、このセルをクリックすると画面右側のConfluenceページに該当バックテスト結果レポートが表示されます。

KPI切り替え

基本、レポート内の全ての指標を切替可能ではありますが、設定の手間もあるので、基本的なもののみ選択出来るようにしました。

KPI

フィルタ

特定の通貨ペア、売買、期間足などの軸で絞り込んで見ると、情報量を絞込み、その範囲の比較検討がしやすくなります。

backtest_report_filter-2-1

 

やはりドル高方向になる売買区分が成績が安定しているようですね。

内訳~バックテストレポート詳細

箱ヒゲ図をクリックすると、バックテスト結果のヒートマップがその範囲に絞り込まれます。

一見、中央値が高めに出ているグループでも,年単位で見ると負けているケースが散見されるところが難しいところですし、

また一見合計値だけ見れば良い結果に見えても、残高が線形にならず、急騰・急落するようなケースは実際に継続的に運用するのは躊躇してしまうのでは、と考えられますので、

残高推移グラフを見ながら評価した方が安全です。

backtest_report_detail

 

評価

最適化結果の上澄み部分だけを抽出しても、12年での残高の伸びが極端に高いものはリスクが高いものも混在し、開始年によってはマイナスになりやすい傾向があることが確認できました。

該当パラメータを除外すれば自然と安定性の高いものが残ることになるので、一定の効果は見込めたのではないかと思います。

最後は実環境での検証も必要のため、いくつか候補を選定し、検証に進みたいと思います。

まとめ

準備が整ったら、バージョンアップ後のEA配布や運用実績の公開も再開しますので、ご興味あれば是非お声掛けください。

また、前回記事を公開した際にテスト手法をサービスとして提供してほしいというお声も頂いており、大変ありがたいご意見と受け止めておりますが
AWS, Atlassian製品, Tableauといった複数サービス横断の仕組みとなるため、パッケージ化は様々な検討が必要になりそうです。

ただ、個別に対応させて頂ける部分はありますので、ご興味をお持ち頂けたら、お問い合わせフォームからご相談頂けますと幸いです。

スポンサーリンク

Twitterでフォローしよう

おすすめの記事