Xgboost: El modelo producido en 1.0.0 no se puede cargar en 0.90

¿Intentaste install.packages('xgboost') ?

¿Intentaste install.packages('xgboost') ?

Eso funciona bien, pero luego todas las predicciones de los modelos guardados (usando saveRDS) producen numéricos (0). Parece que los modelos entrenados con openMP no funcionan en computadoras sin ese marco. Mi esperanza era que compilar desde la fuente resolvería esto.

Así es como compila XGBoost desde la fuente:

mkdir build
cd build
cmake .. -G"Visual Studio 14 2015 Win64" -DR_LIB=ON
cmake --build . --target install --config Release

¿Puede compartir el archivo del modelo para que podamos intentar averiguar por qué obtiene un 0 en la predicción?

Gracias. ¿Quiere el objeto R o prefiere convertirlo a través de xgb.save.raw?

Ambos

Gracias por su ayuda y apoyo (y por hacer un programa de aprendizaje tan extraordinario).

Se adjunta un archivo .rdata comprimido. En 3 sistemas (Mac, MacBook, Ubuntu), puedo ejecutar el siguiente código:

modelList <- readRDS("<path_to_folder>/modelList.rdata")
attach(modelList)
predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))

Y obtener el siguiente resultado:

> predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
[23:12:50] WARNING: ../..//amalgamation/../src/objective/regression_obj.cu:167: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_caret)
[1] 14.0180358887 13.0352602005 12.9208145142 13.2430124283 13.6698570251
[6] 12.9033651352

> predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
[23:16:17] WARNING: ../..//amalgamation/../src/objective/regression_obj.cu:167: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_xgbbase)
[1] 14.0180358887 13.0352602005 12.9208145142 13.2430124283 13.6698570251
[6] 12.9033651352

En el sistema 4 (Windows base R con xgboost instalado desde CRAN) obtengo resultados muy diferentes:

> predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
[23:18:04] WARNING: amalgamation/../src/objective/regression_obj.cu:152: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_caret)
numeric(0)

> predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
[23:18:41] WARNING: amalgamation/../src/objective/regression_obj.cu:152: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_xgbbase)
numeric(0)

Sospecho que esto puede necesitar que se abra un nuevo problema, pero agradezco cualquier orientación que pueda brindar sobre por qué el mismo código se comportaría de manera diferente en diferentes sistemas.

Por último, se incluye xgbRaw (debería ser invocable si usas attach()), se generó con el siguiente código:

xgbRaw=xgb.save.raw(xgb.Booster.complete(caretModel$finalModel))

Gracias otra vez.

modelList.rdata.zip

¿Probablemente debido a nuestra protección dmlc contra la excepción omp?

@leedrake5 ¿Su máquina no es compatible con OpenMP?

@hcho3 ¿Encontraste la causa? Acabo de compilar XGBoost sin OpenMP (con algunos parches para CMakeLists), las pruebas de memoria externa fallan como se esperaba, también falla la prueba de grupo paralelo hist (que arreglé en la rama local). Pero hasta ahora puedo obtener valores de predicción perfectos.

@hcho3 Mi máquina admite openmp. Pero estamos implementando estos modelos a escala industrial y muchas de las computadoras en sitios específicos no tienen openmp. Acabamos de descubrir esto después de 6 meses de preparación y una semana hasta la implementación, por lo que estamos luchando para descubrir por qué los modelos funcionan en algunas computadoras y no en otras.

Si hay alguna filosofía sobre por qué los modelos solo deberían funcionar en su entorno de construcción, ¿habría alguna forma de obtener un error informativo sobre por qué?

@leedrake5 Es un error. He estado tratando de reproducirlo en Ubuntu con openmp deshabilitado, pero hasta ahora no he tenido suerte.

@trivialfs Si ayuda, yo y la mayoría de mis colegas experimentamos el error en Windows. Aunque un colega mío pudo reproducirlo en ubuntu sin openmp.

Sospecho que una instalación mínima de R sin cosas sofisticadas (openmp, intelmkl, openblas, etc.) puede reproducirlo, pero todavía estoy pensando en qué parte del sistema está causando problemas.

@leedrake5 Si hay una manera de reproducirlo en distribuciones de Linux, ¡sería de gran ayuda!

Deshabilité todas las opciones, incluida la prueba de google, omp ... Pero aún tengo el resultado correcto al cargar sus modelos. La instalación de R es la distribución predeterminada de apt , no creo que tenga nada que ver con la predicción de XGBoost.

Puede que no sea causado por OpenMP. Como incluso la predicción sale realmente mal, todavía hay un sesgo global, no 0.

La única razón por la que puedo pensar es que XGBoost en realidad no se está instalando. Creo que hacemos pruebas en CRAN, ¿verdad? @hcho3

Probé la compilación de CMake y la compilación de herramientas automáticas. Estos son mis indicadores de compilación informados por install.packages(...) (construcción de autotools):

g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG -I../..//include -I../..//dmlc-core/include -I../..//rabit/include -I../../ -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_    -DDMLC_CMAKE_LITTLE_ENDIAN=1 -pthread -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-el7SHG/r-base-3.5.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c ../..//amalgamation/xgboost-all0.cc -o ../..//amalgamation/xgboost-all0.o

@trivialfis Aún más curioso, ya que XGBoost se instala con éxito desde CRAN y la biblioteca (xgboost) funciona sin ningún problema.

Aunque un colega mío pudo reproducirlo en ubuntu sin openmp.

¿Es posible que amablemente pueda compartir cómo reproducirse?

Aunque un colega mío pudo reproducirlo en ubuntu sin openmp.

¿Es posible que amablemente pueda compartir cómo reproducirse?

No estoy seguro de que sepan lo suficiente sobre cómo funcionan los sistemas Linux, pero si conocen algún diagnóstico que puedan proporcionar, háganmelo saber.

Por mi parte, estoy tratando de crear una instalación de ubuntu de caja virtual que pueda replicar el problema; si tiene éxito, enviaré un enlace de descarga para eso.

Reproduje con éxito el problema en Linux; vea la captura de pantalla adjunta.

Estoy subiendo la caja virtual a dropbox. Pero en caso de que prefiera instalar desde cero, las instrucciones para replicar son las siguientes:

1. Descargar e instalar virtualbox
2. Descargue una compilación de ubuntu bionic beaver (utilicé ubuntu-18.04.3-desktop-amd64).
3. Siga las instrucciones aquí: https://medium.com/@mannycodes/installing-ubuntu-18-04-on-mac-os-with-virtualbox-ac3b39678602 . Usé una unidad virtual fija de 15 gigabytes
4. Configure para R 3.6.2 de la siguiente manera:

sudo apt-get update
sudo apt-get install vim
sudo vim /etc/apt/sources.list
i
deb https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/
<esc> :wq
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9
gpg -a --export E298A3A825C0D65DFD57CBB651716619E084DAB9 | sudo apt-key add -
sudo apt-get update
sudo apt-get install r-base-dev

1. instalar paquetes en R

install.packages(c("caret", "xgboost"))

1. cargar paquetes en R

library(caret)
library(xgboost)

1. Cargar los datos

modelList <- readRDS("~/Desktop/modelList.rdata")
attach(modelList)

1. intento de predecir

predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))

Y esto devolvió lo ahora familiar:

[13:00:55] ADVERTENCIA: amalgamation/../src/objective/regression_obj.cu:152: reg:linear ahora está obsoleto en favor de reg:squarederror.
numérico (0)

nota: probé bibliotecas de llamadas explícitas y solo probé la predicción. Ambos resultaron en la misma respuesta numérica (0).

El enlace a la instancia virtual comprimida 7z está aquí: https://www.dropbox.com/s/ld06zz798m0segf/UbuntuDebug.7z?dl=0

Déjame obtener la caja virtual primero. Usualmente uso KVM.

Mirando esto ahora.

@leedrake5 Logré reproducir el problema en la máquina virtual que proporcionó. Parece que hay un problema con saveRDS y xgb.save.raw . ¿Intentó usar xgb.save y xgb.load en su lugar? Este conjunto de funciones utiliza el formato "nativo" del modelo XGBoost y no guarda los atributos que son específicos del entorno R. Es útil si desea transferir su modelo de un paquete R a Python.

El guardado en bruto no debería ser un problema. El problema podría estar en cómo R serializa el código R. Agregamos un nuevo parámetro opcional para predecir, que podría afectar la carga de este tipo de serialización. Intenté investigarlo, pero parece realmente peculiar, al igual que el problema con Python pickle.

@trivialfis ¿ alguna idea sobre las opciones en la función de predicción que podría eludir esto? Mi opinión es que tiene algo que ver con las instrucciones de la CPU, posiblemente más profundas en R de lo que puede abordar el paquete.

@hcho3 Intentaré agregar xgb.save.raw a la tubería de datos actual y veré si eso ayuda. Aunque en el ejemplo que envié, probé esto usando xgb.save.raw en la computadora donde funcionaron las predicciones, y desafortunadamente todavía conduce a numérico (0) en xgb.load. Es cierto que esto fue después de que el modelo ya se había guardado a través de saveRDS, tal vez algo en ese proceso lo corrompa, aunque todavía funciona en el entorno en el que se creó.

Por lo que puedo decir, todavía hay algo sobre el entorno en el que se creó el modelo que debe estar presente en todos los entornos en los que se utiliza. Aunque no sé qué es.

No, quise decir xgb.save , no xgb.save.raw .

@trivialfis Tenga en cuenta que el paquete XGBoost sigue siendo 0.90 en CRAN.

Probé xgb.save, lo cargué en R a través de xgb.load(), y lo mismo, numeric(0). Ver adjunto de xgb.save

xgbModelSaved.xgb.zip

Además, probé el mismo método usando los datos en modelList anteriormente en este hilo en la misma computadora que generó el modelo, funcionó allí.

No importa cómo lo corte, xgb.save, xgb.save.raw, saveRDS, etc., hay algo en el entorno informático en el que se creó el modelo que impide su uso en otros lugares.

Puedo reproducir el problema usando el archivo modelo que proporcionó. Sin embargo, no tengo idea de cómo se generó el archivo del modelo. ¿Puede proporcionar más contexto, por ejemplo

• sistema operativo
• Versión XGBoost
• Comando para guardar el modelo

OS X (Catalina). Compilación de XGBoost desde la fuente, 1.0 (openMP compatible con el sistema). Modelo originalmente guardado usando saveRDS. Intentaré volver a ejecutarlo y guardarlo de diferentes maneras e informaré.

Regeneré un modelo desde cero, lo guardé usando xgb.save (por ejemplo, no usé saveRDS o readRDS excepto para datos de predicción) y lo cargué usando xgb.load. Mismos resultados: la predicción funciona en el sistema informático utilizado para generar el modelo (OS X, XGB 1.0) y falla en otro sistema (Windows 7, XGB 0.9). Adjuntándolo y el modelList a este mensaje. Si hay algo más que pueda hacer para ayudar a diagnosticar este problema, hágamelo saber.

