-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flaml: fix lgbm reproducibility #1369
Flaml: fix lgbm reproducibility #1369
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for the PR, @dannycg1996 !
Co-authored-by: Li Jiang <[email protected]>
Hi @thinkall, thanks for taking the time to explain - I understand why you wish to keep the early stopping! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you sooooooooo much, @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 @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_estimators
value 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_estimators
value, 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