-
Notifications
You must be signed in to change notification settings - Fork 28
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
Support pred_contrib argument at predict #38
Comments
Hi @Fish-Soup, Thanks for the interest in the project. Can you please provide a miminal working example so that I can look into it? Thanks! |
Sure I managed to get something working, in a slightly in-elegant way. Extended the LightGBMLSS class and overwrote the prediction function. Here is the bit that does the pred_contrib argument.
This gives a multi index column with 2 levels one for the distribution arg_name (e.g. loc and scale for a Gaussian) and Feature Contributions which is the number of features + 1 (for the constant column) It seems however the better place to do this is in the distribution class itself, possibly when generally speaking we cannot apply the response functions in The above also allows us to get a feature_importance metric for a prediction data set for each distributional parameter as follows
For example we get each features contribution to both |
I'm writing a PR to review |
Hi @StatMixedML I've written a PR to the code, including adding a small unit test. |
Hi
I've been learning how to use this great package. One thing I like using in lightGBM is the pred_contrib=True argument at prediction time.
I notice if we run model.booster.predict(data, pred_contrib=True) this does generate data of the expected shape (n_features + 1) * (n_distributional_parameters).
However when I try and sum the contributions from each feature, this does not result in the same result as that which is generated when we call predict.
I believe this is due to the logic within the distribution class that occurs after booster.predict
EDIT: Upon more reading I realize that it is not always possible to decompose in such a way, as a function is called on each component, such that the sum of the function call on each component is not the same as the function call on the sum of the components.
However in the case of the identity function it is. In this case the difference seems to come from setting of the init score that is applied before the distribution function is called.
In lightGBM this is also an issue with Classifiers where the prediction_contributions are returned in logit_space.
Therefore in lightGBMLSS, pred_contrib could be supported, but when it is the distributional functions are not applied.
The text was updated successfully, but these errors were encountered: