Flaml: fix lgbm reproducibility - #1369
Conversation
Li Jiang (thinkall)
left a comment
There was a problem hiding this comment.
Thank you so much for the PR, Daniel Grindrod (@dannycg1996) !
Co-authored-by: Li Jiang <bnujli@gmail.com>
|
Hi Li Jiang (@thinkall), thanks for taking the time to explain - I understand why you wish to keep the early stopping! |
Li Jiang (thinkall)
left a comment
There was a problem hiding this comment.
Thank you sooooooooo much, Daniel Grindrod (@dannycg1996) ! LGTM!
|
Ah, it seems I have an issue with this test which I added. That's fine - we know it isn't always possible to reproduce scores when EarlyStopping is concerned! I'll tweak the test to ensure that our reproduced loss is at least as good as the loss reported by FLAML, and then it should be re-approvable/mergeable! |
…AML results, when LGBM earlystopping is involved
|
Sorry about that Li Jiang (@thinkall), I think it should be approvable and mergeable now! |
Why are these changes needed?
In some cases, FLAML LGBM results are not reproducible, using the best model provided by FLAML. I can split the problem, and the solution, into two:
1. n_estimators on automl.model.model always = 1
As described in the title, the code
self._model.set_params(n_estimators=best_iteration + 1)onLGBMEstimator.fit()causes the then_estimatorsvalue to always be 1. I'm not sure whyself._model.best_iteration_is always 0 - I think it's due to using EarlyStopping? Regardless, we have no need to overwrite a correctn_estimatorsvalue, so I've removed this code (and my unit tests now pass!)2. When a time_budget is set, LGBMEstimator sometimes is not reproducible, if the deadline is running out when the estimator is trained
This is a very similar issue to the one we recently resolved for the CatBoost model. Basically the callback causes the training of a model to differ, when the time budget is running out - thus making the loss impossible to reproduce. I've fixed this by simply deleting the if statement responsible - I think this is a clean solution.
Like with the CatBoost fix, I've also added a unit test, which fails when the if statement above is re-added to the codebase. This will help us identify if the issue is ever reimplemented somehow. It also allows others to test this issue, should they wish.
Also, am I okay to open an issue sometime to refactor this LGBMEstimator? There's a lot of defunct code, and it could be made both more readable and possibly more efficient.
Anyway, please let me know what you think!
Related issue number
Closes #1368
Checks