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

Asymmetric causal Shapley values with adaptive sampling #400

Merged
merged 290 commits into from
Oct 13, 2024

Conversation

LHBO
Copy link
Collaborator

@LHBO LHBO commented Oct 4, 2024

Extension of PR #395 that builds on the adaptive sampling introduced in PR #396. As the latter PR completely rewrote all of the main functions in shapr, I found it easier to start on a new one as there were a lot of merge conflicts when trying to merge #396 into #395.

In this PR, we add support for computing asymmetric and/or causal Shapley values. The asymmetric version can use all approaches, while the causal version is limited to the Monte Carlo-based approaches. The implementation is an extension of #273 (but this PR was restricted to the gaussian approach and the old version of shapr), which was adapted from the package CauSHAPley.

Asymmetric Shapley values were proposed by Frye et al. (2020) as a way to incorporate causal knowledge in the real world by restricting the possible permutations of the features when computing the Shapley values to those consistent with a (partial) causal ordering.

Causal Shapley values were proposed by Heskes et al. (2020) as a way to explain the total effect of features on the prediction, taking into account their causal relationships, by adapting the sampling procedure in shapr.

The two ideas can be combined to obtain asymmetric causal Shapley values. If you would like more details, you can see Heskes et al. (2020).

Usage: (Assume N_features = 7)
(Symmetric) Conditional Shapley values: asymmetric = FALSE (default), causal_ordering = list(1:7) (default), and confounding = FALSE (default)

Marginal Shapley values: either 1) the same as above, but set approach = independence, or 2) asymmetric = FALSE (default), causal_ordering = list(1:7) (default), and confounding = TRUE.

Asymmetric conditional Shapley values with respect to a specific ordering: asymmetric = TRUE, causal_ordering = list(1, c(2, 3), 4:7), and confounding = FALSE (default).

Causal Shapley values (compute all coalitions, but chains of sampling steps): asymmetric = FALSE (default), causal_ordering = list(1, c(2, 3), 4:7), andconfounding = c(FALSE, TRUE, FALSE).

Asymmetric Causal Shapley values (compute only coalitions respecting the ordering and chains of sampling steps): asymmetric = TRUE, causal_ordering = list(1, c(2, 3), 4:7), and confounding = c(FALSE, TRUE, FALSE).

Main differences:
The user now has the option to specify asymmetric, causal_ordering, and confounding in the explain function.
The first argument, asymmetric, specifies if we should consider all feature combinations/coalitions, or only the combinations that respect the (partial) causal ordering given by causal_ordering. The second argument, causal_ordering is a list specifying the (partial) causal ordering of the features (groups), i.e., causal_ordering = list(1:3, 4:5), which implies that features one to three are the ancestors of four and five. The third argument, confounding specifies if the user assumes that each component is subject to confounding or not, e.g., causal_confounding = c(FALSE, TRUE). So that you know, practitioners are responsible for correctly identifying the causal structures.

When the causal_ordering is not list(1:N_features), then we have a causal structure that implies that some coalitions/feature combinations will not respect the order. For example, we cannot have a combination that conditions/includes feature four and not all of the features one to three in the setting above, as they are feature four's ancestors. If asymmetric = TRUE, then we only use the combinations that respect the order. If asymmetric = FALSE, then we use all combinations. Furthermore, generating the MC samples for each valid coalition will introduce a chain of sampling steps, which the confounding argument influences.

That is, if S = {2}, we would in the first step (assuming confounding = c(FALSE, TRUE)) sample X1, X3 | X2, and in the second step, we would sample X4, X5 | X1, X2, X3. The confounding changes whether to include the features in the same component as conditional features or not, as Heskes et al. (2020) explained. Also, see examples in get_S_causal() for demonstrations of how changing the confounding assumption changes the data generation steps.

To reuse most of the shapr code, we iteratively call prepare_data() with different values of S to generate the data. This introduces a lot of redundant computations, as we then generate X1, X3, X4, X5 | X2 in the first step, but throw away X4 and X5. To only generate MC samples for the relevant features, we would have to rewrite all prepare_data.approach functions also to take in a Sbar argument as they currently assume that Sbar is all features not in S.

The independence, empirical, and ctree approaches can not necessarily generate n_samples but rather weigh the samples. Combining these weights in an interactive sampling process is not obvious. We solve it by sampling the samples n_samples time using the weights. This means that we will have duplicates, which introduces extra computations.

Plot:
Additionally, we have introduced the include_group_feature_means = FALSE argument in plot.shapr and plot_SV_several_approaches as some plots need to have a feature value, which we do not have for group-wise Shapley values. When TRUE, we use the average feature value among the features in each group (for each explicand).
In plot_SV_several_approaches, we also add the index_explicands_sort argument to decide the order of the explicands in the plots.

TODO:

  • Implement exact asymmetric causal feature Shapley values for all Monte Carlo-based approaches.
  • Implement support for non-exact. Need to figure out how to sample the allowed combinations and what weights to give them. I have a function that can create all valid combinations but still grows at O(2^C), where C is the number of features in the largest component in the causal ordering.
  • Implement support for groups. Restrict feature groups to be in the same component in the causal ordering.
  • Ctree is not very fast due to many inputs/MC samples. Can we somehow use the weights to speed it up?
  • Create a small vignette.
  • Make vignette runnable.
  • Add new tests that test that it works both in the adaptive and regular version

FUTURE:

  • FUTURE: Generate only the features in Sbar and not all features not in S (Since Sbar union S is not all features). To do this, all prepare_data.approach functions must be rewritten.
  • FUTURE: Be more clever in choosing the combinations to go into the different batches. Combinations that condition on features in the same components have similar chains of sampling steps. Often, only the first step is different. See ?get_S_causal for some examples of chains. E.g., we can have c("2|", "3,4|1,2", "5|1,2,3,4") and c("1|", "3,4|1,2", "5|1,2,3,4"). Could then ideally save some time by computing the rest together to minimize the number of times we have to recompute/model the same conditional distributions (the last step is often identical for all combinations).
  • FUTURE: The causal versions of Gaussian and copula can be written faster in C++ by sending the whole chain of sampling steps for each coalition, but then we would no longer have the same structure for all sampling methods.

References:

  • Heskes, T., Sijben, E., Bucur, I. G., & Claassen, T. (2020). Causal Shapley Values: Exploiting Causal Knowledge to Explain Individual Predictions of Complex Models. Advances in Neural Information Processing Systems, 33.
  • Frye, C., Rowat, C., & Feige, I. (2020). Asymmetric Shapley values: incorporating causal knowledge into model-agnostic explainability. Advances in Neural Information Processing Systems, 33.

Copy link
Member

@martinju martinju left a comment

Choose a reason for hiding this comment

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

Done with the rest of the review. See the last minor comments. Not crucial to change the name.

R/shapley_setup.R Show resolved Hide resolved
R/shapley_setup.R Outdated Show resolved Hide resolved
inst/extdata/day.csv Outdated Show resolved Hide resolved
Copy link
Member

@martinju martinju left a comment

Choose a reason for hiding this comment

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

Let's say this is good now :-)

@martinju
Copy link
Member

We're aware that the mac-os test fails for the categorical approach, where one observation gets a different shapley value, due to a change in dt_vS value of v(S={3}). Further debugging is required to figure this out, but it is not straight forward as it only happens on the GHA macOS version, not locally on mac. Would probably need to add a new test which with keep_vS_output = TRUE to figure out more precisely where this is occuring.

@martinju martinju merged commit 14128ac into NorskRegnesentral:shapr-1.0.0 Oct 13, 2024
4 of 5 checks passed
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.

3 participants