Xgboost: Modelo produzido em 1.0.0 não pode ser carregado em 0.90

Você tentou install.packages('xgboost') ?

Você tentou install.packages('xgboost') ?

Isso funciona muito bem, mas todas as previsões de modelos salvos (usando saveRDS) produzem numeric(0). Parece que os modelos treinados usando openMP não funcionam em computadores sem essa estrutura. Minha esperança era que a compilação da fonte resolvesse isso.

É assim que você compila o XGBoost da fonte:

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

Você pode compartilhar o arquivo de modelo para que possamos tentar descobrir por que você está obtendo um 0 para previsão?

Obrigado - você quer o objeto R ou prefere que ele seja convertido via xgb.save.raw?

Ambos

Obrigado por sua ajuda e apoio (e por fazer um programa de aprendizado tão extraordinário).

Em anexo está um arquivo .rdata compactado. Em 3 sistemas (Mac, MacBook, Ubuntu), posso executar o seguinte 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"]))

E obtenha a seguinte saída:

> 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

No sistema 4 (windows base R com xgboost instalado do CRAN), recebo resultados muito 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)

Suspeito que isso possa precisar de um novo problema aberto, mas agradeço qualquer orientação que você possa fornecer sobre por que o mesmo código se comportaria de maneira diferente em sistemas diferentes.

Por fim, o xgbRaw está incluído (deve ser chamado se você usar attach()), ele foi gerado com o seguinte código:

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

Agradeço novamente.

modelList.rdata.zip

Provavelmente devido à nossa proteção dmlc contra a exceção omp?

@leedrake5 Sua máquina não suporta OpenMP?

@hcho3 Você encontrou a causa? Acabei de compilar o XGBoost sem OpenMP (com alguns patches para CMakeLists), os testes de memória externa estão falhando conforme o esperado, também o teste de grupo paralelo está falhando (o que consertei no branch local). Mas até agora eu posso obter valores de previsão perfeitos.

@hcho3 Minha máquina suporta openmp. Mas estamos implantando esses modelos em escala industrial, e muitos computadores em locais específicos não têm openmp. Acabamos de descobrir isso após 6 meses de preparação e uma semana até a implementação, então estamos lutando para descobrir por que os modelos funcionam em alguns computadores e não em outros.

Se houver alguma filosofia sobre por que os modelos devem funcionar apenas em seu ambiente de construção, haveria alguma maneira de obter um erro informativo sobre o porquê?

@leedrake5 É um bug. Eu tenho tentado reproduzi-lo no Ubuntu com o openmp desativado, mas até agora sem sorte.

@trivialfs Se ajudar, eu e a maioria dos meus colegas estamos enfrentando o bug no Windows. Embora um colega meu tenha conseguido reproduzi-lo no Ubuntu sem o openmp.

Suspeito que uma instalação mínima do R sem coisas extravagantes (openmp, intelmkl, openblas, etc.) possa reproduzi-lo, mas ainda estou pensando em qual parte do sistema está causando problemas.

@leedrake5 Se houver uma maneira de reproduzi-lo em distribuições Linux, seria de grande ajuda!

Desativei todas as opções inclusive google test, omp... Mas ainda tenho o resultado correto carregando seus modelos. A instalação do R é a distribuição padrão de apt , acho que não tem nada a ver com a previsão do XGBoost.

Pode não ser causado pelo OpenMP. Como até a previsão dá muito errado, ainda há um viés global, não 0.

A única razão em que consigo pensar é que o XGBoost não está realmente sendo instalado. Acho que fazemos testes no CRAN certo? @hcho3

Eu tentei a compilação do CMake e a compilação do autotools. Estes são meus sinalizadores de compilação relatados por install.packages(...) (autotools build):

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 Ainda mais curioso, pois o XGBoost é instalado com sucesso a partir do CRAN e a biblioteca (xgboost) funciona sem nenhum problema.

Embora um colega meu tenha conseguido reproduzi-lo no Ubuntu sem o openmp.

É possível que ele/ela possa gentilmente compartilhar como se reproduzir?

Embora um colega meu tenha conseguido reproduzi-lo no Ubuntu sem o openmp.

É possível que ele/ela possa gentilmente compartilhar como se reproduzir?

Não tenho certeza se eles sabem o suficiente sobre como os sistemas linux funcionam - mas se você souber de algum diagnóstico que eles possam fornecer, avise-me.

De minha parte, estou tentando criar uma instalação do ubuntu de caixa virtual que possa replicar o problema - se for bem-sucedido, enviarei um link de download para isso.

Reproduzi com sucesso o problema no linux - veja a captura de tela anexada.

Estou enviando a caixa virtual para o dropbox. Mas caso você prefira instalar do zero, as instruções para replicar são as seguintes:

1. Baixe e instale o virtualbox
2. Baixe uma compilação do ubuntu bionic beaver (usei ubuntu-18.04.3-desktop-amd64).
3. Siga as instruções aqui: https://medium.com/@mannycodes/installing -ubuntu-18-04-on-mac-os-with-virtualbox-ac3b39678602. Eu usei uma unidade virtual fixa de 15 gigabytes
4. Configure para R 3.6.2 com o seguinte:

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 pacotes em R

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

1. carregar pacotes em R

library(caret)
library(xgboost)

1. Carregar os dados

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

1. Tente prever

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

E isso retornou o agora familiar:

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

nota: eu tentei bibliotecas de chamadas explícitas e apenas tentei a previsão. Ambos resultaram na mesma resposta numérica(0).

O link para a instância virtual compactada 7z está aqui: https://www.dropbox.com/s/ld06zz798m0segf/UbuntuDebug.7z?dl=0

Deixe-me pegar a caixa virtual primeiro. Eu costumo usar KVM.

Olhando para isso agora.

@leedrake5 Consegui reproduzir o problema na máquina virtual que você forneceu. Parece que há um problema com saveRDS e xgb.save.raw . Você tentou usar xgb.save e xgb.load ? Esse conjunto de funções usa o formato "nativo" do modelo XGBoost e não salva atributos específicos do ambiente R. É útil se você deseja transferir seu modelo de um pacote R para o Python.

O save raw não deve ser um problema. O problema pode estar em como R serializar o código R. Adicionamos um novo parâmetro opcional para prever, o que pode afetar o carregamento desses tipos de serialização. Eu tentei investigar, mas parece muito peculiar, assim como o problema com o picles do Python.

@trivialfis alguma ideia sobre opções na função de previsão que poderiam contornar isso? Meu pensamento é que tem algo a ver com instruções da CPU, possivelmente mais profundas em R do que podem ser abordadas pelo pacote.

@hcho3 Vou tentar adicionar xgb.save.raw ao canal de dados atual e ver se isso ajuda. Embora no exemplo que enviei, eu tentei isso usando xgb.save.raw no computador onde as previsões funcionaram e, infelizmente, ainda levou a numeric(0) em xgb.load. É certo que isso foi depois que o modelo já havia sido salvo via saveRDS, talvez algo nesse processo o corrompa, mesmo que ainda funcione no ambiente em que foi criado.

Até onde eu sei, ainda há algo sobre o ambiente onde o modelo foi criado que precisa estar presente em todos os ambientes em que é usado. Eu não sei o que é embora.

Não, eu quis dizer xgb.save , não xgb.save.raw .

@trivialfis Observe que o pacote XGBoost ainda é 0,90 no CRAN.

Eu tentei xgb.save, carreguei em R via xgb.load(), e a mesma coisa, numeric(0). Veja anexo de xgb.save

xgbModelSaved.xgb.zip

Também testei o mesmo método usando os dados em modelList anteriormente neste tópico no mesmo computador que gerou o modelo - funcionou lá.

Não importa como você o divide, xgb.save, xgb.save.raw, saveRDS, etc., há algo sobre o ambiente de computador no qual o modelo foi criado que impede seu uso em outro lugar.

Eu sou capaz de reproduzir o problema usando o arquivo de modelo que você forneceu. No entanto, não tenho idéia de como o arquivo de modelo foi gerado. Você pode fornecer mais contexto, por exemplo

• SO
• Versão do XGBoost
• Comando para salvar o modelo

OS X (Catalina). XGBoost build from source, 1.0 (openMP suportado no sistema). Modelo originalmente salvo usando saveRDS. Vou tentar executá-lo novamente e salvar de maneiras diferentes e retornarei.

Regenerei um modelo do zero, salvei-o usando xgb.save (por exemplo, sem uso de saveRDS ou readRDS, exceto para dados de previsão) e carreguei usando xgb.load. Mesmos resultados - a previsão funciona no sistema de computador usado para gerar o modelo (OS X, XGB 1.0) e falha em outro sistema (Windows 7, XGB 0.9). Anexando-o e o modelList a esta mensagem. Se houver mais alguma coisa que eu possa fazer para ajudar a diagnosticar esse problema, por favor me avise.

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)

newxgbModelSaved.xgb.zip

modelList2.rdata.zip

@leedrake5 É possível usar o XGBoost 1.0 no Windows?

@trivialfis Isso pode ser um problema com a compatibilidade com versões anteriores dos arquivos de modelo.

É definitivamente versionamento. Acabei de baixar a versão 1.0 do XGBoost, instalei a 0.9 do CRAN e o método descrito acima funcionou.

