今年 1 月に ALBERT に入社した清水です。深層学習プログラマとして自社プロダクト開発をしております。このブログを書くのは始めてなのですが、今日はちょっとプログラミング寄りの記事を。残暑厳しい折ですが、実装の詳細にまで立ち入りつつアツく Yuxin Wu および Kaiming He の考案した手法 Group Normalization（ECCV 2018 採択済）について語ります。Kaiming He 氏は ResNet を筆頭に優れた convolutional neural networks (CNN) の設計で知られていることもあり、みなさんも注目している手法ではないでしょうか？
Chainer v5.0.0b4 を用いて、Chainer に入っている実装と弊社の独自実装での速度比較、また Batch Normalization との速度・精度比較を行いました。その上で、速度差が生じる原因の調査や CUDA を使った高速化の工夫について詳しく記します。ソースコードは MIT ライセンスで GitHub に公開していますので、ぜひご覧ください。
Group Normalization の発想はシンプルです。早速ですが、Group Normalization を端的に表す図（論文 Figure 2 より引用）を見てみましょう。
(N, C, HW) の 3 次元からなる多次元配列が出てきましたが、これは CNN の中間層の出力だと考えると想像しやすいかと思います。バッチサイズ N, チャンネル数 C, 画像の縦幅 H, 画像の横幅 W です。
図に示された Batch Normalization, Layer Normalization, Instance Normalization およびこの記事の本題 Group Normalization の 4 つの手法は、いずれも青色で示された領域ごとに算出される平均・分散によって入力を正規化 (normalize) します。Batch Normalization が各チャンネルごとに平均・分散を求めることは有名ですね。精度・収束性を劇的に向上させる Batch Normalization は今や CNN のデファクトスタンダードですが、しかし
といった難点も併せ持っており、いつでも使えるわけではありません。このためミニバッチに依存しない正規化手法が待ち望まれていました。
そのような手法として、全チャンネルにまたがって平均・分散を取る Layer Normalization と、各チャンネル独立に画像の縦横方向についてのみ平均・分散を取る Instance Normalization が考案されました。とはいえ十分にバッチサイズが確保されている条件下での精度は Batch Normalization に比べてかなり劣っており、主流とはなっていません。
そこで登場したのが Group Normalization です。チャンネルを G 個にグルーピングして Layer Normalization と Instance Normalization の中間的な処理を行うことで、画像分類などのタスクで Batch Normalization に匹敵する精度を実現しました。グループ数 G を 32 にした場合がベストだったと論文に述べられていますが、それほど G の値に対して敏感ではないようです。Group Normalization の論文では、Instance Normalization には複数のチャンネルの組み合わせによって表現される特徴を歪めてしまう問題があると考察されています。その対極になるのが Layer Normalization ですが、こちらは大域的すぎて、特に重要ではないチャンネルが画像全体にわたって高い値を示した場合に他の全てのチャンネルが抑制されてしまいます。中間的な Group Normalization は良いとこ取りをできるというわけです。
なんだか素晴らしそうですね。Chainer では v5.0.0b3 から Group Normalization がサポートされているのでお手軽に使えます。しかし、本当に Batch Normalization をドロップインで置き換えて精度低下は起きないのでしょうか？ Batch Normalization と同等の速度で動作するのでしょうか？ この疑問を検証します。
結論から言えば、Batch Normalization を単に Group Normalization に置き換えるだけでは精度がかなり落ちてしまいました。なので Group Normalization を使う場合は精度の確認やパラメータチューニングをきちんとやるべきでしょう。また、Chainer v5.0.0b3 に追加された Group Normalization の実装はあまり効率的ではなく、CNN 全体の実行速度を大きく下げてしまうことがわかりました。この原因や、より効率のいい実装方法についても詳述します。
はじめまして、システムソリューション部の松本です。
今回は、ディープラーニングの分散学習を可能にするサービス「Azure Batch AI Training」を用いて、Twitterの投稿に対する分類モデルを分散学習させてみようと思います。
初めまして。
システムソリューション部の長田と申します。
昨今では「AI」や「Deep Learning」などのキーワードとともに、データ分析が注目されています。 データ分析を行うためのツールは数多く存在し、それらをインストールするには意外と手間がかかります。 特にDeep LearningのアルゴリズムをGPUで計算する際に使われるcuda周りのインストールはノウハウがないと面倒です。
本記事では、データ分析で用いる主要なツールがプレインストールされているAzureのデータサイエンス仮想マシン(DSVM)を使ってDeep Learningを行ってみた感想について書いていきます。
システムソリューション部の佐藤奏です。
業務でAWS Data Pipelineを結構ヘビーに使ったので、調べにくいところやハマりどころをQ&A形式でご紹介します。
サービスの概要について少しだけコメントします。その後はひたすら細かい話になります。なお、以下はもっぱらリソースとしてEC2を使う場合の記述です（EC2の他に、EMRクラスタを起動することもできますが、筆者は使ったことがありません）。
システムソリューション部の佐藤奏です。
並列分散処理フレームワークApache Sparkがホットな昨今。サンプルコードや活用事例もいろいろと公開されていますが、では実際にSparkを利用してシステムを構築しようとするとき、どのような考慮が必要なのでしょうか。
今回は「SparkとAWS EMRを使ったシステム構築」を念頭に、開発の初期段階――技術選定や開発スケジュール検討、外部設計、プロトタイプ作成・評価――において有用な情報や開発の進め方のポイントをいろいろとご紹介してみようと思います。結構、地味な話が多いですがお付き合いください。
本記事執筆時点でのSparkの最新バージョン1.6.1をベースとした記述です。
このエントリーはGoogle Cloud Platform Advent Calendar 2015の14日目です。
10月に入社しましてブログには初めて投稿します石井です。休日はJavaScriptやGoで趣味の開発を行っていたり、家に知人を集めてボードゲーム会をしてたりします。
さて、ALBERTはAWSメインの開発を行っているのですが、GCP (Google Cloud Platform) も最近盛り上がって来ている！という事で、新しい案件をGCPで構築してみることにしました。その際にGAE (Google AppEngine) 周りの調査を色々と行ったので、今回は特にManaged VMとCustom Runtimeについて紹介できればと思います。
GAE Managed VM, Custom Runtimeは簡単に言うと、GAEが裏で管理していたコンテナを触れることができるようになったり、自分で定義したDockerのコンテナをGAE上で動かすことがでるようになるものです。
みなさまこんにちは。池内です。
Redis 3.0.0 から正式な機能として盛り込まれたRedis Clusterの構築と基本的な動作について紹介します。
※ 期せずして本日 LINEさんの事例 LINEの100億超/日メッセージを支えるRedis・HBaseのスケールアウト・アップ戦略（A-5） #linedevday – Togetterまとめ が話題になっていますが、合計48TBものメモリサイズで運用しているようです。凄いですね。
概ね上記のような内容です。マルチマスタを「疑似的」としているのは、実際にデータが各ノードに伝播しているわけではないからです。Redis Clusterは、あるレコードをどのノードに保存するかを把握しておき、ノード間でリダイレクトすることによって、どのノードから接続しても指定するデータにたどり着けるというアーキテクチャを採用しています。この記事では便宜上マルチマスタと表記します。