R rasgele orman hesaplama zamanı

Ben kullanıyorum parti 10.000 satır ve 34 özelliklerle R paketi ve bazı faktör özellikleri 300'den fazla seviyeleri var. Hesaplama süresi çok uzun. (Şimdiye kadar 3 saat sürdü ve henüz bitmedi.)

Hangi öğelerin rastgele bir ormanın hesaplama zamanı üzerinde büyük bir etkisi olduğunu bilmek istiyorum. Çok fazla seviyeye sahip faktörleri var mı? RF hesaplama süresini iyileştirmek için optimize edilmiş yöntemler var mı?

RF'nin genel karmaşıklığı, ; Hesaplamalarınızı hızlandırmak istiyorsanız, aşağıdakileri deneyebilirsiniz:$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. Kullanım randomForestyerine partyveya daha da iyisi, rangerya Rborist(hem henüz savaş görmüş olmasa da).
2. Formül kullanma, yani randomForest(predictors,decision)yerine çağrı yapmayın randomForest(decision~.,data=input).
3. do.traceOOB hatasını gerçek zamanlı olarak görmek için argümanı kullanın ; Bu şekilde daha düşük olduğunu tespit edebilirsiniz ntree.
4. Faktörler hakkında; RF (ve tüm ağaç yöntemleri), optimal bir alt düzey kümesi bulmaya çalışır, böylece olasılıklarını tarar ; Bu amaçla, bu faktörün size çok fazla bilgi vermesi oldukça naif - randomForest'in 32'den fazla seviyedeki faktörleri yemeyeceğinden bahsetmiyorum bile. Belki basitçe sipariş edilen bir (veya bu nedenle RF için normal, sayısal bir değişkene eşdeğer) gibi davranabilir ya da bunu bir niteliğe ayırarak bazı gruplara ayırabilirsiniz?$2^\text{(# of levels-1)}$
5. Bilgisayarınızın RAM'inde bitip bitmediğini ve takas alanı kullanıp kullanmadığını kontrol edin. Eğer öyleyse, daha büyük bir bilgisayar satın alın.
6. Son olarak, bazı rasgele nesne alt kümelerini ayıklayabilir ve bu konuda ilk deneyler yapabilirsiniz.

RandomForest, rastgele bir özellikler alt kümesi üzerine eğitilmiş bağımsız sepetlerden oluşan bir koleksiyon olduğu ve paralelleşmeye yol açtığı için. combine()RandomForest paketinde bağımsız olarak işlev eğitimli ormanlar birlikte dikiş olacaktır. İşte bir oyuncak örneği. @Mpq 'in cevabında belirtildiği gibi, formül gösterimini kullanmamalısınız, ancak değişkenlerin bir dataframe / matrisini ve bir sonuç vektörünü iletmelisiniz. Bunları doktorlardan utanmadan kaldırdım.

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 işlevini, benzer şekilde adlandırılmış .combine parametresine (döngü çıkışının işlevini denetleyen) geçirdim.

Düzenle:

Gönderiyi tekrar okuduktan sonra, 34+ faktör meselesi hakkında hiçbir şeyden bahsetmediğimin farkındayım. Düşünülmemiş bir cevap, onları ikili değişkenler olarak göstermek olabilir. Bu, her bir faktör varlığı / varlığı olmayan durum hakkında 0/1-seviyeli faktörle kodlanan bir sütundur. Önemsiz faktörler üzerinde bazı değişken seçimler yaparak ve bunları kaldırarak alanın çok fazla büyümesini önleyebilirsiniz.

Birkaç bağlantı önerebilirim:

1) Bir faktör değişkeninin seviyesini küçültmekstackoverflow , randomForestpaketi kullanırken benzer bir konuyu ele almak için bir soruya bir bağlantıdır . Özellikle, sadece en sık görülen seviyelerin kullanılması ve diğer tüm daha az sıklıkta olan seviyelere yeni bir seviye verilmesi ile ilgilidir.

Bunun için fikir buradan geldi: 2009 KDD Kupası Yavaş Mücadelesi . Bu yarışma için veriler birçok seviyede faktöre sahipti ve 2 çekirdekli / 2GB RAM dizüstü bilgisayarda çalıştırmak için verileri 50.000 sıradan 15.000 sütun düşürmek için kullandıkları yöntemlerden bazılarını tartışıyor.

Son önerim, hi-CPU Amazon EC2 örneğine paralel olarak, yukarıda önerildiği gibi sorunu yönetmeye bakmak.

R'deki belirli algoritmaların hızıyla konuşamıyorum ama uzun hesaplama süresine neyin sebep olduğu açık olmalı. Her daldaki her ağaç için CART, en iyi ikili bölünme formuna bakıyor. Bu yüzden, 34 özelliğin her biri için, değişkenlerin her birinin verdiği bölmelere en çok bakar. Bir ağaçtaki her bölünme için çalıştırma süresini, ağaçtaki dalların sayısıyla çarpın ve ardından ormandaki ağaçların sayısıyla çarpın ve uzun bir çalışma süreniz olsun. Kim bilir? Belki hızlı bir bilgisayarda bile bu işlemin tamamlanması yıllar alabilir?

İşleri hızlandırmanın en iyi yolu, bazı değişkenleri bir araya getirerek, her bir değişkenin 300 yerine 3 ila 5 seviyeye düşmesi olduğunu düşünüyorum. verilerinizdeki bilgiler.

Bundan sonra, ağaçların her bir düğümünde bölme için arama süresini hızlandıran akıllı bir algoritma olup olmadığını görmek için bakabilirsiniz. Belirli bir ağaçta bölünmüş aramanın önceki bir ağaç için yapılmış bir aramanın tekrarı olduğu olabilir. Öyleyse, önceki bölünmüş kararların çözümlerini koruyabilir ve ne zaman tekrarladığınızı belirleyebilirseniz, belki de bu strateji hesaplama zamanından biraz tasarruf sağlayabilir.