xgboost en R : pourquoi le patch Python ne doit pas rassurer sur le reste

À la une

xgboost : un calendrier de releases piloté par Python, pas par R

Depuis plusieurs versions, les releases successives de xgboost se concentrent presque exclusivement sur l'écosystème Python : compatibilité avec une nouvelle version de l'interpréteur, corrections dans le binding JVM, ajustements sur des structures de données spécifiques à scikit-learn. Le binding R, lui, n'apparaît quasiment jamais dans les changelogs. Ce n'est pas un hasard : xgboost est un projet C++ dont R, Python et JVM sont des interfaces, et la priorité de maintenance va naturellement là où se trouve la masse des utilisateurs et des problèmes remontés.

Pour une équipe data qui fait tourner des modèles xgboost en production depuis R, ce déséquilibre a des conséquences concrètes. Un correctif de sécurité ou de performance côté Python peut sortir plusieurs semaines avant d'être reflété dans le package R sur CRAN, ou ne jamais y apparaître si le bug touche uniquement le binding Python. À l'inverse, une montée de version majeure du cœur C++ peut casser silencieusement des comportements numériques côté R si les tests de non-régression n'ont pas été pensés pour couvrir le binding R spécifiquement.

Concrètement, aujourd'hui, le bon réflexe n'est pas de suivre les releases GitHub comme un fil d'actualité, mais de fixer une version de xgboost dans ses environnements de production (via renv ou un lockfile équivalent) et de ne la faire évoluer qu'après un test de régression sur ses propres métriques : AUC, log-loss, temps d'entraînement, taille du modèle sérialisé. Un modèle xgboost entraîné avec une version et rechargé avec une autre peut se comporter différemment, en particulier si les paramètres par défaut d'un hyperparamètre ont changé entre deux versions majeures.

La bonne pratique minimale consiste à versionner le modèle et les métadonnées d'entraînement ensemble, pas seulement les poids. Un objet xgb.Booster sauvegardé sans la version de la librairie, les paramètres d'entraînement et un jeu de validation de référence est un objet qu'on ne peut plus auditer dans six mois. C'est exactement le problème que des outils comme vetiver adressent, mais encore faut-il l'avoir anticipé en amont.

La limite de cet exercice est qu'on ne peut pas tout tester à chaque patch mineur : le coût d'une revalidation complète sur un modèle de production est réel. L'arbitrage raisonnable est de revalider à chaque montée de version mineure ou majeure (3.3 vers 3.4, par exemple), et de laisser passer les patchs de compatibilité pure (support Python 3.11) sans y toucher si rien dans le changelog ne concerne le moteur de calcul lui-même.

CODE R

library(xgboost)

set.seed(1)
n <- 500
x <- matrix(rnorm(n * 5), ncol = 5)
y <- as.numeric(x[, 1] + x[, 2] > 0)

dtrain <- xgb.DMatrix(data = x, label = y)

params <- list(objective = "binary:logistic", max_depth = 3, eta = 0.1)
model <- xgb.train(params = params, data = dtrain, nrounds = 50)

# on fige les métadonnées essentielles a cote du modele
meta <- list(
  xgboost_version = as.character(packageVersion("xgboost")),
  r_version = R.version.string,
  params = params,
  train_date = Sys.Date(),
  n_obs = n
)

xgb.save(model, "modele_prod.model")
saveRDS(meta, "modele_prod_meta.rds")

# a chaque montee de version : recharger et comparer les predictions
pred_ref <- predict(model, dtrain)
meta_check <- readRDS("modele_prod_meta.rds")
stopifnot(identical(meta_check$params, params))

Le code montre comment accompagner un modèle xgboost de ses métadonnées de version et de paramètres, condition minimale pour auditer un modèle en production après une montée de version.

Notre avis

xgboost reste un moteur d'entraînement excellent en R, mais son rythme de maintenance est désormais piloté par Python ; les équipes qui l'utilisent en production doivent se doter de leur propre discipline de versioning, sans compter sur l'écosystème pour le faire à leur place.

→ Pour qui : Data scientists et ingénieurs ML qui déploient des modèles xgboost en production depuis R.

LES BRÈVES

torch passe à l'indexation façon R

La mise à jour de torch aligne enfin l'indexation des tenseurs sur la convention R (base 1) pour plusieurs fonctions, au lieu de l'habituel héritage Python. Un détail qui évite des erreurs silencieuses dans les pipelines de deep learning écrits en R pur.

Source : github.com ↗

DATA

DuckDB resserre sa traduction dbplyr

Le binding R de DuckDB remplace certaines conversions de type strictes par des conversions tolérantes dans la traduction SQL de dplyr, ce qui réduit les erreurs de requêtes sur des colonnes au typage incertain. Utile pour les pipelines analytiques qui enchaînent des jointures entre sources hétérogènes.

Source : github.com ↗

OUTILS

processx muscle la gestion des sous-processus

processx gagne des pipelines de processus au niveau système et une meilleure gestion de la terminaison des processus enfants sous Linux. Pour les apps Shiny ou les scripts qui orchestrent des commandes externes, c'est moins de processus zombies à traquer en production.

Source : tidyverse.org ↗

LE TIP R DU JOUR

Retrouver un objet par son nom sans le charger dans l'environnement global

La fonction get0 permet de récupérer un objet par son nom de façon sûre, en renvoyant une valeur par défaut s'il n'existe pas, sans déclencher d'erreur comme get.

CODE R

x_existe <- get0("mon_objet", ifnotfound = NA)
print(x_existe)

SOURCES

VOUS CODEZ EN R ?

Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.

Parlons-en →

← Tout R Underground