{"notes":[{"id":"classic-cnns/inception-v3","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Inception-v3","subtitle":"Les grands noyaux tirent leur révérence","author":"Z. Yuan","paperDate":"2015-12-02","publishedOn":"2025-12-16","world":"external/inception-v3","paperTitle":"Rethinking the Inception Architecture for Computer Vision","paperUrl":"https://arxiv.org/abs/1512.00567","bibliography":{"title":"Rethinking the Inception Architecture for Computer Vision","authors":["Christian Szegedy","Vincent Vanhoucke","Sergey Ioffe","Jonathon Shlens","Zbigniew Wojna"],"url":"https://arxiv.org/abs/1512.00567","pdfUrl":"https://arxiv.org/pdf/1512.00567v3","codeUrl":null,"preprint":{"id":"1512.00567","submittedOn":"2015-12-02","url":"https://arxiv.org/abs/1512.00567"},"publication":null,"citation":"@misc{classiccnnsinceptionv32015,\n  title = {{Rethinking the Inception Architecture for Computer Vision}},\n  author = {Christian Szegedy and Vincent Vanhoucke and Sergey Ioffe and Jonathon Shlens and Zbigniew Wojna},\n  year = {2015},\n  eprint = {1512.00567},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1512.00567}\n}\n","citationPath":"/content/papers/citations/classic-cnns/inception-v3.5636c0bddf2d.bib"},"thumbnail":{"src":"/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png","width":419,"height":358},"locale":"fr","path":"/content/papers/fr/classic-cnns/inception-v3.cef04f61bedf.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"remplacer-un-55-par-deux-couches-33","text":"Remplacer un 5×5 par deux couches 3×3","depth":3},{"id":"décomposer-encore-en-1n-et-n1","text":"Décomposer encore en 1×n et n×1","depth":3},{"id":"le-véritable-rôle-des-classifieurs-auxiliaires","text":"Le véritable rôle des classifieurs auxiliaires","depth":3},{"id":"réduire-les-cartes-de-caractéristiques-sans-étrangler-linformation","text":"Réduire les cartes de caractéristiques sans étrangler l'information","depth":3},{"id":"assembler-les-pièces","text":"Assembler les pièces","depth":3},{"id":"rendre-le-modèle-moins-sûr-de-lui","text":"Rendre le modèle moins sûr de lui","depth":3},{"id":"réglages-dentraînement","text":"Réglages d'entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"ajouter-les-modifications-une-à-une","text":"Ajouter les modifications une à une","depth":3},{"id":"avec-une-résolution-plus-faible-combien-perd-on","text":"Avec une résolution plus faible, combien perd-on ?","depth":3},{"id":"comparaison-avec-dautres-modèles","text":"Comparaison avec d'autres modèles","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/inception-v1","relation":"referenced","topic":""},{"id":"normalization/batchnorm","relation":"referenced","topic":""},{"id":"classic-cnns/convnext","relation":"referenced","topic":""}]},{"id":"classic-cnns/inception-v1","category":"classic-cnns","legacyPath":"classic-cnns/1409-inception-v1","legacySlug":"1409-inception-v1","legacyPaths":[],"title":"GoogLeNet","subtitle":"Ou encore Inception-V1","author":"Z. Yuan","paperDate":"2014-09-17","publishedOn":"2024-09-22","paperTitle":"Going Deeper with Convolutions","paperUrl":"https://arxiv.org/abs/1409.4842","bibliography":{"title":"Going Deeper with Convolutions","authors":["Christian Szegedy","Wei Liu","Yangqing Jia","Pierre Sermanet","Scott Reed","Dragomir Anguelov","Dumitru Erhan","Vincent Vanhoucke","Andrew Rabinovich"],"url":"https://arxiv.org/abs/1409.4842","pdfUrl":"https://arxiv.org/pdf/1409.4842","codeUrl":null,"preprint":{"id":"1409.4842","submittedOn":"2014-09-17","url":"https://arxiv.org/abs/1409.4842"},"publication":{"venue":"CVPR","year":2015,"kind":"conference","url":"https://doi.org/10.1109/cvpr.2015.7298594"},"citation":"@misc{classiccnnsinceptionv12014,\n  title = {{Going Deeper with Convolutions}},\n  author = {Christian Szegedy and Wei Liu and Yangqing Jia and Pierre Sermanet and Scott Reed and Dragomir Anguelov and Dumitru Erhan and Vincent Vanhoucke and Andrew Rabinovich},\n  year = {2014},\n  eprint = {1409.4842},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1409.4842}\n}\n","citationPath":"/content/papers/citations/classic-cnns/inception-v1.3d20e0e32bcd.bib"},"thumbnail":{"src":"/content/papers/assets/254b970b1374c24267b60c2d684338760e9ba8b10dad761a5fa15f1bb8bcf6ef.jpg","width":1330,"height":394},"locale":"fr","path":"/content/papers/fr/classic-cnns/inception-v1.8e21e48f0201.md","headings":[{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"le-module-inception","text":"Le module Inception","depth":3},{"id":"configuration-des-paramètres","text":"Configuration des paramètres","depth":3},{"id":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"résultats-à-lilsvrc-2014","text":"Résultats à l'ILSVRC 2014","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/resnext","relation":"comparison","topic":"Branches, convolutions groupées et réutilisation des caractéristiques"},{"id":"classic-cnns/cspnet","relation":"comparison","topic":"Branches, convolutions groupées et réutilisation des caractéristiques"}]},{"id":"normalization/batchnorm","category":"normalization","legacyPath":"normalization/1502-batchnorm","legacySlug":"1502-batchnorm","legacyPaths":[],"title":"BatchNorm","subtitle":"Normalisation par lots","author":"Z. Yuan","paperDate":"2015-02-11","publishedOn":"2024-08-01","paperTitle":"Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift","paperUrl":"https://arxiv.org/abs/1502.03167","bibliography":{"title":"Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift","authors":["Sergey Ioffe","Christian Szegedy"],"url":"https://arxiv.org/abs/1502.03167","pdfUrl":"https://arxiv.org/pdf/1502.03167","codeUrl":null,"preprint":{"id":"1502.03167","submittedOn":"2015-02-11","url":"https://arxiv.org/abs/1502.03167"},"publication":null,"citation":"@misc{normalizationbatchnorm2015,\n  title = {{Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift}},\n  author = {Sergey Ioffe and Christian Szegedy},\n  year = {2015},\n  eprint = {1502.03167},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1502.03167}\n}\n","citationPath":"/content/papers/citations/normalization/batchnorm.bfa8abb33f32.bib"},"thumbnail":{"src":"/content/papers/assets/48b236d4b897164b93764eccfe22db29e5b9bce290d864336b8f12ec127c1e4b.jpg","width":1016,"height":824},"locale":"fr","path":"/content/papers/fr/normalization/batchnorm.0faad80bd1c0.md","headings":[{"id":"définition-du-problème","text":"Définition du problème","depth":2},{"id":"résolution-du-problème","text":"Résolution du problème","depth":2},{"id":"augmenter-le-taux-dapprentissage","text":"Augmenter le taux d'apprentissage","depth":3},{"id":"peut-on-retirer-dropout-","text":"Peut-on retirer Dropout ?","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"expérience-sur-mnist","text":"Expérience sur MNIST","depth":3},{"id":"expérience-sur-imagenet","text":"Expérience sur ImageNet","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"normalization/layernorm","relation":"next","topic":"Choisir les axes de normalisation"}]},{"id":"classic-cnns/convnext","category":"classic-cnns","legacyPath":"classic-cnns/2201-convnext","legacySlug":"2201-convnext","legacyPaths":[],"title":"ConvNeXt","subtitle":"Redonner sa grandeur à la convolution","author":"Z. Yuan","paperDate":"2022-01-10","publishedOn":"2024-06-30","paperTitle":"A ConvNet for the 2020s","paperUrl":"https://arxiv.org/abs/2201.03545","bibliography":{"title":"A ConvNet for the 2020s","authors":["Zhuang Liu","Hanzi Mao","Chao-Yuan Wu","Christoph Feichtenhofer","Trevor Darrell","Saining Xie"],"url":"https://arxiv.org/abs/2201.03545","pdfUrl":"https://arxiv.org/pdf/2201.03545","codeUrl":"https://github.com/facebookresearch/ConvNeXt","preprint":{"id":"2201.03545","submittedOn":"2022-01-10","url":"https://arxiv.org/abs/2201.03545"},"publication":{"venue":"CVPR","year":2022,"kind":"conference","url":"https://arxiv.org/abs/2201.03545"},"citation":"@misc{classiccnnsconvnext2022,\n  title = {{A ConvNet for the 2020s}},\n  author = {Zhuang Liu and Hanzi Mao and Chao-Yuan Wu and Christoph Feichtenhofer and Trevor Darrell and Saining Xie},\n  year = {2022},\n  eprint = {2201.03545},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2201.03545}\n}\n","citationPath":"/content/papers/citations/classic-cnns/convnext.801b4060b807.bib"},"thumbnail":{"src":"/content/papers/assets/37882616c5c72df33699003256d14bf7c58c8ea5d1e9e4fb5b1c33268c9a6923.jpg","width":1224,"height":432},"locale":"fr","path":"/content/papers/fr/classic-cnns/convnext.9500f216d84f.md","headings":[{"id":"définition-du-problème","text":"Définition du problème","depth":2},{"id":"résolution-du-problème","text":"Résolution du problème","depth":2},{"id":"repenser-larchitecture-du-réseau","text":"Repenser l'architecture du réseau","depth":3},{"id":"introduire-des-méthodes-dentraînement-modernes","text":"Introduire des méthodes d'entraînement modernes","depth":3},{"id":"conception-générale","text":"Conception générale","depth":3},{"id":"à-la-manière-de-resnext","text":"À la manière de ResNeXt","depth":3},{"id":"goulot-inversé","text":"Goulot inversé","depth":3},{"id":"convolutions-à-grand-noyau","text":"Convolutions à grand noyau","depth":3},{"id":"conception-détaillée","text":"Conception détaillée","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"configurations-des-modèles","text":"Configurations des modèles","depth":3},{"id":"résultats-sur-imagenet","text":"Résultats sur ImageNet","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"vision-transformers/convmixer","relation":"comparison","topic":"Mélanger les patches par convolution"},{"id":"vision-transformers/caformer","relation":"comparison","topic":"Mélanger les patches par convolution"},{"id":"reparameterization/replknet","relation":"comparison","topic":"Grands noyaux et architectures convolutives simplifiées"}]}],"text":"Quand GoogLeNet remporte la classification de l'ILSVRC 2014, il n'utilise qu'environ 5 millions de paramètres, douze fois moins qu'AlexNet.\n\nCette efficacité est séduisante, mais quiconque veut modifier le réseau se heurte vite à des difficultés. L'article de GoogLeNet n'explique pas clairement d'où vient chaque choix de conception ; et le module Inception a tant de branches que, pour agrandir le modèle, le réflexe le plus naturel consiste à doubler le nombre de filtres de chaque groupe, ce qui multiplie par quatre à la fois le calcul et le nombre de paramètres.\n\nEn décembre 2015, Christian Szegedy, Vincent Vanhoucke, Sergey Ioffe et Jonathon Shlens, de Google, et Zbigniew Wojna, de l'University College London, publient cet article, présenté ensuite à CVPR 2016. Le « Rethinking » du titre désigne exactement cela : démonter Inception et tout repenser, pour voir quelles pratiques permettent d'agrandir le réseau tout en rentabilisant le calcul supplémentaire.\n\n\n> [!TIP]\n> \n> Pour la forme de base du module Inception, vous pouvez commencer par notre note :\n> \n> - **[[14.09] GoogLeNet : Ou encore Inception-V1](/blog/papers/classic-cnns/inception-v1)**\n\n\n## Définir le problème\n\nLa question à laquelle les auteurs veulent répondre : avec un budget de calcul limité, comment agrandir un réseau ?\n\nDe nombreuses expériences d'architecture, ils tirent quatre principes. Les auteurs restent eux-mêmes très prudents : ces principes comportent encore une part de spéculation, et il faudra davantage d'expériences pour en préciser le domaine de validité ; ils conseillent de ne s'y référer qu'en cas d'hésitation. Dans leurs expériences, toutefois, les réseaux qui s'en écartent nettement voient généralement leur qualité baisser, et remonter une fois corrigés.\n\n1. **Éviter les goulots d'étranglement de représentation, surtout au début du réseau.** De l'entrée à la sortie, la taille des caractéristiques doit diminuer progressivement, sans être brutalement écrasée dans une couche donnée. Les auteurs rappellent aussi que la dimension n'est qu'une estimation grossière de la quantité d'information.\n2. **Les représentations de haute dimension se traitent plus facilement localement.** Avec davantage d'activations par position, les caractéristiques se démêlent plus facilement, et l'entraînement va plus vite.\n3. **L'agrégation spatiale peut se faire en basse dimension.** Par exemple, réduire le nombre de canaux avant une convolution $3\\times3$ nuit peu à l'expressivité. Selon l'hypothèse des auteurs, les sorties de positions voisines sont fortement corrélées, et la réduction de dimension perd donc peu d'information.\n4. **Équilibrer largeur et profondeur.** Augmenter l'une ou l'autre améliore les résultats ; à calcul fixé, augmenter les deux à la fois donne le meilleur résultat.\n\nLes premiers gains de GoogLeNet venaient pour une bonne part de l'usage massif de convolutions $1\\times1$ pour réduire la dimension, autrement dit du principe 3. Les auteurs voient cette réduction comme un cas particulier de « factorisation des convolutions », et cherchent à présent d'autres façons de factoriser.\n\n## Résoudre le problème\n\n### Remplacer un 5×5 par deux couches 3×3\n\nLes grands noyaux de convolution coûtent cher. À nombre égal de canaux d'entrée et de sortie, une convolution $5\\times5$ coûte $25/9\\approx2.78$ fois plus qu'une $3\\times3$.\n\nMais un grand noyau voit aussi plus loin. Peut-on obtenir un champ de vision aussi large avec moins de paramètres ?\n\nLes auteurs regardent la convolution $5\\times5$ sous un autre angle : chaque sortie est un petit réseau entièrement connecté qui glisse sur une région $5\\times5$ de l'entrée. Puisqu'il s'agit d'un réseau de vision, ce petit réseau peut lui-même exploiter l'invariance par translation et se décomposer en deux couches : la première est une convolution $3\\times3$, la seconde est entièrement connectée sur la grille $3\\times3$ produite par la première. Faire glisser ce petit réseau à deux couches sur toute l'entrée revient à empiler deux convolutions $3\\times3$.\n\n[![Trois couches de grilles bleues superposées. En bas, une région d'entrée de 5×5 ; au milieu, une grille de 3×3 ; en haut, une case de sortie. Des traits rouges montrent que la case du haut est reliée à toute la grille 3×3 du milieu, et que chaque case du milieu est reliée à une région 3×3 en dessous](/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png)](/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png)\n\n*Figure 1 de l'article, extraite de la [**page 3 du PDF v3**](https://arxiv.org/pdf/1512.00567v3#page=3). Le petit réseau qui remplace la convolution $5\\times5$ : une sortie de la couche supérieure regarde $3\\times3$ cases de la couche du milieu, et chaque case du milieu regarde $3\\times3$ cases de l'entrée.*\n\nCalculons d'abord l'économie. Prenons une carte de caractéristiques de $35\\times35$ à 64 canaux, avec le même nombre de canaux en sortie :\n\n```python\nimport torch\nimport torch.nn as nn\n\nx = torch.randn(1, 64, 35, 35)                 # carte de caractéristiques 35×35, 64 canaux\n\nbig = nn.Conv2d(64, 64, 5, padding=2, bias=False)\nsmall = nn.Sequential(nn.Conv2d(64, 64, 3, padding=1, bias=False),\n                      nn.Conv2d(64, 64, 3, padding=1, bias=False))\n\ndef params(m):\n    return sum(p.numel() for p in m.parameters())\n\nprint(big(x).shape, small(x).shape)\nprint(\"paramètres 5×5 :\", params(big))\nprint(\"paramètres de deux couches 3×3 :\", params(small), f\"({params(small) / params(big):.0%})\")\n```\n\n```text\ntorch.Size([1, 64, 35, 35]) torch.Size([1, 64, 35, 35])\nparamètres 5×5 : 102400\nparamètres de deux couches 3×3 : 73728 (72%)\n```\n\nLa forme de sortie est la même, et il reste $(9+9)/25 = 72\\%$ des paramètres : 28 % d'économie. Dans un réseau convolutif, chaque poids sert exactement une fois par position de sortie ; le calcul diminue donc dans la même proportion. On suppose ici que la couche intermédiaire a autant de canaux que l'entrée ; l'analyse de l'article fait la même simplification.\n\nVérifions ensuite le champ de vision. Mettons à 1 les poids des deux couches $3\\times3$ et regardons le gradient de la sortie centrale par rapport à l'entrée :\n\n```python\nimport torch\nimport torch.nn as nn\n\nstack = nn.Sequential(nn.Conv2d(1, 1, 3, padding=1), nn.ReLU(),\n                      nn.Conv2d(1, 1, 3, padding=1))\nfor conv in (stack[0], stack[2]):              # poids à 1, pour que chaque connexion soit visible\n    nn.init.ones_(conv.weight)\n    nn.init.zeros_(conv.bias)\n\nx = torch.rand(1, 1, 9, 9, requires_grad=True)\nstack(x)[0, 0, 4, 4].backward()                # on ne regarde que la sortie centrale\n\nprint(x.grad[0, 0].int())\n```\n\n```text\ntensor([[0, 0, 0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 1, 2, 3, 2, 1, 0, 0],\n        [0, 0, 2, 4, 6, 4, 2, 0, 0],\n        [0, 0, 3, 6, 9, 6, 3, 0, 0],\n        [0, 0, 2, 4, 6, 4, 2, 0, 0],\n        [0, 0, 1, 2, 3, 2, 1, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0, 0, 0]], dtype=torch.int32)\n```\n\nLa zone non nulle fait exactement $5\\times5$. Chaque nombre indique combien de chemins mènent de ce point d'entrée à la sortie : 9 au centre, 1 seul dans les coins. Deux couches $3\\times3$ voient aussi loin qu'un $5\\times5$ ; simplement, les positions centrales pèsent davantage.\n\nCe remplacement soulève deux questions. D'abord, l'expressivité en souffre-t-elle ? Ensuite, puisque ce qu'on décompose est l'opération linéaire $5\\times5$, la première couche ne devrait-elle pas rester linéaire, sans ReLU ?\n\nLes auteurs mènent plusieurs expériences de contrôle ; l'une compare deux modèles Inception, l'un avec une activation linéaire dans la première couche issue de la décomposition, l'autre avec des ReLU dans les deux couches. Ils plafonnent respectivement à 76,2 % et 77,2 % de précision top-1 sur l'ensemble de validation. D'après les auteurs, la version linéaire est moins bonne dans toutes les expériences de contrôle ; leur explication : une non-linéarité de plus élargit l'éventail des variations que le réseau peut apprendre, surtout avec la batch normalization.\n\n### Décomposer encore en 1×n et n×1\n\nVu ainsi, tout noyau plus grand que $3\\times3$ peut être remplacé par une suite de $3\\times3$. Et le $3\\times3$ lui-même, peut-on le décomposer ?\n\nLe découper en deux couches $2\\times2$ n'économise que 11 %. Les auteurs trouvent mieux : les convolutions asymétriques. Un $3\\times1$ suivi d'un $1\\times3$ a le même champ de vision $3\\times3$.\n\n[![Un schéma étroit en haut et large en bas : à la base, une région d'entrée de 3×3 ; au milieu, une rangée de 3×1 cases ; au sommet, une case de sortie. Des traits rouges montrent que la sortie est reliée aux 3 cases de cette rangée, chacune étant reliée à une rangée entière de l'entrée](/content/papers/assets/26d9fd5f020cc9ce53cac89b03dbc710d155db812e4745d2e1c47a456faa3b1a.png)](/content/papers/assets/26d9fd5f020cc9ce53cac89b03dbc710d155db812e4745d2e1c47a456faa3b1a.png)\n\n*Figure 3 de l'article, extraite de la [**page 4 du PDF v3**](https://arxiv.org/pdf/1512.00567v3#page=4). Le petit réseau qui remplace la convolution $3\\times3$ : la couche inférieure est une convolution $3\\times1$ à 3 sorties.*\n\nVérifions de la même manière :\n\n```python\nimport torch\nimport torch.nn as nn\n\npair = nn.Sequential(nn.Conv2d(1, 1, (1, 3), padding=(0, 1)),   # 1×3 : ne regarde qu'à gauche et à droite\n                     nn.Conv2d(1, 1, (3, 1), padding=(1, 0)))   # 3×1 : ne regarde qu'en haut et en bas\nfor conv in pair:\n    nn.init.ones_(conv.weight)\n    nn.init.zeros_(conv.bias)\n\nx = torch.rand(1, 1, 7, 7, requires_grad=True)\npair(x)[0, 0, 3, 3].backward()\nprint(x.grad[0, 0].int())\n\nfor name, cost in [(\"3×3\", 9), (\"1×3 + 3×1\", 3 + 3), (\"deux couches 2×2\", 4 + 4),\n                   (\"7×7\", 49), (\"1×7 + 7×1\", 7 + 7)]:\n    print(f\"{name} : {cost}\")\n```\n\n```text\ntensor([[0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 1, 1, 1, 0, 0],\n        [0, 0, 1, 1, 1, 0, 0],\n        [0, 0, 1, 1, 1, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0],\n        [0, 0, 0, 0, 0, 0, 0]], dtype=torch.int32)\n3×3 : 9\n1×3 + 3×1 : 6\ndeux couches 2×2 : 8\n7×7 : 49\n1×7 + 7×1 : 14\n```\n\nLes dernières lignes donnent le nombre de multiplications par sortie et par paire de canaux d'entrée et de sortie. $1\\times3$ plus $3\\times1$ en demandent 6, un tiers de moins que $3\\times3$ ; deux couches $2\\times2$ en demandent 8, un neuvième de moins seulement. Plus le noyau est grand, plus l'économie est forte : un $7\\times7$ demande 49 multiplications, contre 14 seulement une fois décomposé en $1\\times7$ plus $7\\times1$.\n\nCette astuce ne marche pas partout, cependant. Les auteurs constatent qu'elle donne de mauvais résultats au début du réseau, mais de très bons sur des cartes de caractéristiques de taille moyenne (côté d'environ 12 à 20). Le réseau réel utilise un $1\\times7$ suivi d'un $7\\times1$ sur les cartes de caractéristiques $17\\times17$ :\n\n[![Schéma d'un module Inception : en bas, Base, d'où partent quatre branches. La plus à gauche enchaîne un 1x1 puis 1xn, nx1, 1xn, nx1, soit quatre couches ; la deuxième, un 1x1 puis 1xn et nx1 ; la troisième, un Pool puis un 1x1 ; la plus à droite, un simple 1x1. Les quatre branches se rejoignent dans Filter Concat](/content/papers/assets/d7b13cfd7a93816701d9571a2e87bd67983a5e6ffe9a7b93cbcf40e82db76a2f.png)](/content/papers/assets/d7b13cfd7a93816701d9571a2e87bd67983a5e6ffe9a7b93cbcf40e82db76a2f.png)\n\n*Figure 6 de l'article, extraite de la [**page 5 du PDF v3**](https://arxiv.org/pdf/1512.00567v3#page=5). Module Inception après décomposition des convolutions $n\\times n$ ; sur les cartes de caractéristiques $17\\times17$, les auteurs prennent $n=7$.*\n\nComparons-le au module d'origine de GoogLeNet, avec ses quatre branches $1\\times1$, $3\\times3$, $5\\times5$ et pooling. Ici, la branche la plus à gauche revient à décomposer deux couches $7\\times7$, chacune en une paire de convolutions asymétriques ; la deuxième branche décompose une seule couche $7\\times7$. La partie en $35\\times35$ utilise le module de la Figure 5, où le $5\\times5$ est remplacé par deux couches $3\\times3$.\n\nSur les plus petites cartes de caractéristiques, en $8\\times8$, les auteurs utilisent l'astuce autrement :\n\n[![Schéma d'un module Inception : la branche la plus à gauche enchaîne un 1x1 et un 3x3, puis se divise en deux convolutions côte à côte, 1x3 et 3x1 ; la deuxième branche, après un 1x1, se divise aussi en 1x3 et 3x1 ; s'y ajoutent un Pool suivi d'un 1x1, et un 1x1 seul. Toutes les sorties se rejoignent dans Filter Concat](/content/papers/assets/1475f4de3132dd0d1dbd081ddc453fb140796cb802987fa051a70356070b1b41.png)](/content/papers/assets/1475f4de3132dd0d1dbd081ddc453fb140796cb802987fa051a70356070b1b41.png)\n\n*Figure 7 de l'article, extraite de la [**page 5 du PDF v3**](https://arxiv.org/pdf/1512.00567v3#page=5). Module Inception à banc de filtres de sortie élargi, utilisé seulement sur les cartes de caractéristiques les plus grossières, en $8\\times8$.*\n\nNotez qu'ici, le $1\\times3$ et le $3\\times1$ sont **en parallèle** : leurs deux sorties vont directement à la concaténation finale, sans être enchaînées. Le nombre de canaux de sortie augmente ainsi, conformément au principe 2 : produire des représentations de haute dimension sur les dernières cartes de caractéristiques. Les auteurs ne l'utilisent qu'en $8\\times8$, car à ce stade, le traitement local des convolutions $1\\times1$ compte davantage que l'agrégation spatiale.\n\n### Le véritable rôle des classifieurs auxiliaires\n\nGoogLeNet accroche deux classifieurs auxiliaires au milieu du réseau ; l'idée était d'envoyer un gradient utile aux premières couches pour lutter contre la disparition du gradient et accélérer la convergence.\n\nEn y regardant de plus près, les auteurs constatent que les choses ne se passent pas ainsi. Au début de l'entraînement, les courbes avec et sans classifieurs auxiliaires sont presque confondues ; ce n'est que vers la fin que le réseau doté de classifieurs auxiliaires prend l'avantage, pour finir un peu plus haut. Retirer le classifieur auxiliaire placé le plus bas ne dégrade pas non plus la qualité finale.\n\nL'hypothèse de GoogLeNet, selon laquelle les branches auxiliaires aident les caractéristiques basses à évoluer, ne tient donc probablement pas, selon les auteurs. Leur nouvelle explication : les classifieurs auxiliaires sont une forme de **régularisation**. À l'appui, le classifieur principal fonctionne mieux quand la branche auxiliaire reçoit une batch normalization ou du dropout ; ajouter une batch normalization à la branche auxiliaire améliore la précision top-1 de 0,4 % en valeur absolue. Dans Inception-v3, le classifieur auxiliaire est branché sur la dernière carte de caractéristiques $17\\times17$.\n\nLes auteurs notent au passage que ce phénomène apporte un faible appui à l'hypothèse selon laquelle la batch normalization a un effet régularisateur.\n\n### Réduire les cartes de caractéristiques sans étrangler l'information\n\nLes réseaux convolutifs réduisent généralement leurs cartes de caractéristiques par pooling. Supposons qu'il faille passer de $35\\times35\\times320$ à $17\\times17\\times640$ ; il y a deux approches directes :\n\n- **Convolution puis pooling** : passer d'abord de 320 à 640 canaux en $35\\times35$, puis faire le pooling. L'information n'est pas étranglée, mais la convolution la plus coûteuse se fait sur la grande carte de caractéristiques.\n- **Pooling puis convolution** : réduire d'abord à $17\\times17$ par pooling, puis augmenter les canaux. C'est bien moins cher, mais il y a une étape intermédiaire où il ne reste que $17\\times17\\times320$, en violation du principe 1.\n\nFaisons un calcul approximatif avec une seule couche de convolution $3\\times3$ :\n\n```python\nd, k = 35, 320                               # 35×35×320, à transformer en 17×17×640\nh = 17\n\nconv_then_pool = d * d * k * (2 * k) * 9     # d'abord une convolution 3×3 320→640 en 35×35\npool_then_conv = h * h * k * (2 * k) * 9     # d'abord un pooling vers 17×17, puis 320→640\nparallel = h * h * k * k * 9                 # la convolution de pas 2 ne produit que 320 canaux, le pooling fournit l'autre moitié\n\nfor name, macs in [(\"convolution puis pooling\", conv_then_pool), (\"pooling puis convolution\", pool_then_conv), (\"convolution et pooling en parallèle\", parallel)]:\n    print(f\"{name} : {macs / 1e6:7.1f} M multiplications-additions\")\n\nprint(\"Pooling d'abord : au milieu, il ne reste que\", h * h * k, \"valeurs, contre\", d * d * k, \"en entrée\")\n```\n\n```text\nconvolution puis pooling :  2257.9 M multiplications-additions\npooling puis convolution :   532.7 M multiplications-additions\nconvolution et pooling en parallèle :   266.3 M multiplications-additions\nPooling d'abord : au milieu, il ne reste que 92480 valeurs, contre 392000 en entrée\n```\n\nFaire la convolution d'abord coûte plus de quatre fois plus que faire le pooling d'abord.\n\nLa solution des auteurs correspond à la troisième ligne : placer **en parallèle** une convolution de pas 2 et un pooling de pas 2, qui réduisent chacun directement la carte de caractéristiques, puis concaténer les canaux des deux côtés :\n\n[![Deux schémas côte à côte. À gauche, les opérations du module : de Base partent trois branches ; deux enchaînent un 1x1 et une convolution 3x3 de pas 2 (l'une avec, en plus, une couche 3x3 de pas 1 en amont), la troisième est un pooling de pas 2 ; le tout se rejoint dans Filter Concat. À droite, le point de vue des tailles de cartes de caractéristiques : 35x35x320 se sépare en conv et pool, qui donnent chacun 17x17x320, concaténés en 17x17x640](/content/papers/assets/9d6b75a1dd143d0b517f52adf42c4fe794cb400e3276a8109561db2277fb2fb6.png)](/content/papers/assets/9d6b75a1dd143d0b517f52adf42c4fe794cb400e3276a8109561db2277fb2fb6.png)\n\n*Figure 10 de l'article, extraite de la [**page 6 du PDF v3**](https://arxiv.org/pdf/1512.00567v3#page=6). À gauche, le module Inception qui réduit la carte de caractéristiques tout en augmentant le nombre de canaux ; à droite, la même opération vue sous l'angle des tailles de cartes de caractéristiques.*\n\nLe schéma de droite est le plus facile à lire : $35\\times35\\times320$ se sépare en deux voies ; la voie de convolution produit $17\\times17\\times320$, la voie de pooling aussi, et leur concaténation donne $17\\times17\\times640$. La convolution n'a à produire que la moitié des canaux, ce qui divise encore par deux le calcul par rapport à l'approche « pooling d'abord » ; et la sortie a directement 640 canaux, sans passer par l'étape écrasée.\n\n### Assembler les pièces\n\nLes auteurs assemblent toutes ces pièces en un nouveau réseau :\n\n| Type | Noyau / pas ou remarque | Taille d'entrée |\n| --- | --- | --- |\n| conv | $3\\times3$/2 | $299\\times299\\times3$ |\n| conv | $3\\times3$/1 | $149\\times149\\times32$ |\n| conv (avec remplissage) | $3\\times3$/1 | $147\\times147\\times32$ |\n| pool | $3\\times3$/2 | $147\\times147\\times64$ |\n| conv | $3\\times3$/1 | $73\\times73\\times64$ |\n| conv | $3\\times3$/2 | $71\\times71\\times80$ |\n| conv | $3\\times3$/1 | $35\\times35\\times192$ |\n| 3 × Inception | Comme la Figure 5 | $35\\times35\\times288$ |\n| 5 × Inception | Comme la Figure 6 | $17\\times17\\times768$ |\n| 2 × Inception | Comme la Figure 7 | $8\\times8\\times1280$ |\n| pool | $8\\times8$ | $8\\times8\\times2048$ |\n| linear | logits | $1\\times1\\times2048$ |\n| softmax | classifieur | $1\\times1\\times1000$ |\n\n*Tableau : extrait de la Table 1 de l'article. La taille d'entrée de chaque ligne est la taille de sortie de la ligne précédente.*\n\nLes trois couches de convolution $3\\times3$ du début résultent de la décomposition de la traditionnelle première couche $7\\times7$, selon la même idée que le remplacement d'un $5\\times5$ par deux couches $3\\times3$. Entre les trois étages Inception, des modules du type de la Figure 10 réduisent les cartes de caractéristiques. Le réseau compte 42 couches au total.\n\nVous vous demandez peut-être pourquoi l'entrée est en $299\\times299$, un nombre si étrange. Faisons le calcul avec les réglages du tableau :\n\n```python\ndef out(n, k, s, pad=0):\n    return (n + 2 * pad - k) // s + 1\n\nn = 299\nfor name, k, s, pad in [(\"conv 3×3/2\", 3, 2, 0), (\"conv 3×3/1\", 3, 1, 0), (\"conv 3×3/1 avec remplissage\", 3, 1, 1),\n                        (\"pool 3×3/2\", 3, 2, 0), (\"conv 3×3/1\", 3, 1, 0), (\"conv 3×3/2\", 3, 2, 0)]:\n    m = out(n, k, s, pad)\n    print(f\"{name} : {n} → {m}, reste {(n + 2 * pad - k) % s}\")\n    n = m\n\nfor name in [\"réduction à 17×17\", \"réduction à 8×8\"]:\n    m = out(n, 3, 2)\n    print(f\"{name} : {n} → {m}, reste {(n - 3) % 2}\")\n    n = m\n```\n\n```text\nconv 3×3/2 : 299 → 149, reste 0\nconv 3×3/1 : 149 → 147, reste 0\nconv 3×3/1 avec remplissage : 147 → 147, reste 0\npool 3×3/2 : 147 → 73, reste 0\nconv 3×3/1 : 73 → 71, reste 0\nconv 3×3/2 : 71 → 35, reste 0\nréduction à 17×17 : 35 → 17, reste 0\nréduction à 8×8 : 17 → 8, reste 0\n```\n\nChaque couche de pas 2 sans remplissage tombe juste, sans perdre la moindre rangée de pixels, et l'on aboutit aux $35$, $17$ et $8$ du tableau. L'article n'explique pas le choix de 299, mais cette valeur aligne effectivement tout le parcours au pixel près.\n\n### Rendre le modèle moins sûr de lui\n\nLa dernière pièce n'a rien à voir avec l'architecture : elle concerne les étiquettes.\n\nPour une image d'entraînement $x$, le modèle calcule avec un softmax la probabilité de chaque classe :\n\n$$\np(k\\mid x) = \\frac{\\exp(z_k)}{\\sum_{i=1}^{K}\\exp(z_i)}\n$$\n\n$z_k$ désigne les logits. On note $q(k\\mid x)$ la distribution de la vraie étiquette ; la perte d'entropie croisée s'écrit :\n\n$$\n\\ell = -\\sum_{k=1}^{K} \\log p(k)\\, q(k)\n$$\n\nSon gradient par rapport aux logits est très simple : $\\partial\\ell/\\partial z_k = p(k) - q(k)$, compris entre $-1$ et $1$.\n\nL'entraînement ordinaire utilise des étiquettes one-hot : pour la bonne classe $y$, $q(y)=1$, et 0 pour toutes les autres. Pour minimiser la perte, il faudrait que $p(y)$ vaille 1, ce qui est impossible avec des logits finis ; le seul moyen est de faire grandir indéfiniment l'écart entre $z_y$ et les autres logits.\n\nLes auteurs soulignent deux problèmes. D'abord, le modèle apprend à attribuer une confiance de cent pour cent à chaque image d'entraînement, ce qui ne se généralise pas forcément. Ensuite, l'écart entre le plus grand logit et les autres devient très grand, et comme le gradient est borné, le modèle a plus de mal à s'ajuster. Pour le dire crûment, le modèle est trop sûr de ses prédictions.\n\nLeur solution consiste à remplacer la distribution des étiquettes :\n\n$$\nq'(k\\mid x) = (1-\\epsilon)\\,\\delta_{k,y} + \\epsilon\\, u(k)\n$$\n\n$u(k)$ est une distribution fixe, indépendante de l'image ; les auteurs prennent la distribution uniforme $u(k)=1/K$. Cette méthode s'appelle label smoothing regularization (LSR), c'est-à-dire régularisation par lissage des étiquettes. Pour ImageNet, $K=1000$ classes et $\\epsilon=0.1$.\n\nTraitons directement les logits comme des paramètres, et voyons où les deux types d'étiquettes les poussent :\n\n```python\nimport torch\nimport torch.nn.functional as F\n\nK, eps, y = 1000, 0.1, 0\nhard = torch.zeros(K); hard[y] = 1\nsmooth = (1 - eps) * hard + eps / K\nprint(\"cible lissée : classe correcte\", round(smooth[y].item(), 4), \", autres classes\", round(smooth[1].item(), 4))\n\nfor name, q in [(\"one-hot\", hard), (\"label smoothing\", smooth)]:\n    z = torch.zeros(K, requires_grad=True)               # les logits eux-mêmes comme paramètres : où la perte les pousse-t-elle ?\n    opt = torch.optim.SGD([z], lr=1.0)\n    for step in range(1, 20001):\n        loss = -(q * F.log_softmax(z, 0)).sum()\n        opt.zero_grad(); loss.backward(); opt.step()\n        if step in (100, 1000, 20000):\n            gap = (z[y] - z[1:].max()).item()\n            print(f\"{name:15s} étape {step:5d} : avance du logit correct {gap:6.3f}\")\n\nprint(\"point d'arrivée du label smoothing : ln(0.9001 / 0.0001) =\", round(torch.log(torch.tensor(0.9001 / 0.0001)).item(), 3))\n```\n\n```text\ncible lissée : classe correcte 0.9001 , autres classes 0.0001\none-hot         étape   100 : avance du logit correct 11.417\none-hot         étape  1000 : avance du logit correct 13.805\none-hot         étape 20000 : avance du logit correct 16.810\nlabel smoothing étape   100 : avance du logit correct  9.105\nlabel smoothing étape  1000 : avance du logit correct  9.105\nlabel smoothing étape 20000 : avance du logit correct  9.105\npoint d'arrivée du label smoothing : ln(0.9001 / 0.0001) = 9.105\n```\n\nAvec des étiquettes one-hot, l'écart ne cesse de croître : plus l'entraînement dure, plus il est poussé loin. Avec des étiquettes lissées, l'écart s'arrête à 9,105. Cette valeur se calcule directement : au minimum de la perte, $p = q'$, et sous un softmax, l'écart de logit entre deux classes est égal au logarithme du rapport de leurs probabilités, soit $\\ln(0.9001/0.0001)$.\n\nLes auteurs en proposent aussi une autre lecture. En développant l'entropie croisée :\n\n$$\nH(q', p) = (1-\\epsilon)\\,H(q, p) + \\epsilon\\, H(u, p)\n$$\n\nCela revient à ajouter à la perte d'origine une pénalité : plus la distribution prédite $p$ s'éloigne de la distribution uniforme $u$, plus elle coûte cher.\n\nSur l'ILSVRC 2012, le LSR fait baisser l'erreur top-1 de 23,1 % à 22,8 %, et l'erreur top-5 de 6,3 % à 6,1 %.\n\n\n> [!NOTE]\n> \n> Quatre ans plus tard, Rafael Müller, Simon Kornblith et Geoffrey Hinton reviennent sur cette technique dans [When Does Label Smoothing Help?](https://arxiv.org/abs/1906.02629), à NeurIPS 2019. Ils constatent que le lissage des étiquettes améliore la calibration du modèle et resserre aussi les représentations de l'avant-dernière couche pour les exemples d'entraînement d'une même classe ; en contrepartie, les logits contiennent moins d'information sur « la ressemblance de cette image avec les autres classes », si bien qu'un modèle enseignant entraîné avec lissage des étiquettes donne de bien moins bons résultats en distillation des connaissances.\n\n\n### Réglages d'entraînement\n\nLes auteurs utilisent l'entraînement distribué de TensorFlow, avec 50 répliques tournant chacune sur un GPU NVIDIA Kepler, une taille de lot de 32 par réplique, pendant 100 époques.\n\nLes premières expériences utilisent le momentum ; le meilleur modèle passe à RMSProp (decay 0,9, $\\epsilon=1.0$). Le taux d'apprentissage est de 0,045, multiplié par 0,94 toutes les deux époques. L'écrêtage du gradient est fixé à 2,0 pour stabiliser l'entraînement ; l'évaluation utilise une moyenne mobile des paramètres.\n\n## Discussion\n\n### Ajouter les modifications une à une\n\n| Réseau | Erreur top-1 | Erreur top-5 | Coût (milliards d'opérations) |\n| --- | ---: | ---: | ---: |\n| GoogLeNet | 29 % | 9,2 % | 1,5 |\n| BN-GoogLeNet | 26,8 % | – | 1,5 |\n| BN-Inception | 25,2 % | 7,8 % | 2,0 |\n| Inception-v2 | 23,4 % | – | 3,8 |\n| + RMSProp | 23,1 % | 6,3 % | 3,8 |\n| + lissage des étiquettes | 22,8 % | 6,1 % | 3,8 |\n| + 7×7 factorisé | 21,6 % | 5,8 % | 4,8 |\n| + classifieur auxiliaire avec BN | **21,2 %** | **5,6 %** | 4,8 |\n\n*Tableau : extrait de la Table 3 de l'article. Ensemble de validation de l'ILSVRC 2012, recadrage unique. À partir d'Inception-v2, chaque ligne inclut toutes les modifications précédentes.*\n\nCe tableau est cumulatif : chaque ligne ajoute une modification à la précédente. La dernière ligne, « classifieur auxiliaire avec BN », signifie que la batch normalization est appliquée aussi à la couche entièrement connectée du classifieur auxiliaire, et pas seulement aux couches de convolution. **La version qui cumule toutes les modifications est celle que les auteurs appellent Inception-v3.**\n\nQuelques points à relever :\n\n- Le seul passage à la nouvelle architecture (ligne Inception-v2) fait baisser l'erreur top-1 de 25,2 % pour BN-Inception à 23,4 %, mais le coût passe aussi de 2,0 à 3,8.\n- RMSProp et le lissage des étiquettes n'augmentent pas le calcul et apportent chacun environ 0,3 point de pourcentage d'amélioration en top-1.\n- Décomposer la première couche $7\\times7$ en trois couches $3\\times3$ fait passer le coût de 3,8 à 4,8 et améliore le top-1 de 1,2 point de pourcentage : c'est le plus grand pas parmi les dernières modifications.\n\nAu total, Inception-v3 coûte environ 2,4 fois plus de calcul que BN-Inception et 3,2 fois plus que GoogLeNet.\n\n\n> [!TIP]\n> \n> Les noms sont un peu embrouillés. Cet article appelle Inception-v2 la nouvelle architecture, et Inception-v3 la version qui cumule toutes les modifications. Mais l'année suivante, en retraçant l'histoire de la famille, l'article d'Inception-v4 appelle Inception-v2 le BN-Inception, c'est-à-dire la version avec batch normalization. Quand vous rencontrez « Inception-v2 », vérifiez d'abord de laquelle il s'agit.\n> \n> Pour l'origine de BN-Inception, vous pouvez consulter notre note :\n> \n> - **[[15.02] BatchNorm : Normalisation par lots](/blog/papers/normalization/batchnorm)**\n\n\nToutes les évaluations portent sur les 48 238 images de l'ensemble de validation de l'ILSVRC 2012 qui ne figurent pas sur la liste noire. Les auteurs ont aussi essayé avec les 50 000 images : l'écart est d'environ 0,1 point de pourcentage en erreur top-5 et d'environ 0,2 point en erreur top-1.\n\n### Avec une résolution plus faible, combien perd-on ?\n\nLes systèmes de détection doivent souvent classer de petits morceaux d'image, où les objets sont petits et flous. On considère généralement qu'une résolution d'entrée plus élevée vaut mieux, mais les auteurs soulignent que deux choses se mélangent ici : la résolution du champ réceptif de la première couche, et la capacité et le calcul du modèle lui-même. Réduire seulement l'entrée sans toucher au modèle revient à attaquer un problème plus difficile avec un modèle beaucoup moins coûteux.\n\nIls fixent donc le calcul et ne changent que la résolution d'entrée. Quand l'entrée rapetisse, ils retirent un pas ou un pooling au début, pour que les cartes de caractéristiques suivantes gardent à peu près la même taille :\n\n| Taille du champ réceptif | Ajustement | Précision top-1 |\n| --- | --- | ---: |\n| $79\\times79$ | Pas de 1 dans la première couche, sans pooling ensuite | 75,2 % |\n| $151\\times151$ | Pas de 1 dans la première couche, max pooling ensuite | 76,4 % |\n| $299\\times299$ | Pas de 2 dans la première couche, max pooling ensuite | 76,6 % |\n\n*Tableau : extrait de la Table 2 de l'article ; les ajustements sont résumés d'après la description des expériences de la section 9.*\n\nLes trois réseaux ont presque le même coût de calcul. Les réseaux à basse résolution s'entraînent plus longtemps, mais leurs résultats finaux restent proches de celui en $299\\times299$ : $151\\times151$ ne perd que 0,2 point de pourcentage, et $79\\times79$, 1,4 point.\n\nLes auteurs en tirent une recommandation : dans les chaînes de détection du type R-CNN, on peut envisager des réseaux dédiés aux petits objets, à basse résolution mais au calcul non négligeable.\n\n### Comparaison avec d'autres modèles\n\nComparaison des modèles uniques, avec plusieurs recadrages :\n\n| Réseau | Recadrages | Erreur top-1 | Erreur top-5 |\n| --- | ---: | ---: | ---: |\n| GoogLeNet | 144 | – | 7,89 % |\n| VGG | – | 24,4 % | 6,8 % |\n| BN-Inception | 144 | 22 % | 5,82 % |\n| PReLU | – | 21,59 % | 5,71 % |\n| Inception-v3 | 12 | 19,47 % | 4,48 % |\n| **Inception-v3** | **144** | **18,77 %** | **4,2 %** |\n\n*Tableau : quelques lignes extraites de la Table 4 de l'article.*\n\nComparaison des ensembles de plusieurs modèles :\n\n| Réseau | Modèles | Recadrages | Erreur top-1 | Erreur top-5 |\n| --- | ---: | ---: | ---: | ---: |\n| VGGNet | 2 | – | 23,7 % | 6,8 % |\n| GoogLeNet | 7 | 144 | – | 6,67 % |\n| PReLU | – | – | – | 4,94 % |\n| BN-Inception | 6 | 144 | 20,1 % | 4,9 % |\n| **Inception-v3** | **4** | **144** | **17,2 %** | **3,58 %** |\n\n*Tableau : extrait de la Table 5 de l'article. Les 3,58 % d'Inception-v3 sont un résultat sur l'ensemble de test ; les autres viennent de l'ensemble de validation.*\n\nDans leur conclusion, les auteurs se comparent au réseau PReLU de He et al. : Inception-v3 réduit les erreurs top-5 et top-1 de 25 % et 14 % en valeur relative, pour un calcul six fois moins coûteux et au moins cinq fois moins de paramètres (les auteurs précisent qu'il s'agit d'une estimation). L'ensemble de quatre modèles atteint une erreur top-5 environ deux fois plus faible que celle de l'ensemble de GoogLeNet vainqueur en 2014.\n\n## Conclusion\n\nCet article se lit plutôt comme un carnet de conception. La Table 3 cumule les modifications une à une et rend visible la contribution de chacune ; quant aux quatre principes de conception, les auteurs les présentent franchement comme des règles empiriques qui restent à valider.\n\nFaisons pour finir l'inventaire des pièces laissées par cet article :\n\n1. **Décomposer les grands noyaux en petits** : un $5\\times5$ devient deux couches $3\\times3$, un $n\\times n$ devient un $1\\times n$ suivi d'un $n\\times1$.\n2. **Pour réduire les cartes de caractéristiques, placer convolution et pooling en parallèle**, afin de ne pas étrangler l'information.\n3. **Les classifieurs auxiliaires servent plutôt de régularisation.**\n4. **Le lissage des étiquettes**, pour que le modèle ne soit pas trop sûr de ses réponses.\n\nS'il ne fallait en garder qu'une, ce serait sans doute le lissage des étiquettes : indépendant de l'architecture, il s'ajoute en quelques lignes de code, et figure aussi dans la recette d'entraînement de [ConvNeXt](/blog/papers/classic-cnns/convnext). La version suivante d'Inception va rencontrer ResNet ; nous la verrons dans [la note suivante](/blog/papers/classic-cnns/inception-v4).\n","imageSizes":{"/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png":{"width":419,"height":358},"/content/papers/assets/26d9fd5f020cc9ce53cac89b03dbc710d155db812e4745d2e1c47a456faa3b1a.png":{"width":293,"height":401},"/content/papers/assets/d7b13cfd7a93816701d9571a2e87bd67983a5e6ffe9a7b93cbcf40e82db76a2f.png":{"width":623,"height":824},"/content/papers/assets/1475f4de3132dd0d1dbd081ddc453fb140796cb802987fa051a70356070b1b41.png":{"width":625,"height":539},"/content/papers/assets/9d6b75a1dd143d0b517f52adf42c4fe794cb400e3276a8109561db2277fb2fb6.png":{"width":635,"height":365}}}