記事"強化学習におけるランダム決定フォレスト"についてのディスカッション

 

新しい記事 強化学習におけるランダム決定フォレスト はパブリッシュされました:

バギングを使用するランダムフォレスト(RF)は最も強力な機械学習方法の1つですが、グラジエントブースティングには若干劣ります。本稿では、市場との相互作用から得られた経験に基づいて意思決定を行う自己学習型取引システムの開発を試みます。

決定木が基盤として使われている場合、ランダムフォレストはバギングの特別なケースであると言えます。同時に、従来の決定木の構築方法とは異なり、プルーニングは使用されません。この方法は、できるだけ速く大きなデータサンプルから構成を作成することを目的としています。それぞれの木は特定の方法で構築されています。木ノードを構築するための特徴(属性)は、特徴の総数から選択されるのではなく、そのランダムな部分集合から選択されます。 回帰モデルを構築する場合、特徴の数はn/3です。分類の場合はnです。これらはすべて実証的な勧告であり、無相関化と呼ばれています。特徴の異なるセットは異なるツリーに分類され、ツリーは異なるサンプルで訓練されます。


図1 ランダムフォレスト操作のスキーム

作者: Maxim Dmitrievsky

 
   if(ts<0.4 && CheckMoneyForTrade(_Symbol,lots,ORDER_TYPE_BUY))
     {
      if(OrderSend(Symbol(),OP_BUY,lots,SymbolInfoDouble(_Symbol,SYMBOL_ASK),0,0,0,NULL,OrderMagic,Green))
        {
         updatePolicy(ts);
        };
     }

次のように置き換えることができます。

if((ts<0.4) && (OrderSend(Symbol(),OP_BUY,lots,SymbolInfoDouble(_Symbol,SYMBOL_ASK),0,0,0,NULL,OrderMagic,INT_MIN) > 0))
  updatePolicy(ts);


ところで、あなたのif(OrderSend)チェックは常に機能します。なぜなら、OrderSendはエラー時にゼロを返さないからです。

 
エージェントはオプティマイザで順次トレーニングされる。つまり、ファイルに記録された前回のトレーニング結果が、次の実行に使用される。これを行うには、単純にすべてのテストエージェントとクラウドのスイッチを切り、1つのコアだけを残します。

残念ながら、これはまさに我々がやらなければならないことだ。エージェントにデータを "渡す "面白い方法があるので、この記事を チェックしてほしい。

Управляемая оптимизация: метод отжига
Управляемая оптимизация: метод отжига
  • 2018.02.27
  • Aleksey Zinovik
  • www.mql5.com
В состав тестера стратегий торговой платформы 5 входят только два варианта оптимизации: полный перебор параметров и генетический алгоритм. В этой статье я предлагаю новый вариант оптимизации торговых стратегий — метод отжига. Здесь приводится алгоритм метода отжига, рассмотрена его реализация и способ подключения к любому советнику. Далее мы...
 
fxsaber:

残念ながら、これはまさに我々がやらなければならないことだ。エイジェントにデータを "渡す "面白い方法があるので、この記事を チェックしてみてほしい。

ええ、見ましたよ、素晴らしい記事です。私は派手なことはしないことに決めた。パフォーマンスは今のままで十分だし、たくさんのパスは必要ないからだ。

 
fxsaber:

次のように置き換えることができます。


ところで、あなたのif(OrderSend)チェックは常に機能します。なぜなら、OrderSendはエラー時にゼロを返さないからです。

ありがとうございます。後で修正します。

 

ネイティブのMQLツールを使い、松葉杖なしでMLを実装した素晴らしい例に敬意を表したい!

私の唯一のIMHO意見は、この例を強化学習と 位置づけることについてです。

第一に、強化学習はエージェントの記憶、つまりこの場合はRDFに依存した効果を持つべきだと思いますが、ここではトレーニングサンプルのサンプルをフィルタリングするだけで、実質的には教師によるトレーニングのためのデータ準備と大差ありません。

第二に、訓練そのものはストリーミングで連続的なものではなく、一回限りのものである。テスターが通過するたびに、最適化の過程で、システム全体が再度訓練されるため、リアルタイムであることは言うまでもない。

 
Ivan Negreshniy:

MQLのネイティブ・ツールを使い、松葉杖を使わずにMLを実装した素晴らしい例に敬意を表したい!

私の唯一のIMHOは、この例を強化学習と位置づけていることだ。

第一に、強化はエージェントの記憶、つまりこの場合はRDFに依存的に影響を与えるべきですが、ここでは訓練サンプルのサンプルをフィルタリングするだけで、実質的には教師を使って訓練用のデータを準備するのと大差ないように思えます。

第二に、トレーニングそのものはストリーミングや連続的なものではなく、アドホックなものです。テスターが通過するたびに、最適化プロセスの間に、システム全体が再度トレーニングされるため、リアルタイムの話ではありません。

