Skip to content
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

Change default parameters for feature selectors #3110

Merged
merged 6 commits into from
Dec 2, 2021

Conversation

jeremyliweishih
Copy link
Contributor

@jeremyliweishih jeremyliweishih commented Dec 1, 2021

This PR proposes changing the default parameters for RFRegressorSelectFromModel and RFClassifierSelectFromModel. The current, incorrect, behavior of these components is as follows:

  • number_features=None, percent_features=0.5, and threshold=-np.inf
  • max features is then calculated as:
max_features = (
            max(1, int(percent_features * number_features)) if number_features else None
        )
  • therefore, max_features = None
  • with max_features == None and threshold=-np.inf, the component will select every feature with importance above -np.inf` which is every feature available.

Performance tests using default algorithm:
fs_parameters_tests.zip

@@ -29,11 +29,11 @@ class RFClassifierSelectFromModel(FeatureSelector):
name = "RF Classifier Select From Model"
hyperparameter_ranges = {
"percent_features": Real(0.01, 1),
"threshold": ["mean", -np.inf],
"threshold": ["mean"],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR proposes using the mean as the threshold but experiments show that median performs similarly as well. median will select exactly half of the features and mean depending on the distribution. Happy to discuss which one to choose but I chose mean in the... meantime..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought: using median might be the move as the mean of feature importances will bound to be dragged down by low signal features (which are inevitable). However, performance results show similar model quality between median and mean but median having slightly longer fit times due to median selecting more features.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not allow both 'mean' and 'median' to be in the hyperparameter ranges? We can default to one, but allowing both in the ranges seems to be ideal for our automlsearch algo

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that suggestion. Right now the DefaultAlgorithm only runs one feature selector, so I'm down to set median as the default. Yesterday we discussed letting the algorithm tune the parameters of the selector in which case broadening the threshold search space (like parametrizing it as a quantile of the observed feature importance distribution) will be in play.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bchen1116 @freddyaboulton

sounds good, I'll add them both as hyperparameter ranges! My main concern is what Freddy brought up about the default parameter and having only 1 FS batch but I'm still on the fence on chosing mean or median. Either way it'll be a quick fix so I'm not too worried!

@codecov
Copy link

codecov bot commented Dec 1, 2021

Codecov Report

Merging #3110 (11ceecc) into main (840fc3b) will increase coverage by 0.1%.
The diff coverage is 100.0%.

Impacted file tree graph

@@           Coverage Diff           @@
##            main   #3110     +/-   ##
=======================================
+ Coverage   99.8%   99.8%   +0.1%     
=======================================
  Files        313     313             
  Lines      30579   30585      +6     
=======================================
+ Hits       30489   30495      +6     
  Misses        90      90             
Impacted Files Coverage Δ
...eature_selection/rf_classifier_feature_selector.py 100.0% <ø> (ø)
...feature_selection/rf_regressor_feature_selector.py 100.0% <ø> (ø)
evalml/tests/component_tests/test_components.py 98.9% <100.0%> (+0.1%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 840fc3b...11ceecc. Read the comment docs.

Copy link
Contributor

@bchen1116 bchen1116 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! So this change will then allow the RF...FeatureSelector to now choose the top features that fall above the mean importance weight?

Looking at the perf tests, the fit times and performance changes seem reasonable. In all three tests, though, LightGBM seems to drop very significantly in performance:
image

Do you know why this is? This seems to be something that we should figure out and resolve before moving ahead with the change, especially if it's a potential bug somewhere in the code.

@@ -29,11 +29,11 @@ class RFClassifierSelectFromModel(FeatureSelector):
name = "RF Classifier Select From Model"
hyperparameter_ranges = {
"percent_features": Real(0.01, 1),
"threshold": ["mean", -np.inf],
"threshold": ["mean"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not allow both 'mean' and 'median' to be in the hyperparameter ranges? We can default to one, but allowing both in the ranges seems to be ideal for our automlsearch algo

@@ -29,11 +28,11 @@ class RFRegressorSelectFromModel(FeatureSelector):
name = "RF Regressor Select From Model"
hyperparameter_ranges = {
"percent_features": Real(0.01, 1),
"threshold": ["mean", -np.inf],
"threshold": ["mean"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here, seems to be ideal to allow median as a possible value in the hyperparams.

elif isinstance(component, RFRegressorSelectFromModel):
assert transform_output.shape == (X.shape[0], 2)
elif isinstance(component, RFClassifierSelectFromModel):
assert transform_output.shape == (X.shape[0], 5)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the 2 or 5 values coming from here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's the number of columns selected by the FS component using the default parameters on X_y_binary and X_y_regression.

Copy link
Contributor

@freddyaboulton freddyaboulton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me @jeremyliweishih ! Agree with @bchen1116 that setting median and mean as hyperparameter values makes sense.

@@ -29,11 +29,11 @@ class RFClassifierSelectFromModel(FeatureSelector):
name = "RF Classifier Select From Model"
hyperparameter_ranges = {
"percent_features": Real(0.01, 1),
"threshold": ["mean", -np.inf],
"threshold": ["mean"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that suggestion. Right now the DefaultAlgorithm only runs one feature selector, so I'm down to set median as the default. Yesterday we discussed letting the algorithm tune the parameters of the selector in which case broadening the threshold search space (like parametrizing it as a quantile of the observed feature importance distribution) will be in play.

@jeremyliweishih
Copy link
Contributor Author

@bchen1116

LightGBM drops significantly in terms of percentage change (since the log loss is < 0.1) but it's not that big in absolute terms and likewise with the best pipeline validation score for that dataset so I'm not too worried about it. I guess the columns selected by the FS doesn't play nicely with LightGBM but I don't have enough knowledge about how LightGBM works to make any concrete statements about the change.

Copy link
Contributor

@bchen1116 bchen1116 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good to me!

@jeremyliweishih jeremyliweishih merged commit 36a50d2 into main Dec 2, 2021
@chukarsten chukarsten mentioned this pull request Dec 9, 2021
@freddyaboulton freddyaboulton deleted the js_change_fs_parameters branch May 13, 2022 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants