{"notes":[{"id":"classic-cnns/inception-v3","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Inception-v3","subtitle":"大きなカーネルの退場","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":"ja","path":"/content/papers/ja/classic-cnns/inception-v3.1a1cc69c4ec2.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"55を33の2層に分ける","text":"5×5を3×3の2層に分ける","depth":3},{"id":"さらに1nとn1に分ける","text":"さらに1×nとn×1に分ける","depth":3},{"id":"補助分類器の本当の役割","text":"補助分類器の本当の役割","depth":3},{"id":"特徴マップを縮めつつ情報をせき止めない","text":"特徴マップを縮めつつ、情報をせき止めない","depth":3},{"id":"部品を組み立てる","text":"部品を組み立てる","depth":3},{"id":"モデルに自信を持たせすぎない","text":"モデルに自信を持たせすぎない","depth":3},{"id":"学習設定","text":"学習設定","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"一つずつ加えていく","text":"一つずつ加えていく","depth":3},{"id":"解像度を下げるとどれだけ違うか","text":"解像度を下げると、どれだけ違うか？","depth":3},{"id":"ほかのモデルと比べる","text":"ほかのモデルと比べる","depth":3},{"id":"結論","text":"結論","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":"またの名を 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":"ja","path":"/content/papers/ja/classic-cnns/inception-v1.e67514209915.md","headings":[{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"inception-モジュール","text":"Inception モジュール","depth":3},{"id":"パラメータ設定","text":"パラメータ設定","depth":3},{"id":"モデルアーキテクチャ","text":"モデルアーキテクチャ","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"ilsvrc-2014-でのパフォーマンス","text":"ILSVRC 2014 でのパフォーマンス","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/resnext","relation":"comparison","topic":"分岐・グループ畳み込み・特徴の再利用"},{"id":"classic-cnns/cspnet","relation":"comparison","topic":"分岐・グループ畳み込み・特徴の再利用"}]},{"id":"normalization/batchnorm","category":"normalization","legacyPath":"normalization/1502-batchnorm","legacySlug":"1502-batchnorm","legacyPaths":[],"title":"BatchNorm","subtitle":"バッチ正規化","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":"ja","path":"/content/papers/ja/normalization/batchnorm.0bdafbaf4990.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"学習率の向上","text":"学習率の向上","depth":3},{"id":"dropout-は不要","text":"Dropout は不要","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"mnist-実験での結果","text":"MNIST 実験での結果","depth":3},{"id":"imagenet-実験での結果","text":"ImageNet 実験での結果","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{"定義問題":"問題の定義","解決問題":"問題の解決","討論":"考察"},"guide":null,"relatedReading":[{"id":"normalization/layernorm","relation":"next","topic":"正規化する軸の選び方"}]},{"id":"classic-cnns/convnext","category":"classic-cnns","legacyPath":"classic-cnns/2201-convnext","legacySlug":"2201-convnext","legacyPaths":[],"title":"ConvNeXt","subtitle":"卷積を再び偉大に","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":"ja","path":"/content/papers/ja/classic-cnns/convnext.4e647352c822.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"解決策","text":"解決策","depth":2},{"id":"ネットワークアーキテクチャの再設計","text":"ネットワークアーキテクチャの再設計","depth":3},{"id":"現代的なトレーニング技術の導入","text":"現代的なトレーニング技術の導入","depth":3},{"id":"マクロ設計","text":"マクロ設計","depth":3},{"id":"resnext-化","text":"ResNeXt 化","depth":3},{"id":"逆瓶頸","text":"逆瓶頸","depth":3},{"id":"大きな畳み込み核","text":"大きな畳み込み核","depth":3},{"id":"微細設計","text":"微細設計","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"モデル設定の概要","text":"モデル設定の概要","depth":3},{"id":"imagenet-上での性能","text":"ImageNet 上での性能","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"vision-transformers/convmixer","relation":"comparison","topic":"畳み込みによる画像パッチの混合"},{"id":"vision-transformers/caformer","relation":"comparison","topic":"畳み込みによる画像パッチの混合"},{"id":"reparameterization/replknet","relation":"comparison","topic":"大きなカーネルと簡潔な畳み込み骨格"}]}],"text":"GoogLeNetがILSVRC 2014の分類部門で優勝したとき、使ったパラメータは約500万個だけで、AlexNetの12分の1でした。\n\nこの効率は魅力的ですが、手を加えようとするとすぐに壁にぶつかります。GoogLeNetの論文は、それぞれの設計判断がどこから来たのかをはっきり説明していません。しかもInceptionモジュールには分岐がたくさんあります。モデルを大きくしようとして、最も直観的にすべてのフィルタ群の数を2倍にすると、計算量もパラメータ数も一緒に4倍になってしまいます。\n\n2015年12月、GoogleのChristian Szegedy、Vincent Vanhoucke、Sergey Ioffe、Jonathon Shlensと、ユニバーシティ・カレッジ・ロンドンのZbigniew Wojnaがこの論文を公開し、のちにCVPR 2016で発表しました。タイトルの「Rethinking」が指しているのはこのことです。Inceptionを分解して考え直し、ネットワークを大きくしながら、増えた計算を無駄なく生かせるやり方を探ります。\n\n\n> [!TIP]\n> \n> Inceptionモジュールの基本的な形は、先に私たちのノートで確認できます。\n> \n> - **[[14.09] GoogLeNet：またの名を Inception-V1](/blog/papers/classic-cnns/inception-v1)**\n\n\n## 問題の定義\n\n著者らが答えようとした問いは、計算の予算が限られているとき、ネットワークをどう大きくするか、です。\n\n彼らは大量のアーキテクチャ実験から、四つの原則をまとめました。著者ら自身はかなり控えめで、これらの原則にはまだ推測が含まれ、適用範囲を確かめるにはさらに実験が必要であり、判断に迷ったときにだけ参考にするよう勧めています。ただ、実験でこれらに明らかに反したネットワークは、たいてい品質が落ち、直すとまた良くなりました。\n\n1. **表現のボトルネックを避ける、特にネットワークの前半で**。入力から出力に向かって、特徴の大きさはゆっくり縮めるべきで、ある層で急に押しつぶしてはいけません。著者らは、次元は情報量の大まかな目安にすぎないとも注意しています。\n2. **高次元の表現は局所的に処理しやすい**。位置ごとの活性化の数を増やすと、特徴を解きほぐしやすくなり、学習も速くなります。\n3. **空間的な集約は低次元で行える**。たとえば$3\\times3$畳み込みの前にチャネル数を減らしても、表現力はあまり損なわれません。著者らの推測では、隣り合う位置の出力は相関が強いので、次元を減らしても情報はあまり失われません。\n4. **幅と深さのバランスをとる**。どちらを増やしても良くなりますが、計算量が一定なら、幅と深さを同時に増やすのが最も効果的です。\n\nGoogLeNetの初期の成果の多くは、$1\\times1$畳み込みによる次元削減を大量に使ったこと、つまり3つ目の原則から来ています。著者らは次元削減を「畳み込みの分解」の特殊な場合とみなし、ほかの分解方法を探していきます。\n\n## 問題の解決\n\n### 5×5を3×3の2層に分ける\n\n大きな畳み込みカーネルは高くつきます。入力と出力のチャネル数が同じなら、$5\\times5$畳み込みの計算量は$3\\times3$の$25/9\\approx2.78$倍です。\n\nしかし、大きなカーネルはそのぶん遠くまで見渡せます。より少ないパラメータで、同じ広さの視野を得られないでしょうか？\n\n著者らは$5\\times5$畳み込みを別の角度から見ました。各出力は、入力上の$5\\times5$の領域をスライドする小さな全結合ネットワークです。視覚のネットワークなのだから、この小さなネットワーク自体にも平行移動不変性を利用して、2層に分けられます。1層目は$3\\times3$畳み込み、2層目は1層目の出力の$3\\times3$のマス目に対する全結合です。この2層の小さなネットワークを入力全体でスライドさせれば、$3\\times3$畳み込みを2層重ねたものと同じになります。\n\n[![青いマス目が3層重なっている。最下層は5×5の入力領域、中間は3×3のマス目、最上層は1マスの出力。赤い線は、最上層のマスが中間の3×3領域全体につながり、中間の各マスがさらに下の3×3領域につながることを示す](/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png)](/content/papers/assets/c87d3d6fa9ea76d954eba2570f702150eca32d62c7cdb3d724075a4be9a63080.png)\n\n*原論文Figure 1。[**v3 PDFの3ページ**](https://arxiv.org/pdf/1512.00567v3#page=3)から抜粋。$5\\times5$畳み込みを置き換える小さなネットワーク：上の層の1つの出力が中間層の$3\\times3$を見て、中間層の各マスがさらに入力の$3\\times3$を見ます。*\n\nまず、どれだけ節約できるかを計算します。$35\\times35$、64チャネルの特徴マップで、出力チャネル数は変えません。\n\n```python\nimport torch\nimport torch.nn as nn\n\nx = torch.randn(1, 64, 35, 35)                 # 35×35の特徴マップ、64チャネル\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(\"5×5のパラメータ：\", params(big))\nprint(\"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])\n5×5のパラメータ： 102400\n3×3を二層重ねたパラメータ： 73728 （72%）\n```\n\n出力の形は同じで、パラメータは$(9+9)/25 = 72\\%$に減り、28%の節約です。畳み込みネットワークでは各重みが出力位置ごとにちょうど1回ずつ使われるので、計算量も同じ割合だけ減ります。ここでは中間層のチャネル数を入力と同じと仮定しています。論文の分析も同じように単純化しています。\n\n次に視野を確かめます。2層の$3\\times3$の重みをすべて1にして、中心の出力1つの入力に対する勾配を見ます。\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]):              # 重みを1にして、すべての接続を見えるようにする\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()                # 中心の出力1つだけを見る\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\nゼロでない領域はちょうど$5\\times5$です。マス目の数字は「この入力点から出力までの道が何本あるか」で、中心は9本、角は1本だけです。$3\\times3$の2層は$5\\times5$と同じ遠さまで見ていて、ただ中央の位置がより重く見られています。\n\nこの置き換えには二つの疑問が残ります。一つ目、表現力は落ちないのか。二つ目、分解したいのは$5\\times5$という線形演算なのだから、1層目は線形のままにして、ReLUを入れないほうがよいのではないか。\n\n著者らはいくつかの対照実験を行いました。その一つは二つのInceptionモデルの比較で、一方は分解した1層目に線形の活性化を、もう一方は2層ともReLUを使います。検証セットでのtop-1正解率は、最終的にそれぞれ76.2%と77.2%に落ち着きました。著者らによれば、どの対照実験でも線形版のほうが悪い結果でした。非線形の層が一つ増えるとネットワークが学べる変化が増えるため、という説明で、batch normalizationを加えたときに特にはっきりするとしています。\n\n### さらに1×nとn×1に分ける\n\nこう考えると、$3\\times3$より大きなカーネルは、すべて$3\\times3$の連なりに置き換えられます。では、$3\\times3$はさらに分けられるでしょうか？\n\n$2\\times2$の2層に分けても、11%しか節約できません。著者らはもっと良い分け方を見つけました。非対称な畳み込みです。$3\\times1$の後に$1\\times3$を行えば、視野は同じく$3\\times3$です。\n\n[![下が広く上が狭い模式図。底面は3×3の入力領域、中間に3×1の3マス、頂上に1マスの出力。赤い線は、出力がまず中間の3マスにつながり、その3マスがそれぞれ入力の1行分全体につながることを示す](/content/papers/assets/26d9fd5f020cc9ce53cac89b03dbc710d155db812e4745d2e1c47a456faa3b1a.png)](/content/papers/assets/26d9fd5f020cc9ce53cac89b03dbc710d155db812e4745d2e1c47a456faa3b1a.png)\n\n*原論文Figure 3。[**v3 PDFの4ページ**](https://arxiv.org/pdf/1512.00567v3#page=4)から抜粋。$3\\times3$畳み込みを置き換える小さなネットワーク：下の層は、出力が3つある$3\\times1$畳み込みです。*\n\n同じ方法で確かめます。\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：左右だけを見る\n                     nn.Conv2d(1, 1, (3, 1), padding=(1, 0)))   # 3×1：上下だけを見る\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), (\"二層の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\n二層の2×2：8\n7×7：49\n1×7 + 7×1：14\n```\n\n下の数行は、出力1つ、入出力チャネルの組1つあたりに必要な乗算の回数です。$1\\times3$と$3\\times1$の組み合わせは6回で、$3\\times3$より3分の1少なくなります。$2\\times2$の2層は8回で、9分の1しか減りません。カーネルが大きいほど節約も大きく、$7\\times7$なら49回必要なところが、$1\\times7$と$7\\times1$に分ければ14回で済みます。\n\nただし、この手が効く場所は限られています。著者らは、ネットワークの前半に置くとうまくいかず、中くらいの大きさの特徴マップ（一辺がおよそ12〜20）に置くととてもうまくいくことに気づきました。実際のネットワークでは、$17\\times17$の特徴マップで$1\\times7$の後に$7\\times1$を続けています。\n\n[![Inceptionモジュールの模式図：最下部がBaseで、上に向かって4本の分岐に分かれる。最も左は1x1の後に1xn、nx1、1xn、nx1の計4層。2本目は1x1の後に1xn、nx1。3本目はPoolの後に1x1。最も右は1x1だけ。4本の分岐は最後にFilter Concatで合流する](/content/papers/assets/d7b13cfd7a93816701d9571a2e87bd67983a5e6ffe9a7b93cbcf40e82db76a2f.png)](/content/papers/assets/d7b13cfd7a93816701d9571a2e87bd67983a5e6ffe9a7b93cbcf40e82db76a2f.png)\n\n*原論文Figure 6。[**v3 PDFの5ページ**](https://arxiv.org/pdf/1512.00567v3#page=5)から抜粋。$n\\times n$畳み込みを分解したInceptionモジュール。$17\\times17$の特徴マップでは、著者らは$n=7$としています。*\n\nGoogLeNetの元のモジュールと比べてみましょう。元は$1\\times1$、$3\\times3$、$5\\times5$、プーリングの4本の分岐でした。ここで最も左の分岐は、$7\\times7$を2層重ね、それぞれを非対称な畳み込みの組に分けたものに相当します。2本目は、$7\\times7$を1層分けたものです。$35\\times35$の区間ではFigure 5のモジュール、つまり$5\\times5$を$3\\times3$の2層に置き換えたものを使います。\n\n最も小さい$8\\times8$の特徴マップでは、著者らは別の使い方をしています。\n\n[![Inceptionモジュールの模式図：最も左の分岐は1x1、3x3の後、1x3と3x1の二つの畳み込みに並列に分かれる。2本目は1x1の後、1x3と3x1に並列に分かれる。ほかにPoolの後の1x1と、単独の1x1がある。すべての出力はFilter Concatで合流する](/content/papers/assets/1475f4de3132dd0d1dbd081ddc453fb140796cb802987fa051a70356070b1b41.png)](/content/papers/assets/1475f4de3132dd0d1dbd081ddc453fb140796cb802987fa051a70356070b1b41.png)\n\n*原論文Figure 7。[**v3 PDFの5ページ**](https://arxiv.org/pdf/1512.00567v3#page=5)から抜粋。出力フィルタを拡張したInceptionモジュールで、最も粗い$8\\times8$の特徴マップでだけ使います。*\n\nここでは$1\\times3$と$3\\times1$が**並列**になっていることに注意してください。二つの出力は直列につながらず、そのまま最後の連結に入ります。こうすると出力のチャネル数が増えます。2つ目の原則、つまり最後の特徴マップで高次元の表現を作ることに対応しています。著者らがこれを$8\\times8$でだけ使うのは、この段階では、$1\\times1$畳み込みによる局所的な処理のほうが、空間的な集約より重要だからです。\n\n### 補助分類器の本当の役割\n\nGoogLeNetはネットワークの途中に補助分類器を2つ付けていました。もともとの狙いは、有用な勾配を前の方の層に届けて勾配消失に対抗し、収束を速めることでした。\n\n著者らが改めて観察すると、実際はそうなっていませんでした。学習の前半では、補助分類器のある場合とない場合の2本の曲線はほとんど同じです。学習が終わりに近づいてようやく、補助分類器のあるネットワークが前に出始め、最後は少し高いところで落ち着きます。低い位置にある方の補助分類器を外しても、最終的な品質は落ちませんでした。\n\nそのため著者らは、補助分岐が下位層の特徴の発達を助けるというGoogLeNetの当初の仮説は、おそらく成り立たないと考えています。彼らの新しい説明は、補助分類器は一種の**正則化**だ、というものです。根拠は、補助分岐にbatch normalizationやdropoutを加えると、主分類器の成績が良くなることです。補助分岐にbatch normalizationを加えると、top-1正解率は絶対値で0.4%上がります。Inception-v3の補助分類器は、最後の$17\\times17$の特徴マップの上に接続されています。\n\n著者らはついでに、この現象は「batch normalizationには正則化の効果がある」という推測を弱いながら支持する、とも述べています。\n\n### 特徴マップを縮めつつ、情報をせき止めない\n\n畳み込みネットワークは、普通はプーリングで特徴マップを縮めます。$35\\times35\\times320$を$17\\times17\\times640$にしたいとすると、素直なやり方は二つあります。\n\n- **畳み込みの後にプーリング**：まず$35\\times35$上でチャネルを320から640に増やし、それからプーリングします。情報はせき止められませんが、最も高くつく畳み込みを大きな特徴マップの上で行うことになります。\n- **プーリングの後に畳み込み**：先に$17\\times17$までプーリングし、それからチャネルを増やします。ずっと安くなりますが、途中に$17\\times17\\times320$しか残らない段階があり、1つ目の原則に反します。\n\n$3\\times3$畳み込み1層で、ざっと計算してみましょう。\n\n```python\nd, k = 35, 320                               # 35×35×320を17×17×640にしたい\nh = 17\n\nconv_then_pool = d * d * k * (2 * k) * 9     # 先に35×35上で320→640の3×3畳み込み\npool_then_conv = h * h * k * (2 * k) * 9     # 先に17×17までプーリングしてから320→640\nparallel = h * h * k * k * 9                 # ストライド2の畳み込みは320チャネルだけ出し、残り半分はプーリングに任せる\n\nfor name, macs in [(\"畳み込み→プーリング\", conv_then_pool), (\"プーリング→畳み込み\", pool_then_conv), (\"畳み込みとプーリングを並列\", parallel)]:\n    print(f\"{name}：{macs / 1e6:7.1f} M回の積和演算\")\n\nprint(\"先にプーリングすると、途中に残るのは\", h * h * k, \"個の数。入力は\", d * d * k, \"個\")\n```\n\n```text\n畳み込み→プーリング： 2257.9 M回の積和演算\nプーリング→畳み込み：  532.7 M回の積和演算\n畳み込みとプーリングを並列：  266.3 M回の積和演算\n先にプーリングすると、途中に残るのは 92480 個の数。入力は 392000 個\n```\n\n先に畳み込む方法の計算量は、先にプーリングする方法の4倍以上です。\n\n著者らの解決策は3行目です。ストライド2の畳み込みとストライド2のプーリングを**並列**に置き、それぞれが直接特徴マップを縮め、両方のチャネルを連結します。\n\n[![左右2枚の図。左はモジュールの演算：Baseから上に3本の分岐に分かれ、2本は1x1の後にストライド2の3x3畳み込み（うち1本はその前にストライド1の3x3がもう1層ある）、3本目はストライド2のプーリングで、最後にFilter Concatで合流する。右は特徴マップの大きさから見たもの：35x35x320がconvとpoolの二手に分かれ、それぞれ17x17x320になり、連結して17x17x640になる](/content/papers/assets/9d6b75a1dd143d0b517f52adf42c4fe794cb400e3276a8109561db2277fb2fb6.png)](/content/papers/assets/9d6b75a1dd143d0b517f52adf42c4fe794cb400e3276a8109561db2277fb2fb6.png)\n\n*原論文Figure 10。[**v3 PDFの6ページ**](https://arxiv.org/pdf/1512.00567v3#page=6)から抜粋。左は特徴マップを縮めながらチャネルを増やすInceptionモジュール、右は同じことを特徴マップの大きさの観点から見たものです。*\n\n右の図が一番読みやすいでしょう。$35\\times35\\times320$が二手に分かれ、畳み込みの側は$17\\times17\\times320$を、プーリングの側も$17\\times17\\times320$を出力し、連結すると$17\\times17\\times640$になります。畳み込みは半分のチャネルを出力するだけでよいので、計算量は先にプーリングする方法よりさらに半分になります。しかも出力は最初から640チャネルで、押しつぶされる段階を経ません。\n\n### 部品を組み立てる\n\n著者らは、ここまでの部品を組み合わせて新しいネットワークを作りました。\n\n| 種類 | カーネル／ストライドまたは説明 | 入力サイズ |\n| --- | --- | --- |\n| conv | $3\\times3$／2 | $299\\times299\\times3$ |\n| conv | $3\\times3$／1 | $149\\times149\\times32$ |\n| conv（パディングあり） | $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 | Figure 5と同じ | $35\\times35\\times288$ |\n| 5 × Inception | Figure 6と同じ | $17\\times17\\times768$ |\n| 2 × Inception | Figure 7と同じ | $8\\times8\\times1280$ |\n| pool | $8\\times8$ | $8\\times8\\times2048$ |\n| linear | logits | $1\\times1\\times2048$ |\n| softmax | 分類器 | $1\\times1\\times1000$ |\n\n*表：原論文Table 1から抜粋。各行の入力サイズは、一つ上の行の出力サイズです。*\n\n最初の3層の$3\\times3$畳み込みは、従来の$7\\times7$の第1層を分解した結果で、$5\\times5$を$3\\times3$の2層に置き換えたのと同じ考え方です。3段のInceptionのあいだでは、Figure 10のようなモジュールで特徴マップを縮めます。ネットワーク全体は42層です。\n\n入力がなぜ$299\\times299$という半端な数なのか、気になるかもしれません。表の設定どおりに計算してみましょう。\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 パディング\", 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}、余り {(n + 2 * pad - k) % s}\")\n    n = m\n\nfor name in [\"17×17に縮小\", \"8×8に縮小\"]:\n    m = out(n, 3, 2)\n    print(f\"{name}：{n} → {m}、余り {(n - 3) % 2}\")\n    n = m\n```\n\n```text\nconv 3×3/2：299 → 149、余り 0\nconv 3×3/1：149 → 147、余り 0\nconv 3×3/1 パディング：147 → 147、余り 0\npool 3×3/2：147 → 73、余り 0\nconv 3×3/1：73 → 71、余り 0\nconv 3×3/2：71 → 35、余り 0\n17×17に縮小：35 → 17、余り 0\n8×8に縮小：17 → 8、余り 0\n```\n\nストライド2でパディングなしの層は、どれもちょうど割り切れていて、画素が1行も捨てられず、最後は表の$35$、$17$、$8$に収まります。論文は299を選んだ理由を説明していませんが、この数字のおかげで、経路全体がきれいにそろっているのは確かです。\n\n### モデルに自信を持たせすぎない\n\n最後の部品はアーキテクチャとは関係なく、ラベルを扱います。\n\n学習画像$x$に対して、モデルはsoftmaxで各クラスの確率を計算します。\n\n$$\np(k\\mid x) = \\frac{\\exp(z_k)}{\\sum_{i=1}^{K}\\exp(z_i)}\n$$\n\n$z_k$はlogitsです。正解ラベルの分布を$q(k\\mid x)$と書くと、交差エントロピー損失は次のとおりです。\n\n$$\n\\ell = -\\sum_{k=1}^{K} \\log p(k)\\, q(k)\n$$\n\nlogitsに対する勾配は単純で、$\\partial\\ell/\\partial z_k = p(k) - q(k)$です。大きさは$-1$から$1$のあいだに収まります。\n\n通常の学習ではone-hotラベルを使います。正解クラス$y$は$q(y)=1$、ほかはすべて0です。損失を最小にするには$p(y)$が1にならなければなりませんが、logitsが有限ではそれは不可能なので、$z_y$をほかのlogitsよりどこまでも大きくしていくしかありません。\n\n著者らは、これが二つの問題を生むと指摘します。一つ目に、モデルはどの学習画像にも100%の確信を示すようになり、それがうまく汎化するとは限りません。二つ目に、最大のlogitとほかのlogitsの差が大きく押し広げられ、しかも勾配には上限があるので、モデルが後から調整しにくくなります。平たく言えば、モデルが自分の予測に自信を持ちすぎるのです。\n\n彼らの方法は、ラベルの分布を置き換えることです。\n\n$$\nq'(k\\mid x) = (1-\\epsilon)\\,\\delta_{k,y} + \\epsilon\\, u(k)\n$$\n\n$u(k)$は画像に依存しない固定の分布で、著者らは一様分布$u(k)=1/K$を使います。この方法をlabel smoothing regularization（LSR）と呼びます。ImageNetでは$K=1000$クラス、$\\epsilon=0.1$です。\n\nlogitsを直接パラメータとして扱い、2種類のラベルがそれをどこまで押しやるかを見てみましょう。\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(\"平滑化後の目標：正解クラス\", round(smooth[y].item(), 4), \"、ほかのクラス\", round(smooth[1].item(), 4))\n\nfor name, q in [(\"one-hot\", hard), (\"label smoothing\", smooth)]:\n    z = torch.zeros(K, requires_grad=True)               # logitsを直接パラメータにして、損失がそれをどこへ押しやるかを見る\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} {step:5d}ステップ目：正解クラスのlogitのリード {gap:6.3f}\")\n\nprint(\"label smoothingの到達点：ln(0.9001 / 0.0001) =\", round(torch.log(torch.tensor(0.9001 / 0.0001)).item(), 3))\n```\n\n```text\n平滑化後の目標：正解クラス 0.9001 、ほかのクラス 0.0001\none-hot           100ステップ目：正解クラスのlogitのリード 11.417\none-hot          1000ステップ目：正解クラスのlogitのリード 13.805\none-hot         20000ステップ目：正解クラスのlogitのリード 16.810\nlabel smoothing   100ステップ目：正解クラスのlogitのリード  9.105\nlabel smoothing  1000ステップ目：正解クラスのlogitのリード  9.105\nlabel smoothing 20000ステップ目：正解クラスのlogitのリード  9.105\nlabel smoothingの到達点：ln(0.9001 / 0.0001) = 9.105\n```\n\none-hotでは差が伸び続け、学習させた分だけ押し広げられます。平滑化したラベルに替えると、差は9.105で止まります。この数字は直接計算できます。損失が最小になるとき$p = q'$で、softmaxでは二つのクラスのlogitの差が確率の比の対数に等しいので、$\\ln(0.9001/0.0001)$になります。\n\n著者らはもう一つの見方も示しています。交差エントロピーを展開すると次のようになります。\n\n$$\nH(q', p) = (1-\\epsilon)\\,H(q, p) + \\epsilon\\, H(u, p)\n$$\n\n元の損失に、罰則の項を一つ加えたことになります。予測分布$p$が一様分布$u$から離れすぎると、その代償を払うわけです。\n\nILSVRC 2012では、LSRを加えるとtop-1誤り率が23.1%から22.8%に、top-5が6.3%から6.1%に下がりました。\n\n\n> [!NOTE]\n> \n> 4年後、Rafael Müller、Simon Kornblith、Geoffrey HintonはNeurIPS 2019の[When Does Label Smoothing Help?](https://arxiv.org/abs/1906.02629)で、この技法を改めて研究しました。label smoothingはモデルのキャリブレーションを改善し、同じクラスの学習サンプルの最後から2番目の層の表現をより密にまとめることがわかりました。代わりに、logitsに含まれる「この画像がほかのクラスとどれだけ似ているか」の情報が減るので、label smoothingで学習させた教師モデルでは、知識蒸留の効果がずっと悪くなります。\n\n\n### 学習設定\n\n著者らはTensorFlowの分散学習を使い、50個のレプリカをそれぞれNVIDIA Kepler GPU 1枚で動かしました。各レプリカのバッチサイズは32で、100エポック学習しています。\n\n初期の実験ではmomentumを使い、最良のモデルではRMSProp（decay 0.9、$\\epsilon=1.0$）に切り替えました。学習率は0.045で、2エポックごとに0.94を掛けます。学習を安定させるため、勾配クリッピングのしきい値を2.0にし、評価ではパラメータの移動平均を使っています。\n\n## 考察\n\n### 一つずつ加えていく\n\n| ネットワーク | Top-1誤り率 | Top-5誤り率 | 計算量（10億回の演算） |\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| ＋ Label Smoothing | 22.8% | 6.1% | 3.8 |\n| ＋ 7×7の分解 | 21.6% | 5.8% | 4.8 |\n| ＋ BN補助分類器 | **21.2%** | **5.6%** | 4.8 |\n\n*表：原論文Table 3から抜粋。ILSVRC 2012検証セット、シングルクロップ。Inception-v2以下の各行は、それより上のすべての変更を含みます。*\n\nこの表は累積です。各行は、一つ上の行に変更を一つ加えたものです。最後の行の「BN補助分類器」は、補助分類器の畳み込み層だけでなく、全結合層にもbatch normalizationを加えたことを指します。**すべての変更を加えた版を、著者らはInception-v3と呼んでいます**。\n\n注目すべき点がいくつかあります。\n\n- 新しいアーキテクチャに替えるだけで（Inception-v2の行）、top-1誤り率はBN-Inceptionの25.2%から23.4%に下がりますが、計算量も2.0から3.8に増えます。\n- RMSPropとlabel smoothingはどちらも計算量を増やさず、それぞれtop-1で0.3ポイント前後の改善を得ています。\n- 第1層の$7\\times7$を$3\\times3$の3層に分けると、計算量は3.8から4.8に増え、top-1は1.2ポイント改善します。後半の項目の中で最も大きな一歩です。\n\n全体として、Inception-v3の計算量はBN-Inceptionの約2.4倍、GoogLeNetの約3.2倍です。\n\n\n> [!TIP]\n> \n> ここの命名は少しややこしくなっています。この論文は新しいアーキテクチャをInception-v2と呼び、すべての変更を加えたものをInception-v3と呼んでいます。ところが翌年のInception-v4の論文は、ファミリーの歴史を振り返る中で、batch normalizationを加えたBN-InceptionをInception-v2と呼んでいます。今後「Inception-v2」を見かけたら、どちらを指しているのかをまず確認してください。\n> \n> BN-Inceptionの出どころは、私たちのノートで読めます。\n> \n> - **[[15.02] BatchNorm：バッチ正規化](/blog/papers/normalization/batchnorm)**\n\n\n評価はすべて、ILSVRC 2012検証セットのうちブラックリストに入っていない48,238枚で行っています。著者らは50,000枚すべてでも試しており、top-5誤り率は約0.1ポイント、top-1は約0.2ポイントの差でした。\n\n### 解像度を下げると、どれだけ違うか？\n\n検出システムでは画像の小さな一部を分類しなければならないことがよくあり、物体は小さくぼやけています。一般に入力解像度は高いほど良いと考えられていますが、著者らは、ここに二つのことが混ざっていると指摘します。第1層の受容野の解像度と、モデル自体の容量や計算量です。入力だけを縮めてモデルをそのままにすると、ずっと安いモデルでより難しい問題を解くことになります。\n\nそこで彼らは計算量を固定し、入力解像度だけを変えました。入力を小さくするときは、前半のストライドやプーリングを取り除き、後ろの特徴マップの大きさをほぼ同じに保ちます。\n\n| 受容野の大きさ | 調整方法 | Top-1正解率 |\n| --- | --- | ---: |\n| $79\\times79$ | 第1層ストライド1、その後プーリングなし | 75.2% |\n| $151\\times151$ | 第1層ストライド1、その後最大プーリング | 76.4% |\n| $299\\times299$ | 第1層ストライド2、その後最大プーリング | 76.6% |\n\n*表：原論文Table 2から抜粋。調整方法は第9節の実験の説明から整理しました。*\n\n三つのネットワークの計算量はほぼ同じです。解像度の低いネットワークは学習に時間がかかりますが、最終的な成績は$299\\times299$とあまり変わりません。$151\\times151$は0.2ポイント、$79\\times79$は1.4ポイントの差です。\n\n著者らはここから、R-CNNのような検出パイプラインでは、小さな物体のために、解像度は低いが計算量は少なくない専用のネットワークを用意することを検討してよい、と提案しています。\n\n### ほかのモデルと比べる\n\n単一モデル、マルチクロップでの比較です。\n\n| ネットワーク | クロップ数 | Top-1誤り率 | 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*表：原論文Table 4の一部の行を抜粋。*\n\n複数モデルのアンサンブルでの比較です。\n\n| ネットワーク | モデル数 | クロップ数 | Top-1誤り率 | 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*表：原論文Table 5から抜粋。Inception-v3の3.58%はテストセットの結果で、ほかは検証セットの結果です。*\n\n結論で、著者らはHeらのPReLUネットワークと比較しています。Inception-v3はtop-5とtop-1の誤り率を相対的にそれぞれ25%と14%減らしながら、計算量は6分の1、パラメータも5分の1以下です（著者らは推定値だと明記しています）。4モデルのアンサンブルのtop-5誤り率は、2014年に優勝したGoogLeNetのアンサンブルのおよそ半分です。\n\n## 結論\n\nこの論文は、設計ノートのように読めます。Table 3は一項目ずつ積み上げていくので、各変更の貢献が見えます。四つの設計原則についても、著者らはまだ検証が必要な経験則だと率直に断っています。\n\n最後に、この論文が残した部品を整理しておきます。\n\n1. **大きなカーネルを小さく分ける**：$5\\times5$を$3\\times3$の2層に、$n\\times n$を$1\\times n$と$n\\times1$の組に置き換える。\n2. **特徴マップを縮めるときは、畳み込みとプーリングを並列に置き**、情報がせき止められるのを避ける。\n3. **補助分類器の働きは、むしろ正則化に近い**。\n4. **Label smoothing**で、モデルが答えに自信を持ちすぎないようにする。\n\n一つだけ持ち帰るなら、おそらくlabel smoothingでしょう。アーキテクチャと無関係で、数行のコードを足すだけで使え、[ConvNeXt](/blog/papers/classic-cnns/convnext)の学習レシピにも入っています。次の版のInceptionは、いよいよResNetと出会います。続きは[次の記事](/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}}}