-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Difference between local shap values coming from global and from the "shap_values"-method #2101
Comments
I was not able to reproduce that error in my environment. Can you please tell me the code to reproduce it?
outputs |
Having the same issue, the values are just different... Could it be that the two methods handle categorical dtype differently? |
You guys should index based on the second axis to get the Shap's for each feature alone: |
This issue has been inactive for two years, so it's been automatically marked as 'stale'. We value your input! If this issue is still relevant, please leave a comment below. This will remove the 'stale' label and keep it open. If there's no activity in the next 90 days the issue will be closed. |
Hi,
I have a tree explanation object containing ".data", ".values" and ".base_values". If I extract the shapley values from this object for a single data row ("local" value), I get the shapley values for the 32 features of my single data row.
Now, if I run the method "shap_values" on the explainer object and pass to it the feature data for that particular row, I also get the shapley values for the same row as above.
In my understanding, the shapley values extracted from the explanation object and the shapley values from the "shap_values"-method run on the explainer object should be the same.
But they are not. Very often (not always), there is a difference for only ONE feature shapley value. In my case, the shapley values for 31 features are exactly the same (for the two approaches), but most often there is a difference in ONE feature shapley value. I tried this on different data sets ... .
Why is that? And is this a bug?
The text was updated successfully, but these errors were encountered: