Why I got different n_estimators when using automl.model.estimator.get_params() and automl.best_config?

[azurechen97]

I tried to train a LightGBM model via FLAML. In the end, I got the tunned model automl.model.estimator. But I got n_estimator = 1 when I call automl.model.estimator.get_params(), instead of the actual 14142 provided by calling automl.best_config. What could be the problem?

[Nevermetyou65]

I got the same result as you even though I just copied the code from this example https://microsoft.github.io/FLAML/docs/Examples/AutoML-for-LightGBM

Someone NEED to clarify this!

Here is my result:

Best hyperparmeter config: {'n_estimators': 34, 'num_leaves': 178, 'min_child_samples': 14, 'learning_rate': 0.16444778912464297, 'log_max_bin': 9, 'colsample_bytree': 0.8963761466973907, 'reg_alpha': 0.0009765625, 'reg_lambda': 0.027857858022692313}
Best r2 on validation data: 0.8389
Training duration of best run: 0.8493 s
LGBMRegressor(colsample_bytree=0.8963761466973907,
              learning_rate=0.16444778912464297, max_bin=511,
              min_child_samples=14, n_estimators=1, n_jobs=-1, num_leaves=178,
              reg_alpha=0.0009765625, reg_lambda=0.027857858022692313,
              verbose=-1)

[jmrichardson]

I got the same issue:

Best hyperparmeter config: {'n_estimators': 1314, 'num_leaves': 6376, 'min_child_samples': 38, 'learning_rate': 0.0988351059982288, 'log_max_bin': 9, 'colsample_bytree': 0.6663805206578503, 'reg_alpha': 0.001100862503118278, 'reg_lambda': 136.83211237673618}
Best r2 on validation data: 0.2975
Training duration of best run: 6365 s
LGBMRegressor(colsample_bytree=0.6663805206578503,
              learning_rate=0.0988351059982288, max_bin=511,
              min_child_samples=38, n_estimators=1, n_jobs=-1, num_leaves=6376,
              reg_alpha=0.001100862503118278, reg_lambda=136.83211237673618,
              verbose=-1)

[jmrichardson]

Is this going to be fixed? New release has same error

[azurechen97]

I believe the issue is solved in release v2.3.2.

[azurechen97]

Per checking, the bug is fixed in Release v2.3.2. Thank you @dannycg1996!