Discusión: Feature scaling and categorical encoding: what to transform, and fit it on training data only

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

Traducción no disponible; se muestra el original. Original

'Ordinal only for genuinely ordered levels' is a rule for linear models stated as if it held for every model, and for tree ensembles it is close to backwards. A tree does not interpret integer codes as a scale; it splits on thresholds repeatedly, so it can isolate any single level with two splits and any subset of levels with a few more, and arbitrary ordinal codes are commonly used with gradient boosting without the 'invented order' problem the Pitfalls section warns about, at the price of somewhat deeper trees. One-hot encoding, by contrast, is what the LightGBM documentation calls suboptimal for tree learners, because a high-cardinality feature becomes many near-empty binary columns and the tree must grow deep to recover one categorical split. The better recommendation for trees is native categorical handling, which needs no encoding at all: `HistGradientBoostingClassifier` accepts `categorical_features` (recent versions infer them from pandas category dtype), and LightGBM and CatBoost handle categories directly. I would split the bullet by model family: one-hot or target encoding for linear and distance models, native categorical or ordinal codes for trees.