xgboost: Predict error in R as of 1.1.1
R version: 3.6.1 (Action of the Toes) xgboost version: 1.1.1.1
This error can be produced when attempting to call predict on an xgboost model developed pre-1.0
Error:
Error in predict.xgb.Booster(model, data) : [11:24:23] amalgamation/../src/learner.cc:506: Check failed: mparam_.num_feature != 0 (0 vs. 0) : 0 feature is supplied. Are you using raw Booster interface?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 4
- Comments: 103 (18 by maintainers)
@jrausch12 @shapenaji @jrwishart @jameslamb @meztez @mpquast @euklid321 @leedrake5 The 1.2.0 version of XGBoost is now available on CRAN: https://cran.r-project.org/web/packages/xgboost/index.html. It is now able to read models from old RDS files. The manual also has a guidance for future-proofing your models: https://www.rdocumentation.org/packages/xgboost/versions/1.2.0.1/topics/a-compatibility-note-for-saveRDS-save
What I ended up doing to convert the model and keep meta data
then update handle in API or before using
For package use, I use an onLoad function to restore handle on package load and I store models in a
new.env(). zzz.Rin package code
You can’t modify data that comes from the package directly, so this work around work for us.
@leedrake5 were some of those models saved with R version 3.6.x? I see you’re now using 4.0.1.
.rdsfiles are not guaranteed to be compatible across major versions of R@jrausch12 @shapenaji @jrwishart @jameslamb @meztez @mpquast @euklid321 @leedrake5 Hello everyone, today I had a Eureka moment and found a way to make old RDS files readable again in latest XGBoost: #5940. This pull requests add a compatibility layer to read XGBoost models from old RDS files.
Example: Suppose we have a RDS file that saved a XGBoost model from XGBoost 1.0.0 or 0.90:
With the patch fix from #5940, the latest XGBoost will be able to read the model from the RDS file:
Output:
@shapenaji
Here you need xgb.Booster.complete: (supposing model is your object from caret)
aux_model <- model$finalModelaux_model <- xgb.Booster.complete(aux_model, saveraw = TRUE)Then proceed with the load.R/save.R using this aux_model. But be aware that you´ll be working with an xgboost object, not a caret object. At the end, if you want to come back to caret, you´ll have to do something like (using the bst2 object created in load.R):
model$finalModel$handle <- bst2$handlemodel$finalModel$raw <- raw.vec.loadedI didn´t test the final line (saving as JSON).
@jrwishart The workaround seems reasonable for this moment. However, it is not future-proof.
I respectfully ask you to reconsider. The workaround may stop working at any moment in future releases of XGBoost. We (**) are unable to provide any support whatsoever when the same issue arises again with
saveRDS(). Also, some significant features we (**) are planning will be depending on the JSON serialization format (*). You should ask yourself how important it is for your users to retain access to latest versions of XGBoost. If latest access is important, you should plan a switch to the recommended way of serializing XGBoost models.(*) For example, fitting binary splits with categorical features without one-hot encoding. (**) XGBoost developers. See the list here.
Full example of saving a model from 0.90 and loading it back in 1.1.0 (note the use of
xgb.save.rawandxgb.load.raw):save.R
load.R
I tested it as follows:
Here is a working example for writing JSON:
The feature is quite new, however, so it won’t work with XGBoost version older than 1.1.
The reference manual should be updated to mention this feature.
EDIT. Add example of running prediction after loading.
Looking at the documentation for
saveRDS(), it looks like therefhookparameter might offer the type of customization you want.I have no experience with that, but it might be helpful for taking references and resolving them so you can write enough information into the
.rdsobject.In my humble opinion, it would be enough to say “we support
xgb.load()andxgb.save()for serializing and deserializing model objects.readRDS()/writeRDS()are not supported and might cause issues”.