Tempo di calcolo casuale della foresta in R

Sto usando il pacchetto party in R con 10.000 righe e 34 funzionalità e alcune funzionalità dei fattori hanno più di 300 livelli. Il tempo di elaborazione è troppo lungo. (Ci sono volute 3 ore finora e non è ancora finito.)

Voglio sapere quali elementi hanno un grande effetto sul tempo di calcolo di una foresta casuale. Sta avendo fattori con troppi livelli? Esistono metodi ottimizzati per migliorare i tempi di elaborazione RF?

La complessità generale del RF è qualcosa di simile ; se vuoi velocizzare i tuoi calcoli, puoi provare quanto segue:$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. Usa randomForestinvece di party, o, ancora meglio, rangero Rborist(sebbene entrambi non siano ancora stati testati in battaglia).
2. Non usare la formula, ovvero chiama randomForest(predictors,decision)invece di randomForest(decision~.,data=input).
3. Utilizzare l' do.traceargomento per visualizzare l'errore OOB in tempo reale; in questo modo è possibile rilevare che è possibile ridurre ntree.
4. Sui fattori; RF (e tutti i metodi ad albero) cercano di trovare un sottoinsieme ottimale di livelli, scansionando così possibilità; a tal fine è piuttosto ingenuo che questo fattore possa darti così tante informazioni - per non parlare del fatto che randomForest non consumerà fattori con più di 32 livelli. Forse puoi semplicemente trattarlo come ordinato (e quindi equivalente a una normale variabile numerica per RF) o raggrupparlo in alcuni gruppi, suddividendo questo attributo in diversi?$2^\text{(# of levels-1)}$
5. Controlla se il tuo computer non ha esaurito la RAM e sta utilizzando lo spazio di swap. In tal caso, acquista un computer più grande.
6. Infine, puoi estrarre un sottoinsieme casuale di oggetti e fare alcuni esperimenti iniziali su questo.

Poiché randomForest è una raccolta di carrelli indipendenti addestrati su un sottoinsieme casuale di funzionalità e registrazioni, si presta alla parallelizzazione. La combine()funzione nel pacchetto randomForest riunirà foreste addestrate in modo indipendente. Ecco un esempio di giocattolo. Come afferma la risposta di @mpq, non dovresti usare la notazione formula, ma passare un frame di dati / matrice di variabili e un vettore di risultati. Ho spudorato sollevato questi dai documenti.

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)
}

Ho passato la funzione di combinazione randomForest al parametro .combine chiamato in modo simile (che controlla la funzione sull'output del loop. Il lato negativo è che non si ottiene alcun tasso di errore OOB o importanza più tragicamente variabile.

Modificare:

Dopo aver riletto il post, mi rendo conto di non parlare nulla del problema dei 34+ fattori. Una risposta totalmente non pensata potrebbe essere rappresentarli come variabili binarie. Questo è ogni fattore una colonna codificata con fattore 0/1-level sulla sua presenza / non-presenza. Effettuando una selezione variabile su fattori non importanti e rimuovendoli, è possibile impedire che lo spazio delle funzionalità cresca troppo.

Vorrei suggerire un paio di link:

1) Ridurre il numero di livelli di una variabile fattore è un collegamento a una domanda su stackoverflowcome affrontare un problema simile durante l'utilizzo del randomForestpacchetto. In particolare, si tratta di utilizzare solo i livelli che si verificano più frequentemente e di assegnare un nuovo livello a tutti gli altri livelli, che si verificano meno frequentemente.

L'idea è nata da qui: 2009 KDD Cup Slow Challenge . I dati di questa competizione avevano molti fattori con molti livelli e discute alcuni dei metodi usati per ridurre i dati da 50.000 righe a 15.000 colonne per l'esecuzione su un laptop RAM 2-core / 2GB.

Il mio ultimo suggerimento sarebbe quello di esaminare l'esecuzione del problema, come suggerito sopra, in parallelo su un'istanza Amazon EC2 ad alta CPU.

Non posso parlare della velocità di specifici algoritmi in R, ma dovrebbe essere ovvio cosa sta causando lunghi tempi di elaborazione. Per ogni albero in ogni ramo, il CARRELLO sta cercando la migliore divisione binaria. Quindi, per ciascuna delle 34 caratteristiche, la maggior parte guarda alle divisioni fornite da ciascuno dei livelli delle variabili. Moltiplica il tempo di esecuzione per ogni divisione in un albero per il numero di rami nella struttura e quindi moltiplicalo per il numero di alberi nella foresta e avrai un tempo di esecuzione lungo. Chissà? Forse anche con un computer veloce potrebbero volerci anni per finire?

Penso che il modo migliore per accelerare le cose sarebbe quello di raggruppare alcuni livelli insieme in modo che ogni variabile scenda a forse da 3 a 5 livelli anziché fino a 300. Naturalmente questo dipende dal fatto di essere in grado di farlo senza perdere importanti informazioni nei tuoi dati.

Dopodiché forse potresti vedere se esiste qualche algoritmo intelligente che può accelerare i tempi di ricerca per la divisione in ciascun nodo dei singoli alberi. potrebbe essere che in un determinato albero la ricerca suddivisa sia una ripetizione di una ricerca già effettuata per un albero precedente. Quindi, se riesci a salvare le soluzioni delle precedenti decisioni divise e identificare quando stai ripetendo, forse quella strategia potrebbe risparmiare un po 'di tempo di calcolo.