Tentei instalar o 0.90 da fonte usando a versão mais recente , mas a pasta dmlc-core está vazia, então o Cmake lança o erro necessário. Gostaria muito de manter a funcionalidade do openMP no entanto.

Eu vejo. Você tentou instalar a versão 1.0.0 no Windows?

Essa foi a razão inicial para este tópico, curiosamente. Vou tentar, mas haverá um atraso, pois o projeto não pode esperar mais. Se isso for um problema, suspeito que instalar o 1.0 da fonte na imagem virtual do Ubuntu que enviei resolveria a mesma coisa.

@leedrake5 Sim, você deve corresponder à versão do XGBoost. Use 0,90 em todos os lugares ou 1,0,0 em todos os lugares.

@trivialfis Lembro-me de que fizemos uma mudança radical no formato do modelo binário. Isso está certo?

Não, somos compatíveis com versões anteriores, 1.0 deve definitivamente carregar o modelo de 0.9

@trivialfis Obrigado pelo esclarecimento. Nesse caso, vamos tratar este ticket como um bug, já que esperávamos compatibilidade com versões anteriores e encontramos um contra-exemplo. Vou olhar isso esta semana.

Eu acho que a mudança de título proposta é invertida - o modelo produzido em 1.0 não pode ser usado para prever em 0.90. Não sei qual o grau de compatibilidade pretendido entre as versões, mas no mínimo um erro informativo deve ajudar.

Opa, foi mal.

@trivialfis Acredito que o que @leedrake5 está pedindo é compatibilidade com versões anteriores, ou seja, carregar o modelo de 1.0.0 para 0.90. Não tenho certeza se é isso que prometemos.

@leedrake5 Tentei instalar o 1.0.0 na máquina virtual do Ubuntu e agora o arquivo RDS carrega bem e recebo um vetor de números reais. Então, provavelmente é o problema da versão.

EDITAR. A mensagem de aviso na captura de tela é estranha: Loading model from < 1.0.0, consider saving it again . Isso não deveria estar aqui, já que o modelo foi produzido por 1.0.0.

Eu concordo. Muito feliz em definir a convergência sobre qual é o problema.

Infelizmente, do ponto de vista da produção, tenho que fazer modelos implantáveis ​​na versão em massa (portanto, instalação do CRAN). Mas, eu sei como fazer o XGBoost funcionar daqui em diante, que é o ponto crítico absoluto.

Ainda estou tendo problemas para instalar o 0.9 da fonte baixada dos lançamentos ou da árvore, mas acho que encontrei o problema. cub, dmlc-core, rabit, todos são pastas vazias nesses downloads. Eles também tem @após as pastas - acho que está relacionado a quais pastas estão vazias. Se eu seguir esses links, posso reconstruir as pastas e continuar a instalação.

Veja captura de tela:

Sim, usamos submódulos git, então a instrução de compilação pede que você use git clone --recursive para instalar a partir da fonte. Você está em uma situação em que a instalação do CRAN é inadequada? Se o uso de 0,90 em todos os lugares resolver seu problema, você poderá usar a instalação do CRAN em todos os lugares (Linux, Mac, Windows)?

Sim - CRAN não permite openMP, que para geração de modelo é uma grande vantagem. Então, passará algum tempo descobrindo como compilar o xgboost 0.90 da fonte para fazê-lo funcionar novamente. Agradeço toda a sua ajuda para diagnosticar este problema.

@leedrake5

Entendi. Por enquanto, aqui está o comando que você pode usar para obter o código-fonte completo, incluindo os submódulos git:

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

Isso deve buscar o código-fonte do XGBoost e preencher os diretórios rabit, cub, dmlc-core. -b release_0.90 é usado para obter a versão 0.90, não a mais recente.

Aparte:

CRAN não permite openMP

Isso é realmente corrigido em 1.0.0. Vou tentar obter a versão 1.0.0 no CRAN em breve.

Obrigado, muito apreciado em todos os aspectos!

@hetong007 Podemos enviar 1.0.0 ao CRAN?

@hcho3 Parece bom, já que temos uma detecção endian válida. Eu vou fazer uma apresentação em uma semana.

@hetong007 Alguma atualização? Deixe-me saber se eu puder ajudar de alguma forma.

@hcho3 oh sim. Eu gostaria de perguntar se temos o ambiente para testes de solaris? Há um erro não resolvido no solaris de 0.9: https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/xgboost-00check.html Eu gostaria de verificá-lo antes do submissão.

@hetong007 Acabei de baixar a imagem Solaris VM do Oracle que pode ser executada com o VirtualBox. Deixe-me tentar reproduzir o problema.

