{"notes":[{"id":"graph-learning/over-squashing","category":"graph-learning","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Over-squashing","subtitle":"Ça ne rentre plus","author":"Z. Yuan","paperDate":"2020-06-09","publishedOn":"2024-03-03","paperTitle":"On the Bottleneck of Graph Neural Networks and its Practical Implications","paperUrl":"https://arxiv.org/abs/2006.05205","bibliography":{"title":"On the Bottleneck of Graph Neural Networks and its Practical Implications","authors":["Uri Alon","Eran Yahav"],"url":"https://arxiv.org/abs/2006.05205","pdfUrl":"https://arxiv.org/pdf/2006.05205v4","codeUrl":"https://github.com/tech-srl/bottleneck","preprint":{"id":"2006.05205","submittedOn":"2020-06-09","url":"https://arxiv.org/abs/2006.05205"},"publication":{"venue":"ICLR","year":2021,"kind":"conference","url":"https://arxiv.org/abs/2006.05205"},"citation":"@misc{graphlearningoversquashing2020,\n  title = {{On the Bottleneck of Graph Neural Networks and its Practical Implications}},\n  author = {Uri Alon and Eran Yahav},\n  year = {2020},\n  eprint = {2006.05205},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2006.05205}\n}\n","citationPath":"/content/papers/citations/graph-learning/over-squashing.af346c012204.bib"},"thumbnail":{"src":"/content/papers/assets/c3454ca38b6e53b6467ff66db7867788efed8d8a71eec3c6e7f754e586a99d4d.png","width":1078,"height":356},"locale":"fr","path":"/content/papers/fr/graph-learning/over-squashing.53fa3625a72f.md","headings":[{"id":"poser-le-problème","text":"Poser le problème","depth":2},{"id":"le-rayon-du-problème","text":"Le rayon du problème","depth":3},{"id":"comparaison-au-goulet-des-rnn","text":"Comparaison au goulet des RNN","depth":3},{"id":"ne-regarder-que-la-part-propagée","text":"Ne regarder que la part propagée","depth":3},{"id":"une-tâche-volontairement-construite","text":"Une tâche volontairement construite","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"une-dernière-couche-entièrement-connectée","text":"Une dernière couche entièrement connectée","depth":3},{"id":"quelle-taille-de-vecteur-faut-il-","text":"Quelle taille de vecteur faut-il ?","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"tree-neighborsmatch","text":"Tree-NeighborsMatch","depth":3},{"id":"qm9","text":"QM9","depth":3},{"id":"jeux-biologiques","text":"Jeux biologiques","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"graph-learning/deeper-insights","relation":"referenced","topic":""},{"id":"graph-learning/graphgps","relation":"referenced","topic":""}]},{"id":"graph-learning/deeper-insights","category":"graph-learning","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Deeper Insights","subtitle":"Trop bien lissé","author":"Z. Yuan","paperDate":"2018-01-22","publishedOn":"2023-11-29","paperTitle":"Deeper Insights into Graph Convolutional Networks for Semi-Supervised Learning","paperUrl":"https://arxiv.org/abs/1801.07606","bibliography":{"title":"Deeper Insights into Graph Convolutional Networks for Semi-Supervised Learning","authors":["Qimai Li","Zhichao Han","Xiao-Ming Wu"],"url":"https://arxiv.org/abs/1801.07606","pdfUrl":"https://arxiv.org/pdf/1801.07606v1","codeUrl":null,"preprint":{"id":"1801.07606","submittedOn":"2018-01-22","url":"https://arxiv.org/abs/1801.07606"},"publication":{"venue":"AAAI","year":2018,"kind":"conference","url":"https://ojs.aaai.org/index.php/AAAI/article/view/11604"},"citation":"@misc{graphlearningdeeperinsights2018,\n  title = {{Deeper Insights into Graph Convolutional Networks for Semi-Supervised Learning}},\n  author = {Qimai Li and Zhichao Han and Xiao-Ming Wu},\n  year = {2018},\n  eprint = {1801.07606},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1801.07606}\n}\n","citationPath":"/content/papers/citations/graph-learning/deeper-insights.52354c86fac9.bib"},"thumbnail":{"src":"/content/papers/assets/2a13880b48fae6456e19c622cee1d7c7907f8c31d6890722d4980a381fddb06a.png","width":1396,"height":268},"locale":"fr","path":"/content/papers/fr/graph-learning/deeper-insights.3da7994e8311.md","headings":[{"id":"poser-le-problème","text":"Poser le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"comparer-au-réseau-entièrement-connecté","text":"Comparer au réseau entièrement connecté","depth":3},{"id":"le-lissage-laplacien","text":"Le lissage laplacien","depth":3},{"id":"lisser-trop-souvent","text":"Lisser trop souvent","depth":3},{"id":"trop-peu-de-couches-pose-aussi-problème","text":"Trop peu de couches pose aussi problème","depth":3},{"id":"le-remède--donner-plus-détiquettes-à-gcn","text":"Le remède : donner plus d'étiquettes à GCN","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"graph-learning/appnp","relation":"referenced","topic":""},{"id":"graph-learning/sgc","relation":"referenced","topic":""}]},{"id":"graph-learning/graphgps","category":"graph-learning","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"GraphGPS","subtitle":"Un GPS sur le graphe","author":"Z. Yuan","paperDate":"2022-05-25","publishedOn":"2025-09-09","world":"external/graphgps","paperTitle":"Recipe for a General, Powerful, Scalable Graph Transformer","paperUrl":"https://arxiv.org/abs/2205.12454","bibliography":{"title":"Recipe for a General, Powerful, Scalable Graph Transformer","authors":["Ladislav Rampášek","Mikhail Galkin","Vijay Prakash Dwivedi","Anh Tuan Luu","Guy Wolf","Dominique Beaini"],"url":"https://arxiv.org/abs/2205.12454","pdfUrl":"https://arxiv.org/pdf/2205.12454v4","codeUrl":"https://github.com/rampasek/GraphGPS","preprint":{"id":"2205.12454","submittedOn":"2022-05-25","url":"https://arxiv.org/abs/2205.12454"},"publication":{"venue":"NeurIPS","year":2022,"kind":"conference","url":"https://proceedings.neurips.cc/paper_files/paper/2022/hash/5d4834a159f1547b267a05a4e2b7cf5e-Abstract-Conference.html"},"citation":"@misc{graphlearninggraphgps2022,\n  title = {{Recipe for a General, Powerful, Scalable Graph Transformer}},\n  author = {Ladislav Rampášek and Mikhail Galkin and Vijay Prakash Dwivedi and Anh Tuan Luu and Guy Wolf and Dominique Beaini},\n  year = {2022},\n  eprint = {2205.12454},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2205.12454}\n}\n","citationPath":"/content/papers/citations/graph-learning/graphgps.053e58fd5309.bib"},"thumbnail":{"src":"/content/papers/assets/e4177a894582643d7811bced6f6c6cf8bb51ff7738da4af5d98115883e1a4bb8.png","width":1116,"height":798},"locale":"fr","path":"/content/papers/fr/graph-learning/graphgps.e64f8dec7145.md","headings":[{"id":"poser-le-problème","text":"Poser le problème","depth":2},{"id":"position-et-structure","text":"Position et structure","depth":3},{"id":"pourquoi-les-messages-en-ont-besoin","text":"Pourquoi les messages en ont besoin","depth":3},{"id":"propager-avant-lattention-peut-déjà-perdre-linformation","text":"Propager avant l'attention peut déjà perdre l'information","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"trois-ingrédients","text":"Trois ingrédients","depth":3},{"id":"une-couche-gps","text":"Une couche GPS","depth":3},{"id":"une-complexité-linéaire","text":"Une complexité linéaire","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"ablation--le-poids-de-chaque-voie","text":"Ablation : le poids de chaque voie","depth":3},{"id":"comparaison-aux-autres-modèles","text":"Comparaison aux autres modèles","depth":3},{"id":"une-réévaluation-un-an-plus-tard","text":"Une réévaluation, un an plus tard","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"graph-learning/graph-transformer","relation":"referenced","topic":""},{"id":"graph-learning/san","relation":"referenced","topic":""},{"id":"graph-learning/graphormer","relation":"referenced","topic":""}]}],"text":"Depuis leurs débuts vers 2005, les réseaux sur graphes traînent un vieux problème : les informations des nœuds lointains arrivent difficilement.\n\nEn pratique, quelques couches suffisent souvent à arrêter les progrès. L'explication admise est le surlissage : en profondeur, tous les nœuds se ressemblent. Uri Alon et Eran Yahav, du Technion, remarquent que cette observation provient surtout de tâches locales, comme la classification d'articles, dont la réponse dépend des voisins proches et exige peu de couches. Si la tâche demande vraiment des informations lointaines, le blocage peut venir d'ailleurs.\n\n\n> [!TIP]\n> \n> Pour l'origine du surlissage et sa démonstration, voir notre note :\n> \n> - **[[18.01] Deeper Insights : Trop bien lissé](/blog/papers/graph-learning/deeper-insights)**\n\n\nPour faire interagir des nœuds distants de $r$, il faut au moins $r$ couches. Or chaque couche multiplie exponentiellement le nombre de voisins à prendre en compte, dont les informations doivent tenir dans un même vecteur de longueur fixe. Les auteurs nomment ce phénomène **over-squashing** : une compression excessive de l'information.\n\n## Poser le problème\n\n### Le rayon du problème\n\nLes auteurs définissent le **rayon du problème** $r$, la distance d'interaction nécessaire à une prédiction. Généralement inconnu à l'avance, il est estimé en réglant le nombre de couches $K$.\n\nLe champ réceptif $\\mathcal N_v^K$ du nœud $v$ après $K$ couches contient tous les nœuds à $K$ sauts au plus. Une tâche à longue portée exige $K\\ge r$ ; sinon, les nœuds lointains restent hors de portée, phénomène nommé **under-reaching**.\n\nMais $|\\mathcal N_v^K|$ croît exponentiellement avec $K$. L'agrégation somme cette masse d'informations dans un vecteur de longueur fixe, et les messages décisifs n'arrivent plus à destination. Le modèle apprend alors les signaux locaux de l'entraînement et généralise mal au test.\n\n### Comparaison au goulet des RNN\n\nCela rappelle la traduction automatique avant l'attention : l'encodeur seq2seq comprimait toute la phrase dans son dernier état caché et perdait de l'information avec les phrases longues.\n\n[![Figure 1 de l'article : à gauche, le goulet d'un RNN seq2seq transmet l'information de la séquence le long d'une chaîne jusqu'au dernier nœud. À droite, celui d'un GNN rassemble progressivement une multitude de nœuds disposés en arbre vers la cible à droite ; les courbes rouges s'y compriment en un faisceau.](/content/papers/assets/c3454ca38b6e53b6467ff66db7867788efed8d8a71eec3c6e7f754e586a99d4d.png)](/content/papers/assets/c3454ca38b6e53b6467ff66db7867788efed8d8a71eec3c6e7f754e586a99d4d.png)\n\n*Figure 1 de l'article (Alon et Yahav), extraite de la [**page 2 du PDF**](https://arxiv.org/pdf/2006.05205v4#page=2). Légende originale omise.*\n\nPour les auteurs, le goulet des GNN est pire : le champ réceptif du RNN croît **linéairement** avec les pas, celui du GNN **exponentiellement**. À longueur de vecteur égale, le GNN doit faire tenir bien plus de choses.\n\n### Ne regarder que la part propagée\n\nPrenons un arbre binaire, sans poids appris ni non-linéarité. Après $r$ couches, quelle part de chaque feuille reste à la racine ?\n\n```python\nimport numpy as np\n\ndef binary_tree(r):\n    n = 2 ** (r + 1) - 1                     # Racine 0 ; enfants de i : 2i+1 et 2i+2\n    A = np.zeros((n, n))\n    for i in range((n - 1) // 2):\n        for c in (2 * i + 1, 2 * i + 2):\n            A[i, c] = A[c, i] = 1\n    return A\n\nfor r in range(2, 8):\n    A = binary_tree(r) + np.eye(2 ** (r + 1) - 1)\n    d = A.sum(1)\n    A_hat = A / np.sqrt(np.outer(d, d))\n    share = np.linalg.matrix_power(A_hat, r)[0, -1]     # Part de la dernière feuille dans la racine après r pas\n    print(f\"r={r}  {2 ** r:>3} feuilles, part de chacune dans la racine {share:.5f}\")\n```\n\n```text\nr=2    4 feuilles, part de chacune dans la racine 0.10206\nr=3    8 feuilles, part de chacune dans la racine 0.02552\nr=4   16 feuilles, part de chacune dans la racine 0.00638\nr=5   32 feuilles, part de chacune dans la racine 0.00159\nr=6   64 feuilles, part de chacune dans la racine 0.00040\nr=7  128 feuilles, part de chacune dans la racine 0.00010\n```\n\nChaque niveau double les feuilles, mais divise approximativement leur part à la racine par quatre. À $r=7$, les informations de 128 feuilles se mélangent, chacune ne pesant qu'environ un dix-millième. Cette démonstration est une intuition ; l'article raisonne sur la quantité d'information stockable dans un vecteur.\n\n### Une tâche volontairement construite\n\nPour isoler le goulet, les auteurs inventent **NeighborsMatch**.\n\nDes nœuds verts ont chacun un nombre distinct de voisins bleus et une lettre comme étiquette. La cible a aussi des voisins bleus ; il faut lui donner la lettre du nœud vert qui possède le même nombre de voisins bleus. La correspondance change dans chaque graphe : le modèle doit transmettre les informations de tous les nœuds verts à la cible et les comparer, sans raccourci.\n\nLa tâche paraît artificielle, mais ressemble selon les auteurs à un problème de programmation. Un code Python déclare plusieurs variables de types et de valeurs distincts ; choisir celle à utiliser à un endroit exige de comparer les variables visibles au type et à la valeur recherchés. C'est la tâche VarMisuse évaluée ensuite.\n\n**Tree-NeighborsMatch** remplace la structure intermédiaire par un arbre binaire de profondeur $r$. Les nœuds verts sont les feuilles, la cible la racine, et toutes les arêtes pointent vers elle. $r$ est donc le rayon du problème et contrôle directement la compression. Les modèles utilisent $r+1$ couches pour appliquer encore une non-linéarité après l'arrivée à la racine.\n\n## Résoudre le problème\n\nLa principale contribution est l'identification et l'explication de l'over-squashing. Les auteurs présentent leur correction comme l'une des plus simples, destinée à montrer qu'un problème répandu restait ignoré.\n\n### Une dernière couche entièrement connectée\n\nOn remplace la dernière couche par une couche **entièrement adjacente** (fully-adjacent, FA). Chaque paire de nœuds y est voisine, $\\mathcal N_v:=V$, sans changer le type de couche ni ajouter de poids.\n\nLes $K-1$ premières couches suivent le graphe et apprennent des représentations porteuses de structure ; la dernière laisse tous les nœuds interagir directement, sans entasser l'information couche après couche dans le goulet.\n\n### Quelle taille de vecteur faut-il ?\n\nLes auteurs calculent aussi une borne combinatoire inférieure sur la dimension cachée $d$ nécessaire pour atteindre 100% d'exactitude d'entraînement sur Tree-NeighborsMatch. Elle croît factoriellement avec $r$, plus vite qu'une exponentielle. Pour $d=32$, leur dimension expérimentale, le rayon ne peut dépasser $r=7$. En pratique, c'est pire : la descente de gradient ne garantit pas de trouver la solution existante ; même $d=512$ ne permet d'ajuster que jusqu'à $r=7$.\n\n## Discussion\n\n### Tree-NeighborsMatch\n\n[![Figure 3 de l'article : rayon r de 2 à 8 à l'horizontale, exactitude d'entraînement à la verticale. GGNN, GAT, GIN et GCN sont à 1.0 pour r=2 et 3. À r=4, GGNN et GAT restent à 1.0, GIN tombe à 0.77 et GCN à 0.70 ; tous baissent ensuite et passent sous 0.2 à r=8.](/content/papers/assets/7a0066769f814f3963a4fbb407f58d7c16ecbc9fcc0c7107807c9ffd895b54e4.png)](/content/papers/assets/7a0066769f814f3963a4fbb407f58d7c16ecbc9fcc0c7107807c9ffd895b54e4.png)\n\n*Figure 3 de l'article (Alon et Yahav), extraite de la [**page 5 du PDF**](https://arxiv.org/pdf/2006.05205v4#page=5). Légende originale omise.*\n\nIl s'agit ici de l'exactitude d'**entraînement**. GCN et GIN n'ajustent parfaitement que jusqu'à $r=3$ ; GCN tombe à 70% à $r=4$. Dès $r=5$, aucun des quatre GNN n'ajuste parfaitement l'entraînement, même après avoir vu chaque exemple plus de dix mille fois.\n\nGAT et GGNN tiennent jusqu'à $r=4$. Selon les auteurs, GCN et GIN somment tous les messages en un vecteur avant de le combiner avec la cible ; GAT peut, par attention, sélectionner les voisins pertinents selon la représentation de cette cible. GGNN filtre lui aussi, par des portes élément par élément.\n\nSi tous échouent à ajuster ici, comment ajustent-ils les jeux publics à longue portée ? Les auteurs supposent qu'ils exploitent les signaux locaux et les caractéristiques fortuites de l'entraînement, sans apprendre les informations lointaines perdues dans le goulet, d'où une mauvaise généralisation.\n\n### QM9\n\nQM9 compte environ 130,000 molécules, de 18 atomes en moyenne, avec 13 propriétés de chimie quantique à régresser. Les auteurs reprennent l'implémentation de Brockschmidt (2020), qui avait exploré 500 configurations de divers GNN. Leur meilleure profondeur était généralement 8 couches, suggérant un besoin d'informations lointaines.\n\nMême code, mêmes partitions et réglages : seule la dernière couche devient FA, avec 5 entraînements par propriété. L'erreur baisse en moyenne de 42%.\n\nIls éliminent ensuite plusieurs explications possibles :\n\n- **Under-reaching ?** Pour au moins 90% des exemples, la profondeur atteint déjà le diamètre moléculaire : les nœuds lointains sont accessibles. Passer à 10 couches n'améliore rien.\n- **Vecteurs trop petits ?** Doubler la dimension n'améliore que de 5.5% ; FA conserve la dimension et les poids, pour 42% de gain.\n- **Faut-il tout connecter ?** Ajouter aléatoirement la moitié des arêtes à la dernière couche réduit encore l'erreur de 31.5% en moyenne. Plus on ajoute d'arêtes, plus le gain augmente.\n- **Pourquoi ne pas connecter toutes les couches ?** L'erreur monte au contraire de 1500%. La structure reste nécessaire ; il faut simplement un lieu d'échange direct à la fin.\n\n### Jeux biologiques\n\nNCI1 contient 4,110 composés à classer selon leur activité contre le cancer du poumon ; ENZYMES contient 600 enzymes de 6 classes. Les auteurs reprennent le protocole équitable d'Errica et al. (2020) : 10 plis, 3 graines aléatoires, soit 30 essais moyennés.\n\nErrica et al. avaient trouvé une référence sans graphe supérieure à tous les GNN sur ENZYMES. Avec FA, GIN gagne 8.1 points sur sa version initiale et 2.5 sur cette référence ; sur NCI1, GIN+FA gagne 1.5 point sur le meilleur GIN. En moyenne, FA réduit l'erreur de 12% sur ENZYMES et de 4.8% sur NCI1.\n\nSur les programmes VarMisuse, les cinq GNN gagnent avec FA pour les projets vus à l'entraînement, R-GCN atteignant 88.4%. Sur les projets inconnus, la plupart progressent aussi : R-GCN passe de 82.9% à 83.8%, tandis que GGNN et GNN-MLP baissent légèrement.\n\n## Conclusion\n\nL'article isole une cause jusque-là peu discutée des difficultés à longue portée : un champ réceptif exponentiel, un vecteur de longueur fixe, et de l'information écrasée dans le goulet. GCN et GIN, qui somment indistinctement les voisins, sont les plus touchés. Une dernière couche entièrement adjacente, sans poids supplémentaires, améliore nettement des modèles pourtant déjà largement réglés.\n\nLes auteurs disent clairement que FA n'est qu'un départ. Les travaux suivants élargiront les goulets en modifiant les connexions, ou combineront à chaque couche messages locaux et attention globale, comme GraphGPS.\n\n\n> [!TIP]\n> \n> Pour la combinaison du passage de messages et de l'attention globale dans une même couche, voir notre note :\n> \n> - **[[22.05] GraphGPS : Un GPS sur le graphe](/blog/papers/graph-learning/graphgps)**\n\n\nSi votre GNN bloque sur une tâche à longue portée, avant de l'approfondir ou de l'élargir, essayez de connecter tous les nœuds à la dernière couche. Aucun paramètre à ajouter : seule son adjacence change.\n","imageSizes":{"/content/papers/assets/c3454ca38b6e53b6467ff66db7867788efed8d8a71eec3c6e7f754e586a99d4d.png":{"width":1078,"height":356},"/content/papers/assets/7a0066769f814f3963a4fbb407f58d7c16ecbc9fcc0c7107807c9ffd895b54e4.png":{"width":558,"height":316}}}