[Explainability]: explain support for heterogenous graphs.

[wsad1]

🚀 The feature, motivation and pitch

Add a new class HeteroExplainer that supports explaining heterogenous graphs. This will involve the following changes to
explain module

1. Create a BaseExplainer which will have common functions both HeteroExplainer and Explainer needs.
2. Explainer class will inherit from BaseExplainer. Note: The Explainer class will have the same interface the only change is that it inherits form BaseExplainer
3. Add HeteroExplanation(HeteroData) to hold heterogenous explanations.
4. HeteroExplainer inherits from BaseExplainer. Both HeteroExplainer and Explainer can use the same config files as input.

class HeteroExplainer(BaseExplainer):
    def __call__(x_dict, edge_index_dict, *, target, target_idx)-> HeteroExplanation:
     ...
    def _threshold(self, explanation: HeteroExplanation)->HeteroExplanation:
    ...

cc: @dufourc1 @RexYing for thoughts

Alternatives

An alternative will be for Explainer to handle both hetero and homo graphs. But I feel this makes the interface more cluttered because it has to accept both dictionary or tensors and the implementation more complicated.

Additional context

This is part of the explainability roadmap: #5520, #5630

[rusty1s]

Do you think we can just share the Explainer class for both cases? I would like to avoid creating replicas for each algorithm and the base class. Since we usually just forward pass input arguments to the model, I believe the interface isn't necessarily cluttered at all.

[dufourc1]

The type hints for the Explainer class will be ugly, but since the user has to give an explanation algorithm to the Explainer, I tend to agree with rusty1s that they can probably share the same Explainer.

Maybe we can have two classes of ExplainerAlgorithm, one for the heterogeneous and the other for the homogeneous graphs ? I'm guessing the heterogeneous case will have to have quite a lot of utilities functions that the homogeneous case will never need.

[wsad1]

Yeah having Explainer support both seems reasonable now. But we'll have some if conditions checking if input is of type dictionary or tensor

class Explainer():
    def __call__(x: Union[Tensor, Dict[NodeType, Tensor]], edge_index: Union[Tensor,Dict[EdgeType, Tensor]],   *, target, 
                   target_idx)-> Union[HeteroExplanation, Explanation]:
          ....

    def _threshold(self, explanation: Union[Explanation, HeteroExplanation])->Union[Explanation, HeteroExplanation]:
        if isinstanc(expalnation, Explanation):
            return _threshold_explanation(explanation)
       else:
             return _threshold_hetero_explantion(explanation)

Maybe we can have two classes of ExplainerAlgorithm, one for the heterogeneous and the other for the homogeneous graphs

If we are unifying everything behind the Explainer interface then we should be able to do the same for ExplainerAlgorithm. Some ExplainerAlgorithms will support explaining both homo and hetero graphs, other won't. We could add a new config variable ModelConfig.model_type to indicate the type of model being explained. This config would be set internally in Explainer.__call__ and ExpalinerAlgorithm.supports would check this to see it supports explaining the kind of model.

[dufourc1]

Do we need the new config type (apart from checking if the ExplainerAlgorithm supports the kind of explanation)? Can't we infer the heterogeneous vs homogeneous from the x and edge type ?

[rusty1s]

Yes, we don‘t need new configs for this IMO.