Tiempo de computación forestal aleatorio en R

Estoy usando el paquete de fiesta en R con 10,000 filas y 34 características, y algunas características de factor tienen más de 300 niveles. El tiempo de computación es demasiado largo. (Ha tomado 3 horas hasta ahora y aún no ha terminado).

Quiero saber qué elementos tienen un gran efecto en el tiempo de cálculo de un bosque aleatorio. ¿Tiene factores con demasiados niveles? ¿Existen métodos optimizados para mejorar el tiempo de computación de RF?

La complejidad general de RF es algo así como ; si desea acelerar sus cálculos, puede intentar lo siguiente:$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. Use en randomForestlugar de party, o, incluso mejor, rangero Rborist(aunque ambos aún no están probados en batalla).
2. No utilice la fórmula, es decir, llame en randomForest(predictors,decision)lugar de randomForest(decision~.,data=input).
3. Use el do.traceargumento para ver el error OOB en tiempo real; De esta manera puede detectar que puede bajar ntree.
4. Sobre los factores; RF (y todos los métodos de árbol) intentan encontrar un subconjunto óptimo de niveles, escaneando posibilidades; para este fin es bastante ingenuo, este factor puede brindarle tanta información, sin mencionar que randomForest no comerá factores con más de 32 niveles. ¿Quizás puede simplemente tratarlo como uno ordenado (y, por lo tanto, equivalente a una variable numérica normal para RF) o agruparlo en algunos grupos, dividiendo este atributo en varios?$2^\text{(# of levels-1)}$
5. Compruebe si su computadora no se ha quedado sin RAM y está utilizando espacio de intercambio. Si es así, compre una computadora más grande.
6. Finalmente, puede extraer un subconjunto aleatorio de objetos y hacer algunos experimentos iniciales sobre esto.

Debido a que randomForest es una colección de carros independientes entrenados en un subconjunto aleatorio de características y registros, se presta a la paralelización. La combine()función en el paquete randomForest unirá bosques capacitados de forma independiente. Aquí hay un ejemplo de juguete. Como dice la respuesta de @mpq, no debe usar la notación de fórmula, sino pasar un marco de datos / matriz de variables y un vector de resultados. Desvergonzadamente los saqué de los documentos.

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

Pasé la función combinada randomForest al parámetro .combine de nombre similar (que controla la función en la salida del bucle. El lado negativo es que no obtienes una tasa de error OOB o una importancia más trágicamente variable.

Editar:

Después de volver a leer la publicación, me doy cuenta de que no hablo nada sobre el problema del factor 34+. Una respuesta total no pensada podría ser representarlos como variables binarias. Ese es cada factor de una columna que está codificada como factor de nivel 0/1 sobre su presencia / no presencia. Al hacer una selección variable de factores sin importancia y eliminarlos, podría evitar que su espacio de características crezca demasiado.

Sugeriría un par de enlaces:

1) Reducir el número de niveles de una variable de factor es un enlace a una pregunta stackoverflowpara tratar un problema similar mientras se usa el randomForestpaquete. Específicamente, se trata de usar solo los niveles más frecuentes y asignar un nuevo nivel a todos los demás niveles menos frecuentes.

La idea surgió de aquí: 2009 KDD Cup Slow Challenge . Los datos para esta competencia tenían muchos factores con muchos niveles y discute algunos de los métodos que usaron para reducir los datos de 50,000 filas por 15,000 columnas para ejecutar en una computadora portátil de 2 núcleos / 2GB RAM.

Mi última sugerencia sería mirar cómo se ejecuta el problema, como se sugirió anteriormente, en paralelo en una instancia de Amazon EC2 de alta CPU.

No puedo hablar de la velocidad de algoritmos específicos en R, pero debería ser obvio lo que está causando un tiempo de cómputo prolongado. Para cada árbol en cada rama, CART está buscando la mejor división binaria. Entonces, para cada una de las 34 características, la mayoría mira las divisiones dadas por cada uno de los niveles de las variables. Multiplique el tiempo de ejecución para cada división en un árbol por la cantidad de ramas en el árbol y luego multiplíquelo por la cantidad de árboles en el bosque y tendrá un tiempo de ejecución prolongado. ¿Quién sabe? ¿Quizás incluso con una computadora rápida esto podría llevar años terminar?

Creo que la mejor manera de acelerar las cosas sería agrupar algunos de los niveles para que cada variable baje a entre 3 y 5 niveles en lugar de 300. Por supuesto, esto depende de poder hacer esto sin perder importantes información en sus datos.

Después de eso, tal vez podría mirar para ver si hay algún algoritmo inteligente que pueda acelerar el tiempo de búsqueda para dividirse en cada nodo de los árboles individuales. podría ser que en un árbol en particular la búsqueda dividida sea una repetición de una búsqueda ya realizada para un árbol anterior. Entonces, si puede guardar las soluciones de las decisiones divididas anteriores e identificar cuándo está repitiendo, tal vez esa estrategia podría ahorrar un poco en tiempo de computación.