Xgboost: Le modèle produit en 1.0.0 ne peut pas être chargé en 0.90

Avez-vous essayé install.packages('xgboost') ?

Avez-vous essayé install.packages('xgboost') ?

Cela fonctionne très bien, mais toutes les prédictions des modèles enregistrés (à l'aide de saveRDS) produisent numeric(0). Il semble que les modèles formés à l'aide d'openMP ne fonctionnent pas sur des ordinateurs sans ce framework. J'espérais que la compilation à partir des sources résoudrait ce problème.

Voici comment vous compilez XGBoost à partir de la source :

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

Pouvez-vous partager le fichier de modèle afin que nous puissions essayer de trouver pourquoi vous obtenez un 0 pour la prédiction ?

Merci - voulez-vous l'objet R ou préférez-vous qu'il soit converti via xgb.save.raw ?

Les deux

Merci pour votre aide et votre soutien (et d'avoir créé un programme d'apprentissage aussi extraordinaire).

Vous trouverez ci-joint un fichier .rdata compressé. Sur 3 systèmes (Mac, MacBook, Ubuntu), je peux exécuter le code suivant :

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"]))

Et obtenez la sortie suivante :

> 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

Sur le système 4 (Windows base R avec xgboost installé à partir de CRAN), j'obtiens des résultats très différents :

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

Je soupçonne que cela peut nécessiter l'ouverture d'un nouveau problème, mais j'apprécie tous les conseils que vous pouvez donner pour savoir pourquoi le même code se comporterait différemment sur différents systèmes.

Enfin, xgbRaw est inclus (devrait être appelable si vous utilisez attach()), il a été généré avec le code suivant :

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

Merci une fois de plus.

modelList.rdata.zip

Probablement en raison de notre garde dmlc contre l'exception omp?

@leedrake5 Votre machine ne prend-elle pas en charge OpenMP ?

@hcho3 Avez-vous trouvé la cause ? Je viens de compiler XGBoost sans OpenMP (avec quelques correctifs pour CMakeLists), les tests de mémoire externe échouent comme prévu, ainsi que le test de groupe parallèle hist échoue (que j'ai corrigé dans la branche locale). Mais jusqu'à présent, je peux obtenir des valeurs de prédiction parfaites.

@ hcho3 Ma machine prend en charge openmp. Mais nous déployons ces modèles à l'échelle industrielle, et de nombreux ordinateurs sur des sites spécifiques n'ont pas openmp. Nous venons de découvrir cela après 6 mois de préparation et une semaine jusqu'à la mise en œuvre, nous nous efforçons donc de comprendre pourquoi les modèles fonctionnent sur certains ordinateurs et pas sur d'autres.

S'il existe une philosophie sur la raison pour laquelle les modèles ne devraient fonctionner que sur leur environnement de construction, y aurait-il un moyen d'obtenir une erreur informative sur la raison ?

@ leedrake5 C'est un bug. J'ai essayé de le reproduire sur Ubuntu avec openmp désactivé mais jusqu'à présent, pas de chance.

@trivialfs Si cela aide, moi et la plupart de mes collègues rencontrons le bogue sous Windows. Bien qu'un de mes collègues ait pu le reproduire sur Ubuntu sans openmp.

Je soupçonne qu'une installation minimale de R sans éléments sophistiqués (openmp, intelmkl, openblas, etc.) peut le reproduire, mais je suis toujours en train de comprendre quelle partie du système cause des problèmes.

@ leedrake5 S'il existe un moyen de le reproduire sur les distributions Linux, ce serait d'une grande aide!

J'ai désactivé toutes les options, y compris google test, omp ... Mais j'ai toujours le résultat correct en chargeant vos modèles. L'installation de R est la distribution par défaut de apt , je ne pense pas que cela ait quelque chose à voir avec la prédiction XGBoost.

Cela pourrait ne pas être causé par OpenMP. Comme même la prédiction tourne vraiment mal, il y a toujours un biais global, pas 0.

La seule raison à laquelle je peux penser est que XGBoost n'est pas réellement installé. Je pense que nous effectuons des tests sur CRAN, n'est-ce pas ? @hcho3

J'ai essayé à la fois CMake build et autotools build. Voici mes drapeaux de compilation rapportés par install.packages(...) (build 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 Encore plus curieux, car XGBoost s'installe avec succès à partir du CRAN et la bibliothèque (xgboost) fonctionne sans aucun problème.

Bien qu'un de mes collègues ait pu le reproduire sur Ubuntu sans openmp.

Est-il possible qu'il/elle puisse gentiment partager comment se reproduire ?

Bien qu'un de mes collègues ait pu le reproduire sur Ubuntu sans openmp.

Est-il possible qu'il/elle puisse gentiment partager comment se reproduire ?

Je ne suis pas sûr qu'ils en sachent assez sur le fonctionnement des systèmes Linux - mais si vous connaissez des diagnostics qu'ils peuvent fournir, faites-le moi savoir.

Pour ma part, j'essaie de créer une installation d'ubuntu de boîte virtuelle qui peut reproduire le problème - en cas de succès, j'enverrai un lien de téléchargement pour cela.

J'ai reproduit avec succès le problème sur Linux - voir la capture d'écran ci-jointe.

Je télécharge la boîte virtuelle sur dropbox. Mais au cas où vous préféreriez installer à partir de zéro, les instructions de réplication sont les suivantes :

1. Télécharger et installer virtualbox
2. Téléchargez une version d'ubuntu bionic beaver (j'ai utilisé ubuntu-18.04.3-desktop-amd64).
3. Suivez les instructions ici : https://medium.com/@mannycodes/installing -ubuntu-18-04-on-mac-os-with-virtualbox-ac3b39678602. J'ai utilisé un lecteur virtuel fixe de 15 gigaoctets
4. Configurez pour R 3.6.2 en procédant comme suit :

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. installer des packages dans R

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

1. charger des packages dans R

library(caret)
library(xgboost)

1. Charger les données

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

1. Tenter de prédire

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

Et cela a renvoyé le désormais familier:

[13:00:55] ATTENTION : amalgamation/../src/objective/regression_obj.cu:152 : reg:linear est désormais obsolète au profit de reg:squarederror.
numérique(0)

note: j'ai essayé des bibliothèques d'appel explicites et j'ai juste essayé la prédiction. Les deux ont abouti à la même réponse numérique (0).

Le lien vers l'instance virtuelle compressée 7z est ici : https://www.dropbox.com/s/ld06zz798m0segf/UbuntuDebug.7z?dl=0

Permettez-moi d'abord d'obtenir une boîte virtuelle. J'utilise habituellement KVM.

En regardant cela maintenant.

@ leedrake5 J'ai réussi à reproduire le problème sur la machine virtuelle que vous avez fournie. Il semble qu'il y ait un problème avec saveRDS et xgb.save.raw . Avez-vous essayé d'utiliser xgb.save et xgb.load la place ? Cet ensemble de fonctions utilise le format "natif" du modèle XGBoost et n'enregistre pas les attributs spécifiques à l'environnement R. Il est utile si vous souhaitez transférer votre modèle d'un package R vers Python.

La sauvegarde brute ne devrait pas poser de problème. Le problème pourrait être dans la façon dont R sérialise le code R. Nous avons ajouté un nouveau paramètre facultatif à prédire, qui pourrait affecter le chargement de ces types de sérialisation. J'ai essayé d'y jeter un coup d'œil, mais cela semble vraiment bizarre, tout comme le problème avec Python pickle.

@trivialfis avez-vous des idées sur les options de la fonction de prédiction qui pourraient potentiellement contourner cela ? Je pense que cela a quelque chose à voir avec les instructions du processeur, peut-être plus profondément dans R que ce qui peut être résolu par le package.

@ hcho3 Je vais essayer d'ajouter xgb.save.raw au canal de données actuel et voir si cela aide. Bien que dans l'exemple que j'ai envoyé, j'ai essayé cela en utilisant xgb.save.raw sur l'ordinateur où les prédictions ont fonctionné, et cela conduit malheureusement toujours à numeric(0) sur xgb.load. Certes, c'était après que le modèle ait déjà été enregistré via saveRDS, peut-être que quelque chose à propos de ce processus le corrompt, même s'il fonctionne toujours dans l'environnement dans lequel il a été créé.

Pour autant que je sache, il y a encore quelque chose dans l'environnement dans lequel le modèle a été créé qui doit être présent dans chaque environnement dans lequel il est utilisé. Je ne sais pas ce que c'est cependant.

Non, je voulais dire xgb.save , pas xgb.save.raw .

@trivialfis Notez que le package XGBoost est toujours 0.90 sur CRAN.

J'ai essayé xgb.save, je l'ai chargé dans R via xgb.load(), et la même chose, numeric(0). Voir ci-joint à partir de xgb.save

xgbModelSaved.xgb.zip

Également testé la même méthode en utilisant les données de modelList plus tôt dans ce fil sur le même ordinateur qui a généré le modèle - cela a fonctionné là-bas.

Peu importe comment vous le découpez, xgb.save, xgb.save.raw, saveRDS, etc., il y a quelque chose dans l'environnement informatique sur lequel le modèle a été créé qui empêche son utilisation ailleurs.

Je suis en mesure de reproduire le problème à l'aide du fichier modèle que vous avez fourni. Cependant, je n'ai aucune idée de la façon dont le fichier de modèle a été généré. Pouvez-vous fournir plus de contexte, par exemple

• SE
• Version XGBoost
• Commande pour enregistrer le modèle

OS X (Catalina). XGBoost construit à partir de la source, 1.0 (openMP pris en charge sur le système). Modèle enregistré à l'origine à l'aide de saveRDS. Je vais essayer de le relancer et de sauvegarder de différentes manières et de faire rapport.

J'ai régénéré un modèle à partir de zéro, l'ai enregistré à l'aide de xgb.save (par exemple, aucune utilisation de saveRDS ou readRDS sauf pour les données de prédiction) et chargé à l'aide de xgb.load. Mêmes résultats - la prédiction fonctionne sur le système informatique utilisé pour générer le modèle (OS X, XGB 1.0) et échoue sur un autre système (Windows 7, XGB 0.9). Attachez-le et le modelList à ce message. S'il y a autre chose que je peux faire pour aider à diagnostiquer ce problème, faites-le moi savoir.

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)

