¿Cómo mejorar el rendimiento de randomForest?

Ya no tienes que buscar más por otras páginas ya que estás al lugar adecuado, poseemos la solución que quieres pero sin complicarte.

Solución:

(El tl; dr es que debe a) aumentar el tamaño del nodo a >> 1 yb) excluir columnas de características de muy baja importancia, tal vez incluso excluir (digamos) el 80% de sus columnas. Su problema es casi seguro que no na.roughfixpero si sospechas eso, corre na.roughfix por separado como un paso independiente, antes de llamar randomForest. Quite esa pista falsa al principio).

Ahora, todos los siguientes consejos solo se aplican hasta que supere los límites de su memoria, así que mida el uso de su memoria y asegúrese de no excederse. (Comience con parámetros ridículamente pequeños, luego amplíelos, mida el tiempo de ejecución y siga comprobando que no aumentó de manera desproporcionada).

Los principales parámetros que afectan el rendimiento de randomForest son:

• probar (menos es más rápido)
• ntrees
• número de características/cols en datos – ¡más es cuadráticamente más lento, o peor! Vea abajo
• número de observaciones/filas en datos
• ncores (más es más rápido, siempre que se utilice la opción paralela)
• algún aumento de rendimiento al configurar la importancia = F y la proximidad = F (no calcule la matriz de proximidad)
• Nunca use el valor predeterminado loco nodesize=1, para la clasificación! En el paquete de Breiman, no puede establecer directamente la profundidad máxima, pero use nodesize como un proxy para eso, y también lea todos los buenos consejos en: CrossValidated: “Preguntas prácticas sobre cómo ajustar Random Forests”
• Así que aquí sus datos tienen 4.2e+5 filas, luego, si cada nodo no debe ser más pequeño que ~ 0.1%, intente nodesize=42. (Primero intente tamaño de nodo = 420 (1%), vea qué tan rápido es, luego vuelva a ejecutar, ajustando el tamaño de nodo hacia abajo. Determine empíricamente un buen tamaño de nodo para este conjunto de datos).
• el tiempo de ejecución es proporcional a ~ 2^D_max, es decir, polinomial a (-log1p(nodesize))
• opcionalmente, también puede acelerar mediante el uso de muestreo, consulte strata,sampsize argumentos

Luego, una estimación de primer orden del tiempo de ejecución, que denota mtry=M, ntrees=T, ncores=C, nfeatures=F, nrows=R, max depth=D_max, es:

Runtime proportional to: T * F^2 * (R^1.something) * 2^D_max / C

(Nuevamente, todas las apuestas están canceladas si excede la memoria. Además, intente ejecutar solo un núcleo, luego 2, luego 4 y verifique que realmente obtenga una aceleración lineal. Y no una desaceleración). (El efecto de R grande es peor que lineal , tal vez cuadrático, ya que la partición en árbol tiene que considerar todas las particiones de las filas de datos; ciertamente es algo peor que lineal. Compruébelo usando muestreo o indexación para dar solo el 10% de las filas).

Sugerencia: mantener un montón de características basura de baja importancia aumenta cuadráticamente el tiempo de ejecución, para un aumento sublineal en la precisión. Esto se debe a que en cada nodo, debemos considerar todas las posibles selecciones de características (o cualquier número de mtry) que permita. Y dentro de cada árbol, debemos considerar todas (F-choose-mtry) posibles combinaciones de características.

Así que aquí está mi metodología, haciendo una “selección de características rápida y sucia para el rendimiento”:

1. generar un árbol normalmente (lento), aunque use un cuerdo nodesize=42 o más grande
2. mirar rf $ importancias o randomForest::varImpPlot(). Elija solo las funciones K principales, donde elija K; para un ejemplo tonto-rápido, elija K=3. Guarde toda la lista para referencia futura.
3. ahora vuelve a ejecutar el árbol pero solo dale newdata[,importantCols]
4. confirme que la velocidad es cuadráticamente más rápida y oob.error no es mucho peor
5. una vez que conozca la importancia de sus variables, puede desactivar importance=F
6. ajustar mtry y nodesize (modificar uno a la vez), volver a ejecutar y medir la mejora de la velocidad
7. trazar los resultados de su rendimiento en ejes logarítmicos
8. publicanos los resultados! ¿Confirmaste lo anterior? ¿Algún comentario sobre el uso de la memoria?

(Tenga en cuenta que lo anterior no es un procedimiento estadísticamente válido para la selección de características real, no confíe en él para eso, lea el paquete randomForest para conocer los métodos adecuados reales para la selección de características basada en RF).

Sospecho que do.trace también podría consumir tiempo … en lugar de do.trace = TRUE, puede usar do.trace = 5 (para mostrar solo 5 rastros) solo para tener una idea de los errores. Para conjuntos de datos grandes, do.trace también tomaría mucho tiempo.

Valoraciones y comentarios

Recuerda algo, que tienes la opción de explicar si atinaste tu apuro a tiempo.

---

---

Utiliza Nuestro Buscador