@hetong007 Estou tendo muitos problemas para configurar o ambiente R no Solaris. Em particular, não posso instalar pacotes R como igraph e testthat porque utilitários como awk se comportam de maneira diferente no Solaris. Não faço ideia de como prosseguir.

@hcho3 Você poderia ser mais claro? Imagino que alguém possa instalar pacotes no console R com install.packages('testthat') , dado que testthat passou na verificação do solaris no CRAN.

@hetong007 O pacote igraph usa awk na etapa de configuração, e o awk do Solaris não é compatível com o GNU awk. É possível instalar o GNU awk, mas chama-se gawk . Ainda tentando descobrir como fazer R usar gawk em vez de awk .

@hcho3 OK, isso parece horrível. Também não tenho conhecimento de como proceder. Acabei de dar uma olhada na página de resultados de igraph no CRAN: https://cran.r-project.org/web/checks/check_results_igraph.html. Sente que não vamos ser piores. Eu vou fazer uma apresentação de qualquer maneira.

@hetong007 Obrigado. Tentarei voltar aos testes do Solaris em algum momento. Tenho certeza que há um jeito.

@hetong007 Ah sim, certifique-se de usar o branch release_1.0.0 ao enviar o código.

@hcho3 A pré-verificação avisa:

* 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.

e o arquivo 00install.out está aqui (disponível em ~72 horas): https://win-builder.r-project.org/v6XJQBjzgMaW/00install.out

Seria possível uma solução rápida?

@hetong007 Isso é um bloqueador? Memset foi usado para acelerar a zeragem do histograma (matriz de estrutura). Se isso estiver bloqueando o CRAN, colocarei um guarda de macro para que o pacote R use o construtor comum.

@hcho3 Sim, é um bloqueador. A pré-verificação é automatizada e a submissão deve passar sem aviso prévio. A macro parece boa o suficiente, obrigado!

@hcho3 Você poderia tentar usar std::fill primeiro? Mesmo o compilador pode não ser capaz de otimizá-lo em memset , não acho que seja crítico o suficiente para ter qualquer impacto visível no desempenho.

@hetong007 Fiz a alteração necessária (https://github.com/dmlc/xgboost/commit/3550b16a34055bc8ec33bf0b7006448e8c1a4eca). Você pode tentar novamente?

@trivialfis Vou arquivar uma solicitação de pull separada para substituir memset .

@hcho3 obrigado pela correção! Se nada de grave der errado, está a caminho do CRAN.

@hcho3 Então falha no Soalris, do 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 Legal. Por favor, agradeça ao Prof. Ripley por ter tempo para depurar o problema. Vou seguir em frente e proteger essa linha para rodar apenas no ambiente Linux adequado, já que só temos instalações de teste adequadas para testar o XGBoost com Windows e Linux. Idealmente, quaisquer recursos C++ não padrão não devem ser usados, a menos que sejam testados primeiro como parte do CI. Também terei que verificar a base de código em busca de outros recursos C++ não padrão e tentar removê-los também. cc @trivialfis

@hcho3 parece bom para mim. O prazo do Prof. Ripley para uma nova submissão ao CRAN é 2020-04-06. Se você estiver interessado no log de instalação detalhado, visite https://cran.r-project.org/web/checks/check_results_xgboost.html

@hetong007 O commit https://github.com/dmlc/xgboost/commit/d83db4844bae5969609e58cd6bb201e7831cfaa3 deve resolver o problema. Finalmente consegui fazer com que o R mais recente funcionasse com minha VM Solaris e executei verificações de CRAN para XGBoost.

@hcho3 Brilhante! Posso levá-lo como você o fez passar na verificação do Solaris?

Sim, devemos enviar agora.

Oi, estou enfrentando problemas semelhantes com Python. Salvei o modelo via xgboost 1.0.1 e carreguei-o via xgboost 0.9, e as previsões são listas vazias. Como nosso ambiente de produção está usando o xgboost 0.9, gostaria de saber se há alguma maneira de carregar um modelo salvo via xgboost-1.0 no xgboost 0.9?

@hcho3 Existe uma maneira de compartilhar seu instantâneo? É valioso para nossa submissão adicional também.

@sunhs também estou enfrentando um problema semelhante. Você conseguiu resolver isso?

@giladmaya Não cara. Depois de tentar vários métodos, finalmente decidi que treinar novamente o modelo economizava meu tempo.

Fechando isso, pois não podemos prometer que modelos de versões mais recentes sejam suportados por versões mais antigas. É como comprar um PlayStation 4 e tentar carregar um jogo desenvolvido para o PlayStation 5.

Prometemos apenas compatibilidade com versões anteriores, para que você possa salvar modelos usando a versão antiga e carregá-lo novamente usando uma nova versão. Isso é para que o formato do modelo possa evoluir gradualmente ao longo do tempo.