MessagePassing.explain_message functionality.

[fork123aniket]

This PR contains implementation of how to compute layer-wise weights for each edge in order to produce explanations for both node-level and graph-level tasks. Furthermore, this implementation is different from authors' original implementation and is fast and more memory efficient than theirs.

[fork123aniket]

Please take a look at functions (message, get_latest_source_embeddings, get_latest_target_embeddings, and get_latest_messages) which must be copied to other layers' implementation in order to make this GraphMask implementation model-agnostic. The significance of each of these functions can be seen on lines 241-243 (updated_gcn.py) and 306-308 (updated_rgcn.py).

[codecov]

Codecov Report

Merging #4278 (9747c8c) into master (6500858) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #4278      +/-   ##
==========================================
+ Coverage   82.58%   82.60%   +0.01%     
==========================================
  Files         312      312              
  Lines       16135    16152      +17     
==========================================
+ Hits        13325    13342      +17     
  Misses       2810     2810              

Impacted Files	Coverage Δ
torch_geometric/nn/conv/message_passing.py	99.43% <100.00%> (+0.02%)	⬆️
torch_geometric/nn/models/explainer.py	95.86% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6500858...9747c8c. Read the comment docs.

[fork123aniket]

@rusty1s Am just following up with you that did you get a chance to look into the code files pinned with this PR? Am still awaiting any review comments so we can make further progress on how to make this GraphMask Explainer implementation model-agnostic. In the previous comment, I've provided details of which functions to put more focus on.

[rusty1s]

Hi @fork123aniket. Yes, sorry for the delay. I will try to have a review ready by tomorrow. I sadly only have two hands :(

[rusty1s]

Sorry for the delay. I left some ideas on how to make this GNN-agnostic :) Looking forward to your reply.

[fork123aniket]

I've just replied to all the comments above. Please look into each of them and let me know your thoughts. Looking forward to hearing from you very soon....... :)

[Padarn]

The 'explain message' interface just seemed a little specific (and difficult to understand what to do with), and all models using it will need to implement it anyway. But just a gut reaction. Not very familiar with the whole proposal.

…

On Fri, 1 Apr 2022, 7:30 pm Matthias Fey, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In torch_geometric/nn/conv/updated_gcn.py <#4278 (comment)> : > + message_scale=message_scale, + message_replacement=message_replacement, + size=None) + + if self.bias is not None and not False and not self.explain: + out += self.bias + + return out + + def message(self, x_i: Tensor, x_j: Tensor, edge_index: Tensor, + edge_weight: OptTensor, message_scale, + message_replacement) -> Tensor: + if self.explain: + basis_messages = x_j if edge_weight is None else edge_weight.view( + -1, 1) * x_j + basis_messages = self.convert(basis_messages) I think the goal here is to make this procedure GNN agnostic. As such, when we want to implement this inside a model's message function, we basically have to do this for every PyG GNN layer. Let me know if I might be misunderstanding something. — Reply to this email directly, view it on GitHub <#4278 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRPNYSZ6F2YXDS6DIIM4DVC3M6XANCNFSM5Q4PMM7A> . You are receiving this because you commented.Message ID: ***@***.***>

-- By communicating with Grab Inc and/or its subsidiaries, associate companies and jointly controlled entities (“Grab Group”), you are deemed to have consented to the processing of your personal data as set out in the Privacy Notice which can be viewed at https://grab.com/privacy/ <https://grab.com/privacy/> This email contains confidential information and is only for the intended recipient(s). If you are not the intended recipient(s), please do not disseminate, distribute or copy this email Please notify Grab Group immediately if you have received this by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free as any information therein could be intercepted, corrupted, lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do not accept liability for any errors or omissions in the contents of this email arises as a result of email transmission. All intellectual property rights in this email and attachments therein shall remain vested in Grab Group, unless otherwise provided by law.

[rusty1s]

@fork123aniket Thanks for the update :) Can you apply the modifications directly inside message_passing.py? This makes it easier to track the changes (and we need to do that anyway before merging).

What do message_scale and message_replace represent? Do we really need to pass them as arguments to forward or can we simply set them as instance attributes during explainability? This way, we could simply access them via self.message_replace since explain_message rather than adding them as input arguments to every GNN layer (which again obviously does not scale).

[fork123aniket]

@rusty1s Bingo!!! Successfully set those two required parameters (message_scale and message_replacement) as instance attributes only at the time of generating explanations. Now, we need not to worry about adding them to each layer type's forward() function. Have tested the whole proposed explainability technique on datasets:- Cora (Node Classification - GAT, GCN), Enzymes (Graph Classification - GAT, GCN), and AIFB (Node Classification - RGCN) without touching any of the layer types' original implementation which signals the successful achievement towards model-agnostic graph explainability, WDYT??

Furthermore, as mentioned above, since making changes to any GNN layer types' original implementation is not required, hence have taken all the three previously added files (updated_gcn.py, updated_gat.py, and updated_rgcn.py) down from this PR and added all the modifications, made for GraphMask Explainer to work, inside MessagePassing interface of the recently committed message_passing.py file. Now, you'll be easily able to figure out the differences between this committed change and the original PyG message_passing.py file.

Please review the changes and let me know if any further change is still required somewhere.

[rusty1s]

Thanks for the updates :)

[rusty1s]

Not sure why we need these arguments here. IMO, the GraphMask module should set these attributes (and we solely rely on _explain to call self.explain_message or not).

[fork123aniket]

@rusty1s All the above mentioned 5 issues have been addressed in the recently added message_passing.py. Please review the changes.

[rusty1s]

Thank you! Cleaned up a bit and added necessary tests :)