nouveauxgbModelSaved.xgb.zip

modelList2.rdata.zip

@leedrake5 Est-il possible d'utiliser XGBoost 1.0 sous Windows ?

@trivialfis Cela peut être un problème de rétrocompatibilité des fichiers de modèle.

C'est certainement du versioning. Je viens de tomber sur la version 1.0 de XGBoost, d'installer la 0.9 de CRAN et la méthode décrite ci-dessus a fonctionné.

J'ai essayé d'installer 0.90 à partir de la source en utilisant la dernière version , mais le dossier dmlc-core est vide, donc Cmake génère l'erreur nécessaire. J'aimerais beaucoup conserver la fonctionnalité openMP, mais cela se passe.

Je vois. Avez-vous essayé d'installer la version 1.0.0 sur Windows ?

C'était la raison initiale de ce fil, assez curieusement. Je vais essayer, mais il y aura un retard car le projet ne peut plus attendre. S'il s'agit d'un problème, je soupçonne que l'installation de la version 1.0 à partir de la source sur l'image virtuelle Ubuntu que j'ai envoyée traiterait la même chose.

@ leedrake5 Oui, vous devez correspondre à la version de XGBoost. Utilisez 0.90 partout ou 1.0.0 partout.

@trivialfis Je me souviens que nous avons apporté une modification radicale au format du modèle binaire. Est-ce correct?

