CatBoost vs XGBoost : lequel choisir pour des données tabulaires, et ce qui compte vraiment

Si vos données tiennent dans des tableaux (clients, transactions, mesures de capteurs, analyses de laboratoire), les arbres de gradient boosting sont en général le premier modèle à essayer. Et tôt ou tard, la question arrive : CatBoost ou XGBoost ?

J'ai utilisé les deux sur de vrais projets, dont un système de classification géologique où nous les avons comparés côte à côte. Ma réponse honnête : les deux sont excellents, les différences existent mais sont plus petites qu'on ne le croit, et la façon dont vous validez votre modèle compte bien plus que la librairie choisie.

CatBoost vs XGBoost : la version courte

• Prenez CatBoost si vous avez beaucoup de colonnes catégorielles (type de produit, région, segment client, identifiant de capteur) et que vous voulez de bons résultats avec peu de réglages.
• Prenez XGBoost si vos variables sont surtout numériques, si vous voulez un contrôle fin sur les arbres, ou si vous avez besoin de l'écosystème et des options de déploiement les plus larges.
• Essayez les deux quand le modèle compte. Ça ne coûte pas cher.

Les variables catégorielles : la plus grosse différence pratique

C'est là que CatBoost mérite son nom. Vous pouvez lui donner directement les colonnes catégorielles, et il les encode en interne avec des statistiques sur la cible calculées de façon ordonnée : l'encodage de chaque ligne n'utilise que les lignes placées « avant » elle dans une permutation aléatoire. Cela limite la fuite de la cible qu'on obtient en remplaçant naïvement une catégorie par la moyenne de son label.

XGBoost demande traditionnellement d'encoder les catégories soi-même : one-hot, codes ordinaux ou target encoding. Les versions récentes ont ajouté une prise en charge native des catégories, mais il faut l'activer et utiliser les bons types de données, et elle ne fonctionne pas comme celle de CatBoost. Si vous faites un target encoding à la main, faites-le à l'intérieur de chaque pli de validation croisée, sinon le label fuit dans vos variables et les scores s'effondrent en production.

Avec quelques catégories à faible cardinalité, ça change peu de choses. Avec des catégories à forte cardinalité (des milliers de références produit ou de codes postaux), CatBoost fait souvent gagner un vrai travail.

Réglages par défaut et effort de tuning

Les réglages par défaut de CatBoost sont bons. Sur beaucoup de jeux de données, un CatBoost non réglé est proche de sa version optimisée. C'est utile quand il faut une base solide rapidement, ou quand la personne qui maintiendra le modèle n'est pas spécialiste du ML.

XGBoost récompense davantage le tuning. Taux d'apprentissage, profondeur, poids minimal des feuilles, sous-échantillonnage et régularisation comptent tous, et les valeurs par défaut sont un point de départ, pas une réponse. Ce n'est pas difficile, mais prévoyez une vraie recherche d'hyperparamètres, idéalement avec arrêt précoce sur un pli de validation.

La structure des arbres

CatBoost construit par défaut des arbres symétriques (oblivious) : à chaque profondeur, tous les nœuds utilisent la même règle de séparation. Ces arbres sont rapides en prédiction et jouent un rôle de régularisation, ce qui explique en partie pourquoi les réglages par défaut tiennent bien.

XGBoost fait croître ses arbres par profondeur par défaut, et peut aussi les faire croître en suivant la perte, plus proche de la croissance par feuille de LightGBM. Cette souplesse capte mieux les interactions complexes, mais peut aussi surapprendre plus vite si on ne la contrôle pas.

Vitesse, GPU et surapprentissage

Les deux librairies savent entraîner sur GPU, et les deux sont assez rapides pour la plupart des données d'entreprise sur un simple portable. Les comparaisons de vitesse dépendent énormément de la forme des données, des réglages et du matériel : je ne me fie pas aux benchmarks génériques. Mesurez sur vos propres données.

Contre le surapprentissage, les deux offrent les outils nécessaires : arrêt précoce, limite de profondeur, taux d'apprentissage, sous-échantillonnage des lignes et des colonnes, régularisation L2. Utilisez l'arrêt précoce sur un pli de validation dans tous les cas : c'est le réglage qui évite le plus d'ennuis.

N'oubliez pas LightGBM

