XGBoost var det som gjorde gradient boosting till standardvalet för tabelldata, och den positionen håller i sig. Se gradient boosting för metoden i sig.
Varför den ofta blir vald
Alla kan den. Det är sällan det starkaste tekniska argumentet och ofta det starkaste praktiska. Ett uppdrag är lyckat när kundens team kan förvalta modellen utan mig, och XGBoost är det bibliotek de sannolikt redan har i sina befintliga flöden.
Finns överallt. Inbyggt stöd i SageMaker, Vertex AI, Databricks och de flesta MLOps-verktyg. Det tar bort integrationsarbete som annars äter en vecka.
Förutsägbar. Beteendet är välkänt, fallgroparna är dokumenterade, och det finns svar på nästan varje fråga som kan uppstå.
Egna målfunktioner. Möjligheten att definiera egen förlustfunktion och gradient är underutnyttjad. Vid asymmetriska kostnader, där underprognos kostar annat än överprognos, går det att koda in kostnadsstrukturen direkt i stället för att välja ett standardmått som antar symmetri. Se felmått.
Jämfört med de andra
| Styrka | |
|---|---|
| XGBoost | Etablerat, finns överallt, bredast dokumenterat |
| CatBoost | Kategoriska variabler utan förarbete, bäst utan justering |
| LightGBM | Snabbast på stora datamängder |
Skillnaden i träffsäkerhet mellan dem är oftast liten nog att inte avgöra någonting. Skillnaden mot en felvald utfallsfördelning eller ett backtest med läckage är stor. Prioritera därefter.
Vad man behöver hålla reda på
Som all trädbaserad metod kan XGBoost inte extrapolera. Vid stigande trend i en tidsserie planar prognosen ut vid högsta historiska värdet, ett tyst fel som inte syns om testperioden råkar ligga inom det historiska spannet.
Kategoriska variabler kräver förarbete. Nyare versioner har visst inbyggt stöd, men det är fortfarande svagare än CatBoosts.
Och sannolikheterna är sällan kalibrerade direkt ur lådan. Ska talet multipliceras med ett belopp behöver det efterkalibreras.