Non, nous sommes rétrocompatibles, 1.0 devrait certainement charger le modèle de 0.9

@trivialfis Merci pour la clarification. Dans ce cas, traitons ce ticket comme un bogue, puisque nous nous attendions à une rétrocompatibilité et avons trouvé un contre-exemple. Je vais regarder ça cette semaine.

Je pense que le changement de titre proposé l'a inversé - le modèle produit en 1.0 ne peut pas être utilisé pour prédire en 0.90. Je ne sais pas quel degré de compatibilité est prévu entre les versions, mais au minimum une erreur informative devrait aider.

Oups, ma faute.

@trivialfis Je crois que ce que @ leedrake5 demande, c'est la compatibilité ascendante, c'est-à-dire le chargement du modèle de 1.0.0 à 0.90. Je ne sais pas si c'est ce que nous promettons.

@ leedrake5 J'ai essayé d'installer 1.0.0 dans la machine virtuelle Ubuntu, et maintenant le fichier RDS se charge correctement et j'obtiens un vecteur de nombres réels. Il s'agit donc très probablement d'un problème de version.

ÉDITER. Le message d'avertissement dans la capture d'écran est étrange : Loading model from < 1.0.0, consider saving it again . Cela ne devrait pas être ici, étant donné que le modèle a été produit par 1.0.0.

