[Explainability Evaluation] - GNN model (Un)Faithfulness

[ZeynepP]

Here is the implementation of metric faithfulness with its examples for node and graph classification. I made some implementation decisions, we can discuss. I did not implement edge_mask, again to discuss.
#5961

[codecov]

Codecov Report

Merging #6090 (2aab785) into master (7b11472) will decrease coverage by 1.90%.
The diff coverage is 100.00%.

❗ Current head 2aab785 differs from pull request most recent head f6250d6. Consider uploading reports for the commit f6250d6 to get more accurate results

@@            Coverage Diff             @@
##           master    #6090      +/-   ##
==========================================
- Coverage   86.46%   84.55%   -1.91%     
==========================================
  Files         378      379       +1     
  Lines       21106    21100       -6     
==========================================
- Hits        18249    17842     -407     
- Misses       2857     3258     +401     

Impacted Files	Coverage Δ
torch_geometric/explain/metric/__init__.py	100.00% <100.00%> (ø)
torch_geometric/explain/metric/faithfulness.py	100.00% <100.00%> (ø)
torch_geometric/explain/metric/fidelity.py	100.00% <100.00%> (ø)
torch_geometric/nn/models/dimenet_utils.py	0.00% <0.00%> (-75.52%)	⬇️
torch_geometric/nn/models/dimenet.py	14.90% <0.00%> (-52.76%)	⬇️
torch_geometric/visualization/graph.py	68.25% <0.00%> (-26.99%)	⬇️
torch_geometric/profile/profile.py	33.33% <0.00%> (-25.39%)	⬇️
torch_geometric/nn/conv/utils/typing.py	83.75% <0.00%> (-15.00%)	⬇️
torch_geometric/nn/pool/asap.py	92.10% <0.00%> (-7.90%)	⬇️
torch_geometric/nn/inits.py	67.85% <0.00%> (-7.15%)	⬇️
... and 34 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[wsad1]

Thanks for adding this. Lets add some tests.

[BlazStojanovic]

Thank you very much @ZeynepP for your work, and sorry for late PR review!

I've left some comments on how to make the functionality of faithfulness.py more general and make the usability more consistent between all the metrics.

High-level comments

• Instead of trying to implement faithfulness just as in the paper, let's think about how to make it as good and as general as possible! (See notes about faithfulness and perturbations)
• I don't think we need two examples for this metric. The behaviour between node and graph faithfulness should be similar enough that only one example is needed to understand both.
• We want the metrics to be as similar as possible among each other, so let's try and define faithfulness as: graph_faithfulness(explainer: Explainer, explanation: Explanation, index: Union[int, Tensor] = None, topk: int, **kwargs):. Alongside more unified interface, this has the additional benefit of having the Explainer (along with all of its configs) available for various checks and branches you might want to do.
• Let's try to leverage as much of the existing functionality of Explainer and Explanation as possible, this will make implementation of faithfulness much easier and clearer (see my comments for details). Also on this note, I'll try to update Explainer and Explanation so I make your job easier, this will include updating get_explanation_subgraph and get_complement_subgraph so that they include all updated attributes needed for prediction and different utils for properly (and consistently across the codebase) obtaining thresholded masks. Will follow up with PR, so you can see what new functionality is available.

Notes about faithfulness and perturbations

You are correct that there are really two types of faithfulness which makes all of this very confusing.

1. there is node_faithfulness (or just faithfulness) as defined in https://arxiv.org/pdf/2106.09078.pdf. This is the case with node perturbations.
2. then you have graph_explanation_faithfulness which is from the paper https://arxiv.org/pdf/2208.09339.pdf, this one is a bit easier to implement as it just imposes a top-k map over features and calls it a day.
3. They also measure faithfulness in different ways (1) measures the average difference between model predictions (2) measures the KL divergence.
4. My suggestion: Let's combine all of this functionality into a single function, moreover let's expand it in different ways

Here are my implementation considerations

• Focus on explaining a single instance at a time (this you have already done)
  • The instance can be anything the Explainer can explain, this means: node, edge, graph level tasks (also many nodes and edges)
• The basic idea behind faithfulness is simple, we make small perturbations and see if these have a significant effect on the predictions:
  • Users might want to measure faithfulness both in regression and classification settings
  • Users might want to perturb node features, edge features, graph connectivity, we can provide them with functionality for all of these
  • Users might want to test different thresholding (i.e. topk at different levels or hard_mask at different thresholds)
• My ultimate suggestion is to start with implementing a faithfulness function that takes into account all of the above, and returns a single score, but it is flexible enough that it encompasses all previous definitions of faithfulness. We can later wrap the function to produce specific faithfulnesses (e.g. node feature faithfulness, etc.)

Tell me what you think, I'd love to chat more and guide you through this (quite challenging) task! :)

[rusty1s]

I did go with graph (un)faithfulness for now to be able to finally merge this. @BlazStojanovic Let me know if you think node (un)faithfulness is also necessary.