Cloud Cost Optimization Engineer の大澤です。ルンバをレンタルして一昨日から我が家で稼働し始めました。半信半疑だった妻もキレイになった我が家を見て納得してくれました。レンタルなのでランニングコストしかかからないのがいいですね。1年ぐらいしたら返却しようと思います。
本題です。7月25日に開催された July Tech Festa 2020 に登壇してきました。カンファレンスなどのセッション登壇するのは昨年7月の CloudNative Days Tokyo 2019 以来です。
今回も会社から登壇依頼されたものではなく、個人として CfP（Call for Proposals）に応募した結果、採択されて登壇しました。登壇する理由については上のリンク先に書いていますので時間があればお読みください。
続きを読むこんにちは、ニューラルネット老人こと糟谷勇児です。
今回はついに！！！第二回で紹介した2012年の技術、AlexNetを学習させます。
ここまで長かったですね。これができればディープラーニングできたと言って過言ではないでしょう。
これまでC#で作ってきたニューラルネットはある程度汎用的に作ってきたのですが、そうは言ってもAlexNetとして動かすといろいろ問題が出てくるだろうなと思っていました。
そして、いくつか問題が出てきましたが、何とか学習することができました。
正直ここまで続くとは思ってなかったです。奇跡的です。
実際のところ、フルスクラッチで作るのは、次こそ作れないんじゃないかとか、本当に合ってるのかとか、プレッシャーとの戦いです。今のところ月一で続けられていてラッキーです。
AlexNetは最初のコンボリューション層に11×11のフィルタを持っています。
しかし、これは32×32のCifar10の画像には大きすぎるということで縮小版のネットワークが提案されています。
qiita.com
これまで拡張してきたLeNetと比較して、各層でのフィルタの数が圧倒的に多いことと、これまで2回だったコンボリューション層＋MaxPooling層に加えて、三連続のコンボリューション層＋1回のMaxPooling層がついたことが特徴的です。
今回はCifar10の中でも、飛行機と船のみ学習するので、フィルタ数を少なめにしてみました。
早速学習してみましたが、誤差が減っていかない・・・。いろいろ調べてみるとpaddingという画像の周りに仮想の画素を置く操作が必要なことがわかりました。
これまで、LeNetを拡張する形で進めてきたのですが、LeNetにはpaddingが使われていなかったので未実装でした。
こちらが以前紹介したLeNetの図です。
32*32の画像が5*5のフィルターを通すことで28*28になっているのがわかると思います。
画像の左端から右端までフィルターをはみ出ないように操作していくと、縦横28の画像ができるわけです。
しかしこれには問題があります。端っこの画素はフィルタの端っこに一回使われるだけで、あまり考慮されません。
（真ん中の画素は5*5のフィルタなら25回使ってもらえるが、角の画素は1回だけ）
層が浅ければそれでも大きな問題はないですが、深いと何度も端っこがないがしろにされていき、結構広い範囲があまり考慮されなくなります。
LeNetは層が浅いのと数字の認識を目的にしていたので、一番端っこまで線が来ることが稀なため重要視していなかったのかもしれません。あるいは入力画像にすでにpaddingが入っていたのかもしれません。
そんなわけで、画像の周りをpaddingという画素で埋めてあげます。
paddingについてはこちらのブログの図がわかりやすいです。
deepage.net
paddingの画素の値はゼロでいいようです（本当にいいのかな。隣の値を延長するとかしたほうがいい気もするけど・・・）。
さて、前回、下のほうにある飛行機を判定できないという話がありましたが、paddingを入れると一部改善します。
前回と同じネットワーク構造でも90.6%まで精度が上がりました。
さて、これで誤差が減っていくかと思いましたが、勾配がほぼゼロ。
デバッガで値を見てみると、重みの初期値が大きめだったので、何層も経るうちに、ソフトマックス層に20と80のような大きな入力が来るようになっていました。
20と80にソフトマックス関数をかけると、ほぼ0とほぼ1になります。
ソフトマックスは第七回で紹介しましたが、微分すると下記のようになるので、このような値を入れると微分値がほぼゼロになってしまいます。
なので、初期値が小さくなるように全体的に調整しました。
AlexNetの学習の実行時間の7割ぐらいは、コンボリューション層のバックプロパゲーションの計算に使われていたので、そのあたりをチューニングしました。例えばリストを使っていた部分があったので配列に直したりしました。
（ここから先の高速化は、3*3でpaddingありで、stride=1だったらとか条件を付けて、ループをアンローリングするとかしていかないと速くならなそう）
今回は何とか土日で収まるぐらいの学習時間になりました。
今回は、学習率0.0002、バッチサイズ512、8並列で学習しました。学習率は75エポックから、5エポックごとに0.9倍するステップディケイを採用しました。
初回なので、データオーギュメンテーションはせずに4500枚ずつの飛行機と船の画像を入れました。
学習結果はこんな感じです。
精度は最大でも90.0%、これまで使ってきた7層のネットワークにpaddingを入れた場合は90.6まで行ったので、ちょっと微妙な結果な気もします。
ちなみに、いろいろなブログを見るとAlexNetでCifar10を学習する際の精度は86%とかみたいです。
もちろんこれは10カテゴリー全部を学習させる際の話なので、難易度は全然違いますが、AlexNetを使ったとしてもどうしても誤判定するものは出てきそうです。
とはいえ、正直まだAlexNetの能力を完全に引き出せているわけでもないので、もう少しチューニングしてみたいです。
とりあえずAlexNetを作るところまで来ました。
次回はパラメーターを変えたり、学習された重みを調べてみたり、データオーギュメンテーションを入れてみたりいろいろ試して理解を深めていこうと思います。
せっかくだから同じように学習している人向けにコードを公開するのもいいかもしれないですね。
▼本シリーズのほかの記事はこちら
リモートワークが盛んである今、 VPN 接続を利用している人が多いのではないでしょうか。 私もそんな一人ですが、そういえば VPN サーバを立てたことがなかったので、挑戦してみました、というのは表向きの理由で、IPv6 による経路の VPN 接続を行いたいということが真の目的です。
自宅回線は IPv4(PPPoE)・IPv6(IPoE) となっており、IPv4 インターネット利用時は PPPoE の輻輳だと考えられますが、混み合う時間帯に RTT(Round Trip Time)*1 が安定しません（速度は普通に100Mbps を超えており十分です）。 諸々の都合により、IPv4 over IPv6 系サービスに変更できないため、IPv6 で接続する VPN サーバをクラウドサービス上に構築することで自前で IPv4 over IPv6 接続を試みます。イメージとしては、こちら で紹介されているものの経路を変えるというものです。
さらに、自宅から常に安定した経路で通信するために、ラズベリーパイを VPN ルータ化します。
結果として、ping を数回試行すると数回に一度跳ねていた RTT が安定するようになりました。
*1:信号を送って返ってくるまでの時間のこと。ping 値と言われることが多いが、ping とはツールのこと。
Sansan DSOC研究員の前嶋です。「つながりに効く、ネットワーク研究小話」の第15回です。
このブログ連載で様々な研究を紹介していると、「一番好きな社会学の論文は何ですか？」と聞かれることが多々あるのですが、毎回答えに迷ってしまいます。というのも、同じくらい好きな論文が2本あるからです。そのうち片方は、かの有名な「弱い紐帯の強さ」論文ですが、今回の記事では、もう片方の論文についてその内容を紹介します。
2004年に出版された、その論文の名前は、"Chains of Affection: The Structure of Adolescent Romantic and Sexual Networks"です。この論文が面白いのは、交際ネットワークの構造から、社会の中に潜む「暗黙のルール」を炙り出している点です。
論文URL : https://www.journals.uchicago.edu/doi/abs/10.1086/386272
続きを読むこんにちは。 Sansan iOS アプリエンジニアの中川です。
Sansan iOS アプリは今年の 6 月 15 日にメジャーバージョンアップをしました。 このバージョンアップにはオンライン名刺が目玉機能として含まれています。 オンライン名刺は昨今の新型コロナウイルスの流行から企業がテレワークやオンライン上での働き方への移行を迫られている中、名刺交換をオンラインで実施できない現状に対して、会社として向き合わなければならなかった重要な機能でした。
| 項目 | 数字 |
|---|---|
| 開発に関わった iOS アプリエンジニア | 9 人 (全員) |
| 開発期間 | 33 日 (営業日ベース) |
| Pull Request 数 | 189 Pull Requests |
| 前バージョン (v5.6.2) からのコミット数 | 1567 commits |
| 前バージョン (v5.6.2) からの変更ファイル数 | 384 files |
改めて、数字を出してみると、多くのメンバーがオンライン名刺に向き合ってくれたことが分かります。 これほどの人数で一機能を作るのは自分の経験の中でもはじめてのことでいかに円滑に進めて、事業的に要求されている期日にコミットできるかプロジェクト当初に頭を悩ませていたことを思い出せます。
では、何がオンライン名刺の開発で有効だったか、チームで振り返って出た意見を以下に挙げます。
Sansanプロダクト開発部・基盤チームの加畑です。法人向け名刺管理サービスSansan(以下、Sansan)の開発をしています。
これまでに、レガシーシステムの改善を主題とした記事を2つ書きました。レガシーシステムのおそうじでは、レガシーシステムを改善するプロジェクトの担当者としての経験をご紹介しました。レガシーシステムとつきあうでは、少し視点を広げ、ソフトウェアや開発組織の拡大に応じたレガシー化の変遷について考察し、組織としてどのように取り組むべきかの一考察を紹介しました。
ソフトウェア（システム）は本質的に複雑性をはらんでおり、変更が生じるかぎりにおいて、メンテナンス性の低下、いわゆるレガシー化と呼ばれる現象は避けられません。レガシーなシステムは事業の視点からみても技術的負債としてメンテナンスコストとして「利息」を払い続けることになります。それを避けるためには継続的に改善していく必要がありますが、レガシー改善プロジェクトはそれ自体が直接的な利益やユーザ価値を生まないにもかかわらず、コストが生じます。このコストを払わない最良の方法のひとつは、レガシー化してからなおすのではなく、開発の過程で生じるレガシー化の程度を最小限に抑えることです。
そこで今回は、「そもそもレガシーシステムを作り込まない」ことを目的に、開発プロセスについて考えてみます。
続きを読むこんにちは、DSOC研究開発部の橋本です。最近買ってよかったな、と思ったものは「詰め替えそのまま」です。これはシャンプーやトリートメントの詰め替えをそのままホルダーにかけて使うことができるようになるグッズで、文字通り（比較的安い）詰め替えをそのまま・簡単に使えるようになる点、お風呂の床に詰め替えを置かなくて済むようになる点という2つの点から非常に良いです。気になる人はぜひググって買ってみてください。
詰め替えそのままの話はさておき、今回時間依存性を考慮したword embeddingsの話をします。
© Sansan, Inc.