Je suis d'accord. Très heureux de mettre la convergence sur ce qu'est le problème.

Malheureusement, du point de vue de la production, je dois rendre les modèles déployables dans la version de masse (par exemple, installation CRAN). Mais, je sais comment faire fonctionner XGBoost à partir de maintenant, ce qui est le point critique absolu.

J'ai toujours des problèmes pour installer la version 0.9 à partir de la source téléchargée à partir des versions ou de l'arborescence, mais je pense avoir trouvé le problème. cub, dmlc-core, rabit, tous sont des dossiers vides dans ces téléchargements. Ils ont aussi @après les dossiers - je pense que cela est lié aux dossiers vides. Si je suis ces liens, je peux reconstruire les dossiers et poursuivre l'installation.

Voir capture d'écran :

Oui, nous utilisons des sous-modules git, donc l'instruction de construction vous demande d'utiliser git clone --recursive pour installer à partir de la source. Êtes-vous dans une situation où l'installation du CRAN est inadéquate ? Si l'utilisation de 0.90 partout résout votre problème, vous pouvez simplement utiliser l'installation CRAN partout (Linux, Mac, Windows) ?

Oui - CRAN n'autorise pas openMP, ce qui pour la génération de modèles est une énorme aubaine. Nous passerons donc un peu de temps à comprendre comment compiler xgboost 0.90 à partir de la source pour que cela fonctionne à nouveau. J'apprécie toute votre aide pour diagnostiquer ce problème.

@leedrake5

J'ai compris. Pour l'instant, voici la commande que vous pouvez utiliser pour obtenir le code source complet, y compris les sous-modules git :

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

Cela devrait récupérer le code source XGBoost et remplir les répertoires rabit, cub, dmlc-core. -b release_0.90 est utilisé pour obtenir la version 0.90, pas la dernière.

De côté:

CRAN n'autorise pas openMP

Ceci est en fait corrigé dans la version 1.0.0. Je vais essayer d'obtenir la version 1.0.0 sur CRAN bientôt.

Merci, très apprécié à tous égards!

@hetong007 Pouvons-nous soumettre 1.0.0 au CRAN ?

@ hcho3 Cela semble bien, étant donné que nous avons une détection endian valide. Je ferai une soumission dans une semaine.

@ hetong007 Des mises à jour ? Faites-moi savoir si je peux aider de quelque manière que ce soit.

@ hcho3 oh oui. Je voudrais demander si nous avons l'environnement pour les tests solaris ? Il y a une erreur non résolue sur solaris à partir de 0.9 : https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/xgboost-00check.html J'aimerais le faire vérifier avant le soumission.

@ hetong007 Je viens de télécharger l'image Solaris VM d'Oracle qui peut fonctionner avec VirtualBox. Essayons de reproduire le problème.

@ hetong007 J'ai beaucoup de mal à configurer l'environnement R dans Solaris. En particulier, je ne peux pas installer de packages R tels que igraph et testthat car des utilitaires tels que awk se comportent différemment sur Solaris. Je n'ai aucune idée de comment procéder plus loin.

@hcho3 Pourriez-vous être plus clair ? J'imagine que l'on pourrait installer des packages dans la console R avec install.packages('testthat') , étant donné que testthat a réussi la vérification solaris sur CRAN.

@ hetong007 Le package igraph utilise awk dans l'étape de configuration, et le awk de Solaris n'est pas compatible avec GNU awk. Il est possible d'installer GNU awk, mais il s'appelle gawk . J'essaie toujours de comprendre comment faire en sorte que R utilise gawk au lieu de awk .

@ hcho3 OK, ça a l'air horrible. Je ne sais pas non plus comment procéder. Je viens de jeter un œil à la page de résultats de igraph sur CRAN : https://cran.r-project.org/web/checks/check_results_igraph.html. Sent que nous n'allons pas être pires. Je vais faire une soumission quoi qu'il en soit.

