How graph adjacency impact graph classification?

[evantianzg]

Hi,

I am performing graph classification using some basic GNN models. I noticed the adjacency of MUTAG for graph classification is just like that:

I understand an ideal GNN model for graph-level tasks should be permutation-invariant. So my question is:

Does the order of the adjacency matrix impact the performance of the GNN model? Especially when using the mini-batch strategy. For example, suppose the first graph has "n_1" nodes and "m_1" edges, and the second graph has "n_2" nodes and "m_2" edges. Suppose the batch size is "b". So there should be "b" graphs for each training. In this case, how can we ensure the number of graphs for a mini-batch training is exactly b since all the graph adjacencies are put together in one?

[rusty1s]

GNN layers in PyG are usually permutation-invariant, and the order of edges does not matter. DataLoader can handle varying sizes across graphs by stacking adjacency matrices diagonally.

The TUDataset unwraps the raw format of stacking all graphs into a single file and puts them each into separate Data objects.

[evantianzg]

Sorry for not being clear in my question. You are really nice, and your reply helped me a lot. Here is the full picture.

I am interested in anomaly detection in large-scale graphs. Currently, I am working on the fraud detection of a large-scale transaction network. There are millions of accounts and over ten million transactions between these accounts. Over 1000 accounts are labeled as fraudulent, and the remaining accounts are marked as non-fraudulent. Apparently, it is highly challenging to detect fraudsters via node classification due to the extreme data imbalance. So I tried to build a balanced dataset by combining k-order transaction networks of fraudulent accounts with an equal number of k-order transaction networks from non-fraudulent accounts. Then I could perform graph classification to detect fraudulent accounts. However, I found that these transaction networks had a lot of common neighbors after I carefully checked them.

Intuitively, I think it is ideal not to change these transaction networks (no duplication of common nodes), but that will definitely make the code more complicated (maybe I need to override the torch_geometric.data.Data.__inc__() method?). I don't want to get myself into more trouble: I am new to coding :) So I think maybe duplicating the common nodes is the simplest solution.

[rusty1s]

I think what you really want to do in this use case is to use NeighborLoader and treat this as a node classification problem. Then, you can also pass a custom sampler (e.g., ImbalancedSampler from PyG) so that fraudulent accounts are sampled more frequently. With this, you can even share nodes across different seed nodes in your mini-batch.

[evantianzg]

Never though of such a solution. I am not sure how this method will work in a scenario where the class ratio reaches 1:100, but it sounds great and worth a try.

BTW, I think it is not essential to feed node features into a graph classification model, but would adding node features improve the model's performance?

[rusty1s]

If you have meaningful node features, they are always good to add.

[evantianzg]

I think so too. There are some distinct differences between fraudulent accounts and non-fraudulent ones. It must be helpful to add node features. Thank you for your suggestions.

Have a good day:)