xgb_model <- xgb.load("Z:/Desktop/newxgbModelSaved.xgb")
modelList <- readRDS("Z:/Desktop/modelList2.rdata")
attach(modelList)
predict(object=xgb_model, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
numeric(0)

nuevoxgbModelSaved.xgb.zip

modelList2.rdata.zip

@leedrake5 ¿Es posible usar XGBoost 1.0 en Windows?

@trivialfis Esto podría ser un problema con la compatibilidad con versiones anteriores de los archivos modelo.

Definitivamente es versionado. Acabo de descargar la versión 1.0 de XGBoost, instalé 0.9 de CRAN y el método descrito anteriormente funcionó.

Traté de instalar 0.90 desde la fuente utilizando la última versión , pero la carpeta dmlc-core está vacía, por lo que Cmake arroja el error necesario. Me gustaría mucho mantener la funcionalidad de OpenMP sin importar cómo vaya.

Veo. ¿Intentó instalar la versión 1.0.0 en Windows?

Esa fue la razón inicial de este hilo, por extraño que parezca. Lo intentaré, pero habrá un retraso ya que el proyecto no puede esperar más. Si esto es un problema, sospecho que instalar 1.0 desde la fuente en la imagen virtual de ubuntu que envié solucionaría el mismo problema.

@leedrake5 Sí, debe coincidir con la versión de XGBoost. Use 0.90 en todas partes o 1.0.0 en todas partes.

@trivialfis Recuerdo que hicimos un cambio importante en el formato del modelo binario. ¿Está bien?

No, somos compatibles con versiones anteriores, 1.0 definitivamente debería cargar el modelo desde 0.9

@trivialfis Gracias por la aclaración. En ese caso, tratemos este ticket como un error, ya que esperábamos compatibilidad con versiones anteriores y encontramos un contraejemplo. Lo miraré esta semana.

Creo que el cambio de título propuesto es al revés: el modelo producido en 1.0 no se puede usar para predecir en 0.90. No sé qué grado de compatibilidad se pretende entre versiones, pero como mínimo un error informativo debería ayudar.

Uy, mi mal.

@trivialfis Creo que lo que @leedrake5 está preguntando es compatibilidad con versiones anteriores, es decir, cargar el modelo de 1.0.0 a 0.90. No estoy seguro si esto es lo que prometemos.

@leedrake5 Intenté instalar 1.0.0 en la máquina virtual de Ubuntu, y ahora el archivo RDS se carga bien y obtengo un vector de números reales. Así que lo más probable es que sea el problema de la versión.

EDITAR. El mensaje de advertencia en la captura de pantalla es extraño: Loading model from < 1.0.0, consider saving it again . Esto no debería estar aquí, dado que el modelo fue producido por 1.0.0.

Estoy de acuerdo. Muy contento de establecer la convergencia sobre cuál es el problema.

Desafortunadamente, desde el punto de vista de la producción, tengo que hacer modelos desplegables en la versión masiva (ergo, instalación de CRAN). Pero sé cómo hacer que XGBoost funcione de aquí en adelante, que es el punto crítico absoluto.

Todavía tengo problemas para instalar 0.9 desde la fuente descargada de las versiones o del árbol, pero creo que encontré el problema. cub, dmlc-core, rabit, todas son carpetas vacías en estas descargas. También tienen @después de las carpetas, creo que está relacionado con qué carpetas están vacías. Si sigo esos enlaces, puedo reconstruir carpetas y continuar con la instalación.

Ver captura de pantalla:

Sí, usamos submódulos de git, por lo que la instrucción de compilación le pide que use git clone --recursive para instalar desde la fuente. ¿Está en una situación en la que la instalación de CRAN es inadecuada? Si usar 0.90 en todas partes soluciona su problema, ¿podría simplemente usar CRAN install en todas partes (Linux, Mac, Windows)?

Sí, CRAN no permite OpenMP, que para la generación de modelos es una gran ayuda. Por lo tanto, dedicará algún tiempo a descubrir cómo compilar xgboost 0.90 desde el código fuente para que vuelva a funcionar. Agradezco toda su ayuda para diagnosticar este problema.

@ledrake5

Entendido. Por ahora, este es el comando que puede usar para obtener el código fuente completo, incluidos los submódulos de git:

git clone --recursive https://github.com/dmlc/xgboost -b release_0.90

Esto debería obtener el código fuente de XGBoost y llenar los directorios rabit, cub, dmlc-core. -b release_0.90 se usa para obtener la versión 0.90, no la más reciente.

Aparte:

CRAN no permite OpenMP

En realidad, esto está arreglado en 1.0.0. Intentaré obtener la versión 1.0.0 en CRAN pronto.

Gracias, muy apreciado en todos los aspectos!

@ hetong007 ¿Podemos enviar 1.0.0 a CRAN?

@hcho3 Suena bien, dado que tenemos una detección endian válida. Voy a hacer una presentación en una semana.

@ hetong007 ¿ Alguna actualización? Déjame saber si puedo ayudar de alguna manera.

@hcho3 oh sí. Me gustaría preguntar si tenemos el entorno para las pruebas de Solaris. Hay un error sin resolver en solaris de 0.9: https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/xgboost-00check.html Me gustaría que lo revisaran antes de la sumisión.

@hetong007 Acabo de descargar una imagen de máquina virtual de Solaris de Oracle que puede ejecutarse con VirtualBox. Déjame intentar reproducir el problema.

@ hetong007 Tengo muchos problemas para configurar el entorno R en Solaris. En particular, no puedo instalar paquetes R como igraph y testthat porque las utilidades como awk se comportan de manera diferente en Solaris. No tengo idea de cómo continuar.

@hcho3 ¿Podría ser más claro? Me imagino que uno podría instalar paquetes en la consola R con install.packages('testthat') , dado que testthat ha pasado la verificación de solaris en CRAN.

@hetong007 El paquete igraph usa awk en el paso de configuración, y la función awk de Solaris no es compatible con GNU awk. Es posible instalar GNU awk, pero se llama gawk . Todavía estoy tratando de averiguar cómo hacer que R use gawk en lugar de awk .

@hcho3 OK, esto suena horrible. Tampoco tengo conocimiento de cómo proceder. Acabo de echar un vistazo a la página de resultados de igraph en CRAN: https://cran.r-project.org/web/checks/check_results_igraph.html. Siente que no vamos a estar peor. Haré una presentación de todos modos.

@ hetong007 Gracias. Intentaré volver a las pruebas de Solaris en algún momento. Estoy seguro de que hay una manera.

@hetong007 Ah, sí, asegúrese de usar la rama release_1.0.0 al enviar el código.

@ hcho3 La verificación previa advierte:

* checking whether package 'xgboost' can be installed ... WARNING
Found the following significant warnings:
  amalgamation/../src/common/hist_util.cc:666:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct xgboost::tree::GradStats'; use assignment or value-initialization instead [-Wclass-memaccess]
See 'd:/RCompile/CRANguest/R-devel_gcc8/xgboost.Rcheck/00install.out' for details.

y el archivo 00install.out está aquí (disponible en ~72 horas): https://win-builder.r-project.org/v6XJQBjzgMaW/00install.out

¿Sería posible tener una solución rápida?

@ hetong007 ¿Es esto un bloqueador? Memset se utilizó para acelerar la puesta a cero del histograma (matriz de estructura). Si esto bloquea CRAN, colocaré una protección de macro para que el paquete R use un constructor ordinario en su lugar.

@hcho3 Sí, es un bloqueador. La verificación previa está automatizada y el envío debe pasar sin previo aviso. La macro suena bastante bien, ¡gracias!

@hcho3 ¿Podría intentar usar std::fill primero? Incluso es posible que el compilador no pueda optimizarlo en memset , no creo que sea lo suficientemente crítico como para tener un impacto visible en el rendimiento.

@hetong007 Hice el cambio necesario (https://github.com/dmlc/xgboost/commit/3550b16a34055bc8ec33bf0b7006448e8c1a4eca). ¿Puedes intentarlo de nuevo?

@trivialfis Presentaré una solicitud de extracción por separado para reemplazar memset .

@ hcho3 gracias por la solución! Si nada grave sale mal, está en camino a CRAN.

@hcho3 Entonces falla en Soalris, del Prof. Ripley:

On Solaris it was quicker to diagnose the problems with the GCC compilers:

amalgamation/../src/common/io.cc:120:27: error: ‘POSIX_FADV_SEQUENTIAL’
was not declared in this scope
    posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL);

amalgamation/../src/common/io.cc:120:48: error: ‘posix_fadvise’ was not
declared in this scope
    posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL);

