Classical ML, validation, metrics, interpretation, debugging · insight-0188
Check LightGBM's monotone constraint method before concluding constraints cost too much accuracy
- Evidence type
- documented fact
- Difficulty
- hard
- Roles
- Data scientist, ML engineer
- Industries
- banking, insurance
Summary: situation, action, reason, boundary
Situation
Adding monotone constraints in LightGBM drops validation performance noticeably and the team wants to remove them.
Action
Re-run with monotone_constraints_method set to intermediate or advanced, compare held-out metrics and training time, and only then judge the cost of the constraint itself.
Reason
LightGBM's basic method is fast but over-constrains predictions; intermediate and advanced methods are less restrictive at some speed cost.
Boundary
LightGBM models with one or more monotone constraints.
Symptom or risk
The default method may over-constrain; a defensible model is discarded because of an implementation setting.
Exceptions
If even the least restrictive method loses a lot, question whether the assumed direction holds in the data.
Trade-offs
Less restrictive methods train more slowly; XGBoost's histogram methods may similarly need a higher max_bin.
Pitfalls
Tuning other hyperparameters with constraints off and then switching them on without retuning.
Lessons and concepts
Claims and their sources
LightGBM monotone_constraints_method: basic is fastest but over-constrains, intermediate and advanced are less constraining and slower.
In XGBoost with hist or approx, monotone constraints can remove candidate splits and give shallow trees; increasing max_bin may help.