その通り、これは単純な粗視化された例であり、強化学習と いうよりも、より親しみやすい足場を作ることを目的としている。このトピックをさらに発展させ、強化の他の方法を検討する価値はあると思う。

 
Maxim Dmitrievsky

参考になった!

 
Ivan Negreshniy:

第一に、強化はエージェントの記憶、つまりこの場合はRDFを投与するべきだと思われるが、ここでは訓練サンプルをフィルタリングしているだけで、教師を使って学習するための訓練データとほとんど変わらない。

第二に、訓練そのものはストリーミングで連続的なものではなく、一回限りのものです。テスターが通過するたびに、最適化の過程で、システム全体が再度訓練されるからです。

あなたの回答に少し補足します。この2点は密接に関連しています。このバージョンは、エクスペリエンス・リプレイというテーマのバリエーションです。これは、常にテーブルを更新せず、森を再訓練せず(これはより多くのリソースを必要とする)、新しい経験で最後にのみ再訓練する。つまり、これは完全に正当な強化の変形であり、例えばDeepMindでアタリ ゲームに使用されているが、そこではすべてがより複雑で、過剰適合に対抗するためにミニバッチが使用されている。

学習をストリーミング化するためには、NSに追加学習をさせるのがいいと思う。もし、プラスでそのようなネットワークの例をご存知の方がいらっしゃいましたら、ぜひ教えてください。)

繰り返しになりますが、もし近似器が再学習する可能性がないのであれば、リアルタイムの更新のためには、過去の状態の行列全体をドラッグしなければなりません。

また、Q-phraseとNNをmqlと組み合わせたいのですが、この論文のように通常の時間差推定に限定できるのに、なぜそれを使って状態間遷移確率でサイクルを回すのか理解できません。したがって、ここではアクター・クリティックの方が適切である。

 
Maxim Dmitrievsky:

答えに少し補足したい。この2点は密接に関連している。このバージョンは、経験再プレーというテーマのバリエーションである。これは、常にテーブルを更新せず、森を再教育せず(これはより多くのリソースを必要とする)、新しい経験で最後にのみ再教育する。つまり、これはリエンフォースメントの完全に正当なバリエーションであり、例えばアタリ ゲームのDeepMindで使用されているが、そこではすべてがより複雑で、オーバーフィッティングに対抗するためにミニバッチが使用されている。

学習をストリーミング化するためには、追加学習が可能なNSがあればいいと思う。もし、あなたか他の誰かが、プラスでそのようなネットワークの例を持っていたら、ありがたいです :)

繰り返しになりますが、もし近似器が再学習する可能性がないのであれば、リアルタイムの更新のためには、過去の状態の行列全体をドラッグする必要があります。

また、Q-phraseとNNをmqlと組み合わせたいのですが、この論文のように通常の時間差推定に限定できるのに、なぜそれを使って状態間遷移確率でサイクルを回すのか理解できません。だから、ここではアクター・クリティックの方が話題になっている。

バッチ学習という形で経験を再現する変形は、RLの正当な実装であることに異論はありませんが、RLの主な欠点の1つである長期の単位割り当てを示すものでもあります。 報酬(強化)はラグをもって発生するので、非効率的かもしれません。

同時に、もうひとつのよく知られた欠点は、「探索vs.探索」というバランスが崩れるということである。したがって、IMHOは、ストリーミング学習のないRLでは、良いことは何も起こらないだろうと考えている。

ネットワークの新しい例についてですが、私がこのフォーラムで紹介したP-netについて言えば、まだNDAなのでソースコードを共有することはできません。技術的には、もちろんその長所と短所があります。長所としては、学習の高速化、さまざまなデータオブジェクトの処理、将来的な追加トレーニング、おそらくLSTMがあります。
現時点では、Python用のライブラリとネイティブのMT4 EAジェネレータがありますが、すべてテスト段階です。直接コーディングするために、エンジンに組み込まれたPythonインタプリタを使用するバリエーションがあります。

RLの純粋なMQL実装については、直感的には、決定木(ポリシーツリー)の動的な構築やMLP間の重みの配列の操作にあるように思えます。

 

よくやった、ミハイル! 成功への道のりは20%だ。残りの3%は合格だ。そして、あなたは正しい方向に進んでいる。

多くの人は、37のインジケータがあるExpert Advisorに84のインジケータを追加して、「これで絶対にうまくいく」と考える。ナイーブだ。

そして本題。あなたはマシンとマシンの間でのみ対話を持っています。私の意見では、機械 - 人間 - 機械を追加する必要があります。

説明しよう。ゲーム理論では、戦略ゲームには次のような属性がある:膨大な数のランダム要因、規則的要因、心理的要因。

心理的要因とは、良い映画があり、悪い映画があり、インド映画があるというようなものだ。おわかりいただけただろうか?

もし興味があれば、次に何をすればいいのか、どうすればそれを実現できるのかを尋ねてくれるだろうか?まだわからない。自分で答えを見つけようとしているところだ。

でも、クルマだけにこだわっていたら、84のインジケーターと同じで、足すか足さないかで堂々巡りになってしまう。