@ hetong007 Merci. J'essaierai de revenir aux tests Solaris à un moment donné. Je suis sûr qu'il y a un moyen.

@ hetong007 Ah oui, assurez-vous d'utiliser la branche release_1.0.0 lors de la soumission du code.

@hcho3 La pré-vérification avertit :

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

et le fichier 00install.out est ici (disponible dans ~72 heures): https://win-builder.r-project.org/v6XJQBjzgMaW/00install.out

Serait-il possible d'avoir une solution rapide ?

@ hetong007 Est-ce un bloqueur ? Memset a été utilisé pour accélérer la mise à zéro de l'histogramme (tableau de structure). Si cela bloque CRAN, je mettrai une protection de macro afin que le package R utilise à la place un constructeur ordinaire.

@ hcho3 Oui C'est un bloqueur. La pré-vérification est automatisée et la soumission devrait passer sans avertissement. La macro sonne assez bien, merci !

@hcho3 Pourriez-vous d'abord essayer d'utiliser std::fill ? Même le compilateur peut ne pas être en mesure de l'optimiser en memset , je ne pense pas que ce soit suffisamment critique pour avoir un impact visible sur les performances.

@ hetong007 J'ai fait le changement nécessaire (https://github.com/dmlc/xgboost/commit/3550b16a34055bc8ec33bf0b7006448e8c1a4eca). Peux-tu réessayer?

@trivialfis Je déposerai une demande d'extraction distincte pour remplacer memset .

@ hcho3 merci pour le correctif ! Si rien de grave ne va mal, c'est en route pour le CRAN.

@ hcho3 Donc, ça échoue sur Soalris, du professeur 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 Sympa. Veuillez dire au professeur Ripley merci d'avoir pris le temps de déboguer le problème. Je vais continuer et garder cette ligne pour ne fonctionner que dans un environnement Linux approprié, car nous ne disposons que d'une installation de test appropriée pour tester XGBoost avec Windows et Linux. Idéalement, toutes les fonctionnalités C++ non standard ne doivent pas être utilisées à moins qu'elles ne soient d'abord testées dans le cadre de CI. Je devrai également analyser la base de code pour d'autres fonctionnalités C++ non standard et essayer de les supprimer également. cc @trivialfis

@hcho3 me semble bien. La date limite du professeur Ripley pour une nouvelle soumission au CRAN est le 2020-04-06. Si vous êtes intéressé par le journal d'installation détaillé, veuillez visiter https://cran.r-project.org/web/checks/check_results_xgboost.html

@ hetong007 Le commit https://github.com/dmlc/xgboost/commit/d83db4844bae5969609e58cd6bb201e7831cfaa3 devrait résoudre le problème. J'ai finalement réussi à faire fonctionner le dernier R avec ma machine virtuelle Solaris et à exécuter des vérifications CRAN pour XGBoost.

@hcho3 Génial ! Puis-je le prendre comme vous l'avez fait passer le contrôle sur Solaris ?

Oui, nous devrions le soumettre maintenant.

Bonjour, je suis confronté à des problèmes similaires avec Python. J'ai enregistré le modèle via xgboost 1.0.1 et l'ai chargé via xgboost 0.9, et les prédictions sont des listes vides. Étant donné que notre environnement de production utilise xgboost 0.9, je me demande s'il est possible de charger un modèle enregistré via xgboost-1.0 dans xgboost 0.9 ?

@hcho3 Existe-t-il un moyen de partager votre instantané ? Il est également précieux pour notre future soumission.

@sunhs Je suis également confronté à un problème similaire. Avez-vous pu résoudre ce problème ?

@giladmaya Non mec. Après avoir essayé plusieurs méthodes, j'ai finalement décidé que le recyclage du modèle me faisait gagner du temps.

En fermant ceci, car nous ne pouvons pas promettre que les modèles des versions plus récentes seraient pris en charge par les versions plus anciennes. C'est comme acheter une PlayStation 4 et essayer de charger un jeu développé pour PlayStation 5.

Nous ne promettons qu'une rétrocompatibilité, vous pouvez donc enregistrer des modèles en utilisant l'ancienne version et les recharger en utilisant une nouvelle version. Ceci afin que le format du modèle puisse évoluer progressivement dans le temps.