As 'Writing R Extensions' told you, you need to use configure to test
for the presence of non-standard C/C++ functions.  In this case, it
seems that line is not actually necessary.

@ hetong007 Genial . Dígale al Prof. Ripley gracias por tomarse el tiempo para solucionar el problema. Seguiré adelante y protegeré esa línea para que solo se ejecute en el entorno Linux adecuado, ya que solo tenemos las instalaciones de prueba adecuadas para probar XGBoost con Windows y Linux. Idealmente, no se deben utilizar las instalaciones de C++ no estándar a menos que se prueben primero como parte de CI. También tendré que escanear el código base en busca de otras funciones de C++ no estándar e intentar eliminarlas también. cc @trivialfis

@hcho3 suena bien para mí. La fecha límite del Prof. Ripley para una nueva presentación a CRAN es 2020-04-06. Si está interesado en el registro de instalación detallado, visite https://cran.r-project.org/web/checks/check_results_xgboost.html

@ hetong007 La confirmación https://github.com/dmlc/xgboost/commit/d83db4844bae5969609e58cd6bb201e7831cfaa3 debería abordar el problema. Finalmente logré que la versión R más reciente funcionara con mi máquina virtual Solaris y ejecuté comprobaciones CRAN para XGBoost.

@hcho3 ¡Genial! ¿Puedo tomarlo como lo ha hecho pasar el control de Solaris?

Sí, deberíamos enviarlo ahora.

Hola, me enfrento a problemas similares con Python. Guardé el modelo a través de xgboost 1.0.1 y lo cargué a través de xgboost 0.9, y las predicciones son listas vacías. Dado que nuestro entorno de producción usa xgboost 0.9, me pregunto si hay alguna forma de cargar un modelo guardado a través de xgboost-1.0 en xgboost 0.9.

@hcho3 ¿Hay alguna manera de compartir su instantánea? También es valioso para nuestra presentación posterior.

@sunhs También estoy enfrentando un problema similar. ¿Pudiste resolver esto?

@giladmaya No, hombre. Después de probar varios métodos, finalmente decidí que volver a entrenar al modelo me ahorró tiempo.

Cerrando esto, ya que no podemos prometer que los modelos de versiones más nuevas sean compatibles con versiones anteriores. Es como comprar una PlayStation 4 e intentar cargar un juego desarrollado para PlayStation 5.

Solo prometemos compatibilidad con versiones anteriores, por lo que puede guardar modelos usando la versión anterior y volver a cargarlos usando una nueva versión. Esto es para que el formato del modelo pueda evolucionar gradualmente con el tiempo.