Rでのランダムフォレストコンピューティング時間

R のパーティパッケージを10,000行と34の機能で使用していますが、一部の要因機能には300以上のレベルがあります。計算時間が長すぎます。（これまでに3時間かかりましたが、まだ終了していません。）

ランダムフォレストの計算時間に大きな影響を与える要素を知りたいです。レベルが多すぎる要因がありますか？RF計算時間を改善するための最適化された方法はありますか？

RFの全体的な複雑さは、です。計算を高速化する場合は、次を試してください。$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. のrandomForest代わりに使用するpartyか、さらに良い、rangerまたはRborist（両方はまだテストされていません）。
2. 数式を使用しないでください。つまり、のrandomForest(predictors,decision)代わりに呼び出しますrandomForest(decision~.,data=input)。
3. do.trace引数を使用して、OOBエラーをリアルタイムで確認します。このようにして、あなたが下げることができることを検出することができますntree。
4. 要因について; RF（およびすべてのツリーメソッド）は、レベルの最適なサブセットを見つけようとするため、可能性をスキャンします。このため、この要素があなたに多くの情報を与えることができるのはかなり単純です-言うまでもなく、randomForestは32レベル以上の要素を食べません。たぶん、単にそれを順序付けられたものとして扱うことができ（したがって、RFの通常の数値変数と同等です）、いくつかのグループにクラスター化し、この1つの属性をいくつかに分割できますか？$2^\text{(# of levels-1)}$
5. コンピューターのRAMが不足しておらず、スワップスペースを使用しているかどうかを確認します。その場合、より大きなコンピューターを購入します。
6. 最後に、オブジェクトのランダムなサブセットを抽出し、これについていくつかの初期実験を行うことができます。

randomForestは、フィーチャとレコードのランダムなサブセットでトレーニングされた独立したカートのコレクションであるため、並列化に役立ちます。combine()randomForestパッケージの関数は、個別にトレーニングされたフォレストをつなぎ合わせます。これがおもちゃの例です。@mpqの答えが示すように、式表記を使用するべきではなく、変数のデータフレーム/マトリックスと結果のベクトルを渡す必要があります。私は恥知らずにこれらをドキュメントから削除しました。

library("doMC")
library("randomForest")
data(iris)

registerDoMC(4) #number of cores on the machine
darkAndScaryForest <- foreach(y=seq(10), .combine=combine ) %dopar% {
   set.seed(y) # not really needed
   rf <- randomForest(Species ~ ., iris, ntree=50, norm.votes=FALSE)
}

randomForest結合関数を同様の名前の.combineパラメーターに渡しました。これはループの出力で関数を制御します。欠点は、OOBエラー率がなく、より悲劇的な変数重要度が得られることです。

編集：

投稿を読み直した後、34以上の要因の問題について何も話していないことに気付きました。完全に考え抜かれた答えは、それらをバイナリ変数として表すことです。それは、それぞれの要素が、その存在/非存在について0/1レベルの要素でエンコードされた列です。重要でない要素に対して変数を選択して削除することにより、フィーチャのスペースが大きくなりすぎないようにすることができます。

いくつかのリンクをお勧めします。

1）因子変数のレベル数の縮小 はstackoverflow、randomForestパッケージの使用中に同様の問題に対処するための質問へのリンクです。具体的には、最も頻繁に発生するレベルのみを使用し、他のすべてのそれほど頻繁に発生しないレベルに新しいレベルを割り当てます。

そのアイデアは、2009 KDD Cup Slow Challengeから生まれました。この競争のデータには多くのレベルの要素があり、2コア/ 2GB RAMラップトップで実行するために50,000行から15,000列にデータを切り分けるために使用した方法のいくつかについて説明します。

私の最後の提案は、上記で提案したように、hi-CPU Amazon EC2インスタンスで並行して問題を実行することです。

Rの特定のアルゴリズムの速度について話すことはできませんが、長い計算時間の原因は明らかです。各ブランチのツリーごとに、CARTは最良のバイナリ分割を形成しています。したがって、34の機能のそれぞれについて、変数の各レベルによって与えられる分割を最も多く見ます。ツリー内の各分割の実行時間にツリー内のブランチの数を乗算し、それをフォレスト内のツリーの数で乗算すると、実行時間が長くなります。知るか？たぶん、高速のコンピューターでもこれを完了するには何年もかかるでしょうか？

物事をスピードアップするための最良の方法は、いくつかのレベルをまとめて、各変数が300の代わりに3〜5レベルになるようにすることです。データ内の情報。

その後、個々のツリーの各ノードで分割するための検索時間を短縮できる巧妙なアルゴリズムがあるかどうかを確認できます。特定のツリーでは、分割検索は前のツリーに対してすでに実行された検索の繰り返しである可能性があります。そのため、以前の分割決定のソリューションを保存し、繰り返し実行するタイミングを特定できる場合、その戦略によって計算時間が少し節約される可能性があります。