LightGBM est la troisième option courante. Il est souvent le plus rapide sur de gros volumes grâce à ses histogrammes et à sa croissance par feuille, et il a sa propre gestion des catégories. En pratique, les trois librairies donnent des résultats proches sur des données bien préparées. Si l'une écrase les autres, vérifiez votre pipeline avant de vous réjouir.

La validation compte plus que la librairie

Voici ce que la plupart des comparatifs oublient. La première source de résultats trompeurs en ML tabulaire, ce n'est pas la librairie. C'est la fuite d'information entre l'entraînement et le test.

Si vos lignes vont par groupes (plusieurs mesures par patient, par client, par machine, par forage), un découpage aléatoire met des lignes du même groupe des deux côtés. Le modèle apprend à reconnaître le groupe plutôt que le phénomène, et le score de test paraît excellent. Puis un vrai nouveau patient, client ou forage arrive, et le score chute.

La solution, c'est la validation croisée par groupes : toutes les lignes d'un groupe restent dans le même pli. La version la plus stricte est le leave-one-group-out, où chaque pli met de côté exactement un groupe. C'est plus lent, mais cela répond à la vraie question : que vaut le modèle sur quelque chose qu'il n'a jamais vu ?

Pour les données temporelles, même idée avec le temps : on entraîne sur le passé, on teste sur le futur. J'en parle dans prévision des ventes pour les PME.

Un exemple réel : des couches géologiques à partir d'essais CPT

Dans le projet CPT Dashboard, un projet de data science à cinq à l'université de Hasselt avec des données du VITO, il fallait prédire laquelle de 15 couches géologiques se trouve à chaque profondeur d'un essai de pénétration au cône (CPT). Le jeu de données comptait environ 184 000 mesures étiquetées.

Ces mesures arrivent par sondages : un CPT donne des centaines de lignes, toutes au même endroit du sol, et les lignes voisines sont presque identiques. Un découpage aléatoire aurait mis des lignes du même sondage dans l'entraînement et dans le test, et les scores n'auraient rien voulu dire.

Chaque modèle a donc été validé en mettant de côté des sondages entiers, en leave-one-CPT-out sur 238 sondages. Nous avons comparé CatBoost, XGBoost, Random Forest et LightGBM à des modèles de séquence (LSTM, modèles de Markov cachés et CRF), tous avec cette même validation stricte. Les arbres utilisaient la profondeur, la résistance de pointe, le rapport de frottement, des indices de comportement du sol et la position.

Le modèle n'était que la moitié de la réponse. Les prédictions brutes sautent d'une couche à l'autre d'une façon qu'aucun géologue n'accepterait. Un post-traitement par programmation dynamique (Viterbi) impose l'ordre d'apparition des couches, fusionne les séquences trop courtes et corrige les couches prises en sandwich. Le tableau de bord affiche ensuite les trois interprétations les plus plausibles avec leur score de confiance, et permet d'entraîner un nouveau modèle CatBoost, XGBoost ou Random Forest depuis le navigateur.

La leçon que j'en garde : une fois la validation honnête, le choix entre librairies de gradient boosting devient un détail. Le vrai travail, c'était la validation et les règles métier.

Comment je choisirais aujourd'hui

1. Mettez d'abord en place une validation par groupes ou temporelle. Décidez ce que « jamais vu » veut dire pour votre problème.
2. Entraînez CatBoost avec ses réglages par défaut comme base solide, surtout avec des variables catégorielles.
3. Entraînez XGBoost ou LightGBM avec arrêt précoce et un petit budget de tuning.
4. Comparez sur les mêmes plis, et regardez les erreurs par groupe, pas seulement le score moyen.
5. Gardez le modèle le plus simple qui tient, et passez le temps gagné sur les variables et sur ce qui se passe après la prédiction.

Travailler ensemble

Je suis Driss Briksine, ingénieur logiciel et ML, titulaire d'un master en statistique et science des données de l'université de Hasselt. Je construis des modèles de ML et les logiciels de production qui les entourent. Voyez l'étude de cas CPT Dashboard et mes autres réalisations, ou lisez que faut-il automatiser en premier.

Si vous avez des données tabulaires et une prédiction en laquelle vous devez pouvoir avoir confiance, envoyez-moi un court descriptif.